10/94 Direct Attach Disk Adhoc Minutes

Kurt Chan kc at core.rose.hp.com
Fri Oct 14 01:27:18 PDT 1994

From:  Kurt Chan, HP (kc at core.rose.hp.com)
To:    FC, SCSI Reflectors
Subj:  Minutes of 10/4/94 FC-AL Ad Hoc Meeting
Date:  10/14/94

           FC-AL Direct Attach DIsk Ad Hoc Meeting Minutes
                      Red Lion Stapleton
                         Denver, CO

There were 21 attendees: 

  Dal Allan, ENDL                  250-1752 at mcimail.com
  Charles Binford, ATT-GIS         charles.binford at wichitaks.ncr.com
  Kurt Chan, HP                    kc at core.rose.hp.com
  Jim Coomes, Seagate              jim_coomes at notes.seagate.com
  Steve Dean, HP                   dean at core.rose.hp.com
  Brian Doore, Seagate             brian_doore at notes.seagate.com
  Giles Frazier, IBM               gfrazier at ausvm6.vnet.ibm.com
  Gene Freeman, ATT-GIS-NCR Micro  gene.freeman at colospgs.ncr.com
  Stillman Gates, Adaptec          stillman at eng.adaptec.com
  Norm Harris, Adaptec             nharris at eng.adaptec.com
  M.K. Jibbe, ATT-GIS              mahmoud.jibbe at wichitaks.ncr.com
  Jon Kellen, Cray Research        jjk at cray.com
  Jean Kodama, QLogic              j_kodama at qlc.com
  Jim McGrath, Quantum             jmcgrath at qntm.com
  Greg Scherer, Emulex             g_scherer at emulex.com
  Ken Smith, Conner                ken.smith at conner.com
  Horst Truestedt, IBM             truested at vnet.ibm.com
  Peter Walford, FCSI              walford at btr.com
  Dan Weinstein, EMC               danw at emc.com
  Jeff Williams, HP                jlw at hpdmd48.boi.hp.com
  Fanny Wong, IBM                  fwong at vnet.ibm.com


As usual, feel free to comment if you see issues/inaccuracies in any of the
following and these will automatically become agenda items for next month.

Although Nov 1 meant travelling on Halloween night, a straw poll indicated
that people were unwilling to move the meeting later into the week (sorry
Jeff, I tried!).  So the next meeting will be:

        Date: Nov 1-2
        Time: 8:30
        Location; Red Lion Stapleton, Denver

I hope to wrap up all of the remaining private loop protocol issues so we
can publish a profile in December and start the new year with Public Loop
work.  We'll make the second day Dal's FL_Port WG and a springboard into
public loop work. See the November Agenda below.

Beginning in January, I'd like to begin holding our meetings in conjunction
with X3T10 and X3T11 on Mondays:
        Mon, Jan 9   X3T10   Lake Tahoe, NV
        Mon, Feb 6   X3T11   So. Calif.
        Mon, Mar 6   X3T10   Newport Beach, CA
        Mon, Apr 3   X3T11   Monterey, CA 
        Mon, Jun 12  X3T10   Rochester, MN
        Mon, Jul 10  X3T11   Colorado Springs

Steve reviewed the fairness problems brought up at the previous meeting,
and discussed over email since.  After reviewing the nature of the problems
and the proposed solutions by Emulex, the agreement was not to change the
existing FC-AL document for the following reasons:

a) the need to forward a document for public review were perceived to
   outweigh the need to solve the problems before forwarding.

b) Further analysis/simulation may reveal other problems with FC-AL that
   would warrant changes to the proposed solutions.

c) 2 of the 3 scenarios would not result in long-term or wide-spread
   starvation, and the third requires very specific configurations, traffic
   patterns, and congestive traffic volumes in order to create the problem
   in a private SCSI Loop application.  ULP timeouts should provide
   recovery in severe cases without changes to FC-AL.

d) Early implementors can still move forward with fixes to these problems
   to ensure fairness, despite the absence of documentation in FC-AL.
   However, this should not affect interoperability with ports which have
   not implemented the same solutions.

Action items:

- Horst will document the details of the problems and the proposed
  solutions of the early implementors on the reflector.

- The private loop profile will add these to an Informative Annex.

- These solutions may show up as FC-AL public review comments if they
  survive scrutiny over the next 4 months.

