Re: Re: Last Call TMF resolution

David,

Legacy->RFC3720 change done.  Latest text is attached below.  

AFAICT, initiator behavior parenthetical text under 4.1.3 bullet-c is what you are suggesting we clarify in 4.1.4. 
"this step also applies when the initiator is receiving the Async Message in the third-party role"

But let me know if that isn't the case.

Thanks.

Mallikarjun


----- Original Message ----
From: "[email protected]" <[email protected]>
To: [email protected]; [email protected]
Sent: Friday, January 26, 2007 2:02:34 PM
Subject: RE: [Ips] Re: Last Call TMF resolution


I think I see some of where I'm confused.  4.1.2 and 4.1.3 are
about what the initiator that sent the TMF does as well as the
target.  We need to explain what a 3rd-party initiator does,
which for a 3720-only initiator is unchanged.  I think your
new 4.1.4 is headed towards covering this in addition to the
Target behavior in a mixed FastAbort/non-FastAbort case.

One crucial point that needs
to be made is that a FastAbort initiator may get an AsyncEvent=5
message out of the blue if some other initiator, even a Legacy
initiator, issues a TMF that affects the FastAbort initiator's
tasks, even if the iSCSI session only contains a single TCP
connection (FastAbort initiator will never get AsyncEvent=5
messages for its own TMFs on a single connection session).

On another minor note, "Legacy" as a key value seems pejorative
to me. "RFC3720" would be neutral and in fact more descriptive
of what's actually going on.

Thanks,
--David

4.1.3 Updated multi-task abort semantics
Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document.  Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (section 9.1) key to “FastAbort” on that session.  The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party. 
The initiator iSCSI layer:
a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.
b. Should receive any responses that the target may provide for some tasks among the affected tasks (may process them as usual because they are guaranteed to have chronologically originated prior to the TMF response).
c. MUST respond to each Async Message PDU with AsyncEvent=5 as defined in section 8.1 (this step also applies when the initiator is receiving the Async Message in the third-party role).
d. Should receive the TMF Response concluding all the tasks in the set of affected tasks.

The target iSCSI layer:
a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session.  SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks.  In the case of target-scoped requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream can be considered to have been received with no command waiting period - i.e. the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
b. MUST propagate the TMF request to and receive the response from the target SCSI layer. 
c. MUST leave all active "affected TTTs" (i.e. active TTTs associated with affected tasks) valid.
d. MUST send an Asynchronous Message PDU with AsyncEvent=5 (section 8.1) on:
i) each connection of each third-party session to which at least one affected task is allegiant if TaskReporting=FastAbort is operational on that third-party session, and
ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.
If there are multiple affected LUs (say due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task.  The LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
e. MUST address the Response Fence flag on the TMF Response on issuing session as defined in 3.3.2.
f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once it receives each associated Nop-Out acknowledgement that the initiator generated in response to each Async Message.  
Implementation note: Technically, the TMF servicing is complete in Step.e.  Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step.f.  TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step.e, and MAY be sent at the end of Step.e despite these outstanding Data transfers until Step.g.  Step.g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.  

4.1.3.1 Clearing effects update
---No changes -----

4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions
If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (section 9.1), it may end up in a situation where some sessions have TaskReporting=RFC3720 operational (RFC3720 sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (section 4.1.1).
If the issuing session is a RFC3720 session, iSCSI target implementation is FastAbort-capable and third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:
a. Between steps c and d of target behavior in section 4.1.2, send an Asynchronous Message PDU with AsyncEvent=5 (section 8.1) on each connection of each third-party session to which at least one affected task is allegiant.  If there are multiple affected LUs, then send one Async Message PDU for each such LU on each connection that has at least one allegiant affected task.  When sent, the LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
b. After step e of target behavior in section 4.1.2, free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once each associated Nop-Out acknowledgement is received that the third-party initiator generated in response to each Async Message sent in step a.
If the issuing session is a FastAbort session, iSCSI target implementation is FastAbort-capable and third-party affected session is a RFC3720 session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior.


 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips