4/95 FC-AL Direct Attach Disk Adhoc Meeting Minutes

Kurt Chan kc at core.rose.hp.com
Tue Apr 18 22:34:26 PDT 1995


From:  Kurt Chan, HP
To:    FC, SCSI Reflectors
Subj:  4/95 FC-AL Direct Attach Disk Adhoc Minutes
Date:  18 Apr 95

               FC-AL Direct Attach Disk Adhoc Meeting Minutes
                              Monterey, CA   
                                4/7/95      

    Dal Allan           ENDL                    dal.allan at mcimail.com 
    Charles Binford     Symbios Logic           charles.binford at symbios.com
    Kurt Chan           HP Roseville            kc at core.rose.hp.com
    Mike Chenery        Fujitsu                 mchenery at fcpa.fujitsu.com
    Jim Coomes          Seagate                 jim_coomes at notes.seagate.com
    Roger Cummings      StorageTek              roger_cummings at stortek.com
    Gene Freeman        Symbios Logic           gene.freeman at symbios.com
    Ed Frymoyer         HP FCSI                 emf at best.com
    Stillman Gates      Adaptec                 stillman at eng.adaptec.com
    Gary Goodwin        IBM San Jose            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 Research           tjohnson at cray.com
    Bob Kembel          Connectivity Solutions  73040.1376 at compuserve.com
    Budd Levin          Applied MicroCircuits   buddl at amcc.com
    Roland Marbot       Bull                    roland.marbot at frcl.bull.fr.com
    Dennis Moore        Zadian                  dmoore at netcom.com
    Allison Parsons     Conner                  allison.parsons at conner.com
    Richard Rolls       IBM San Jose            rrolls at vnet.ibm.com
    Colin Schaffer      Intellistor/FJ          cschaffer at intellistor.com
    Brian R. Smith      Infinity Software       isi_info at io.com
    Bob Snively         Sun Microsystems        bob.snively at sun.com
    Jeff Stai           WDC-IOP                 stai at dt.wdc.com
    Arlan Stone         Unisys                  astone at po2.mv.unisys.com
    Robert Stubbs       FCPA-Intellistor        stubbs at intellistor.com
    Horst Truestedt     IBM Rochester           truested at vnet.ibm.com
    Peter Walford       FCSI/DemoGraFx          walford at btr.com
    Stewart Wyatt       HP Boise                setwart at hpdmd48.boi.hp.com

1.  TARGET RESET and ADDRESS CHANGES

    It was agreed that Target Reset will not invoke changes to the
    preferred address, and that such changes would only be invoked by
    LIP.  For example, if a device has a switch from which it derives
    its preferred address, and that switch is manually modified
    without power-cycling the device, Target Reset does not cause the
    modified preferred address to take effect.

    It was also noted that the hierarchy for which address to use when
    LIP is received is:
    1) Fabric-assigned (which does not pertain to private loop devices),
    2) Previously-acquired, and
    3) Hard-assigned or "preferred"
    4) Soft-assigned. 

    This implies that it is mandatory for a port to remember its
    previously acquired address, and to use that address even if its
    preferred address is now available.

      [Q:  Is a device allowed to "forget" it's previously acquired
       address and fall back to requesting it's preferred address only
       on power cycle, or also when it receives a Hard Reset LIP?]

2.  TARGET RESET AND LOGIN PARAMETERS

    The need to be able to synchronize the state of multiple
    initiators which are joining or exiting a quorum via shared
    Targets brought up the subject of whether or not Target Reset
    could be made to cause a Target to log out all initiators as part
    of performing "hard" reset.  The net effect of such a proposal
    would be that any spurious I/Os which might be emanating from
    intelligent host adapters in a "dead" initiator would be prevented
    from affecting the shared Target until some intelligence in the
    host performed N_Port Login.

    Dal and Bob felt the preferred solution was to incorporate this
    functionality into a new type of reserve function, (e.g., a new
    BLOCK Command which specifies which Initiator the Target should
    send RESERVATION CONFLICT to until an UNBLOCK command is
    received).  It is likely that the same addressing structures and
    reservation priorities for these commands will leverage the work
    Snively has done on third party PERSISTENT RESERVE.  HP will
    follow up by posting any proposals to the SCSI reflector following
    consultation with HP implementors.  Direct suggestions/comments to
    me (kc at core.rose.hp.com).

