6/95 FC-AL Direct Attach Disk Adhoc Minutes

Kurt Chan kc at core.rose.hp.com
Thu Jun 29 19:23:41 PDT 1995


From:  Kurt Chan 
To:    FC, SCSI Reflectors 
Subj:  6/95 FC-AL Direct Attach Disk Adhoc Minutes
Date:  6/29/95 
 
               FC-AL Direct Attach Disk Adhoc Meeting Minutes
                            Rochester, MN  
                               6/16/95     

    Dal Allan         ENDL             dal.allan at mcimail.com 
    Jaime Calle       AT&T GIS         jaime.calle at sandiegoca.attgis.com
    Kurt Chan         HP Roseville     kc at core.rose.hp.com
    Mike Chenery      Fujutsu          mchenery at fcpa.fujitsu.com
    Jim Coomes        Seagate          jim_coomes at notes.seagate.com
    Pete Cummings     IBM              petec at vnet.ibm.com
    Brian Doore       Seagate          brian_doore at notes.seagate.com
    Phil Duclos       Array Tech       pjd at arraytech.com
    Bob Edge          Tektronix        bob.c.edge at tek.com
    Dave Ford         Cambex           dford at cambex.com
    Mike Fitzpatrick  Seagate          mike.fitzpatrick at notes.seagate.com
    Gene Freeman      Symbios Logic    gene.freeman at symbios.com
    Ed Frymoyer       EMF              emf at best.com
    Ed Gardner        Quantum          gardner at acm.org
    Bill Galloway     Compaq           billg at bangate.compaq.com
    Gary Goodwin      IBM              ggoodwin at vnet.ibm.com
    Doug Hagerman     DEC              hagerman at starch.enet.dec.com
    Norm Harris       Adaptec          nharris at eng.adaptec.com
    Tim Johnson       Cray             tjohnson at cray.com
    Hyeu Tae Lee                       htlee at prism.etri.re.kr
    Mike Miller       Seagate          mike_miller at notes.seagate.com
    Gene Milligan     Seagate          gene_milligan at notes.seagate.com
    James W. Oliver   SGI              oliver at sgi.com
    Tom Osten         IBM              thomas_j_osten at vnet.ibm.com
    Thomas M. Pasker                   crbh99a at prodigy.com
    Wayne Rickard     Emulex           w_rickard at emulex.com
    Richard Rolls     IBM              rrolls at vnet.ibm.com
    Jeff Stai         Western Digital  stai at dt.wdc.com
    Gary Stephens     FSI              6363897 at mcimail.com
    Arlan Stone       Unisys           arlan.stone at mv.unisys.com
    Horst Truestedt   IBM              truested at vnet.ibm.com
    Peter Walford     FCSI/DemoGraFx   walford at btr.com
    Joel Warford      Adaptec          jwarf at corp.adaptec.com
    Fanny Wong        IBM              fwong at vnet.ibm.com
    Stewart Wyatt     HP DMD           stewart at hpbs3928.boi.hp.com
    Teras Yonker      IBM              teras at vnet.ibm.com


1. SCHEDULE AND SCOPE

   Although this was the last discusssion of the day, it is reported here
   first since it had the most impact on the future activities of the
   group.  At the suggestion of Dal and Doug, it was agreed that our
   highest priority was releasing a document for public consumption
   representing closure on the agreements to date.  An SD-3 for a Technical
   Report will be submitted to X3T11 in August, with an editor for that TR
   to be named.  We'll still meet during the Monday of X3T10 week in
   Colorado Springs at the Red Lion, but primarily to confirm the changes
   agreed upon at this meeting.  New subjects must be posted on the
   disk_attach reflector prior to the next meeting in order to optimize
   meeting time.

   In order to invite review of the TR by the tape communities and others,
   the term "Disk" will be replaced by "FCP" in the title, although the
   content will not otherwise change (except some softer wording in the
   Scope section to connote that the non-disk specific sections may be
   applicable to other device types).

   It is expected that Friday of X3T11 week in Tarrytown and Monday of
   X3T10 week in Manchester will be available for FC-AL2 discussion.


