97-184r3.txt Class 2 Fibre Channel Tape Proposal

Doug Hagerman, DEC, 508-841-2145, reply-to: hagerman@mail.dec.com 19-Aug-1997 0002 hagerman at starch.enet.dec.com
Mon Aug 18 20:56:56 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Doug Hagerman, DEC, 508-841-2145, reply-to: hagerman at mail.dec.com  19-Aug-1997 0002" <hagerman at starch.ENET.dec.com>
*
I just realized that I need to pick up my daughter at the airport
tomorrow at 1:10 pm, right in the middle of the teleconference. I don't
have a cellular phone, so I will not be able to attend. Here is the latest
version of the Class 2 proposal, including all the comments I have
received so far. There are no identified holes at this point. I hope
the formatting makes it's way through the internet...

Doug.

---------------


Use of Class 2 for Fibre Channel Tapes              T10/97-184R3.TXT

970819

This paper describes the use of the Fibre Channel Class 2 protocol
when communicating to a tape device that implements the SCSI-3
Streaming Commands (SSC) device model. Some preliminary discussion
on this topic is in document T10/97-155R3.TXT.


1. Scope

1.1 The basic proposal here is to "use Class 2". There are no newly 
invented primitives or FC-PH concepts. This proposal fits in exactly 
with the error handling philosophy described in sections 4.15 (page 31) 
and 29.7 (page 265) of FC-PH. Most of this paper is a tutorial on the 
Fibre Channel error handling mechanism for Class 2 as described in
FC-PH.

1.2. The protocol is intended to work using the FC-PH Class 2 behavior
as it applies to switched Fibre Channel, FC-AL, and FCL environments.
This has numerous implications such as, for example, the possibility
of out-of-order delivery of frames within a sequence.

1.3. While this discussion is narrowly targeted at SSC devices, it is 
believed that the protocol described here would work for all SCSI-3 
device models. It may be particularly useful in cases where the 
physical environment is less than ideal, or where command sequentiality 
is of particular concern (e.g. systems using XOR functions in disks).

2. Other possibilities

Refer to 97-189Rx.TXT (the Crossroads proposal) for discussion of a
protocol for the use of Class 3 for tapes. This Class 3 proposal
is to poll the target device at certain times to determine the
status of a transfer.

3. FC/FCP/SCSI Reminder

According to the FCP mapping of SCSI to Fibre Channel, each
SCSI command is completely processed within a single Fibre
Channel exchange. If command sequentiality is required, it is to be
managed entirely by the initiator.

Throughout this discussion it is held as a fundamental assumption
that when a SCSI command, contained within the bounds of an exchange,
is issued by the initiator every possible attempt shall be made
to successfully transfer that command, and its associated data and
return status, between the initiator and the target.

Proposals that require commands to be retried at the ULP level, except
in the most severe cases, are not under discussion.



4. Proposal

4.1. Class 2 Concepts and Rules

- Use Class 2 ACK 0 model. This is one ACK per sequence.
- Use E_D_TOV to detect most errors.
- Use RES (Read Exchange Status) to inquire about the state of the 
other device.
- Use a specified large number "n" of retry sequences; n is currently 
TBD.
- Allow ULP timeout if n retries fail (gross target device failures).
- Use existing FCP Information Units (IU) and FC-PH features.
- If E_D_TOV expires before a given sequence completes, retransmit the 
entire IU in a new sequence using new sequence ID and counts.
- Follow all existing Class 2 rules regarding the use of ABTS and RRQ.
- Use the same rules whether on a loop or a fabric.
- Release sequence and exchange data structures as early as possible.

The basic rules are as follows. It is intended that these not conflict 
with the normal use of Class 2 as described in FC-PH.

a.) For each exchange, the exchange initiator starts a ULP timer using 
a value defined by the SCSI command timeout for the given command. If 
the timer expires before the SCSI status is successfully returned in 
the FCP_RSP IU, then the exchange and SCSI command have failed and this 
is reported to the user's program.

The ULP timer is primarily intended for detection of a completely 
failed target device or communication path, and is not used in the 
error recovery process.

