Minutes of FCP meeting, June 20, 1994

Bob Snively 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
be made.

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

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

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:
	    	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)

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

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)


	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