Nov '94 Direct Attach Disk Adhoc minutes

[Kurt Chan]

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

           FC-AL Direct Attach Disk Ad Hoc Meeting Minutes
                           11/1/94
                      Red Lion Stapleton
                         Denver, CO

There were 13 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
  Dave Ford, Cambex                dford at cambex.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
  Jean Kodama, QLogic              j_kodama at qlc.com
  Bob Snively, Sun Micro           bob.snively at sun.com
  Horst Truestedt, IBM             truested at vnet.ibm.com
  Fanny Wong, IBM                  fwong at vnet.ibm.com


1. SERIAL SHOOT-OUT

Bob Snively brought up the subject of using two backplane pins for
serial-in/serial-out shift registers.  These registers would be used
to turn on and off LEDs, sense environmental conditions, etc.  Dal and
Bob disagreed on how to use the bits (whether drive SUPPLIES or merely
RECEIVES information).  Dal wanted to be able to insert a card in
place of a drive which gathers information on behalf of some
management entity, whether it's SCSI-based (e.g., SEND/RECEIVE
DIAGNOSTIC) or IP (e.g., SNMP).  Dave Ford mentioned that some systems
have a separate SCSI Device on the bus which gathers this information.

RS-232 with 7 SEL lines can address any drive in a cabinet without the
need for encoding addresses serially.  Dal wanted to move intelligence
requirements away from drive.  It was expected that the SFF group in
Palm Springs would address some of these issues.  Another scheme could
have a controlling entity performing the data acquisition/control over
point-point links to each drive (similar to a Port Bypass manager).


2. MULTIPLE PORT INITIALIZATION

With the absence of a multi-port model in SAM, a gap remains in defining
the behavior of a multi-ported Target for interoperability.

   +----------------+  LOOP 1    LOOP 2  +-----------------+
   | Initiator 1  Tx|<-----.      .----->|Rx  Initiator 3  | 
   |              Rx|->-.  |      |  .-<-|Tx               |
   +----------------+   |  |      |  |   +-----------------+
   +----------------+   |  |      |  |   +-----------------+
   | Initiator 2  Rx|<--'  |      |  `->-|Rx  Initiator 4  |
   |              Tx|->-.  |      |  .-<-|Tx               |
   +----------------+   |  |      |  |   +-----------------+
                   +----+--+------+--+---+
                   |   Port 1    Port 2  |
                   |        TARGET       |
                   +---------------------+

Consider the above system (4 hosts sharing a dual-ported drives on two
separate loops).  A function is needed to reset all tasks PER PORT
without disturbing the other tasks on the second port (e.g., a second
Initiator acting on behalf of a failed Initiator).  This involves a
new:

- PRIORITY RESERVE command (which breaks all other reservations)
- ABORT TASK SET OTHER INITIATOR Task Management Function

In FC, the "Other Initiator" would be identified via its WWN.  Other
interfaces may have link-specific methods of identifying ports.  This
would also address a system which had more than 2 initiators per port,
and more than two ports per Target.

The next question is, how does an Initiator discover who the "Other
Initiator" is?  One possible solution is that, when RESERVATION
CONFLICT is returned, the Target can put the WWN of the Reserving
Initiator in the payload.  Another answer that doesn't necessarily
promote interoperability is that discovery of the WWN which owns a
Reservation is vendor-unique, and should not require Target resources.
No resolution was arrived at, but Bob Snively will draft a proposal.


3. LINKED COMMANDS

Horst questioned why linked commands were prohibited, since he felt
there were applications which could benefit from them.  SKIP
READ/WRITE requires linked commands (even though it is has been
removed from SCSI and is a VU command).  The primary reasons linked
commands are prohibited in both the FCSI and adhoc profiles are:

- Initial implementors don't support them, and

- Added text is required to describe their behavior if they are
  Allowed.  Since the authors of such text are also usually the early
  implementors, there is little motivation for them to document a
  feature which is not implemented.

Dave Ford mentioned that typically, database management applications
won't entrust locking to Linked Commands, even though reserving an
entire drive via peer-peer semaphore passing (or RESERVE/RELEASE) is
inefficient.

A possible compromise would be:

- to keep Linked Commands Prohibited in the baseline Profile

- allow in future profiles via a Discovery mechanism (PRLI?)

- if an Initiator discovers that a Target supports Linked Commands, it
  may use them.  If a Target does not, the Initiator must fall back
  to the baseline Profile for interoperability

- It remains up to Horst (or some other volunteer) to write up how:
  o linked Command capability is discovered (and propose a new method
    if none is available)
  o linked commands are transmitted and completion reported
  o error recovery works for linked commands 

A clause will be added to clarify what Prohibited means for the
various tables, since this was a stumbling point.


4. ACA

After some lengthy discussion as to the merits of ACA, two ideas were
proposed:

1. Add IUs to make the delivery of FCP autosense reliable, or
2. Add ACA with some simplifications

Item 1 was viewed as not possible given that the Profile does not
perform Sequence Recovery or retransmission.  Adding an IU which
acknowledges FCP_RSP would still not guarantee that sense information
was delivered reliably to the Initiator, since the unit of recovery in
the profile is an Exchange, not a Sequence.  Futhermore, an Initiator
may not be able to determine if it's acknowledgement to an FCP_RSP was
successful in class 3 to know whether or not to reuse an OX_ID,
resulting in the requirement of a THREE-way handshake, which is
undesireable.

Item 2 looked the most promising, if we prohibit the Initiator from
attempting media access commands.  Targets would be required to return
BUSY status to the faulted Initiator if it sends any media access
commands with the ACA attribute set (other Initiators receive ACA
ACTIVE status as usual, which is how you determine whether or not an
ACA condition is for you versus some other Initiator).  This added
restriction does not appear to violate any existing ANSI standards,
yet greatly simplifies ACA support in both Targets and Initiators.

Note that the other added requirement is that the only actions that
can clear an ACA condition are:

1) CLEAR ACA Task Management fucntion 
2) TARGET RESET Task Management function
3) LIP hard reset
4) Powerfail of the Target

An error in ver 1.00 of the profile was corrected (Request Sense with
ACA attribute set does NOT clear an ACA condition).


5. MEETING SCHEDULE

Next meeting is Dec 5 in San Jose at the Red Lion (concurrent with
ANSI week).  We'll be in the Board Room from 830-5p, although I expect
to be able to adjourn early.  The only preplanned agenda items will
be:

o Review Vince Cavanna's test results for the Hirosi vs Coax
  connectoring and discuss external physical layer issues in general

o Review ver 1.10 of the Profile. In particular,
  - ACA
  - Annex A (proposed FC-PH/FCP changes)
  - Initialization

o Future meeting schedule (esp re: January in Lake Tahoe)

I'll announce when version 1.10 is available on-line (11/18 target).