2. ADDRESS DISCOVERY AND NPA USAGE

   The FC-PH working group suggested that the Read Hard Address ELS be
   changed to accomodate six identifiers:

   - Hard Address for LIHA Loop Initialization (8 bits)
   - Preferred Address for Fabric Login (24 bits)
   - N_Port ID (24 bits)
   - Port Name (60 bits)
   - Node Name (60 bits)

   The adhoc WG discussed the addition of one bit as a pointer to a "Node
   Discover" function (yet to be defined).  This function would report node
   attributes such as how many ports are connected to the node, whether or
   not the other ports have functional addresses, etc.  However, since it
   was unclear how this bit would be used to solve generic multi-pathing
   diagnostics, it's inclusion will be deferred.  For example, for an
   N-ported node with 'N-M' ports functional, some method of communicating
   configuration as well as diagnostic information is needed which is
   beyond the scope of ADISC.

   The NPA bit in PLOGI will be defined in a later version of FC-PH2.  As a
   placeholder for future reference, it's use will be prohibited in the
   until the NPA proposal can be fully evaluated by the group or in public
   review.


3. TARGET-INITIATED PDISC

   A case was made for requiring targets to validate the initiators they
   have open tasks with before resuming those tasks following a LIP.  It
   was deemed insufficient to have the ports which CHANGED their addresses
   be responsible for originating PDISC, since Jim Coomes described a
   scenario where target-initiated PDISC is essential.  

   Consider a dual-ported initiator connected to separate loops:

    +-----------+-----------+     +------------+     +-----------+
    |           | Initiator |---->|  Target    |---->| Target    |---+
    |           |    Port   |     |  AL_PA = 2 |     | AL_PA = 3 |   | LOOP 1
    |           |  1ABCDEF  |     +------------+     +-----------+   |
    |           | AL_PA = 1 |<---------<-----------<-----------<-----+
    |           +-----------+
    |    NODE               |
    |  0ABCDEF  +-----------+     +------------+     +-----------+
    |           | Initiator |---->|  Target    |---->| Target    |---+
    |           |    Port   |     |  AL_PA = 2 |     | AL_PA = 3 |   | LOOP 2
    |           |  2ABCDEF  |     +------------+     +-----------+   |
    |           | AL_PA = 1 |<---------<-----------<-----------<-----+
    +-----------------------+

   The above configuration consists of two identical loops with identical
   AL_PAs.  The targets for Loop 1 are in one cabinet, and the targets for
   Loop 2 are in another cabinet.  The cabinets are inadvertantly swapped
   so that Initiator Port 1 connects to Loop 2, and Initiator Port 2
   connects to Loop 1.  Loop initialization in the initiator does not
   detect any changes, so if the targets do not validate that the same
   initiator ports are in use before they continue I/Os with those
   initiator ports, data corruption may occur.

   Furthermore, if an initiator merely goes offline, there are no timers in
   the target to reclaim resources dedicated to the dead initiator, which
   may affect the performance of the remaining initiators.

   Resolution:  If Target-Initiated PDISC detects that an Initiator for
   which it has open tasks is no longer present (the Port|Node name pair is
   nonexistent at the expected AL_PA) the target shall implicitly abort all
   tasks associated with the missing initiator by performing implicit
   logout.


