idnits 2.17.1 draft-ietf-ips-iscsi-impl-guide-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1705. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC3720, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2007) is 6031 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) -- Possible downref: Non-RFC (?) normative reference: ref. 'SPC3' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Mallikarjun Chadalapaka 3 draft-ietf-ips-iscsi-impl-guide-07.txt Hewlett-Packard Co. 4 Editor 6 Updates: RFC 3720 7 Intended status: Proposed Standard 9 Expires October 2007 11 iSCSI Corrections and Clarifications 13 Status of this Memo 14 By submitting this Internet-Draft, each author represents 15 that any applicable patent or other IPR claims of which he or 16 she is aware have been or will be disclosed, and any of which 17 he or she becomes aware will be disclosed, in accordance with 18 Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet 21 Engineering Task Force (IETF), its areas, and its working 22 groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by 27 other documents at any time. It is inappropriate to use 28 Internet-Drafts as reference material or to cite them other 29 than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed 35 at http://www.ietf.org/shadow.html. 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 38 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 39 "OPTIONAL" in this document are to be interpreted as 40 described in [RFC2119]. 42 Abstract 43 iSCSI is a SCSI transport protocol and maps the SCSI 44 architecture and command sets onto TCP/IP. RFC 3720 defines 45 the iSCSI protocol. This document compiles the 46 clarifications to the original protocol definition in RFC 47 3720 to serve as a companion document for the iSCSI 48 implementers. This document updates RFC 3720 and the text in 49 this document supersedes the text in RFC 3720 when the two 50 differ. 52 Table of Contents 54 1 Definitions and acronyms ...............................5 55 1.1 Definitions ............................................5 56 1.2 Acronyms ...............................................5 57 2 Introduction ...........................................7 58 3 iSCSI semantics for SCSI tasks .........................8 59 3.1 Residual handling ......................................8 60 3.1.1 Overview..............................................8 61 3.1.2 SCSI REPORT LUNS and Residual Overflow................9 62 3.2 R2T Ordering ..........................................10 63 3.3 Model Assumptions for Response Ordering ...............11 64 3.3.1 Model Description....................................11 65 3.3.2 iSCSI Semantics with the Interface Model.............12 66 3.3.3 Current List of Fenced Response Use Cases............12 67 4 Task Management .......................................14 68 4.1 Requests Affecting Multiple Tasks .....................14 69 4.1.1 Scope of affected tasks..............................14 70 4.1.2 Clarified multi-task abort semantics.................14 71 4.1.3 Updated multi-task abort semantics...................16 72 4.1.4 Affected tasks shared across RFC3720 & FastAbort 73 sessions....................................................18 74 4.1.5 Implementation considerations........................19 75 4.1.6 Rationale behind the new semantics...................20 76 5 Discovery semantics ...................................22 77 5.1 Error Recovery for Discovery Sessions .................22 78 5.2 Reinstatement Semantics of Discovery Sessions .........22 79 5.2.1 Unnamed Discovery Sessions...........................23 80 5.2.2 Named Discovery Sessions.............................23 81 5.3 Target PDUs during Discovery ..........................24 82 6 Negotiation and Others ................................25 83 6.1 TPGT Values ...........................................25 84 6.2 SessionType Negotiation ...............................25 85 6.3 Understanding NotUnderstood ...........................25 86 6.4 Outstanding Negotiation Exchanges .....................26 87 7 iSCSI Error Handling and Recovery .....................27 88 7.1 ITT ...................................................27 89 7.2 Format Errors .........................................27 90 7.3 Digest Errors .........................................27 91 7.4 Message Error Checking ................................28 92 8 iSCSI PDUs ............................................29 93 8.1 Asynchronous Message ..................................29 94 8.2 Reject ................................................29 95 9 Login/Text Operational Text Keys ......................31 96 9.1 TaskReporting .........................................31 97 10 Security Considerations ...............................33 98 11 IANA Considerations ...................................34 99 11.1 iSCSI-related IANA registries........................34 100 11.2 iSCSI Opcodes........................................34 101 11.3 iSCSI Login/Text Keys................................36 102 11.4 iSCSI Asynchronous Events............................38 103 11.5 iSCSI Task Management Function Codes.................39 104 11.6 iSCSI Login Response Status Codes....................40 105 11.7 iSCSI Reject Reason Codes............................42 106 11.8 iSER Opcodes.........................................44 107 12 References and Bibliography ...........................45 108 12.1 Normative References.................................45 109 12.2 Informative References...............................45 110 13 Editor's Address ......................................46 111 14 Acknowledgements ......................................47 112 15 Full Copyright Statement ..............................48 113 16 Intellectual Property Statement .......................49 115 1 Definitions and acronyms 117 1.1 Definitions 119 I/O Buffer - A buffer that is used in a SCSI Read or Write 120 operation so SCSI data may be sent from or received into 121 that buffer. For a read or write data transfer to take 122 place for a task, an I/O Buffer is required on the 123 initiator and at least one required on the target. 125 SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 126 aggregate data length of the data that SCSI layer 127 logically "presents" to iSCSI layer for a Data-in or 128 Data-out transfer in the context of a SCSI task. For a 129 bidirectional task, there are two SPDTL values - one for 130 Data-in and one for Data-out. Note that the notion of 131 "presenting" includes immediate data per the data 132 transfer model in [SAM2], and excludes overlapping data 133 transfers, if any, requested by the SCSI layer. 135 Third-party: A term used in this document to denote nexus 136 objects (I_T or I_T_L) and iSCSI sessions which reap the 137 side-effects of actions that take place in the context of 138 a separate iSCSI session, while being third parties to 139 the action that caused the side-effects. One example of 140 a Third-party session is an iSCSI session hosting an 141 I_T_L nexus to an LU that is reset with an LU Reset TMF 142 via a separate I_T nexus. 144 1.2 Acronyms 146 Acronym Definition 148 ------------------------------------------------------------- 150 EDTL Expected Data Transfer Length 152 IANA Internet Assigned Numbers Authority 154 IETF Internet Engineering Task Force 156 I/O Input - Output 158 IP Internet Protocol 160 iSCSI Internet SCSI 162 iSER iSCSI Extensions for RDMA 164 ITT Initiator Task Tag 166 LO Leading Only 168 LU Logical Unit 170 LUN Logical Unit Number 172 PDU Protocol Data Unit 174 RDMA Remote Direct Memory Access 176 R2T Ready To Transfer 178 R2TSN Ready To Transfer Sequence Number 180 RFC Request For Comments 182 SAM SCSI Architecture Model 184 SCSI Small Computer Systems Interface 186 SN Sequence Number 188 SNACK Selective Negative Acknowledgment - also 190 Sequence Number Acknowledgement for data 192 TCP Transmission Control Protocol 194 TMF Task Management Function 196 TTT Target Transfer Tag 198 UA Unit Attention 200 2 Introduction 202 Several iSCSI implementations had been built after [RFC3720] was 203 published and the iSCSI community is now richer by the resulting 204 implementation expertise. The goal of this document is to 205 leverage this expertise both to offer clarifications to the 206 [RFC3720] semantics and to address defects in [RFC3720] as 207 appropriate. This document intends to offer critical guidance 208 to implementers with regard to non-obvious iSCSI implementation 209 aspects so as to improve interoperability and accelerate iSCSI 210 adoption. This document, however, does not purport to be an 211 all-encompassing iSCSI how-to guide for implementers, nor a 212 complete revision of [RFC3720]. This document instead is 213 intended as a companion document to [RFC3720] for the iSCSI 214 implementers. 216 iSCSI implementers are required to reference [RFC3722] and 217 [RFC3723] in addition to [RFC3720] for mandatory requirements. 218 In addition, [RFC3721] also contains useful information for 219 iSCSI implementers. The text in this document, however, updates 220 and supersedes the text in [RFC3720] whenever there is such a 221 question. 223 3 iSCSI semantics for SCSI tasks 225 3.1 Residual handling 227 Section 10.4.1 of [RFC3720] defines the notion of "residuals" 228 and specifies how the residual information should be encoded 229 into the SCSI Response PDU in Counts and Flags fields. Section 230 3.1.1 clarifies the intent of [RFC3720] and explains the general 231 principles. Section 3.1.2 describes the residual handling in 232 the REPORT LUNS scenario. 234 3.1.1 Overview 236 SCSI-Presented Data Transfer Length (SPDTL) is the term this 237 document uses (see section 1.1 for definition) to represent the 238 aggregate data length that the target SCSI layer attempts to 239 transfer using the local iSCSI layer for a task. Expected Data 240 Transfer Length (EDTL) is the iSCSI term that represents the 241 length of data that the iSCSI layer expects to transfer for a 242 task. EDTL is specified in the SCSI Command PDU. 244 When SPDTL = EDTL for a task, the target iSCSI layer completes 245 the task with no residuals. Whenever SPDTL differs from EDTL 246 for a task, that task is said to have a residual. 248 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in 249 the SCSI Response PDU as specified in [RFC3720]. Residual Count 250 MUST be set to the numerical value of (SPDTL - EDTL). 252 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 253 the SCSI Response PDU as specified in [RFC3720]. Residual Count 254 MUST be set to the numerical value of (EDTL - SPDTL). 256 Note that the Overflow and Underflow scenarios are independent 257 of Data-in and Data-out. Either scenario is logically possible 258 in either direction of data transfer. 260 3.1.2 SCSI REPORT LUNS and Residual Overflow 262 This section discusses the residual overflow issues citing the 263 example of SCSI REPORT LUNS command. Note however that there 264 are several SCSI commands (e.g. INQUIRY) with ALLOCATION LENGTH 265 fields following the same underlying rules. The semantics in 266 the rest of the section apply to all such SCSI commands. 268 The specification of the SCSI REPORT LUNS command requires that 269 the SCSI target limit the amount of data transferred to a 270 maximum size (ALLOCATION LENGTH) provided by the initiator in 271 the REPORT LUNS CDB. If the Expected Data Transfer Length 272 (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT 273 LUNS command is set to at least as large as that ALLOCATION 274 LENGTH, the SCSI layer truncation prevents an iSCSI Residual 275 Overflow from occurring. A SCSI initiator can detect that such 276 truncation has occurred via other information at the SCSI layer. 277 The rest of the section elaborates this required behavior. 279 iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI 280 Response and the last SCSI Data-In PDUs to indicate that that an 281 iSCSI target was unable to transfer all of the SCSI data for a 282 command to the initiator because the amount of data to be 283 transferred exceeded the EDTL in the corresponding SCSI Command 284 PDU (see Section 10.4.1 of [RFC3720]). 286 The SCSI REPORT LUNS command requests a target SCSI layer to 287 return a logical unit inventory (LUN list) to the initiator SCSI 288 layer (see section 6.21 of SPC-3 [SPC3]). The size of this LUN 289 list may not be known to the initiator SCSI layer when it issues 290 the REPORT LUNS command; to avoid transfer of more LUN list data 291 than the initiator is prepared for, the REPORT LUNS CDB contains 292 an ALLOCATION LENGTH field to specify the maximum amount of data 293 to be transferred to the initiator for this command. If the 294 initiator SCSI layer has under-estimated the number of logical 295 units at the target, it is possible that the complete logical 296 unit inventory does not fit in the specified ALLOCATION LENGTH. 297 In this situation, section 4.3.3.6 in [SPC3] requires that the 298 target SCSI layer "shall terminate transfers to the Data-In 299 Buffer" when the number of bytes specified by the ALLOCATION 300 LENGTH field have been transferred. 302 Therefore, in response to a REPORT LUNS command, the SCSI layer 303 at the target presents at most ALLOCATION LENGTH bytes of data 304 (logical unit inventory) to iSCSI for transfer to the initiator. 305 For a REPORT LUNS command, if the iSCSI EDTL is at least as 306 large as the ALLOCATION LENGTH, the SCSI truncation ensures that 307 the EDTL will accommodate all of the data to be transferred. If 308 all of the logical unit inventory data presented to the iSCSI 309 layer - i.e. the data remaining after any SCSI truncation - is 310 transferred to the initiator by the iSCSI layer, an iSCSI 311 Residual Overflow has not occurred and the iSCSI (O) bit MUST 312 NOT be set in the SCSI Response or final SCSI Data-Out PDU. 313 This is not a new requirement but is already required by the 314 combination of [RFC3720] with the specification of the REPORT 315 LUNS command in [SPC3]. If the iSCSI EDTL is larger than the 316 ALLOCATION LENGTH however in this scenario, note that the iSCSI 317 Underflow MUST be signaled in the SCSI Response PDU. An iSCSI 318 Underflow MUST also be signaled when the iSCSI EDTL is equal to 319 ALLOCATION LENGTH but the logical unit inventory data presented 320 to the iSCSI layer is smaller than ALLOCATION LENGTH. 322 The LUN LIST LENGTH field in the logical unit inventory (first 323 field in the inventory) is not affected by truncation of the 324 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 325 initiator to determine that the received inventory is incomplete 326 by noticing that the LUN LIST LENGTH in the inventory is larger 327 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. 328 A common initiator behavior in this situation is to re-issue the 329 REPORT LUNS command with a larger ALLOCATION LENGTH. 331 3.2 R2T Ordering 333 Section 10.8 in [RFC3720] says the following: 335 The target may send several R2T PDUs. It, therefore, can have 336 a number of pending data transfers. The number of outstanding 337 R2T PDUs are limited by the value of the negotiated key 338 MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST 339 be fulfilled by the initiator in the order in which they were 340 received. 342 The quoted [RFC3720] text was unclear on the scope of 343 applicability - either per task, or across all tasks on a 344 connection - and may be interpreted as either. This section is 345 intended to clarify that the scope of applicability of the 346 quoted text is a task. No R2T ordering relationship - either in 347 generation at the target or in fulfilling at the initiator - 348 across tasks is implied. I.e., outstanding R2Ts within a task 349 MUST be fulfilled by the initiator in the order in which they 350 were received on a connection. 352 3.3 Model Assumptions for Response Ordering 354 Whenever an iSCSI session is composed of multiple connections, 355 the Response PDUs (task responses or TMF responses) originating 356 in the target SCSI layer are distributed onto the multiple 357 connections by the target iSCSI layer according to iSCSI 358 connection allegiance rules. This process generally may not 359 preserve the ordering of the responses by the time they are 360 delivered to the initiator SCSI layer. Since ordering is not 361 expected across SCSI responses anyway, this approach works fine 362 in the general case. However to address the special cases where 363 some ordering is desired by the SCSI layer, the following 364 "Response Fence" semantics are defined with respect to handling 365 SCSI response messages as they are handed off from the SCSI 366 protocol layer to the iSCSI layer. 368 3.3.1 Model Description 370 Target SCSI protocol layer hands off the SCSI response messages 371 to the target iSCSI layer by invoking the "Send Command 372 Complete" protocol data service ([SAM2], clause 5.4.2) and "Task 373 Management Function Executed" ([SAM2], clause 6.9) service. On 374 receiving the SCSI response message, iSCSI layer exhibits the 375 Response Fence behavior for certain SCSI response messages 376 (section 3.3.3 describes the specific instances where the 377 semantics must be realized). Whenever the Response Fence 378 behavior is required for a SCSI response message, the target 379 iSCSI layer MUST ensure that the following conditions are met in 380 delivering the response message to the initiator iSCSI layer: 382 (1) Response with Response Fence MUST chronologically be 383 delivered after all the "preceding" responses on the 384 I_T_L nexus, if the preceding responses are delivered at 385 all, to the initiator iSCSI layer. 387 (2) Response with Response Fence MUST chronologically be 388 delivered prior to all the "following" responses on the 389 I_T_L nexus. 391 The "preceding" and "following" notions refer to the order of 392 hand-off of a response message from the target SCSI protocol 393 layer to the target iSCSI layer. 395 3.3.2 iSCSI Semantics with the Interface Model 397 Whenever the TaskReporting key (section 9.1) is negotiated to 398 ResponseFence or FastAbort for an iSCSI session and the Response 399 Fence behavior is required for a SCSI response message, the 400 target iSCSI layer MUST perform the actions described in this 401 section for that session.: 403 a) If it is a single-connection session, no special processing 404 is required. Standard SCSI Response PDU build and dispatch 405 process happens. 407 b) If it is a multi-connection session, target iSCSI layer 408 takes note of last-sent and unacknowledged StatSN on each 409 of the connections in the iSCSI session, and waits for 410 acknowledgement (Nop-In PDUs MAY be used to solicit 411 acknowledgements as needed in order to accelerate this 412 process) of each such StatSN to clear the fence. The SCSI 413 response requiring Response Fence behavior MUST NOT be sent 414 to the initiator before acknowledgements are received for 415 each of the unacknowledged StatSNs.. 417 c) Target iSCSI layer must wait for an acknowledgement of the 418 SCSI Response PDU that carried the SCSI response requiring 419 the Response Fence behavior. The fence MUST be considered 420 cleared only after receiving the acknowledgement. 422 d) All further status processing for the LU is resumed only 423 after clearing the fence. If any new responses for the 424 I_T_L nexus are received from the SCSI layer before the 425 fence is cleared, those Response PDUs MUST be held and 426 queued at the iSCSI layer until the fence is cleared. 428 3.3.3 Current List of Fenced Response Use Cases 430 This section lists the fenced response use cases that iSCSI 431 implementations MUST comply with. However, this is not an 432 exhaustive enumeration. It is expected that as SCSI protocol 433 specifications evolve, the specifications will specify when 434 response fencing is required on a case-by-case basis. 436 Whenever the TaskReporting key (section 9.1) is negotiated to 437 ResponseFence or FastAbort for an iSCSI session, target iSCSI 438 layer MUST assume that Response Fence is required for the 439 following SCSI completion messages: 441 1. The first completion message carrying the UA after the 442 multi-task abort on issuing and third-party sessions. See 443 section 4.1.1 for related TMF discussion. 445 2. The TMF Response carrying the multi-task TMF Response on 446 the issuing session. 448 3. The completion message indicating ACA establishment on the 449 issuing session. 451 4. The first completion message carrying the ACA ACTIVE status 452 after ACA establishment on issuing and third-party 453 sessions. 455 5. The TMF Response carrying the Clear ACA response on the 456 issuing session. 458 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 459 command 461 Note: Due to the absence of ACA-related fencing requirements in 462 [RFC3720], initiator implementations SHOULD NOT use ACA on 463 multi-connection iSCSI sessions to targets complying only with 464 [RFC3720]. Initiators which want to employ ACA on multi- 465 connection iSCSI sessions SHOULD first assess response fencing 466 behavior via negotiating for ResponseFence or FastAbort values 467 for the TaskReporting (section 9.1) key. 469 4 Task Management 471 4.1 Requests Affecting Multiple Tasks 473 This section clarifies and updates the original text in section 474 10.6.2 of [RFC3720]. The clarified semantics (section 4.1.2) 475 are a superset of the protocol behavior required in the original 476 text and all iSCSI implementations MUST support the new 477 behavior. The updated semantics (section 4.1.3) on the other 478 hand are mandatory only when the new key TaskReporting (section 479 9.1) is negotiated to "FastAbort". 481 4.1.1 Scope of affected tasks 483 This section defines the notion of "affected tasks" in multi- 484 task abort scenarios. Scope definitions in this section apply 485 to both the clarified protocol behavior (section 4.1.2) and the 486 updated protocol behavior (section 4.1.3). 488 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 489 identified by the LUN field in the ABORT TASK SET TMF 490 Request PDU. 492 CLEAR TASK SET: All outstanding tasks in the task set for 493 the LU identified by the LUN field in the CLEAR TASK SET 494 TMF Request PDU. See [SPC3] for the definition of a "task 495 set". 497 LOGICAL UNIT RESET: All outstanding tasks from all 498 initiators for the LU identified by the LUN field in the 499 LOGICAL UNIT RESET Request PDU. 501 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks 502 from all initiators across all LUs to which the TMF-issuing 503 session has access to on the SCSI target device hosting the 504 iSCSI session. 506 Usage: an "ABORT TASK SET TMF Request PDU" in the preceding text 507 is an iSCSI TMF Request PDU with the "Function" field set to 508 "ABORT TASK SET" as defined in [RFC3720]. Similar usage is 509 employed for other scope descriptions. 511 4.1.2 Clarified multi-task abort semantics 513 All iSCSI implementations MUST support the protocol behavior 514 defined in this section as the default behavior. The execution 515 of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET 516 WARM RESET, and TARGET COLD RESET TMF Requests consists of the 517 following sequence of actions in the specified order on the 518 specified party. 520 The initiator iSCSI layer: 522 a. MUST continue to respond to each TTT received for the 523 affected tasks. 525 b. SHOULD process any responses received for affected tasks in 526 the normal fashion. This is acceptable because the 527 responses are guaranteed to have been sent prior to the TMF 528 response. 530 c. Should receive the TMF Response concluding all the tasks in 531 the set of affected tasks. 533 The target iSCSI layer: 535 a. MUST wait for responses on currently valid target transfer 536 tags of the affected tasks from the issuing initiator. MAY 537 wait for responses on currently valid target transfer tags 538 of the affected tasks from third-party initiators. 540 b. MUST wait (concurrent with the wait in Step.a) for all 541 commands of the affected tasks to be received based on the 542 CmdSN ordering. SHOULD NOT wait for new commands on 543 third-party affected sessions - only the instantiated tasks 544 have to be considered for the purpose of determining the 545 affected tasks. In the case of target-scoped requests 546 (i.e. TARGET WARM RESET and TARGET COLD RESET), all the 547 commands that are not yet received on the issuing session 548 in the command stream however can be considered to have 549 been received with no command waiting period - i.e. the 550 entire CmdSN space up to the CmdSN of the task management 551 function can be "plugged". 553 c. MUST propagate the TMF request to and receive the response 554 from the target SCSI layer. 556 d. MUST provide Response Fence behavior for the TMF Response 557 on issuing session as specified in 3.3.2. 559 e. MUST provide the Response Fence behavior on the first post- 560 TMF Response on third-party sessions as specified in 3.3.2. 561 If some tasks originate from non-iSCSI I_T_L nexuses then 562 the means by which the target ensures that all affected 563 tasks have returned their status to the initiator are 564 defined by the specific non-iSCSI transport protocol(s). 566 Technically, the TMF servicing is complete in Step.d. Data 567 transfers corresponding to terminated tasks may however still be 568 in progress on third-party iSCSI sessions even at the end of 569 Step.e. TMF Response MUST NOT be sent by the target iSCSI layer 570 before the end of Step.d, and MAY be sent at the end of Step.d 571 despite these outstanding data transfers until after Step.e. 573 4.1.3 Updated multi-task abort semantics 575 Protocol behavior defined in this section MUST be implemented by 576 all iSCSI implementations complying with this document. 577 Protocol behavior defined in this section MUST be exhibited by 578 iSCSI implementations on an iSCSI session when they negotiate 579 the TaskReporting (section 9.1) key to "FastAbort" on that 580 session. The execution of ABORT TASK SET, CLEAR TASK SET, 581 LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF 582 Requests consists of the following sequence of actions in the 583 specified order on the specified party. 585 The initiator iSCSI layer: 587 a. MUST NOT send any more Data-Out PDUs for affected tasks on 588 the issuing connection of the issuing iSCSI session once 589 the TMF is sent to the target. 591 b. SHOULD process any responses received for affected tasks in 592 the normal fashion. This is acceptable because the 593 responses are guaranteed to have been sent prior to the TMF 594 response. 596 c. MUST respond to each Async Message PDU with AsyncEvent=5 as 597 defined in section 8.1. 599 d. MUST treat the TMF response as terminating all affected 600 tasks for which responses have not been received, and MUST 601 discard any responses for affected tasks received after the 602 TMF response is passed to the SCSI layer (although the 603 semantics defined in this section ensure that such an out 604 of order scenario will never happen with a compliant target 605 implementation). 607 The target iSCSI layer: 609 a. MUST wait for all commands of the affected tasks to be 610 received based on the CmdSN ordering on the issuing 611 session. SHOULD NOT wait for new commands on third-party 612 affected sessions - only the instantiated tasks have to be 613 considered for the purpose of determining the affected 614 tasks. In the case of target-scoped requests (i.e. TARGET 615 WARM RESET and TARGET COLD RESET), all the commands that 616 are not yet received on the issuing session in the command 617 stream can be considered to have been received with no 618 command waiting period - i.e. the entire CmdSN space up to 619 the CmdSN of the task management function can be "plugged". 620 b. MUST propagate the TMF request to and receive the response 621 from the target SCSI layer. 623 c. MUST leave all active "affected TTTs" (i.e. active TTTs 624 associated with affected tasks) valid. 625 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 626 (section 8.1) on: 627 i) each connection of each third-party session to which at 628 least one affected task is allegiant if 629 TaskReporting=FastAbort is operational on that third- 630 party session, and 631 ii) each connection except the issuing connection of the 632 issuing session that has at least one allegiant affected 633 task. 635 If there are multiple affected LUs (say due to a target 636 reset), then one Async Message PDU MUST be sent for each 637 such LU on each connection that has at least one allegiant 638 affected task. The LUN field in the Asynchronous Message 639 PDU MUST be set to match the LUN for each such LU. 641 e. MUST address the Response Fence flag on the TMF Response on 642 issuing session as defined in 3.3.2. 644 f. MUST address the Response Fence flag on the first post-TMF 645 Response on third-party sessions as defined in 3.3.2. If 646 some tasks originate from non-iSCSI I_T_L nexuses then the 647 means by which the target ensures that all affected tasks 648 have returned their status to the initiator are defined by 649 the specific non-iSCSI transport protocol(s). 651 g. MUST free up the affected TTTs (and STags, if applicable) 652 and the corresponding buffers, if any, once it receives 653 each associated Nop-Out acknowledgement that the initiator 654 generated in response to each Async Message. 656 Technically, the TMF servicing is complete in Step.e. Data 657 transfers corresponding to terminated tasks may however still be 658 in progress even at the end of Step.f. TMF Response MUST NOT be 659 sent by the target iSCSI layer before the end of Step.e, and MAY 660 be sent at the end of Step.e despite these outstanding Data 661 transfers until Step.g. Step.g specifies an event to free up 662 any such resources that may have been reserved to support 663 outstanding data transfers. 665 4.1.3.1 Clearing effects update 667 Appendix F.1 of [RFC3720] specifies the clearing effects of 668 target and LU resets on "Incomplete TTTs" as "Y". This meant 669 that a target warm reset or a target cold reset or an LU reset 670 would clear the active TTTs upon completion. The 671 TaskReporting=FastAbort (section 9.1) semantics defined by this 672 section however do not guarantee that the active TTTs are 673 cleared by the end of the reset operations. In fact, the new 674 semantics are designed to allow clearing the TTTs in a "lazy" 675 fashion after the TMF Response is delivered. Thus, when 676 TaskReporting=FastAbort is operational on a session, the 677 clearing effects of reset operations on "Incomplete TTTs" is 678 "N". 680 4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions 682 If an iSCSI target implementation is capable of supporting 683 TaskReporting=FastAbort functionality (section 9.1), it may end 684 up in a situation where some sessions have TaskReporting=RFC3720 685 operational (RFC3720 sessions) while some other sessions have 686 TaskReporting=FastAbort operational (FastAbort sessions) even 687 while accessing a shared set of affected tasks (section 4.1.1). 689 If the issuing session is a RFC3720 session, iSCSI target 690 implementation is FastAbort-capable and third-party affected 691 session is a FastAbort session, the following behavior SHOULD be 692 exhibited by the iSCSI target layer: 694 a. Between steps c and d of target behavior in section 4.1.2, 695 send an Asynchronous Message PDU with AsyncEvent=5 (section 696 8.1) on each connection of each third-party session to 697 which at least one affected task is allegiant. If there 698 are multiple affected LUs, then send one Async Message PDU 699 for each such LU on each connection that has at least one 700 allegiant affected task. When sent, the LUN field in the 701 Asynchronous Message PDU MUST be set to match the LUN for 702 each such LU. 703 b. After step e of target behavior in section 4.1.2, free up 704 the affected TTTs (and STags, if applicable) and the 705 corresponding buffers, if any, once each associated Nop-Out 706 acknowledgement is received that the third-party initiator 707 generated in response to each Async Message sent in step a. 709 If the issuing session is a FastAbort session, iSCSI target 710 implementation is FastAbort-capable and third-party affected 711 session is a RFC3720 session, the following behavior MUST be 712 exhibited by the iSCSI target layer: Asynchronous Message PDUs 713 MUST NOT be sent on the third-party session to prompt the 714 FastAbort behavior. 716 If the third-party affected session is a FastAbort session and 717 issuing session is a FastAbort session, initiator in the third- 718 party role MUST respond to each Async Message PDU with 719 AsyncEvent=5 as defined in section 8.1. Note that an initiator 720 MAY thus receive these Async Messages on a third-party affected 721 session even if the session is a single-connection session. 723 4.1.5 Implementation considerations 725 Both in clarified semantics (section 4.1.2) and updated 726 semantics (section 4.1.3), there may be outstanding data 727 transfers even after the TMF completion is reported on the 728 issuing session. In the case of iSCSI/iSER [iSER], these would 729 be tagged data transfers for STags not owned by any active 730 tasks. Whether or not real buffers support these data transfers 731 is implementation-dependent. However, the data transfers 732 logically MUST be silently discarded by the target iSCSI layer 733 in all cases. A target MAY, on an implementation-defined 734 internal timeout, also choose to drop the connections on which 735 it did not receive the expected Data-out sequences (section 736 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to 737 reclaim the associated buffer, STag and TTT resources as 738 appropriate. 740 4.1.6 Rationale behind the new semantics 742 There are fundamentally three basic objectives behind the 743 semantics specified in section 4.1.2 and section 4.1.3. 745 1. Maintaining an ordered command flow I_T nexus abstraction 746 to the target SCSI layer even with multi-connection 747 sessions. 749 o Target iSCSI processing of a TMF request must maintain 750 the single flow illusion. Target behavior in Step.b 751 of section 4.1.2 and Step.a of section 4.1.3 752 correspond to this objective. 754 2. Maintaining a single ordered response flow I_T nexus 755 abstraction to the initiator SCSI layer even with multi- 756 connection sessions when one response (i.e. TMF response) 757 could imply the status of other unfinished tasks from the 758 initiator's perspective. 760 o Target must ensure that the initiator does not see 761 "old" task responses (that were placed on the wire 762 chronologically earlier than the TMF Response) after 763 seeing the TMF response. Target behavior in Step.d of 764 section 4.1.2 and Step.e of section 4.1.3 correspond 765 to this objective. 767 o Whenever the result of a TMF action is visible across 768 multiple I_T_L nexuses, [SAM2] requires the SCSI 769 device server to trigger a UA on each of the other 770 I_T_L nexuses. Once an initiator is notified of such 771 an UA, the application client on the receiving 772 initiator is required to clear its task state (clause 773 5.5 in [SAM2]) for the affected tasks. It would thus 774 be inappropriate to deliver a SCSI Response for a task 775 after the task state is cleared on the initiator, i.e. 776 after the UA is notified. The UA notification 777 contained in the first SCSI Response PDU on each 778 affected Third-party I_T_L nexus after the TMF action 779 thus MUST NOT pass the affected task responses on any 780 of the iSCSI sessions accessing the LU. Target 781 behavior in Step.e of section 4.1.2 and Step.f of 782 section 4.1.3 correspond to this objective. 784 3. Draining all active TTTs corresponding to affected tasks 785 in a deterministic fashion. 787 o Data-out PDUs with stale TTTs arriving after the tasks 788 are terminated can create a buffer management problem 789 even for traditional iSCSI implementations, and is 790 fatal for the connection for iSCSI/iSER 791 implementations. Either the termination of affected 792 tasks should be postponed until the TTTs are retired 793 (as in Step.a of section 4.1.2), or the TTTs and the 794 buffers should stay allocated beyond task termination 795 to be deterministically freed up later (as in Step.c 796 and Step.g of section 4.1.3). 798 The only other notable optimization is the plugging. If all 799 tasks on an I_T nexus will be aborted anyway (as with a target 800 reset), there is no need to wait to receive all commands to plug 801 the CmdSN holes. Target iSCSI layer can simply plug all missing 802 CmdSN slots and move on with TMF processing. The first 803 objective (maintaining a single ordered command flow) is still 804 met with this optimization because target SCSI layer only sees 805 ordered commands. 807 5 Discovery semantics 809 5.1 Error Recovery for Discovery Sessions 811 The negotiation of the key ErrorRecoveryLevel is not required 812 for Discovery sessions - i.e. for sessions that negotiated 813 "SessionType=Discovery" - because the default value of 0 is 814 necessary and sufficient for Discovery sessions. It is however 815 possible that some legacy iSCSI implementations might attempt to 816 negotiate the ErrorRecoveryLevel key on Discovery sessions. 817 When such a negotiation attempt is made by the remote side, a 818 compliant iSCSI implementation MUST propose a value of 0 (zero) 819 in response. The operational ErrorRecoveryLevel for Discovery 820 sessions thus MUST be 0. This naturally follows from the 821 functionality constraints [RFC3720] imposes on Discovery 822 sessions. 824 5.2 Reinstatement Semantics of Discovery Sessions 826 Discovery sessions are intended to be relatively short-lived. 827 Initiators are not expected to establish multiple Discovery 828 sessions to the same iSCSI Network Portal (see [RFC3720]). An 829 initiator may use the same iSCSI Initiator Name and ISID when 830 establishing different unique sessions with different targets 831 and/or different portal groups. This behavior is discussed in 832 Section 9.1.1 of [RFC3720] and is, in fact, encouraged as 833 conservative reuse of ISIDs. ISID RULE in [RFC3720] states that 834 there must not be more than one session with a matching 4-tuple: 835 . While 836 the spirit of the ISID RULE applies to Discovery sessions the 837 same as it does for Normal sessions, note that some Discovery 838 sessions differ from the Normal sessions in two important 839 aspects: 841 Because [RFC3720] allows a Discovery session to be 842 established without specifying a TargetName key in the 843 Login Request PDU (let us call such a session an "Unnamed" 844 Discovery session), there is no Target Node context to 845 enforce the ISID RULE. 847 Portal Groups are defined only in the context of a Target 848 Node. When the TargetName key is NULL-valued (i.e. not 849 specified), the TargetPortalGroupTag thus cannot be 850 ascertained to enforce the ISID RULE. 852 The following sections describe the two scenarios - Named 853 Discovery sessions and Unnamed Discovery sessions - separately. 855 5.2.1 Unnamed Discovery Sessions 857 For Unnamed Discovery sessions, neither the TargetName nor the 858 TargetPortalGroupTag is available to the targets in order to 859 enforce the ISID RULE. So the following rule applies. 861 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 862 following 4-tuple for Unnamed Discovery sessions: 863 . The following 864 semantics are implied by this uniqueness requirement. 866 Targets SHOULD allow concurrent establishment of one Discovery 867 session with each of its Network Portals by the same initiator 868 port with a given iSCSI Node Name and an ISID. Each of the 869 concurrent Discovery sessions, if established by the same 870 initiator port to other Network Portals, MUST be treated as 871 independent sessions - i.e. one session MUST NOT reinstate the 872 other. 874 A new Unnamed Discovery session that has a matching 875 to an existing 876 discovery session MUST reinstate the existing Unnamed Discovery 877 session. Note thus that only an Unnamed Discovery session may 878 reinstate an Unnamed Discovery session. 880 5.2.2 Named Discovery Sessions 882 For a Named Discovery session, the TargetName key is specified 883 by the initiator and thus the target can unambiguously ascertain 884 the TargetPortalGroupTag as well. Since all the four elements 885 of the 4-tuple are known, the ISID RULE MUST be enforced by 886 targets with no changes from [RFC3720] semantics. A new session 887 with a matching thus will reinstate an existing session. 889 Note in this case that any new iSCSI session (Discovery or 890 Normal) with the matching 4-tuple may reinstate an existing 891 Named Discovery iSCSI session. 893 5.3 Target PDUs during Discovery 895 Targets SHOULD NOT send any responses other than a Text Response 896 and Logout Response on a Discovery session, once in full feature 897 phase. 899 Implementation Note: A target may simply drop the connection in 900 a Discovery session when it would have requested a Logout via an 901 Async Message on Normal sessions. 903 6 Negotiation and Others 905 6.1 TPGT Values 907 [SAM2] and [SAM3] specifications incorrectly note in their 908 informative text that TPGT value should be non-zero, although 909 [RFC3720] allows the value of zero for TPGT. This section is to 910 clarify that zero value is expressly allowed as a legal value 911 for TPGT. This discrepancy currently stands corrected in 912 [SAM4]. 914 6.2 SessionType Negotiation 916 During the Login phase, the SessionType key is offered by the 917 initiator to choose the type of session it wants to create with 918 the target. The target may accept or reject the offer. 919 Depending on the type of the session, a target may decide on 920 resources to allocate and the security to enforce etc. for the 921 session. If the SessionType key is thus going to be offered as 922 "Discovery", it SHOULD be offered in the initial Login request 923 by the initiator. 925 6.3 Understanding NotUnderstood 927 [RFC3720] defines NotUnderstood as a valid answer during a 928 negotiation text key exchange between two iSCSI nodes. 929 NotUnderstood has the reserved meaning that the sending side did 930 not understand the proposed key semantics. This section seeks 931 to clarify that NotUnderstood is a valid answer for both 932 declarative and negotiated keys. The general iSCSI philosophy 933 is that comprehension precedes processing for any iSCSI key. A 934 proposer of an iSCSI key, negotiated or declarative, in a text 935 key exchange MUST thus be able to properly handle a 936 NotUnderstood response. 938 The proper way to handle a NotUnderstood response depends on 939 where the key is specified and whether the key is declarative 940 vs. negotiated All keys defined in [RFC3720] MUST be supported 941 by all compliant implementations; a NotUnderstood answer on any 942 of the [RFC3720] keys therefore MUST be considered a protocol 943 error and handled accordingly. For all other later keys, a 944 NotUnderstood answer concludes the negotiation for a negotiated 945 key whereas for a declarative key, a NotUnderstood answer simply 946 informs the declarer of lack of comprehension by the receiver. 948 In either case, a NotUnderstood answer always requires that the 949 protocol behavior associated with that key be not used within 950 the scope of the key (connection/session) by either side. 952 6.4 Outstanding Negotiation Exchanges 954 There was some uncertainty around the number of outstanding 955 Login Response PDUs on a connection. [RFC3720] offers the 956 analogy of SCSI linked commands to Login and Text negotiations 957 in sections 5.3 and 10.10.3 respectively, but does not make it 958 fully explicit. This section is to offer a clarification in 959 this regard. 961 There MUST NOT be more than one outstanding Login Request or 962 Login Response or Text Request or Text Response PDU on an iSCSI 963 connection. An outstanding PDU in this context is one that has 964 not been acknowledged by the remote iSCSI side. 966 7 iSCSI Error Handling and Recovery 968 7.1 ITT 970 Section 10.19 in [RFC3720] mentions this in passing but noted 971 here again for making it obvious since the semantics apply to 972 the initiators in general. An ITT value of 0xffffffff is 973 reserved and MUST NOT be assigned for a task by the initiator. 974 The only instance it may be seen on the wire is in a target- 975 initiated NOP-In PDU (and in the initiator response to that PDU 976 if necessary). 978 7.2 Format Errors 980 Section 6.6 of [RFC3720] discusses format error handling. This 981 section elaborates on the "inconsistent" PDU field contents 982 noted in [RFC3720]. 984 All initiator-detected PDU construction errors MUST be 985 considered as format errors. Some examples of such errors are: 987 - NOP-In with a valid TTT but an invalid LUN 989 - NOP-In with a valid ITT (i.e. a NOP-In response) and also a 990 valid TTT 992 - SCSI Response PDU with Status=CHECK CONDITION, but 993 DataSegmentLength = 0 995 7.3 Digest Errors 997 Section 6.7 of [RFC3720] discusses digest error handling. It 998 states that "No further action is necessary for initiators if 999 the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" 1000 on detecting a payload digest error. This is incorrect. 1002 An Asynchronous Message PDU or a Reject PDU carries the next 1003 StatSN value on an iSCSI connection, advancing the StatSN. When 1004 an initiator discards one of these PDUs due to a payload digest 1005 error, the entire PDU including the header MUST be discarded. 1006 Consequently, the initiator MUST treat the exception like a loss 1007 of any other solicited response PDU - i.e. it MUST use one of 1008 the following options noted in [RFC3720]: 1010 a) Request PDU retransmission with a status SNACK. 1012 b) Logout the connection for recovery and continue the 1013 tasks on a different connection instance. 1015 c) Logout to close the connection (abort all the commands 1016 associated with the connection). 1018 7.4 Message Error Checking 1020 There has been some uncertainty on the extent to which incoming 1021 messages have to be checked for protocol errors, beyond what is 1022 strictly required for processing the inbound message. This 1023 section addresses that question. 1025 Unless [RFC3720] or this draft requires it, an iSCSI 1026 implementation is not required to do an exhaustive protocol 1027 conformance checking on an incoming iSCSI PDU. The iSCSI 1028 implementation especially is not required to double-check the 1029 remote iSCSI implementation's conformance to protocol 1030 requirements. 1032 8 iSCSI PDUs 1034 8.1 Asynchronous Message 1036 This section defines additional semantics for the Asynchronous 1037 Message PDU defined in section 10.9 of [RFC3720] using the same 1038 conventions. 1040 The following new legal value for AsyncEvent is defined: 1042 5: all active tasks for LU with matching LUN field in the Async 1043 Message PDU are being terminated. 1045 The receiving initiator iSCSI layer MUST respond to this Message 1046 by taking the following steps in order. 1048 i) Stop Data-Out transfers on that connection for all active 1049 TTTs for the affected LUN quoted in the Async Message 1050 PDU. 1051 ii) Acknowledge the StatSN of the Async Message PDU via a 1052 Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor), 1053 while copying the LUN field from Async Message to Nop- 1054 Out. 1056 The new AsyncEvent defined in this section however MUST NOT be 1057 used on an iSCSI session unless the new TaskReporting text key 1058 defined in section 9.1 was negotiated to FastAbort on the 1059 session. 1061 8.2 Reject 1063 Section 10.17.1 of [RFC3720] specifies the Reject reason code of 1064 0x0b with an explanation of "Negotiation Reset". At this point, 1065 we do not see any legitimate iSCSI protocol use case for using 1066 this reason code. Thus reason code 0x0b MUST be considered as 1067 deprecated and MUST NOT be sent by implementations that 1068 comply with the requirements of this document. An 1069 implementation receiving reason code 0x0b MUST treat it as a 1070 negotiation failure that terminates the Login phase and the TCP 1071 connection, as specified in Section 6.10 of [RFC3720]. 1073 Section 5.4 of [RFC3720] states: 1075 Neither the initiator nor the target should attempt to 1076 declare or negotiate a parameter more than once during any 1077 negotiation sequence without an intervening operational 1078 parameter negotiation reset, except for responses to 1079 specific keys that explicitly allow repeated key 1080 declarations (e.g., TargetAddress). 1082 The deprecation of reason code 0x0b eliminates the possibility 1083 of an operational parameter negotiation reset, causing 1084 the phrase "without an intervening operational 1085 parameter negotiation reset" in [RFC3720] to refer to an 1086 impossible event. The quoted phrase SHOULD be ignored by 1087 receivers that handle reason code 0x0b in the manner specified 1088 in this section. 1090 9 Login/Text Operational Text Keys 1092 This section follows the same conventions as section 12 of 1093 [RFC3720]. 1095 9.1 TaskReporting 1097 Use: LO 1098 Senders: Initiator and Target 1099 Scope: SW 1101 Irrelevant when: SessionType=Discovery 1102 TaskReporting= 1104 Default is RFC3720. 1105 Result function is AND. 1107 This key is used to negotiate the task completion reporting 1108 semantics from the SCSI target. Following table describes the 1109 semantics an iSCSI target MUST support for respective negotiated 1110 key values. Whenever this key is negotiated, at least the 1111 RFC3720 and ResponseFence values MUST be offered as options by 1112 the negotiation originator. 1114 +--------------+------------------------------------------+ 1115 | Name | Description | 1116 +--------------+------------------------------------------+ 1117 | RFC3720 | RFC 3720-compliant semantics. Response | 1118 | | fencing is not guaranteed and fast | 1119 | | completion of multi-task aborting is not | 1120 | | supported | 1121 +--------------+------------------------------------------+ 1122 | ResponseFence| Response Fence (section 3.3.1) semantics | 1123 | | MUST be supported in reporting task | 1124 | | completions | 1125 +--------------+------------------------------------------+ 1126 | FastAbort | Updated fast multi-task abort semantics | 1127 | | defined in section 4.1.3 MUST be | 1128 | | supported. Support for Response Fence is| 1129 | | implied - i.e. section 3.3.1 semantics | 1130 | | MUST be supported as well | 1131 +--------------+------------------------------------------+ 1132 When TaskReporting is not negotiated to FastAbort, the [RFC3720] 1133 TMF semantics as clarified in section 4.1.2 MUST be used. 1135 10 Security Considerations 1137 This document does not introduce any new security considerations 1138 other than those already noted in [RFC3720]. Consequently, all 1139 the iSCSI-related security text in [RFC3723] is also directly 1140 applicable to this document. 1142 11 IANA Considerations 1144 11.1 iSCSI-related IANA registries 1146 This draft creates the following iSCSI-related registries for 1147 IANA to manage. 1149 1. iSCSI Opcodes 1151 2. iSCSI Login/Text Keys 1153 3. iSCSI Asynchronous Events 1155 4. iSCSI Task Management Function Codes 1157 5. iSCSI Login Response Status Codes 1159 6. iSCSI Reject Reason Codes 1161 7. iSCSI Authentication Mechanisms 1163 8. iSCSI Digest Algorithms 1165 9. iSER Opcodes 1167 Each of the following sections describes the proposed registries 1168 and their administration policies in more detail. 1170 11.2 iSCSI Opcodes 1172 Name of the registry: "iSCSI Opcodes" 1174 Namespace details: Numerical values that can fit in one octet 1175 with most significant two bits (bits 0 and 1) already designated 1176 by [RFC3720], bit 0 being reserved and bit 1 for immediate 1177 delivery. Bit 2 is designated to identify the originator of the 1178 opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target 1180 Information that must be provided to assign a new value: An 1181 IESG-approved standards-track specification defining the 1182 semantics and interoperability requirements of the proposed new 1183 value and the fields to be recorded in the registry 1185 Assignment policy: 1187 1) If initiator opcode and target opcode to identify the request 1188 and response of a new type of protocol operation are requested, 1189 assign the same lower five bits (i.e. Bit 3 through Bit 7) for 1190 both opcodes, e.g. 0x13 and 0x33 1192 2) If only the initiator opcode or target opcode is requested to 1193 identify a one-way protocol message (i.e. request without a 1194 response or a "response" without a request), assign an unused 1195 number from the appropriate category (i.e. Bit 2 set to 0 or 1 1196 for initiator category or target category) and add the other 1197 pair member (i.e. same opcode with Bit 2 set to 1 or 0, 1198 respectively) to "Reserved to IANA" list. 1200 3) If there are no other opcodes available to assign on a 1201 request for a new opcode except the reserved opcodes in the 1202 "Reserved to IANA" list, allocate the opcodes from the 1203 appropriate category (initiator or target). 1205 Fields to record in the registry: Assigned value, Who can 1206 originate (Initiator or Target), Operation Name and its 1207 associated RFC reference 1209 Initial registry contents: 1211 0x00, Initiator, NOP-Out, [RFC3720] 1213 0x01, Initiator, SCSI Command, [RFC3720] 1215 0x02, Initiator, SCSI Task Management function request, 1216 [RFC3720] 1218 0x03, Initiator, Login Request, [RFC3720] 1220 0x04, Initiator, Text Request, [RFC3720] 1222 0x05, Initiator, SCSI Data-Out, [RFC3720] 1224 0x06, Initiator, Logout Request, [RFC3720] 1226 0x10, Initiator, SNACK Request, [RFC3720] 1228 0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720] 1230 0x20, Target, NOP-In, [RFC3720] 1232 0x21, Target, SCSI Response, [RFC3720] 1233 0x22, Target, SCSI Task Management function response, [RFC3720] 1235 0x23, Target, Login Response, [RFC3720] 1237 0x24, Target, Text Response, [RFC3720] 1239 0x25, Target, SCSI Data-In, [RFC3720] 1241 0x26, Target, Logout Response, [RFC3720] 1243 0x31, Target, Ready To Transfer (R2T), [RFC3720] 1245 0x32, Target, Asynchronous Message, [RFC3720] 1247 0x3c-0x3e, Target, Vendor specific codes, [RFC3720] 1249 0x3f, Target, Reject, [RFC3720] 1251 "Reserved to IANA" opcodes: 0x11, 0x12, 0x1f, 0x30 1253 Review process: 1255 Standards Action ([IANA]) 1257 11.3 iSCSI Login/Text Keys 1259 Name of the registry: "iSCSI Text Keys" 1261 Namespace details: Key=value pairs with "Key" names in UTF-8 1262 Unicode, and the permissible "value" options for the "Key" are 1263 Key-dependent. [RFC3720] defines the rules on key names and 1264 allowed values 1266 Information that must be provided to assign a new value: An 1267 IESG-approved standards-track specification defining the 1268 semantics and interoperability requirements of the proposed new 1269 Key per [RFC3720] key specification template and the fields to 1270 be recorded in the registry 1272 Assignment policy: 1274 If the requested Key name is not already assigned and is roughly 1275 representative of its proposed semantics, it may be assigned to 1276 the requester. 1278 Fields to record in the registry: Assigned Key Name and its 1279 associated RFC reference 1281 Initial registry contents: 1283 AuthMethod, [RFC3720] 1285 HeaderDigest, [RFC3720] 1287 DataDigest, [RFC3720] 1289 MaxConnections, [RFC3720] 1291 SendTargets, [RFC3720] 1293 TargetName, [RFC3720] 1295 InitiatorName, [RFC3720] 1297 TargetAlias, [RFC3720] 1299 InitiatorAlias, [RFC3720] 1301 TargetAddress, [RFC3720] 1303 TargetPortalGroupTag, [RFC3720] 1305 InitialR2T, [RFC3720] 1307 ImmediateData, [RFC3720] 1309 MaxRecvDataSegmentLength, [RFC3720] 1311 MaxBurstLength, [RFC3720] 1313 FirstBurstLength, [RFC3720] 1315 DefaultTime2Wait, [RFC3720] 1317 DefaultTime2Retain, [RFC3720] 1319 MaxOutstandingR2T, [RFC3720] 1321 DataPDUInOrder, [RFC3720] 1322 DataSequenceInOrder, [RFC3720] 1324 ErrorRecoveryLevel, [RFC3720] 1326 SessionType, [RFC3720] 1328 RDMAExtensions, [iSER] 1330 TargetRecvDataSegmentLength, [iSER] 1332 InitiatorRecvDataSegmentLength, [iSER] 1334 MaxOutstandingUnexpectedPDUs, [iSER] 1336 TaskReporting, this document 1338 Review process: 1340 Standards Action ([IANA]) 1342 11.4 iSCSI Asynchronous Events 1344 Name of the registry: "iSCSI Asynchronous Events" 1346 Namespace details: Numerical values that can fit in one octet 1348 Information that must be provided to assign a new value: A IESG- 1349 approved standards-track specification defining the semantics 1350 and interoperability requirements of the proposed new Event and 1351 the fields to be recorded in the registry 1353 Assignment policy: 1355 If the requested value is not already assigned, it may be 1356 assigned to the requester. 1358 Fields to record in the registry: Assigned Event number, 1359 Description and its associated RFC reference 1360 Initial registry contents: 1362 0, SCSI Async Event, [RFC3720] 1364 1, Logout Request, [RFC3720] 1366 2, Connection drop notification, [RFC3720] 1368 3, Session drop notification, [RFC3720] 1370 4, Negotiation Request, [RFC3720] 1372 5, Task termination, this document 1374 248-254, Vendor-unique, this document 1376 255, Vendor-unique, [RFC3720] 1378 Review process: 1380 Standards Action ([IANA]) 1382 11.5 iSCSI Task Management Function Codes 1384 Name of the registry: "iSCSI TMF Codes" 1386 Namespace details: Numerical values that can fit in 7 bits 1388 Information that must be provided to assign a new value: An 1389 IESG-approved standards-track specification defining the 1390 semantics and interoperability requirements of the proposed new 1391 Code and the fields to be recorded in the registry 1393 Assignment policy: 1395 If the requested value is not already assigned, it may be 1396 assigned to the requester. 1398 Fields to record in the registry: Assigned Code, Description and 1399 its associated RFC reference 1401 Initial registry contents: 1403 1, ABORT TASK, [RFC3720] 1404 2, ABORT TASK SET, [RFC3720] 1406 3, CLEAR ACA, [RFC3720] 1408 4, CLEAR TASK SET, [RFC3720] 1410 5, LOGICAL UNIT RESET, [RFC3720] 1412 6, TARGET WARM RESET, [RFC3720] 1414 7, TARGET COLD RESET, [RFC3720] 1416 8, TASK REASSIGN, [RFC3720] 1418 Review process: 1420 Standards Action ([IANA]) 1422 11.6 iSCSI Login Response Status Codes 1424 Name of the registry: "iSCSI Login Response Status Codes" 1426 Namespace details: Numerical values; Status-Class (one octet), 1427 Status-Detail (one octet) for each possible value of Status- 1428 Class except for Vendor-Unique Status-Class (0x0f) 1430 Information that must be provided to assign a new value: An 1431 IESG-approved specification defining the semantics and 1432 interoperability requirements of the proposed new Code, its 1433 Status-Class affiliation (only if a new Status-Detail value is 1434 being proposed for a Status-Class), Status-Class definition 1435 (only if a new Status-Class is being proposed) and the fields to 1436 be recorded in the registry 1438 Assignment policy: 1440 If the requested value is not already assigned, it may be 1441 assigned to the requester. 1443 Fields to record in the Status-Class main registry: Assigned 1444 Code, Description and its associated RFC reference 1446 Fields to record in the Status-Detail sub-registries: Status- 1447 Class, Assigned Code, Description and its associated RFC 1448 reference 1450 Initial registry contents (Status-Class): 1452 0x00, Success, [RFC3720] 1454 0x01, Redirection, [RFC3720] 1456 0x02, Initiator Error, [RFC3720] 1458 0x03, Target Error, [RFC3720] 1460 0x0f, Vendor-Unique, this document 1462 Initial sub-registry contents (Status-Detail for Status- 1463 Class=0x00): 1465 0x00, 0x00, Success, [RFC3720] 1467 Initial sub-registry contents (Status-Detail for Status- 1468 Class=0x01): 1470 0x01, 0x01, Temporary move, [RFC3720] 1472 0x01, 0x02, Permanent move, [RFC3720] 1474 Initial sub-registry contents (Status-Detail for Status- 1475 Class=0x02): 1477 0x02, 0x00, Miscellaneous, [RFC3720] 1479 0x02, 0x01, Authentication failure, [RFC3720] 1481 0x02, 0x02, Authorization failure, [RFC3720] 1483 0x02, 0x03, Not found, [RFC3720] 1484 0x02, 0x04, Target removed, [RFC3720] 1486 0x02, 0x05, Unsupported version, [RFC3720] 1488 0x02, 0x06, Too many connections, [RFC3720] 1490 0x02, 0x07, Missing parameter, [RFC3720] 1492 0x02, 0x08, Can't include in session, [RFC3720] 1494 0x02, 0x09, Unsupported session type, [RFC3720] 1496 0x02, 0x0a, Non-existent session, [RFC3720] 1498 0x02, 0x0b, Invalid during login, [RFC3720] 1500 Initial sub-registry contents (Status-Detail for Status- 1501 Class=0x03): 1503 0x03, 0x00, Target error, [RFC3720] 1505 0x03, 0x01, Service unavailable, [RFC3720] 1507 0x03, 0x02, Out of resources, [RFC3720] 1509 Review process: 1511 Standards Action ([IANA]) 1513 11.7 iSCSI Reject Reason Codes 1515 Name of the registry: "iSCSI Reject Reason Codes" 1517 Namespace details: Numerical values that can fit in a single 1518 octet 1520 Information that must be provided to assign a new value: A 1521 published specification defining the semantics and 1522 interoperability requirements of the proposed new Code and the 1523 fields to be recorded in the registry 1524 Assignment policy: 1526 If the requested value is not already assigned, it may be 1527 assigned to the requester. 1529 Fields to record in the registry: Assigned Code, Description and 1530 its associated RFC reference 1532 Initial registry contents: 1534 0x01, Reserved, [RFC3720] 1536 0x02, Data digest error, [RFC3720] 1538 0x03, SNACK Reject, [RFC3720] 1540 0x04, Protocol Error, [RFC3720] 1542 0x05, Command not supported, [RFC3720] 1544 0x06, Immediate command reject, [RFC3720] 1546 0x07, Task in progress, [RFC3720] 1548 0x08, Invalid data ack, [RFC3720] 1550 0x09, Invalid PDU field, [RFC3720] 1552 0x0a, Long op reject, [RFC3720] 1554 0x0b, "Deprecated reason code", this document 1556 0x0c, Waiting for Logout, [RFC3720] 1558 Review process: 1560 Standards Action ([IANA]) 1561 11.8 iSER Opcodes 1563 Name of the registry: "iSER Opcodes" 1565 Namespace details: Numerical values that can fit in 4 bits 1567 Information that must be provided to assign a new value: An 1568 IESG-approved specification defining the semantics and 1569 interoperability requirements of the proposed new value and the 1570 fields to be recorded in the registry 1572 Assignment policy: 1574 If the requested value is not already assigned, it may be 1575 assigned to the requester. 1577 Fields to record in the registry: Assigned value, Operation Name 1578 and its associated RFC reference 1580 Initial registry contents: 1582 0x1, iSCSI control-type, [iSER] 1584 0x2, iSER Hello, [iSER] 1586 0x3, iSER HelloReply, [iSER] 1588 Review process: 1590 Standards Action ([IANA]) 1591 12 References and Bibliography 1593 12.1 Normative References 1595 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 1596 M., and E. Zeidner, "Internet Small Computer Systems 1597 Interface (iSCSI)", RFC 3720, April 2004. 1599 [SPC3] ANSI INCITS 408-2005, SCSI Primary Commands-3. 1601 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1602 Requirement Levels", March 1997. 1604 [IANA] Alvestrand, H. and T. Narten, "Guidelines for Writing 1605 an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1606 October 1998. 1608 [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, 1609 P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet 1610 Draft draft-ietf-ips-iser-04.txt (work in progress), June 1611 2005. 1613 12.2 Informative References 1615 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., 1616 and M. Krueger, "Internet Small Computer Systems Interface 1617 (iSCSI) Naming and Discovery", RFC 3721, April 2004. 1619 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and 1620 F. Travostino, "Securing Block Storage Protocols over IP", 1621 RFC 3723, April 2004. 1623 [RFC3722] Bakke, M., "String Profile for Internet Small 1624 Computer Systems Interface (iSCSI) Names", RFC 3722, April 1625 2004. 1627 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 1628 Requirement Levels", BCP 14, RFC 2119, March 1997. 1630 [SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM- 1631 2). 1633 [SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM- 1634 3). 1636 [SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM- 1637 4), Work in Progress. 1639 13 Editor's Address 1641 Mallikarjun Chadalapaka 1642 Hewlett-Packard Company 1643 8000 Foothills Blvd. 1644 Roseville, CA 95747-5668, USA 1645 Phone: +1-916-785-5621 1646 E-mail: cbm@rose.hp.com 1648 14 Acknowledgements 1650 The IP Storage (ips) Working Group in the Transport Area of 1651 IETF has been responsible for defining the iSCSI protocol 1652 (apart from a host of other relevant IP Storage protocols). 1653 The editor acknowledges the contributions of the entire 1654 working group. 1656 The following individuals directly contributed to identifying 1657 [RFC3720] issues and/or suggesting resolutions to the issues 1658 clarified in this document: David Black, Gwendal Grignou, 1659 Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob 1660 Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh 1661 Gupta, Eddy Quicksall, Paul Koning. This document benefited 1662 from all these contributions. 1664 15 Full Copyright Statement 1666 Copyright (C) The IETF Trust (2007). This document is 1667 subject to the rights, licenses and restrictions contained in 1668 BCP 78, and except as set forth therein, the authors retain 1669 all their rights. 1671 This document and the information contained herein are 1672 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1673 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1674 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 1675 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1676 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1677 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1678 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1679 PARTICULAR PURPOSE. 1681 16 Intellectual Property Statement 1683 The IETF takes no position regarding the validity or scope of 1684 any Intellectual Property Rights or other rights that might 1685 be claimed to pertain to the implementation or use of the 1686 technology described in this document or the extent to which 1687 any license under such rights might or might not be 1688 available; nor does it represent that it has made any 1689 independent effort to identify any such rights. Information 1690 on the procedures with respect to rights in RFC documents can 1691 be found in BCP 78 and BCP 79. 1693 Copies of IPR disclosures made to the IETF Secretariat and 1694 any assurances of licenses to be made available, or the 1695 result of an attempt made to obtain a general license or 1696 permission for the use of such proprietary rights by 1697 implementers or users of this specification can be obtained 1698 from the IETF on-line IPR repository at 1699 http://www.ietf.org/ipr. 1701 The IETF invites any interested party to bring to its 1702 attention any copyrights, patents or patent applications, or 1703 other proprietary rights that may cover technology that may 1704 be required to implement this standard. Please address the 1705 information to the IETF at ietf-ipr@ietf.org.