Proposed Responses to additional Fibre Channel Protocol questions
Bob Snively
Bob.Snively at eng.sun.com
Tue Jun 14 02:04:01 PDT 1994
To: fibre-channel-ext at think.com, scsi at WichitaKS.NCR.COM
From: Bob Snively
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)
Comment:
We would like to eliminate requirements for target to send ABTS
to host after:
FCP Logout
Target reset
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
Target Reset).
The requirement to use ABTS in these situations adds substantial
complexity to both the target and the host, so should be eliminated.
Proposed Response:
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)
Comment:
Section 7.1.2.2, 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
wording.
Proposed Response:
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)
Comment:
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
Initiator.
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.....
Proposed Response:
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
overlapping tags."
D) TTD/CIOP (Brian Doore, Seagate, Brian_Doore at notes.seagate.com)
Comment:
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).
Proposed Response:
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
mailing list