draft-ietf-ips-iscsi-impl-guide-06.txt   draft-ietf-ips-iscsi-impl-guide-07.txt 
INTERNET DRAFT Mallikarjun Chadalapaka INTERNET DRAFT Mallikarjun Chadalapaka
draft-ietf-ips-iscsi-impl-guide-06.txt Hewlett-Packard Co. draft-ietf-ips-iscsi-impl-guide-07.txt Hewlett-Packard Co.
Editor Editor
Updates: RFC 3720 Updates: RFC 3720
Intended status: Proposed Standard Intended status: Proposed Standard
Expires August 2007 Expires October 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.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
The list of Internet-Draft Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html. at http://www.ietf.org/shadow.html.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as "OPTIONAL" in this document are to be interpreted as
described in [RFC2119]. described in [RFC2119].
Abstract Abstract
iSCSI is a SCSI transport protocol and maps the SCSI family iSCSI is a SCSI transport protocol and maps the SCSI
of application protocols onto TCP/IP. RFC 3720 defines the architecture and command sets onto TCP/IP. RFC 3720 defines
iSCSI protocol. This document compiles the clarifications to the iSCSI protocol. This document compiles the
the original protocol definition in RFC 3720 to serve as a clarifications to the original protocol definition in RFC
companion document for the iSCSI implementers. This document 3720 to serve as a companion document for the iSCSI
updates RFC 3720 and the text in this document supersedes the implementers. This document updates RFC 3720 and the text in
text in RFC 3720 when the two differ. this document supersedes the text in RFC 3720 when the two
differ.
Table of Contents Table of Contents
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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
6.3 Understanding NotUnderstood ...........................25 6.3 Understanding NotUnderstood ...........................25
6.4 Outstanding Negotiation Exchanges .....................26 6.4 Outstanding Negotiation Exchanges .....................26
7 iSCSI Error Handling and Recovery .....................27 7 iSCSI Error Handling and Recovery .....................27
7.1 ITT ...................................................27 7.1 ITT ...................................................27
7.2 Format Errors .........................................27 7.2 Format Errors .........................................27
7.3 Digest Errors .........................................27 7.3 Digest Errors .........................................27
7.4 Message Error Checking ................................28 7.4 Message Error Checking ................................28
8 iSCSI PDUs ............................................29 8 iSCSI PDUs ............................................29
8.1 Asynchronous Message ..................................29 8.1 Asynchronous Message ..................................29
8.2 Reject ................................................29 8.2 Reject ................................................29
9 Login/Text Operational Text Keys ......................30 9 Login/Text Operational Text Keys ......................31
9.1 TaskReporting .........................................30 9.1 TaskReporting .........................................31
10 Security Considerations ...............................32 10 Security Considerations ...............................33
11 IANA Considerations ...................................33 11 IANA Considerations ...................................34
12 References and Bibliography ...........................34 11.1 iSCSI-related IANA registries........................34
12.1 Normative References.................................34 11.2 iSCSI Opcodes........................................34
12.2 Informative References...............................34 11.3 iSCSI Login/Text Keys................................36
13 Editor's Address ......................................35 11.4 iSCSI Asynchronous Events............................38
14 Acknowledgements ......................................36 11.5 iSCSI Task Management Function Codes.................39
15 Full Copyright Statement ..............................37 11.6 iSCSI Login Response Status Codes....................40
16 Intellectual Property Statement .......................38 11.7 iSCSI Reject Reason Codes............................42
11.8 iSER Opcodes.........................................44
12 References and Bibliography ...........................45
12.1 Normative References.................................45
12.2 Informative References...............................45
13 Editor's Address ......................................46
14 Acknowledgements ......................................47
15 Full Copyright Statement ..............................48
16 Intellectual Property Statement .......................49
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 12, line 20 skipping to change at page 12, line 20
target iSCSI layer MUST perform the actions described in this target iSCSI layer MUST perform the actions described in this
section for that session.: section for that session.:
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 and dispatch is required. Standard SCSI Response PDU build and dispatch
process 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 (Nop-In PDUs MAY be used to solicit
of a Nop-In) of each such StatSN to clear the fence. SCSI acknowledgements as needed in order to accelerate this
response with the Response Fence flag must be sent to the process) of each such StatSN to clear the fence. The SCSI
initiator only after receiving acknowledgements for each of response requiring Response Fence behavior MUST NOT be sent
the unacknowledged StatSNs. to the initiator before acknowledgements are received for
each of the unacknowledged StatSNs..
c) Target iSCSI layer must wait for an acknowledgement of the c) Target iSCSI layer must wait for an acknowledgement of the
SCSI Response PDU that carried the response which the SCSI Response PDU that carried the SCSI response requiring
target SCSI layer marked with the Response Fence flag. The the Response Fence behavior. The fence MUST be considered
fence must be considered cleared after receiving the cleared only after receiving the acknowledgement.
acknowledgement.
d) All further status processing for the LU is resumed only d) All further status processing for the LU is resumed only
after clearing the fence. If any new responses for the after clearing the fence. If any new responses for the
I_T_L nexus are received from the SCSI layer before the I_T_L nexus are received from the SCSI layer before the
fence is cleared, those Response PDUs must be held and fence is cleared, those Response PDUs MUST be held and
queued at the iSCSI layer until the fence is cleared. queued at the iSCSI layer until the fence is cleared.
3.3.3 Current List of Fenced Response Use Cases 3.3.3 Current List of Fenced Response Use Cases
This section lists the fenced response use cases that iSCSI This section lists the fenced response use cases that iSCSI
implementations must comply with. However, this is not an implementations MUST comply with. However, this is not an
exhaustive enumeration. It is expected that as SCSI protocol exhaustive enumeration. It is expected that as SCSI protocol
specifications evolve, the specifications will specify when specifications evolve, the specifications will specify when
response fencing is required on a case-by-case basis. response fencing is required on a case-by-case basis.
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, target iSCSI ResponseFence or FastAbort for an iSCSI session, target iSCSI
layer MUST assume that Response Fence flag is set by the target layer MUST assume that Response Fence is required for the
SCSI layer on the following SCSI completion messages handed down following SCSI completion messages:
to it:
1. The first completion message carrying the UA after the 1. The first completion message carrying the UA after the
multi-task abort on issuing and third-party sessions. multi-task abort on issuing and third-party sessions. See
section 4.1.1 for related TMF discussion.
2. The TMF Response carrying the multi-task TMF Response on 2. The TMF Response carrying the multi-task TMF Response on
the issuing session. the issuing session.
3. The completion message indicating ACA establishment on the 3. The completion message indicating ACA establishment on the
issuing session. issuing session.
4. The first completion message carrying the ACA ACTIVE status 4. The first completion message carrying the ACA ACTIVE status
after ACA establishment on issuing and third-party after ACA establishment on issuing and third-party
sessions. sessions.
skipping to change at page 15, line 10 skipping to change at page 15, line 10
of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET
WARM RESET, and TARGET COLD RESET TMF Requests consists of the WARM RESET, and TARGET COLD RESET TMF Requests consists of the
following sequence of actions in the specified order on the following sequence of actions in the specified order on the
specified party. specified party.
The initiator iSCSI layer: The initiator iSCSI layer:
a. MUST continue to respond to each TTT received for the a. MUST continue to respond to each TTT received for the
affected tasks. affected tasks.
b. Should receive any responses that the target may provide b. SHOULD process any responses received for affected tasks in
for some tasks among the affected tasks (may process them the normal fashion. This is acceptable because the
as usual because they are guaranteed to have responses are guaranteed to have been sent prior to the TMF
chronologically originated prior to the TMF response). response.
c. Should receive the TMF Response concluding all the tasks in c. Should receive the TMF Response concluding all the tasks in
the set of affected tasks. the set of affected tasks.
The target iSCSI layer: The target iSCSI layer:
a. MUST wait for responses on currently valid target transfer a. MUST wait for responses on currently valid target transfer
tags of the affected tasks from the issuing initiator. MAY tags of the affected tasks from the issuing initiator. MAY
wait for responses on currently valid target transfer tags wait for responses on currently valid target transfer tags
of the affected tasks from third-party initiators. of the affected tasks from third-party initiators.
skipping to change at page 15, line 41 skipping to change at page 15, line 41
(i.e. TARGET WARM RESET and TARGET COLD RESET), all the (i.e. TARGET WARM RESET and TARGET COLD RESET), all the
commands that are not yet received on the issuing session commands that are not yet received on the issuing session
in the command stream however can be considered to have in the command stream however can be considered to have
been received with no command waiting period - i.e. the been received with no command waiting period - i.e. the
entire CmdSN space up to the CmdSN of the task management entire CmdSN space up to the CmdSN of the task management
function can be "plugged". function can be "plugged".
c. MUST propagate the TMF request to and receive the response c. MUST propagate the TMF request to and receive the response
from the target SCSI layer. from the target SCSI layer.
d. MUST address the Response Fence flag on the TMF Response on d. MUST provide Response Fence behavior for the TMF Response
issuing session as defined in 3.3.2. on issuing session as specified in 3.3.2.
e. MUST address the Response Fence flag on the first post-TMF e. MUST provide the Response Fence behavior on the first post-
Response on third-party sessions as defined in 3.3.2. If TMF Response on third-party sessions as specified in 3.3.2.
some tasks originate from non-iSCSI I_T_L nexuses then the If some tasks originate from non-iSCSI I_T_L nexuses then
means by which the target ensures that all affected tasks the means by which the target ensures that all affected
have returned their status to the initiator are defined by tasks have returned their status to the initiator are
the specific non-iSCSI transport protocol(s). defined by the specific non-iSCSI transport protocol(s).
Implementation note: Technically, the TMF servicing is complete Technically, the TMF servicing is complete in Step.d. Data
in Step.d. Data transfers corresponding to terminated tasks may transfers corresponding to terminated tasks may however still be
however still be in progress on third-party iSCSI sessions even in progress on third-party iSCSI sessions even at the end of
at the end of Step.e. TMF Response MUST NOT be sent by the Step.e. TMF Response MUST NOT be sent by the target iSCSI layer
target iSCSI layer before the end of Step.d, and MAY be sent at before the end of Step.d, and MAY be sent at the end of Step.d
the end of Step.d despite these outstanding data transfers until despite these outstanding data transfers until after Step.e.
after Step.e.
4.1.3 Updated multi-task abort semantics 4.1.3 Updated multi-task abort semantics
Protocol behavior defined in this section MUST be implemented by Protocol behavior defined in this section MUST be implemented by
all iSCSI implementations complying with this document. all iSCSI implementations complying with this document.
Protocol behavior defined in this section MUST be exhibited by Protocol behavior defined in this section MUST be exhibited by
iSCSI implementations on an iSCSI session when they negotiate iSCSI implementations on an iSCSI session when they negotiate
the TaskReporting (section 9.1) key to "FastAbort" on that the TaskReporting (section 9.1) key to "FastAbort" on that
session. The execution of ABORT TASK SET, CLEAR TASK SET, session. The execution of ABORT TASK SET, CLEAR TASK SET,
LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF
Requests consists of the following sequence of actions in the Requests consists of the following sequence of actions in the
specified order on the specified party. specified order on the specified party.
The initiator iSCSI layer: The initiator iSCSI layer:
a. MUST NOT send any more Data-Out PDUs for affected tasks on a. MUST NOT send any more Data-Out PDUs for affected tasks on
the issuing connection of the issuing iSCSI session once the issuing connection of the issuing iSCSI session once
the TMF is sent to the target. the TMF is sent to the target.
b. Should receive any responses that the target may provide b. SHOULD process any responses received for affected tasks in
for some tasks among the affected tasks (may process them the normal fashion. This is acceptable because the
as usual because they are guaranteed to have responses are guaranteed to have been sent prior to the TMF
chronologically originated prior to the TMF response). response.
c. MUST respond to each Async Message PDU with AsyncEvent=5 as c. MUST respond to each Async Message PDU with AsyncEvent=5 as
defined in section 8.1. defined in section 8.1.
d. Should receive the TMF Response concluding all the tasks in d. MUST treat the TMF response as terminating all affected
the set of affected tasks. tasks for which responses have not been received, and MUST
discard any responses for affected tasks received after the
TMF response is passed to the SCSI layer (although the
semantics defined in this section ensure that such an out
of order scenario will never happen with a compliant target
implementation).
The target iSCSI layer: The target iSCSI layer:
a. MUST wait for all commands of the affected tasks to be a. MUST wait for all commands of the affected tasks to be
received based on the CmdSN ordering on the issuing received based on the CmdSN ordering on the issuing
session. SHOULD NOT wait for new commands on third-party session. SHOULD NOT wait for new commands on third-party
affected sessions - only the instantiated tasks have to be affected sessions - only the instantiated tasks have to be
considered for the purpose of determining the affected considered for the purpose of determining the affected
tasks. In the case of target-scoped requests (i.e. TARGET tasks. In the case of target-scoped requests (i.e. TARGET
WARM RESET and TARGET COLD RESET), all the commands that WARM RESET and TARGET COLD RESET), all the commands that
skipping to change at page 18, line 7 skipping to change at page 18, line 10
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).
g. MUST free up the affected TTTs (and STags, if applicable) g. MUST free up the affected TTTs (and STags, if applicable)
and the corresponding buffers, if any, once it receives and the corresponding buffers, if any, once it receives
each associated Nop-Out acknowledgement that the initiator each associated Nop-Out acknowledgement that the initiator
generated in response to each Async Message. generated in response to each Async Message.
Implementation note: Technically, the TMF servicing is complete Technically, the TMF servicing is complete in Step.e. Data
in Step.e. Data transfers corresponding to terminated tasks may transfers corresponding to terminated tasks may however still be
however still be in progress even at the end of Step.f. TMF in progress even at the end of Step.f. TMF Response MUST NOT be
Response MUST NOT be sent by the target iSCSI layer before the sent by the target iSCSI layer before the end of Step.e, and MAY
end of Step.e, and MAY be sent at the end of Step.e despite be sent at the end of Step.e despite these outstanding Data
these outstanding Data transfers until Step.g. Step.g specifies transfers until Step.g. Step.g specifies an event to free up
an event to free up any such resources that may have been any such resources that may have been reserved to support
reserved to support outstanding data transfers. outstanding data transfers.
4.1.3.1 Clearing effects update 4.1.3.1 Clearing effects update
Appendix F.1 of [RFC3720] specifies the clearing effects of Appendix F.1 of [RFC3720] specifies the clearing effects of
target and LU resets on "Incomplete TTTs" as "Y". This meant target and LU resets on "Incomplete TTTs" as "Y". This meant
that a target warm reset or a target cold reset or an LU reset that a target warm reset or a target cold reset or an LU reset
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
skipping to change at page 25, line 32 skipping to change at page 25, line 32
resources to allocate and the security to enforce etc. for the resources to allocate and the security to enforce etc. for the
session. If the SessionType key is thus going to be offered as session. If the SessionType key is thus going to be offered as
"Discovery", it SHOULD be offered in the initial Login request "Discovery", it SHOULD be offered in the initial Login request
by the initiator. by the initiator.
6.3 Understanding NotUnderstood 6.3 Understanding NotUnderstood
[RFC3720] defines NotUnderstood as a valid answer during a [RFC3720] defines NotUnderstood as a valid answer during a
negotiation text key exchange between two iSCSI nodes. negotiation text key exchange between two iSCSI nodes.
NotUnderstood has the reserved meaning that the sending side did NotUnderstood has the reserved meaning that the sending side did
not understand the key semantics. This section seeks to clarify not understand the proposed key semantics. This section seeks
that NotUnderstood is a valid answer for both declarative and to clarify that NotUnderstood is a valid answer for both
negotiated keys. The general iSCSI philosophy is that declarative and negotiated keys. The general iSCSI philosophy
comprehension precedes processing for any iSCSI key. A proposer is that comprehension precedes processing for any iSCSI key. A
of an iSCSI key, negotiated or declarative, in a text key proposer of an iSCSI key, negotiated or declarative, in a text
exchange MUST thus be able to properly handle a NotUnderstood key exchange MUST thus be able to properly handle a
response. NotUnderstood response.
The proper way to handle a NotUnderstood response varies The proper way to handle a NotUnderstood response depends on
depending on the lineage and type of the key. All keys defined where the key is specified and whether the key is declarative
in [RFC3720] MUST be supported by all compliant implementations; vs. negotiated All keys defined in [RFC3720] MUST be supported
a NotUnderstood answer on any of the [RFC3720] keys therefore by all compliant implementations; a NotUnderstood answer on any
MUST be considered a protocol error and handled accordingly. of the [RFC3720] keys therefore MUST be considered a protocol
For all other later keys, a NotUnderstood answer concludes the error and handled accordingly. For all other later keys, a
negotiation for a negotiated key whereas for a declarative key, NotUnderstood answer concludes the negotiation for a negotiated
a NotUnderstood answer simply informs the declarer of lack of key whereas for a declarative key, a NotUnderstood answer simply
comprehension by the receiver. In either case, a NotUnderstood informs the declarer of lack of comprehension by the receiver.
answer always requires that the protocol behavior associated In either case, a NotUnderstood answer always requires that the
with that key be not used within the scope of the key protocol behavior associated with that key be not used within
(connection/session) by either side. the scope of the key (connection/session) by either side.
6.4 Outstanding Negotiation Exchanges 6.4 Outstanding Negotiation Exchanges
There was some uncertainty around the number of outstanding There was some uncertainty around the number of outstanding
Login Response PDUs on a connection. [RFC3720] offers the Login Response PDUs on a connection. [RFC3720] offers the
analogy of SCSI linked commands to Login and Text negotiations analogy of SCSI linked commands to Login and Text negotiations
in sections 5.3 and 10.10.3 respectively, but does not make it in sections 5.3 and 10.10.3 respectively, but does not make it
fully explicit. This section is to offer a clarification in fully explicit. This section is to offer a clarification in
this regard. this regard.
skipping to change at page 29, line 29 skipping to change at page 29, line 29
by taking the following steps in order. by taking the following steps in order.
i) Stop Data-Out transfers on that connection for all active i) Stop Data-Out transfers on that connection for all active
TTTs for the affected LUN quoted in the Async Message TTTs for the affected LUN quoted in the Async Message
PDU. PDU.
ii) Acknowledge the StatSN of the Async Message PDU via a ii) Acknowledge the StatSN of the Async Message PDU via a
Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor), Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor),
while copying the LUN field from Async Message to Nop- while copying the LUN field from Async Message to Nop-
Out. Out.
The new AsyncEvent defined in this section however MUST NOT be
used on an iSCSI session unless the new TaskReporting text key
defined in section 9.1 was negotiated to FastAbort on the
session.
8.2 Reject 8.2 Reject
Section 10.17.1 of [RFC3720] specifies the Reject reason code of Section 10.17.1 of [RFC3720] specifies the Reject reason code of
0x0b with an explanation of "Negotiation Reset". At this point, 0x0b with an explanation of "Negotiation Reset". At this point,
we do not see any legitimate iSCSI protocol use case for using we do not see any legitimate iSCSI protocol use case for using
this reason code. Thus reason code 0x0b MUST be considered as this reason code. Thus reason code 0x0b MUST be considered as
deprecated and MUST NOT be used by any new implementations. deprecated and MUST NOT be sent by implementations that
comply with the requirements of this document. An
implementation receiving reason code 0x0b MUST treat it as a
negotiation failure that terminates the Login phase and the TCP
connection, as specified in Section 6.10 of [RFC3720].
Section 5.4 of [RFC3720] states:
Neither the initiator nor the target should attempt to
declare or negotiate a parameter more than once during any
negotiation sequence without an intervening operational
parameter negotiation reset, except for responses to
specific keys that explicitly allow repeated key
declarations (e.g., TargetAddress).
The deprecation of reason code 0x0b eliminates the possibility
of an operational parameter negotiation reset, causing
the phrase "without an intervening operational
parameter negotiation reset" in [RFC3720] to refer to an
impossible event. The quoted phrase SHOULD be ignored by
receivers that handle reason code 0x0b in the manner specified
in this section.
9 Login/Text Operational Text Keys 9 Login/Text Operational Text Keys
This section follows the same conventions as section 12 of This section follows the same conventions as section 12 of
[RFC3720]. [RFC3720].
9.1 TaskReporting 9.1 TaskReporting
Use: LO Use: LO
Senders: Initiator and Target Senders: Initiator and Target
skipping to change at page 31, line 5 skipping to change at page 32, line 5
| | 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 |
| | supported. Support for Response Fence is| | | supported. Support for Response Fence is|
| | implied - i.e. section 3.3.1 semantics | | | implied - i.e. section 3.3.1 semantics |
| | MUST be supported as well | | | MUST be supported as well |
+--------------+------------------------------------------+ +--------------+------------------------------------------+
When TaskReporting is not negotiated to FastAbort, the default When TaskReporting is not negotiated to FastAbort, the [RFC3720]
behavior is to use the [RFC3720] TMF semantics as clarified in TMF semantics as clarified in section 4.1.2 MUST be used.
section 4.1.2.
10 Security Considerations 10 Security Considerations
This document does not introduce any new security considerations This document does not introduce any new security considerations
other than those already noted in [RFC3720]. Consequently, all other than those already noted in [RFC3720]. Consequently, all
the iSCSI-related security text in [RFC3723] is also directly the iSCSI-related security text in [RFC3723] is also directly
applicable to this document. applicable to this document.
11 IANA Considerations 11 IANA Considerations
This draft does not have any specific IANA considerations. 11.1 iSCSI-related IANA registries
This draft creates the following iSCSI-related registries for
IANA to manage.
1. iSCSI Opcodes
2. iSCSI Login/Text Keys
3. iSCSI Asynchronous Events
4. iSCSI Task Management Function Codes
5. iSCSI Login Response Status Codes
6. iSCSI Reject Reason Codes
7. iSCSI Authentication Mechanisms
8. iSCSI Digest Algorithms
9. iSER Opcodes
Each of the following sections describes the proposed registries
and their administration policies in more detail.
11.2 iSCSI Opcodes
Name of the registry: "iSCSI Opcodes"
Namespace details: Numerical values that can fit in one octet
with most significant two bits (bits 0 and 1) already designated
by [RFC3720], bit 0 being reserved and bit 1 for immediate
delivery. Bit 2 is designated to identify the originator of the
opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target
Information that must be provided to assign a new value: An
IESG-approved standards-track specification defining the
semantics and interoperability requirements of the proposed new
value and the fields to be recorded in the registry
Assignment policy:
1) If initiator opcode and target opcode to identify the request
and response of a new type of protocol operation are requested,
assign the same lower five bits (i.e. Bit 3 through Bit 7) for
both opcodes, e.g. 0x13 and 0x33
2) If only the initiator opcode or target opcode is requested to
identify a one-way protocol message (i.e. request without a
response or a "response" without a request), assign an unused
number from the appropriate category (i.e. Bit 2 set to 0 or 1
for initiator category or target category) and add the other
pair member (i.e. same opcode with Bit 2 set to 1 or 0,
respectively) to "Reserved to IANA" list.
3) If there are no other opcodes available to assign on a
request for a new opcode except the reserved opcodes in the
"Reserved to IANA" list, allocate the opcodes from the
appropriate category (initiator or target).
Fields to record in the registry: Assigned value, Who can
originate (Initiator or Target), Operation Name and its
associated RFC reference
Initial registry contents:
0x00, Initiator, NOP-Out, [RFC3720]
0x01, Initiator, SCSI Command, [RFC3720]
0x02, Initiator, SCSI Task Management function request,
[RFC3720]
0x03, Initiator, Login Request, [RFC3720]
0x04, Initiator, Text Request, [RFC3720]
0x05, Initiator, SCSI Data-Out, [RFC3720]
0x06, Initiator, Logout Request, [RFC3720]
0x10, Initiator, SNACK Request, [RFC3720]
0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720]
0x20, Target, NOP-In, [RFC3720]
0x21, Target, SCSI Response, [RFC3720]
0x22, Target, SCSI Task Management function response, [RFC3720]
0x23, Target, Login Response, [RFC3720]
0x24, Target, Text Response, [RFC3720]
0x25, Target, SCSI Data-In, [RFC3720]
0x26, Target, Logout Response, [RFC3720]
0x31, Target, Ready To Transfer (R2T), [RFC3720]
0x32, Target, Asynchronous Message, [RFC3720]
0x3c-0x3e, Target, Vendor specific codes, [RFC3720]
0x3f, Target, Reject, [RFC3720]
"Reserved to IANA" opcodes: 0x11, 0x12, 0x1f, 0x30
Review process:
Standards Action ([IANA])
11.3 iSCSI Login/Text Keys
Name of the registry: "iSCSI Text Keys"
Namespace details: Key=value pairs with "Key" names in UTF-8
Unicode, and the permissible "value" options for the "Key" are
Key-dependent. [RFC3720] defines the rules on key names and
allowed values
Information that must be provided to assign a new value: An
IESG-approved standards-track specification defining the
semantics and interoperability requirements of the proposed new
Key per [RFC3720] key specification template and the fields to
be recorded in the registry
Assignment policy:
If the requested Key name is not already assigned and is roughly
representative of its proposed semantics, it may be assigned to
the requester.
Fields to record in the registry: Assigned Key Name and its
associated RFC reference
Initial registry contents:
AuthMethod, [RFC3720]
HeaderDigest, [RFC3720]
DataDigest, [RFC3720]
MaxConnections, [RFC3720]
SendTargets, [RFC3720]
TargetName, [RFC3720]
InitiatorName, [RFC3720]
TargetAlias, [RFC3720]
InitiatorAlias, [RFC3720]
TargetAddress, [RFC3720]
TargetPortalGroupTag, [RFC3720]
InitialR2T, [RFC3720]
ImmediateData, [RFC3720]
MaxRecvDataSegmentLength, [RFC3720]
MaxBurstLength, [RFC3720]
FirstBurstLength, [RFC3720]
DefaultTime2Wait, [RFC3720]
DefaultTime2Retain, [RFC3720]
MaxOutstandingR2T, [RFC3720]
DataPDUInOrder, [RFC3720]
DataSequenceInOrder, [RFC3720]
ErrorRecoveryLevel, [RFC3720]
SessionType, [RFC3720]
RDMAExtensions, [iSER]
TargetRecvDataSegmentLength, [iSER]
InitiatorRecvDataSegmentLength, [iSER]
MaxOutstandingUnexpectedPDUs, [iSER]
TaskReporting, this document
Review process:
Standards Action ([IANA])
11.4 iSCSI Asynchronous Events
Name of the registry: "iSCSI Asynchronous Events"
Namespace details: Numerical values that can fit in one octet
Information that must be provided to assign a new value: A IESG-
approved standards-track specification defining the semantics
and interoperability requirements of the proposed new Event and
the fields to be recorded in the registry
Assignment policy:
If the requested value is not already assigned, it may be
assigned to the requester.
Fields to record in the registry: Assigned Event number,
Description and its associated RFC reference
Initial registry contents:
0, SCSI Async Event, [RFC3720]
1, Logout Request, [RFC3720]
2, Connection drop notification, [RFC3720]
3, Session drop notification, [RFC3720]
4, Negotiation Request, [RFC3720]
5, Task termination, this document
248-254, Vendor-unique, this document
255, Vendor-unique, [RFC3720]
Review process:
Standards Action ([IANA])
11.5 iSCSI Task Management Function Codes
Name of the registry: "iSCSI TMF Codes"
Namespace details: Numerical values that can fit in 7 bits
Information that must be provided to assign a new value: An
IESG-approved standards-track specification defining the
semantics and interoperability requirements of the proposed new
Code and the fields to be recorded in the registry
Assignment policy:
If the requested value is not already assigned, it may be
assigned to the requester.
Fields to record in the registry: Assigned Code, Description and
its associated RFC reference
Initial registry contents:
1, ABORT TASK, [RFC3720]
2, ABORT TASK SET, [RFC3720]
3, CLEAR ACA, [RFC3720]
4, CLEAR TASK SET, [RFC3720]
5, LOGICAL UNIT RESET, [RFC3720]
6, TARGET WARM RESET, [RFC3720]
7, TARGET COLD RESET, [RFC3720]
8, TASK REASSIGN, [RFC3720]
Review process:
Standards Action ([IANA])
11.6 iSCSI Login Response Status Codes
Name of the registry: "iSCSI Login Response Status Codes"
Namespace details: Numerical values; Status-Class (one octet),
Status-Detail (one octet) for each possible value of Status-
Class except for Vendor-Unique Status-Class (0x0f)
Information that must be provided to assign a new value: An
IESG-approved specification defining the semantics and
interoperability requirements of the proposed new Code, its
Status-Class affiliation (only if a new Status-Detail value is
being proposed for a Status-Class), Status-Class definition
(only if a new Status-Class is being proposed) and the fields to
be recorded in the registry
Assignment policy:
If the requested value is not already assigned, it may be
assigned to the requester.
Fields to record in the Status-Class main registry: Assigned
Code, Description and its associated RFC reference
Fields to record in the Status-Detail sub-registries: Status-
Class, Assigned Code, Description and its associated RFC
reference
Initial registry contents (Status-Class):
0x00, Success, [RFC3720]
0x01, Redirection, [RFC3720]
0x02, Initiator Error, [RFC3720]
0x03, Target Error, [RFC3720]
0x0f, Vendor-Unique, this document
Initial sub-registry contents (Status-Detail for Status-
Class=0x00):
0x00, 0x00, Success, [RFC3720]
Initial sub-registry contents (Status-Detail for Status-
Class=0x01):
0x01, 0x01, Temporary move, [RFC3720]
0x01, 0x02, Permanent move, [RFC3720]
Initial sub-registry contents (Status-Detail for Status-
Class=0x02):
0x02, 0x00, Miscellaneous, [RFC3720]
0x02, 0x01, Authentication failure, [RFC3720]
0x02, 0x02, Authorization failure, [RFC3720]
0x02, 0x03, Not found, [RFC3720]
0x02, 0x04, Target removed, [RFC3720]
0x02, 0x05, Unsupported version, [RFC3720]
0x02, 0x06, Too many connections, [RFC3720]
0x02, 0x07, Missing parameter, [RFC3720]
0x02, 0x08, Can't include in session, [RFC3720]
0x02, 0x09, Unsupported session type, [RFC3720]
0x02, 0x0a, Non-existent session, [RFC3720]
0x02, 0x0b, Invalid during login, [RFC3720]
Initial sub-registry contents (Status-Detail for Status-
Class=0x03):
0x03, 0x00, Target error, [RFC3720]
0x03, 0x01, Service unavailable, [RFC3720]
0x03, 0x02, Out of resources, [RFC3720]
Review process:
Standards Action ([IANA])
11.7 iSCSI Reject Reason Codes
Name of the registry: "iSCSI Reject Reason Codes"
Namespace details: Numerical values that can fit in a single
octet
Information that must be provided to assign a new value: A
published specification defining the semantics and
interoperability requirements of the proposed new Code and the
fields to be recorded in the registry
Assignment policy:
If the requested value is not already assigned, it may be
assigned to the requester.
Fields to record in the registry: Assigned Code, Description and
its associated RFC reference
Initial registry contents:
0x01, Reserved, [RFC3720]
0x02, Data digest error, [RFC3720]
0x03, SNACK Reject, [RFC3720]
0x04, Protocol Error, [RFC3720]
0x05, Command not supported, [RFC3720]
0x06, Immediate command reject, [RFC3720]
0x07, Task in progress, [RFC3720]
0x08, Invalid data ack, [RFC3720]
0x09, Invalid PDU field, [RFC3720]
0x0a, Long op reject, [RFC3720]
0x0b, "Deprecated reason code", this document
0x0c, Waiting for Logout, [RFC3720]
Review process:
Standards Action ([IANA])
11.8 iSER Opcodes
Name of the registry: "iSER Opcodes"
Namespace details: Numerical values that can fit in 4 bits
Information that must be provided to assign a new value: An
IESG-approved specification defining the semantics and
interoperability requirements of the proposed new value and the
fields to be recorded in the registry
Assignment policy:
If the requested value is not already assigned, it may be
assigned to the requester.
Fields to record in the registry: Assigned value, Operation Name
and its associated RFC reference
Initial registry contents:
0x1, iSCSI control-type, [iSER]
0x2, iSER Hello, [iSER]
0x3, iSER HelloReply, [iSER]
Review process:
Standards Action ([IANA])
12 References and Bibliography 12 References and Bibliography
12.1 Normative References 12.1 Normative References
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka,
M., and E. Zeidner, "Internet Small Computer Systems M., and E. Zeidner, "Internet Small Computer Systems
Interface (iSCSI)", RFC 3720, April 2004. Interface (iSCSI)", RFC 3720, April 2004.
[SPC3] T10/1416-D, SCSI Primary Commands-3. [SPC3] ANSI INCITS 408-2005, SCSI Primary Commands-3.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[IANA] Alvestrand, H. and T. Narten, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler,
P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet
Draft draft-ietf-ips-iser-04.txt (work in progress), June
2005.
12.2 Informative References 12.2 Informative References
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K.,
and M. Krueger, "Internet Small Computer Systems Interface and M. Krueger, "Internet Small Computer Systems Interface
(iSCSI) Naming and Discovery", RFC 3721, April 2004. (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and
F. Travostino, "Securing Block Storage Protocols over IP", F. Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004. RFC 3723, April 2004.
[RFC3722] Bakke, M., "String Profile for Internet Small [RFC3722] Bakke, M., "String Profile for Internet Small
Computer Systems Interface (iSCSI) Names", RFC 3722, April Computer Systems Interface (iSCSI) Names", RFC 3722, April
2004. 2004.
[iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler,
P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet
Draft draft-ietf-ips-iser-04.txt (work in progress), June
2005.
[RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM- [SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-
2). 2).
[SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM- [SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-
3). 3).
[SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM- [SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-
skipping to change at page 36, line 15 skipping to change at page 47, line 15
14 Acknowledgements 14 Acknowledgements
The IP Storage (ips) Working Group in the Transport Area of The IP Storage (ips) Working Group in the Transport Area of
IETF has been responsible for defining the iSCSI protocol IETF has been responsible for defining the iSCSI protocol
(apart from a host of other relevant IP Storage protocols). (apart from a host of other relevant IP Storage protocols).
The editor acknowledges the contributions of the entire The editor acknowledges the contributions of the entire
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, Gwendal Grignou,
semantics, ACA semantics, TMF semantics), Gwendal Grignou Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob
(TMF scope), Mike Ko (digest error handling for Asynchronous Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh
Message), Dmitry Fomichev (reserved ITT), Bill Studenmund Gupta, Eddy Quicksall, Paul Koning. This document benefited
(residual handling, discovery semantics), Ken Sandars from all these contributions.
(discovery semantics), Bob Russell (discovery semantics),
Julian Satran (discovery semantics, TMF semantics), Rob
Elliott (T10 liaison, R2T ordering), Joseph Pittman(TMF
scope), Somesh Gupta (multi-task abort semantics), Eddy
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. 28 change blocks. 
110 lines changed or deleted 598 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/