idnits 2.17.1 draft-ietf-ips-iscsi-impl-guide-09.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1837. 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 (December 2007) is 5976 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. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Mallikarjun Chadalapaka 2 draft-ietf-ips-iscsi-impl-guide-09.txt Hewlett-Packard Co. 3 Editor 5 Updates: RFC 3720 6 Intended status: Proposed Standard 8 Expires December 2007 10 iSCSI Corrections and Clarifications 12 Status of this Memo 13 By submitting this Internet-Draft, each author represents 14 that any applicable patent or other IPR claims of which he or 15 she is aware have been or will be disclosed, and any of which 16 he or she becomes aware will be disclosed, in accordance with 17 Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet 20 Engineering Task Force (IETF), its areas, and its working 21 groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by 26 other documents at any time. It is inappropriate to use 27 Internet-Drafts as reference material or to cite them other 28 than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed 34 at http://www.ietf.org/shadow.html. 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 37 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 38 "OPTIONAL" in this document are to be interpreted as 39 described in [RFC2119]. 41 Abstract 42 iSCSI is a SCSI transport protocol and maps the SCSI 43 architecture and command sets onto TCP/IP. RFC 3720 defines 44 the iSCSI protocol. This document compiles the 45 clarifications to the original protocol definition in RFC 46 3720 to serve as a companion document for the iSCSI 47 implementers. This document updates RFC 3720 and the text in 48 this document supersedes the text in RFC 3720 when the two 49 differ. 51 Table of Contents 53 1 Definitions, Acronyms and Document Summary............. 5 54 1.1 Definitions............................................ 5 55 1.2 Acronyms............................................... 5 56 1.3 Clarifications, Changes and New Semantics.............. 6 57 2 Introduction........................................... 9 58 3 iSCSI semantics for SCSI tasks........................ 10 59 3.1 Residual handling..................................... 10 60 3.1.1 Overview ............................................ 10 61 3.1.2 SCSI REPORT LUNS and Residual Overflow .............. 11 62 3.2 R2T Ordering.......................................... 12 63 3.3 Model Assumptions for Response Ordering............... 13 64 3.3.1 Model Description ................................... 13 65 3.3.2 iSCSI Semantics with the Interface Model ............ 14 66 3.3.3 Current List of Fenced Response Use Cases ........... 14 67 4 Task Management....................................... 16 68 4.1 Requests Affecting Multiple Tasks..................... 16 69 4.1.1 Scope of affected tasks ............................. 16 70 4.1.2 Clarified multi-task abort semantics ................ 16 71 4.1.3 Updated multi-task abort semantics .................. 18 72 4.1.4 Affected tasks shared across RFC3720 & FastAbort 73 sessions ................................................... 20 74 4.1.5 Implementation considerations ....................... 21 75 4.1.6 Rationale behind the new semantics .................. 22 76 5 Discovery semantics................................... 24 77 5.1 Error Recovery for Discovery Sessions................. 24 78 5.2 Reinstatement Semantics of Discovery Sessions......... 24 79 5.2.1 Unnamed Discovery Sessions .......................... 25 80 5.2.2 Named Discovery Sessions ............................ 25 81 5.3 Target PDUs during Discovery.......................... 26 82 6 Negotiation and Others................................ 27 83 6.1 TPGT Values........................................... 27 84 6.2 SessionType Negotiation............................... 27 85 6.3 Understanding NotUnderstood........................... 27 86 6.4 Outstanding Negotiation Exchanges..................... 28 87 7 iSCSI Error Handling and Recovery..................... 29 88 7.1 ITT................................................... 29 89 7.2 Format Errors......................................... 29 90 7.3 Digest Errors......................................... 29 91 7.4 Message Error Checking................................ 30 92 8 iSCSI PDUs............................................ 31 93 8.1 Asynchronous Message.................................. 31 94 8.2 Reject................................................ 31 95 9 Login/Text Operational Text Keys...................... 33 96 9.1 TaskReporting......................................... 33 97 10 Security Considerations............................... 35 98 11 IANA Considerations................................... 36 99 11.1 iSCSI-related IANA registries ....................... 36 100 11.2 iSCSI Opcodes ....................................... 36 101 11.3 iSCSI Login/Text Keys ............................... 39 102 11.4 iSCSI Asynchronous Events ........................... 41 103 11.5 iSCSI Task Management Function Codes ................ 42 104 11.6 iSCSI Login Response Status Codes ................... 43 105 11.7 iSCSI Reject Reason Codes ........................... 45 106 11.8 iSER Opcodes ........................................ 47 107 12 References and Bibliography........................... 49 108 12.1 Normative References ................................ 49 109 12.2 Informative References .............................. 49 110 13 Editor's Address...................................... 50 111 14 Acknowledgements...................................... 51 112 15 Full Copyright Statement.............................. 52 113 16 Intellectual Property Statement....................... 53 115 1 Definitions, Acronyms and Document Summary 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 1.3 Clarifications, Changes and New Semantics 202 This document specifies certain changes to [RFC3720] semantics 203 as well as defines new iSCSI semantics. In addition, this 204 document also clarifies the [RFC3720] semantics. This section 205 summarizes the contents of the document, categorizing each 206 section into one or more of a Clarification, a Change or a New 207 Semantic. 209 Section 3.1.1: Clarification on iSCSI residuals computation 210 general principles 212 Section 3.1.2: Clarification on iSCSI residuals computation 213 with an example 215 Section 3.2: Clarification on R2T ordering requirements 217 Section 3.3: New Semantics for Response Ordering in multi- 218 connection iSCSI sessions 220 Section 4.1.2: Clarifications, Changes and New Semantics on 221 multi-task abort semantics that all implementations must 222 comply with 224 Section 4.1.3: Changes and New Semantics (FastAbort 225 semantics) on multi-task abort semantics that 226 implementations should use for faster error recovery 228 Section 4.1.3.1: Changes in iSCSI Clearing effects semantics 229 resulting out of new FastAbort semantics 231 Section 4.1.4: New Semantics on third-party session 232 interactions with the new FastAbort semantics 234 Section 4.1.5: Clarification on implementation considerations 235 related to outstanding data transfers in order to realize 236 right iSCSI protocol behavior 238 Section 4.1.6: Clarification on the intent behind FastAbort 239 semantics (not clarifications to [RFC3720] semantics) 241 Section 5.1: Clarification on error recovery semantics as 242 applicable to Discovery sessions 244 Section 5.2.1: Clarification and New Semantics on applying 245 ISID RULE ([RFC3720]) to Unnamed Discovery Sessions 247 Section 5.2.2: Clarification on applying ISID RULE to Named 248 Discovery Sessions 250 Section 5.3: Clarification on allowed PDU types and target 251 Logout notification behavior on a Discovery session 253 Section 6.1: Clarification on the legality of TPGT value of 254 zero 256 Section 6.2: Clarification on the negotiating order of 257 SessionType with respect to other keys 259 Section 6.3: Clarification on NotUnderstood negotiation 260 response on declarative keys and the implied semantics 261 Section 6.4: Clarification on the number of legal outstanding 262 negotiation PDUs (Text or Login-related) 264 Section 7.1: Clarification on usage of ITT value of 265 0xffffffff 267 Section 7.2: Clarification on what constitute format errors 268 for the purpose of error recovery defined in [RFC3720] 270 Section 7.3: Change in error recovery semantics for the case 271 of discarding unsolicited PDUs 273 Section 7.4: Clarification on the intended level of error 274 checking on inbound PDUs 276 Section 8.1: New Semantics for a new AsyncEvent code 278 Section 8.2: Change of legal status for Reject reason code 279 0x0b, it is now deprecated 281 Section 9.1: New Semantics for a new text key TaskReporting 283 2 Introduction 285 Several iSCSI implementations had been built after [RFC3720] was 286 published and the iSCSI community is now richer by the resulting 287 implementation expertise. The goal of this document is to 288 leverage this expertise both to offer clarifications to the 289 [RFC3720] semantics and to address defects in [RFC3720] as 290 appropriate. This document intends to offer critical guidance 291 to implementers with regard to non-obvious iSCSI implementation 292 aspects so as to improve interoperability and accelerate iSCSI 293 adoption. This document, however, does not purport to be an 294 all-encompassing iSCSI how-to guide for implementers, nor a 295 complete revision of [RFC3720]. This document instead is 296 intended as a companion document to [RFC3720] for the iSCSI 297 implementers. 299 iSCSI implementers are required to reference [RFC3722] and 300 [RFC3723] in addition to [RFC3720] for mandatory requirements. 301 In addition, [RFC3721] also contains useful information for 302 iSCSI implementers. The text in this document, however, updates 303 and supersedes the text in [RFC3720] whenever there is such a 304 question. 306 3 iSCSI semantics for SCSI tasks 308 3.1 Residual handling 310 Section 10.4.1 of [RFC3720] defines the notion of "residuals" 311 and specifies how the residual information should be encoded 312 into the SCSI Response PDU in Counts and Flags fields. Section 313 3.1.1 clarifies the intent of [RFC3720] and explains the general 314 principles. Section 3.1.2 describes the residual handling in 315 the REPORT LUNS scenario. 317 3.1.1 Overview 319 SCSI-Presented Data Transfer Length (SPDTL) is the term this 320 document uses (see section 1.1 for definition) to represent the 321 aggregate data length that the target SCSI layer attempts to 322 transfer using the local iSCSI layer for a task. Expected Data 323 Transfer Length (EDTL) is the iSCSI term that represents the 324 length of data that the iSCSI layer expects to transfer for a 325 task. EDTL is specified in the SCSI Command PDU. 327 When SPDTL = EDTL for a task, the target iSCSI layer completes 328 the task with no residuals. Whenever SPDTL differs from EDTL 329 for a task, that task is said to have a residual. 331 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in 332 the SCSI Response PDU as specified in [RFC3720]. Residual Count 333 MUST be set to the numerical value of (SPDTL - EDTL). 335 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 336 the SCSI Response PDU as specified in [RFC3720]. Residual Count 337 MUST be set to the numerical value of (EDTL - SPDTL). 339 Note that the Overflow and Underflow scenarios are independent 340 of Data-in and Data-out. Either scenario is logically possible 341 in either direction of data transfer. 343 3.1.2 SCSI REPORT LUNS and Residual Overflow 345 This section discusses the residual overflow issues citing the 346 example of SCSI REPORT LUNS command. Note however that there 347 are several SCSI commands (e.g. INQUIRY) with ALLOCATION LENGTH 348 fields following the same underlying rules. The semantics in 349 the rest of the section apply to all such SCSI commands. 351 The specification of the SCSI REPORT LUNS command requires that 352 the SCSI target limit the amount of data transferred to a 353 maximum size (ALLOCATION LENGTH) provided by the initiator in 354 the REPORT LUNS CDB. If the Expected Data Transfer Length 355 (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT 356 LUNS command is set to at least as large as that ALLOCATION 357 LENGTH, the SCSI layer truncation prevents an iSCSI Residual 358 Overflow from occurring. A SCSI initiator can detect that such 359 truncation has occurred via other information at the SCSI layer. 360 The rest of the section elaborates this required behavior. 362 iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI 363 Response and the last SCSI Data-In PDUs to indicate that that an 364 iSCSI target was unable to transfer all of the SCSI data for a 365 command to the initiator because the amount of data to be 366 transferred exceeded the EDTL in the corresponding SCSI Command 367 PDU (see Section 10.4.1 of [RFC3720]). 369 The SCSI REPORT LUNS command requests a target SCSI layer to 370 return a logical unit inventory (LUN list) to the initiator SCSI 371 layer (see section 6.21 of SPC-3 [SPC3]). The size of this LUN 372 list may not be known to the initiator SCSI layer when it issues 373 the REPORT LUNS command; to avoid transfer of more LUN list data 374 than the initiator is prepared for, the REPORT LUNS CDB contains 375 an ALLOCATION LENGTH field to specify the maximum amount of data 376 to be transferred to the initiator for this command. If the 377 initiator SCSI layer has under-estimated the number of logical 378 units at the target, it is possible that the complete logical 379 unit inventory does not fit in the specified ALLOCATION LENGTH. 380 In this situation, section 4.3.3.6 in [SPC3] requires that the 381 target SCSI layer "shall terminate transfers to the Data-In 382 Buffer" when the number of bytes specified by the ALLOCATION 383 LENGTH field have been transferred. 385 Therefore, in response to a REPORT LUNS command, the SCSI layer 386 at the target presents at most ALLOCATION LENGTH bytes of data 387 (logical unit inventory) to iSCSI for transfer to the initiator. 388 For a REPORT LUNS command, if the iSCSI EDTL is at least as 389 large as the ALLOCATION LENGTH, the SCSI truncation ensures that 390 the EDTL will accommodate all of the data to be transferred. If 391 all of the logical unit inventory data presented to the iSCSI 392 layer - i.e. the data remaining after any SCSI truncation - is 393 transferred to the initiator by the iSCSI layer, an iSCSI 394 Residual Overflow has not occurred and the iSCSI (O) bit MUST 395 NOT be set in the SCSI Response or final SCSI Data-Out PDU. 396 This is not a new requirement but is already required by the 397 combination of [RFC3720] with the specification of the REPORT 398 LUNS command in [SPC3]. If the iSCSI EDTL is larger than the 399 ALLOCATION LENGTH however in this scenario, note that the iSCSI 400 Underflow MUST be signaled in the SCSI Response PDU. An iSCSI 401 Underflow MUST also be signaled when the iSCSI EDTL is equal to 402 ALLOCATION LENGTH but the logical unit inventory data presented 403 to the iSCSI layer is smaller than ALLOCATION LENGTH. 405 The LUN LIST LENGTH field in the logical unit inventory (first 406 field in the inventory) is not affected by truncation of the 407 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 408 initiator to determine that the received inventory is incomplete 409 by noticing that the LUN LIST LENGTH in the inventory is larger 410 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. 411 A common initiator behavior in this situation is to re-issue the 412 REPORT LUNS command with a larger ALLOCATION LENGTH. 414 3.2 R2T Ordering 416 Section 10.8 in [RFC3720] says the following: 418 The target may send several R2T PDUs. It, therefore, can have 419 a number of pending data transfers. The number of outstanding 420 R2T PDUs is limited by the value of the negotiated key 421 MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST 422 be fulfilled by the initiator in the order in which they were 423 received. 425 The quoted [RFC3720] text was unclear on the scope of 426 applicability - either per task, or across all tasks on a 427 connection - and may be interpreted as either. This section is 428 intended to clarify that the scope of applicability of the 429 quoted text is a task. No R2T ordering relationship - either in 430 generation at the target or in fulfilling at the initiator - 431 across tasks is implied. I.e., outstanding R2Ts within a task 432 MUST be fulfilled by the initiator in the order in which they 433 were received on a connection. 435 3.3 Model Assumptions for Response Ordering 437 Whenever an iSCSI session is composed of multiple connections, 438 the Response PDUs (task responses or TMF responses) originating 439 in the target SCSI layer are distributed onto the multiple 440 connections by the target iSCSI layer according to iSCSI 441 connection allegiance rules. This process generally may not 442 preserve the ordering of the responses by the time they are 443 delivered to the initiator SCSI layer. Since ordering is not 444 expected across SCSI responses anyway, this approach works fine 445 in the general case. However to address the special cases where 446 some ordering is desired by the SCSI layer, the following 447 "Response Fence" semantics are defined with respect to handling 448 SCSI response messages as they are handed off from the SCSI 449 protocol layer to the iSCSI layer. 451 3.3.1 Model Description 453 Target SCSI protocol layer hands off the SCSI response messages 454 to the target iSCSI layer by invoking the "Send Command 455 Complete" protocol data service ([SAM2], clause 5.4.2) and "Task 456 Management Function Executed" ([SAM2], clause 6.9) service. On 457 receiving the SCSI response message, iSCSI layer exhibits the 458 Response Fence behavior for certain SCSI response messages 459 (section 3.3.3 describes the specific instances where the 460 semantics must be realized). Whenever the Response Fence 461 behavior is required for a SCSI response message, the target 462 iSCSI layer MUST ensure that the following conditions are met in 463 delivering the response message to the initiator iSCSI layer: 465 (1) Response with Response Fence MUST chronologically be 466 delivered after all the "preceding" responses on the 467 I_T_L nexus, if the preceding responses are delivered at 468 all, to the initiator iSCSI layer. 470 (2) Response with Response Fence MUST chronologically be 471 delivered prior to all the "following" responses on the 472 I_T_L nexus. 474 The "preceding" and "following" notions refer to the order of 475 hand-off of a response message from the target SCSI protocol 476 layer to the target iSCSI layer. 478 3.3.2 iSCSI Semantics with the Interface Model 480 Whenever the TaskReporting key (section 9.1) is negotiated to 481 ResponseFence or FastAbort for an iSCSI session and the Response 482 Fence behavior is required for a SCSI response message, the 483 target iSCSI layer MUST perform the actions described in this 484 section for that session.: 486 a) If it is a single-connection session, no special processing 487 is required. Standard SCSI Response PDU build and dispatch 488 process happens. 490 b) If it is a multi-connection session, target iSCSI layer 491 takes note of last-sent and unacknowledged StatSN on each 492 of the connections in the iSCSI session, and waits for 493 acknowledgement (Nop-In PDUs MAY be used to solicit 494 acknowledgements as needed in order to accelerate this 495 process) of each such StatSN to clear the fence. The SCSI 496 response requiring Response Fence behavior MUST NOT be sent 497 to the initiator before acknowledgements are received for 498 each of the unacknowledged StatSNs.. 500 c) Target iSCSI layer must wait for an acknowledgement of the 501 SCSI Response PDU that carried the SCSI response requiring 502 the Response Fence behavior. The fence MUST be considered 503 cleared only after receiving the acknowledgement. 505 d) All further status processing for the LU is resumed only 506 after clearing the fence. If any new responses for the 507 I_T_L nexus are received from the SCSI layer before the 508 fence is cleared, those Response PDUs MUST be held and 509 queued at the iSCSI layer until the fence is cleared. 511 3.3.3 Current List of Fenced Response Use Cases 513 This section lists the fenced response use cases that iSCSI 514 implementations MUST comply with. However, this is not an 515 exhaustive enumeration. It is expected that as SCSI protocol 516 specifications evolve, the specifications will specify when 517 response fencing is required on a case-by-case basis. 519 Whenever the TaskReporting key (section 9.1) is negotiated to 520 ResponseFence or FastAbort for an iSCSI session, target iSCSI 521 layer MUST assume that Response Fence is required for the 522 following SCSI completion messages: 524 1. The first completion message carrying the UA after the 525 multi-task abort on issuing and third-party sessions. See 526 section 4.1.1 for related TMF discussion. 528 2. The TMF Response carrying the multi-task TMF Response on 529 the issuing session. 531 3. The completion message indicating ACA establishment on the 532 issuing session. 534 4. The first completion message carrying the ACA ACTIVE status 535 after ACA establishment on issuing and third-party 536 sessions. 538 5. The TMF Response carrying the Clear ACA response on the 539 issuing session. 541 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 542 command 544 Note: Due to the absence of ACA-related fencing requirements in 545 [RFC3720], initiator implementations SHOULD NOT use ACA on 546 multi-connection iSCSI sessions to targets complying only with 547 [RFC3720]. Initiators which want to employ ACA on multi- 548 connection iSCSI sessions SHOULD first assess response fencing 549 behavior via negotiating for ResponseFence or FastAbort values 550 for the TaskReporting (section 9.1) key. 552 4 Task Management 554 4.1 Requests Affecting Multiple Tasks 556 This section clarifies and updates the original text in section 557 10.6.2 of [RFC3720]. The clarified semantics (section 4.1.2) 558 are a superset of the protocol behavior required in the original 559 text and all iSCSI implementations MUST support the new 560 behavior. The updated semantics (section 4.1.3) on the other 561 hand are mandatory only when the new key TaskReporting (section 562 9.1) is negotiated to "FastAbort". 564 4.1.1 Scope of affected tasks 566 This section defines the notion of "affected tasks" in multi- 567 task abort scenarios. Scope definitions in this section apply 568 to both the clarified protocol behavior (section 4.1.2) and the 569 updated protocol behavior (section 4.1.3). 571 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 572 identified by the LUN field in the ABORT TASK SET TMF 573 Request PDU. 575 CLEAR TASK SET: All outstanding tasks in the task set for 576 the LU identified by the LUN field in the CLEAR TASK SET 577 TMF Request PDU. See [SPC3] for the definition of a "task 578 set". 580 LOGICAL UNIT RESET: All outstanding tasks from all 581 initiators for the LU identified by the LUN field in the 582 LOGICAL UNIT RESET Request PDU. 584 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks 585 from all initiators across all LUs to which the TMF-issuing 586 session has access to on the SCSI target device hosting the 587 iSCSI session. 589 Usage: an "ABORT TASK SET TMF Request PDU" in the preceding text 590 is an iSCSI TMF Request PDU with the "Function" field set to 591 "ABORT TASK SET" as defined in [RFC3720]. Similar usage is 592 employed for other scope descriptions. 594 4.1.2 Clarified multi-task abort semantics 596 All iSCSI implementations MUST support the protocol behavior 597 defined in this section as the default behavior. The execution 598 of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET 599 WARM RESET, and TARGET COLD RESET TMF Requests consists of the 600 following sequence of actions in the specified order on the 601 specified party. 603 The initiator iSCSI layer: 605 a. MUST continue to respond to each TTT received for the 606 affected tasks. 608 b. SHOULD process any responses received for affected tasks in 609 the normal fashion. This is acceptable because the 610 responses are guaranteed to have been sent prior to the TMF 611 response. 613 c. SHOULD receive the TMF Response concluding all the tasks in 614 the set of affected tasks unless the initiator has done 615 something (e.g.,LU reset, connection drop) that may prevent 616 the TMF Response from being sent or received. The 617 initiator MUST thus conclude all affected tasks as part of 618 this step in either case, and MUST discard any TMF Response 619 received after the affected tasks are concluded. 621 The target iSCSI layer: 623 a. MUST wait for responses on currently valid target transfer 624 tags of the affected tasks from the issuing initiator. MAY 625 wait for responses on currently valid target transfer tags 626 of the affected tasks from third-party initiators. 628 b. MUST wait (concurrent with the wait in Step.a) for all 629 commands of the affected tasks to be received based on the 630 CmdSN ordering. SHOULD NOT wait for new commands on 631 third-party affected sessions - only the instantiated tasks 632 have to be considered for the purpose of determining the 633 affected tasks. In the case of target-scoped requests 634 (i.e. TARGET WARM RESET and TARGET COLD RESET), all the 635 commands that are not yet received on the issuing session 636 in the command stream however can be considered to have 637 been received with no command waiting period - i.e. the 638 entire CmdSN space up to the CmdSN of the task management 639 function can be "plugged". 641 c. MUST propagate the TMF request to and receive the response 642 from the target SCSI layer. 644 d. MUST provide Response Fence behavior for the TMF Response 645 on issuing session as specified in 3.3.2. 647 e. MUST provide the Response Fence behavior on the first post- 648 TMF Response on third-party sessions as specified in 3.3.2. 649 If some tasks originate from non-iSCSI I_T_L nexuses then 650 the means by which the target ensures that all affected 651 tasks have returned their status to the initiator are 652 defined by the specific non-iSCSI transport protocol(s). 654 Technically, the TMF servicing is complete in Step.d. Data 655 transfers corresponding to terminated tasks may however still be 656 in progress on third-party iSCSI sessions even at the end of 657 Step.e. TMF Response MUST NOT be sent by the target iSCSI layer 658 before the end of Step.d, and MAY be sent at the end of Step.d 659 despite these outstanding data transfers until after Step.e. 661 4.1.3 Updated multi-task abort semantics 663 Protocol behavior defined in this section MUST be implemented by 664 all iSCSI implementations complying with this document. 665 Protocol behavior defined in this section MUST be exhibited by 666 iSCSI implementations on an iSCSI session when they negotiate 667 the TaskReporting (section 9.1) key to "FastAbort" on that 668 session. The execution of ABORT TASK SET, CLEAR TASK SET, 669 LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF 670 Requests consists of the following sequence of actions in the 671 specified order on the specified party. 673 The initiator iSCSI layer: 675 a. MUST NOT send any more Data-Out PDUs for affected tasks on 676 the issuing connection of the issuing iSCSI session once 677 the TMF is sent to the target. 679 b. SHOULD process any responses received for affected tasks in 680 the normal fashion. This is acceptable because the 681 responses are guaranteed to have been sent prior to the TMF 682 response. 684 c. MUST respond to each Async Message PDU with AsyncEvent=5 as 685 defined in section 8.1. 687 d. MUST treat the TMF response as terminating all affected 688 tasks for which responses have not been received, and MUST 689 discard any responses for affected tasks received after the 690 TMF response is passed to the SCSI layer (although the 691 semantics defined in this section ensure that such an out 692 of order scenario will never happen with a compliant target 693 implementation). 695 The target iSCSI layer: 697 a. MUST wait for all commands of the affected tasks to be 698 received based on the CmdSN ordering on the issuing 699 session. SHOULD NOT wait for new commands on third-party 700 affected sessions - only the instantiated tasks have to be 701 considered for the purpose of determining the affected 702 tasks. In the case of target-scoped requests (i.e. TARGET 703 WARM RESET and TARGET COLD RESET), all the commands that 704 are not yet received on the issuing session in the command 705 stream can be considered to have been received with no 706 command waiting period - i.e. the entire CmdSN space up to 707 the CmdSN of the task management function can be "plugged". 709 b. MUST propagate the TMF request to and receive the response 710 from the target SCSI layer. 712 c. MUST leave all active "affected TTTs" (i.e. active TTTs 713 associated with affected tasks) valid. 715 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 716 (section 8.1) on: 717 i) each connection of each third-party session to which at 718 least one affected task is allegiant if 719 TaskReporting=FastAbort is operational on that third- 720 party session, and 721 ii)each connection except the issuing connection of the 722 issuing session that has at least one allegiant affected 723 task. 725 If there are multiple affected LUs (say due to a target 726 reset), then one Async Message PDU MUST be sent for each 727 such LU on each connection that has at least one allegiant 728 affected task. The LUN field in the Asynchronous Message 729 PDU MUST be set to match the LUN for each such LU. 731 e. MUST address the Response Fence flag on the TMF Response on 732 issuing session as defined in 3.3.2. 734 f. MUST address the Response Fence flag on the first post-TMF 735 Response on third-party sessions as defined in 3.3.2. If 736 some tasks originate from non-iSCSI I_T_L nexuses then the 737 means by which the target ensures that all affected tasks 738 have returned their status to the initiator are defined by 739 the specific non-iSCSI transport protocol(s). 741 g. MUST free up the affected TTTs (and STags, if applicable) 742 and the corresponding buffers, if any, once it receives 743 each associated Nop-Out acknowledgement that the initiator 744 generated in response to each Async Message. 746 Technically, the TMF servicing is complete in Step.e. Data 747 transfers corresponding to terminated tasks may however still be 748 in progress even at the end of Step.f. TMF Response MUST NOT be 749 sent by the target iSCSI layer before the end of Step.e, and MAY 750 be sent at the end of Step.e despite these outstanding Data 751 transfers until Step.g. Step.g specifies an event to free up 752 any such resources that may have been reserved to support 753 outstanding data transfers. 755 4.1.3.1 Clearing effects update 757 Appendix F.1 of [RFC3720] specifies the clearing effects of 758 target and LU resets on "Incomplete TTTs" as "Y". This meant 759 that a target warm reset or a target cold reset or an LU reset 760 would clear the active TTTs upon completion. The 761 TaskReporting=FastAbort (section 9.1) semantics defined by this 762 section however do not guarantee that the active TTTs are 763 cleared by the end of the reset operations. In fact, the new 764 semantics are designed to allow clearing the TTTs in a "lazy" 765 fashion after the TMF Response is delivered. Thus, when 766 TaskReporting=FastAbort is operational on a session, the 767 clearing effects of reset operations on "Incomplete TTTs" is 768 "N". 770 4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions 772 If an iSCSI target implementation is capable of supporting 773 TaskReporting=FastAbort functionality (section 9.1), it may end 774 up in a situation where some sessions have TaskReporting=RFC3720 775 operational (RFC3720 sessions) while some other sessions have 776 TaskReporting=FastAbort operational (FastAbort sessions) even 777 while accessing a shared set of affected tasks (section 4.1.1). 779 If the issuing session is a RFC3720 session, iSCSI target 780 implementation is FastAbort-capable and third-party affected 781 session is a FastAbort session, the following behavior SHOULD be 782 exhibited by the iSCSI target layer: 784 a. Between steps c and d of target behavior in section 4.1.2, 785 send an Asynchronous Message PDU with AsyncEvent=5 (section 786 8.1) on each connection of each third-party session to 787 which at least one affected task is allegiant. If there 788 are multiple affected LUs, then send one Async Message PDU 789 for each such LU on each connection that has at least one 790 allegiant affected task. When sent, the LUN field in the 791 Asynchronous Message PDU MUST be set to match the LUN for 792 each such LU. 793 b. After step e of target behavior in section 4.1.2, free up 794 the affected TTTs (and STags, if applicable) and the 795 corresponding buffers, if any, once each associated Nop-Out 796 acknowledgement is received that the third-party initiator 797 generated in response to each Async Message sent in step a. 799 If the issuing session is a FastAbort session, iSCSI target 800 implementation is FastAbort-capable and third-party affected 801 session is a RFC3720 session, the following behavior MUST be 802 exhibited by the iSCSI target layer: Asynchronous Message PDUs 803 MUST NOT be sent on the third-party session to prompt the 804 FastAbort behavior. 806 If the third-party affected session is a FastAbort session and 807 issuing session is a FastAbort session, initiator in the third- 808 party role MUST respond to each Async Message PDU with 809 AsyncEvent=5 as defined in section 8.1. Note that an initiator 810 MAY thus receive these Async Messages on a third-party affected 811 session even if the session is a single-connection session. 813 4.1.5 Implementation considerations 815 Both in clarified semantics (section 4.1.2) and updated 816 semantics (section 4.1.3), there may be outstanding data 817 transfers even after the TMF completion is reported on the 818 issuing session. In the case of iSCSI/iSER [iSER], these would 819 be tagged data transfers for STags not owned by any active 820 tasks. Whether or not real buffers support these data transfers 821 is implementation-dependent. However, the data transfers 822 logically MUST be silently discarded by the target iSCSI layer 823 in all cases. A target MAY, on an implementation-defined 824 internal timeout, also choose to drop the connections on which 825 it did not receive the expected Data-out sequences (section 826 4.1.2) or Nop-Out acknowledgements (section 4.1.3) so as to 827 reclaim the associated buffer, STag and TTT resources as 828 appropriate. 830 4.1.6 Rationale behind the new semantics 832 There are fundamentally three basic objectives behind the 833 semantics specified in section 4.1.2 and section 4.1.3. 835 1. Maintaining an ordered command flow I_T nexus abstraction 836 to the target SCSI layer even with multi-connection 837 sessions. 839 o Target iSCSI processing of a TMF request must maintain 840 the single flow illusion. Target behavior in Step.b 841 of section 4.1.2 and Step.a of section 4.1.3 842 correspond to this objective. 844 2. Maintaining a single ordered response flow I_T nexus 845 abstraction to the initiator SCSI layer even with multi- 846 connection sessions when one response (i.e. TMF response) 847 could imply the status of other unfinished tasks from the 848 initiator's perspective. 850 o Target must ensure that the initiator does not see 851 "old" task responses (that were placed on the wire 852 chronologically earlier than the TMF Response) after 853 seeing the TMF response. Target behavior in Step.d of 854 section 4.1.2 and Step.e of section 4.1.3 correspond 855 to this objective. 857 o Whenever the result of a TMF action is visible across 858 multiple I_T_L nexuses, [SAM2] requires the SCSI 859 device server to trigger a UA on each of the other 860 I_T_L nexuses. Once an initiator is notified of such 861 an UA, the application client on the receiving 862 initiator is required to clear its task state (clause 863 5.5 in [SAM2]) for the affected tasks. It would thus 864 be inappropriate to deliver a SCSI Response for a task 865 after the task state is cleared on the initiator, i.e. 866 after the UA is notified. The UA notification 867 contained in the first SCSI Response PDU on each 868 affected Third-party I_T_L nexus after the TMF action 869 thus MUST NOT pass the affected task responses on any 870 of the iSCSI sessions accessing the LU. Target 871 behavior in Step.e of section 4.1.2 and Step.f of 872 section 4.1.3 correspond to this objective. 874 3. Draining all active TTTs corresponding to affected tasks 875 in a deterministic fashion. 877 o Data-out PDUs with stale TTTs arriving after the tasks 878 are terminated can create a buffer management problem 879 even for traditional iSCSI implementations, and is 880 fatal for the connection for iSCSI/iSER 881 implementations. Either the termination of affected 882 tasks should be postponed until the TTTs are retired 883 (as in Step.a of section 4.1.2), or the TTTs and the 884 buffers should stay allocated beyond task termination 885 to be deterministically freed up later (as in Step.c 886 and Step.g of section 4.1.3). 888 The only other notable optimization is the plugging. If all 889 tasks on an I_T nexus will be aborted anyway (as with a target 890 reset), there is no need to wait to receive all commands to plug 891 the CmdSN holes. Target iSCSI layer can simply plug all missing 892 CmdSN slots and move on with TMF processing. The first 893 objective (maintaining a single ordered command flow) is still 894 met with this optimization because target SCSI layer only sees 895 ordered commands. 897 5 Discovery semantics 899 5.1 Error Recovery for Discovery Sessions 901 The negotiation of the key ErrorRecoveryLevel is not required 902 for Discovery sessions - i.e. for sessions that negotiated 903 "SessionType=Discovery" - because the default value of 0 is 904 necessary and sufficient for Discovery sessions. It is however 905 possible that some legacy iSCSI implementations might attempt to 906 negotiate the ErrorRecoveryLevel key on Discovery sessions. 907 When such a negotiation attempt is made by the remote side, a 908 compliant iSCSI implementation MUST propose a value of 0 (zero) 909 in response. The operational ErrorRecoveryLevel for Discovery 910 sessions thus MUST be 0. This naturally follows from the 911 functionality constraints [RFC3720] imposes on Discovery 912 sessions. 914 5.2 Reinstatement Semantics of Discovery Sessions 916 Discovery sessions are intended to be relatively short-lived. 917 Initiators are not expected to establish multiple Discovery 918 sessions to the same iSCSI Network Portal (see [RFC3720]). An 919 initiator may use the same iSCSI Initiator Name and ISID when 920 establishing different unique sessions with different targets 921 and/or different portal groups. This behavior is discussed in 922 Section 9.1.1 of [RFC3720] and is, in fact, encouraged as 923 conservative reuse of ISIDs. ISID RULE in [RFC3720] states that 924 there must not be more than one session with a matching 4-tuple: 925 . While 926 the spirit of the ISID RULE applies to Discovery sessions the 927 same as it does for Normal sessions, note that some Discovery 928 sessions differ from the Normal sessions in two important 929 aspects: 931 Because [RFC3720] allows a Discovery session to be 932 established without specifying a TargetName key in the 933 Login Request PDU (let us call such a session an "Unnamed" 934 Discovery session), there is no Target Node context to 935 enforce the ISID RULE. 937 Portal Groups are defined only in the context of a Target 938 Node. When the TargetName key is NULL-valued (i.e. not 939 specified), the TargetPortalGroupTag thus cannot be 940 ascertained to enforce the ISID RULE. 942 The following sections describe the two scenarios - Named 943 Discovery sessions and Unnamed Discovery sessions - separately. 945 5.2.1 Unnamed Discovery Sessions 947 For Unnamed Discovery sessions, neither the TargetName nor the 948 TargetPortalGroupTag is available to the targets in order to 949 enforce the ISID RULE. So the following rule applies. 951 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 952 following 4-tuple for Unnamed Discovery sessions: 953 . The following 954 semantics are implied by this uniqueness requirement. 956 Targets SHOULD allow concurrent establishment of one Discovery 957 session with each of its Network Portals by the same initiator 958 port with a given iSCSI Node Name and an ISID. Each of the 959 concurrent Discovery sessions, if established by the same 960 initiator port to other Network Portals, MUST be treated as 961 independent sessions - i.e. one session MUST NOT reinstate the 962 other. 964 A new Unnamed Discovery session that has a matching 965 to an existing 966 discovery session MUST reinstate the existing Unnamed Discovery 967 session. Note thus that only an Unnamed Discovery session may 968 reinstate an Unnamed Discovery session. 970 5.2.2 Named Discovery Sessions 972 For a Named Discovery session, the TargetName key is specified 973 by the initiator and thus the target can unambiguously ascertain 974 the TargetPortalGroupTag as well. Since all the four elements 975 of the 4-tuple are known, the ISID RULE MUST be enforced by 976 targets with no changes from [RFC3720] semantics. A new session 977 with a matching thus will reinstate an existing session. 979 Note in this case that any new iSCSI session (Discovery or 980 Normal) with the matching 4-tuple may reinstate an existing 981 Named Discovery iSCSI session. 983 5.3 Target PDUs during Discovery 985 Targets SHOULD NOT send any responses other than a Text Response 986 and Logout Response on a Discovery session, once in full feature 987 phase. 989 Implementation Note: A target may simply drop the connection in 990 a Discovery session when it would have requested a Logout via an 991 Async Message on Normal sessions. 993 6 Negotiation and Others 995 6.1 TPGT Values 997 [SAM2] and [SAM3] specifications incorrectly note in their 998 informative text that TPGT value should be non-zero, although 999 [RFC3720] allows the value of zero for TPGT. This section is to 1000 clarify that zero value is expressly allowed as a legal value 1001 for TPGT. This discrepancy currently stands corrected in 1002 [SAM4]. 1004 6.2 SessionType Negotiation 1006 During the Login phase, the SessionType key is offered by the 1007 initiator to choose the type of session it wants to create with 1008 the target. The target may accept or reject the offer. 1009 Depending on the type of the session, a target may decide on 1010 resources to allocate and the security to enforce etc. for the 1011 session. If the SessionType key is thus going to be offered as 1012 "Discovery", it SHOULD be offered in the initial Login request 1013 by the initiator. 1015 6.3 Understanding NotUnderstood 1017 [RFC3720] defines NotUnderstood as a valid answer during a 1018 negotiation text key exchange between two iSCSI nodes. 1019 NotUnderstood has the reserved meaning that the sending side did 1020 not understand the proposed key semantics. This section seeks 1021 to clarify that NotUnderstood is a valid answer for both 1022 declarative and negotiated keys. The general iSCSI philosophy 1023 is that comprehension precedes processing for any iSCSI key. A 1024 proposer of an iSCSI key, negotiated or declarative, in a text 1025 key exchange MUST thus be able to properly handle a 1026 NotUnderstood response. 1028 The proper way to handle a NotUnderstood response depends on 1029 where the key is specified and whether the key is declarative 1030 vs. negotiated. All keys defined in [RFC3720] MUST be supported 1031 by all compliant implementations; a NotUnderstood answer on any 1032 of the [RFC3720] keys therefore MUST be considered a protocol 1033 error and handled accordingly. For all other later keys, a 1034 NotUnderstood answer concludes the negotiation for a negotiated 1035 key whereas for a declarative key, a NotUnderstood answer simply 1036 informs the declarer of lack of comprehension by the receiver. 1038 In either case, a NotUnderstood answer always requires that the 1039 protocol behavior associated with that key be not used within 1040 the scope of the key (connection/session) by either side. 1042 6.4 Outstanding Negotiation Exchanges 1044 There was some uncertainty around the number of outstanding 1045 Login Response PDUs on a connection. [RFC3720] offers the 1046 analogy of SCSI linked commands to Login and Text negotiations 1047 in sections 5.3 and 10.10.3 respectively, but does not make it 1048 fully explicit. This section is to offer a clarification in 1049 this regard. 1051 There MUST NOT be more than one outstanding Login Request or 1052 Login Response or Text Request or Text Response PDU on an iSCSI 1053 connection. An outstanding PDU in this context is one that has 1054 not been acknowledged by the remote iSCSI side. 1056 7 iSCSI Error Handling and Recovery 1058 7.1 ITT 1060 Section 10.19 in [RFC3720] mentions this in passing but noted 1061 here again for making it obvious since the semantics apply to 1062 the initiators in general. An ITT value of 0xffffffff is 1063 reserved and MUST NOT be assigned for a task by the initiator. 1064 The only instance it may be seen on the wire is in a target- 1065 initiated NOP-In PDU (and in the initiator response to that PDU 1066 if necessary). 1068 7.2 Format Errors 1070 Section 6.6 of [RFC3720] discusses format error handling. This 1071 section elaborates on the "inconsistent" PDU field contents 1072 noted in [RFC3720]. 1074 All initiator-detected PDU construction errors MUST be 1075 considered as format errors. Some examples of such errors are: 1077 - NOP-In with a valid TTT but an invalid LUN 1079 - NOP-In with a valid ITT (i.e. a NOP-In response) and also a 1080 valid TTT 1082 - SCSI Response PDU with Status=CHECK CONDITION, but 1083 DataSegmentLength = 0 1085 7.3 Digest Errors 1087 Section 6.7 of [RFC3720] discusses digest error handling. It 1088 states that "No further action is necessary for initiators if 1089 the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" 1090 on detecting a payload digest error. This is incorrect. 1092 An Asynchronous Message PDU or a Reject PDU carries the next 1093 StatSN value on an iSCSI connection, advancing the StatSN. When 1094 an initiator discards one of these PDUs due to a payload digest 1095 error, the entire PDU including the header MUST be discarded. 1096 Consequently, the initiator MUST treat the exception like a loss 1097 of any other solicited response PDU - i.e. it MUST use one of 1098 the following options noted in [RFC3720]: 1100 a) Request PDU retransmission with a status SNACK. 1102 b) Logout the connection for recovery and continue the 1103 tasks on a different connection instance. 1105 c) Logout to close the connection (abort all the commands 1106 associated with the connection). 1108 7.4 Message Error Checking 1110 There has been some uncertainty on the extent to which incoming 1111 messages have to be checked for protocol errors, beyond what is 1112 strictly required for processing the inbound message. This 1113 section addresses that question. 1115 Unless [RFC3720] or this draft requires it, an iSCSI 1116 implementation is not required to do an exhaustive protocol 1117 conformance checking on an incoming iSCSI PDU. The iSCSI 1118 implementation especially is not required to double-check the 1119 remote iSCSI implementation's conformance to protocol 1120 requirements. 1122 8 iSCSI PDUs 1124 8.1 Asynchronous Message 1126 This section defines additional semantics for the Asynchronous 1127 Message PDU defined in section 10.9 of [RFC3720] using the same 1128 conventions. 1130 The following new legal value for AsyncEvent is defined: 1132 5: all active tasks for LU with matching LUN field in the Async 1133 Message PDU are being terminated. 1135 The receiving initiator iSCSI layer MUST respond to this Message 1136 by taking the following steps in order. 1138 i) Stop Data-Out transfers on that connection for all active 1139 TTTs for the affected LUN quoted in the Async Message 1140 PDU. 1141 ii)Acknowledge the StatSN of the Async Message PDU via a 1142 Nop-Out PDU with ITT=0xffffffff (i.e. non-ping flavor), 1143 while copying the LUN field from Async Message to Nop- 1144 Out. 1146 The new AsyncEvent defined in this section however MUST NOT be 1147 used on an iSCSI session unless the new TaskReporting text key 1148 defined in section 9.1 was negotiated to FastAbort on the 1149 session. 1151 8.2 Reject 1153 Section 10.17.1 of [RFC3720] specifies the Reject reason code of 1154 0x0b with an explanation of "Negotiation Reset". At this point, 1155 we do not see any legitimate iSCSI protocol use case for using 1156 this reason code. Thus reason code 0x0b MUST be considered as 1157 deprecated and MUST NOT be sent by implementations that 1158 comply with the requirements of this document. An 1159 implementation receiving reason code 0x0b MUST treat it as a 1160 negotiation failure that terminates the Login phase and the TCP 1161 connection, as specified in Section 6.10 of [RFC3720]. 1163 Section 5.4 of [RFC3720] states: 1165 Neither the initiator nor the target should attempt to 1166 declare or negotiate a parameter more than once during any 1167 negotiation sequence without an intervening operational 1168 parameter negotiation reset, except for responses to 1169 specific keys that explicitly allow repeated key 1170 declarations (e.g., TargetAddress). 1172 The deprecation of reason code 0x0b eliminates the possibility 1173 of an operational parameter negotiation reset, causing 1174 the phrase "without an intervening operational 1175 parameter negotiation reset" in [RFC3720] to refer to an 1176 impossible event. The quoted phrase SHOULD be ignored by 1177 receivers that handle reason code 0x0b in the manner specified 1178 in this section. 1180 9 Login/Text Operational Text Keys 1182 This section follows the same conventions as section 12 of 1183 [RFC3720]. 1185 9.1 TaskReporting 1187 Use: LO 1188 Senders: Initiator and Target 1189 Scope: SW 1191 Irrelevant when: SessionType=Discovery 1192 TaskReporting= 1194 Default is RFC3720. 1195 Result function is AND. 1197 This key is used to negotiate the task completion reporting 1198 semantics from the SCSI target. Following table describes the 1199 semantics an iSCSI target MUST support for respective negotiated 1200 key values. Whenever this key is negotiated, at least the 1201 RFC3720 and ResponseFence values MUST be offered as options by 1202 the negotiation originator. 1204 +--------------+------------------------------------------+ 1205 | Name | Description | 1206 +--------------+------------------------------------------+ 1207 | RFC3720 | RFC 3720-compliant semantics. Response | 1208 | | fencing is not guaranteed and fast | 1209 | | completion of multi-task aborting is not | 1210 | | supported | 1211 +--------------+------------------------------------------+ 1212 | ResponseFence| Response Fence (section 3.3.1) semantics | 1213 | | MUST be supported in reporting task | 1214 | | completions | 1215 +--------------+------------------------------------------+ 1216 | FastAbort | Updated fast multi-task abort semantics | 1217 | | defined in section 4.1.3 MUST be | 1218 | | supported. Support for Response Fence is| 1219 | | implied - i.e. section 3.3.1 semantics | 1220 | | MUST be supported as well | 1221 +--------------+------------------------------------------+ 1222 When TaskReporting is not negotiated to FastAbort, the [RFC3720] 1223 TMF semantics as clarified in section 4.1.2 MUST be used. 1225 10 Security Considerations 1227 This document does not introduce any new security considerations 1228 other than those already noted in [RFC3720]. Consequently, all 1229 the iSCSI-related security text in [RFC3723] is also directly 1230 applicable to this document. 1232 11 IANA Considerations 1234 11.1 iSCSI-related IANA registries 1236 This draft creates the following iSCSI-related registries for 1237 IANA to manage. 1239 1. iSCSI Opcodes 1241 2. iSCSI Login/Text Keys 1243 3. iSCSI Asynchronous Events 1245 4. iSCSI Task Management Function Codes 1247 5. iSCSI Login Response Status Codes 1249 6. iSCSI Reject Reason Codes 1251 7. iSER Opcodes 1253 Each of the following sections describes a proposed registry and 1254 its sub-registries if any and their administration policies in 1255 more detail. IANA may publish what this document calls the main 1256 "registries" as sub-registries of a larger iSCSI registry if 1257 doing so is appropriate. However, wherever registry-to-sub- 1258 registry relationships are specified by this document, they must 1259 be preserved intact in the new hierarchy by the end of the IANA 1260 publication process. 1262 [RFC3720] specifies three iSCSI-related registries - extended 1263 key, authentication methods, digests. This document recommends 1264 that those registries be published together with the registries 1265 defined by this document. Further, this document recommends 1266 that the three [RFC3720] registries be listed in between 1267 registry item no. 6 and registry item no. 7 in the registry list 1268 that preceded this text. 1270 11.2 iSCSI Opcodes 1272 Name of the registry: "iSCSI Opcodes" 1274 Namespace details: Numerical values that can fit in one octet 1275 with most significant two bits (bits 0 and 1) already designated 1276 by [RFC3720], bit 0 being reserved and bit 1 for immediate 1277 delivery. Bit 2 is designated to identify the originator of the 1278 opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target 1280 Information that must be provided to assign a new value: An 1281 IESG-approved standards-track specification defining the 1282 semantics and interoperability requirements of the proposed new 1283 value and the fields to be recorded in the registry 1285 Allocation request guidance to requesters: 1287 1) If initiator opcode and target opcode to identify the request 1288 and response of a new type of protocol operation are requested, 1289 assign the same lower five bits (i.e. Bit 3 through Bit 7) for 1290 both opcodes, e.g. 0x13 and 0x33 1292 2) If only the initiator opcode or target opcode is requested to 1293 identify a one-way protocol message (i.e. request without a 1294 response or a "response" without a request), assign an unused 1295 number from the appropriate category (i.e. Bit 2 set to 0 or 1 1296 for initiator category or target category) and add the other 1297 pair member (i.e. same opcode with Bit 2 set to 1 or 0, 1298 respectively) to "Reserved to IANA" list. 1300 3) If there are no other opcodes available to assign on a 1301 request for a new opcode except the reserved opcodes in the 1302 "Reserved to IANA" list, allocate the opcodes from the 1303 appropriate category (initiator or target). 1305 Notes to IANA: 1307 - Publish the preceding Allocation request guidance verbatim in 1308 the registry 1310 - Use the Expert Review process ([IANA]) to ensure that 1311 compliance with the Allocation request guidance is met 1313 Fields to record in the registry: Assigned value, Who can 1314 originate (Initiator or Target), Operation Name and its 1315 associated RFC reference 1316 Initial registry contents: 1318 0x00, Initiator, NOP-Out, [RFC3720] 1320 0x01, Initiator, SCSI Command, [RFC3720] 1322 0x02, Initiator, SCSI Task Management function request, 1323 [RFC3720] 1325 0x03, Initiator, Login Request, [RFC3720] 1327 0x04, Initiator, Text Request, [RFC3720] 1329 0x05, Initiator, SCSI Data-Out, [RFC3720] 1331 0x06, Initiator, Logout Request, [RFC3720] 1333 0x10, Initiator, SNACK Request, [RFC3720] 1335 0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720] 1337 0x20, Target, NOP-In, [RFC3720] 1339 0x21, Target, SCSI Response, [RFC3720] 1341 0x22, Target, SCSI Task Management function response, [RFC3720] 1343 0x23, Target, Login Response, [RFC3720] 1345 0x24, Target, Text Response, [RFC3720] 1347 0x25, Target, SCSI Data-In, [RFC3720] 1349 0x26, Target, Logout Response, [RFC3720] 1351 0x31, Target, Ready To Transfer (R2T), [RFC3720] 1353 0x32, Target, Asynchronous Message, [RFC3720] 1355 0x3c-0x3e, Target, Vendor specific codes, [RFC3720] 1357 0x3f, Target, Reject, [RFC3720] 1359 "Reserved to IANA" opcodes: 0x11, 0x12, 0x1f, 0x30 1361 Allocation Policy: 1363 Standards Action ([IANA]): This is required for defining the 1364 semantics of the opcode 1365 Expert Review ([IANA]): This is required for selecting the 1366 specific opcode(s) to allocate in order to ensure compliance 1367 with the earlier "Allocation request guidance to requesters" 1369 11.3 iSCSI Login/Text Keys 1371 Name of the registry: "iSCSI Text Keys" 1373 Namespace details: Key=value pairs with "Key" names in UTF-8 1374 Unicode, and the permissible "value" options for the "Key" are 1375 Key-dependent. [RFC3720] defines the rules on key names and 1376 allowed values 1378 Information that must be provided to assign a new value: An 1379 IESG-approved standards-track specification defining the 1380 semantics and interoperability requirements of the proposed new 1381 Key per [RFC3720] key specification template and the fields to 1382 be recorded in the registry 1384 Assignment policy: 1386 If the requested Key name is not already assigned and is roughly 1387 representative of its proposed semantics, it may be assigned to 1388 the requester. 1390 Given the arbitrary nature of text strings, there is no maximum 1391 reserved by IANA for assignment in this registry. 1393 Fields to record in the registry: Assigned Key Name and its 1394 associated RFC reference 1396 Initial registry contents: 1398 AuthMethod, [RFC3720] 1399 HeaderDigest, [RFC3720] 1401 DataDigest, [RFC3720] 1403 MaxConnections, [RFC3720] 1405 SendTargets, [RFC3720] 1407 TargetName, [RFC3720] 1409 InitiatorName, [RFC3720] 1411 TargetAlias, [RFC3720] 1413 InitiatorAlias, [RFC3720] 1415 TargetAddress, [RFC3720] 1417 TargetPortalGroupTag, [RFC3720] 1419 InitialR2T, [RFC3720] 1421 ImmediateData, [RFC3720] 1423 MaxRecvDataSegmentLength, [RFC3720] 1425 MaxBurstLength, [RFC3720] 1427 FirstBurstLength, [RFC3720] 1429 DefaultTime2Wait, [RFC3720] 1431 DefaultTime2Retain, [RFC3720] 1433 MaxOutstandingR2T, [RFC3720] 1435 DataPDUInOrder, [RFC3720] 1437 DataSequenceInOrder, [RFC3720] 1439 ErrorRecoveryLevel, [RFC3720] 1441 SessionType, [RFC3720] 1443 RDMAExtensions, [iSER] 1445 TargetRecvDataSegmentLength, [iSER] 1447 InitiatorRecvDataSegmentLength, [iSER] 1448 MaxOutstandingUnexpectedPDUs, [iSER] 1450 TaskReporting, this document 1452 Allocation Policy: 1454 Standards Action ([IANA]) 1456 11.4 iSCSI Asynchronous Events 1458 Name of the registry: "iSCSI Asynchronous Events" 1460 Namespace details: Numerical values that can fit in one octet 1462 Information that must be provided to assign a new value: A IESG- 1463 approved standards-track specification defining the semantics 1464 and interoperability requirements of the proposed new Event and 1465 the fields to be recorded in the registry 1467 Assignment policy: 1469 If the requested value is not already assigned, it may be 1470 assigned to the requester. 1472 6-247: range reserved by IANA for assignment in this registry 1474 Fields to record in the registry: Assigned Event number, 1475 Description and its associated RFC reference 1477 Initial registry contents: 1479 0, SCSI Async Event, [RFC3720] 1481 1, Logout Request, [RFC3720] 1482 2, Connection drop notification, [RFC3720] 1484 3, Session drop notification, [RFC3720] 1486 4, Negotiation Request, [RFC3720] 1488 5, Task termination, this document 1490 248-254, Vendor-unique, this document 1492 255, Vendor-unique, [RFC3720] 1494 Allocation Policy: 1496 Standards Action ([IANA]) 1498 11.5 iSCSI Task Management Function Codes 1500 Name of the registry: "iSCSI TMF Codes" 1502 Namespace details: Numerical values that can fit in 7 bits 1504 Information that must be provided to assign a new value: An 1505 IESG-approved standards-track specification defining the 1506 semantics and interoperability requirements of the proposed new 1507 Code and the fields to be recorded in the registry 1509 Assignment policy: 1511 If the requested value is not already assigned, it may be 1512 assigned to the requester. 1514 9-127: range reserved by IANA for assignment in this registry 1516 Fields to record in the registry: Assigned Code, Description and 1517 its associated RFC reference 1519 Initial registry contents: 1521 1, ABORT TASK, [RFC3720] 1523 2, ABORT TASK SET, [RFC3720] 1525 3, CLEAR ACA, [RFC3720] 1526 4, CLEAR TASK SET, [RFC3720] 1528 5, LOGICAL UNIT RESET, [RFC3720] 1530 6, TARGET WARM RESET, [RFC3720] 1532 7, TARGET COLD RESET, [RFC3720] 1534 8, TASK REASSIGN, [RFC3720] 1536 Allocation Policy: 1538 Standards Action ([IANA]) 1540 11.6 iSCSI Login Response Status Codes 1542 Name of the registry: "iSCSI Login Response Status Codes" 1544 Namespace details: Numerical values; Status-Class (one octet), 1545 Status-Detail (one octet) for each possible value of Status- 1546 Class except for Vendor-Unique Status-Class (0x0f) 1548 Information that must be provided to assign a new value: An 1549 IESG-approved specification defining the semantics and 1550 interoperability requirements of the proposed new Code, its 1551 Status-Class affiliation (only if a new Status-Detail value is 1552 being proposed for a Status-Class), Status-Class definition 1553 (only if a new Status-Class is being proposed) and the fields to 1554 be recorded in the registry 1556 Assignment policy: 1558 If the requested value is not already assigned, it may be 1559 assigned to the requester. 1561 4-14 and 16-255: range reserved by IANA for assignment in this 1562 registry 1564 Fields to record in the Status-Class main registry: Assigned 1565 Code, Description and its associated RFC reference 1566 Fields to record in the Status-Detail sub-registries: Status- 1567 Class, Assigned Code, Description and its associated RFC 1568 reference 1570 Initial registry contents (Status-Class): 1572 0x00, Success, [RFC3720] 1574 0x01, Redirection, [RFC3720] 1576 0x02, Initiator Error, [RFC3720] 1578 0x03, Target Error, [RFC3720] 1580 0x0f, Vendor-Unique, this document 1582 Initial sub-registry contents (Status-Detail for Status- 1583 Class=0x00): 1585 0x00, 0x00, Success, [RFC3720] 1587 1-255: range reserved by IANA for assignment in Status-Class=0 1588 sub-registry 1590 Initial sub-registry contents (Status-Detail for Status- 1591 Class=0x01): 1593 0x01, 0x01, Temporary move, [RFC3720] 1595 0x01, 0x02, Permanent move, [RFC3720] 1597 3-255: range reserved by IANA for assignment in Status-Class=1 1598 sub-registry 1600 Initial sub-registry contents (Status-Detail for Status- 1601 Class=0x02): 1603 0x02, 0x00, Miscellaneous, [RFC3720] 1605 0x02, 0x01, Authentication failure, [RFC3720] 1607 0x02, 0x02, Authorization failure, [RFC3720] 1608 0x02, 0x03, Not found, [RFC3720] 1610 0x02, 0x04, Target removed, [RFC3720] 1612 0x02, 0x05, Unsupported version, [RFC3720] 1614 0x02, 0x06, Too many connections, [RFC3720] 1616 0x02, 0x07, Missing parameter, [RFC3720] 1618 0x02, 0x08, Can't include in session, [RFC3720] 1620 0x02, 0x09, Unsupported session type, [RFC3720] 1622 0x02, 0x0a, Non-existent session, [RFC3720] 1624 0x02, 0x0b, Invalid during login, [RFC3720] 1626 12-255: range reserved by IANA for assignment in Status-Class=2 1627 sub-registry 1629 Initial sub-registry contents (Status-Detail for Status- 1630 Class=0x03): 1632 0x03, 0x00, Target error, [RFC3720] 1634 0x03, 0x01, Service unavailable, [RFC3720] 1636 0x03, 0x02, Out of resources, [RFC3720] 1638 3-255: range reserved by IANA for assignment in Status-Class=3 1639 sub-registry 1641 Allocation Policy: 1643 Standards Action ([IANA]) 1645 11.7 iSCSI Reject Reason Codes 1647 Name of the registry: "iSCSI Reject Reason Codes" 1648 Namespace details: Numerical values that can fit in a single 1649 octet 1651 Information that must be provided to assign a new value: A 1652 published specification defining the semantics and 1653 interoperability requirements of the proposed new Code and the 1654 fields to be recorded in the registry 1656 Assignment policy: 1658 If the requested value is not already assigned, it may be 1659 assigned to the requester. 1661 13-255: range reserved by IANA for assignment in this registry 1663 Fields to record in the registry: Assigned Code, Description and 1664 its associated RFC reference 1666 Initial registry contents: 1668 0x01, Reserved, [RFC3720] 1670 0x02, Data digest error, [RFC3720] 1672 0x03, SNACK Reject, [RFC3720] 1674 0x04, Protocol Error, [RFC3720] 1676 0x05, Command not supported, [RFC3720] 1678 0x06, Immediate command reject, [RFC3720] 1680 0x07, Task in progress, [RFC3720] 1682 0x08, Invalid data ack, [RFC3720] 1684 0x09, Invalid PDU field, [RFC3720] 1686 0x0a, Long op reject, [RFC3720] 1688 0x0b, "Deprecated reason code", this document 1689 0x0c, Waiting for Logout, [RFC3720] 1691 Allocation Policy: 1693 Standards Action ([IANA]) 1695 11.8 iSER Opcodes 1697 Name of the registry: "iSER Opcodes" 1699 Namespace details: Numerical values that can fit in 4 bits 1701 Information that must be provided to assign a new value: An 1702 IESG-approved specification defining the semantics and 1703 interoperability requirements of the proposed new value and the 1704 fields to be recorded in the registry 1706 Assignment policy: 1708 If the requested value is not already assigned, it may be 1709 assigned to the requester. 1711 4-15: range reserved by IANA for assignment in this registry 1713 Fields to record in the registry: Assigned value, Operation Name 1714 and its associated RFC reference 1716 Initial registry contents: 1718 0x1, iSCSI control-type, [iSER] 1720 0x2, iSER Hello, [iSER] 1722 0x3, iSER HelloReply, [iSER] 1723 Allocation Policy: 1725 Standards Action ([IANA]) 1726 12 References and Bibliography 1728 12.1 Normative References 1730 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 1731 M., and E. Zeidner, "Internet Small Computer Systems 1732 Interface (iSCSI)", RFC 3720, April 2004. 1734 [SPC3] ANSI INCITS 408-2005, SCSI Primary Commands-3. 1736 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1737 Requirement Levels", March 1997. 1739 [IANA] Alvestrand, H. and T. Narten, "Guidelines for Writing 1740 an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1741 October 1998. 1743 [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, 1744 P., J. Hufferd, "iSCSI Extensions for RDMA", IETF Internet 1745 Draft draft-ietf-ips-iser-04.txt (work in progress), June 1746 2005. 1748 12.2 Informative References 1750 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., 1751 and M. Krueger, "Internet Small Computer Systems Interface 1752 (iSCSI) Naming and Discovery", RFC 3721, April 2004. 1754 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and 1755 F. Travostino, "Securing Block Storage Protocols over IP", 1756 RFC 3723, April 2004. 1758 [RFC3722] Bakke, M., "String Profile for Internet Small 1759 Computer Systems Interface (iSCSI) Names", RFC 3722, April 1760 2004. 1762 [SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM- 1763 2). 1765 [SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM- 1766 3). 1768 [SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM- 1769 4), Work in Progress. 1771 13 Editor's Address 1773 Mallikarjun Chadalapaka 1774 Hewlett-Packard Company 1775 8000 Foothills Blvd. 1776 Roseville, CA 95747-5668, USA 1777 Phone: +1-916-785-5621 1778 E-mail: cbm@rose.hp.com 1780 14 Acknowledgements 1782 The IP Storage (ips) Working Group in the Transport Area of 1783 IETF has been responsible for defining the iSCSI protocol 1784 (apart from a host of other relevant IP Storage protocols). 1785 The editor acknowledges the contributions of the entire 1786 working group. 1788 The following individuals directly contributed to identifying 1789 [RFC3720] issues and/or suggesting resolutions to the issues 1790 clarified in this document: David Black, Gwendal Grignou, 1791 Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob 1792 Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh 1793 Gupta, Eddy Quicksall, Paul Koning. This document benefited 1794 from all these contributions. 1796 15 Full Copyright Statement 1798 Copyright (C) The IETF Trust (2007). This document is 1799 subject to the rights, licenses and restrictions contained in 1800 BCP 78, and except as set forth therein, the authors retain 1801 all their rights. 1803 This document and the information contained herein are 1804 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1805 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1806 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 1807 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1808 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1809 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1810 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1811 PARTICULAR PURPOSE. 1813 16 Intellectual Property Statement 1815 The IETF takes no position regarding the validity or scope of 1816 any Intellectual Property Rights or other rights that might 1817 be claimed to pertain to the implementation or use of the 1818 technology described in this document or the extent to which 1819 any license under such rights might or might not be 1820 available; nor does it represent that it has made any 1821 independent effort to identify any such rights. Information 1822 on the procedures with respect to rights in RFC documents can 1823 be found in BCP 78 and BCP 79. 1825 Copies of IPR disclosures made to the IETF Secretariat and 1826 any assurances of licenses to be made available, or the 1827 result of an attempt made to obtain a general license or 1828 permission for the use of such proprietary rights by 1829 implementers or users of this specification can be obtained 1830 from the IETF on-line IPR repository at 1831 http://www.ietf.org/ipr. 1833 The IETF invites any interested party to bring to its 1834 attention any copyrights, patents or patent applications, or 1835 other proprietary rights that may cover technology that may 1836 be required to implement this standard. Please address the 1837 information to the IETF at ietf-ipr@ietf.org.