Proposal to handle unconfirmed FCP_RSP: X3T10/95-203r0

Binford, Charles cbinford at ppdpost.ks.symbios.com
Tue May 2 14:59:00 PDT 1995


     To: Fibre Channel
         SCSI
   From: Charles.Binford at Symbios.com
Subject: Proposal to handle unconfirmed FCP_RSP: X3T10/95-203r0


John Lohmeyer will be adding the above subject to the May SCSI Working group 
meeting.  Below is the text of the proposal.  I will be putting a Word 6 
(.doc) version complete with a couple of diagrams on ftp.symbios.com in the 
next couple of days.



Background:
The fact that the delivery of the FCP_RSP packet is unconfirmed in the class 
3 AL environment has been discussed over the past few months in committees 
and on the SCSI and Disk Attach reflectors.  (Some also argue that even 
under class 2, the successful delivery of FCP_RSP cannot be known.  This 
argument hinges on whether or not the ACK implies delivery to the ULP.)  A 
major consideration in the discussion on the potential loss of the FCP_RSP 
IU (and thus any SCSI Sense data since FCP uses autosense) is whether or not 
a host actually cares.  If the FCP_RSP IU is lost, the typical host will 
time-out the IO and reissue it.  For block devices doing reads and writes 
this may be a sufficient error recovery scheme.  The issue gets interesting, 
however, when the FCP_RSP IU which is lost contains autosense data WHICH IS 
NOT ASSOCIATED WITH THE COMMAND.  This can occur when the target is 
attempting to report a Unit Attention or a deferred error.

The intent of this document is not to further the debate concerning the 
FCP_RSP IU, but rather to propose a solution.  To that end the following 
describes an optional interlock mechanism which may be used by a target to 
ensure delivery of SCSI Sense data.   The additional interlock may be 
invoked by the target on a per IO basis so as to not impede performance (it 
is assumed targets would not ask for confirmation for GOOD status).  One 
problem encountered when adding a "handshake" is when to stop: what if the 
host+s FCP_RSP_ acknowledgment IU gets lost?  This proposal addresses that 
and other potential error scenarios.

     1. Two New IUs
     - FCP_RSP_REQ_CONFIRM
     - FCP_RSP_CONFIRM

     1.1 IU Definition

     1.1.1 FCP_RSP_REQ_CONFIRM
     (target to init) An FCP_RSP_REQ_CONFIRM IU is a normal FCP_RSP IU
     with the following F_CTL bit changes:
     - set Transfer Sequence Initiative
     - do not set Last Sequence

     1.2.2 FCP_RSP_CONFIRM
     (init to target) An FCP_RSP_CONFIRM IU is defined as follows:
     - R_CTL bits 31-28: 0000 FC-4 Device_Data
     - R_CTL bits 27-24: 0011 Solicited Control
     - Type code: 0000 1000 SCSI-FCP
     - Payload: 4 bytes, value TBD

     2. Interoperability
     - Use determined by PRLI parameter.
     - Only invoked by target if initiator supports.
     - May be invoked by target on a per IO basis (e.g. only when NOT
       good status)

     3. Usage Rules

     3.1 Target use of FCP_RSP_REQ_CONFIRM
     If the target wishes to request confirmation from the initiator of
     an FCP_RSP it shall send the FCP_RSP_REQ_CONFIRM IU instead of the
     normal FCP_RSP.

     3.2 Initiator use of FCP_RSP_CONFIRM
     When an initiator detects FCP_RSP_REQ_CONFIRM IU it shall send an
     FCP_RSP_CONFIRM IU.

     3.3 Target cleanup of exchange and data
     A target which sends an FCP_RSP_REQ_CONFIRM IU shall maintain any
     associated sense data to allow for a vendor unique number of
     retries until any of the following:
     - an FCP_RSP_CONFIRM IU is received with a payload of (TBD) and
       FQXID
     - an FCP_CMD is received with an OX_ID and S_ID matching that of
       the yet to be confirmed FCP_RSP_REQ_CONFIRM IU.  (Note: this is
       the case where the FCP_RSP_CONFIRM was lost.)

     3.4 Target Error Detection and Recovery

     3.4.1 Target detection of lost FCP_RSP_REQ_CONFIRM IU
     A target shall assume the FCP_RSP_REQ_CONFIRM IU was not received
     by the initiator if the FCP_RSP_CONFIRM IU is not received within a
     target specific time-out.
     - the time-out shall be > R_A_TOV

     3.4.2 Target retry of FCP_RSP_REQ_CONFIRM IU
     The  target may retry the FCP_RSP_REQ_CONFIRM  IU using the
     following rules:
     - maintain the original FCP_SNS_INFO and FCP_STATUS
     - set the RSP_CODE to FCP_RSP_RETRY (value TBD)

     3.4.3 Initiator receipt of a retried FCP_RSP_REQ_CONFIRM IU
     If an initiator receives an FCP_RSP_REQ_CONFIRM  IU with an
     RSP_CODE set to FCP_RSP_RETRY it shall take one of the following
     actions:
     - if the OX_ID is not currently active, send confirmation (previous
       confirmation was lost)
     - if the FCP_CMD which is active on this OX_ID was sent at time t
       and (current_time - t) >= R_A_TOV, then treat as normal
       FCP_RSP_REQ_CONFIRM  and send confirmation (previous
       FCP_RSP_REQ_CONFIRM  was lost)
     - if the FCP_CMD which is active on this OX_ID was sent at time t
       and (current_time - t) < R_A_TOV, then ignore (previous
       confirmation was lost and target attempted retry at the same time
       initiator reused OX_ID.  The target will see the new FCP_CMD with
       the given OX_ID and cleanup the previous IO.)





More information about the T10 mailing list