draft-ietf-ips-iscsi-impl-guide-09.txt   rfc5048.txt 
INTERNET DRAFT Mallikarjun Chadalapaka
draft-ietf-ips-iscsi-impl-guide-09.txt Hewlett-Packard Co.
Editor
Updates: RFC 3720 Network Working Group M. Chadalapaka, Ed.
Intended status: Proposed Standard Request for Comments: 5048 Hewlett-Packard Co.
Updates: 3720 October 2007
Category: Standards Track
Expires December 2007 Internet Small Computer System Interface (iSCSI)
Corrections and Clarifications
iSCSI Corrections and Clarifications Status of This Memo
Status of this Memo This document specifies an Internet standards track protocol for the
By submitting this Internet-Draft, each author represents Internet community, and requests discussion and suggestions for
that any applicable patent or other IPR claims of which he or improvements. Please refer to the current edition of the "Internet
she is aware have been or will be disclosed, and any of which Official Protocol Standards" (STD 1) for the standardization state
he or she becomes aware will be disclosed, in accordance with and status of this protocol. Distribution of this memo is unlimited.
Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Abstract
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of The Internet Small Computer System Interface (iSCSI) is a SCSI
six months and may be updated, replaced, or obsoleted by transport protocol and maps the SCSI architecture and command sets
other documents at any time. It is inappropriate to use onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document
Internet-Drafts as reference material or to cite them other compiles the clarifications to the original protocol definition in
than as "work in progress." RFC 3720 to serve as a companion document for the iSCSI implementers.
This document updates RFC 3720 and the text in this document
supersedes the text in RFC 3720 when the two differ.
The list of current Internet-Drafts can be accessed at Table of Contents
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed 1. Introduction ....................................................3
at http://www.ietf.org/shadow.html. 2. Definitions, Acronyms, and Document Summary .....................3
2.1. Definitions ................................................3
2.2. Acronyms ...................................................4
2.3. Clarifications, Changes, and New Semantics .................5
3. iSCSI Semantics for SCSI Tasks ..................................7
3.1. Residual Handling ..........................................7
3.1.1. Overview ............................................7
3.1.2. SCSI REPORT LUNS and Residual Overflow ..............7
3.2. R2T Ordering ...............................................9
3.3. Model Assumptions for Response Ordering ....................9
3.3.1. Model Description ..................................10
3.3.2. iSCSI Semantics with the Interface Model ...........10
3.3.3. Current List of Fenced Response Use Cases ..........11
4. Task Management ................................................12
4.1. Requests Affecting Multiple Tasks .........................12
4.1.1. Scope of Affected Tasks ............................12
4.1.2. Clarified Multi-Task Abort Semantics ...............13
4.1.3. Updated Multi-Task Abort Semantics .................14
4.1.4. Affected Tasks Shared across RFC 3720 and
FastAbort Sessions .................................16
4.1.5. Implementation Considerations ......................17
4.1.6. Rationale behind the New Semantics .................17
5. Discovery Semantics ............................................19
5.1. Error Recovery for Discovery Sessions .....................19
5.2. Reinstatement Semantics of Discovery Sessions .............19
5.2.1. Unnamed Discovery Sessions .........................20
5.2.2. Named Discovery Sessions ...........................20
5.3. Target PDUs during Discovery ..............................20
6. Negotiation and Others .........................................21
6.1. TPGT Values ...............................................21
6.2. SessionType Negotiation ...................................21
6.3. Understanding NotUnderstood ...............................21
6.4. Outstanding Negotiation Exchanges .........................22
7. iSCSI Error Handling and Recovery ..............................22
7.1. ITT .......................................................22
7.2. Format Errors .............................................22
7.3. Digest Errors .............................................22
7.4. Message Error Checking ....................................23
8. iSCSI PDUs .....................................................23
8.1. Asynchronous Message ......................................23
8.2. Reject ....................................................24
9. Login/Text Operational Text Keys ...............................24
9.1. TaskReporting .............................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................26
11.1. iSCSI-Related IANA Registries ............................26
11.2. iSCSI Opcodes ............................................26
11.3. iSCSI Login/Text Keys ....................................28
11.4. iSCSI Asynchronous Events ................................30
11.5. iSCSI Task Management Function Codes .....................31
11.6. iSCSI Login Response Status Codes ........................32
11.7. iSCSI Reject Reason Codes ................................34
11.8. iSER Opcodes .............................................35
12. References ....................................................36
12.1. Normative References .....................................36
12.2. Informative References ...................................36
Acknowledgements ..................................................37
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 1. Introduction
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as
described in [RFC2119].
Abstract Several iSCSI implementations have been built since [RFC3720] was
iSCSI is a SCSI transport protocol and maps the SCSI published and the iSCSI community is now richer by the resulting
architecture and command sets onto TCP/IP. RFC 3720 defines implementation expertise. The goal of this document is to leverage
the iSCSI protocol. This document compiles the this expertise both to offer clarifications to the [RFC3720]
clarifications to the original protocol definition in RFC semantics and to address defects in [RFC3720] as appropriate. This
3720 to serve as a companion document for the iSCSI document intends to offer critical guidance to implementers with
implementers. This document updates RFC 3720 and the text in regard to non-obvious iSCSI implementation aspects so as to improve
this document supersedes the text in RFC 3720 when the two interoperability and accelerate iSCSI adoption. This document,
differ. however, does not purport to be an all-encompassing iSCSI how-to
guide for implementers, nor a complete revision of [RFC3720].
Instead, this document is intended as a companion document to
[RFC3720] for the iSCSI implementers.
Table of Contents 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.
1 Definitions, Acronyms and Document Summary............. 5 2. Definitions, Acronyms, and Document Summary
1.1 Definitions............................................ 5
1.2 Acronyms............................................... 5
1.3 Clarifications, Changes and New Semantics.............. 6
2 Introduction........................................... 9
3 iSCSI semantics for SCSI tasks........................ 10
3.1 Residual handling..................................... 10
3.1.1 Overview ............................................ 10
3.1.2 SCSI REPORT LUNS and Residual Overflow .............. 11
3.2 R2T Ordering.......................................... 12
3.3 Model Assumptions for Response Ordering............... 13
3.3.1 Model Description ................................... 13
3.3.2 iSCSI Semantics with the Interface Model ............ 14
3.3.3 Current List of Fenced Response Use Cases ........... 14
4 Task Management....................................... 16
4.1 Requests Affecting Multiple Tasks..................... 16
4.1.1 Scope of affected tasks ............................. 16
4.1.2 Clarified multi-task abort semantics ................ 16
4.1.3 Updated multi-task abort semantics .................. 18
4.1.4 Affected tasks shared across RFC3720 & FastAbort
sessions ................................................... 20
4.1.5 Implementation considerations ....................... 21
4.1.6 Rationale behind the new semantics .................. 22
5 Discovery semantics................................... 24
5.1 Error Recovery for Discovery Sessions................. 24
5.2 Reinstatement Semantics of Discovery Sessions......... 24
5.2.1 Unnamed Discovery Sessions .......................... 25
5.2.2 Named Discovery Sessions ............................ 25
5.3 Target PDUs during Discovery.......................... 26
6 Negotiation and Others................................ 27
6.1 TPGT Values........................................... 27
6.2 SessionType Negotiation............................... 27
6.3 Understanding NotUnderstood........................... 27
6.4 Outstanding Negotiation Exchanges..................... 28
7 iSCSI Error Handling and Recovery..................... 29
7.1 ITT................................................... 29
7.2 Format Errors......................................... 29
7.3 Digest Errors......................................... 29
7.4 Message Error Checking................................ 30
8 iSCSI PDUs............................................ 31
8.1 Asynchronous Message.................................. 31
8.2 Reject................................................ 31
9 Login/Text Operational Text Keys...................... 33
9.1 TaskReporting......................................... 33
10 Security Considerations............................... 35
11 IANA Considerations................................... 36
11.1 iSCSI-related IANA registries ....................... 36
11.2 iSCSI Opcodes ....................................... 36
11.3 iSCSI Login/Text Keys ............................... 39
11.4 iSCSI Asynchronous Events ........................... 41
11.5 iSCSI Task Management Function Codes ................ 42
11.6 iSCSI Login Response Status Codes ................... 43
11.7 iSCSI Reject Reason Codes ........................... 45
11.8 iSER Opcodes ........................................ 47
12 References and Bibliography........................... 49
12.1 Normative References ................................ 49
12.2 Informative References .............................. 49
13 Editor's Address...................................... 50
14 Acknowledgements...................................... 51
15 Full Copyright Statement.............................. 52
16 Intellectual Property Statement....................... 53
1 Definitions, Acronyms and Document Summary 2.1. Definitions
1.1 Definitions 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 that buffer. For a read or
write data transfer to take place for a task, an I/O Buffer is
required on the initiator and at least one is required on the
target.
I/O Buffer - A buffer that is used in a SCSI Read or Write SCSI-Presented Data Transfer Length (SPDTL)
operation so SCSI data may be sent from or received into SPDTL is the aggregate data length of the data that the SCSI layer
that buffer. For a read or write data transfer to take logically "presents" to the iSCSI layer for a Data-In or Data-Out
place for a task, an I/O Buffer is required on the transfer in the context of a SCSI task. For a bidirectional task,
initiator and at least one required on the target. there are two SPDTL values -- one for Data-In and one for Data-
Out. Note that the notion of "presenting" includes immediate data
per the data transfer model in [SAM2], and excludes overlapping
data transfers, if any, requested by the SCSI layer.
SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the Third-party
aggregate data length of the data that SCSI layer A term used in this document to denote nexus objects (I_T or
logically "presents" to iSCSI layer for a Data-in or I_T_L) and iSCSI sessions that reap the side effects of actions
Data-out transfer in the context of a SCSI task. For a that take place in the context of a separate iSCSI session, while
bidirectional task, there are two SPDTL values - one for being third parties to the action that caused the side effects.
Data-in and one for Data-out. Note that the notion of One example of a third-party session is an iSCSI session hosting
"presenting" includes immediate data per the data an I_T_L nexus to an LU that is reset with an LU Reset TMF via a
transfer model in [SAM2], and excludes overlapping data separate I_T nexus.
transfers, if any, requested by the SCSI layer.
Third-party: A term used in this document to denote nexus The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
objects (I_T or I_T_L) and iSCSI sessions which reap the "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
side-effects of actions that take place in the context of document are to be interpreted as described in [RFC2119].
a separate iSCSI session, while being third parties to
the action that caused the side-effects. One example of
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
via a separate I_T nexus.
1.2 Acronyms 2.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
skipping to change at page 6, line 40 skipping to change at page 5, line 17
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
1.3 Clarifications, Changes and New Semantics 2.3. Clarifications, Changes, and New Semantics
This document specifies certain changes to [RFC3720] semantics This document specifies certain changes to [RFC3720] semantics as
as well as defines new iSCSI semantics. In addition, this well as defines new iSCSI semantics. In addition, this document also
document also clarifies the [RFC3720] semantics. This section clarifies the [RFC3720] semantics. This section summarizes the
summarizes the contents of the document, categorizing each contents of the document, categorizing each section into one or more
section into one or more of a Clarification, a Change or a New of a clarification, change, or new semantic.
Semantic.
Section 3.1.1: Clarification on iSCSI residuals computation Section 3.1.1: Clarification on iSCSI residuals computation
general principles general principles
Section 3.1.2: Clarification on iSCSI residuals computation
with an example Section 3.1.2: Clarification on iSCSI residuals computation with
an example
Section 3.2: Clarification on R2T ordering requirements Section 3.2: Clarification on R2T ordering requirements
Section 3.3: New Semantics for Response Ordering in multi- Section 3.3: New Semantics for Response Ordering in multi-
connection iSCSI sessions connection iSCSI sessions
Section 4.1.2: Clarifications, Changes and New Semantics on Section 4.1.2: Clarifications, changes, and new semantics on
multi-task abort semantics that all implementations must multi-task abort semantics that all implementations must comply
comply with 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 Section 4.1.3: Changes and new semantics (FastAbort semantics) on
resulting out of new FastAbort semantics multi-task abort semantics that implementations should use for
faster error recovery
Section 4.1.4: New Semantics on third-party session Section 4.1.3.1: Changes in iSCSI clearing effects semantics
interactions with the new FastAbort semantics resulting from 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 Section 4.1.5: Clarification on implementation considerations
related to outstanding data transfers in order to realize related to outstanding data transfers in order to realize correct
right iSCSI protocol behavior iSCSI protocol behavior
Section 4.1.6: Clarification on the intent behind FastAbort Section 4.1.6: Clarification on the intent behind FastAbort
semantics (not clarifications to [RFC3720] semantics) semantics (not clarifications to [RFC3720] semantics)
Section 5.1: Clarification on error recovery semantics as Section 5.1: Clarification on error recovery semantics as
applicable to Discovery sessions applicable to Discovery sessions
Section 5.2.1: Clarification and New Semantics on applying Section 5.2.1: Clarification and new semantics on applying the
ISID RULE ([RFC3720]) to Unnamed Discovery Sessions Initiator Session Identifier (ISID) RULE ([RFC3720]) to Unnamed
Discovery Sessions
Section 5.2.2: Clarification on applying ISID RULE to Named Section 5.2.2: Clarification on applying the ISID RULE to Named
Discovery Sessions Discovery Sessions
Section 5.3: Clarification on allowed PDU types and target Section 5.3: Clarification on allowed PDU types and target Logout
Logout notification behavior on a Discovery session notification behavior on a Discovery session
Section 6.1: Clarification on the legality of TPGT value of Section 6.1: Clarification on the legality of the Target Portal
zero Group Tag (TPGT) value of zero
Section 6.2: Clarification on the negotiating order of Section 6.2: Clarification on the negotiating order of SessionType
SessionType with respect to other keys with respect to other keys
Section 6.3: Clarification on NotUnderstood negotiation Section 6.3: Clarification on the NotUnderstood negotiation
response on declarative keys and the implied semantics response on declarative keys and the implied semantics
Section 6.4: Clarification on the number of legal outstanding Section 6.4: Clarification on the number of legal outstanding
negotiation PDUs (Text or Login-related) negotiation PDUs (Text or Login-related)
Section 7.1: Clarification on usage of ITT value of Section 7.1: Clarification on usage of the ITT value of 0xffffffff
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 Section 7.2: Clarification on what constitutes format errors for
0x0b, it is now deprecated the purpose of error recovery defined in [RFC3720]
Section 9.1: New Semantics for a new text key TaskReporting Section 7.3: Change in error recovery semantics for the case of
discarding unsolicited PDUs
2 Introduction Section 7.4: Clarification on the intended level of error checking
on inbound PDUs
Several iSCSI implementations had been built after [RFC3720] was Section 8.1: New semantics for a new AsyncEvent code
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 Section 8.2: Change of legal status for Reject reason code 0x0b;
[RFC3723] in addition to [RFC3720] for mandatory requirements. it is now deprecated
In addition, [RFC3721] also contains useful information for Section 9.1: New semantics for a new text key TaskReporting
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. iSCSI Semantics for SCSI Tasks
3.1 Residual handling 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
and specifies how the residual information should be encoded specifies how the residual information should be encoded into the
into the SCSI Response PDU in Counts and Flags fields. Section SCSI Response PDU in the Counts and Flags fields. Section 3.1.1
3.1.1 clarifies the intent of [RFC3720] and explains the general 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
the REPORT LUNS scenario. 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
document uses (see section 1.1 for definition) to represent the uses (see Section 1.1 for definition) to represent the aggregate data
aggregate data length that the target SCSI layer attempts to length that the target SCSI layer attempts to transfer using the
transfer using the local iSCSI layer for a task. Expected Data local iSCSI layer for a task. Expected Data Transfer Length (EDTL)
Transfer Length (EDTL) is the iSCSI term that represents the is the iSCSI term that represents the length of data that the iSCSI
length of data that the iSCSI layer expects to transfer for a layer expects to transfer for a task. EDTL is specified in the SCSI
task. EDTL is specified in the SCSI Command PDU. 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
the task with no residuals. Whenever SPDTL differs from EDTL task with no residuals. Whenever SPDTL differs from EDTL for a task,
for a task, that task is said to have a residual. 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
the SCSI Response PDU as specified in [RFC3720]. Residual Count SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST
MUST be set to the numerical value of (SPDTL - EDTL). 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
the SCSI Response PDU as specified in [RFC3720]. Residual Count SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST
MUST be set to the numerical value of (EDTL - SPDTL). 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
of Data-in and Data-out. Either scenario is logically possible Data-In and Data-Out. Either scenario is logically possible in
in either direction of data transfer. 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 the SCSI REPORT LUNS command. Note however that there are
are several SCSI commands (e.g. INQUIRY) with ALLOCATION LENGTH several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH fields
fields following the same underlying rules. The semantics in following the same underlying rules. The semantics in the rest of
the rest of the section apply to all such SCSI commands. 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
the SCSI target limit the amount of data transferred to a SCSI target limit the amount of data transferred to a maximum size
maximum size (ALLOCATION LENGTH) provided by the initiator in (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS CDB.
the REPORT LUNS CDB. If the Expected Data Transfer Length If the Expected Data Transfer Length (EDTL) in the iSCSI header of
(EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT the SCSI Command PDU for a REPORT LUNS command is set to at least as
LUNS command is set to at least as large as that ALLOCATION large as that ALLOCATION LENGTH, the SCSI layer truncation prevents
LENGTH, the SCSI layer truncation prevents an iSCSI Residual an iSCSI Residual Overflow from occurring. A SCSI initiator can
Overflow from occurring. A SCSI initiator can detect that such detect that such truncation has occurred via other information at the
truncation has occurred via other information at the SCSI layer. SCSI layer. The rest of the section elaborates this required
The rest of the section elaborates this required behavior. behavior.
iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI
Response and the last SCSI Data-In PDUs to indicate that that an Response and the last SCSI Data-In PDUs to indicate that an iSCSI
iSCSI target was unable to transfer all of the SCSI data for a target was unable to transfer all of the SCSI data for a command to
command to the initiator because the amount of data to be the initiator because the amount of data to be transferred exceeded
transferred exceeded the EDTL in the corresponding SCSI Command the EDTL in the corresponding SCSI Command PDU (see Section 10.4.1 of
PDU (see Section 10.4.1 of [RFC3720]). [RFC3720]).
The SCSI REPORT LUNS command requests a target SCSI layer to The SCSI REPORT LUNS command requests a target SCSI layer to return a
return a logical unit inventory (LUN list) to the initiator SCSI logical unit inventory (LUN list) to the initiator SCSI layer (see
layer (see section 6.21 of SPC-3 [SPC3]). The size of this LUN Section 6.21 of SPC-3 [SPC3]). The size of this LUN list may not be
list may not be known to the initiator SCSI layer when it issues known to the initiator SCSI layer when it issues the REPORT LUNS
the REPORT LUNS command; to avoid transfer of more LUN list data command; to avoid transferring more LUN list data than the initiator
than the initiator is prepared for, the REPORT LUNS CDB contains is prepared for, the REPORT LUNS CDB contains an ALLOCATION LENGTH
an ALLOCATION LENGTH field to specify the maximum amount of data field to specify the maximum amount of data to be transferred to the
to be transferred to the initiator for this command. If the initiator for this command. If the initiator SCSI layer has under-
initiator SCSI layer has under-estimated the number of logical estimated the number of logical units at the target, it is possible
units at the target, it is possible that the complete logical that the complete logical unit inventory does not fit in the
unit inventory does not fit in the specified ALLOCATION LENGTH. specified ALLOCATION LENGTH. In this situation, Section 4.3.3.6 in
In this situation, section 4.3.3.6 in [SPC3] requires that the [SPC3] requires that the target SCSI layer "shall terminate transfers
target SCSI layer "shall terminate transfers to the Data-In to the Data-In Buffer" when the number of bytes specified by the
Buffer" when the number of bytes specified by the ALLOCATION ALLOCATION LENGTH field have been transferred.
LENGTH field have been transferred.
Therefore, in response to a REPORT LUNS command, the SCSI layer Therefore, in response to a REPORT LUNS command, the SCSI layer at
at the target presents at most ALLOCATION LENGTH bytes of data the target presents at most ALLOCATION LENGTH bytes of data (logical
(logical unit inventory) to iSCSI for transfer to the initiator. unit inventory) to iSCSI for transfer to the initiator. For a REPORT
For a REPORT LUNS command, if the iSCSI EDTL is at least as LUNS command, if the iSCSI EDTL is at least as large as the
large as the ALLOCATION LENGTH, the SCSI truncation ensures that ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL will
the EDTL will accommodate all of the data to be transferred. If accommodate all of the data to be transferred. If all of the logical
all of the logical unit inventory data presented to the iSCSI unit inventory data presented to the iSCSI layer -- i.e., the data
layer - i.e. the data remaining after any SCSI truncation - is remaining after any SCSI truncation -- is transferred to the
transferred to the initiator by the iSCSI layer, an iSCSI initiator by the iSCSI layer, an iSCSI Residual Overflow has not
Residual Overflow has not occurred and the iSCSI (O) bit MUST occurred and the iSCSI (O) bit MUST NOT be set in the SCSI Response
NOT be set in the SCSI Response or final SCSI Data-Out PDU. or final SCSI Data-Out PDU. This is not a new requirement but is
This is not a new requirement but is already required by the already required by the combination of [RFC3720] with the
combination of [RFC3720] with the specification of the REPORT specification of the REPORT LUNS command in [SPC3]. However, if the
LUNS command in [SPC3]. If the iSCSI EDTL is larger than the iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario,
ALLOCATION LENGTH however in this scenario, note that the iSCSI note that the iSCSI Underflow MUST be signaled in the SCSI Response
Underflow MUST be signaled in the SCSI Response PDU. An iSCSI PDU. An iSCSI Underflow MUST also be signaled when the iSCSI EDTL is
Underflow MUST also be signaled when the iSCSI EDTL is equal to equal to the ALLOCATION LENGTH but the logical unit inventory data
ALLOCATION LENGTH but the logical unit inventory data presented presented to the iSCSI layer is smaller than the 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 (the 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
initiator to determine that the received inventory is incomplete to determine that the received inventory is incomplete by noticing
by noticing that the LUN LIST LENGTH in the inventory is larger that the LUN LIST LENGTH in the inventory is larger than the
than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A common
A common initiator behavior in this situation is to re-issue the initiator behavior in this situation is to re-issue the REPORT LUNS
REPORT LUNS command with a larger ALLOCATION LENGTH. 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
a number of pending data transfers. The number of outstanding number of pending data transfers. The number of outstanding R2T
R2T PDUs is limited by the value of the negotiated key 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
be fulfilled by the initiator in the order in which they were 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
applicability - either per task, or across all tasks on a -- either per task, or across all tasks on a connection -- and may be
connection - and may be interpreted as either. This section is interpreted as either. This section is intended to clarify that the
intended to clarify that the scope of applicability of the scope of applicability of the quoted text is a task. No R2T ordering
quoted text is a task. No R2T ordering relationship - either in relationship -- either in generation at the target or in fulfilling
generation at the target or in fulfilling at the initiator - at the initiator -- across tasks is implied. That is, outstanding
across tasks is implied. I.e., outstanding R2Ts within a task R2Ts within a task MUST be fulfilled by the initiator in the order in
which they were received on a connection.
MUST be fulfilled by the initiator in the order in which they
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
the Response PDUs (task responses or TMF responses) originating Response PDUs (task responses or TMF responses) originating in the
in the target SCSI layer are distributed onto the multiple target SCSI layer are distributed onto the multiple connections by
connections by the target iSCSI layer according to iSCSI the target iSCSI layer according to iSCSI connection allegiance
connection allegiance rules. This process generally may not rules. This process generally may not preserve the ordering of the
preserve the ordering of the responses by the time they are responses by the time they are delivered to the initiator SCSI layer.
delivered to the initiator SCSI layer. Since ordering is not Since ordering is not expected across SCSI responses anyway, this
expected across SCSI responses anyway, this approach works fine approach works fine in the general case. However, to address the
in the general case. However to address the special cases where special cases where some ordering is desired by the SCSI layer, the
some ordering is desired by the SCSI layer, the following following "Response Fence" semantics are defined with respect to
"Response Fence" semantics are defined with respect to handling 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 The 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"
Complete" protocol data service ([SAM2], clause 5.4.2) and "Task protocol data service ([SAM2], clause 5.4.2) and "Task Management
Management Function Executed" ([SAM2], clause 6.9) service. On Function Executed" ([SAM2], clause 6.9) service. On receiving the
receiving the SCSI response message, iSCSI layer exhibits the SCSI response message, the iSCSI layer exhibits the Response Fence
Response Fence behavior for certain SCSI response messages behavior for certain SCSI response messages (Section 3.3.3 describes
(section 3.3.3 describes the specific instances where the the specific instances where the semantics must be realized).
semantics must be realized). Whenever the Response Fence Whenever the Response Fence behavior is required for a SCSI response
behavior is required for a SCSI response message, the target message, the target iSCSI layer MUST ensure that the following
iSCSI layer MUST ensure that the following conditions are met in conditions are met in delivering the response message to the
delivering the response message to the initiator iSCSI layer: initiator iSCSI layer:
(1) Response with Response Fence MUST chronologically be (1) Response with Response Fence MUST be delivered chronologically
delivered after all the "preceding" responses on the after all the "preceding" responses on the I_T_L nexus, if the
I_T_L nexus, if the preceding responses are delivered at preceding responses are delivered at all, to the initiator iSCSI
all, to the initiator iSCSI layer. layer.
(2) Response with Response Fence MUST chronologically be (2) Response with Response Fence MUST be delivered chronologically
delivered prior to all the "following" responses on the 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 handoff
hand-off of a response message from the target SCSI protocol of a response message from the target SCSI protocol layer to the
layer to the target iSCSI layer. 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
target iSCSI layer MUST perform the actions described in this iSCSI layer MUST perform the actions described in this section for
section for that session.: 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
is required. Standard SCSI Response PDU build and dispatch required. The 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, the target iSCSI layer
takes note of last-sent and unacknowledged StatSN on each takes note of the 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 an
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)
process) of each such StatSN to clear the fence. The SCSI of each such StatSN to clear the fence. The SCSI response
response requiring Response Fence behavior MUST NOT be sent requiring Response Fence behavior MUST NOT be sent to the
to the initiator before acknowledgements are received for initiator before acknowledgements are received for each of the
each of the unacknowledged StatSNs.. unacknowledged StatSNs.
c) Target iSCSI layer must wait for an acknowledgement of the c) The 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
the Response Fence behavior. The fence MUST be considered Response Fence behavior. The fence MUST be considered cleared
cleared only after receiving the acknowledgement. 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
after clearing the fence. If any new responses for the clearing the fence. If any new responses for the I_T_L nexus
I_T_L nexus are received from the SCSI layer before the are received from the SCSI layer before the fence is cleared,
fence is cleared, those Response PDUs MUST be held and those Response PDUs MUST be held and queued at the iSCSI layer
queued at the iSCSI layer until the fence is cleared. 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
exhaustive enumeration. It is expected that as SCSI protocol enumeration. It is expected that as SCSI protocol specifications
specifications evolve, the specifications will specify when evolve, the specifications will specify when response fencing is
response fencing is required on a case-by-case basis. 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, the target iSCSI
layer MUST assume that Response Fence is required for the layer MUST assume that the 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-
multi-task abort on issuing and third-party sessions. See task abort on issuing and third-party sessions. See Section
section 4.1.1 for related TMF discussion. 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
the issuing session. 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
issuing session. 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-
multi-connection iSCSI sessions to targets complying only with connection iSCSI sessions to targets complying only with [RFC3720].
[RFC3720]. Initiators which want to employ ACA on multi- Initiators that want to employ ACA on multi-connection iSCSI sessions
connection iSCSI sessions SHOULD first assess response fencing SHOULD first assess response-fencing behavior via negotiating for
behavior via negotiating for ResponseFence or FastAbort values ResponseFence or FastAbort values for the TaskReporting (Section 9.1)
for the TaskReporting (section 9.1) key. 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
are a superset of the protocol behavior required in the original superset of the protocol behavior required in the original text and
text and all iSCSI implementations MUST support the new all iSCSI implementations MUST support the new behavior. The updated
behavior. The updated semantics (section 4.1.3) on the other semantics (Section 4.1.3) on the other hand are mandatory only when
hand are mandatory only when the new key TaskReporting (section 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
task abort scenarios. Scope definitions in this section apply abort scenarios. Scope definitions in this section apply to both the
to both the clarified protocol behavior (section 4.1.2) and the clarified protocol behavior (Section 4.1.2) and the updated protocol
updated protocol behavior (section 4.1.3). 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
Request PDU. 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
the LU identified by the LUN field in the CLEAR TASK SET identified by the LUN field in the CLEAR TASK SET TMF Request
TMF Request PDU. See [SPC3] for the definition of a "task 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
initiators for the LU identified by the LUN field in the the LU identified by the LUN field in the LOGICAL UNIT RESET
LOGICAL UNIT RESET Request PDU. Request PDU.
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from
from all initiators across all LUs to which the TMF-issuing all initiators across all LUs to which the TMF-issuing session
session has access to on the SCSI target device hosting the has access 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
is an iSCSI TMF Request PDU with the "Function" field set to an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK
"ABORT TASK SET" as defined in [RFC3720]. Similar usage is SET" as defined in [RFC3720]. Similar usage is employed for other
employed for other scope descriptions. 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
defined in this section as the default behavior. The execution in this section as the default behavior. The execution of ABORT TASK
of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and
WARM RESET, and TARGET COLD RESET TMF Requests consists of the TARGET COLD RESET TMF Requests consists of the following sequence of
following sequence of actions in the specified order on the 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
affected tasks. tasks.
b. SHOULD process any responses received for affected tasks in b. SHOULD process any responses received for affected tasks in the
the normal fashion. This is acceptable because the normal fashion. This is acceptable because the responses are
responses are guaranteed to have been sent prior to the TMF 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
the set of affected tasks unless the initiator has done set of affected tasks unless the initiator has done something
something (e.g.,LU reset, connection drop) that may prevent (e.g., LU reset, connection drop) that may prevent the TMF
the TMF Response from being sent or received. The Response from being sent or received. The initiator MUST thus
initiator MUST thus conclude all affected tasks as part of conclude all affected tasks as part of this step in either
this step in either case, and MUST discard any TMF Response case, and MUST discard any TMF Response received after the
received after the affected tasks are concluded. 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
tags of the affected tasks from the issuing initiator. MAY of the affected tasks from the issuing initiator. MAY wait for
wait for responses on currently valid target transfer tags responses on currently valid target-transfer tags of the
of the affected tasks from third-party initiators. 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
commands of the affected tasks to be received based on the of the affected tasks to be received based on the CmdSN
CmdSN ordering. SHOULD NOT wait for new commands on ordering. SHOULD NOT wait for new commands on third-party
third-party affected sessions - only the instantiated tasks affected sessions -- only the instantiated tasks have to be
have to be considered for the purpose of determining the considered for the purpose of determining the affected tasks.
affected tasks. In the case of target-scoped requests In the case of target-scoped requests (i.e., TARGET WARM RESET
(i.e. TARGET WARM RESET and TARGET COLD RESET), all the and TARGET COLD RESET), all of the commands that are not yet
commands that are not yet received on the issuing session received on the issuing session in the command stream however
in the command stream however can be considered to have can be considered to have been received with no command waiting
been received with no command waiting period - i.e. the period -- i.e., the entire CmdSN space up to the CmdSN of the
entire CmdSN space up to the CmdSN of the task management 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
from the target SCSI layer. the target SCSI layer.
d. MUST provide Response Fence behavior for the TMF Response d. MUST provide the Response Fence behavior for the TMF Response
on issuing session as specified in 3.3.2. on the issuing session as specified in Section 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
TMF Response on third-party sessions as specified in 3.3.2. Response on third-party sessions as specified in Section 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
the means by which the target ensures that all affected means by which the target ensures that all affected tasks have
tasks have returned their status to the initiator are returned their status to the initiator are defined by the
defined by the specific non-iSCSI transport protocol(s). 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
transfers corresponding to terminated tasks may however still be corresponding to terminated tasks may however still be in progress on
in progress on third-party iSCSI sessions even at the end of third-party iSCSI sessions even at the end of Step e. The TMF
Step.e. TMF Response MUST NOT be sent by the target iSCSI layer Response MUST NOT be sent by the target iSCSI layer before the end of
before the end of Step.d, and MAY be sent at the end of Step.d Step d, and MAY be sent at the end of Step d despite these
despite these outstanding data transfers until after Step.e. 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
all iSCSI implementations complying with this document. iSCSI implementations complying with this document. Protocol
Protocol behavior defined in this section MUST be exhibited by behavior defined in this section MUST be exhibited by iSCSI
iSCSI implementations on an iSCSI session when they negotiate implementations on an iSCSI session when they negotiate the
the TaskReporting (section 9.1) key to "FastAbort" on that TaskReporting (Section 9.1) key to "FastAbort" on that session. The
session. The execution of ABORT TASK SET, CLEAR TASK SET, execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET,
LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the
Requests consists of the following sequence of actions in the following sequence of actions in the specified order on the specified
specified order on the specified party. 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
the issuing connection of the issuing iSCSI session once issuing connection of the issuing iSCSI session once the TMF is
the TMF is sent to the target. 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
the normal fashion. This is acceptable because the normal fashion. This is acceptable because the responses are
responses are guaranteed to have been sent prior to the TMF 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
tasks for which responses have not been received, and MUST for which responses have not been received, and MUST discard
discard any responses for affected tasks received after the any responses for affected tasks received after the TMF
TMF response is passed to the SCSI layer (although the response is passed to the SCSI layer (although the semantics
semantics defined in this section ensure that such an out defined in this section ensure that such an out-of-order
of order scenario will never happen with a compliant target 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
received based on the CmdSN ordering on the issuing based on the CmdSN ordering on the issuing session. SHOULD NOT
session. SHOULD NOT wait for new commands on third-party wait for new commands on third-party affected sessions -- only
affected sessions - only the instantiated tasks have to be the instantiated tasks have to be considered for the purpose of
considered for the purpose of determining the affected determining the affected tasks. In the case of target-scoped
tasks. In the case of target-scoped requests (i.e. TARGET requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all
WARM RESET and TARGET COLD RESET), all the commands that the commands that are not yet received on the issuing session
are not yet received on the issuing session in the command in the command stream can be considered to have been received
stream can be considered to have been received with no with no command waiting period -- i.e., the entire CmdSN space
command waiting period - i.e. the entire CmdSN space up to up to the CmdSN of the task management function can be
the CmdSN of the task management function can be "plugged". "plugged".
b. MUST propagate the TMF request to and receive the response b. MUST propagate the TMF request to and receive the response from
from the target SCSI layer. the target SCSI layer.
c. MUST leave all active "affected TTTs" (i.e. active TTTs c. MUST leave all active "affected TTTs" (i.e., active TTTs
associated with affected tasks) valid. associated with affected tasks) valid.
d. MUST 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
party session, and 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),
reset), then one Async Message PDU MUST be sent for each then one Async Message PDU MUST be sent for each such LU on each
such LU on each connection that has at least one allegiant connection that has at least one allegiant affected task. The LUN
affected task. The LUN field in the Asynchronous Message field in the Asynchronous Message PDU MUST be set to match the LUN
PDU MUST be set to match the LUN for each such LU. 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 the
issuing session as defined in 3.3.2. issuing session as defined in Section 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 Section 3.3.2.
some tasks originate from non-iSCSI I_T_L nexuses then the If some tasks originate from non-iSCSI I_T_L nexuses, then the
means by which the target ensures that all affected tasks means by which the target ensures that all affected tasks have
have returned their status to the initiator are defined by returned their status to the initiator are defined by the
the specific non-iSCSI transport protocol(s). 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
and the corresponding buffers, if any, once it receives the corresponding buffers, if any, once it receives each
each associated Nop-Out acknowledgement that the initiator associated NOP-Out acknowledgement that the initiator generated
generated in response to each Async Message. 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
transfers corresponding to terminated tasks may however still be corresponding to terminated tasks may however still be in progress
in progress even at the end of Step.f. TMF Response MUST NOT be even at the end of Step f. A TMF Response MUST NOT be sent by the
sent by the target iSCSI layer before the end of Step.e, and MAY target iSCSI layer before the end of Step e, and MAY be sent at the
be sent at the end of Step.e despite these outstanding Data end of Step e despite these outstanding Data transfers until Step g.
transfers until Step.g. Step.g specifies an event to free up Step g specifies an event to free up any such resources that may have
any such resources that may have been reserved to support 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
target and LU resets on "Incomplete TTTs" as "Y". This meant and LU resets on "Incomplete TTTs" as "Y". This meant that a target
that a target warm reset or a target cold reset or an LU reset warm reset or a target cold reset or an LU reset would clear the
would clear the active TTTs upon completion. The active TTTs upon completion. However, the TaskReporting=FastAbort
TaskReporting=FastAbort (section 9.1) semantics defined by this (Section 9.1) semantics defined by this section do not guarantee that
section however do not guarantee that the active TTTs are the active TTTs are cleared by the end of the reset operations. In
cleared by the end of the reset operations. In fact, the new fact, the new semantics are designed to allow clearing the TTTs in a
semantics are designed to allow clearing the TTTs in a "lazy" "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 clearing
TaskReporting=FastAbort is operational on a session, the effects of reset operations on "Incomplete TTTs" is "N".
clearing effects of reset operations on "Incomplete TTTs" is
"N".
4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions 4.1.4. Affected Tasks Shared across RFC 3720 and 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
up in a situation where some sessions have TaskReporting=RFC3720 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
while accessing a shared set of affected tasks (section 4.1.1). 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 an RFC 3720 session, the iSCSI target
implementation is FastAbort-capable and third-party affected implementation is FastAbort-capable, and the 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 the 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
which at least one affected task is allegiant. If there least one affected task is allegiant. If there are multiple
are multiple affected LUs, then send one Async Message PDU affected LUs, then send one Async Message PDU for each such LU
for each such LU on each connection that has at least one on each connection that has at least one allegiant affected
allegiant affected task. When sent, the LUN field in the task. When sent, the LUN field in the Asynchronous Message PDU
Asynchronous Message PDU MUST be set to match the LUN for 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 the 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
implementation is FastAbort-capable and third-party affected
session is a RFC3720 session, the following behavior MUST be
exhibited by the iSCSI target layer: Asynchronous Message PDUs
MUST NOT be sent on the third-party session to prompt the
FastAbort behavior.
If the third-party affected session is a FastAbort session and If the issuing session is a FastAbort session, the iSCSI target
issuing session is a FastAbort session, initiator in the third- implementation is FastAbort-capable, and the third-party affected
party role MUST respond to each Async Message PDU with session is an RFC 3720 session, the following behavior MUST be
AsyncEvent=5 as defined in section 8.1. Note that an initiator exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST
MAY thus receive these Async Messages on a third-party affected NOT be sent on the third-party session to prompt the FastAbort
session even if the session is a single-connection session. behavior.
4.1.5 Implementation considerations If the third-party affected session is a FastAbort session and the
issuing session is a FastAbort session, the initiator in the third-
party role MUST respond to each Async Message PDU with AsyncEvent=5
as defined in Section 8.1. Note that an initiator MAY thus receive
these Async Messages on a third-party affected session even if the
session is a single-connection session.
Both in clarified semantics (section 4.1.2) and updated 4.1.5. Implementation Considerations
semantics (section 4.1.3), there may be outstanding data
transfers even after the TMF completion is reported on the
issuing session. In the case of iSCSI/iSER [iSER], these would
be tagged data transfers for STags not owned by any active
tasks. Whether or not real buffers support these data transfers
is implementation-dependent. However, the data transfers
logically MUST be silently discarded by the target iSCSI layer
in all cases. A target MAY, on an implementation-defined Both in clarified semantics (Section 4.1.2) and updated semantics
internal timeout, also choose to drop the connections on which (Section 4.1.3), there may be outstanding data transfers even after
it did not receive the expected Data-out sequences (section the TMF completion is reported on the issuing session. In the case
4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to of iSCSI/iSER [iSER], these would be tagged data transfers for STags
reclaim the associated buffer, STag and TTT resources as not owned by any active tasks. Whether or not real buffers support
appropriate. these data transfers is implementation-dependent. However, the data
transfers logically MUST be silently discarded by the target iSCSI
layer in all cases. A target MAY, on an implementation-defined
internal timeout, also choose to drop the connections on which it did
not receive the expected Data-Out sequences (Section 4.1.2) or NOP-
Out acknowledgements (Section 4.1.3) so as to reclaim the associated
buffer, STag, and TTT resources as 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
semantics specified in section 4.1.2 and section 4.1.3. specified in Sections 4.1.2 and 4.1.3.
1. Maintaining an ordered command flow I_T nexus abstraction 1. Maintaining an ordered command flow I_T nexus abstraction to
to the target SCSI layer even with multi-connection 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
the single flow illusion. Target behavior in Step.b single flow illusion. Target behavior in Step b of Section
of section 4.1.2 and Step.a of section 4.1.3 4.1.2 and Step a of Section 4.1.3 correspond to this
correspond to this objective. 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 The target must ensure that the initiator does not see "old"
"old" task responses (that were placed on the wire task responses (that were placed on the wire chronologically
chronologically earlier than the TMF Response) after earlier than the TMF Response) after seeing the TMF
seeing the TMF response. Target behavior in Step.d of response. The target behavior in Step d of Section 4.1.2
section 4.1.2 and Step.e of section 4.1.3 correspond 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
device server to trigger a UA on each of the other server to trigger a UA on each of the other I_T_L nexuses.
I_T_L nexuses. Once an initiator is notified of such Once an initiator is notified of such an UA, the application
an UA, the application client on the receiving client on the receiving initiator is required to clear its
initiator is required to clear its task state (clause task state (clause 5.5 in [SAM2]) for the affected tasks.
5.5 in [SAM2]) for the affected tasks. It would thus It would thus be inappropriate to deliver a SCSI Response
be inappropriate to deliver a SCSI Response for a task for a task after the task state is cleared on the initiator,
after the task state is cleared on the initiator, i.e. 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 affected
contained in the first SCSI Response PDU on each Third-party I_T_L nexus after the TMF action thus MUST NOT
affected Third-party I_T_L nexus after the TMF action pass the affected task responses on any of the iSCSI
thus MUST NOT pass the affected task responses on any sessions accessing the LU. The target behavior in Step e of
of the iSCSI sessions accessing the LU. Target Section 4.1.2 and Step f of Section 4.1.3 correspond to this
behavior in Step.e of section 4.1.2 and Step.f of 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
in a deterministic fashion. 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
are terminated can create a buffer management problem terminated can create a buffer management problem even for
even for traditional iSCSI implementations, and is traditional iSCSI implementations, and is fatal for the
fatal for the connection for iSCSI/iSER connection for iSCSI/iSER implementations. Either the
implementations. Either the termination of affected termination of affected tasks should be postponed until the
tasks should be postponed until the TTTs are retired TTTs are retired (as in Step a of Section 4.1.2), or the
(as in Step.a of section 4.1.2), or the TTTs and the TTTs and the buffers should stay allocated beyond task
buffers should stay allocated beyond task termination termination to be deterministically freed up later (as in
to be deterministically freed up later (as in Step.c Steps c and 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
tasks on an I_T nexus will be aborted anyway (as with a target an I_T nexus will be aborted anyway (as with a target reset), there
reset), there is no need to wait to receive all commands to plug is no need to wait to receive all commands to plug the CmdSN holes.
the CmdSN holes. Target iSCSI layer can simply plug all missing The target iSCSI layer can simply plug all missing CmdSN slots and
CmdSN slots and move on with TMF processing. The first move on with TMF processing. The first objective (maintaining a
objective (maintaining a single ordered command flow) is still single ordered command flow) is still met with this optimization
met with this optimization because target SCSI layer only sees because the 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
for Discovery sessions - i.e. for sessions that negotiated 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
When such a negotiation attempt is made by the remote side, a such a negotiation attempt is made by the remote side, a compliant
compliant iSCSI implementation MUST propose a value of 0 (zero) iSCSI implementation MUST propose a value of 0 (zero) in response.
in response. The operational ErrorRecoveryLevel for Discovery The operational ErrorRecoveryLevel for Discovery sessions thus MUST
sessions thus MUST be 0. This naturally follows from the be 0. This naturally follows from the functionality constraints that
functionality constraints [RFC3720] imposes on Discovery [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
sessions to the same iSCSI Network Portal (see [RFC3720]). An to the same iSCSI Network Portal (see [RFC3720]). An initiator may
initiator may use the same iSCSI Initiator Name and ISID when use the same iSCSI Initiator Name and ISID when establishing
establishing different unique sessions with different targets different unique sessions with different targets and/or different
and/or different portal groups. This behavior is discussed in portal groups. This behavior is discussed in Section 9.1.1 of
Section 9.1.1 of [RFC3720] and is, in fact, encouraged as [RFC3720] and is, in fact, encouraged as conservative reuse of ISIDs.
conservative reuse of ISIDs. ISID RULE in [RFC3720] states that The ISID RULE in [RFC3720] states that there must not be more than
there must not be more than one session with a matching 4-tuple: one session with a matching 4-tuple: <InitiatorName, ISID,
<InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While TargetName, TargetPortalGroupTag>. While the spirit of the ISID RULE
the spirit of the ISID RULE applies to Discovery sessions the applies to Discovery sessions the same as it does for Normal
same as it does for Normal sessions, note that some Discovery sessions, note that some Discovery sessions differ from the Normal
sessions differ from the Normal sessions in two important sessions in two important aspects:
aspects:
Because [RFC3720] allows a Discovery session to be Because [RFC3720] allows a Discovery session to be established
established without specifying a TargetName key in the without specifying a TargetName key in the Login Request PDU (let
Login Request PDU (let us call such a session an "Unnamed" us call such a session an "Unnamed" Discovery session), there is
Discovery session), there is no Target Node context to 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.
Node. When the TargetName key is NULL-valued (i.e. not When the TargetName key is NULL-valued (i.e., not specified), the
specified), the TargetPortalGroupTag thus cannot be TargetPortalGroupTag thus cannot be ascertained to enforce the
ascertained to enforce the ISID RULE. ISID RULE.
The following sections describe the two scenarios - Named The following sections describe the two scenarios -- Named Discovery
Discovery sessions and Unnamed Discovery sessions - separately. 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
enforce the ISID RULE. So the following rule applies. 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,
<InitiatorName, ISID, NULL, TargetAddress>. The following ISID, NULL, TargetAddress>. The following semantics are implied by
semantics are implied by this uniqueness requirement. 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
port with a given iSCSI Node Name and an ISID. Each of the with a given iSCSI Node Name and an ISID. Each of the concurrent
concurrent Discovery sessions, if established by the same Discovery sessions, if established by the same initiator port to
initiator port to other Network Portals, MUST be treated as other Network Portals, MUST be treated as independent sessions --
independent sessions - i.e. one session MUST NOT reinstate the 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,
<InitiatorName, ISID, NULL, TargetAddress> to an existing ISID, NULL, TargetAddress> to an existing Discovery session MUST
discovery session MUST reinstate the existing Unnamed Discovery reinstate the existing Unnamed Discovery session. Note thus that
session. Note thus that only an Unnamed Discovery session may only an Unnamed Discovery session may reinstate an Unnamed Discovery
reinstate an Unnamed Discovery session. 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
by the initiator and thus the target can unambiguously ascertain initiator and thus the target can unambiguously ascertain the
the TargetPortalGroupTag as well. Since all the four elements TargetPortalGroupTag as well. Since all the four elements of the 4-
of the 4-tuple are known, the ISID RULE MUST be enforced by tuple are known, the ISID RULE MUST be enforced by targets with no
targets with no changes from [RFC3720] semantics. A new session changes from [RFC3720] semantics. A new session with a matching
with a matching <InitiatorName, ISID, TargetName, <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will
TargetPortalGroupTag> thus will reinstate an existing session. reinstate an existing session. Note in this case that any new iSCSI
Note in this case that any new iSCSI session (Discovery or session (Discovery or Normal) with the matching 4-tuple may reinstate
Normal) with the matching 4-tuple may reinstate an existing 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
and Logout Response on a Discovery session, once in full feature 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
a Discovery session when it would have requested a Logout via an Discovery session when it would have requested a Logout via an Async
Async Message on Normal sessions. 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 a zero value is expressly allowed as a legal value for
for TPGT. This discrepancy currently stands corrected in 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
the target. The target may accept or reject the offer. target. The target may accept or reject the offer. Depending on the
Depending on the type of the session, a target may decide on type of the session, a target may decide on resources to allocate and
resources to allocate and the security to enforce etc. for the the security to enforce, etc. for the session. If the SessionType
session. If the SessionType key is thus going to be offered as key is thus going to be offered as "Discovery", it SHOULD be offered
"Discovery", it SHOULD be offered in the initial Login request 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
NotUnderstood has the reserved meaning that the sending side did has the reserved meaning that the sending side did not understand the
not understand the proposed key semantics. This section seeks proposed key semantics. This section seeks to clarify that
to clarify that NotUnderstood is a valid answer for both NotUnderstood is a valid answer for both declarative and negotiated
declarative and negotiated keys. The general iSCSI philosophy keys. The general iSCSI philosophy is that comprehension precedes
is that comprehension precedes processing for any iSCSI key. A processing for any iSCSI key. A proposer of an iSCSI key, negotiated
proposer of an iSCSI key, negotiated or declarative, in a text or declarative, in a text key exchange MUST thus be able to properly
key exchange MUST thus be able to properly handle a 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
where the key is specified and whether the key is declarative the key is specified and whether the key is declarative vs.
vs. negotiated. All keys defined in [RFC3720] MUST be supported negotiated. All keys defined in [RFC3720] MUST be supported by all
by all compliant implementations; a NotUnderstood answer on any compliant implementations; a NotUnderstood answer on any of the
of the [RFC3720] keys therefore MUST be considered a protocol [RFC3720] keys therefore MUST be considered a protocol error and
error and handled accordingly. For all other later keys, a handled accordingly. For all other later keys, a NotUnderstood
NotUnderstood answer concludes the negotiation for a negotiated answer concludes the negotiation for a negotiated key whereas for a
key whereas for a declarative key, a NotUnderstood answer simply declarative key, a NotUnderstood answer simply informs the declarer
informs the declarer of lack of comprehension by the receiver. of a 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 not be used within the
the scope of the key (connection/session) by either side. 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
Login Response PDUs on a connection. [RFC3720] offers the Response PDUs on a connection. [RFC3720] offers the analogy of SCSI
analogy of SCSI linked commands to Login and Text negotiations linked commands to Login and Text negotiations in Sections 5.3 and
in sections 5.3 and 10.10.3 respectively, but does not make it 10.10.3, respectively, but does not make it fully explicit. This
fully explicit. This section is to offer a clarification in 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, Login
Login Response or Text Request or Text Response PDU on an iSCSI Response, Text Request, or Text Response PDU on an iSCSI connection.
connection. An outstanding PDU in this context is one that has An outstanding PDU in this context is one that has not been
not been acknowledged by the remote iSCSI side. 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 An ITT value of 0xffffffff is reserved and MUST NOT be assigned for a
here again for making it obvious since the semantics apply to task by the initiator. The only instance in which it may be seen on
the initiators in general. An ITT value of 0xffffffff is the wire is in a target-initiated NOP-In PDU (and in the initiator
reserved and MUST NOT be assigned for a task by the initiator. response to that PDU, if necessary). Section 10.19 in [RFC3720]
The only instance it may be seen on the wire is in a target- mentions this in passing but is noted here again to make it obvious
initiated NOP-In PDU (and in the initiator response to that PDU since the semantics apply to the initiators in general.
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
noted in [RFC3720]. [RFC3720].
All initiator-detected PDU construction errors MUST be All initiator-detected PDU construction errors MUST be considered as
considered as format errors. Some examples of such errors are: 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
states that "No further action is necessary for initiators if that "No further action is necessary for initiators if the discarded
the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a
on detecting a payload digest error. This is incorrect. 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
StatSN value on an iSCSI connection, advancing the StatSN. When value on an iSCSI connection, advancing the StatSN. When an
an initiator discards one of these PDUs due to a payload digest initiator discards one of these PDUs due to a payload digest error,
error, the entire PDU including the header MUST be discarded. the entire PDU including the header MUST be discarded. Consequently,
Consequently, the initiator MUST treat the exception like a loss the initiator MUST treat the exception like a loss of any other
of any other solicited response PDU - i.e. it MUST use one of solicited response PDU -- i.e., it MUST use one of the following
the following options noted in [RFC3720]: 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
tasks on a different connection instance. 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
section addresses that question. addresses this question.
Unless [RFC3720] or this draft requires it, an iSCSI Unless [RFC3720] or this document 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 check on an incoming iSCSI PDU. The iSCSI implementation
implementation especially is not required to double-check the especially is not required to double-check the remote iSCSI
remote iSCSI implementation's conformance to protocol 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 the AsyncEvent is defined:
5: all active tasks for LU with matching LUN field in the Async 5: all active tasks for LU with a 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
by taking the following steps in order. 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
TTTs for the affected LUN quoted in the Async Message for the affected LUN quoted in the Async Message PDU.
PDU.
ii)Acknowledge the StatSN of the Async Message PDU via a
Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor),
while copying the LUN field from Async Message to Nop-
Out.
The new AsyncEvent defined in this section however MUST NOT be ii) Acknowledge the StatSN of the Async Message PDU via a NOP-Out
used on an iSCSI session unless the new TaskReporting text key PDU with ITT=0xffffffff (i.e., non-ping flavor), while copying
defined in section 9.1 was negotiated to FastAbort on the the LUN field from the Async Message to NOP-Out.
session.
8.2 Reject The new AsyncEvent defined in this section however MUST NOT be used
on an iSCSI session unless the new TaskReporting text key defined in
Section 9.1 was negotiated to FastAbort on the session.
Section 10.17.1 of [RFC3720] specifies the Reject reason code of 8.2. Reject
0x0b with an explanation of "Negotiation Reset". At this point,
we do not see any legitimate iSCSI protocol use case for using Section 10.17.1 of [RFC3720] specifies the Reject reason code of 0x0b
this reason code. Thus reason code 0x0b MUST be considered as with an explanation of "Negotiation Reset". At this point, we do not
deprecated and MUST NOT be sent by implementations that see any legitimate iSCSI protocol use case for using this reason
comply with the requirements of this document. An code. Thus, reason code 0x0b MUST be considered as deprecated and
implementation receiving reason code 0x0b MUST treat it as a MUST NOT be sent by implementations that comply with the requirements
negotiation failure that terminates the Login phase and the TCP of this document. An implementation receiving reason code 0x0b MUST
connection, as specified in Section 6.10 of [RFC3720]. treat it as a negotiation failure that terminates the Login Phase and
the TCP connection, as specified in Section 6.10 of [RFC3720].
Section 5.4 of [RFC3720] states: 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
declare or negotiate a parameter more than once during any negotiate a parameter more than once during any negotiation
negotiation sequence without an intervening operational sequence without an intervening operational parameter negotiation
parameter negotiation reset, except for responses to reset, except for responses to specific keys that explicitly allow
specific keys that explicitly allow repeated key 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
of an operational parameter negotiation reset, causing operational parameter negotiation reset, causing the phrase "without
the phrase "without an intervening operational an intervening operational parameter negotiation reset" in [RFC3720]
parameter negotiation reset" in [RFC3720] to refer to an to refer to an impossible event. The quoted phrase SHOULD be ignored
impossible event. The quoted phrase SHOULD be ignored by by receivers that handle reason code 0x0b in the manner specified in
receivers that handle reason code 0x0b in the manner specified 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
semantics from the SCSI target. Following table describes the from the SCSI target. The following table describes the semantics
semantics an iSCSI target MUST support for respective negotiated that an iSCSI target MUST support for respective negotiated key
key values. Whenever this key is negotiated, at least the values. Whenever this key is negotiated, at least the RFC3720 and
RFC3720 and ResponseFence values MUST be offered as options by ResponseFence values MUST be offered as options by the negotiation
the negotiation originator. 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
TMF semantics as clarified in section 4.1.2 MUST be used. 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
the iSCSI-related security text in [RFC3723] is also directly iSCSI-related security text in [RFC3723] is also directly applicable
applicable to this document. 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 document creates the following iSCSI-related registries for IANA
IANA to manage. 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 registry, its sub-
its sub-registries if any and their administration policies in registries if any, and their administration policies in more detail.
more detail. IANA may publish what this document calls the main IANA has registered what this document calls the main "registries" as
"registries" as sub-registries of a larger iSCSI registry if sub-registries of a larger iSCSI registry. However, wherever
doing so is appropriate. However, wherever registry-to-sub- registry-to-sub-registry relationships are specified by this
registry relationships are specified by this document, they must document, they have been preserved intact.
be preserved intact in the new hierarchy by the end of the IANA
publication process.
[RFC3720] specifies three iSCSI-related registries - extended [RFC3720] specifies three iSCSI-related registries -- extended key,
key, authentication methods, digests. This document recommends authentication methods, and digests. This document recommends that
that those registries be published together with the registries these registries be published together with the registries defined by
defined by this document. Further, this document recommends this document. Further, this document recommends that the three
that the three [RFC3720] registries be listed in between [RFC3720] registries be listed in between items 6 and 7 in the
registry item no. 6 and registry item no. 7 in the registry list registry list above.
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
with most significant two bits (bits 0 and 1) already designated the most significant two bits (bits 0 and 1) already designated by
by [RFC3720], bit 0 being reserved and bit 1 for immediate [RFC3720], bit 0 being reserved and bit 1 for immediate delivery.
Bit 2 is designated to identify the originator of the opcode. Bit 2
delivery. Bit 2 is designated to identify the originator of the = 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 IESG-
IESG-approved standards-track specification defining the approved standards-track specification defining the semantics and
semantics and interoperability requirements of the proposed new interoperability requirements of the proposed new value and the
value and the fields to be recorded in the registry fields to be recorded in the registry.
Allocation request guidance to requesters: Allocation request guidance to requesters:
1) If initiator opcode and target opcode to identify the request 1) If the initiator opcode and target opcode used to identify the
and response of a new type of protocol operation are requested, request and response of a new type of protocol operation are
assign the same lower five bits (i.e. Bit 3 through Bit 7) for requested, assign the same lower five bits (i.e., Bit 3 through
both opcodes, e.g. 0x13 and 0x33 Bit 7) for both opcodes, e.g., 0x13 and 0x33.
2) If only the initiator opcode or target opcode is requested to 2) If only the initiator opcode or target opcode is requested to
identify a one-way protocol message (i.e. request without a identify a one-way protocol message (i.e., request without a
response or a "response" without a request), assign an unused response or a "response" without a request), assign an unused
number from the appropriate category (i.e. Bit 2 set to 0 or 1 number from the appropriate category (i.e., Bit 2 set to 0 or 1
for initiator category or target category) and add the other for initiator category or target category) and add the other
pair member (i.e. same opcode with Bit 2 set to 1 or 0, pair member (i.e., same opcode with Bit 2 set to 1 or 0,
respectively) to "Reserved to IANA" list. respectively) to "no opcode pair is available" list.
3) If there are no other opcodes available to assign on a
request for a new opcode except the reserved opcodes in the
"Reserved to IANA" list, allocate the opcodes from the
appropriate category (initiator or target).
Notes to IANA:
- Publish the preceding Allocation request guidance verbatim in
the registry
- Use the Expert Review process ([IANA]) to ensure that 3) If there are no other opcodes available in the appropriate
compliance with the Allocation request guidance is met "Reserved to IANA" list to assign on a request for a new opcode
except the reserved opcodes in the "no opcode pair is
available" list, allocate the opcode from the appropriate
category (initiator or target) of the "no opcode pair is
available" list.
Fields to record in the registry: Assigned value, Who can Fields to record in the registry: Assigned value, Who can originate
originate (Initiator or Target), Operation Name and its (Initiator or Target), Operation Name, and its associated RFC
associated RFC reference reference.
Initial registry contents: Initial registry contents:
0x00, Initiator, NOP-Out, [RFC3720] 0x00, Initiator, NOP-Out, [RFC3720]
0x01, Initiator, SCSI Command, [RFC3720] 0x01, Initiator, SCSI Command, [RFC3720]
0x02, Initiator, SCSI Task Management function request, 0x02, Initiator, SCSI Task Management function request, [RFC3720]
[RFC3720]
0x03, Initiator, Login Request, [RFC3720] 0x03, Initiator, Login Request, [RFC3720]
0x04, Initiator, Text Request, [RFC3720] 0x04, Initiator, Text Request, [RFC3720]
0x05, Initiator, SCSI Data-Out, [RFC3720] 0x05, Initiator, SCSI Data-Out, [RFC3720]
0x06, Initiator, Logout Request, [RFC3720] 0x06, Initiator, Logout Request, [RFC3720]
0x10, Initiator, SNACK Request, [RFC3720] 0x10, Initiator, SNACK Request, [RFC3720]
skipping to change at page 38, line 48 skipping to change at page 28, line 28
0x26, Target, Logout Response, [RFC3720] 0x26, Target, Logout Response, [RFC3720]
0x31, Target, Ready To Transfer (R2T), [RFC3720] 0x31, Target, Ready To Transfer (R2T), [RFC3720]
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:
0x07-0x0f, 0x13-0x1b (initiator codes)
0x27-0x2f, 0x33-0x3b (target codes)
No opcode pair is available:
0x11, 0x12, 0x1f (initiator codes)
0x30 (target codes)
Allocation Policy: Allocation Policy:
Standards Action ([IANA]): This is required for defining the Standards Action ([IANA]): This is required for defining the
semantics of the opcode semantics of the opcode.
Expert Review ([IANA]): This is required for selecting the Expert Review ([IANA]): This is required for selecting the specific
specific opcode(s) to allocate in order to ensure compliance opcode(s) to allocate in order to ensure compliance with the earlier
with the earlier "Allocation request guidance to requesters" "Allocation request guidance to requesters".
11.3 iSCSI Login/Text Keys 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,
Unicode, and the permissible "value" options for the "Key" are and the permissible "value" options for the "Key" are Key-dependent.
Key-dependent. [RFC3720] defines the rules on key names and [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-
IESG-approved standards-track specification defining the approved standards-track specification defining the semantics and
semantics and interoperability requirements of the proposed new interoperability requirements of the proposed new Key per [RFC3720]
Key per [RFC3720] key specification template and the fields to key specification template and the fields to be recorded in the
be recorded in the registry registry.
Assignment policy: Assignment policy:
If the requested Key name is not already assigned and is roughly If the requested Key name is not already assigned and is roughly
representative of its proposed semantics, it may be assigned to representative of its proposed semantics, it may be assigned to the
the requester. requester.
Given the arbitrary nature of text strings, there is no maximum Given the arbitrary nature of text strings, there is no maximum
reserved by IANA for assignment in this registry. reserved by IANA for assignment in this registry.
Fields to record in the registry: Assigned Key Name and its Fields to record in the registry: Assigned Key Name and its
associated RFC reference associated RFC reference.
Initial registry contents: Initial registry contents:
AuthMethod, [RFC3720] AuthMethod, [RFC3720]
HeaderDigest, [RFC3720] HeaderDigest, [RFC3720]
DataDigest, [RFC3720] DataDigest, [RFC3720]
MaxConnections, [RFC3720] MaxConnections, [RFC3720]
skipping to change at page 41, line 13 skipping to change at page 30, line 36
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: An IESG-
approved standards-track specification defining the semantics approved standards-track specification defining the semantics and
and interoperability requirements of the proposed new Event and interoperability requirements of the proposed new Event and the
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
assigned to the requester. the requester.
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
Description and its associated RFC reference 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]
skipping to change at page 42, line 21 skipping to change at page 31, line 32
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-
IESG-approved standards-track specification defining the approved standards-track specification defining the semantics and
semantics and interoperability requirements of the proposed new interoperability requirements of the proposed new Code and the fields
Code and the fields to be recorded in the registry 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
assigned to the requester. the requester.
9-127: range reserved by IANA for assignment in this registry 9-127: 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
its associated RFC reference 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]
skipping to change at page 43, line 19 skipping to change at page 32, line 27
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
Class except for Vendor-Unique Status-Class (0x0f) 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-
IESG-approved specification defining the semantics and approved specification defining the semantics and interoperability
interoperability requirements of the proposed new Code, its requirements of the proposed new Code, its Status-Class affiliation
Status-Class affiliation (only if a new Status-Detail value is (only if a new Status-Detail value is being proposed for a Status-
being proposed for a Status-Class), Status-Class definition Class), Status-Class definition (only if a new Status-Class is being
(only if a new Status-Class is being proposed) and the fields to proposed), and the fields to be recorded in the registry.
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
assigned to the requester. the requester.
4-14 and 16-255: range reserved by IANA for assignment in this 4-14 and 16-255: range reserved by IANA for assignment in this
registry registry.
Fields to record in the Status-Class main registry: Assigned Fields to record in the Status-Class main registry: Assigned Code,
Code, Description and its associated RFC reference Description, and its associated RFC reference.
Fields to record in the Status-Detail sub-registries: Status- Fields to record in the Status-Detail sub-registries: Status-Class,
Class, Assigned Code, Description and its associated RFC Assigned Code, Description, and its associated RFC reference.
reference
Initial registry contents (Status-Class): Initial registry contents (Status-Class):
0x00, Success, [RFC3720] 0x00, Success, [RFC3720]
0x01, Redirection, [RFC3720] 0x01, Redirection, [RFC3720]
0x02, Initiator Error, [RFC3720] 0x02, Initiator Error, [RFC3720]
0x03, Target Error, [RFC3720] 0x03, Target Error, [RFC3720]
0x0f, Vendor-Unique, this document 0x0f, Vendor-Unique, this document
Initial sub-registry contents (Status-Detail for Status- Initial sub-registry contents (Status-Detail for Status-Class=0x00):
Class=0x00):
0x00, 0x00, Success, [RFC3720] 0x00, 0x00, Success, [RFC3720]
1-255: range reserved by IANA for assignment in Status-Class=0 1-255: range reserved by IANA for assignment in Status-Class=0 sub-
sub-registry registry.
Initial sub-registry contents (Status-Detail for Status- Initial sub-registry contents (Status-Detail for Status-Class=0x01):
Class=0x01):
0x01, 0x01, Temporary move, [RFC3720] 0x01, 0x01, Temporary move, [RFC3720]
0x01, 0x02, Permanent move, [RFC3720] 0x01, 0x02, Permanent move, [RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=1 3-255: range reserved by IANA for assignment in Status-Class=1 sub-
sub-registry registry.
Initial sub-registry contents (Status-Detail for Status- Initial sub-registry contents (Status-Detail for Status-Class=0x02):
Class=0x02):
0x02, 0x00, Miscellaneous, [RFC3720] 0x02, 0x00, Miscellaneous, [RFC3720]
0x02, 0x01, Authentication failure, [RFC3720] 0x02, 0x01, Authentication failure, [RFC3720]
0x02, 0x02, Authorization failure, [RFC3720] 0x02, 0x02, Authorization failure, [RFC3720]
0x02, 0x03, Not found, [RFC3720] 0x02, 0x03, Not found, [RFC3720]
0x02, 0x04, Target removed, [RFC3720] 0x02, 0x04, Target removed, [RFC3720]
skipping to change at page 45, line 14 skipping to change at page 34, line 4
0x02, 0x03, Not found, [RFC3720] 0x02, 0x03, Not found, [RFC3720]
0x02, 0x04, Target removed, [RFC3720] 0x02, 0x04, Target removed, [RFC3720]
0x02, 0x05, Unsupported version, [RFC3720] 0x02, 0x05, Unsupported version, [RFC3720]
0x02, 0x06, Too many connections, [RFC3720] 0x02, 0x06, Too many connections, [RFC3720]
0x02, 0x07, Missing parameter, [RFC3720] 0x02, 0x07, Missing parameter, [RFC3720]
0x02, 0x08, Can't include in session, [RFC3720] 0x02, 0x08, Can't include in session, [RFC3720]
0x02, 0x09, Unsupported session type, [RFC3720] 0x02, 0x09, Unsupported session type, [RFC3720]
0x02, 0x0a, Non-existent session, [RFC3720] 0x02, 0x0a, Non-existent session, [RFC3720]
0x02, 0x0b, Invalid during login, [RFC3720] 0x02, 0x0b, Invalid during login, [RFC3720]
12-255: range reserved by IANA for assignment in Status-Class=2 12-255: range reserved by IANA for assignment in Status-Class=2 sub-
sub-registry registry.
Initial sub-registry contents (Status-Detail for Status- Initial sub-registry contents (Status-Detail for Status-Class=0x03):
Class=0x03):
0x03, 0x00, Target error, [RFC3720] 0x03, 0x00, Target error, [RFC3720]
0x03, 0x01, Service unavailable, [RFC3720] 0x03, 0x01, Service unavailable, [RFC3720]
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-
sub-registry 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
published specification defining the semantics and specification defining the semantics and interoperability
interoperability requirements of the proposed new Code and the requirements of the proposed new Code and the fields to be recorded
fields to be recorded in the registry 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
assigned to the requester. 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
its associated RFC reference associated RFC reference.
Initial registry contents: Initial registry contents:
0x01, Reserved, [RFC3720] 0x01, Reserved, [RFC3720]
0x02, Data digest error, [RFC3720] 0x02, Data digest error, [RFC3720]
0x03, SNACK Reject, [RFC3720] 0x03, SNACK Reject, [RFC3720]
0x04, Protocol Error, [RFC3720] 0x04, Protocol Error, [RFC3720]
skipping to change at page 47, line 11 skipping to change at page 35, line 35
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-
IESG-approved specification defining the semantics and approved specification defining the semantics and interoperability
interoperability requirements of the proposed new value and the requirements of the proposed new value and the fields to be recorded
fields to be recorded in the registry 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
assigned to the requester. the requester.
4-15: range reserved by IANA for assignment in this registry 4-15: range reserved by IANA for assignment in this registry.
Fields to record in the registry: Assigned value, Operation Name Fields to record in the registry: Assigned value, Operation Name, and
and its associated RFC reference 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
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
M., and E. Zeidner, "Internet Small Computer Systems E. Zeidner, "Internet Small Computer Systems Interface
Interface (iSCSI)", RFC 3720, April 2004. (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] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[IANA] Alvestrand, H. and T. Narten, "Guidelines for Writing [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 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., Hufferd, J., Elzur, U., Shah, H.,
P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet and P. Thaler, "Internet Small Computer System Interface
Draft draft-ietf-ips-iser-04.txt (work in progress), June (iSCSI) Extensions for Remote Direct Memory Access (RDMA)",
2005. RFC 5046, October 2007.
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.
and M. Krueger, "Internet Small Computer Systems Interface Krueger, "Internet Small Computer Systems Interface (iSCSI)
(iSCSI) Naming and Discovery", RFC 3721, April 2004. 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.
F. Travostino, "Securing Block Storage Protocols over IP", Travostino, "Securing Block Storage Protocols over IP", RFC
RFC 3723, April 2004. 3723, April 2004.
[RFC3722] Bakke, M., "String Profile for Internet Small [RFC3722] Bakke, M., "String Profile for Internet Small Computer
Computer Systems Interface (iSCSI) Names", RFC 3722, April Systems Interface (iSCSI) Names", RFC 3722, April 2004.
2004.
[SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM- [SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-2).
2).
[SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM- [SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-a3).
3).
[SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM- [SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-4),
4), Work in Progress. Work in Progress.
13 Editor's Address Acknowledgements
The IP Storage (IPS) Working Group in the Transport Area of the IETF
has been responsible for defining the iSCSI protocol (apart from a
host of other relevant IP Storage protocols). The editor
acknowledges the contributions of the entire working group.
The following individuals directly contributed to identifying
[RFC3720] issues and/or suggesting resolutions to the issues
clarified in this document: David Black, Gwendal Grignou, Mike Ko,
Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob Russell, Julian
Satran, Rob Elliott, Joseph Pittman, Somesh Gupta, Eddy Quicksall,
Paul Koning. This document benefited from all of these
contributions.
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 EMail: cbm@rose.hp.com
14 Acknowledgements
The IP Storage (ips) Working Group in the Transport Area of
IETF has been responsible for defining the iSCSI protocol
(apart from a host of other relevant IP Storage protocols).
The editor acknowledges the contributions of the entire
working group.
The following individuals directly contributed to identifying Full Copyright Statement
[RFC3720] issues and/or suggesting resolutions to the issues
clarified in this document: David Black, Gwendal Grignou,
Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob
Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh
Gupta, Eddy Quicksall, Paul Koning. This document benefited
from all these contributions.
15 Full Copyright Statement Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007). This document is This document is subject to the rights, licenses and restrictions
subject to the rights, licenses and restrictions contained in contained in BCP 78, and except as set forth therein, the authors
BCP 78, and except as set forth therein, the authors retain 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
provided on an "AS IS" basis and THE CONTRIBUTOR, THE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
16 Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of The IETF takes no position regarding the validity or scope of any
any Intellectual Property Rights or other rights that might Intellectual Property Rights or other rights that might be claimed to
be claimed to pertain to the implementation or use of the pertain to the implementation or use of the technology described in
technology described in this document or the extent to which this document or the extent to which any license under such rights
any license under such rights might or might not be might or might not be available; nor does it represent that it has
available; nor does it represent that it has made any 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 be
on the procedures with respect to rights in RFC documents can 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
any assurances of licenses to be made available, or the assurances of licenses to be made available, or the result of an
result of an attempt made to obtain a general license or attempt made to obtain a general license or permission for the use of
permission for the use of such proprietary rights by such proprietary rights by implementers or users of this
implementers or users of this specification can be obtained 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
attention any copyrights, patents or patent applications, or copyrights, patents or patent applications, or other proprietary
other proprietary rights that may cover technology that may rights that may cover technology that may be required to implement
be required to implement this standard. Please address the this standard. Please address the information to the IETF at
information to the IETF at ietf-ipr@ietf.org. ietf-ipr@ietf.org.
 End of changes. 299 change blocks. 
1089 lines changed or deleted 1000 lines changed or added

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