FC-AL Ad Hoc Meeting Notes

Kurt Chan kc at core.rose.hp.com
Mon Feb 28 12:36:07 PST 1994


From:  Kurt Chan
To:    SCSI Reflector
       FC Reflector
Subj:  FC-AL Disk Ad Hoc Meeting Minutes 2/17/94
Date:  2/28/94 

Attendees:  

Adaptec		Fred Kool, Doug Fields, Larry Lamers
Amdahl		Neil Wanamaker
Ancor		Bob Cornelius
CDInt 		Jay Mork, Bob Pedersen, Ed Vegdahl
Conner 		Ken Smith
Cray 		Tim Johnson
Cypress		Ed Grivna, Yun-Che Wang, Greg Somer
DEC		Doug Hagerman
EMC		Brian Gallagher
Emulex		Charles Bazaar
ENDL		Dal Allan
FSI		Gary Stephens
HP		Kurt Chan, Steve Dean, Ed Frymoyer, Jeff Williams 
HP CNO		Kumar Malavalli, Bent Stoevhase
IBM		Pat Buckland, Bob Dugan, Giles Frazier, Bob Kembel 
		Ray Muggli, Horst Truested 
Interphase	Scottt Mindemann
LLNL		Paul Rupert, Lansing Sloan
LSI Logic	Srini Malladi
National Semi	Gary Rara
Seagate		Jim Coomes, Mike Miller 
Sun		Bob Snively
Systran		Gary Warden 
Tandem		Todd Sprenkle
TI		Richard Prentice
Unisys		Arlan Stone, Lloyd Thorsbakken
Vitro		Masuod Parvaresh

No, this wasn't an ANSI meeting.  Many of the attendees above were
lured into the HP meeting room by either the Breakfast Burritos
(generously supplied by IBM AWS) or because of afternoon flights with
nothng to do in the interim ;-).  

The next meeting will be on Monday afternoon (1pm-5pm), 3/14 at
Newport Beach, which may separate the intrepid from the mildly
curious, although luring people from the frozen tundras to Newport
Beach a day early may not pose as difficult a hurdle as anticipated.
I'll post an agenda soon (much of which will be based on the open
issues below).

If you want a copy of my original slides, send me your email address if you
can receive and print Postscript, or send me your fax number if you can't.
Warning - you will receive three 500kByte files if you request Postscript.

Below are comments made by attendees, documentation of open issues, and
some random observations by yours truly.

------

ERROR DETECTION

For slow error detection, Host ULP timers can perform all detection.
There was some concern expressed that the profile allow Targets to
signal detection of errors if they have the ability to do so.  For
faster error detection on class 3, the following E_D_TOV timers could
be allowed at both Target and Host (as Sequence Recipients):

- interframe reception timers
- intersequence reception timers 
- Sequence Initiative confirmation timers

If Targets detect these conditions, they could signal the host via ABTS.


IMPLICIT LOGIN

Implicit login parameters were discussed to prevent peripherals from having
to perform N_Port login.  This would help reduce the scenario where a Host
logs in with successive peripherals and is forced to log out and log back
in with previously logged-in peripherals as it attempts to negotiate to a
common set.

Explicit login would be allowed, if the device had a different set of
preferred operating parameters.  There was some question as to whether
2048 byte frames should be the default.  My opinion:  since Explicit
login is still allowed to negotiate *smaller* frames, the majority of
implementors should win over the minority viewpoint as the default
value. I will be taking straw polls in the future, but this is still
an open issue.


CONCURRENT SEQUENCES AND SYMMETRICAL XFR_RDY

