FCP-2 Error Recovery question

Dave Peterson dap at cisco.com
Sun Jun 23 11:05:15 PDT 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Dave Peterson" <dap at cisco.com>
*
This is a multi-part message in MIME format.

------=_NextPart_000_0061_01C21AB6.9DA87C30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Howdy Hugh,
 
Per FCP-2 clause 12.4.1.5 FCP_RSP IU Recovery:
For non-tagged command queuing operations, the target shall retain the
Exchange information until

a) the next FCP_CMND IU has been received for that LUN from the same
initiator;

b) an FCP_CONF IU is received for the Exchange; or

c) after RR_TOV times out.

For tagged command queuing operations, the target shall retain Exchange
information until

a) an FCP_CONF IU is received for the Exchange; or

b) after RR_TOV times out.

The Exchange information retained shall include data transfer
information, data descriptors, and FCP_RSP IU

information.

If retransmission is enabled between the initiator and target, FCP_RSP
IU information shall be:

a) discarded RR_TOV after the FCP_RSP IU was transmitted to the
initiator; or,

b) discarded after a new Exchange with the same OX_ID and S_ID is
received.

If retransmission is not enabled between the initiator and target,
FCP_RSP information may be discarded

immediately after the FCP_RSP IU has been transmitted to the initiator.

...dap

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Hugh
Curley
Sent: Saturday, June 22, 2002 1:19 PM
To: t10 at t10.org
Cc: T11_3 at mail.t11.org
Subject: FCP-2 Error Recovery question


I have been going over the ladder charts in annex C of FCP-2 rev 7a and
have a question on C17 and C19.  Both of these involve lost read data in
class 3: one the last frame of the data transfer sequence is lost, in
the other it is other that the last frame that is lost.
 
Normal operation would be for the initiator to open the exchange by
sending a single frame sequence containing the command to the target,
the target returning the requested data in a single or multiple frame
sequence and then the target sending the status/response in a single
frame sequence.  As far as the target is concerned, it has done all and
done it properly, so it will set the "last sequence of the exchange" and
"last frame of the sequence" bits in the F_CNTL on the status/response
frame.  From the target's standpoint the exchange is completed.
 
However, in these cases, C17 and C19, one of the data frames got lost in
the transport and never arrived at the Initiator (or arrived corrupted).
The target has no way of knowing this so goes on as above.  The
initiator discovers that a frame is missing, so after REC_TOV sends a
REC.  So far, all is OK.
 
But I believe that when the target gets the REC asking for status on the
exchange, the target will see there is not open exchange with that S_ID,
D_ID and OX_ID because the target has completed that exchange and closed
it.  The target should therefore return an LS_REJ.  The notes on pages
C17 and C19 state that the target will send an ACC with Exchange Open.
 
Why does the target see the exchange as Open?
What am I missing here?
 
I could see that the target would not close the exchange until receiving
a CONF, but the charts make no mention of that optional facitlity being
used.
 
Thank you for your help,
 
 
Hugh Curley
hcurley at indra.com  
 


------=_NextPart_000_0061_01C21AB6.9DA87C30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

 Howdy=20 Hugh,
  
 Per=20 FCP-2 clause 12.4.1.5 FCP_RSP IU=20 Recovery:
 For non-tagged command = queuing operations,=20 the target shall retain the Exchange information until a) the next FCP_CMND IU has = been received=20 for that LUN from the same initiator; b) an FCP_CONF IU is = received for the=20 Exchange; or c) after RR_TOV times = out. For tagged command queuing = operations, the=20 target shall retain Exchange information until a) an FCP_CONF IU is = received for the=20 Exchange; or b) after RR_TOV times = out. The Exchange information = retained shall=20 include data transfer information, data descriptors, and FCP_RSP = IU information. If retransmission is = enabled between the=20 initiator and target, FCP_RSP IU information shall be: a) discarded RR_TOV after = the FCP_RSP IU=20 was transmitted to the initiator; or, b) discarded after a new = Exchange with the=20 same OX_ID and S_ID is received. If retransmission is not = enabled between=20 the initiator and target, FCP_RSP information may be = discarded immediately after the = FCP_RSP IU has been=20 transmitted to the initiator. ...dap
 -----Original Message-----
From: owner-t10 at t10.org = [mailto:owner-t10 at t10.org]On Behalf Of Hugh = Curley
Sent:=20 Saturday, June 22, 2002 1:19 PM
To: = t10 at t10.org
Cc:=20 T11_3 at mail.t11.org
Subject: FCP-2 Error Recovery=20 question


 I have been going over the ladder = charts in annex=20 C of FCP-2 rev 7a and have a question on C17 and C19.  Both of = these=20 involve lost read data in class 3: one the last frame of the data = transfer=20 sequence is lost, in the other it is other that the last frame that = is=20 lost.
  
 Normal operation would be for the = initiator to=20 open the exchange by sending a single frame sequence containing the = command to=20 the target, the target returning the requested data in a single or = multiple=20 frame sequence and then the target sending the status/response in a = single=20 frame sequence.  As far as the target is concerned, it has done = all and=20 done it properly, so it will set the "last sequence of the exchange" = and "last=20 frame of the sequence" bits in the F_CNTL on the status/response = frame. =20 From the target's standpoint the exchange is completed.
  
 However, in these cases, C17 and = C19, one of the=20 data frames got lost in the transport and never arrived at the = Initiator (or=20 arrived corrupted).  The target has no way of knowing this so = goes on as=20 above.  The initiator discovers that a frame is missing, so = after REC_TOV=20 sends a REC.  So far, all is OK.
  
 But I believe that when the target = gets the REC=20 asking for status on the exchange, the target will see there is not = open=20 exchange with that S_ID, D_ID and OX_ID because the target has = completed that=20 exchange and closed it.  The target should therefore return an=20 LS_REJ.  The notes on pages C17 and C19 state that the target = will send=20 an ACC with Exchange Open.
  
 Why does the target see the exchange = as=20 Open?
 What am I missing here?
  
 I could see that the target would = not close the=20 exchange until receiving a CONF, but the charts make no mention of = that=20 optional facitlity being used.
  
 Thank you for your = help,
  
  
 Hugh Curley
 hcurley at indra.com
  


------=_NextPart_000_0061_01C21AB6.9DA87C30--




More information about the T10 mailing list