3.  BB FLOW CONTROL AND DUAL PORTS

    Horst was seeking a new login bit on behalf of Giles Frazier.  He
    was concerned that if a dual ported device has a common set of
    BB_Buffers between its two ports, data may be lost if both ports
    are active and Login_BB_Credit > 0 on both ports.  The resolution
    was that if both ports cannot be used simultaneously, then no
    login bits would help.  Three solutions were proposed:

    1) Advertise Login_BB_Credit = 0 on both ports
    2) Have separate BB_Flow_Control management and buffers on each portj
    3) Activate only one port at a time (using the bypass function). 

    Jim Coomes noted that merely performing the bypass does not cause
    a loop reconfiguration - a LIP is needed to cause a port to
    relinquish its AL_PA.  Similarly, reenabling a port does not
    automatically cause it to enter participating mode, since it may
    not have a valid AL-PA when enabled.

4.  SEQ_ID REUSE

    This question is related to aliasing Sequence Qualifiers on long
    reads.  In class 3 without the transfer of Sequence Initiative to
    "acknowledge" receipt of frames, FC-PH prohibits the wrapping of
    SEQ_CNT within a SEQ_ID or reuse of a SEQ_ID within an Exchange
    (even if Relative Offset is being used for reassembly).  A
    Sequence is therefore limited in length to 65536 frames, and an
    Exchange with no transfer of Sequence Initiative is limited in
    length to 256 Sequences.  For an average frame length of 256
    bytes, this makes for 16MB Sequences and 4GB Read Exchanges.

    Several solutions were discussed, but they involved either
    topology specific hardware reassembly techniques or changes to
    FC-PH.  Unless new proposals for extending Read Exchange length
    are introduced, the above FC-PH rules will continue to apply to
    private loops.

5.  FCP_RSP INTEGRITY

    Charles Binford made a case for FCP_RSP integrity, bringing up the
    example of a command for which deferred error status was lost and
    therefore jeapordized data integrity.  His proposal for an
    optional FC-4 acknowledgement to FCP_RSP, will be discussed at
    Harrisburg:

    1. Two New IUs
    - FCP_RSP_REQ_CONFIRM
    - FCP_RSP_CONFIRM
    
    1.1 IU Definition
    
    1.1.1 FCP_RSP_REQ_CONFIRM (target to init) 

    An FCP_RSP_REQ_CONFIRM IU is a normal FCP_RSP IU with the following
    F_CTL bit changes:
    - set Transfer Sequence Initiative
    - do not set Last Sequence
    
    1.1.2 FCP_RSP_CONFIRM (Init to target) 
   
    An FCP_RSP_CONFIRM IU is defined as follows:
    - R_CTL bits 31-28: 0000 FC-4 Device_Data
    - R_CTL bits 27-24: 0011 Solicited Control
    - Type code: 0000 1000 (SCSI-FCP)
    - Payload: 4 bytes, value TBD
    
    2. Interoperability
    - Use determined by PRLI parameter.
    - Only invoked by target if initiator supports.
    - May be invoked by target on a per IO basis (e.g. only when status
      is other than GOOD)
    
    3. Usage Rules
    
    3.1 Target use of FCP_RSP_REQ_CONFIRM

    If the target wishes to request confirmation from the initiator of
    an FCP_RSP it shall send the FCP_RSP_REQ_CONFIRM IU instead of the
    normal FCP_RSP.

    3.2 Initiator use of FCP_RSP_CONFIRM 

    When an initiator detects FCP_RSP_REQ_CONFIRM IU it shall send an
    FCP_RSP_CONFIRM IU.

    3.3 Target cleanup of exchange and data 

    A target which sends an FCP_RSP_REQ_CONFIRM IU shall maintain any
    associated sense data to allow for a vendor unique number of
    retries until any of the following occurs:

    -  an FCP_RSP_CONFIRM IU is received with a payload of (TBD) and FQXID

    -  an FCP_CMD is received with an OX_ID and S_ID matching that of
       the yet to be confirmed FCP_RSP_REQ_CONFIRM IU.  (Note:  this
       is the case where the FCP_RSP_CONFIRM was lost.)

    3.4 Target Error Detection and Recovery

    3.4.1 Target detection of lost FCP_RSP_REQ_CONFIRM IU 

    A target shall assume the FCP_RSP_REQ_CONFIRM IU was not received
    by the initiator if the FCP_RSP_CONFIRM IU is not received within
    a target specific time-out.  The time-out shall be greater than
    R_A_TOV.

    3.4.2 Target retry of FCP_RSP_REQ_CONFIRM IU

    The target may retry the FCP_RSP_REQ_CONFIRM IU using the
    following rules:

    - maintain the original FCP_SNS_INFO and FCP_STATUS 
    - set the RSP_CODE to FCP_RSP_RETRY (value TBD)

    3.4.3 Initiator receipt of a retried FCP_RSP_REQ_CONFIRM IU 

    If an initiator receives an FCP_RSP_REQ_CONFIRM IU with an
    RSP_CODE set to FCP_RSP_RETRY it shall take one of the following
    actions:

    - if the OX_ID is not currently active, send confirmation (previous
      confirmation was lost) 

    - if the FCP_CMD which is active on this OX_ID was sent at time t
      and (current_time - t) >= R_A_TOV, then treat as normal
      FCP_RSP_REQ_CONFIRM and send confirmation (previous
      FCP_RSP_REQ_CONFIRM was lost)

    - if the FCP_CMD which is active on this OX_ID was sent at time t
      and (current_time - t) < R_A_TOV, then ignore (previous
      confirmation was lost and target attempted retry at the same
      time initiator reused OX_ID.  The target will see the new
      FCP_CMD with the given OX_ID and cleanup the previous IO.)

