Proposed Responses to additional Fibre Channel Protocol questions

Bob Snively Bob.Snively at
Tue Jun 14 02:04:01 PDT 1994

To:		fibre-channel-ext at, 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

	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

	Section, 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

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


	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.....

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


	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