3.  ACA
The consensus of the participants is that ACA=1 appears to be the only
viable method for Initiators and Targets to reliably interoperate.  A
problem exists since Peter Walford indicated that the FCSI SCSI
Profile requires ACA=0, and FCSI participants have been reluctant to
depart from previous revisions of the profile. 

One of the problems with ACA=0 is that sense data will be permanently
lost with autosense if FCP_RSP to a faulting command is lost.

Furthermore, I suggest that ACA=1 can only work in this profile if:

- Sense data is retained by a Target as long as an ACA condition exists
  (suggested by Charles Binford)
- ABTS/ABTX do not clear an ACA condition.
- An ACA condition is established upon transmission of FCP_RSP, regardless
  of the class of service.
- One of the three changes is made:
  a) SAM is modified to accomodate protocols where the delivery of autosense
     is unreliable,
  b) Autosense is made optional in FCP for class 3, 
  c) Autosense delivery is made reliable in FCP through the creation of two
     new IUs (e.g., I8: ACA_RSP and T12: I8_RSP) which are only used for
     errored commands.

ACA will be discussed in further detail Nov 1-2.

It was agreed that FCP_RSP to Task management functions were
architecturally consistent and needed to ensure a reliable task
management delivery service is provided by FCP, in both class 2 and
class 3.  It was suggested that a public review comment be generated
to allow the use of T1 instead of T5 for Task Management:

o All commands have the same Information Category = 6.
o I4 would be used with normal payload for the response with:

       FCP_RSP_LEN_VALID = 1
       SCSI status byte = 0
   - FCP_RESID = 0 
   - FCP_SNS_LEN = 0
   - FCP_RSP_LEN = 8
       RSP_CODE = 00  task management function
                = 04  not performed because not function not supported
                = 05  not performed but function is supported 

- What is returned if Target Reset is sent to a Target which has
  an ACA condition established with another Initiator?  
- Do ACA conditions live across Target Reset? 

- No ports are prohibited from issuing selective power-on reset. However,
  FL_Ports and public loop devices are prohibited from *responding* to them.

- This table applies to single-lun Targets only.

- This profile prohibits the transmission of NOS, OLS, LR, or LRR on
  a Loop, regardless of whether or not they are preceded by ARB+OPN.

- I've also added ACA and UA conditions to the table, and simplified
  the footnotes and removed some notes which were redundant with 
  requirements from existing standards.

- FLOGI references were removed.

                                                              Clear   Abort
                                  LOGO,        PRLI, Target   Task    Task
                         LIP(y,x) PLOGI ABTS   PRLO  Reset    Set     Set 
                         -------- ----- ----- ------ ------- ------- -------
PLOGI parmameters          Y(4)     Y     N      N      N       N       N
Open Sequence(s)           Y(4)    Y(2)  Y(2)  Y(2)    N(3)    N(3)    N(3)
Open Task(s)              Y(4,5)  Y(2,5)  Y   Y(2,5)  Y(4,5)  Y(4,5)  Y(2,5)
EE_Credit_CNT               Y       Y     N      N      N       N       N
BB_Credit_CNT               Y       Y     N      N      N       N       N
AL_PA                      N(1)     N     N      N      N       N       N
PRLI parms                 Y(4)    Y(2)   N      Y      N       N       N
Mode page parms = saved    Y(4)    Y(2)   N    Y(2)    Y(4)     N       N
UA condition                N       N     N      N      N       N       N
ACA condition              Y(4)     N     N      N      ?       N       N

1.  Unless AL_PA's have changed (i.e., preferred address has already
    been taken by another port)
2.  For Process or N_Port Login Initiator only, not for all
3.  Tasks are cleared internally within the Target, but open FC-PH
    Sequences must be individually aborted by the SCSI Initiator via
4.  For all initiators
5.  All open tasks

Q: Do we need an -AL version number referenced in the Profile?  
A: FC-AL is already referenced in clause 3.  It will be updated to

Q: How is the loop master determined?
A: The Lowest algrebraic WWN determined by LISM wins mastership (see
   10.4.3 page 54 in FC-AL 4.34)

Q: Will drive respond to commands from 2 initiators on same loop?  
A: Yes, this is standard multiple-initiator behavior.  On a dual
   ported, multi-initiator implementation, if you send a command on one
   port, the Target must respond to that command on the same port.