6. Responses to frames when login is incomplete

   Seagate presented a table which demonstrated what the expected
   response should be if a device receives frames from another device
   which it has not completed login with.  This table will be
   incorporated into the loop profile.

             Frame Type                      PLOGI but        
              Received       No PLOGI         No PRLI        
             ----------   ---------------   -------------   
               ABTS            LOGO             PRLO       
             FCP_CMND          LOGO             PRLO      
               LOGO           LS_RJT            ACC      
               PRLI            LOGO             ACC     
               PRLO            LOGO             ACC*
               PDISC           LOGO          ACC or LOGO**
               PLOGI           ACC              ACC  
               RLS             ACC              ACC 
               
              * with reason code "image pair does not exist"
              ** if the Port Name does not match the previous login,
                 the device shall respond to PDISC with LOGO

7. ALIAS D_IDs IN PUBLIC LOOP DEVICES

   Horst brought up the issue of what happens when a private loop
   device originates an Exchange to a public loop device before it
   knows about the nonzero upper 16 bits of the public loop device's
   address.  The group decided that instead of requiring public loop
   devices to respond to two different D_IDs (0000nn and xxxxnn), that
   it would be better to:

   - require private loop devices to use the true addresses (upper 16
     bits nonzero) of public loop devices when transmitting frames to
     them

   - not require that public loop devices maintain an "alias" in order
     to communicate with private loop devices

   - require that public loop devices originate N_Port login with
     any private loop devices they wish to communicate with

   - continue to require (per FC-PH) that both public and private loop
     devices which do not support aliases discard frames (in class 3)
     that arrive with the wrong D_ID.

   Note that this means that it is not possible for private loop
   devices to "discover" public loop devices which are sharing the
   same loop unless the public loop devices support a special alias
   (respond to 0000nn or xxxxnn, where xxxx = upper 16 bits of the
   attached FL_Port or F/NL_Port).

8. RETRANSMISSION LATENCY

   Ed Gardner did some research and discovered the latency through an
   NL_Port using Seagate VHDL and commercially available transceivers
   can exceed the 6 word latency specified by FC-AL.  Ed will draft a
   comment suggesting the word "maximum" be changed to "nominal" and
   the word "shall" be changed to "should" in the following FC-AL
   clause 8 on page 18:

     "The maximum delay of a Transmission Word through an L_Port
      in the MONITORING or ARBITRATING states shall not exceed six
      Transmission Word periods."

9. USE OF DISCONNECT-RECONNECT MODE PAGE

   Ed discussed the use of existing mode pages on FC-AL Rather than
   attempt to map loop-specific functionality onto existing mode
   pages, Ed was encouraged to define loop-specific parameters where
   needed, particularly since SGI will be introducing some
   loop-specific Mode Page parameters to prevent a device from
   enabling itself onto the loop on power-up, or issuing LIP on
   power-up.  Some of the parameters discussed:

   - max Sequence Size
   - max Burst Size (data sent in a single loop tenancy)
   - min Burst Size (for multi-frame Sequences - the minimum amount of
     data a port must be able to transmit at link rate before
     attempting ARB)

10.  256 BYTE MIN FRAME SIZE

    It was suggested that the profile adopt a minimum frame payload
    size of of 256 bytes, rather than the 128 bytes required by FC-PH.
    The reason is twofold - one is in anticipation of longer payloads
    for extended link services such as PLOGI and a desire to keep them
    single-frame sequences.  The other is that initialization frames
    which support the AL_PA position map require payloads of 132 bytes
    (see FC-AL4.4 , p52) Dal suggested that the 128 byte value in
    FC-PH was only to accomodate early fabric implementations, and was
    not meant as an architectural limit for future products such as
    loop ports.

11. NEXT MEETINGS

    Meetings will be held on Mondays of X3T10 week at 9am and on
    Fridays of X3T11 week at 830am.  The next two meetings are at
    Harrisburg with X3T10 (May 8) and at Rochester with X3T11 (June
    16).




More information about the T10 mailing list