Proposed Responses to additional Fibre Channel Protocol questions

Kurt Chan kc at core.rose.hp.com
Wed Jun 15 13:52:10 PDT 1994


| A)	Use of Error Abort	(Jim Coomes, Seagate)
| 
| 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

The wording that I believe Jim is having problems with is:

  "Any open Exchanges that are in an ambiguous state shall be
   terminated by whicever port detects the ambiguous state
   using a Recovery Abort."

This does not necessarily require that Targets initiate ABTS.  I define
an "ambiguous" condition as one where an I/O may have different states
depending upon which end of the cable you're on. 

>From the INITIATOR's perspective, an I/O is in an ambiguous state if:
- In class 2, no acknowledgement is received for a CMD, or
- In class 3, no XFR_RDY or Read Data is received for a CMD.
- In any class, if all data has been transferred successfully and
  it is waiting for RSP from the Target.

>From the TARGET's perspective, if
- In class 2, if no acknowledgment is received for a RSP,
- In class 3, from the time until RSP is sent until a duplicate OX_ID
  is received from the same Initiator

For Targets, it is irrelevant whether or not the host has received the
RSP.  If it did not, it will retry the command with a new OX_ID.  The
Target need not attempt to determine whether or not the command is in
an ambiguous state, and therefore it need not take any explicit
action.  Instead, I believe Targets should rely on the implicit Host
knowledge of whether or not commands are outstanding, and require that
Hosts be responsible for error recovery actions when FCP Logout,
Target Reset, Clear Task Set, or Abort Task Set have been invoked
while commands are in indeterminate states.

I don't believe any changes to FCP are needed.


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

I know there is a temptation to solve this problem within smaller
groups, but I agree that this functionality (defining how a host can
dispatch multiple READ commands and then flow control the subsequent
incoming READ data) should be defined within SAM, rather than create
multiple link-specific solutions.

We can then figure out how to map this functionality into FCP.

Regards,

   Kurt Chan               Hewlett-Packard        System Interconnect Lab 
   kc at core.rose.hp.com     Voice: 916-785-5621    Fax: 916-785-2875       
   8000 Foothills Blvd     MS R5NF                Roseville, CA 95747     




More information about the T10 mailing list