In class 3 FCP, single-frame Sequences (SFS's) can be exempt from
SEQ_ID and SEQ_CNT processing since the Recipient does not have to
perform reassembly on the Sequence.  In fact, there is an open issue
as to whether or not SEQ_ID = FF should be used for all SFS's c3 FCP.
This means that SEQ_ID reuse is only an issue for Multi-Frame
Sequences (MFS's).

If Total concurrent Sequences is defined as the number of open or
active Sequences at any time across all Exchanges, then for the
purposes of reusing SEQ_ID, only the Data phases (Read and Write)
need to concern themselves with running out of SEQ_IDs:

At the Host as a class 3 Sequence Initiator, the proposed behavior is:

- A Write CMD Sequence is open until XFR_RDY is received or R_A_TOV
  expires, but the SEQ_ID may be reused immediately.

- A Read CMD Sequence is open until the first Read Data frame is
  received or R_A_TOV expires, but the SEQ_ID may be reused
  immediately.

- If a Write Data is an SFS, it's SEQ_ID may be reused immediately.
  Otherwise it is open until XFR_RDY is received for the next data
  Sequence or until FCP_RSP is received or until R_A_TOV expires.

At the Target as a class 3 Sequence Initiator a Read Data Sequence or 
FCP_RSP Sequence is open until: 

- it receives an Exchange from the same Host using the same OX_ID.

- R_A_TOV expires after having send FCP_RSP

Here is a problem - a device can only have 256 open Sequences across
all Exchanges.  In the Write direction, Data Sequences can be closed
down in a timely fashion using the XFR_RDY interlock.  In the Read
direction, however, a Read Data Sequence remains open for quite some
time and 256 open MFS's per N_Port pair is not a realistic
restriction.  

Therefore, in order to be able to reuse Sequence Qualifiers in class 3
for frames in an MFS there is an open issue of making XFR_RDY
symmetrical in FCP (can come from the host as well as the Target -
perhaps XO_XFR_RDY and XR_XFR_RDY for Exchange Originator and Exchange
Responder XFR_RDY).


FABRIC SUPPORT

Another issue that came up after the meeting is whether or not fabric
support should be addressed by this profile.  There was some concern
that class 3 is not suitable for moving data across fabrics.  The one
valid reason I heard had to do with timely detection of CRC errors.
These errors are expected to happen periodically, and ULP timers can
be large enough so that CRC errors could impact performance.  There is
an open issue of discussing whether or not the suggestions in the
Error Detection section above alleviate the problem by creating
optional EDTOV timers at various points in the protocol.  I also have
some comments from some fabric vendors that I can address at the next
meeting if we decide this is important.


RX_ID ASSIGNMENT

There was some discussion over whether RX_ID assignment is useful.
Some (but not all) implementors are using RX_ID as a short handle into
their inbound Target DMA HW.  On Writes, this RX_ID assignment is not
interlocked on an ACK, but rather assigned on a XFR_RDY (Write) or
Data Frame (Read).  Since there currently is no inbound Target DMA on
Reads, the open issue seems to boil down to how useful RX_ID interlock
is on Write XFR_RDY.  In error recovery, BA_RJT to ABTS would be
disallowed if RX_ID is not assigned.


LINK SERVICES

In addition to the prohibitions specified in the existing class 1/2
FCP profile, the class 3 profile prohibits:

- ABTS from the Target 
- NOP
- RMC
- RRQ
- RSI
- RTV (to Target)

I'm rethinking the ABTS for the reasons described above in Error
Detection.  I think it should be made optional, if a Target has
implemented the E_D_TOV timer on XR_XFR_RDY for fast error detection.
In that case, there is an open issue as to whether or not RTV needed
to the Target or if EDTOV assignment can be a "write-only" function
via N_Port login.

ECHO was deemed useful and will be removed from the prohibited list.


LOOP DISCONNECT

Several rules for CLS were discussed.  One rule stated that devices
(both Hosts and Targets) are required to close the loop immediately
after sending data rather than holding the loop open until an ARB is
observed.  It was noted that Hosts should be allowed to go to TRANSFER
state to open another device on the loop without going through another
CLS-ARB cycle.

Another rule was that Sequence Recipients should not open a Sequence
Initiator for the purposes of receiving data. It was noted that
this is true for Targets, but Hosts should be allowed to open a Target
to receive data, based on the analogy to the Prevent Discconnect function
in parallel SCSI. This is an open issue.


FAIRNESS

It was proposed that Targets must implement FC-AL fairness, whereas
Hosts were not required to.  There was a comment that ALL devices
SHOULD be fair as the default behavior, but ANY device should be
allowed to be UNfair, not just Hosts (for example, to keep a tape
streaming). Even though the dislaimers stated this is a disk-only
profile, I'll leave this as an open issue for now.


SCSI COMMANDS

It was proposed that Hosts could be prohibited from invoking Log
Sense/Select.  There was one comment that objected to the command sets
being different for the class 1/2 vs class 3 profile.  A
counterargument was that these commands are poorly standardized upon,
and therefore vendors all implement them differently.  This is an open
issue. (If we feel these are essential, then I would expect FCSI to
suggest one standard way of doing Log Sense/Select rather than leave
it open-ended).


OTHER

There are a few other open issues which will be brought up next month.
Let me know if you have anything specific.

Kurt.




More information about the T10 mailing list