4. HARD VS PREVIOUSLY ACQUIRED ADDRESSES

   Brian described why he thought hard addresses should not use LIPA
   following address switch changes:

                              WWN = A          WWN = B
          +-----------+     +----------+     +----------+
          |           |---->|  TARGET  |---->|  TARGET  |---+
          | Initiator |     | Hard = 1 |     | Hard = 1 |   |
          | AL_PA = 3 |     | Soft = 1 |     | Soft = 2 |   |
          |           |     +----------+     +----------+   |
          |           |<---------<----------<---------<-----+
          +-----------+

    An initiator is loop master, and two targets share a conflicting hard
    address.  Target B defers to Target A, which is 'upstream' from B.  The
    initiator, through the use of ADISC, notices the hard address conflict
    and points a system administrator to the pair of conflicting targets.
    The administrator changes the hard address of Target A so it doesn't
    conflict with B and resets A:

                              WWN = A          WWN = B
          +-----------+     +----------+     +----------+
          |           |---->|  TARGET  |---->|  TARGET  |---+
          | Initiator |     | Hard = 2 |     | Hard = 1 |   |
          | AL_PA = 3 |     | Soft = 1 |     | Soft = 2 |   |
          |           |     +----------+     +----------+   |
          |           |<---------<----------<---------<-----+
          +-----------+

    Since B attempts to acquire it's previously acquired AL_PA instead of
    it's hard address, we end up with the same configuration unless BOTH
    targets are hard reset.

    Brian's philosophy was that a device should not be configured to
    acquire a hard address unless the application could not tolerate having
    that address at any other value.  An example was raised whereby
    evolving software could initially require hard addresses, but in the
    future may migrate to being tolerant of soft addresses but would not
    want to require it's users to set switches to '7F' on all legacy
    storage cabinets in order to function with the new SW.

    The concensus of the group was that if 'N' devices are configured with
    conflicting hard addresses, the acceptable penalty for applications
    that require unique hard addresses is to:

       a) resolve ALL switch conflicts before resetting ANY devices, and
       b) reset/power-cycle all 'N' devices with address conflicts

     rather than allow exceptions to the FC-AL rules regarding previously
     acquired AL_PAs.  Applications which ARE tolerant of soft addresss
     need not take this action.  All private loop devices will be required
     to follow the FC-AL rules regarding previously acquired addresses.

     (Note - this may lead to the '7F' setting never being used, since
      targets will perform appropriately for soft address tolerant
      applications regardless of what the hard address switches are set to).


5. RRQ

   HP suggested that, in order to minimize differences in error recovery
   between fabric and loop based initiators, that targets support the RRQ
   ELS.  For private loops (or fabrics which guarantee order) the recovery
   timer can be set to zero.  In the absence of protest from target
   implementors, this will be added to the profile.


6. TIMERS

   A basic dilemma exists between the various timers used.  E_D_TOV, which
   is used to determine when to time-out loop initialization, must be long
   enough to accomodate large, maximally configured physical loops with
   "slow" devices.  However, other timing functions derived from E_D_TOV
   need not be long (indeed, some can be zero) on in-order fabrics such as
   private loops.  I will summarize the issues and write up a set of timer
   recommendations for the next working group. 


7. FCP_RSP LENGTH 

   Jeff Stai proposed putting restrictions on the variable length fields in
   FCP_RSP for both GOOD and non-GOOD status.  The reasons are to be able
   to automate the handling of status efficiently without having to worry
   about large payloads.  24 bytes of payload overhead are already used in
   FCP, even with zero length FCP_RSP_INFO and FCP_SNS_INFO.  Therefore,
   the following field length restrictions will be added:

                     FCP_RSP_INFO  FCP_SNS_INFO   Total FCP_RSP payload
                     ------------  ------------   ---------------------
   GOOD status         0 bytes        0 bytes           24 bytes
   non-GOOD status     4 bytes      100 bytes          128 bytes


8. 128 REVISITED

   It was decided that the profile should continue to require all devices
   to be able to receive 256-byte frames, since FC-AL requires each
   participating NL_Port to be able to receive 132-byte initialization
   frames (see FC-AL 4.5, clause 10, page 50).


9. LOOP_ID DEFINITION

   Dal suggested that the concept of Loop_ID need only apply to the
   SFF-8045 definition:  the 7-bit representation of the Hard AL_PA.  His
   reasons were:

   a) if hard addresses are not being used, Loop_IDs lose their usefulness 
      in identifying targets (positional information or other application-
      specific information is required), and
   b) SFF-8045 already uses the term "Loop Identifier". 

   A separate term, therefore, will be defined to denote the 7-bit
   representation of a "working" or "operating" address (which may be
   fabric-assigned or a soft address as well as a hard address).




More information about the T10 mailing list