b.) For each sequence within the exchange, the sender starts a sequence 
timer with a value of E_D_TOV (as defined on FC-PH page 261) upon the 
transmission of the last frame of the sequence.

For the first sequence in an exchange, if after sending the sequence 
the sequence ACK is not received by the time the timer expires, then 
the initiator must attempt to determine whether

i.) the FCP_CMD was lost, or
ii.) the FCP_CMD was delivered but the ACK and FCP_RSP were lost, 
and the target thinks that the command completed successfully.

To do this, the initiator sends an RES (Read Exchange Status) Extended 
Link Service in a new sequence in the same exchange (passing SI to the 
recipient). The reply indicates which case it is.

If the RES sequence fails (detected by E_D_TOV timeout), the initiator 
resends the RES up to n times before terminating the exchange. The RES 
process is describe in more detail below.

After the RES is successfully sent and the state of the other sequence 
recipient known, the initiator perform the ABTS process. This process 
cleans up any outstanding frames that might otherwise pop out of the 
fabric later. See below for details of the ABTS process. (The ABTS 
process also includes the use of RRQ, as described below.)

After the ABTS process completes, if the initiator had determined that 
the exchange was unknown (case i.) then it sends the same IU in a new 
sequence. If the initiator had determined that the exchange was known 
(case ii.) then it expects that the target should be attempting to 
resend the FCP_RSP up to n times. In this case the initiator waits 
until either it successfully receives the FCP_RSP or until the ULP 
timer expires. 

The process described above (send-wait-timeout-RES-ABTS-RRQ-resend) is 
repeated n times, where n is a (large) number that has yet to be 
determined but will be a fixed feature of the protocol. The value of n 
is the same for both the initiator and the target. Presumably n 
failures of this type would be an extremely rare event.

c.) The same basic rule is followed by the initiator and the target for 
each sequence in the exchange. Context for each sequence is held until 
the ACK is received or until the sequence retry count n is equalled. In 
the case of a target doing the retries, after n retries the context for 
the exchange is discarded and the ULP timer in the initiator is allowed 
to expire.

d.) If the target is acting as the Sequence Initiator and it is unable 
to successfully send the sequence and get the associated ACK, then the 
sequence timeout (also E_D_TOV) will cause the sequence to be aborted.

4.2. Notes on Rules

The following notes are to clarify the above overview.

4.2.1. The transmission of a single SCSI command (in one exchange)
is performed using the following four steps:

a.) Normal exchange, sequence, and frame delivery, including correct 
placement of data into the reciever's buffer.
b.) Detection of errors by missing ACKs or other methods.
c.) Run-down and clean-up of the remains of any failed exchanges, 
sequences, and/or frames. This includes the use of the RES, ABTS and 
RRQ processes.
c.) Retransmission of the SCSI command or data in a new sequence.

4.2.2. Timers

Review FC-PH 29.2. The E_D_TOV timer is for error detection, currently 
said to be 2 seconds in various profiles.

The R_A_TOV timer is for "how long a frame may be held in a fabric". 
Currently 120 seconds.

4.2.3. Discard Policy

The policy under discussion is "discard a single sequence" (see FC-PH 
29.6.1) since that allows full out-of-order delivery at both the frame 
and sequence level.

4.2.4. Sequence initiative (SI)

The holder of Sequence Initiative (SI) is the sequence initiator. If a 
node holds SI and receives a frame for that exchange, it transmits a 
P_RJT because its not supposed to be getting any incoming frames.

The sequence initiator may transfer sequence initiative to the sequence 
recipient by setting a control bit in the frame header. SI is 
considered accepted by the sequence recipient when the ACK for the 
sequence is *sent* by the old recipient back to the old initiator. See 
FC-PH 24.6.4.

4.2.5. Sequence Error Detection

Sequence timeout (FC-PH 29.2.4) is the basic Class 2 error detection 
method. The sequence timer is started with a value of E_D_TOV, and if 
no ACK is received for the sequence within that time, a sequence 
timeout has occured.

