FC Direct Attach Disk Ad Hoc Minutes, 7/12/94
kc at core.rose.hp.com
Mon Jul 18 14:56:07 PDT 1994
From: Kurt Chan
To: FC, SCSI Reflectors
Subj: July FC Direct Disk Attach Ad Hoc Meeting Minutes
FC-AL Direct Disk Attach Ad Hoc Meeting Minutes
Red Lion Stapleton
Dal Allan, ENDL 250-1752 at mcimail.com
Kurt Chan, HP kc at core.rose.hp.com
Jim Coomes, Seagate jim_coomes at notes.seagate.com
Jim Fechner, Stortek jfechner at stortek.com
Giles Frazier, IBM gfrazier at ausvm6.vnet.ibm.com
Stillman Gates, Adaptec stillman at eng.adaptec.com
Norm Harris, Adaptec nharris at eng.adaptec.com
Gary Glass, Stortek gary_glass at stortek.com
Jean Kodama, QLogic j_kodama at qlc.com
Fred Kool, Adaptec fredkool at eng.adaptec.com
Greg Scherer, Emulex g_scherer at emulex.com
Ken Smith, Conner ken.smith at conner.com
Dan Weinstein, EMC danw at emc.com
I solicited feedback on how this Profile should be maintained. Since
several attendees did not belong to FCA or FCSI, the general concensus
was to keep the document a public one. One method of getting Global
Engineering distribution is if an ANSI group (e.g., X3T11) votes to
declare this as a "working document", in which case updates can be
included in Global's multimedia package. The next revision will be
0.30 which will capture the results of the July WG and will be
available in early August via anonymous ftp to ncrinfo.ncr.com
(pub/standards/fc/profiles directory) or within HP to
hprnlne.rose.hp.com (pub/FC/AL directory).
While this point was not discussed, some clarification of the differences
between open vs local loop behavior should be added:
+---------+ +------------+ +-----------+
| FL_Port |---->| Local Loop |---->| Open Loop |--->.
+----+----+ | Device | | Device | |
| +------------+ +-----------+ |
| +------------+ +-----------+ |
+-----<----| Local Loop |<----| Open Loop |<---'
| Device | | Device |
The proposed definition of a "Local Loop NL_Port":
A Local Loop NL_Port may not communicate with or through an FL_Port. This
does not preclude the existence of an FL_Port on a Loop containing Local Loop
An Open Loop NL_Port may communicate with other ports on its local loop, or to
other N_Ports or NL_Ports across an FL_Port. This permits Open Loop NL_Ports
to communicate with one another using the Open Loop profile across a Fabric,
while at the same time communicating with Local Loop devices using the Local
Ports which are compliant to both Open and Local Loop profiles may use either
profile when communicating on Local loops. This allows Local and Open Loop
devices to coexist on the same loop (even if that loop contains an FL_Port).
An example of a useful configuration would be an IP-based class 2 Open Loop
device which can also communicate with Local Loop class 3 SCSI devices.
I am therefore suggesting that the term "Local Loop Profile" be used in place
of "Closed Loop Profile" to accomodate the above concepts.
It was clarified that Hosts must be able to originate LOGI to Targets for the
purpose of discovery, but that Targets are not required to originate LOGI
requests. If a Target receives a command (or any frame) for which it has no
record of Login from the Initiator, it must issue LOGO. The Initiator may or
may not be able to associate this LOGO with the command that caused it. If it
cannot, it should simply discard the LOGO frame and the net effect is
identical: a ULP timeout on the command.
Fabric Login is allowed by Initiators (to avoid topology-specific
initialization), and is Prohibited for Targets which are designed specifically
for local loop operation (see above definition of "local loop"). I changed
this from "N/A" back to "P" to allow the existence of FL_Ports but not their
use by local loop devices.
4. Version Number
We discussed using an unused ANSI code point (e.g., "4.9"). However, after
investigating further document 93-246 ("Interoperability Requirements for
Vendor Unique Deviations to FC-PH 4.2") from IBM, I propose we use the
Common Service Parms:
- FC-PH version = 09 (4.3)
- Valid Vendor Version Level = 1
Vendor Version level (16 bytes):
- Vendor code (2 bytes) = TBD ("LLNL" is used in 93-246)
- Vendor specific version (6 bytes) contains a bit map of which Deltas
- last 8 bytes are reserved
An annex to the profile would serve the same function as 93-246
(documenting the FC-PH 4.3 Deltas required to interoperate with this
My primary reason for preferring this method is that I do not feel
comfortable attempting to obtain an ANSI-approved code point for
vendor-unique deviations. Indeed, this is why I suggested the VU
version field in the login parameters. This way,
- only real ANSI-approved versions are placed in the FC-PH version
- we remain consistent with IBM VU designations
The format and content of this annex can be discussed at the Aug 9 ad
5. Node/N_Port Name Formats
The profile will be changed to allow the Host to use either IEEE or
IEEE Extended formats for both Node and N_Port names. Targets are
still required to use IEEE Extended, with ports on a dual-port
implemention using the same lower 48 bits.
6. P_RJT disallowed
Unlike class 2 which can issue P_RJT if Exchange Resources are
unavailable, class 3 Sequence Recipients are prohibited from using
P_RJT. It is expected that Hosts as Sequence Recipients can avoid
this situation. Targets as Sequence Recipients must either discard
new commands if they are unable to buffer them, or issue "Task Set
Full" status upon receipt of a command for which it has no ULP
7. Target-Initiated ABTS
Resolution: Only a SCSI Initiator may abort Exchanges (via ABTS-LS),
but a receiving N_Port may detect errors and issue ABTS per FC-PH.
This allows both simple Targets that will never initiate ABTS as well
as more sophisticated Targets (or Hosts acting as Targets) to employ
generic FC-PH link-level error detection/recovery which may be common
to multiple ULPs.
Therefore it was agreed upon that the requirement for Target-Initiated
ABTS was unecessary in FCP, and that a public review comment to
suggest the relaxation of that requirement would be supported by the
group. For Target Reset and Clear Task Set functions, hosts with
outstanding commands to a multiple-initiatore Target should respond to
Unit Attention Conditions by aborting those commands via ABTS-LS. If
the Target has already cleared a command for which it receives an
ABTS, it treats it identically to the following scenario:
- A CMD was issued by a host bu lost due to CRC error.
- Host times out waiting for FCP Data (Read) or XFR_RDY (Write).
- Host issues ABTS for CMD never received by Target.
- Target issues BA_ACC with L_S=1. (Target is only allowed
to BA_RJT if it has already assigned an RX_ID and an invalid
OX_ID/RX_ID combination is detected).
8. SCSI Commands
In order for drive vendors to accomodate a variety of markets, it was
suggested that the Mandatory commands be specified in terms of Target
requirements, rather than what commands were allowed or prohibited to
be invoked by the Host. The list of Target-required commands was also
shrunk, since all commands previously Prohibited at the Host are now
simply not specified - it is completely optional at the Target whether
or not these unspecified commands are implemented. These
implementations are interoperable since CHECK CONDITION is returned
for unsupported commands (Note - is there a standard method of
communicating when a command is unsupported versus when an illegal
or invalid CDB has been received?).
The following commands are now mandatory at the Target. All commands
not specified are optional both in SCSI-2 and in the Profile.
Mandatory Profile Mandatory
FORMAT UNIT Y Y (only F/C/DLF = 0/0/000)
INQUIRY Y Y (only EVPD Serial# Page, Std Page)
MODE SENSE/SELECT(10) N Y
READ(6) Y N
READ(10) Y Y
READ DEFECT DATA N Y
RELEASE Y Y (only Unit, not Extent)
REQUEST SENSE Y Y (
RESERVE Y Y (only Unit, not Extent)
SEND DIAGNOSTIC Y Y (only selftest)
READ CAPACITY Y N
START/STOP UNIT N Y
TEST UNIT READY Y Y
WRITE(10) N Y
WRITE BUFFER N Y (download microcode, download/save)
9. MODE SENSE/SELECT Parameters
The same logic was applied to the Mode Sense/Select parameters - only
those required at the Target are specified. All others are optional.
- Number of Block Descriptors = 1. Length = multiple of 2 bytes. (Changed
from 4 bytes).
- Device Specific Parameter: support of WP bit required
- Control mode page: EECA Bit = 0 required
- Disconnect/Reconnect page: Buffer Full/Empty Ratio required
Max burst size (= Sequence length) required
10. SCSI Status
Only GOOD, CHECK CONDITION, BUSY, RESERVATION CONFLICT, TASK SET FULL, and
ACA ACTIVE are required. All others are optional.
11. Arbitrated Loop Features
a) Both Hosts and Targets are Required to Open full duplex.
b) Both Hosts and Targets are Prohibited from opening half duplex, since
opening full duplex with (d) and (e) below is equivalent, and
for future Fabric operation full duplex must be accomodated.
c) NL_Ports do not open another port for the purpose of receiving data
(analogous to class 1 unidirectional behavior).
d) Logging in with the alternate BB_credit management is Required.
e) Logging in with BB_Credit = 0 is Required.
f) SYNC, PBE/PBD, and Replicate functions are not required.
g) Unfairness is allowed by both Targets and Hosts. It was noted that
some ports may go unfair in class 2 to unload ACKs (not an issue for
h) A SCSI Initiator may go unfair or use Transfer mode in order to
dispatch commands without having to wait for "bulk data transfers"
pending on the loop.
i) If an OPEN'ed port cannot grant BB_Credit immediately, it should issue
CLS rather than wait indeterminately for buffers to become available.
12. Out of Order FCP Relative Offset (RO)
FCP RO is NOT the same as FC-PH RO (word 1, bit 30 from the N_Port
Common Service Parameters).
In order to accomodate "Split Write" behavior, the profile allows
Write commands to be split into multi-Sequence transfers, with each
Sequence having no ordered relationship to the previous Sequence. The
XFR_RDY payload specifies the Initial Relative Offset to be
transmitted in the frame header of the first frame of each Sequence.
The Initial Relative Offsets of each Write Data Sequence are not
required to be in order.
Similarly, even though XFR_RDY is not used on Reads, the Target may
return multiple Read Data Sequences in any order (with the Initial RO
of each Sequence reflecting the relative position of the Sequence with
respect to the overall Read Data Transfer).
For both Reads and Writes, FRAMES within each Sequence must always
have continuously increasing Relative Offset values in the frame
header per the FC-2 Feature Set - the Random clause only pertains to
the Initial Relative offset in each Sequence.
Therefore, FCP_XFR_RDY out of order RO will be changed to Allowed.
13. Loop Initialization
Due to a lack of time, Loop Initialization was not discussed. The
redlined text will be on next months agenda:
- Failure to obtain hard-assigned address
- Failure to acquire Loop
- Loop Failures
14. Connectors and cables
- References to SFF-8017 will be added (fax info available from
- HP distributed a handout on external cable/connector candidates and
the criteria that will be used to evaluate them.
- Improved eye diagrams and connector drawings will be included in
next month's version 0.30.
15. Open Loop Issues
The last 30 minutes was spent creating a list of issues for
consideration in the Open Loop profile (Fabric attach).
o Class of Service (class 2, class 1+2, etc).
o ACK model (ACK_1, ACK_0, ACK_1 Host/ACK_0 Target, etc)
o NACK model (P_RJT, F_RJT, P_BSY, F_BSY)
o ACK transmission algorithms over Loop
o Target discovery/registration
o FL_Port functionality (out-of-order delivery, login parameters,
2 vs 6 idles between frames, etc).
o FCP functions
o Congestion/out-of-order/BSY behavior
o FL_Port alternatives
16. Future meeting schedule
All meetings at Red Lion Stapleton, 830-530 on Tuesdays:
- Aug 9
- Sep 6
- Oct 4
- Nov 1 (if needed)
More information about the T10