Q: Is the new AMP-Champ connector with ESD blades and staggered pins
   being used?
A: Yes - will specify "blind mate" connector by referencing SFF once
   they agree on a specification.

Q: Are any input pins to the connector being established in order to
   communicate environmental conditions such as fan, temperature,
   and power?
A: These pins are being defined in SFF, but disk drives will NOT
   implement temp/fan/power conditions.  It is more likely that a
   cabinet will have a separate entity to perform this function rather
   than require the drive to do this.

Q: FLOGI prohibited on page 7 but explicit F_Port Login is allowed by
   initiators. Is this a typo?
A: Yes - will be fixed in next revision.

Q: If linking is not supported, how will we be able to handle Skip
   Read/Write?  How do we do skip mask?
A: Linking commands are optional in profile, but not prohibited.
   Therefore, the above functions may be implemented and still conform
   to the profile.

Q: Same with read long, write long, seek, write same.
A: See (7) above.

Q: Provide signals for future 5V gate and 12V gate.
A: These functions are already supported via the "Long" pins on the
   precharge lines in the SFF committee.  If EMC wants the resistor on
   the drive instead of the backplane, it should address the issue in
   SFF.  [Dan - bring this up again if not addressed to your

Q: Full Duplex code - can we write and read simultaneously to same drive?
A: Yes.  When an Initiator opens a drive, it may offer it BB_credit
   by transmitting R_RDYs. This gives the Target the ability to transmit
   data back to the host at the same time the host is transmitting to
   the Target. The amount of credit offered is implementation-specific.
   If the Initiator has no inbound buffers available, it will disallow
   full duplex behavior for that loop tenancy by not transmitting any

Horsts comments brought up several discussion items:

a) Login and Target Discovery:

   Instead of rejecting new PLOGIs as login resource limits are reached,
   - all PLOGIs must be accepted with the "oldest" PLOGI implicitly
     discarded, where the determination of "oldest" is vendor-unique
   - frames received from ports which are not logged in shall be discarded
     and PLOGO shall be issued to the offending port.

   A new "Port Discovery" ELS will allow open Exchanges to be preserved
   across insertion of new devices or power-cycling of existing devices
   (see proposal on FC Reflector and included below).  The Port Discovery
   algorithm will be mandatory in Private Loop Profile.  If Port Discovery
   shows no WWN or parameter changes following LIP, the Initiator shall not
   continue with PLOGI or PRLI (both of which would terminate open

b) Loop Initialization:

   For hub-type topologies where LIPs are not intrinsically generated on
   insertion, all NL_Ports must have some means of detecting power-on or
   insertion into the cable plant, and must generate their own LIP to alert
   others of a potential topology change.

c) Private vs public reset clarification:

   Only private devices may respond to power-on LIP reset.  If a device
   becomes public, it cannot respond to power-on LIP hard reset, and Target
   Reset must be used in order to protect Public Initiators (which may not
   be on the local loop) from other Initiators.  

   Private loop devices shall not attempt OPN to AL_PA to 00, or attempt
   FLOGI.  Public loop devices must attempt FLOGI to AL_PA=00, but may
   revert to private loop behavior if the OPN to AL_PA=00 or FLOGI fails.

d) Resource recovery scenario: 

   - LIP occurs. 
   - Target keeps its own address, Initiator changes it's address.  
   - Target does not have resource recovery timers.  
   - Initiator performs Port Discovery (PDISC) with Target
   - Target can detect by the WWN in the PDISC payload that it is the same
     Initiator (without looking at the S_ID).  Therefore the Target can
     reclaim the old resources associated with the old WWN, and abnormally
     terminate all Exchanges with that WWN, not the S_ID (regardless of
     whether or not the new Initiator attempts PLOGI with the Target).

e) OPNyr and OPNfr:

   Both Steve and Greg admitted they missed the change to OPNyr and OPNfr,
   Primitives, but agreed that they should remain as specified in 4.34
   since the implementations are already being changed to accomodate 4.34.

- Future meeting schedule
- Review these minutes and any associated comments
- Discuss why 3.3V disappeared and whether or not is should reappear
  (request by HP DMD).
- ACA:
   o handling of undelivered FCP_RSP to errored commands
   o Task Management and ACA
- Review general FC-EP, SAM, FCP changes needed to make Profile work
  (am compiling now - see future posting).

More information about the T10 mailing list