In normal operation the ACK will be returned well before the timer 
expires, and the context for the sequence may be discarded at that 
point. Thus in normal operation the only sequence context that is 
pending is that related to sequences that have not yet had ACKs 
returned.

A sequence timeout may be detected either by the sequence initiator or 
the sequence recipient.

If a sequence timeout is detected by the sequence initiator, then it 
performs the ABTS protocol. The first step in this protocol is to send 
an ABTS Basic Link Services frame.

The sequence recipient also runs an E_D_TOV timer, and if all frames 
for a sequence have not been received within E_D_TOV (if they arrive 
out of order it's ok), a sequence timeout has occured.

If a sequence timeout is detected by the sequence recipient, then
it performs the abnormal sequence termination protocol (FC-PH 29.7.1).
The first step in this process is to return an ACK with the Abort
Sequence Condition bits set.

4.2.6. RES Process

The Read Exchange Status Block (RES) link service requests an N_Port to 
return the contents of the Exchange Status Block for the RX_ID or OX_ID 
specified in the request (FC-PH 21.4.10). The response to the RES may 
be either a BA_ACC or a BA_RJT, depending on the following rules.

At the start of a new Exchange, the originator assigns an OX_ID and 
embeds it in all frames of the Exchange (FC-PH 4.13.4.1). The responder 
assigns an RX_ID and communicates it to the originator before the end 
of the first sequence in the exchange. From then on, all frames have 
both the OX_ID and the RX_ID in them for the duration of the Exchange.

The responder to the RES uses only the RX_ID, ignoring the OX_ID. If 
the sequence under discussion is the first sequence in the exchange, 
then the originator will not have found out the RX_ID yet, so it will 
use FFFF as the RX_ID (FC-PH 24.3.2, 29.7.1.1 Special Case  new 
Exchange).

Thus the possible responses to the RES are:

If RX_ID == FFFF, return BA_ACC (in order to allow the following RRQ to 
be set up)
If RX_ID != FFFF, then
	If OX_ID/RX_ID pair describing an exchange is found, then BA_ACC
	Else BA_RJT

Thus the return of a BA_ACC does not indicate whether or not the target 
has knowledge yet of the command. However, if the Special Case rules 
are being followed then the BA_ACC will contain an indication of 
Invalid Sequence ID in its payload. On the other hand, if the BA_ACC is 
|from the case where there is a known OX_ID/RX_ID pair, then the BA_ACC 
will contain a valid indication along with the Exchange Status Block.

Thus the algorithm to determine whether the target knows about the 
Exchange yet is:

Send RES
If response is BA_ACC with invalid Sequence ID indication, then target 
doesnt know about the command yet
If response is BA_ACC with valid Sequence ID indication and expected 
contents of exchange status block, then target does know about it

Depending on the result of this test, the initiator knows whether to 
start the exchange again. The same exchange ID could be used as 
previously, but the sequence ID would need to be different in that 
case.

[At this point I think that the only time that RES is needed is on the 
first sequence of a new exchange, but perhaps it should be used for 
every sequence?]

4.2.7. ABTS Process

This is used if the failure is detected by the initiator. See below
for the case where the failure is detected by the recipient.

ABTS may be sent without holding SI (FC-PH 21.2.2).

The LS bit in the ABTS is cleared in all cases. (LS = 1, as used in 
current protocols, causes the entire exchange to be terminated when an 
error occurs. This is perhaps the primary change associated with this 
proposal.)

The sequence initiator sends ABTS, then starts an E_D_TOV timer.
The ABTS frame is considered part of the aborted sequence,
but runs under its own timer, since the sequence timer has
already expired (that's what got us here). The ABTS condition
is indicated by a bit in the F_CTL field of a frame.

After the ABTS is transmitted, the sequence is in an indeterminate
state.

At this point the recipient returns the Basic Accept (BA_ACC, FC-PH 
21.2.2).
The BA_ACC payload includes the Recovery Qualifier, a data structure
that allows the initiator and recipient to synchronize their 
understanding
of the status of the sequence. This is done by providing a list
of SEQ_IDs that are non-deliverable, so that the initiator can be
sure to not send that sequence ID again.

In perhaps the most typical case, a single frame in a multi-frame 
sequence will have vanished for some reason. After the timeout, the 
initiator sends ABTS in a frame appended to the end of the sequence. 
[Even though it has already sent the last frame of the sequence, which 
is so marked.]

Since at the recipient's end the frame never arrived, the ABTS 
indicates a sequence to be aborted. [Question here of possible race 
condition if the recipient times out the sequence before it receives 
the ABTS.] The SEQ_ID is known. The high SEQ_CNT in the Recovery 
Qualifier range is the SEQ_ID of the ABTS frame, while the low SEQ_CNT 
of the Recovery Qualifier is that of the first frame in the sequence 
(probably 1).

Thus by FC-PH 21.2.2.1 "a sequence is in error" (page 135--"ABTS
Recipient"), so a recovery range "shall be established for both 
N_Ports".

Assuming that the BA_ACC makes it back to the initiator, it then
knows that the sequence has been successfully aborted, and it may
proceed to send the same IU in a new sequence. After E_D_TOV expires
at the recipient end, the recipient may discard its context for that
aborted sequence and proceed.

4.2.8. What if the recipient has never heard of this sequence?

This is detected by the RES process. The ABTS process with RRQ insures 
that the old sequence does not accidently get reused, and the sequence 
initiator sends the same data in a new sequence.

4.2.9. What if the ABTS fails?

If, after sending ABTS, the E_D_TOV timer expires at the initiator 
before a BA_ACC or BA_RJT is received, then the initiator sends another 
ABTS.

4.2.10. What if the BA_ACC fails?

>From the initiator's viewpoint it's the same as above.

4.2.11. What if the BA_RJT fails?

>From the initiator's viewpoint it's the same as above.

4.2.12. RRQ process

The recovery qualifier is a data structure provided by the recipient to 
the initiator in the BA_ACC to the ABTS. (FC-PH 29.7.1.1) It describes 
a completely qualified exchange and sequence and a range of frames.

The RRQ process is required because the fabric is allowed to hold 
frames for up to R_A_TOV time (120 seconds). Thus if an ACK is lost 
(i.e. not delivered within E_D_TOV) the goal is to construct a range of 
frames that are declared invalid for R_A_TOV time.

For example, if the RRQ process were not used, if a frame were to 
suddenly pop out of the fabric with a sequence ID unknown to the 
recipient, should the recipient think that this is a mid-sequence frame 
for a sequence whose first frame has not yet arrived? If so it would 
hold on to it.

Using RRQ, the Recover Qualifier allows invalid frames to be made known 
to the recipient in advance.

After R_A_TOV expires, the initiator issues an RRQ Link Service
(FC-PH 21.4.14) in a separate exchange. If the RRQ exchange fails,
a nested ABTS and new subsequent RRQ may be used, up to the nesting
capability of the hardware.

4.2.13. Abnormal Sequence Termination

This is used if the failure is detected by the recipient. See above
for the case where the failure is detected by the initiator.

If a sequence error is detected by the exchange recipient, this fact is 
conveyed to the exchange initiator by the Abort Sequence Condition bits 
in an ACK frame (FC-PH 29.6.3). The ABTS process is then started by the 
exchange initiator.

4.2.14. R_RDY to Precede Every Expected ACK

It is implied in FC-PH, but not clearly stated (FC-PH 16.3.2, 20.2.1,
20.3.1, table 56) that an R_RDY must be transmitted before each
sequence for which an ACK is expected. This is to insure that a buffer
is available for the ACK frame. This requirement implies that, since
the time until the ACK is returned is unpredictable, the sequence
initiator must have an available ACK buffer before sending
a sequence for which an ACK is expected.

This also applies to switches. Consider the following case, suggested 
by Bill Martin.

Suppose there is a loop attached to a fabric, with an NL_Port device on 
the loop. Suppose some other devices on the fabric want to send some 
frames (say, 10) to the device. The other devices send R_RDYs, then 
frames, to the fabric. The R_RDYs indicate that the devices have buffer 
space for the expected ACKs for those frames (as required by the above 
rule).

Then the fabric opens the loop, sends the R_RDYs to indicate that it 
has buffer space for the ACKs it expects to receive, then sends the 
frames to the device, then closes the loop (because none of the devices 
are ready to send data back yetsay its all READs). The target NL_Port 
gets the R_RDYs and frames, then opens the loop to send the ACKs back 
to the switch which will then send ACKs back to the original devices 
that sent the frames in the first place.

The original devices that send the frames have control over how many 
frames they send and can thus maintain the required ACK buffer space. 
However, the switch doesn't throttle incoming frames so it can't 
reserve the required ACK buffer space. Clearly this wont work; the 
question is whether it is possible for switches to throttle the 
incoming frames down to the limit required by their available ACK 
buffer space. Recall that the switch sent the R_RDYs indicating that it 
had the ACK buffer space in the first place; perhaps the question is 
whether switches are to maintain this buffer space on a general basis 
considering that the need for it is likely to be fairly low, 
statistically.

This issue requires more clarification, particularly with comment from 
switch implementors.

4.2.15 Use of Relative Offset

This is intended to be a straightforward reading of FC-PH.

Sequences and frames are normally transmitted in sequential order
by the sequence initiator. The fabric may reorder both. Thus
the recipient must reassemble frames into sequences and must deliver
complete sequences of data to the upper layer in the proper order.
This is achieved by the use of Relative Offset (FC-PH 18.11, 27, 24).

(Sequence count (i.e. "frame id within sequence", FC-PH 18.8) could
also be used to define the storage location, but is not in this
proposal.

(Sequence ID (i.e. "location of sequence within this exchange",
FC-PH 18.6) cannot be used to define the storage location because if
a sequence fails, the same data will be sent in a new sequence
with a new sequence ID.)

(Sequence Count:  2 Bytes
 Relative Offset: 4 Bytes
 Sequence ID:     1 Byte)

Relative Offset is defined with respect to the beginning of the
data to be transmitted in the SCSI command (i.e. Exchange), in
terms of Bytes. This rule defines the Relative Offset Space
(FC-PH 27.2). The use of this rule is indicated by word 2, bit 3 = 1
in the F_CTL field (FC-PH 18.5, table 37). Continuously Increasing
relative offset shall be used (FC-PH 27.6).

The sequence recipient shall present data to the ULP only
after a sequence has been completely received. If frames arrive
out of order, the contents of the frames is stored in the recipient's
buffer until the sequence is complete. Before data is presented
to the ULP, all previous data (as indicated by completeness of
the relative offset values) shall have been presented to the ULP.

4.3. Introduction to Examples

The following examples show the case of processing an error
frame that occurs during the transfer of an FCP_DATA sequence.
Errors that occur during the many other frames and sequences are
discussed in the notes following the examples.

Regardless of whether the command is a READ or a WRITE, there are
really only three general cases that need to be handled:

	- first sequence in an exchange, including exchange initiation
	- mid-exchange sequences going in either direction
	- last sequence in an exchange, including exchange completion

4.3.1. First Sequence in an Exchange

In this case, in addition to the normal sequence processing there is 
some overhead related to starting up the exchange. However, the 
procedure for trying to get the sequence to the recipient is the same 
as for the mid-exchange case. 

The difference is that the RES procedure described above is used to 
determine whether or not the target successfully received the first 
sequence of the exchange.

4.3.2. Mid-Exchange Sequences

This is the "normal" case, and is handled with the ABTS and RRQ 
processes.

4.3.3. Last Sequence in an Exchange

In this case the primary issue is running down the exchange and 
releasing various resources.

In the case of the target, the context for the current exchange is 
discarded when the ACK for the last sequence is received.

In the case of the initiator, the context for the current exchange is 
discarded when the ACK for the last sequence is sent.

If the ACK does not make it back to the target, then the target
will perform the ABTS protocol. However, the initiator will return a 
BA_RJT to the ABTS because it no longer has exchange context. At this 
point the target must give up because it has no way to communicate to 
the initiator. Thus it discards exchange context and allows the 
initiator to allow the ULP timer to expire.

If the last sequence from the target does not make it back to the 
initiator (this will be the one containing the FCP_RSP and SCSI 
status), then the target will detect a sequence error and perform the 
ABTS protocol. When the ABTS is received at the initiator the initiator 
returns a BA_ACC describing the exchange context. The target then 
performs a normal sequence recovery to return the FCP_RSP to the 
intiator.

The recovery process is tried n times by the target.

4.4. Mappings of FCP to Class 2

This section shows how FCP is used with Class 2.

4.4.1. WRITE

Transfer of 2 data sequences, each containing 4 frames of data. Target 
indicates its ability to accept data by use of FCP_XFR_RDY IUs.

Initiator          Target
--------------------------------------------

FCP_CMD ---------->

        <----------  ACK
                     Receipt of ACK by initiator indicates FCP_CMD is
                     ok. (FCP_CMD is a single-frame sequence.)

                     A long period of time may be required here
                     for the target to find space for the data or to
                     do some preliminary media positioning.

        <----------  FCP_XFR_RDY
                     Target indicates readiness to accept one
                     sequence of data
ACK     ---------->

        ---------->  DATA sequence ID = 1, CNT = 1 (frame 1)
        ----->X      DATA sequence ID = 1, CNT = 2 (frame 2)
                     Error occurs on interconnect at "X". The frame is
                     lost.

        ---------->  DATA sequence ID = 1, CNT = 3 (frame 3)
        ---------->  DATA sequence ID = 1, CNT = 4 (frame 4)

Initiator has sent all the data frames,
so it starts an E_D_TOV timer for this sequence.

                     Target does not get all the frames, so it doesn't
                     send an ACK

Initiator's timer expires. ACK not received,
so the sequence has failed. Initiator sends ABTS to
make sure that this sequence is aborted.

ATBS    ---------->

        <----------  BA_ACC with Recovery Qualifier

                     Target returns BA_ACC indicating acceptance
                     of the sequence abort. Also included is the
                     Resource Recovery Qualifier.

Initiator starts an R_A_TOV timer (120 seconds)
for use with RRQ.

120 seconds later the timer expires and the resources described in the 
RRQ are released. [This need to keep stuff around "forever" in the RRQ 
process is also something of a problem...]

Initiator retransmits the same data as before in a new sequence.

[Charles asked whether it would make sense to only resend part of the 
data, if some got through ok. I think that would be too fancy. The 
sending of data doesnt take very long...]

        ---------->  DATA sequence ID = 2, CNT = 1 (frame 1)
        ---------->  DATA sequence ID = 2, CNT = 2 (frame 2)
        ---------->  DATA sequence ID = 2, CNT = 3 (frame 3)
        ---------->  DATA sequence ID = 2, CNT = 4 (frame 4)

        <----------  ACK

                     Target discards context for the sequence.

Receipt of ACK by initiator indicates that the sequence is ok.
Initiator may discard context for this sequence.

                     When the tape is ready to receive additional
                     data, it sends another FCP_XFR_RDY.

        <----------  FCP_XFR_RDY
                     Target indicates readiness to accept one
                     sequence of data

ACK     ---------->

        ---------->  DATA sequence ID = 3, CNT = 1 (frame 1)
        ---------->  DATA sequence ID = 3, CNT = 2 (frame 2)
        ---------->  DATA sequence ID = 3, CNT = 3 (frame 3)
        ---------->  DATA sequence ID = 3, CNT = 4 (frame 4)

        <----------  ACK

                     Receipt of ACK indicates that the sequence is ok.
                     Discard sequence context and proceed to next
                     sequence.

                     Target observes that it has enough data to
                     satisfy the requirements of the SCSI WRITE
                     command, so it sends the SCSI status back.

        <----------  FCP_RSP
                     With SCSI Status.

ACK     ---------->
Initiator discards exchange status since
as far as it's concerned, the command is complete.

                     Target closes exchange and deletes command
                     context.


============================================






4.4.2. READ

Transfer of 2 data sequences, each containing 4 frames
of data. Assume the host can accept all the data specified in the 
command.

Initiator          Target
--------------------------------------------

FCP_CMD ---------->
        <----------  ACK
                     Receipt of ACK by initiator indicates FCP_CMD
                     is ok. (FCP_CMD is a single-frame sequence.)

                     A long period of time may be required here
                     for the target to get the data from the media.

        <----------  DATA sequence ID = 1, CNT = 1 (frame 1)

             X<----  DATA sequence ID = 1, CNT = 2 (frame 2)
                     Error occurs on interconnect at "X". The frame is
                     lost.

        <----------  DATA sequence ID = 1, CNT = 3 (frame 3)
        <----------  DATA sequence ID = 1, CNT = 4 (frame 4)

                     Target has sent all the data frames,
                     so it starts an E_D_TOV timer for this sequence.

Initiator does not get all the frames, so it doesn't send an ACK.

                     Target's timer expires. ACK not received,
                     so the sequence has failed.

        <----------  ABTS
BA_ACC  ---------->
with recovery qualifier

                     Target starts R_A_TOV timer for RRQ process.

                     Target retransmits sequence.

        <----------  DATA sequence ID = 2, CNT = 1 (frame 1)
        <----------  DATA sequence ID = 2, CNT = 2 (frame 2)
        <----------  DATA sequence ID = 2, CNT = 3 (frame 3)
        <----------  DATA sequence ID = 2, CNT = 4 (frame 4)

ACK     ---------->
                     Receipt of ACK indicates that the sequence is ok.
                     Proceed to next sequence.

        <----------  DATA sequence ID = 3, CNT = 1 (frame 1)
        <----------  DATA sequence ID = 3, CNT = 2 (frame 2)
        <----------  DATA sequence ID = 3, CNT = 3 (frame 3)
        <----------  DATA sequence ID = 3, CNT = 4 (frame 4)

ACK     ---------->
                     Receipt of ACK indicates that the sequence is ok.
                     Proceed to next sequence.

        <----------  FCP_RSP
                     With SCSI Status.
ACK     ---------->
                     Target closes exchange and deletes command 
context.

Initiator waits for E_D_TOV after sending ACK to make sure no more
sequences are coming. (This would be a resend of the FCP_RSP if the
last ACK had been lost on its way to the target.) After timout expires,
Initiator discards context for this exchange.


120 seconds later the timer expires and the resources described in the 
RRQ are released.

============================================

4.5. Notes on Examples

Any frame in the exchange may fail. The following lists the
handling of each possible case. This is intended to follow
the FC-PH protocol exactly.

4.5.1. Loss of FCP_CMD single-frame sequence. In this case the target 
never sees the command. When initiator's E_D_TOV timer expires it first 
sends an RES, then an ABTS. Depending on the result of the RES it can 
determine whether the command needs to be sent again. If so, it resends 
the FCP_CMD IU using the same information and the same exchange 
identifier in a new sequence.

[I'm not sure about the same exchange? - Charles]

4.5.2. Loss of ACK after FCP_CMD. In this case the target saw the 
command and has constructed exchange context. When initiator's E_D_TOV 
timer expires it first sends an RES to determine what needs to be done. 
This is followed by an ABTS to clean up the sequence but maintain the 
exchange.

4.5.3 Loss of ABTS after loss of FCP_CMD sequence. In this case
the ABTS protocol times out. The ABTS protocol is tried n times.

4.5.4. Loss of ABTS after loss of ACK after FCP_CMD sequence. In this
case the target has constructed exchange context, which is detected by 
the RES. The ABTS is retried n times.



5. Advantages of Class 2

- Uses existing FC-PH features.
- Uses existing FCP Information Units.
- Good opportunity to automate the processing of each exchange.
- Sequence Initiative management is already defined in FC-PH.
- Sequence streaming is already defined in FC-PH.
- Good resource management, event driven in all cases:
	- Sequence recipient releases context as soon as ACK is sent.
	- Sequence initiator releases context as soon as ACK is received.
	- Target releases command (exchange) context as soon as final ACK 
is received for the command.
	- Initiator releases command (exchange) context as soon as final 
ACK is sent for the command.

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




More information about the T10 mailing list