< draft-ietf-ips-iscsi-impl-guide-08.txt   draft-ietf-ips-iscsi-impl-guide-09.txt >
INTERNET DRAFT Mallikarjun Chadalapaka
INTERNET DRAFT Mallikarjun Chadalapaka draft-ietf-ips-iscsi-impl-guide-09.txt Hewlett-Packard Co.
draft-ietf-ips-iscsi-impl-guide-08.txt Hewlett-Packard Co. Editor
Editor
Updates: RFC 3720 Updates: RFC 3720
Intended status: Proposed Standard Intended status: Proposed Standard
Expires Expires December 2007
November 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
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other Internet-Drafts as reference material or to cite them other
than as "work in progress." than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 iSCSI is a SCSI transport protocol and maps the SCSI
architecture and command sets onto TCP/IP. RFC 3720 defines architecture and command sets onto TCP/IP. RFC 3720 defines
the iSCSI protocol. This document compiles the the iSCSI protocol. This document compiles the
clarifications to the original protocol definition in RFC clarifications to the original protocol definition in RFC
3720 to serve as a companion document for the iSCSI 3720 to serve as a companion document for the iSCSI
implementers. This document updates RFC 3720 and the text in implementers. This document updates RFC 3720 and the text in
this document supersedes the text in RFC 3720 when the two this document supersedes the text in RFC 3720 when the two
differ. differ.
Table of Contents Table of Contents
1 Definitions and acronyms ...............................5 1 Definitions, Acronyms and Document Summary............. 5
1.1 Definitions ............................................5 1.1 Definitions............................................ 5
1.2 Acronyms ...............................................5 1.2 Acronyms............................................... 5
2 Introduction ...........................................7 1.3 Clarifications, Changes and New Semantics.............. 6
3 iSCSI semantics for SCSI tasks .........................8 2 Introduction........................................... 9
3.1 Residual handling ......................................8 3 iSCSI semantics for SCSI tasks........................ 10
3.1.1 Overview..............................................8 3.1 Residual handling..................................... 10
3.1.2 SCSI REPORT LUNS and Residual Overflow................9 3.1.1 Overview ............................................ 10
3.2 R2T Ordering ..........................................10 3.1.2 SCSI REPORT LUNS and Residual Overflow .............. 11
3.3 Model Assumptions for Response Ordering ...............11 3.2 R2T Ordering.......................................... 12
3.3.1 Model Description....................................11 3.3 Model Assumptions for Response Ordering............... 13
3.3.2 iSCSI Semantics with the Interface Model.............12 3.3.1 Model Description ................................... 13
3.3.3 Current List of Fenced Response Use Cases............12 3.3.2 iSCSI Semantics with the Interface Model ............ 14
4 Task Management .......................................14 3.3.3 Current List of Fenced Response Use Cases ........... 14
4.1 Requests Affecting Multiple Tasks .....................14 4 Task Management....................................... 16
4.1.1 Scope of affected tasks..............................14 4.1 Requests Affecting Multiple Tasks..................... 16
4.1.2 Clarified multi-task abort semantics.................14 4.1.1 Scope of affected tasks ............................. 16
4.1.3 Updated multi-task abort semantics...................16 4.1.2 Clarified multi-task abort semantics ................ 16
4.1.4 Affected tasks shared across RFC3720 & FastAbort 4.1.3 Updated multi-task abort semantics .................. 18
sessions....................................................18 4.1.4 Affected tasks shared across RFC3720 & FastAbort
4.1.5 Implementation considerations........................19 sessions ................................................... 20
4.1.6 Rationale behind the new semantics...................20 4.1.5 Implementation considerations ....................... 21
5 Discovery semantics ...................................22 4.1.6 Rationale behind the new semantics .................. 22
5.1 Error Recovery for Discovery Sessions .................22 5 Discovery semantics................................... 24
5.2 Reinstatement Semantics of Discovery Sessions .........22 5.1 Error Recovery for Discovery Sessions................. 24
5.2.1 Unnamed Discovery Sessions...........................23 5.2 Reinstatement Semantics of Discovery Sessions......... 24
5.2.2 Named Discovery Sessions.............................23 5.2.1 Unnamed Discovery Sessions .......................... 25
5.3 Target PDUs during Discovery ..........................24 5.2.2 Named Discovery Sessions ............................ 25
6 Negotiation and Others ................................25 5.3 Target PDUs during Discovery.......................... 26
6.1 TPGT Values ...........................................25 6 Negotiation and Others................................ 27
6.2 SessionType Negotiation ...............................25 6.1 TPGT Values........................................... 27
6.3 Understanding NotUnderstood ...........................25 6.2 SessionType Negotiation............................... 27
6.4 Outstanding Negotiation Exchanges .....................26 6.3 Understanding NotUnderstood........................... 27
7 iSCSI Error Handling and Recovery .....................27 6.4 Outstanding Negotiation Exchanges..................... 28
7.1 ITT ...................................................27 7 iSCSI Error Handling and Recovery..................... 29
7.2 Format Errors .........................................27 7.1 ITT................................................... 29
7.3 Digest Errors .........................................27 7.2 Format Errors......................................... 29
7.4 Message Error Checking ................................28 7.3 Digest Errors......................................... 29
8 iSCSI PDUs ............................................29 7.4 Message Error Checking................................ 30
8.1 Asynchronous Message ..................................29 8 iSCSI PDUs............................................ 31
8.2 Reject ................................................29 8.1 Asynchronous Message.................................. 31
9 Login/Text Operational Text Keys ......................31 8.2 Reject................................................ 31
9.1 TaskReporting .........................................31 9 Login/Text Operational Text Keys...................... 33
10 Security Considerations ...............................33 9.1 TaskReporting......................................... 33
11 IANA Considerations ...................................34 10 Security Considerations............................... 35
11.1 iSCSI-related IANA registries........................34 11 IANA Considerations................................... 36
11.2 iSCSI Opcodes........................................34 11.1 iSCSI-related IANA registries ....................... 36
11.3 iSCSI Login/Text Keys................................37 11.2 iSCSI Opcodes ....................................... 36
11.4 iSCSI Asynchronous Events............................39 11.3 iSCSI Login/Text Keys ............................... 39
11.5 iSCSI Task Management Function Codes.................40 11.4 iSCSI Asynchronous Events ........................... 41
11.6 iSCSI Login Response Status Codes....................41 11.5 iSCSI Task Management Function Codes ................ 42
11.7 iSCSI Reject Reason Codes............................43 11.6 iSCSI Login Response Status Codes ................... 43
11.8 iSER Opcodes.........................................45 11.7 iSCSI Reject Reason Codes ........................... 45
12 References and Bibliography ...........................46 11.8 iSER Opcodes ........................................ 47
12.1 Normative References.................................46 12 References and Bibliography........................... 49
12.2 Informative References...............................46 12.1 Normative References ................................ 49
13 Editor's Address ......................................47 12.2 Informative References .............................. 49
14 Acknowledgements ......................................48 13 Editor's Address...................................... 50
15 Full Copyright Statement ..............................49 14 Acknowledgements...................................... 51
16 Intellectual Property Statement .......................50 15 Full Copyright Statement.............................. 52
16 Intellectual Property Statement....................... 53
1 Definitions and acronyms 1 Definitions, Acronyms and Document Summary
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.
SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the
aggregate data length of the data that SCSI layer aggregate data length of the data that SCSI layer
logically "presents" to iSCSI layer for a Data-in or logically "presents" to iSCSI layer for a Data-in or
Data-out transfer in the context of a SCSI task. For a Data-out transfer in the context of a SCSI task. For a
bidirectional task, there are two SPDTL values - one for bidirectional task, there are two SPDTL values - one for
Data-in and one for Data-out. Note that the notion of Data-in and one for Data-out. Note that the notion of
"presenting" includes immediate data per the data "presenting" includes immediate data per the data
transfer model in [SAM2], and excludes overlapping data transfer model in [SAM2], and excludes overlapping data
transfers, if any, requested by the SCSI layer. transfers, if any, requested by the SCSI layer.
Third-party: A term used in this document to denote nexus Third-party: A term used in this document to denote nexus
objects (I_T or I_T_L) and iSCSI sessions which reap the objects (I_T or I_T_L) and iSCSI sessions which reap the
side-effects of actions that take place in the context of side-effects of actions that take place in the context of
a separate iSCSI session, while being third parties to a separate iSCSI session, while being third parties to
the action that caused the side-effects. One example of the action that caused the side-effects. One example of
a Third-party session is an iSCSI session hosting an a Third-party session is an iSCSI session hosting an
I_T_L nexus to an LU that is reset with an LU Reset TMF I_T_L nexus to an LU that is reset with an LU Reset TMF
via a separate I_T nexus. via a separate I_T nexus.
1.2 Acronyms 1.2 Acronyms
Acronym Definition Acronym Definition
------------------------------------------------------------- -------------------------------------------------------------
EDTL Expected Data Transfer Length EDTL Expected Data Transfer Length
IANA Internet Assigned Numbers Authority IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force IETF Internet Engineering Task Force
I/O Input - Output I/O Input - Output
IP Internet Protocol IP Internet Protocol
iSCSI Internet SCSI iSCSI Internet SCSI
iSER iSCSI Extensions for RDMA iSER iSCSI Extensions for RDMA
ITT Initiator Task Tag ITT Initiator Task Tag
LO Leading Only LO Leading Only
LU Logical Unit LU Logical Unit
LUN Logical Unit Number LUN Logical Unit Number
PDU Protocol Data Unit PDU Protocol Data Unit
RDMA Remote Direct Memory Access RDMA Remote Direct Memory Access
R2T Ready To Transfer R2T Ready To Transfer
R2TSN Ready To Transfer Sequence Number R2TSN Ready To Transfer Sequence Number
RFC Request For Comments RFC Request For Comments
SAM SCSI Architecture Model SAM SCSI Architecture Model
SCSI Small Computer Systems Interface SCSI Small Computer Systems Interface
SN Sequence Number SN Sequence Number
SNACK Selective Negative Acknowledgment - also SNACK Selective Negative Acknowledgment - also
Sequence Number Acknowledgement for data Sequence Number Acknowledgement for data
TCP Transmission Control Protocol TCP Transmission Control Protocol
TMF Task Management Function TMF Task Management Function
TTT Target Transfer Tag TTT Target Transfer Tag
UA Unit Attention UA Unit Attention
2 Introduction 1.3 Clarifications, Changes and New Semantics
Several iSCSI implementations had been built after [RFC3720] was This document specifies certain changes to [RFC3720] semantics
published and the iSCSI community is now richer by the resulting as well as defines new iSCSI semantics. In addition, this
implementation expertise. The goal of this document is to document also clarifies the [RFC3720] semantics. This section
leverage this expertise both to offer clarifications to the summarizes the contents of the document, categorizing each
[RFC3720] semantics and to address defects in [RFC3720] as section into one or more of a Clarification, a Change or a New
appropriate. This document intends to offer critical guidance Semantic.
to implementers with regard to non-obvious iSCSI implementation
aspects so as to improve interoperability and accelerate iSCSI
adoption. This document, however, does not purport to be an
all-encompassing iSCSI how-to guide for implementers, nor a
complete revision of [RFC3720]. This document instead is
intended as a companion document to [RFC3720] for the iSCSI
implementers.
iSCSI implementers are required to reference [RFC3722] and Section 3.1.1: Clarification on iSCSI residuals computation
[RFC3723] in addition to [RFC3720] for mandatory requirements. general principles
In addition, [RFC3721] also contains useful information for
iSCSI implementers. The text in this document, however, updates
and supersedes the text in [RFC3720] whenever there is such a
question.
3 iSCSI semantics for SCSI tasks Section 3.1.2: Clarification on iSCSI residuals computation
with an example
3.1 Residual handling Section 3.2: Clarification on R2T ordering requirements
Section 3.3: New Semantics for Response Ordering in multi-
connection iSCSI sessions
Section 4.1.2: Clarifications, Changes and New Semantics on
multi-task abort semantics that all implementations must
comply with
Section 4.1.3: Changes and New Semantics (FastAbort
semantics) on multi-task abort semantics that
implementations should use for faster error recovery
Section 4.1.3.1: Changes in iSCSI Clearing effects semantics
resulting out of new FastAbort semantics
Section 4.1.4: New Semantics on third-party session
interactions with the new FastAbort semantics
Section 4.1.5: Clarification on implementation considerations
related to outstanding data transfers in order to realize
right iSCSI protocol behavior
Section 4.1.6: Clarification on the intent behind FastAbort
semantics (not clarifications to [RFC3720] semantics)
Section 5.1: Clarification on error recovery semantics as
applicable to Discovery sessions
Section 5.2.1: Clarification and New Semantics on applying
ISID RULE ([RFC3720]) to Unnamed Discovery Sessions
Section 5.2.2: Clarification on applying ISID RULE to Named
Discovery Sessions
Section 5.3: Clarification on allowed PDU types and target
Logout notification behavior on a Discovery session
Section 6.1: Clarification on the legality of TPGT value of
zero
Section 6.2: Clarification on the negotiating order of
SessionType with respect to other keys
Section 6.3: Clarification on NotUnderstood negotiation
response on declarative keys and the implied semantics
Section 6.4: Clarification on the number of legal outstanding
negotiation PDUs (Text or Login-related)
Section 7.1: Clarification on usage of ITT value of
0xffffffff
Section 7.2: Clarification on what constitute format errors
for the purpose of error recovery defined in [RFC3720]
Section 7.3: Change in error recovery semantics for the case
of discarding unsolicited PDUs
Section 7.4: Clarification on the intended level of error
checking on inbound PDUs
Section 8.1: New Semantics for a new AsyncEvent code
Section 8.2: Change of legal status for Reject reason code
0x0b, it is now deprecated
Section 9.1: New Semantics for a new text key TaskReporting
2 Introduction
Several iSCSI implementations had been built after [RFC3720] was
published and the iSCSI community is now richer by the resulting
implementation expertise. The goal of this document is to
leverage this expertise both to offer clarifications to the
[RFC3720] semantics and to address defects in [RFC3720] as
appropriate. This document intends to offer critical guidance
to implementers with regard to non-obvious iSCSI implementation
aspects so as to improve interoperability and accelerate iSCSI
adoption. This document, however, does not purport to be an
all-encompassing iSCSI how-to guide for implementers, nor a
complete revision of [RFC3720]. This document instead is
intended as a companion document to [RFC3720] for the iSCSI
implementers.
iSCSI implementers are required to reference [RFC3722] and
[RFC3723] in addition to [RFC3720] for mandatory requirements.
In addition, [RFC3721] also contains useful information for
iSCSI implementers. The text in this document, however, updates
and supersedes the text in [RFC3720] whenever there is such a
question.
3 iSCSI semantics for SCSI tasks
3.1 Residual handling
Section 10.4.1 of [RFC3720] defines the notion of "residuals" Section 10.4.1 of [RFC3720] defines the notion of "residuals"
and specifies how the residual information should be encoded and specifies how the residual information should be encoded
into the SCSI Response PDU in Counts and Flags fields. Section into the SCSI Response PDU in Counts and Flags fields. Section
3.1.1 clarifies the intent of [RFC3720] and explains the general 3.1.1 clarifies the intent of [RFC3720] and explains the general
principles. Section 3.1.2 describes the residual handling in principles. Section 3.1.2 describes the residual handling in
the REPORT LUNS scenario. the REPORT LUNS scenario.
3.1.1 Overview 3.1.1 Overview
SCSI-Presented Data Transfer Length (SPDTL) is the term this SCSI-Presented Data Transfer Length (SPDTL) is the term this
document uses (see section 1.1 for definition) to represent the document uses (see section 1.1 for definition) to represent the
aggregate data length that the target SCSI layer attempts to aggregate data length that the target SCSI layer attempts to
transfer using the local iSCSI layer for a task. Expected Data transfer using the local iSCSI layer for a task. Expected Data
Transfer Length (EDTL) is the iSCSI term that represents the Transfer Length (EDTL) is the iSCSI term that represents the
length of data that the iSCSI layer expects to transfer for a length of data that the iSCSI layer expects to transfer for a
task. EDTL is specified in the SCSI Command PDU. task. EDTL is specified in the SCSI Command PDU.
When SPDTL = EDTL for a task, the target iSCSI layer completes When SPDTL = EDTL for a task, the target iSCSI layer completes
the task with no residuals. Whenever SPDTL differs from EDTL the task with no residuals. Whenever SPDTL differs from EDTL
for a task, that task is said to have a residual. for a task, that task is said to have a residual.
If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in
the SCSI Response PDU as specified in [RFC3720]. Residual Count the SCSI Response PDU as specified in [RFC3720]. Residual Count
MUST be set to the numerical value of (SPDTL - EDTL). MUST be set to the numerical value of (SPDTL - EDTL).
If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in
the SCSI Response PDU as specified in [RFC3720]. Residual Count the SCSI Response PDU as specified in [RFC3720]. Residual Count
MUST be set to the numerical value of (EDTL - SPDTL). MUST be set to the numerical value of (EDTL - SPDTL).
Note that the Overflow and Underflow scenarios are independent Note that the Overflow and Underflow scenarios are independent
of Data-in and Data-out. Either scenario is logically possible of Data-in and Data-out. Either scenario is logically possible
in either direction of data transfer. in either direction of data transfer.
3.1.2 SCSI REPORT LUNS and Residual Overflow 3.1.2 SCSI REPORT LUNS and Residual Overflow
This section discusses the residual overflow issues citing the This section discusses the residual overflow issues citing the
example of SCSI REPORT LUNS command. Note however that there example of SCSI REPORT LUNS command. Note however that there
are several SCSI commands (e.g. INQUIRY) with ALLOCATION LENGTH are several SCSI commands (e.g. INQUIRY) with ALLOCATION LENGTH
fields following the same underlying rules. The semantics in fields following the same underlying rules. The semantics in
the rest of the section apply to all such SCSI commands. the rest of the section apply to all such SCSI commands.
The specification of the SCSI REPORT LUNS command requires that The specification of the SCSI REPORT LUNS command requires that
the SCSI target limit the amount of data transferred to a the SCSI target limit the amount of data transferred to a
maximum size (ALLOCATION LENGTH) provided by the initiator in maximum size (ALLOCATION LENGTH) provided by the initiator in
skipping to change at page 10, line 18 skipping to change at page 12, line 18
For a REPORT LUNS command, if the iSCSI EDTL is at least as For a REPORT LUNS command, if the iSCSI EDTL is at least as
large as the ALLOCATION LENGTH, the SCSI truncation ensures that large as the ALLOCATION LENGTH, the SCSI truncation ensures that
the EDTL will accommodate all of the data to be transferred. If the EDTL will accommodate all of the data to be transferred. If
all of the logical unit inventory data presented to the iSCSI all of the logical unit inventory data presented to the iSCSI
layer - i.e. the data remaining after any SCSI truncation - is layer - i.e. the data remaining after any SCSI truncation - is
transferred to the initiator by the iSCSI layer, an iSCSI transferred to the initiator by the iSCSI layer, an iSCSI
Residual Overflow has not occurred and the iSCSI (O) bit MUST Residual Overflow has not occurred and the iSCSI (O) bit MUST
NOT be set in the SCSI Response or final SCSI Data-Out PDU. NOT be set in the SCSI Response or final SCSI Data-Out PDU.
This is not a new requirement but is already required by the This is not a new requirement but is already required by the
combination of [RFC3720] with the specification of the REPORT combination of [RFC3720] with the specification of the REPORT
LUNS command in [SPC3]. If the iSCSI EDTL is larger than the LUNS command in [SPC3]. If the iSCSI EDTL is larger than the
ALLOCATION LENGTH however in this scenario, note that the iSCSI ALLOCATION LENGTH however in this scenario, note that the iSCSI
Underflow MUST be signaled in the SCSI Response PDU. An iSCSI Underflow MUST be signaled in the SCSI Response PDU. An iSCSI
Underflow MUST also be signaled when the iSCSI EDTL is equal to Underflow MUST also be signaled when the iSCSI EDTL is equal to
ALLOCATION LENGTH but the logical unit inventory data presented ALLOCATION LENGTH but the logical unit inventory data presented
to the iSCSI layer is smaller than ALLOCATION LENGTH. to the iSCSI layer is smaller than ALLOCATION LENGTH.
The LUN LIST LENGTH field in the logical unit inventory (first The LUN LIST LENGTH field in the logical unit inventory (first
field in the inventory) is not affected by truncation of the field in the inventory) is not affected by truncation of the
inventory to fit in ALLOCATION LENGTH; this enables a SCSI inventory to fit in ALLOCATION LENGTH; this enables a SCSI
initiator to determine that the received inventory is incomplete initiator to determine that the received inventory is incomplete
by noticing that the LUN LIST LENGTH in the inventory is larger by noticing that the LUN LIST LENGTH in the inventory is larger
than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB.
A common initiator behavior in this situation is to re-issue the A common initiator behavior in this situation is to re-issue the
REPORT LUNS command with a larger ALLOCATION LENGTH. REPORT LUNS command with a larger ALLOCATION LENGTH.
3.2 R2T Ordering 3.2 R2T Ordering
Section 10.8 in [RFC3720] says the following: Section 10.8 in [RFC3720] says the following:
The target may send several R2T PDUs. It, therefore, can have The target may send several R2T PDUs. It, therefore, can have
a number of pending data transfers. The number of outstanding a number of pending data transfers. The number of outstanding
R2T PDUs are limited by the value of the negotiated key R2T PDUs is limited by the value of the negotiated key
MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST
be fulfilled by the initiator in the order in which they were be fulfilled by the initiator in the order in which they were
received. received.
The quoted [RFC3720] text was unclear on the scope of The quoted [RFC3720] text was unclear on the scope of
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 Model Assumptions 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 some ordering is desired by the SCSI layer, the following
"Response Fence" semantics are defined with respect to handling "Response Fence" semantics are defined with respect to handling
SCSI response messages as they are handed off from the SCSI SCSI response messages as they are handed off from the SCSI
protocol layer to the iSCSI layer. protocol layer to the iSCSI layer.
3.3.1 Model Description 3.3.1 Model Description
Target SCSI protocol layer hands off the SCSI response messages Target SCSI protocol layer hands off the SCSI response messages
to the target iSCSI layer by invoking the "Send Command to the target iSCSI layer by invoking the "Send Command
Complete" protocol data service ([SAM2], clause 5.4.2) and "Task Complete" protocol data service ([SAM2], clause 5.4.2) and "Task
Management Function Executed" ([SAM2], clause 6.9) service. On Management Function Executed" ([SAM2], clause 6.9) service. On
receiving the SCSI response message, iSCSI layer exhibits the receiving the SCSI response message, iSCSI layer exhibits the
Response Fence behavior for certain SCSI response messages Response Fence behavior for certain SCSI response messages
(section 3.3.3 describes the specific instances where the (section 3.3.3 describes the specific instances where the
semantics must be realized). Whenever the Response Fence semantics must be realized). Whenever the Response Fence
behavior is required for a SCSI response message, the target behavior is required for a SCSI response message, the target
iSCSI layer MUST ensure that the following conditions are met in iSCSI layer MUST ensure that the following conditions are met in
delivering the response message to the initiator iSCSI layer: 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 initiator iSCSI layer. 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 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 and the Response ResponseFence or FastAbort for an iSCSI session and the Response
Fence behavior is required for a SCSI response message, the Fence behavior is required for a SCSI response message, the
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 (Nop-In PDUs MAY be used to solicit acknowledgement (Nop-In PDUs MAY be used to solicit
acknowledgements as needed in order to accelerate this acknowledgements as needed in order to accelerate this
process) of each such StatSN to clear the fence. The SCSI process) of each such StatSN to clear the fence. The SCSI
response requiring Response Fence behavior MUST NOT be sent response requiring Response Fence behavior MUST NOT be sent
to the initiator before acknowledgements are received for to the initiator before acknowledgements are received for
each of the unacknowledged StatSNs.. 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 SCSI response requiring SCSI Response PDU that carried the SCSI response requiring
the Response Fence behavior. The fence MUST be considered the Response Fence behavior. The fence MUST be considered
cleared only after receiving the acknowledgement. cleared only after receiving the 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 is required for the layer MUST assume that Response Fence is required for the
following SCSI completion messages: following SCSI completion messages:
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. See multi-task abort on issuing and third-party sessions. See
section 4.1.1 for related TMF discussion. 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.
5. The TMF Response carrying the Clear ACA response on the 5. The TMF Response carrying the Clear ACA response on the
issuing session. issuing session.
6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT
command command
Note: Due to the absence of ACA-related fencing requirements in Note: Due to the absence of ACA-related fencing requirements in
[RFC3720], initiator implementations SHOULD NOT use ACA on [RFC3720], initiator implementations SHOULD NOT use ACA on
multi-connection iSCSI sessions to targets complying only with multi-connection iSCSI sessions to targets complying only with
[RFC3720]. Initiators which want to employ ACA on multi- [RFC3720]. Initiators which want to employ ACA on multi-
connection iSCSI sessions SHOULD first assess response fencing connection iSCSI sessions SHOULD first assess response fencing
behavior via negotiating for ResponseFence or FastAbort values behavior via negotiating for ResponseFence or FastAbort values
for the TaskReporting (section 9.1) key. for the TaskReporting (section 9.1) key.
4 Task Management 4 Task Management
4.1 Requests Affecting Multiple Tasks 4.1 Requests Affecting Multiple Tasks
This section clarifies and updates the original text in section This section clarifies and updates the original text in section
10.6.2 of [RFC3720]. The clarified semantics (section 4.1.2) 10.6.2 of [RFC3720]. The clarified semantics (section 4.1.2)
are a superset of the protocol behavior required in the original are a superset of the protocol behavior required in the original
text and all iSCSI implementations MUST support the new text and all iSCSI implementations MUST support the new
behavior. The updated semantics (section 4.1.3) on the other behavior. The updated semantics (section 4.1.3) on the other
hand are mandatory only when the new key TaskReporting (section hand are mandatory only when the new key TaskReporting (section
9.1) is negotiated to "FastAbort". 9.1) is negotiated to "FastAbort".
4.1.1 Scope of affected tasks 4.1.1 Scope of affected tasks
This section defines the notion of "affected tasks" in multi- This section defines the notion of "affected tasks" in multi-
task abort scenarios. Scope definitions in this section apply task abort scenarios. Scope definitions in this section apply
to both the clarified protocol behavior (section 4.1.2) and the to both the clarified protocol behavior (section 4.1.2) and the
updated protocol behavior (section 4.1.3). updated protocol behavior (section 4.1.3).
ABORT TASK SET: All outstanding tasks for the I_T_L nexus ABORT TASK SET: All outstanding tasks for the I_T_L nexus
identified by the LUN field in the ABORT TASK SET TMF identified by the LUN field in the ABORT TASK SET TMF
Request PDU. Request PDU.
CLEAR TASK SET: All outstanding tasks in the task set for CLEAR TASK SET: All outstanding tasks in the task set for
the LU identified by the LUN field in the CLEAR TASK SET the LU identified by the LUN field in the CLEAR TASK SET
TMF Request PDU. See [SPC3] for the definition of a "task TMF Request PDU. See [SPC3] for the definition of a "task
set". set".
LOGICAL UNIT RESET: All outstanding tasks from all LOGICAL UNIT RESET: All outstanding tasks from all
initiators for the LU identified by the LUN field in the initiators for the LU identified by the LUN field in the
LOGICAL UNIT RESET Request PDU. LOGICAL UNIT RESET Request PDU.
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks
from all initiators across all LUs to which the TMF-issuing from all initiators across all LUs to which the TMF-issuing
session has access to on the SCSI target device hosting the session has access to on the SCSI target device hosting the
iSCSI session. iSCSI session.
Usage: an "ABORT TASK SET TMF Request PDU" in the preceding text Usage: an "ABORT TASK SET TMF Request PDU" in the preceding text
is an iSCSI TMF Request PDU with the "Function" field set to is an iSCSI TMF Request PDU with the "Function" field set to
"ABORT TASK SET" as defined in [RFC3720]. Similar usage is "ABORT TASK SET" as defined in [RFC3720]. Similar usage is
employed for other scope descriptions. employed for other scope descriptions.
4.1.2 Clarified multi-task abort semantics 4.1.2 Clarified multi-task abort semantics
All iSCSI implementations MUST support the protocol behavior All iSCSI implementations MUST support the protocol behavior
defined in this section as the default behavior. The execution defined in this section as the default behavior. The execution
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 process any responses received for affected tasks in b. SHOULD process any responses received for affected tasks in
the normal fashion. This is acceptable because the the normal fashion. This is acceptable because the
responses are guaranteed to have been sent prior to the TMF responses are guaranteed to have been sent 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 unless the initiator has done
something (e.g.,LU reset, connection drop) that may prevent
the TMF Response from being sent or received. The
initiator MUST thus conclude all affected tasks as part of
this step in either case, and MUST discard any TMF Response
received after the affected tasks are concluded.
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.
b. MUST wait (concurrent with the wait in Step.a) for all b. MUST wait (concurrent with the wait in Step.a) for all
commands of the affected tasks to be received based on the commands of the affected tasks to be received based on the
CmdSN ordering. SHOULD NOT wait for new commands on CmdSN ordering. SHOULD NOT wait for new commands on
third-party affected sessions - only the instantiated tasks third-party affected sessions - only the instantiated tasks
have to be considered for the purpose of determining the have to be considered for the purpose of determining the
affected tasks. In the case of target-scoped requests affected tasks. In the case of target-scoped requests
(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 provide Response Fence behavior for the TMF Response d. MUST provide Response Fence behavior for the TMF Response
on issuing session as specified in 3.3.2. on issuing session as specified in 3.3.2.
e. MUST provide the Response Fence behavior on the first post- e. MUST provide the Response Fence behavior on the first post-
TMF Response on third-party sessions as specified in 3.3.2. TMF Response on third-party sessions as specified in 3.3.2.
If some tasks originate from non-iSCSI I_T_L nexuses then If some tasks originate from non-iSCSI I_T_L nexuses then
the means by which the target ensures that all affected the means by which the target ensures that all affected
tasks have returned their status to the initiator are tasks have returned their status to the initiator are
defined by the specific non-iSCSI transport protocol(s). defined by the specific non-iSCSI transport protocol(s).
Technically, the TMF servicing is complete in Step.d. Data Technically, the TMF servicing is complete in Step.d. Data
transfers corresponding to terminated tasks may however still be transfers corresponding to terminated tasks may however still be
in progress on third-party iSCSI sessions even at the end of in progress on third-party iSCSI sessions even at the end of
Step.e. TMF Response MUST NOT be sent by the target iSCSI layer Step.e. TMF Response MUST NOT be sent by the target iSCSI layer
before the end of Step.d, and MAY be sent at the end of Step.d before the end of Step.d, and MAY be sent at the end of Step.d
despite these outstanding data transfers until after Step.e. despite these outstanding data transfers until 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 process any responses received for affected tasks in b. SHOULD process any responses received for affected tasks in
the normal fashion. This is acceptable because the the normal fashion. This is acceptable because the
responses are guaranteed to have been sent prior to the TMF responses are guaranteed to have been sent 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. MUST treat the TMF response as terminating all affected d. MUST treat the TMF response as terminating all affected
tasks for which responses have not been received, and MUST tasks for which responses have not been received, and MUST
discard any responses for affected tasks received after the discard any responses for affected tasks received after the
TMF response is passed to the SCSI layer (although the TMF response is passed to the SCSI layer (although the
semantics defined in this section ensure that such an out semantics defined in this section ensure that such an out
of order scenario will never happen with a compliant target of order scenario will never happen with a compliant target
implementation). 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
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
associated with affected tasks) valid.
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 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 if least one affected task is allegiant if
TaskReporting=FastAbort is operational on that third- TaskReporting=FastAbort is operational on that third-
party session, and 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. The LUN field in the Asynchronous Message affected task. The LUN field in the Asynchronous Message
PDU MUST be set to match the LUN for each such LU. 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).
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.
Technically, the TMF servicing is complete in Step.e. Data Technically, the TMF servicing is complete in Step.e. Data
transfers corresponding to terminated tasks may however still be transfers corresponding to terminated tasks may however still be
in progress even at the end of Step.f. TMF Response MUST NOT 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 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 be sent at the end of Step.e despite these outstanding Data
transfers until Step.g. Step.g specifies an event to free up transfers until Step.g. Step.g specifies an event to free up
any such resources that may have been reserved to support any such resources that may have been 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
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 Affected tasks shared across RFC3720 & FastAbort sessions 4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions
If an iSCSI target implementation is capable of supporting If an iSCSI target implementation is capable of supporting
TaskReporting=FastAbort functionality (section 9.1), it may end TaskReporting=FastAbort functionality (section 9.1), it may end
up in a situation where some sessions have TaskReporting=RFC3720 up in a situation where some sessions have TaskReporting=RFC3720
operational (RFC3720 sessions) while some other sessions have operational (RFC3720 sessions) while some other sessions have
TaskReporting=FastAbort operational (FastAbort sessions) even TaskReporting=FastAbort operational (FastAbort sessions) even
while accessing a shared set of affected tasks (section 4.1.1). while accessing a shared set of affected tasks (section 4.1.1).
If the issuing session is a RFC3720 session, iSCSI target If the issuing session is a RFC3720 session, iSCSI target
implementation is FastAbort-capable and third-party affected implementation is FastAbort-capable and third-party affected
session is a FastAbort session, the following behavior SHOULD be session is a FastAbort session, the following behavior SHOULD be
exhibited by the iSCSI target layer: exhibited by the iSCSI target layer:
a. Between steps c and d of target behavior in section 4.1.2, a. Between steps c and d of target behavior in section 4.1.2,
send an Asynchronous Message PDU with AsyncEvent=5 (section send an Asynchronous Message PDU with AsyncEvent=5 (section
8.1) on each connection of each third-party session to 8.1) on each connection of each third-party session to
which at least one affected task is allegiant. If there which at least one affected task is allegiant. If there
are multiple affected LUs, then send one Async Message PDU are multiple affected LUs, then send one Async Message PDU
for each such LU on each connection that has at least one for each such LU on each connection that has at least one
allegiant affected task. When sent, the LUN field in the allegiant affected task. When sent, the LUN field in the
Asynchronous Message PDU MUST be set to match the LUN for Asynchronous Message PDU MUST be set to match the LUN for
each such LU. each such LU.
b. After step e of target behavior in section 4.1.2, free up b. After step e of target behavior in section 4.1.2, free up
the affected TTTs (and STags, if applicable) and the the affected TTTs (and STags, if applicable) and the
corresponding buffers, if any, once each associated Nop-Out corresponding buffers, if any, once each associated Nop-Out
acknowledgement is received that the third-party initiator acknowledgement is received that the third-party initiator
generated in response to each Async Message sent in step a. generated in response to each Async Message sent in step a.
If the issuing session is a FastAbort session, iSCSI target If the issuing session is a FastAbort session, iSCSI target
implementation is FastAbort-capable and third-party affected implementation is FastAbort-capable and third-party affected
session is a RFC3720 session, the following behavior MUST be session is a RFC3720 session, the following behavior MUST be
exhibited by the iSCSI target layer: Asynchronous Message PDUs exhibited by the iSCSI target layer: Asynchronous Message PDUs
MUST NOT be sent on the third-party session to prompt the MUST NOT be sent on the third-party session to prompt the
FastAbort behavior. FastAbort behavior.
If the third-party affected session is a FastAbort session and If the third-party affected session is a FastAbort session and
issuing session is a FastAbort session, initiator in the third- issuing session is a FastAbort session, initiator in the third-
party role MUST respond to each Async Message PDU with party role MUST respond to each Async Message PDU with
AsyncEvent=5 as defined in section 8.1. Note that an initiator AsyncEvent=5 as defined in section 8.1. Note that an initiator
MAY thus receive these Async Messages on a third-party affected MAY thus receive these Async Messages on a third-party affected
session even if the session is a single-connection session. session even if the session is a single-connection session.
4.1.5 Implementation considerations 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.6 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
of section 4.1.2 and Step.a of section 4.1.3 of section 4.1.2 and Step.a of section 4.1.3
correspond to this objective. correspond to this objective.
2. Maintaining a single ordered response flow I_T nexus 2. Maintaining a single ordered response flow I_T nexus
abstraction to the initiator SCSI layer even with multi- abstraction to the initiator SCSI layer even with multi-
connection sessions when one response (i.e. TMF response) connection sessions when one response (i.e. TMF response)
could imply the status of other unfinished tasks from the could imply the status of other unfinished tasks from the
initiator's perspective. initiator's perspective.
o Target must ensure that the initiator does not see o Target must ensure that the initiator does not see
"old" task responses (that were placed on the wire "old" task responses (that were placed on the wire
chronologically earlier than the TMF Response) after chronologically earlier than the TMF Response) after
seeing the TMF response. Target behavior in Step.d of seeing the TMF response. Target behavior in Step.d of
section 4.1.2 and Step.e of section 4.1.3 correspond section 4.1.2 and Step.e of section 4.1.3 correspond
to this objective. to this objective.
o Whenever the result of a TMF action is visible across o Whenever the result of a TMF action is visible across
multiple I_T_L nexuses, [SAM2] requires the SCSI multiple I_T_L nexuses, [SAM2] requires the SCSI
device server to trigger a UA on each of the other device server to trigger a UA on each of the other
I_T_L nexuses. Once an initiator is notified of such I_T_L nexuses. Once an initiator is notified of such
an UA, the application client on the receiving an UA, the application client on the receiving
initiator is required to clear its task state (clause initiator is required to clear its task state (clause
5.5 in [SAM2]) for the affected tasks. It would thus 5.5 in [SAM2]) for the affected tasks. It would thus
be inappropriate to deliver a SCSI Response for a task be inappropriate to deliver a SCSI Response for a task
after the task state is cleared on the initiator, i.e. after the task state is cleared on the initiator, i.e.
after the UA is notified. The UA notification after the UA is notified. The UA notification
contained in the first SCSI Response PDU on each contained in the first SCSI Response PDU on each
affected Third-party I_T_L nexus after the TMF action affected Third-party I_T_L nexus after the TMF action
thus MUST NOT pass the affected task responses on any thus MUST NOT pass the affected task responses on any
of the iSCSI sessions accessing the LU. Target of the iSCSI sessions accessing the LU. Target
behavior in Step.e of section 4.1.2 and Step.f of behavior in Step.e of section 4.1.2 and Step.f of
section 4.1.3 correspond to this objective. section 4.1.3 correspond to this objective.
3. Draining all active TTTs corresponding to affected tasks 3. Draining all active TTTs corresponding to affected tasks
in a deterministic fashion. in a deterministic fashion.
o Data-out PDUs with stale TTTs arriving after the tasks o Data-out PDUs with stale TTTs arriving after the tasks
are terminated can create a buffer management problem are terminated can create a buffer management problem
even for traditional iSCSI implementations, and is even for traditional iSCSI implementations, and is
fatal for the connection for iSCSI/iSER fatal for the connection for iSCSI/iSER
implementations. Either the termination of affected implementations. Either the termination of affected
tasks should be postponed until the TTTs are retired tasks should be postponed until the TTTs are retired
(as in Step.a of section 4.1.2), or the TTTs and the (as in Step.a of section 4.1.2), or the TTTs and the
buffers should stay allocated beyond task termination buffers should stay allocated beyond task termination
to be deterministically freed up later (as in Step.c to be deterministically freed up later (as in Step.c
and Step.g of section 4.1.3). and Step.g of section 4.1.3).
The only other notable optimization is the plugging. If all The only other notable optimization is the plugging. If all
tasks on an I_T nexus will be aborted anyway (as with a target tasks on an I_T nexus will be aborted anyway (as with a target
reset), there is no need to wait to receive all commands to plug reset), there is no need to wait to receive all commands to plug
the CmdSN holes. Target iSCSI layer can simply plug all missing the CmdSN holes. Target iSCSI layer can simply plug all missing
CmdSN slots and move on with TMF processing. The first CmdSN slots and move on with TMF processing. The first
objective (maintaining a single ordered command flow) is still objective (maintaining a single ordered command flow) is still
met with this optimization because target SCSI layer only sees met with this optimization because target SCSI layer only sees
ordered commands. ordered commands.
5 Discovery semantics 5 Discovery semantics
5.1 Error Recovery for Discovery Sessions 5.1 Error Recovery for Discovery Sessions
The negotiation of the key ErrorRecoveryLevel is not required The negotiation of the key ErrorRecoveryLevel is not required
for Discovery sessions - i.e. for sessions that negotiated for Discovery sessions - i.e. for sessions that negotiated
"SessionType=Discovery" - because the default value of 0 is "SessionType=Discovery" - because the default value of 0 is
necessary and sufficient for Discovery sessions. It is however necessary and sufficient for Discovery sessions. It is however
possible that some legacy iSCSI implementations might attempt to possible that some legacy iSCSI implementations might attempt to
negotiate the ErrorRecoveryLevel key on Discovery sessions. negotiate the ErrorRecoveryLevel key on Discovery sessions.
When such a negotiation attempt is made by the remote side, a When such a negotiation attempt is made by the remote side, a
compliant iSCSI implementation MUST propose a value of 0 (zero) compliant iSCSI implementation MUST propose a value of 0 (zero)
in response. The operational ErrorRecoveryLevel for Discovery in response. The operational ErrorRecoveryLevel for Discovery
sessions thus MUST be 0. This naturally follows from the sessions thus MUST be 0. This naturally follows from the
functionality constraints [RFC3720] imposes on Discovery functionality constraints [RFC3720] imposes on Discovery
sessions. sessions.
5.2 Reinstatement Semantics of Discovery Sessions 5.2 Reinstatement Semantics of Discovery Sessions
Discovery sessions are intended to be relatively short-lived. Discovery sessions are intended to be relatively short-lived.
Initiators are not expected to establish multiple Discovery Initiators are not expected to establish multiple Discovery
sessions to the same iSCSI Network Portal (see [RFC3720]). An sessions to the same iSCSI Network Portal (see [RFC3720]). An
initiator may use the same iSCSI Initiator Name and ISID when initiator may use the same iSCSI Initiator Name and ISID when
establishing different unique sessions with different targets establishing different unique sessions with different targets
and/or different portal groups. This behavior is discussed in and/or different portal groups. This behavior is discussed in
Section 9.1.1 of [RFC3720] and is, in fact, encouraged as Section 9.1.1 of [RFC3720] and is, in fact, encouraged as
conservative reuse of ISIDs. ISID RULE in [RFC3720] states that conservative reuse of ISIDs. ISID RULE in [RFC3720] states that
there must not be more than one session with a matching 4-tuple: there must not be more than one session with a matching 4-tuple:
<InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While <InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While
the spirit of the ISID RULE applies to Discovery sessions the the spirit of the ISID RULE applies to Discovery sessions the
same as it does for Normal sessions, note that some Discovery same as it does for Normal sessions, note that some Discovery
sessions differ from the Normal sessions in two important sessions differ from the Normal sessions in two important
aspects: aspects:
Because [RFC3720] allows a Discovery session to be Because [RFC3720] allows a Discovery session to be
established without specifying a TargetName key in the established without specifying a TargetName key in the
Login Request PDU (let us call such a session an "Unnamed" Login Request PDU (let us call such a session an "Unnamed"
Discovery session), there is no Target Node context to Discovery session), there is no Target Node context to
enforce the ISID RULE. enforce the ISID RULE.
Portal Groups are defined only in the context of a Target Portal Groups are defined only in the context of a Target
Node. When the TargetName key is NULL-valued (i.e. not Node. When the TargetName key is NULL-valued (i.e. not
specified), the TargetPortalGroupTag thus cannot be specified), the TargetPortalGroupTag thus cannot be
ascertained to enforce the ISID RULE. ascertained to enforce the ISID RULE.
The following sections describe the two scenarios - Named The following sections describe the two scenarios - Named
Discovery sessions and Unnamed Discovery sessions - separately. Discovery sessions and Unnamed Discovery sessions - separately.
5.2.1 Unnamed Discovery Sessions 5.2.1 Unnamed Discovery Sessions
For Unnamed Discovery sessions, neither the TargetName nor the For Unnamed Discovery sessions, neither the TargetName nor the
TargetPortalGroupTag is available to the targets in order to TargetPortalGroupTag is available to the targets in order to
enforce the ISID RULE. So the following rule applies. enforce the ISID RULE. So the following rule applies.
UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the
following 4-tuple for Unnamed Discovery sessions: following 4-tuple for Unnamed Discovery sessions:
<InitiatorName, ISID, NULL, TargetAddress>. The following <InitiatorName, ISID, NULL, TargetAddress>. The following
semantics are implied by this uniqueness requirement. semantics are implied by this uniqueness requirement.
Targets SHOULD allow concurrent establishment of one Discovery Targets SHOULD allow concurrent establishment of one Discovery
session with each of its Network Portals by the same initiator session with each of its Network Portals by the same initiator
port with a given iSCSI Node Name and an ISID. Each of the port with a given iSCSI Node Name and an ISID. Each of the
concurrent Discovery sessions, if established by the same concurrent Discovery sessions, if established by the same
initiator port to other Network Portals, MUST be treated as initiator port to other Network Portals, MUST be treated as
independent sessions - i.e. one session MUST NOT reinstate the independent sessions - i.e. one session MUST NOT reinstate the
other. other.
A new Unnamed Discovery session that has a matching A new Unnamed Discovery session that has a matching
<InitiatorName, ISID, NULL, TargetAddress> to an existing <InitiatorName, ISID, NULL, TargetAddress> to an existing
discovery session MUST reinstate the existing Unnamed Discovery discovery session MUST reinstate the existing Unnamed Discovery
session. Note thus that only an Unnamed Discovery session may session. Note thus that only an Unnamed Discovery session may
reinstate an Unnamed Discovery session. reinstate an Unnamed Discovery session.
5.2.2 Named Discovery Sessions 5.2.2 Named Discovery Sessions
For a Named Discovery session, the TargetName key is specified For a Named Discovery session, the TargetName key is specified
by the initiator and thus the target can unambiguously ascertain by the initiator and thus the target can unambiguously ascertain
the TargetPortalGroupTag as well. Since all the four elements the TargetPortalGroupTag as well. Since all the four elements
of the 4-tuple are known, the ISID RULE MUST be enforced by of the 4-tuple are known, the ISID RULE MUST be enforced by
targets with no changes from [RFC3720] semantics. A new session targets with no changes from [RFC3720] semantics. A new session
with a matching <InitiatorName, ISID, TargetName, with a matching <InitiatorName, ISID, TargetName,
TargetPortalGroupTag> thus will reinstate an existing session. TargetPortalGroupTag> thus will reinstate an existing session.
Note in this case that any new iSCSI session (Discovery or Note in this case that any new iSCSI session (Discovery or
Normal) with the matching 4-tuple may reinstate an existing Normal) with the matching 4-tuple may reinstate an existing
Named Discovery iSCSI session. Named Discovery iSCSI session.
5.3 Target PDUs during Discovery 5.3 Target PDUs during Discovery
Targets SHOULD NOT send any responses other than a Text Response Targets SHOULD NOT send any responses other than a Text Response
and Logout Response on a Discovery session, once in full feature and Logout Response on a Discovery session, once in full feature
phase. phase.
Implementation Note: A target may simply drop the connection in Implementation Note: A target may simply drop the connection in
a Discovery session when it would have requested a Logout via an a Discovery session when it would have requested a Logout via an
Async Message on Normal sessions. Async Message on Normal sessions.
6 Negotiation and Others 6 Negotiation and Others
6.1 TPGT Values 6.1 TPGT Values
[SAM2] and [SAM3] specifications incorrectly note in their [SAM2] and [SAM3] specifications incorrectly note in their
informative text that TPGT value should be non-zero, although informative text that TPGT value should be non-zero, although
[RFC3720] allows the value of zero for TPGT. This section is to [RFC3720] allows the value of zero for TPGT. This section is to
clarify that zero value is expressly allowed as a legal value clarify that zero value is expressly allowed as a legal value
for TPGT. This discrepancy currently stands corrected in for TPGT. This discrepancy currently stands corrected in
[SAM4]. [SAM4].
6.2 SessionType Negotiation 6.2 SessionType Negotiation
During the Login phase, the SessionType key is offered by the During the Login phase, the SessionType key is offered by the
initiator to choose the type of session it wants to create with initiator to choose the type of session it wants to create with
the target. The target may accept or reject the offer. the target. The target may accept or reject the offer.
Depending on the type of the session, a target may decide on Depending on the type of the session, a target may decide on
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 proposed key semantics. This section seeks not understand the proposed key semantics. This section seeks
to clarify that NotUnderstood is a valid answer for both to clarify that NotUnderstood is a valid answer for both
declarative and negotiated keys. The general iSCSI philosophy declarative and negotiated keys. The general iSCSI philosophy
is that comprehension precedes processing for any iSCSI key. A is that comprehension precedes processing for any iSCSI key. A
proposer of an iSCSI key, negotiated or declarative, in a text proposer of an iSCSI key, negotiated or declarative, in a text
key exchange MUST thus be able to properly handle a key exchange MUST thus be able to properly handle a
NotUnderstood response. NotUnderstood response.
The proper way to handle a NotUnderstood response depends on The proper way to handle a NotUnderstood response depends on
where the key is specified and whether the key is declarative where the key is specified and whether the key is declarative
vs. negotiated All keys defined in [RFC3720] MUST be supported vs. negotiated. All keys defined in [RFC3720] MUST be supported
by all compliant implementations; a NotUnderstood answer on any by all compliant implementations; a NotUnderstood answer on any
of the [RFC3720] keys therefore MUST be considered a protocol of the [RFC3720] keys therefore MUST be considered a protocol
error and handled accordingly. For all other later keys, a error and handled accordingly. For all other later keys, a
NotUnderstood answer concludes the negotiation for a negotiated NotUnderstood answer concludes the negotiation for a negotiated
key whereas for a declarative key, a NotUnderstood answer simply key whereas for a declarative key, a NotUnderstood answer simply
informs the declarer of lack of comprehension by the receiver. informs the declarer of lack of comprehension by the receiver.
In either case, a NotUnderstood answer always requires that the In either case, a NotUnderstood answer always requires that the
protocol behavior associated with that key be not used within protocol behavior associated with that key be not used within
the scope of the key (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.
There MUST NOT be more than one outstanding Login Request or There MUST NOT be more than one outstanding Login Request or
Login Response or Text Request or Text Response PDU on an iSCSI Login Response or Text Request or Text Response PDU on an iSCSI
connection. An outstanding PDU in this context is one that has connection. An outstanding PDU in this context is one that has
not been acknowledged by the remote iSCSI side. not been acknowledged by the remote iSCSI side.
7 iSCSI Error Handling and Recovery 7 iSCSI Error Handling and Recovery
7.1 ITT 7.1 ITT
Section 10.19 in [RFC3720] mentions this in passing but noted Section 10.19 in [RFC3720] mentions this in passing but noted
here again for making it obvious since the semantics apply to here again for making it obvious since the semantics apply to
the initiators in general. An ITT value of 0xffffffff is the initiators in general. An ITT value of 0xffffffff is
reserved and MUST NOT be assigned for a task by the initiator. reserved and MUST NOT be assigned for a task by the initiator.
The only instance it may be seen on the wire is in a target- The only instance it may be seen on the wire is in a target-
initiated NOP-In PDU (and in the initiator response to that PDU initiated NOP-In PDU (and in the initiator response to that PDU
if necessary). if necessary).
7.2 Format Errors 7.2 Format Errors
Section 6.6 of [RFC3720] discusses format error handling. This Section 6.6 of [RFC3720] discusses format error handling. This
section elaborates on the "inconsistent" PDU field contents section elaborates on the "inconsistent" PDU field contents
noted in [RFC3720]. noted in [RFC3720].
All initiator-detected PDU construction errors MUST be All initiator-detected PDU construction errors MUST be
considered as format errors. Some examples of such errors are: considered as format errors. Some examples of such errors are:
- NOP-In with a valid TTT but an invalid LUN - NOP-In with a valid TTT but an invalid LUN
- NOP-In with a valid ITT (i.e. a NOP-In response) and also a - NOP-In with a valid ITT (i.e. a NOP-In response) and also a
valid TTT valid TTT
- SCSI Response PDU with Status=CHECK CONDITION, but - SCSI Response PDU with Status=CHECK CONDITION, but
DataSegmentLength = 0 DataSegmentLength = 0
7.3 Digest Errors 7.3 Digest Errors
Section 6.7 of [RFC3720] discusses digest error handling. It Section 6.7 of [RFC3720] discusses digest error handling. It
states that "No further action is necessary for initiators if states that "No further action is necessary for initiators if
the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" the discarded PDU is an unsolicited PDU (e.g., Async, Reject)"
on detecting a payload digest error. This is incorrect. on detecting a payload digest error. This is incorrect.
An Asynchronous Message PDU or a Reject PDU carries the next An Asynchronous Message PDU or a Reject PDU carries the next
StatSN value on an iSCSI connection, advancing the StatSN. When StatSN value on an iSCSI connection, advancing the StatSN. When
an initiator discards one of these PDUs due to a payload digest an initiator discards one of these PDUs due to a payload digest
error, the entire PDU including the header MUST be discarded. error, the entire PDU including the header MUST be discarded.
Consequently, the initiator MUST treat the exception like a loss Consequently, the initiator MUST treat the exception like a loss
of any other solicited response PDU - i.e. it MUST use one of of any other solicited response PDU - i.e. it MUST use one of
the following options noted in [RFC3720]: the following options noted in [RFC3720]:
a) Request PDU retransmission with a status SNACK. a) Request PDU retransmission with a status SNACK.
b) Logout the connection for recovery and continue the b) Logout the connection for recovery and continue the
tasks on a different connection instance. tasks on a different connection instance.
c) Logout to close the connection (abort all the commands c) Logout to close the connection (abort all the commands
associated with the connection). associated with the connection).
7.4 Message Error Checking 7.4 Message Error Checking
There has been some uncertainty on the extent to which incoming There has been some uncertainty on the extent to which incoming
messages have to be checked for protocol errors, beyond what is messages have to be checked for protocol errors, beyond what is
strictly required for processing the inbound message. This strictly required for processing the inbound message. This
section addresses that question. section addresses that question.
Unless [RFC3720] or this draft requires it, an iSCSI Unless [RFC3720] or this draft requires it, an iSCSI
implementation is not required to do an exhaustive protocol implementation is not required to do an exhaustive protocol
conformance checking on an incoming iSCSI PDU. The iSCSI conformance checking on an incoming iSCSI PDU. The iSCSI
implementation especially is not required to double-check the implementation especially is not required to double-check the
remote iSCSI implementation's conformance to protocol remote iSCSI implementation's conformance to protocol
requirements. requirements.
8 iSCSI PDUs 8 iSCSI PDUs
8.1 Asynchronous Message 8.1 Asynchronous Message
This section defines additional semantics for the Asynchronous This section defines additional semantics for the Asynchronous
Message PDU defined in section 10.9 of [RFC3720] using the same Message PDU defined in section 10.9 of [RFC3720] using the same
conventions. conventions.
The following new legal value for AsyncEvent is defined: The following new legal value for AsyncEvent is defined:
5: all active tasks for LU with matching LUN field in the Async 5: all active tasks for LU with matching LUN field in the Async
Message PDU are being terminated. Message PDU are being terminated.
The receiving initiator iSCSI layer MUST respond to this Message The receiving initiator iSCSI layer MUST respond to this Message
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 The new AsyncEvent defined in this section however MUST NOT be
used on an iSCSI session unless the new TaskReporting text key used on an iSCSI session unless the new TaskReporting text key
defined in section 9.1 was negotiated to FastAbort on the defined in section 9.1 was negotiated to FastAbort on the
session. 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 sent by implementations that deprecated and MUST NOT be sent by implementations that
comply with the requirements of this document. An comply with the requirements of this document. An
implementation receiving reason code 0x0b MUST treat it as a implementation receiving reason code 0x0b MUST treat it as a
negotiation failure that terminates the Login phase and the TCP negotiation failure that terminates the Login phase and the TCP
connection, as specified in Section 6.10 of [RFC3720]. connection, as specified in Section 6.10 of [RFC3720].
Section 5.4 of [RFC3720] states: Section 5.4 of [RFC3720] states:
Neither the initiator nor the target should attempt to Neither the initiator nor the target should attempt to
declare or negotiate a parameter more than once during any declare or negotiate a parameter more than once during any
negotiation sequence without an intervening operational negotiation sequence without an intervening operational
parameter negotiation reset, except for responses to parameter negotiation reset, except for responses to
specific keys that explicitly allow repeated key specific keys that explicitly allow repeated key
declarations (e.g., TargetAddress). declarations (e.g., TargetAddress).
The deprecation of reason code 0x0b eliminates the possibility The deprecation of reason code 0x0b eliminates the possibility
of an operational parameter negotiation reset, causing of an operational parameter negotiation reset, causing
the phrase "without an intervening operational the phrase "without an intervening operational
parameter negotiation reset" in [RFC3720] to refer to an parameter negotiation reset" in [RFC3720] to refer to an
impossible event. The quoted phrase SHOULD be ignored by impossible event. The quoted phrase SHOULD be ignored by
receivers that handle reason code 0x0b in the manner specified receivers that handle reason code 0x0b in the manner specified
in this section. 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
Scope: SW Scope: SW
Irrelevant when: SessionType=Discovery Irrelevant when: SessionType=Discovery
TaskReporting=<list-of-values> TaskReporting=<list-of-values>
Default is RFC3720. 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
RFC3720 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 |
+--------------+------------------------------------------+ +--------------+------------------------------------------+
| RFC3720 | 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 |
| | 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 [RFC3720] When TaskReporting is not negotiated to FastAbort, the [RFC3720]
TMF semantics as clarified in section 4.1.2 MUST be used. TMF semantics as clarified in section 4.1.2 MUST be used.
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
11.1 iSCSI-related IANA registries 11.1 iSCSI-related IANA registries
This draft creates the following iSCSI-related registries for This draft creates the following iSCSI-related registries for
IANA to manage. IANA to manage.
1. iSCSI Opcodes 1. iSCSI Opcodes
2. iSCSI Login/Text Keys 2. iSCSI Login/Text Keys
3. iSCSI Asynchronous Events 3. iSCSI Asynchronous Events
4. iSCSI Task Management Function Codes 4. iSCSI Task Management Function Codes
5. iSCSI Login Response Status Codes 5. iSCSI Login Response Status Codes
6. iSCSI Reject Reason Codes 6. iSCSI Reject Reason Codes
7. iSER Opcodes 7. iSER Opcodes
Each of the following sections describes a proposed registry and Each of the following sections describes a proposed registry and
its sub-registries if any and their administration policies in its sub-registries if any and their administration policies in
more detail. IANA may publish what this document calls the main more detail. IANA may publish what this document calls the main
"registries" as sub-registries of a larger iSCSI registry if "registries" as sub-registries of a larger iSCSI registry if
doing so is appropriate. However, wherever registry-to-sub- doing so is appropriate. However, wherever registry-to-sub-
registry relationships are specified by this document, they must registry relationships are specified by this document, they must
be preserved intact in the new hierarchy by the end of the IANA be preserved intact in the new hierarchy by the end of the IANA
publication process. publication process.
[RFC3720] specifies three iSCSI-related registries - extended [RFC3720] specifies three iSCSI-related registries - extended
key, authentication methods, digests. This document recommends key, authentication methods, digests. This document recommends
that those registries be published together with the registries that those registries be published together with the registries
defined by this document. Further, this document recommends defined by this document. Further, this document recommends
that the three [RFC3720] registries be listed in between that the three [RFC3720] registries be listed in between
registry item no. 6 and registry item no. 7 in the registry list registry item no. 6 and registry item no. 7 in the registry list
that preceded this text. that preceded this text.
11.2 iSCSI Opcodes 11.2 iSCSI Opcodes
Name of the registry: "iSCSI Opcodes" Name of the registry: "iSCSI Opcodes"
Namespace details: Numerical values that can fit in one octet Namespace details: Numerical values that can fit in one octet
with most significant two bits (bits 0 and 1) already designated with most significant two bits (bits 0 and 1) already designated
by [RFC3720], bit 0 being reserved and bit 1 for immediate by [RFC3720], bit 0 being reserved and bit 1 for immediate
delivery. Bit 2 is designated to identify the originator of the delivery. Bit 2 is designated to identify the originator of the
opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target
Information that must be provided to assign a new value: An Information that must be provided to assign a new value: An
skipping to change at page 36, line 51 skipping to change at page 38, line 51
0x32, Target, Asynchronous Message, [RFC3720] 0x32, Target, Asynchronous Message, [RFC3720]
0x3c-0x3e, Target, Vendor specific codes, [RFC3720] 0x3c-0x3e, Target, Vendor specific codes, [RFC3720]
0x3f, Target, Reject, [RFC3720] 0x3f, Target, Reject, [RFC3720]
"Reserved to IANA" opcodes: 0x11, 0x12, 0x1f, 0x30 "Reserved to IANA" opcodes: 0x11, 0x12, 0x1f, 0x30
Allocation Policy: Allocation Policy:
Standards Action ([IANA]), Expert Review ([IANA]) Standards Action ([IANA]): This is required for defining the
11.3 iSCSI Login/Text Keys semantics of the opcode
Expert Review ([IANA]): This is required for selecting the
specific opcode(s) to allocate in order to ensure compliance
with the earlier "Allocation request guidance to requesters"
11.3 iSCSI Login/Text Keys
Name of the registry: "iSCSI Text Keys" Name of the registry: "iSCSI Text Keys"
Namespace details: Key=value pairs with "Key" names in UTF-8 Namespace details: Key=value pairs with "Key" names in UTF-8
Unicode, and the permissible "value" options for the "Key" are Unicode, and the permissible "value" options for the "Key" are
Key-dependent. [RFC3720] defines the rules on key names and Key-dependent. [RFC3720] defines the rules on key names and
allowed values allowed values
Information that must be provided to assign a new value: An Information that must be provided to assign a new value: An
IESG-approved standards-track specification defining the IESG-approved standards-track specification defining the
skipping to change at page 38, line 45 skipping to change at page 41, line 4
ErrorRecoveryLevel, [RFC3720] ErrorRecoveryLevel, [RFC3720]
SessionType, [RFC3720] SessionType, [RFC3720]
RDMAExtensions, [iSER] RDMAExtensions, [iSER]
TargetRecvDataSegmentLength, [iSER] TargetRecvDataSegmentLength, [iSER]
InitiatorRecvDataSegmentLength, [iSER] InitiatorRecvDataSegmentLength, [iSER]
MaxOutstandingUnexpectedPDUs, [iSER] MaxOutstandingUnexpectedPDUs, [iSER]
TaskReporting, this document TaskReporting, this document
Allocation Policy: Allocation Policy:
Standards Action ([IANA]) Standards Action ([IANA])
11.4 iSCSI Asynchronous Events 11.4 iSCSI Asynchronous Events
Name of the registry: "iSCSI Asynchronous Events" Name of the registry: "iSCSI Asynchronous Events"
Namespace details: Numerical values that can fit in one octet Namespace details: Numerical values that can fit in one octet
Information that must be provided to assign a new value: A IESG- Information that must be provided to assign a new value: A IESG-
approved standards-track specification defining the semantics approved standards-track specification defining the semantics
and interoperability requirements of the proposed new Event and and interoperability requirements of the proposed new Event and
the fields to be recorded in the registry the fields to be recorded in the registry
skipping to change at page 39, line 33 skipping to change at page 42, line 4
6-247: range reserved by IANA for assignment in this registry 6-247: range reserved by IANA for assignment in this registry
Fields to record in the registry: Assigned Event number, Fields to record in the registry: Assigned Event number,
Description and its associated RFC reference Description and its associated RFC reference
Initial registry contents: Initial registry contents:
0, SCSI Async Event, [RFC3720] 0, SCSI Async Event, [RFC3720]
1, Logout Request, [RFC3720] 1, Logout Request, [RFC3720]
2, Connection drop notification, [RFC3720] 2, Connection drop notification, [RFC3720]
3, Session drop notification, [RFC3720] 3, Session drop notification, [RFC3720]
4, Negotiation Request, [RFC3720] 4, Negotiation Request, [RFC3720]
5, Task termination, this document 5, Task termination, this document
248-254, Vendor-unique, this document 248-254, Vendor-unique, this document
255, Vendor-unique, [RFC3720] 255, Vendor-unique, [RFC3720]
Allocation Policy: Allocation Policy:
Standards Action ([IANA]) Standards Action ([IANA])
11.5 iSCSI Task Management Function Codes 11.5 iSCSI Task Management Function Codes
Name of the registry: "iSCSI TMF Codes" Name of the registry: "iSCSI TMF Codes"
Namespace details: Numerical values that can fit in 7 bits Namespace details: Numerical values that can fit in 7 bits
Information that must be provided to assign a new value: An Information that must be provided to assign a new value: An
IESG-approved standards-track specification defining the IESG-approved standards-track specification defining the
semantics and interoperability requirements of the proposed new semantics and interoperability requirements of the proposed new
Code and the fields to be recorded in the registry Code and the fields to be recorded in the registry
skipping to change at page 40, line 40 skipping to change at page 43, line 4
Fields to record in the registry: Assigned Code, Description and Fields to record in the registry: Assigned Code, Description and
its associated RFC reference its associated RFC reference
Initial registry contents: Initial registry contents:
1, ABORT TASK, [RFC3720] 1, ABORT TASK, [RFC3720]
2, ABORT TASK SET, [RFC3720] 2, ABORT TASK SET, [RFC3720]
3, CLEAR ACA, [RFC3720] 3, CLEAR ACA, [RFC3720]
4, CLEAR TASK SET, [RFC3720] 4, CLEAR TASK SET, [RFC3720]
5, LOGICAL UNIT RESET, [RFC3720] 5, LOGICAL UNIT RESET, [RFC3720]
6, TARGET WARM RESET, [RFC3720] 6, TARGET WARM RESET, [RFC3720]
7, TARGET COLD RESET, [RFC3720] 7, TARGET COLD RESET, [RFC3720]
8, TASK REASSIGN, [RFC3720] 8, TASK REASSIGN, [RFC3720]
Allocation Policy: Allocation Policy:
Standards Action ([IANA]) Standards Action ([IANA])
11.6 iSCSI Login Response Status Codes 11.6 iSCSI Login Response Status Codes
Name of the registry: "iSCSI Login Response Status Codes" Name of the registry: "iSCSI Login Response Status Codes"
Namespace details: Numerical values; Status-Class (one octet), Namespace details: Numerical values; Status-Class (one octet),
Status-Detail (one octet) for each possible value of Status- Status-Detail (one octet) for each possible value of Status-
Class except for Vendor-Unique Status-Class (0x0f) Class except for Vendor-Unique Status-Class (0x0f)
Information that must be provided to assign a new value: An Information that must be provided to assign a new value: An
IESG-approved specification defining the semantics and IESG-approved specification defining the semantics and
interoperability requirements of the proposed new Code, its interoperability requirements of the proposed new Code, its
skipping to change at page 43, line 33 skipping to change at page 45, line 41
0x03, 0x02, Out of resources, [RFC3720] 0x03, 0x02, Out of resources, [RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=3 3-255: range reserved by IANA for assignment in Status-Class=3
sub-registry sub-registry
Allocation Policy: Allocation Policy:
Standards Action ([IANA]) Standards Action ([IANA])
11.7 iSCSI Reject Reason Codes 11.7 iSCSI Reject Reason Codes
Name of the registry: "iSCSI Reject Reason Codes" Name of the registry: "iSCSI Reject Reason Codes"
Namespace details: Numerical values that can fit in a single Namespace details: Numerical values that can fit in a single
octet octet
Information that must be provided to assign a new value: A Information that must be provided to assign a new value: A
published specification defining the semantics and published specification defining the semantics and
interoperability requirements of the proposed new Code and the interoperability requirements of the proposed new Code and the
fields to be recorded in the registry fields to be recorded in the registry
Assignment policy: Assignment policy:
If the requested value is not already assigned, it may be If the requested value is not already assigned, it may be
assigned to the requester. assigned to the requester.
13-255: range reserved by IANA for assignment in this registry 13-255: range reserved by IANA for assignment in this registry
Fields to record in the registry: Assigned Code, Description and Fields to record in the registry: Assigned Code, Description and
its associated RFC reference its associated RFC reference
skipping to change at page 44, line 37 skipping to change at page 47, line 4
0x07, Task in progress, [RFC3720] 0x07, Task in progress, [RFC3720]
0x08, Invalid data ack, [RFC3720] 0x08, Invalid data ack, [RFC3720]
0x09, Invalid PDU field, [RFC3720] 0x09, Invalid PDU field, [RFC3720]
0x0a, Long op reject, [RFC3720] 0x0a, Long op reject, [RFC3720]
0x0b, "Deprecated reason code", this document 0x0b, "Deprecated reason code", this document
0x0c, Waiting for Logout, [RFC3720] 0x0c, Waiting for Logout, [RFC3720]
Allocation Policy: Allocation Policy:
Standards Action ([IANA]) Standards Action ([IANA])
11.8 iSER Opcodes
11.8 iSER Opcodes
Name of the registry: "iSER Opcodes" Name of the registry: "iSER Opcodes"
Namespace details: Numerical values that can fit in 4 bits Namespace details: Numerical values that can fit in 4 bits
Information that must be provided to assign a new value: An Information that must be provided to assign a new value: An
IESG-approved specification defining the semantics and IESG-approved specification defining the semantics and
interoperability requirements of the proposed new value and the interoperability requirements of the proposed new value and the
fields to be recorded in the registry fields to be recorded in the registry
skipping to change at page 45, line 32 skipping to change at page 48, line 4
Fields to record in the registry: Assigned value, Operation Name Fields to record in the registry: Assigned value, Operation Name
and its associated RFC reference and its associated RFC reference
Initial registry contents: Initial registry contents:
0x1, iSCSI control-type, [iSER] 0x1, iSCSI control-type, [iSER]
0x2, iSER Hello, [iSER] 0x2, iSER Hello, [iSER]
0x3, iSER HelloReply, [iSER] 0x3, iSER HelloReply, [iSER]
Allocation Policy: Allocation Policy:
Standards Action ([IANA]) 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] ANSI INCITS 408-2005, 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 [IANA] Alvestrand, H. and T. Narten, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC 2434, an IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler,
P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet
Draft draft-ietf-ips-iser-04.txt (work in progress), June Draft draft-ietf-ips-iser-04.txt (work in progress), June
2005. 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.
[RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate [SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-
Requirement Levels", BCP 14, RFC 2119, March 1997. 2).
[SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-
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-
4), Work in Progress. 4), Work in Progress.
13 Editor's Address 13 Editor's Address
Mallikarjun Chadalapaka Mallikarjun Chadalapaka
Hewlett-Packard Company Hewlett-Packard Company
8000 Foothills Blvd. 8000 Foothills Blvd.
Roseville, CA 95747-5668, USA Roseville, CA 95747-5668, USA
Phone: +1-916-785-5621 Phone: +1-916-785-5621
E-mail: cbm@rose.hp.com E-mail: cbm@rose.hp.com
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, Gwendal Grignou, clarified in this document: David Black, Gwendal Grignou,
Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob
Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh
Gupta, Eddy Quicksall, Paul Koning. This document benefited Gupta, Eddy Quicksall, Paul Koning. This document benefited
from all these contributions. 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
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
16 Intellectual Property Statement 16 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might any Intellectual Property Rights or other rights that might
be claimed to pertain to the implementation or use of the be claimed to pertain to the implementation or use of the
technology described in this document or the extent to which technology described in this document or the extent to which
any license under such rights might or might not be any license under such rights might or might not be
available; nor does it represent that it has made any available; nor does it represent that it has made any
independent effort to identify any such rights. Information independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can on the procedures with respect to rights in RFC documents can
be found in BCP 78 and BCP 79. be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and Copies of IPR disclosures made to the IETF Secretariat and
any assurances of licenses to be made available, or the any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by permission for the use of such proprietary rights by
implementers or users of this specification can be obtained implementers or users of this specification can be obtained
from the IETF on-line IPR repository at from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or attention any copyrights, patents or patent applications, or
other proprietary rights that may cover technology that may other proprietary rights that may cover technology that may
be required to implement this standard. Please address the be required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org. information to the IETF at ietf-ipr@ietf.org.
 End of changes. 204 change blocks. 
564 lines changed or deleted 653 lines changed or added

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