FCP-2 recovery problem

[Zeitler, Carl]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Zeitler, Carl" <Carl.Zeitler at compaq.com>
*
Dave, I believe there is one statement with regard to Class 2 that is
incorrect.  Class 2 does not have this ambiguity problem.  The ACK and RX_ID
take care of the situation.  The basic problem you are solving is Class 3
only--there is no idea when an Exchange is complete.  In Class 2 you always
know when the Exchange is complete, either via ACK or the ABTS mechanism
when the ACK is not received. The RX_ID resolves the  ambiguity problem if
the Initiator reuses the OX_ID in a new command that is lost(RX_ID=ffff)
versus the assigned RX_ID carried in the ABTS from the Target, looking for
its lost ACK.  The ABTS gets a reject since the context is gone (no matching
RX_ID). This Exchange in the Target must be logically resolved first for the
out-of-order case and the new command is issued before the ABTS is received,
i.e., within ED_TOV.  Then the new command which establishes a new Exchange
in the Target can be accepted (ACKed) or the  ABTS is issued to ascertain
status on this command, if lost, causes a new Exchange with the this same
OX_ID to be established and then cleaned up with RRQ.

So this mechanism is only necessary for Class 3 when you are doing Sequence
level recovery for a single FC-4, FCP.  That's why I have a problem putting
a handle in the Parameter field in the frame header. 

Let me postulate another possible solution.

Use the CRN on a LUN basis, each previously mentioned in previous E-Mails,
but not combined.  REC and SRR payloads would be expanded to include the LUN
and CRN.

The rules would be as follows:

1.  All Sequence level recovery would use CRN.  Yes, we'll put it in Class 2
also so they are both the same.   

2.  No more than 255 Exchanges could be outstanding against any single LUN
to avoid the aliasing problem we are trying to solve in the first place. A
CRN of 0 can never be used for normal purposes, and only for recovery
purposes. I believe this is already defined.

3.  The Initiator would maintain the LUN and CRN as part of the  context for
all outstanding Exchanges.  Once FCP_RESP is accepted by the Initiator, the
Exchange is complete from the Initiator's point of view and the Exchange
context is purged.

4.  The Target would likewise maintain the LUN and CRN as part of the
context for all outstanding Exchanges.  The Target would also maintain the
Exchange context plus LUN and CRN of ONLY the last completed Exchange for
R_R_TOV at a minimum, on a per LUN basis.  This resolves the ambiguity
problem for REC/SRR.

 In addition, reuse of an OX_ID on a TARGET BASIS implicitly implies that
the previous Exchange is complete and the context of the completed Exchange
with the same OX_ID, IRRESPECTIVE of LUN and CNR, must be purged. Otherwise
we create an ambiguity problem for ABTS.  Note that the same OX_ID can be
outstanding on multiple Targets, since each Target is identified by a unique
D_ID.

5.  The payload of REC/SRR are expanded to include CNR and LUN. These
commands would use the additional fields to resolve the ambiguity.

6.  A CRN of 0 would allow current implementations to run as is. LUN would
always  be required or else we would need a validity bit.

The big question is whether the use of CRN/LUN for Sequence level recovery
is acceptable.  If it isn't then we need to architect an FCP-2 specific
construct that solves this problem and put it in an FCP-2 Device Header, a
la FC-VI. Mixing FC-4 level stuff with FC-2 level stuff should be an
axiomatic no-no, and will bite us down the line if we allow it.








-----Original Message-----
From: Baldwin, Dave [mailto:Dave.Baldwin at emulex.com]
Sent: Friday, June 30, 2000 7:26 PM
To: Fibre Reflector; T10 Reflector
Subject: FCP-2 recovery problem


I have updated my FCP-2 recovery proposal, T10/00-260r1, to clarify the
behavior and to cover some potential problems. Please take a look at the
changes.

1) There is a new requirement for the FCP-2 target to age the completed
command context.

2) There is a new requirement for the FCP-2 target to throw away old
OX_ID context when a new identical OX_ID is received.

3) There is a proposed PRLI negotiation to enable the new recovery
behavior.

Best regards,
Dave Baldwin
Emulex Corporation

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org