Minutes of FCP meeting, June 20, 1994
Bob.Snively at eng.sun.com
Tue Jul 5 19:14:22 PDT 1994
To: X3T10, X3T11 via e-mail
fibre-channel-ext at think.com, scsi at WichitaKS.NCR.COM
From: Bob Snively
Date: June 20, 1994
Subject: FCP Meeting Minutes
The meeting was convened at 5:15 p.m. June 20, 1994
at the Sofitel in Bloomington, MN. Bob Snively,
acting as chair person, indicated that the meeting
was an approved working subgroup meeting of X3T10.
The attendees introduced themselves.
The comment resolution document (X3T10/94-109, revision 1)
and the Fibre Channel Protocol for SCSI document
(X3T10/993D revision 8b) were distributed. The
meeting chose to address only those additional comments
not already discussed by the comment resolution document.
The technical items discussed were:
1) Support for dual port operation
The subject was discussed as part of ballot comment 150.
This capability must first be defined by SAM before it
can be properly defined in FCP. When properly defined,
there is enough space left in the task management
field to provide an indication that a "Reset Other Port"
is requested. The mechanism for identifying the other
port can be included in either the CDB or DL field, although
there is presently no architected method for determining
what ports may be present on a SCSI device.
There appeared to be consensus that forwarding of the
FCP for public review should not be delayed for this
question, but that it may be desirable to address it
in a future edition or a public review comment when some
of the uncertainties have been resolved.
2) Recovery Abort
The additional comment about error abort presented by
Seagate was discussed. The response was considered and
no change was made in the response at the meeting.
3) Target Reset causing logout
The additional comment from Seagate about the possible misunderstanding
of the functions provided by Target Reset was discussed.
The committee recommended that the suggested editorial change
4) Overlapped Command
The additional comment about overlapped commands presented by
Emulex was discussed. The committee agreed that, since
overlapped commands are prohibited by at least two layers
of the architecture, that checking for overlapped commands
should not be required. The committee recommended that
no change be made to FCP.
The additional comment from Seagate proposing the use of the terminate
and continue transfer of data functions was discussed. The
question was withdrawn, pending more study. Significant
modifications in the architecture of SAM and CAM would be
required to allow the function.
6) Interlock XFER_RDY on read operations
The possibility of using an initiator generated acceptance of
the XFER_RDY during read operations was discussed. This function
crosses architectural layers in a manner not presently defined
by SAM or allowed through CAM. There appeared to be consensus
that forwarding of the FCP for public review should not be
delayed for this function. If further study reveals that
such a function is desirable, it may be introduced as a public
7) Task management response
The possibility that a task management response might be useful
was considered by the committee. There appears to be consensus
that no change was required in FCP. A public review comment
would be the appropriate way to request such a change.
The meeting was adjourned. Related activities at other
meetings during the Fibre Channel Plenary week include
the following items:
In the Fibre Channel Plenary meeting of June 22, 1994,
the Fibre Channel committee recommended that the FC-SB
Annex defining the PRLI/PRLO functions be contained as
a normative annex of FCP, since FC-SB will not have been
forwarded in time to properly reference it, nor will the
definition be contained in FC-EP before the FCP is
Larry Lamers provided a marked up review copy of FCP Revision 8b
with numerous editorial recommendations designed to bring
the document into compliance with ISO and ANSI editorial
Bob Snively will provide a revision 9 of the FCP that includes
the changes recommended at the Fibre Channel Plenary meeting
and by the editorial review.
Bob Snively will contact the commenters to verify that their
comments have been correctly addressed by X3T10/94-109, the
comment resolution document.
Attendees of June 20, 1994 FCP meeting:
Jim Coomes Seagate jim_coomes at notes.seagate.com
Brian Doore Seagate Brian_Doore at notes.seagate.com
Bob Edge Tektronix robert.c.edge at tek.com
Norm Harris Adaptec nharris at adaptec.com
Gerald Houlder Seagate gerry_houlder at notes.seagate.com
Larry Lamers Adaptec ljlamers at aol.com
Srinivasa Malladi LSI Logic malladi at lsil.com
Venkat Mattela LSI Logic venkat at lsil.com
James Oliver Silicon Graphics oliver at sgi.com
Gary Porter Ancot garyp at ancot.com
Bob Snively Sun Microsystems bob.snively at sun.com
Jeff Stai WD I/O Products stai at dt.wdc.com
Arlan Stone Unisys arlan.stone at mv-oc.unisys.com
Lloyd Thorsbakken Unisys let2 at rsvl.unisys.com
Neil Wanamaker Amdahl ntw20 at eng.amdahl.com
Jeff Williams HP jlw at hpdnd48.boi.hp.com
----------------- Reference document for additional questions ------------
To: fibre-channel-ext at think.com, scsi at WichitaKS.NCR.COM
From: Bob Snively
Date: June 14, 1994
Subject: Proposed Responses to additional Fibre Channel Protocol questions
The following additional comments have been received concerning
the Fibre Channel Protocol for SCSI.
A) Use of Error Abort (Jim Coomes, Seagate, Jim_Coomes at notes.seagate.com)
We would like to eliminate requirements for target to send ABTS
to host after:
Clear Task Set
Abort Task Set
Here are the reasons:
For FCP logout, explicitly aborting every task from that host
is not needed since the host knows that it should not expect any
further interaction with this target.
For the other three, the current FCP requirement is contrary to SCSI.
SCSI and SAM require targets to simply discard the tasks, creating a
unit attention condition for each affected host (or all hosts, with
The requirement to use ABTS in these situations adds substantial
complexity to both the target and the host, so should be eliminated.
A clean layering of the architecture is desirable to
allow the transmission of TCP/IP, FCP, and other Fibre Channel
FC-4's through the same FC host adapter at the same time.
It is true that the Target Reset, Clear Task Set, and
Abort Task Set cause the SCSI logical tasks to be discarded.
However, these functions are interpreted by the Task Manager,
a SCSI layer, and not by the Fibre Channel port. The mechanism
that the FCP uses to clean up the Fibre Channel port resources
whose state is possibly unknown is the Recovery Abort function.
Without this function, the layering gets quite muddled and
it is likely that interactions between Fibre Channel
error recovery and SCSI task management functions could leave
the system in states that are not defined by the standards.
I would suggest we leave FCP Rev 8b unchanged.
B) Target Reset logout (Jim Coomes, Seagate, Jim_Coomes at notes.seagate.com)
Section 126.96.36.199, Target Reset: It should be stated explicitly that
Target Reset does not cause FCP logout of all initiators which are
logged in with it. Misunderstanding is possible with the current
I think that this is fairly obvious from the text. If the
consensus is that this should be stated explicity, I would
suggest the following wording be added to the first paragraph
about Target Reset:
"The FCP Login state of the affected image pairs
is not changed by the Target Reset"
C) Overlapped Command (Greg Scherer, Emulex, g_scherer at emulex.com)
I do have a minor issue with FCP regarding command TAGs. I know that
with FCP the command TAG is the OX_ID of the Exchange, and that this TAG is used according to the SAM rules.
The issue that I have is with the SAM definition of an overlapped command,
and what should be done in case one occurs. An overlapped command (as I understand it) occurs when an Initiator sends a new command TAG that is still in use between this Initiator-Target pair. The SAM behavior is for
the Target to ABORT ALL commands (queued or active) from the offending
My problem is that re-use of an OX_ID between a set of N_PORTs is an FC-2
detected error (not an FC-4 interpretation), and depending on the FC-2
hierarchy of checks there may be no way to notify the SCSI FC-4 that an "overlapped" command occurred. An example of this would be an FC-2 engine
seeing re-use of an OX_ID as an out-of-sequence frame, or illegal use of
F_CTL FIRST_SEQUENCE, or any number of other FC-2 errors. Without a more
exact indication of an "overlapped" command occurance, the Target can
not properly enforce the SAM behavior.
I believe that some Fibre Channel implementations would ABORT the Exchange
that re-used the OX_ID at the FC-2 layer. This would not satisfy the full
SAM behavior however.
I know that overlapped commands should not happen, but I thought I would
bring up the issue to see what others thought.....
The overlapping of tags was traditionally only a problem in
systems that allowed tag values to be passed from user programs
or partially tested applications. At present, both CAM and the
FC-2 service interface make the assumption that the tags are
generated by trusted state machines at a level unavailable to
user programs or drivers.
As a result, I agree with your final statement that overlapped
commands cannot happen. If they do happen, it really does
not matter which level of the architecture captures the error,
since it is a design failure that will be repaired before
the system is released to customers.
Revision 13 of SAM, section 4.6.2, allows us to indicate
in the SCSI protocol standard whether a logical unit is required
to check for overlapped commands.
I would propose that the following text be added to section 5.4.9
to indicate that overlapping tags need not be checked in FCP:
"Since the value of the OX_ID is required by FC-PH to be unique,
there is no requirement for an FCP logical unit to check for
D) TTD/CIOP (Brian Doore, Seagate, Brian_Doore at notes.seagate.com)
For implementation of our new Raid-assist functions, we have a need to
prevent a target from sending Read data until the host grants permission,
similar to what is currently done in regular SCSI with TTD/CIOP
messages. The Read XFER_RDY defined in FCP could be used for this
but does not currently work because there is no interlocking
acknowledgement from the host (class 3). Jim Coomes and I have
discussed the following mechanism for fixing this problem:
If Read XFER_RDY is used, the target will send only the Read XFER_RDY
(SI transferred) and no data. The target must wait for the host to
send a new Task Management function (CIOP, Continue I/O Process), sent
in an FCP_CMND frame in the same exchange as the original command.
(Suggest Byte 2, Bit 3 of FCP_CMND). The target may then send the
data. A target which has sent Read XFER_RDY to a host may send
Read XFER_RDY for other exchanges to the same or different hosts.
Use of Read XFER_RDY is controlled by FCP login parameters.
An alternate method would be to define a "TTD" task attribute
(must be a bit which can be OR'd with other task attributes)
so that a host could use Read XFER_RDY selectively, e.g. on
READ commands but not on INQUIRY.
If the latter method is used, the target must indicate its support
for TTD in the INQUIRY Data (TranDis bit).
This function has only been partially discussed at the SCSI
meetings and has not been accepted by the committee. It should
not be added to FCP. If approved, it could be added to an
FCP-2 at a future date.
More information about the T10