FC-AL Ad Hoc Meeting Notes
kc at core.rose.hp.com
Mon Feb 28 12:36:07 PST 1994
From: Kurt Chan
To: SCSI Reflector
Subj: FC-AL Disk Ad Hoc Meeting Minutes 2/17/94
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
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.
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 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
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
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
- 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
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
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.
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.
In addition to the prohibitions specified in the existing class 1/2
FCP profile, the class 3 profile prohibits:
- ABTS from the Target
- 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.
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
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.
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.
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
There are a few other open issues which will be brought up next month.
Let me know if you have anything specific.
More information about the T10