draft-ietf-ips-iscsi-impl-guide-04.txt   draft-ietf-ips-iscsi-impl-guide-05.txt 
INTERNET DRAFT Mallikarjun Chadalapaka INTERNET DRAFT Mallikarjun Chadalapaka
draft-ietf-ips-iscsi-impl-guide-04.txt Hewlett-Packard Co. draft-ietf-ips-iscsi-impl-guide-05.txt Hewlett-Packard Co.
Editor Editor
Expires Expires
August 2007
iSCSI Corrections and Clarifications iSCSI Corrections and Clarifications
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he or that any applicable patent or other IPR claims of which he or
she is aware have been or will be disclosed, and any of which she is aware have been or will be disclosed, and any of which
he or she becomes aware will be disclosed, in accordance with he or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79. Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1 Definitions and acronyms ...............................5 1 Definitions and acronyms ...............................5
1.1 Definitions ............................................5 1.1 Definitions ............................................5
1.2 Acronyms ...............................................5 1.2 Acronyms ...............................................5
2 Introduction ...........................................7 2 Introduction ...........................................7
3 iSCSI semantics for SCSI tasks .........................8 3 iSCSI semantics for SCSI tasks .........................8
3.1 Residual handling ......................................8 3.1 Residual handling ......................................8
3.1.1 Overview..............................................8 3.1.1 Overview..............................................8
3.1.2 SCSI REPORT LUNS and Residual Overflow................9 3.1.2 SCSI REPORT LUNS and Residual Overflow................9
3.2 R2T Ordering ..........................................10 3.2 R2T Ordering ..........................................10
3.3 SCSI Protocol Interface Model for Response Ordering ...11 3.3 Model Assumptions for Response Ordering ...............11
3.3.1 Model Description....................................11 3.3.1 Model Description....................................11
3.3.2 iSCSI Semantics with the Interface Model.............11 3.3.2 iSCSI Semantics with the Interface Model.............12
3.3.3 Current List of Fenced Response Use Cases............12 3.3.3 Current List of Fenced Response Use Cases............12
4 Task Management .......................................14 4 Task Management .......................................14
4.1 Requests Affecting Multiple Tasks .....................14 4.1 Requests Affecting Multiple Tasks .....................14
4.1.1 Scope of affected tasks..............................14 4.1.1 Scope of affected tasks..............................14
4.1.2 Clarified multi-task abort semantics.................14 4.1.2 Clarified multi-task abort semantics.................14
4.1.3 Updated multi-task abort semantics...................16 4.1.3 Updated multi-task abort semantics...................16
4.1.4 Implementation considerations........................18 4.1.4 Affected tasks shared across RFC3720 & FastAbort
4.1.5 Rationale behind the new semantics...................19 sessions....................................................18
5 Discovery semantics ...................................21 4.1.5 Implementation considerations........................19
5.1 Error Recovery for Discovery Sessions .................21 4.1.6 Rationale behind the new semantics...................20
5.2 Reinstatement Semantics of Discovery Sessions .........21 5 Discovery semantics ...................................22
5.2.1 Unnamed Discovery Sessions...........................22 5.1 Error Recovery for Discovery Sessions .................22
5.2.2 Named Discovery Sessions.............................22 5.2 Reinstatement Semantics of Discovery Sessions .........22
5.3 Target PDUs during Discovery ..........................23 5.2.1 Unnamed Discovery Sessions...........................23
6 Negotiation and Others ................................24 5.2.2 Named Discovery Sessions.............................23
6.1 TPGT Values ...........................................24 5.3 Target PDUs during Discovery ..........................24
6.2 SessionType Negotiation ...............................24 6 Negotiation and Others ................................25
6.3 Understanding NotUnderstood ...........................24 6.1 TPGT Values ...........................................25
6.4 Outstanding Negotiation Exchanges .....................25 6.2 SessionType Negotiation ...............................25
7 iSCSI Error Handling and Recovery .....................26 6.3 Understanding NotUnderstood ...........................25
7.1 ITT ...................................................26 6.4 Outstanding Negotiation Exchanges .....................26
7.2 Format Errors .........................................26 7 iSCSI Error Handling and Recovery .....................27
7.3 Digest Errors .........................................26 7.1 ITT ...................................................27
7.4 Message Error Checking ................................27 7.2 Format Errors .........................................27
8 iSCSI PDUs ............................................28 7.3 Digest Errors .........................................27
8.1 Asynchronous Message ..................................28 7.4 Message Error Checking ................................28
8.2 Reject ................................................28 8 iSCSI PDUs ............................................29
9 Login/Text Operational Text Keys ......................29 8.1 Asynchronous Message ..................................29
9.1 TaskReporting .........................................29 8.2 Reject ................................................29
10 Security Considerations ...............................31 9 Login/Text Operational Text Keys ......................30
11 IANA Considerations ...................................32 9.1 TaskReporting .........................................30
12 References and Bibliography ...........................33 10 Security Considerations ...............................32
12.1 Normative References.................................33 11 IANA Considerations ...................................33
12.2 Informative References...............................33 12 References and Bibliography ...........................34
13 Editor's Address ......................................34 12.1 Normative References.................................34
14 Acknowledgements ......................................35 12.2 Informative References...............................34
15 Full Copyright Statement ..............................36 13 Editor's Address ......................................35
16 Intellectual Property Statement .......................37 14 Acknowledgements ......................................36
15 Full Copyright Statement ..............................37
16 Intellectual Property Statement .......................38
1 Definitions and acronyms 1 Definitions and acronyms
1.1 Definitions 1.1 Definitions
I/O Buffer - A buffer that is used in a SCSI Read or Write I/O Buffer - A buffer that is used in a SCSI Read or Write
operation so SCSI data may be sent from or received into operation so SCSI data may be sent from or received into
that buffer. For a read or write data transfer to take that buffer. For a read or write data transfer to take
place for a task, an I/O Buffer is required on the place for a task, an I/O Buffer is required on the
initiator and at least one required on the target. initiator and at least one required on the target.
skipping to change at page 11, line 8 skipping to change at page 11, line 8
applicability - either per task, or across all tasks on a applicability - either per task, or across all tasks on a
connection - and may be interpreted as either. This section is connection - and may be interpreted as either. This section is
intended to clarify that the scope of applicability of the intended to clarify that the scope of applicability of the
quoted text is a task. No R2T ordering relationship - either in quoted text is a task. No R2T ordering relationship - either in
generation at the target or in fulfilling at the initiator - generation at the target or in fulfilling at the initiator -
across tasks is implied. I.e., outstanding R2Ts within a task across tasks is implied. I.e., outstanding R2Ts within a task
MUST be fulfilled by the initiator in the order in which they MUST be fulfilled by the initiator in the order in which they
were received on a connection. were received on a connection.
3.3 SCSI Protocol Interface Model for Response Ordering 3.3 Model Assumptions for Response Ordering
Whenever an iSCSI session is composed of multiple connections, Whenever an iSCSI session is composed of multiple connections,
the Response PDUs (task responses or TMF responses) originating the Response PDUs (task responses or TMF responses) originating
in the target SCSI layer are distributed onto the multiple in the target SCSI layer are distributed onto the multiple
connections by the target iSCSI layer according to iSCSI connections by the target iSCSI layer according to iSCSI
connection allegiance rules. This process generally may not connection allegiance rules. This process generally may not
preserve the ordering of the responses by the time they are preserve the ordering of the responses by the time they are
delivered to the initiator SCSI layer. Since ordering is not delivered to the initiator SCSI layer. Since ordering is not
expected across SCSI responses anyway, this approach works fine expected across SCSI responses anyway, this approach works fine
in the general case. However to address the special cases where in the general case. However to address the special cases where
some ordering is desired by the SCSI layer, the following SCSI some ordering is desired by the SCSI layer, the following
protocol interface model is assumed. "Response Fence" semantics are defined with respect to handling
SCSI response messages as they are handed off from the SCSI
protocol layer to the iSCSI layer.
3.3.1 Model Description 3.3.1 Model Description
SCSI protocol layer instructs the SCSI transport layer of a Target SCSI protocol layer hands off the SCSI response messages
"Response Fence" associated with the response in question when to the target iSCSI layer by invoking the "Send Command
the "Send Command Complete" protocol data service (SAM-2, clause Complete" protocol data service ([SAM2], clause 5.4.2) and "Task
5.4.2) and "Task Management Function Executed" (SAM-2, clause Management Function Executed" ([SAM2], clause 6.9) service. On
6.9) service are invoked. The Response Fence flag instructs the receiving the SCSI response message, iSCSI layer exhibits the
SCSI transport layer that the following conditions must be met Response Fence behavior for certain SCSI response messages
in delivering the response message: (section 3.3.3 describes the specific instances where the
semantics must be realized). Whenever the Response Fence
behavior is required for a SCSI response message, the target
iSCSI layer MUST ensure that the following conditions are met in
delivering the response message to the initiator iSCSI layer:
(1) Response with Response Fence MUST chronologically be (1) Response with Response Fence MUST chronologically be
delivered after all the "preceding" responses on the delivered after all the "preceding" responses on the
I_T_L nexus, if the preceding responses are delivered at I_T_L nexus, if the preceding responses are delivered at
all, to the application client on the initiator. all, to the initiator iSCSI layer.
(2) Response with Response Fence MUST chronologically be (2) Response with Response Fence MUST chronologically be
delivered prior to all the "following" responses on the delivered prior to all the "following" responses on the
I_T_L nexus. I_T_L nexus.
The "preceding" and "following" notions refer to the order of The "preceding" and "following" notions refer to the order of
hand-off of a response message from the target SCSI protocol hand-off of a response message from the target SCSI protocol
layer to the target SCSI transport (e.g. iSCSI) layer. layer to the target iSCSI layer.
3.3.2 iSCSI Semantics with the Interface Model 3.3.2 iSCSI Semantics with the Interface Model
Whenever the TaskReporting key (section 9.1) is negotiated to Whenever the TaskReporting key (section 9.1) is negotiated to
ResponseFence or FastAbort for an iSCSI session, the target ResponseFence or FastAbort for an iSCSI session and the Response
iSCSI layer MUST perform the actions described in this section Fence behavior is required for a SCSI response message, the
on all tasks related to that session. A target iSCSI layer MUST target iSCSI layer MUST perform the actions described in this
do the following on sensing the "Response Fence" flag associated section for that session.:
with a response being handed down from the target SCSI layer:
a) If it is a single-connection session, no special processing a) If it is a single-connection session, no special processing
is required. Standard SCSI Response PDU build process is required. Standard SCSI Response PDU build and dispatch
happens. process happens.
b) If it is a multi-connection session, target iSCSI layer b) If it is a multi-connection session, target iSCSI layer
takes note of last-sent and unacknowledged StatSN on each takes note of last-sent and unacknowledged StatSN on each
of the connections in the iSCSI session, and waits for of the connections in the iSCSI session, and waits for
acknowledgement (SHOULD solicit for acknowledgement by way acknowledgement (SHOULD solicit for acknowledgement by way
of a Nop-In) of each such StatSN to clear the fence. SCSI of a Nop-In) of each such StatSN to clear the fence. SCSI
response with the Response Fence flag must be sent to the response with the Response Fence flag must be sent to the
initiator only after receiving acknowledgements for each of initiator only after receiving acknowledgements for each of
the unacknowledged StatSNs. the unacknowledged StatSNs.
skipping to change at page 17, line 18 skipping to change at page 17, line 18
are not yet received on the issuing session in the command are not yet received on the issuing session in the command
stream can be considered to have been received with no stream can be considered to have been received with no
command waiting period - i.e. the entire CmdSN space up to command waiting period - i.e. the entire CmdSN space up to
the CmdSN of the task management function can be "plugged". the CmdSN of the task management function can be "plugged".
b. MUST propagate the TMF request to and receive the response b. MUST propagate the TMF request to and receive the response
from the target SCSI layer. from the target SCSI layer.
c. MUST leave all active "affected TTTs" (i.e. active TTTs c. MUST leave all active "affected TTTs" (i.e. active TTTs
associated with affected tasks) valid. associated with affected tasks) valid.
d. MUST generate an Asynchronous Message PDU with AsyncEvent=5 d. MUST send an Asynchronous Message PDU with AsyncEvent=5
(section 8.1) on: (section 8.1) on:
i) each connection of each third-party session to which at i) each connection of each third-party session to which at
least one affected task is allegiant, and 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 ii) each connection except the issuing connection of the
issuing session that has at least one allegiant affected issuing session that has at least one allegiant affected
task. task.
If there are multiple affected LUs (say due to a target If there are multiple affected LUs (say due to a target
reset), then one Async Message PDU MUST be sent for each reset), then one Async Message PDU MUST be sent for each
such LU on each connection that has at least one allegiant such LU on each connection that has at least one allegiant
affected task. 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 e. MUST address the Response Fence flag on the TMF Response on
issuing session as defined in 3.3.2. issuing session as defined in 3.3.2.
f. MUST address the Response Fence flag on the first post-TMF f. MUST address the Response Fence flag on the first post-TMF
Response on third-party sessions as defined in 3.3.2. If Response on third-party sessions as defined in 3.3.2. If
some tasks originate from non-iSCSI I_T_L nexuses then the some tasks originate from non-iSCSI I_T_L nexuses then the
means by which the target ensures that all affected tasks means by which the target ensures that all affected tasks
have returned their status to the initiator are defined by have returned their status to the initiator are defined by
the specific non-iSCSI transport protocol(s). the specific non-iSCSI transport protocol(s).
skipping to change at page 18, line 29 skipping to change at page 18, line 31
would clear the active TTTs upon completion. The would clear the active TTTs upon completion. The
TaskReporting=FastAbort (section 9.1) semantics defined by this TaskReporting=FastAbort (section 9.1) semantics defined by this
section however do not guarantee that the active TTTs are section however do not guarantee that the active TTTs are
cleared by the end of the reset operations. In fact, the new cleared by the end of the reset operations. In fact, the new
semantics are designed to allow clearing the TTTs in a "lazy" semantics are designed to allow clearing the TTTs in a "lazy"
fashion after the TMF Response is delivered. Thus, when fashion after the TMF Response is delivered. Thus, when
TaskReporting=FastAbort is operational on a session, the TaskReporting=FastAbort is operational on a session, the
clearing effects of reset operations on "Incomplete TTTs" is clearing effects of reset operations on "Incomplete TTTs" is
"N". "N".
4.1.4 Implementation considerations 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.
If the third-party affected session is a FastAbort session and
issuing session is a FastAbort session, initiator in the third-
party role MUST respond to each Async Message PDU with
AsyncEvent=5 as defined in section 8.1. Note that an initiator
MAY thus receive these Async Messages on a third-party affected
session even if the session is a single-connection session.
4.1.5 Implementation considerations
Both in clarified semantics (section 4.1.2) and updated Both in clarified semantics (section 4.1.2) and updated
semantics (section 4.1.3), there may be outstanding data semantics (section 4.1.3), there may be outstanding data
transfers even after the TMF completion is reported on the transfers even after the TMF completion is reported on the
issuing session. In the case of iSCSI/iSER [iSER], these would issuing session. In the case of iSCSI/iSER [iSER], these would
be tagged data transfers for STags not owned by any active be tagged data transfers for STags not owned by any active
tasks. Whether or not real buffers support these data transfers tasks. Whether or not real buffers support these data transfers
is implementation-dependent. However, the data transfers is implementation-dependent. However, the data transfers
logically MUST be silently discarded by the target iSCSI layer logically MUST be silently discarded by the target iSCSI layer
in all cases. A target MAY, on an implementation-defined in all cases. A target MAY, on an implementation-defined
internal timeout, also choose to drop the connections on which internal timeout, also choose to drop the connections on which
it did not receive the expected Data-out sequences (section it did not receive the expected Data-out sequences (section
4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to
reclaim the associated buffer, STag and TTT resources as reclaim the associated buffer, STag and TTT resources as
appropriate. appropriate.
4.1.5 Rationale behind the new semantics 4.1.6 Rationale behind the new semantics
There are fundamentally three basic objectives behind the There are fundamentally three basic objectives behind the
semantics specified in section 4.1.2 and section 4.1.3. semantics specified in section 4.1.2 and section 4.1.3.
1. Maintaining an ordered command flow I_T nexus abstraction 1. Maintaining an ordered command flow I_T nexus abstraction
to the target SCSI layer even with multi-connection to the target SCSI layer even with multi-connection
sessions. sessions.
o Target iSCSI processing of a TMF request must maintain o Target iSCSI processing of a TMF request must maintain
the single flow illusion. Target behavior in Step.b the single flow illusion. Target behavior in Step.b
skipping to change at page 29, line 19 skipping to change at page 30, line 19
9.1 TaskReporting 9.1 TaskReporting
Use: LO Use: LO
Senders: Initiator and Target Senders: Initiator and Target
Scope: SW Scope: SW
Irrelevant when: SessionType=Discovery Irrelevant when: SessionType=Discovery
TaskReporting=<list-of-values> TaskReporting=<list-of-values>
Default is Legacy. Default is RFC3720.
Result function is AND. Result function is AND.
This key is used to negotiate the task completion reporting This key is used to negotiate the task completion reporting
semantics from the SCSI target. Following table describes the semantics from the SCSI target. Following table describes the
semantics an iSCSI target MUST support for respective negotiated semantics an iSCSI target MUST support for respective negotiated
key values. Whenever this key is negotiated, at least the key values. Whenever this key is negotiated, at least the
Legacy and ResponseFence values MUST be offered as options by RFC3720 and ResponseFence values MUST be offered as options by
the negotiation originator. the negotiation originator.
+--------------+------------------------------------------+ +--------------+------------------------------------------+
| Name | Description | | Name | Description |
+--------------+------------------------------------------+ +--------------+------------------------------------------+
| Legacy | RFC 3720-compliant semantics. Response | | RFC3720 | RFC 3720-compliant semantics. Response |
| | fencing is not guaranteed and fast | | | fencing is not guaranteed and fast |
| | completion of multi-task aborting is not | | | completion of multi-task aborting is not |
| | supported | | | supported |
+--------------+------------------------------------------+ +--------------+------------------------------------------+
| ResponseFence| Response Fence (section 3.3.1) semantics | | ResponseFence| Response Fence (section 3.3.1) semantics |
| | MUST be supported in reporting task | | | MUST be supported in reporting task |
| | completions | | | completions |
+--------------+------------------------------------------+ +--------------+------------------------------------------+
| FastAbort | Updated fast multi-task abort semantics | | FastAbort | Updated fast multi-task abort semantics |
| | defined in section 4.1.3 MUST be | | | defined in section 4.1.3 MUST be |
skipping to change at page 35, line 21 skipping to change at page 36, line 21
working group. working group.
The following individuals directly contributed to identifying The following individuals directly contributed to identifying
[RFC3720] issues and/or suggesting resolutions to the issues [RFC3720] issues and/or suggesting resolutions to the issues
clarified in this document: David Black (REPORT LUNS/overflow clarified in this document: David Black (REPORT LUNS/overflow
semantics, ACA semantics, TMF semantics), Gwendal Grignou semantics, ACA semantics, TMF semantics), Gwendal Grignou
(TMF scope), Mike Ko (digest error handling for Asynchronous (TMF scope), Mike Ko (digest error handling for Asynchronous
Message), Dmitry Fomichev (reserved ITT), Bill Studenmund Message), Dmitry Fomichev (reserved ITT), Bill Studenmund
(residual handling, discovery semantics), Ken Sandars (residual handling, discovery semantics), Ken Sandars
(discovery semantics), Bob Russell (discovery semantics), (discovery semantics), Bob Russell (discovery semantics),
Julian Satran (discovery semantics), Rob Elliott (T10 Julian Satran (discovery semantics, TMF semantics), Rob
liaison, R2T ordering), Joseph Pittman(TMF scope), Somesh Elliott (T10 liaison, R2T ordering), Joseph Pittman(TMF
Gupta (multi-task abort semantics). This document benefited scope), Somesh Gupta (multi-task abort semantics), Eddy
from all these contributions. Quicksall (message error checking), Paul Koning (message
error checking). This document benefited from all these
contributions.
15 Full Copyright Statement 15 Full Copyright Statement
Copyright (C) The IETF Trust (2007). This document is Copyright (C) The IETF Trust (2007). This document is
subject to the rights, licenses and restrictions contained in subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain BCP 78, and except as set forth therein, the authors retain
all their rights. all their rights.
This document and the information contained herein are This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE provided on an "AS IS" basis and THE CONTRIBUTOR, THE
 End of changes. 21 change blocks. 
66 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/