RFC 7144
Internet Small Computer System Interface (iSCSI) SCSI Features Update
RFC 7144: Internet Small Computer System Interface (iSCSI) SCSI Features Update ✨
Okay bestie, this one is RFC 7144, the iSCSI SCSI Features Update 🎀 It's from the IETF (Internet Engineering Task Force) and was written by F. Knight (NetApp) and M. Chadalapaka (Microsoft). It's a Standards Track doc, published April 2014, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates. It's a companion to RFC 7143, which is the main iSCSI spec 💅
Abstract 🌸
iSCSI is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combo of RFC 3720 and RFC 5048) is based on the SAM-2 version of the SCSI family. This doc adds enhancements so iSCSI can support some extra SCSI features that were defined in SAM-3, SAM-4, and SAM-5. It's a companion document to RFC 7143 🧚
Status of This Memo 📋
This is an Internet Standards Track document.
This doc is a product of the IETF, so it represents IETF community consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.
Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7144 🔥
Copyright Notice ©️
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶
Table of Contents 📚
1. Introduction ....................................................4
2. Definitions, Acronyms, and Document Summary .....................4
2.1. Definitions ................................................4
2.2. Acronyms ...................................................4
2.3. New Semantics ..............................................4
3. Terminology Mapping .............................................5
4. New Feature Use .................................................7
4.1. Negotiation of New Feature Use .............................7
4.2. Impact on Standard INQUIRY Data - iSCSI Version
Descriptors ................................................8
5. SCSI Commands ...................................................9
5.1. SCSI Command Additions .....................................9
5.1.1. Command Priority (Byte 2) ..........................10
5.2. SCSI Response Additions ...................................11
5.2.1. Status Qualifier ...................................12
5.2.2. Data Segment - Sense and Response Data Segment .....12
6. Task Management Functions ......................................13
6.1. Task Management Function Request PDU ......................13
6.2. Existing Task Management Functions ........................14
6.3. Task Management Function Additions ........................14
6.3.1. LUN Field ..........................................15
6.3.2. Referenced Task Tag ................................16
6.3.3. RefCmdSN ...........................................16
6.4. Task Management Function Responses ........................17
6.4.1. Task Management Function Response PDU ..............17
6.4.2. Task Management Function Response Additions ........18
6.5. Task Management Requests Affecting Multiple Tasks .........19
7. Login/Text Operational Text Keys ...............................19
7.1. New Operational Text Keys .................................19
7.1.1. iSCSIProtocolLevel .................................19
8. Security Considerations ........................................20
9. IANA Considerations ............................................21
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................24
11. Acknowledgements ..............................................241. Introduction 🧚
The original iSCSI protocol [RFC3720] was built on the [SAM2] model for SCSI. Lots of new features and capabilities have been added to the SCSI Architecture Model since then. At the time this doc was published, SAM-5 was the current version of the SCSI Architecture Model. This doc isn't a complete revision of [RFC3720]. Instead, it's a companion document to RFC 7143. It can also be used as a companion to the combo of [RFC3720] and [RFC5048], even though [RFC7143] has obsoleted both of those RFCs 💖
For more on the SCSI Architecture Model and SCSI Primary Commands - 4, check out the INCITS T10 Technical Committee for SCSI Storage Interfaces at <http://www.t10.org> 🌈
2. Definitions, Acronyms, and Document Summary 📖
2.1. Definitions
Okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are read as described in [RFC2119]. Iykyk 🙈
2.2. Acronyms
Here's the acronym list, no cap 🍓
ACA Auto Contingent Allegiance
AHS Additional Header Segment
ISID Initiator Session Identifier
LU Logical Unit
PDU Protocol Data Unit
SAM-5 SCSI Architecture Model - 5 (see [SAM5])
TSIH Target Session Identifying Handle2.3. New Semantics ⭐
This doc specifies new iSCSI semantics. Here's the quick summary of what's inside, so you don't have to dig 👑
- Section 3: The mapping of iSCSI objects to SAM-5 objects. An iSCSI node may contain both initiator and target capabilities 🎀
- Section 4: New feature use. New features need negotiation before they can be used. That negotiation may have an impact on standard INQUIRY data 💜
- Section 5: New command operations. The PRI field for SCSI command priority has been added to the SCSI Command PDU (see Section 5.1.1). The Status Qualifier field has been added to the SCSI Response PDU (see Section 5.2.1). Sense data may be returned (via Autosense) for any SCSI status, not just CHECK CONDITION (see Section 5.2.2). Literally so iconic 💅
- Section 6: New task management functions. Four new ones were added: QUERY TASK, QUERY TASK SET, I_T NEXUS RESET, and QUERY ASYNCHRONOUS EVENT (see Section 6.3). There's also a new "Function succeeded" response (see Section 6.4.2) 🦋
- Section 7: New negotiation key. A new negotiation key was added so you can actually use the new features from Sections 5 and 6 🧚✨
3. Terminology Mapping ✨
okay so the iSCSI model (defined in [RFC7143]) has its own vocab, and it doesn't always match the SCSI Architecture Model's vocab (SAM-5) 🫶 sometimes iSCSI uses a few different terms for what SAM-5 describes with just one. the iSCSI terms and SAM-5 terms aren't necessarily equivalent, they're more like examples of the objects or classes SAM-5 describes, like this:
Terminology in RFC 7143 | Terminology in SAM-5
+-----------------------------+---------------------------+
| Network Entity | none |
+-----------------------------+---------------------------+
| iSCSI Node | SCSI Device |
+-----------------------------+---------------------------+
| iSCSI Name | SCSI Device Name |
+-----------------------------+---------------------------+
| iSCSI Node Name | SCSI Device Name |
+-----------------------------+---------------------------+
| iSCSI Initiator Node | SCSI Initiator Device |
+-----------------------------+---------------------------+
| iSCSI Initiator Name | SCSI Device Name |
+-----------------------------+---------------------------+
| iSCSI Initiator Port | SCSI Initiator Port |
| Identifier; (i.e., iSCSI | Identifier |
| Node Name + ,,,i, + ISID)** | |
+-----------------------------+---------------------------+
| iSCSI Initiator Port Name; | SCSI Initiator Port Name |
| (i.e., iSCSI Node Name + | |
| ,,,i, + ISID)** | |
+-----------------------------+---------------------------+
| iSCSI Target Node | SCSI Target Device |
+-----------------------------+---------------------------+
| iSCSI Target Name | SCSI Device Name |
+-----------------------------+---------------------------+
| iSCSI Target Port | SCSI Target Port |
| Identifier; (i.e., iSCSI | Identifier |
| Node Name + ,,,t, + | |
| Target Portal Group Tag)** | |
+-----------------------------+---------------------------+
| iSCSI Target Port Name; | SCSI Target Port Name |
| (i.e., iSCSI Node Name + | |
| ,,,t, + Target Portal | |
| Group Tag)** | |
+-----------------------------+---------------------------+
| iSCSI Target Portal Group | SCSI Target Port |
+-----------------------------+---------------------------+
| iSCSI Initiator Name + | I_T Nexus Identifier |
| ',i,' + ISID + iSCSI | |
| Target Name + ',t,' + | |
| Target Portal Group Tag | |
+-----------------------------+---------------------------+
| Target Portal Group Tag | Relative Port ID |
+-----------------------------+---------------------------+** The text encoding of the ISID value and the Target Portal Group
Tag value includes an initial ,,0X or ,,0x (see [RFC7143]).next up, a diagram of a combo target device and initiator device 🎀 this kind of setup could show up in a target device that implements a SCSI Copy Manager. it shows how a session that shares Network Portals within a Portal Group can get set up (see Target Portal Group 1), and also how the initiator can use a different portal group than the target's, as long as the initiator's portal group shares Network Portal A with the target's portal group. so cute, right? 💅
----------------------------IP Network---------------------
| | |
+----|---------------|-------+ +----|------------+
| +----------+ +----------+ | | +----------+ |
| | Network | | Network | | | | Network | |
| | Portal A | | Portal B | | | | Portal A | |
| +----------+ +----------+ | | +----------+ |
| | Target | | | | Initiator |
| | Portal | | | | Portal |
| | Group 1 | | | | Group 2 |
+----|---------------|-------+ +----|------------+
| | |
+----------|---------------|--------------------|--------------------+
| +--------|---------------|----+ +-------------|------------------+ |
| |+-------|---------------|---+| |+------------|-----------------+| |
| ||iSCSI Session (Target side)|| ||iSCSI Session (Initiator side)|| |
| || || || || |
| || (TSIH = 56) || || (SSID = 48) || |
| |+---------------------------+| |+------------------------------+| |
| | | | | |
| | iSCSI Target Node | | iSCSI Initiator Node | |
| +-----------------------------+ +--------------------------------+ |
| iSCSI Node |
| (within Network Entity, not shown) |
+--------------------------------------------------------------------+4. New Feature Use 🌸
4.1. Negotiation of New Feature Use
so the iSCSIProtocolLevel operational text key (see Section 7.1.1) with a value of "2" MUST be negotiated before you can use the features in this RFC. no skipping this step, bestie 🙈
this is an iSCSI negotiation mechanism that turns on iSCSI support for matching SCSI capabilities (see [SAM5] and [SPC4]). so negotiating this key to "2" is necessary, but it's not sufficient on its own to use the SCSI capabilities that the iSCSI features in this RFC enable. main character energy? nah, it's a team effort 🫶
for example, an iSCSI implementation might negotiate this new key to "2" and then answer the new task management functions (see Section 6.3) with "Task management function not supported" (which is a SCSI error that stops the function from being performed). but if the key is negotiated to "2", an iSCSI implementation MUST NOT reject a Task Management Function Request PDU that asks for one of the new task management functions, because that kind of reject would count as an iSCSI protocol error 💀
4.2. Impact on Standard INQUIRY Data - iSCSI Version Descriptors
okay so the negotiated value of the iSCSIProtocolLevel key is an increment on top of the base iSCSI version descriptor value (0960h); see [SPC4]. if the SCSI device server returns an iSCSI version descriptor in the standard INQUIRY data, the value in that descriptor MUST be set to the base value (0960h) plus the negotiated value of the iSCSIProtocolLevel key. (for example, if the negotiated iSCSIProtocolLevel=2 and an iSCSI version descriptor shows up in the standard INQUIRY data, it's set to 0962h. the math is mathing 🧮✨)
and to support all this, INCITS Technical Committee T10, which is responsible for SCSI standards, has assigned SCSI version descriptor codes 0961h-097Fh to RFC 7144 so IANA can manage them through the values 1-31 of the iSCSIProtocolLevel key; see Section 9 🦋 the "No version claimed" description for the value 0 of the iSCSIProtocolLevel key matches the existing T10 assignment of the 0960h SCSI version descriptor code to "iSCSI (no version claimed)". that's why the assignment of the value 0 in the IANA registry for the iSCSIProtocolLevel key must not be changed. hands off that one, periodt 🔒
5. SCSI Commands 💜
5.1. SCSI Command Additions
here's what the SCSI Command PDU looks like:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| 0x01 |F|R|W|. .|ATTR | PRI | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| Logical Unit Number (LUN) |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Expected Data Transfer Length |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32/ SCSI Command Descriptor Block (CDB) /
+/ /
+---------------+---------------+---------------+---------------+
48/ AHS (Optional) /
+---------------+---------------+---------------+---------------+
x/ Header Digest (Optional) /
+---------------+---------------+---------------+---------------+
y/ (DataSegment, Command Data) (Optional) /
+/ /
+---------------+---------------+---------------+---------------+
z/ Data Digest (Optional) /
+---------------+---------------+---------------+---------------+this SCSI Command PDU is copied over from [RFC7143] so you can see the PRI field. for any field other than PRI, the text in [RFC7143] wins over Section 5.1 of this document if the two ever disagree 🫶
5.1.1. Command Priority (Byte 2)
the Command Priority (PRI) is a four-bit field that says how much scheduling importance this command has compared to the other commands already in the task set with SIMPLE task attributes (see [SAM5]) ⭐
Section 11 ("iSCSI PDU Formats") of [RFC7143] requires that senders set this field to zero. a sender MUST NOT set this field to anything other than zero unless the iSCSIProtocolLevel text key defined in Section 7.1.1 has been negotiated on the session with a value of "2". 🎀
iSCSI targets MUST ignore this field unless the iSCSIProtocolLevel text key with a value of "2", as defined in Section 7.1.1, was negotiated on the session. so it's basically ignored by default, okay? 🙈
see [SAM5] for more on how the Command Priority field works 🦋
5.2. SCSI Response Additions ✨
okay so here's the layout of the SCSI Response PDU 🎀
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| Status Qualifier | Reserved |
+---------------+---------------+---------------+---------------+
12| Reserved |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| SNACK Tag or Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| ExpDataSN or Reserved |
+---------------+---------------+---------------+---------------+
40| Bidirectional Read Residual Count or Reserved |
+---------------+---------------+---------------+---------------+
44| Residual Count or Reserved |
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+
/ Data Segment (Optional) /
+/ /
+---------------+---------------+---------------+---------------+
| Data-Digest (Optional) |
+---------------+---------------+---------------+---------------+this PDU is copied over from [RFC7143] just so we can see the Status Qualifier field 👀 quick rule: for any field except Status, Status Qualifier, and the Data Segment - Sense and Response Data Segment field, [RFC7143] is the boss, and its text beats Section 5.2 of this document if the two ever disagree 💅
5.2.1. Status Qualifier
the Status Qualifier gives extra status info (see [SAM5]) ✨
as defined in Section 11 ("iSCSI PDU Formats") of [RFC7143], compliant senders already set this field to zero 🌸 compliant senders MUST NOT set this field to a value other than zero unless the iSCSIProtocolLevel text key with a value of "2" as defined in Section 7.1.1 was negotiated on the session 🙈
this field MUST be ignored by receivers unless the iSCSIProtocolLevel text key with a value of "2" as defined in Section 7.1.1 was negotiated on the session 💀
5.2.2. Data Segment - Sense and Response Data Segment
Section 11.4.7 of [RFC7143] says iSCSI targets MUST support and enable Autosense 🔥 if Status is CHECK CONDITION (0x02), then the Data Segment MUST contain sense data for the failed command 😭
now here's the tea: [RFC7143] doesn't say anything about the Data Segment when Status is not CHECK CONDITION (0x02). so it's not banned from holding sense data in that case. but negotiating the iSCSIProtocolLevel text key with a value of "2" as defined in Section 7.1.1 explicitly says the Data Segment MAY contain sense data at any time, no matter what's in the Status field 🦋 iconic, honestly
6. Task Management Functions 🧚
6.1. Task Management Function Request PDU
this is the Task Management Function Request PDU 💜
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|I| 0x02 |1| Function | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| Logical Unit Number (LUN) |
+ +
12| |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Referenced Task Tag or 0xffffffff |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN |
+---------------+---------------+---------------+---------------+
32| RefCmdSN or Reserved |
+---------------+---------------+---------------+---------------+
36| ExpDataSN or Reserved |
+---------------+---------------+---------------+---------------+
40| Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+this one's only here as a reference copy from [RFC7143] 🌷 if the two docs conflict, [RFC7143] supersedes the text in Sections 6.1 and 6.2 of this document
6.2. Existing Task Management Functions
Section 11.5 of [RFC7143] defines the semantics for asking that SCSI task management functions get performed 💅 the following ones are defined:
1 - ABORT TASK
2 - ABORT TASK SET
3 - CLEAR ACA
4 - CLEAR TASK SET
5 - LOGICAL UNIT RESET
6 - TARGET WARM RESET
7 - TARGET COLD RESET
8 - TASK REASSIGN6.3. Task Management Function Additions ✨
more function codes are listed here. for a deeper dive on SCSI task management, check [SAM5] 🧠
9- QUERY TASK - determine if the command identified by the Referenced Task Tag field is present in the task set.10- QUERY TASK SET - determine if any command is present in the task set for theI_T_LNexus on which the task management function was received.11- I_T NEXUS RESET - perform an I_T nexus loss function (see [SAM5]) for the I_T nexus on which the task management function was received.12- QUERY ASYNCHRONOUS EVENT - determine if there is a unit attention condition or a deferred error pending for theI_T_Lnexus on which the task management function was received.
these task management function requests MUST NOT be sent unless the iSCSIProtocolLevel text key with a value of "2" as defined in Section 7.1.1 was negotiated on the session 🚫
any compliant initiator that sends any of the new task management functions defined in this section MUST also support all new task management function responses (as specified in Section 6.4.2) 🫶
for every task management function in this section, the Task Management Function Response MUST be returned as detailed in Section 6.4 💜
the iSCSI target MUST ensure that no responses for the commands covered by a task management function are sent to the iSCSI initiator port after the Task Management response, except for commands covered by a TASK REASSIGN, QUERY TASK, or QUERY TASK SET 👑
if a QUERY TASK is issued for a task created by an immediate command, then RefCmdSN MUST be that of the Task Management request itself (so CmdSN and RefCmdSN are equal). otherwise, RefCmdSN MUST be set to the CmdSN of the task to be queried (lower than CmdSN) 🎀
if the connection is still active (not undergoing an implicit or explicit logout), QUERY TASK MUST be issued on the same connection that the task to be queried is allegiant to at the time the Task Management request is issued. if the connection is implicitly or explicitly logged out (so no other request will be issued on the failing connection and no other response will be received on it), then a QUERY TASK function request may be issued on another connection. this Task Management request will then establish a new allegiance for the command being queried 🦋
at the target, a QUERY TASK function MUST NOT be executed on a Task Management request. such a request MUST result in Task Management response of "Function rejected" 🙅♀️
for the I_T NEXUS RESET function, the target device MUST respond to the function as defined in [SAM5]. each logical unit accessible via the receiving I_T NEXUS MUST behave as dictated by the I_T nexus loss function in [SAM5] for the I_T nexus on which the task management function was received. the target device MUST drop all connections in the session over which this function is received. no matter what the DefaultTime2Wait and DefaultTime2Retain values are for the session that this function came in on, the target device MUST consider each participating connection in the session to have immediately timed out, leading to FREE state. those timeouts cause the session timeout event defined in [RFC7143], which then triggers the I_T nexus loss notification to the SCSI layer as described in [RFC7143] 🌈
6.3.1. LUN Field
this field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET, QUERY TASK, QUERY TASK SET, and QUERY ASYNCHRONOUS EVENT). it's reserved in all the others 🍓
6.3.2. Referenced Task Tag
the Reference Task Tag is the Initiator Task Tag of the task to be aborted for the ABORT TASK function, reassigned for the TASK REASSIGN function, or queried for the QUERY TASK function. for all other functions, this field MUST be set to the reserved value 0xffffffff 🧚
6.3.3. RefCmdSN
if a QUERY TASK is issued for a task created by an immediate command, then RefCmdSN MUST be that of the Task Management request itself (so CmdSN and RefCmdSN are equal) 💖
for a QUERY TASK of a task created by a non-immediate command, RefCmdSN MUST be set to the CmdSN of the task identified by the Referenced Task Tag field. targets must use this field as described in section 11.6.1 of [RFC7143] when the task identified by the Referenced Task Tag field is not in the task set 🌸
6.4. Task Management Function Responses ✨
6.4.1. Task Management Function Response PDU 💅
Okay bestie, this is the Task Management Function Response PDU 🦋 and it has a whole layout:
Byte/ 0 | 1 | 2 | 3 |
/ | | | |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+---------------+---------------+---------------+---------------+
0|.|.| 0x22 |1| Reserved | Response | Reserved |
+---------------+---------------+---------------+---------------+
4|TotalAHSLength | DataSegmentLength |
+-----------------------------------------------+---------------+
8| Additional Response Information | Reserved |
+-----------------------------------------------+---------------+
12| Reserved |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Header-Digest (Optional) |
+---------------+---------------+---------------+---------------+So [RFC7143] has the final say on the SCSI task management responses 👑. Its Section 11.6 is where the semantics live 🧚, and these are the responses it defines:
0 - Function Complete
1 - Task does not exist
2 - LUN does not exist
3 - Task still allegiant
4 - Task allegiance reassignment not supported
5 - Task management function not supported
6 - Function authorization failed
255 - Function rejectedThe PDU above and that list are only copied over from [RFC7143] for reference 📖. If the two ever disagree, [RFC7143] supersedes the text in section 6.4.1 of this document, so RFC7143 always wins 💜.
New task management functions get their own responses (see Section 6.4.2), and there's a brand new task management response too 🌈. For a deeper dive into SCSI task management responses, check out [SAM5] 🎀.
For QUERY TASK, QUERY TASK SET, I_T NEXUS RESET, and QUERY ASYNCHRONOUS EVENT, the target runs the requested Task Management function and then sends a Task Management response back to the initiator ✨.
6.4.2. Task Management Function Response Additions 🦋
The new response is a total glow-up 🌸:
7 - Function succeededSymbolically, Response value 7 maps to the SCSI service response of FUNCTION SUCCEEDED in [SAM5] 💖.
An initiator that sends any of the new task management functions (see Section 6.3) MUST support the Task Management Function Response of "Function succeeded". No skipping this one, bestie 🚨.
For QUERY TASK: if the specified task is in the task set, the logical unit returns a Response value of "Function succeeded" and any additional response information comes back as specified in [SAM5] 🔍. If the specified task isn't in the task set, the logical unit returns a Response value of "Function complete" 🙈.
For QUERY TASK SET: if there's any command in the task set from the specified I_T_L nexus, the logical unit returns "Function succeeded" ✨. If there are no commands in the task set from that I_T_L nexus, it returns "Function complete" 🌙.
For I_T NEXUS RESET: after the events described in Section 6.3 for this function are done, the logical unit returns "Function complete" 🌊. But here's the tea ☕: since the target drops all connections, the Service Response (defined by [SAM5]) for this function may not be reliably delivered to the issuing initiator port 💀.
For QUERY ASYNCHRONOUS EVENT: if there's a unit attention condition or deferred error pending for the specified I_T_L nexus, the logical unit returns "Function succeeded" and additional response information comes back as specified in [SAM5] 🔔. If nothing is pending for that I_T_L nexus, it returns "Function complete" 🫶.
6.5. Task Management Requests Affecting Multiple Tasks 🧚
Section 4.1 of [RFC5048] is where the idea of "affected tasks" in multi-task abort scenarios lives 📚. This section adds to that list by defining the tasks that the I_T NEXUS RESET function affects 🔥:
I_T NEXUS RESET: All outstanding tasks received on the I_T nexus
on which the function request was received for all logical
units accessible to the I_T nexus.Sections 4.1.2 and 4.1.3 of [RFC5048] cover the semantics for task management functions that involve multi-task abort operations 🍓. If an iSCSI implementation supports the I_T NEXUS RESET function, it MUST also support the protocol behavior as defined in those sections and follow the sequence of actions as described in those sections when processing the I_T NEXUS RESET function. Non-negotiable, bestie 💅.
7. Login/Text Operational Text Keys ✨
7.1. New Operational Text Keys 🌈
7.1.1. iSCSIProtocolLevel 🎀
Use: LO, IO
Irrelevant when: SessionType = Discovery
Senders: Initiator and Target
Scope: SW
iSCSIProtocolLevel=<numerical-value-from-0-to-31>
Default is 1.
Result function is Minimum.This key is what you use to negotiate iSCSI features that need different levels of protocol support (for example, PDU formats and end-node semantics) to work properly 🧠.
Negotiating iSCSIProtocolLevel to a value that matches an RFC means both parties are compliant with that RFC and agree to support its PDU formats and semantics on that iSCSI session 🤝. The features using this key are expected to be cumulative ➕.
An iSCSIProtocolLevel negotiated to "0" means the implementation doesn't claim a specific iSCSI protocol level 🫥. Negotiated to "1", it means the implementation claims compliance with [RFC7143] 💜. Negotiated to "2", it's required to enable use of the features defined in this RFC 🔓.
If the acceptor ignores the negotiation answer, or the answer from the remote iSCSI end point is key=NotUnderstood, then the features defined in this RFC, and the features defined in any RFC requiring a key value greater than "2", MUST NOT be used. So don't go using those features, bestie 🙅♀️.
8. Security Considerations 💀
Command priorities are relative values, not absolute values (see [SAM5], and affect collections of commands, not necessarily individual commands (see [SAM5]). If command priority is supported, it should be implemented in a fashion that avoids unwanted reduction or denial of service 🚨. This part is serious, so please don't skip it 🥺.
All the iSCSI-related security text in [RFC3723] is directly applicable to this document 🔐. The security text in [RFC7143] is directly applicable as well 🛡️.
9. IANA Considerations ✨
okay so this section is all about IANA, the folks who keep the official registries 📚 this doc changes some existing iSCSI registries and creates a few new ones, so let's go 💅
The following iSCSI-related registries are modified. 🎀
- iSCSI Task Management Functions Codes
Name of the existing registry: "iSCSI Task Management Function Codes"
The following entries have been added:
9 - QUERY TASK, RFC 7144
10 - QUERY TASK SET, RFC 7144
11 - I_T NEXUS RESET, RFC 7144
12 - QUERY ASYNCHRONOUS EVENT, RFC 7144
13-127 - Unassigned- iSCSI Login/Text Keys
Name of the existing registry: "iSCSI Login/Text Keys"
Fields to record in the registry: Assigned value and its associated RFC reference.
The following entry has been added:
iSCSIProtocolLevel, RFC 7144IANA has created the following iSCSI-related registries. 🌸
- iSCSI Protocol Level
Name of new registry: "iSCSI Protocol Level"
Namespace details: Numerical values from 0 to 31
Information that must be provided to assign a new value: An IESG-approved Standards Track specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
Assignment policy:
The assignments of these values must be coordinated with the INCITS T10 committee, so review by an expert who keeps a connection to that committee is required before IESG approval of the associated specification. After the registry is created, values are assigned sequentially. For example, no value greater than 4 gets assigned until the value 4 has been assigned. 🧚
Special care must be taken in the assignment of new values in this registry. Compatibility and interoperability get hurt if proper care isn't exercised. Features using this key are expected to be cumulative. For example, since this document only explicitly lists value 2 for the features listed here, a new RFC assigning value 3 is expected to also have the features listed in this RFC, so that RFC is expected to either revise or replace this RFC. Assignments that don't follow this policy should be reviewed and approved by the INCITS T10 committee. 💀
3-31: range available to IANA for assignment in this registry.
Fields to record in the registry: Assigned value, description, and its associated RFC reference.
The following entries have been added:
Value Description Reference
0 No version claimed RFC 7144
1 RFC 7143 [RFC7143]
2 RFC 7144 RFC 7144
3-31 UnassignedAllocation Policy: Expert Review and Standards Action [RFC5226]
- iSCSI Task Management Function Response Codes
Name of new registry: "iSCSI Task Management Function Response Codes"
Namespace details: Numerical values that can fit in 8 bits.
Information that must be provided to assign a new value: An IESG-approved specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
Assignment policy:
If the requested value is not already assigned, it may be assigned to the requester. 🫶
8-254: Range available to IANA for assignment in this registry.
Fields to record in the registry: Assigned value, Operation Name, and its associated RFC reference.
The following entries have been added:
0 - Function complete, [RFC7143]
1 - Task does not exist, [RFC7143]
2 - LUN does not exist, [RFC7143]
3 - Task still allegiant, [RFC7143]
4 - Task allegiance reassignment not supported, [RFC7143]
5 - Task management function not supported, [RFC7143]
6 - Function authorization failed, [RFC7143]
7 - Function succeeded, RFC 7144
8-254 - Unassigned
255 - Function rejected, [RFC7143]Allocation Policy: Standards Action [RFC5226]
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC5048] Chadalapaka, M., Ed., "Internet Small Computer System Interface (iSCSI) Corrections and Clarifications", RFC 5048, October 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, April 2014.
[SAM2] INCITS Technical Committee T10, "SCSI Architecture Model - 2 (SAM-2)", ANSI INCITS 366-2003, ISO/IEC 14776-412, 2003.
[SAM5] INCITS Technical Committee T10, "SCSI Architecture Model - 5 (SAM-5)", T10/BSR INCITS 515 rev 04, Committee Draft.
[SPC4] INCITS Technical Committee T10, "SCSI Primary Commands - 4", ANSI INCITS 513-201x.
10.2. Informative References
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
11. Acknowledgements 🌈
The Storage Maintenance (STORM) Working Group in the Transport Area of the IETF is responsible for these additions to the iSCSI protocol, alongside other relevant IP Storage protocols. The authors thank the whole working group and the other IETF reviewers. 👑
The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues clarified in this document: David Black, Rob Elliott. This document benefited from all of these contributions. 💜
Authors' Addresses ✨
Frederick Knight
7301 Kit Creek Road
P.O. Box 13917
Research Triangle Park, NC 27709
USA
Phone: +1-919-476-5362
EMail: knight@netapp.com
Mallikarjun Chadalapaka
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
EMail: cbm@chadalapaka.com📦 where this page comes from
- ietf: rfc7144 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms