idnits 2.17.1 draft-ietf-ips-iscsi-impl-guide-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 717. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 731. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 17 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. -- 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 711 has weird spacing: '... be clai...' == Line 720 has weird spacing: '... any ass...' == Line 721 has weird spacing: '...t of an atte...' == Line 723 has weird spacing: '...of this spec...' == Line 728 has weird spacing: '...tention any...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 2006) is 6588 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) == Missing Reference: 'RFC 3720' is mentioned on line 272, but not defined ** Obsolete undefined reference: RFC 3720 (Obsoleted by RFC 7143) == Unused Reference: 'RFC2119' is defined on line 657, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) -- Possible downref: Non-RFC (?) normative reference: ref. 'SPC3' Summary: 7 errors (**), 0 flaws (~~), 12 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-01.txt Hewlett-Packard Co. 4 Editor 6 Expires March 2006 8 iSCSI Implementer's Guide 10 Status of this Memo 11 By submitting this Internet-Draft, each author represents 12 that any applicable patent or other IPR claims of which he or 13 she is aware have been or will be disclosed, and any of which 14 he or she becomes aware will be disclosed, in accordance with 15 Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed 32 at http://www.ietf.org/shadow.html. 34 Abstract 35 iSCSI is a SCSI transport protocol and maps the SCSI family 36 of application protocols onto TCP/IP. RFC 3720 defines the 37 iSCSI protocol. This document compiles the clarifications to 38 the original protocol definition in RFC 3720 to serve as a 39 companion document for the iSCSI implementers. This document 40 updates RFC 3720 and the text in this document supersedes the 41 text in RFC 3720 when the two differ. 43 Table of Contents 45 1 Definitions and acronyms ...............................3 46 1.1 Definitions ............................................3 47 1.2 Acronyms ...............................................3 48 2 Introduction ...........................................5 49 3 iSCSI semantics for SCSI tasks .........................6 50 3.1 Residual handling ......................................6 51 3.1.1 Overview..............................................6 52 3.1.2 SCSI REPORT LUNS and Residual Overflow................7 53 3.2 R2T Ordering ...........................................8 54 4 Task Management ........................................9 55 4.1 Requests Affecting Multiple Tasks ......................9 56 4.1.1 Scope of affected tasks...............................9 57 4.1.2 Updated semantics.....................................9 58 4.1.3 Rationale behind the new semantics...................11 59 5 Discovery semantics ...................................13 60 5.1 Error Recovery for Discovery Sessions .................13 61 5.2 Reinstatement Semantics of Discovery Sessions .........13 62 5.2.1 Unnamed Discovery Sessions...........................14 63 5.2.2 Named Discovery Sessions.............................14 64 5.3 TPGT Values ...........................................15 65 6 iSCSI Error Handling and Recovery .....................16 66 6.1 ITT ...................................................16 67 6.2 Format Errors .........................................16 68 6.3 Digest Errors .........................................16 69 7 Security Considerations ...............................18 70 8 IANA Considerations ...................................19 71 9 References and Bibliography ...........................20 72 9.1 Normative References ..................................20 73 9.2 Informative References ................................20 74 10 Editor's Address ......................................21 75 11 Acknowledgements ......................................22 76 12 Full Copyright Statement ..............................23 77 13 Intellectual Property Statement .......................24 79 1 Definitions and acronyms 81 1.1 Definitions 83 I/O Buffer � A buffer that is used in a SCSI Read or Write 84 operation so SCSI data may be sent from or received into 85 that buffer. For a read or write data transfer to take 86 place for a task, an I/O Buffer is required on the 87 initiator and at least one required on the target. 89 SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 90 aggregate data length of the data that SCSI layer 91 logically "presents" to iSCSI layer for a Data-in or 92 Data-out transfer in the context of a SCSI task. For a 93 bidirectional task, there are two SPDTL values � one for 94 Data-in and one for Data-out. Note that the notion of 95 "presenting" includes immediate data per the data 96 transfer model in [SAM2], and excludes overlapping data 97 transfers, if any, requested by the SCSI layer. 99 Third-party: A term used in this document to denote nexus 100 objects (I_T or I_T_L) and iSCSI sessions which reap the 101 side-effects of actions took place in the context of a 102 separate iSCSI session, while being third parties to the 103 action that caused the side-effects. One example of a 104 Third-party session is an iSCSI session hosting an I_T_L 105 nexus to an LU that is reset with an LU Reset TMF via a 106 separate I_T nexus. 108 1.2 Acronyms 110 Acronym Definition 112 ------------------------------------------------------------- 114 EDTL Expected Data Transfer Length 116 IANA Internet Assigned Numbers Authority 118 IETF Internet Engineering Task Force 120 I/O Input - Output 122 IP Internet Protocol 124 iSCSI Internet SCSI 126 iSER iSCSI Extensions for RDMA 128 ITT Initiator Task Tag 130 LO Leading Only 132 LU Logical Unit 134 LUN Logical Unit Number 136 PDU Protocol Data Unit 138 RDMA Remote Direct Memory Access 140 R2T Ready To Transfer 142 R2TSN Ready To Transfer Sequence Number 144 RFC Request For Comments 146 SAM SCSI Architecture Model 148 SCSI Small Computer Systems Interface 150 SN Sequence Number 152 SNACK Selective Negative Acknowledgment - also 154 Sequence Number Acknowledgement for data 156 TCP Transmission Control Protocol 158 TMF Task Management Function 160 TTT Target Transfer Tag 162 UA Unit Attention 164 2 Introduction 166 Several iSCSI implementations had been built after [RFC3720] was 167 published and the iSCSI community is now richer by the resulting 168 implementation expertise. The goal of this document is to 169 leverage this expertise both to offer clarifications to the 170 [RFC3720] semantics and to address defects in [RFC3720] as 171 appropriate. This document intends to offer critical guidance 172 to implementers with regard to non-obvious iSCSI implementation 173 aspects so as to improve interoperability and accelerate iSCSI 174 adoption. This document, however, does not purport to be an 175 all-encompassing iSCSI how-to guide for implementers, nor a 176 complete revision of [RFC3720]. This document instead is 177 intended as a companion document to [RFC3720] for the iSCSI 178 implementers. 180 iSCSI implementers are required to reference [RFC3722] and 181 [RFC3723] in addition to [RFC3720] for mandatory requirements. 182 In addition, [RFC3721] also contains useful information for 183 iSCSI implementers. The text in this document, however, updates 184 and supersedes the text in all the noted RFCs whenever there is 185 such a question. 187 3 iSCSI semantics for SCSI tasks 189 3.1 Residual handling 191 Section 10.4.1 of [RFC3720] defines the notion of "residuals" 192 and specifies how the residual information should be encoded 193 into the SCSI Response PDU in Counts and Flags fields. Section 194 3.1.1 clarifies the intent of [RFC3720] and explains the general 195 principles. Section 3.1.2 describes the residual handling in 196 the REPORT LUNS scenario. 198 3.1.1 Overview 200 SCSI-Presented Data Transfer Length (SPDTL) is the term this 201 document uses (see section 1.1 for definition) to represent the 202 aggregate data length that the target SCSI layer attempts to 203 transfer using the local iSCSI layer for a task. Expected Data 204 Transfer Length (EDTL) is the iSCSI term that represents the 205 length of data that iSCSI layer expects to transfer for a task. 206 EDTL is specified in the SCSI Command PDU. 208 When SPDTL = EDTL for a task, the target iSCSI layer completes 209 the task with no residuals. Whenever SPDTL differs from EDTL 210 for a task, that task is said to have a residual. 212 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in 213 the SCSI Response PDU as specified in [RFC3720]. Residual Count 214 MUST be set to the numerical value of (SPDTL � EDTL). 216 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 217 the SCSI Response PDU as specified in [RFC3720]. Residual Count 218 MUST be set to the numerical value of (EDTL � SPDTL). 220 Note that the Overflow and Underflow scenarios are independent 221 of Data-in and Data-out. Either scenario is logically possible 222 in either direction of data transfer. 224 3.1.2 SCSI REPORT LUNS and Residual Overflow 226 The specification of the SCSI REPORT LUNS command requires that 227 the SCSI target limit the amount of data transferred to a 228 maximum size (ALLOCATION LENGTH) provided by the initiator in 229 the REPORT LUNS CDB. If the Expected Data Transfer Length 230 (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT 231 LUNS command is set to at least as large as that ALLOCATION 232 LENGTH, the SCSI layer truncation prevents an iSCSI Residual 233 Overflow from occurring. A SCSI initiator can detect that such 234 truncation has occurred via other information at the SCSI layer. 235 The rest of the section elaborates this required behavior. 237 iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI 238 Response and the last SCSI Data-In PDUs to indicate that that an 239 iSCSI target was unable to transfer all of the SCSI data for a 240 command to the initiator because the amount of data to be 241 transferred exceeded the EDTL in the corresponding SCSI Command 242 PDU (see Section 10.4.1 of [RFC3720]). 244 The SCSI REPORT LUNS command requests a target SCSI layer to 245 return a logical unit inventory (LUN list) to the initiator SCSI 246 layer (see section 6.21 of SPC-3 [SPC3]). The size of this LUN 247 list may not be known to the initiator SCSI layer when it issues 248 the REPORT LUNS command; to avoid transfer of more LUN list data 249 than the initiator is prepared for, the REPORT LUNS CDB contains 250 an ALLOCATION LENGTH field to specify the maximum amount of data 251 to be transferred to the initiator for this command. If the 252 initiator SCSI layer has under-estimated the number of logical 253 units at the target, it is possible that the complete logical 254 unit inventory does not fit in the specified ALLOCATION LENGTH. 255 In this situation, section 4.3.3.6 in [SPC3] requires that the 256 target SCSI layer "shall terminate transfers to the Data-In 257 Buffer" when the number of bytes specified by the ALLOCATION 258 LENGTH field have been transferred. 260 Therefore, in response to a REPORT LUNS command, the SCSI layer 261 at the target presents at most ALLOCATION LENGTH bytes of data 262 (logical unit inventory) to iSCSI for transfer to the initiator. 263 For a REPORT LUNS command, if the iSCSI EDTL is at least as 264 large as the ALLOCATION LENGTH, the SCSI truncation ensures that 265 the EDTL will accommodate all of the data to be transferred. If 266 all of the logical unit inventory data presented to the iSCSI 267 layer � i.e. the data remaining after any SCSI truncation - is 268 transferred to the initiator by the iSCSI layer, an iSCSI 269 Residual Overflow has not occurred and the iSCSI (O) bit MUST 270 NOT be set in the SCSI Response or final SCSI Data-Out PDU. 271 This is not a new requirement but is already required by the 272 combination of [RFC 3720] with the specification of the REPORT 273 LUNS command in [SPC3]. If the iSCSI EDTL is larger than the 274 ALLOCATION LENGTH however in this scenario, note that the iSCSI 275 Underflow MUST be signaled in the SCSI Response PDU. An iSCSI 276 Underflow MUST also be signaled when the iSCSI EDTL is equal to 277 ALLOCATION LENGTH but the logical unit inventory data presented 278 to the iSCSI layer is smaller than ALLOCATION LENGTH. 280 The LUN LIST LENGTH field in the logical unit inventory (first 281 field in the inventory) is not affected by truncation of the 282 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 283 initiator to determine that the received inventory is incomplete 284 by noticing that the LUN LIST LENGTH in the inventory is larger 285 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. 286 A common initiator behavior in this situation is to re-issue the 287 REPORT LUNS command with a larger ALLOCATION LENGTH. 289 3.2 R2T Ordering 291 Section 10.8 in [RFC3720] says the following: 293 The target may send several R2T PDUs. It, therefore, can have 294 a number of pending data transfers. The number of outstanding 295 R2T PDUs are limited by the value of the negotiated key 296 MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST 297 be fulfilled by the initiator in the order in which they were 298 received. 300 The quoted [RFC3720] text was unclear on the scope of 301 applicability � either per task, or across all tasks on a 302 connection � and may be interpreted as either. This section is 303 intended to clarify that the scope of applicability of the 304 quoted text is a task. No R2T ordering relationship � either in 305 generation at the target or in fulfilling at the initiator � 306 across tasks is implied. I.e., outstanding R2Ts within a task 307 MUST be fulfilled by the initiator in the order in which they 308 were received on a connection. 310 4 Task Management 312 4.1 Requests Affecting Multiple Tasks 314 This section updates the original text in section 10.6.2 of 315 [RFC3720]. The clarified semantics are a superset of the 316 semantics of the original text in it the new text covers all 317 TMFs that can impact multiple tasks. 319 4.1.1 Scope of affected tasks 321 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 322 identified by the LUN field in the ABORT TASK SET TMF 323 Request PDU. 325 CLEAR TASK SET: All outstanding tasks in the task set for 326 the LU identified by the LUN field in the CLEAR TASK SET 327 TMF Request PDU. See [SPC3] for the definition of a "task 328 set". 330 LOGICAL UNIT RESET: All outstanding tasks from all 331 initiators for the LU identified by the LUN field in the 332 LOGICAL UNIT RESET Request PDU. 334 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks 335 from all initiators across all LUs that the TMF-issuing 336 session has access to on the SCSI target device hosting the 337 iSCSI session. 339 Usage example: an "ABORT TASK SET TMF Request PDU" in the 340 preceding text is an iSCSI TMF Request PDU with the "Function" 341 field set to "ABORT TASK SET" as defined in [RFC3720]. Similar 342 usage is employed for other scope descriptions. 344 4.1.2 Updated semantics 346 The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT 347 RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests 348 consists of the following sequence of actions in the specified 349 order on each of the entities. 351 The initiator: 353 a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT 354 RESET/TARGET WARM RESET/TARGET COLD RESET request. 356 b) Continues to respond to each TTT received for the affected 357 tasks. 359 c) Receives any responses that the target may provide for some 360 tasks among the affected tasks (may process them as usual 361 because they are guaranteed to have chronologically 362 originated before the TMF response). 364 d) Receives the task management response concluding all the 365 tasks in the set of affected tasks. 367 The Target MUST do the following: 369 a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT 370 RESET/TARGET WARM RESET/TARGET COLD RESET request. 372 b) Waits for all currently valid target transfer tags of the 373 affected tasks to be responded. 375 c) Based on the CmdSN ordering, waits (concurrent with the 376 wait in step (b)) for all commands of the affected tasks to 377 be received. In the case of target-scoped requests (i.e. 378 TARGET WARM RESET and TARGET COLD RESET), all the commands 379 that are not received, as at the end of step (b), in the 380 command stream however can be considered to have been 381 received with no command waiting period - i.e. the entire 382 CmdSN space upto the CmdSN of the task management function 383 can be "plugged" (refer section 6.9 on how aborting a 384 specific task can implicitly plug the CmdSN of the task 385 being aborted) at the end of step (b). 387 d) Propagates the TMF request to and receives the response 388 from the target SCSI layer. 390 e) Takes note of last-sent StatSN on each of the connections 391 in the iSCSI session(s) (one or more) sharing the affected 392 tasks, and waits for acknowledgement of each StatSN (may 393 solicit for acknowledgement by way of a NOP-In). If any 394 new task responses are meanwhile received from the SCSI 395 layer while waiting for StatSN acknowledgement(s), those 396 response PDUs � the first SCSI Response PDU of which is 397 presumably carrying the UA notification on all Third-party 398 sessions - MUST be held and queued at the iSCSI layer. If 399 some tasks originate from non-iSCSI I_T_L nexuses then the 400 means by which the target insures that all affected tasks 401 have returned their status to the initiator are defined by 402 the specific non-iSCSI transport protocol(s). 404 f) Sends the task set management response to the issuing 405 initiator. All task response PDUs held back at the iSCSI 406 layer in step e are simultaneously eligible for being 407 placed on the wire at this point. 409 4.1.3 Rationale behind the new semantics 411 There are fundamentally three basic objectives behind the 412 semantics specified in section 4.1.2. 414 1. Maintaining an ordered command flow I_T nexus abstraction 415 to the target SCSI layer even with multi-connection 416 sessions. 418 o Target iSCSI processing of a TMF request must maintain 419 the single flow illusion - steps c & d of the target 420 behavior correspond to this objective. 422 2. Maintaining a single ordered response flow I_T nexus 423 abstraction to the initiator SCSI layer even with multi- 424 connection sessions when one response (i.e. TMF response) 425 could imply the status of other unfinished tasks from the 426 initiator's perspective. 428 o Target must ensure that the initiator does not see 429 "old" task responses (that were placed on the wire 430 chronologically earlier than the TMF response) after 431 seeing the TMF response - step e of the target 432 behavior corresponds to this objective. 434 o Whenever the result of a TMF action is visible across 435 multiple I_T_L nexuses, [SAM2] requires the SCSI 436 device server to trigger a UA on each of the other 437 I_T_L nexuses. Once an initiator is notified of such 438 an UA, the application client on the receiving 439 initiator is required to clear its task state (clause 440 5.5 in [SAM2]) for the affected tasks. It would thus 441 be inappropriate to deliver a SCSI Response for a task 442 after the task state is cleared on the initiator, i.e. 443 after the UA is notified. The UA notification 444 contained in the first SCSI Response PDU on each 445 affected Third-party I_T_L nexus after the TMF action 446 thus MUST NOT pass the affected task responses on any 447 of the iSCSI sessions accessing the LU � steps e & f 448 of the target behavior correspond to this objective. 450 3. Draining all active TTTs corresponding to affected tasks 451 before the TMF is acted on. 453 o Targets are better off if the TTTs are 454 deterministically retired before the affected tasks 455 are terminated because that eliminates the possibility 456 of large-sized Data-out PDUs with stale TTTs arriving 457 after the tasks are terminated. Step b of the target 458 behavior corresponds to this objective. 460 The only other notable thing in step c of the target behavior is 461 the "plugging" part - it is an optimization that says if all 462 tasks on the I_T nexus will be aborted anyway (as with a target 463 reset), there is no need to wait, the target can simply plug all 464 missing CmdSN slots and move on with TMF processing. The first 465 objective (maintaining a single ordered command flow) is still 466 met with this optimization because target SCSI layer only sees 467 ordered commands. 469 5 Discovery semantics 471 5.1 Error Recovery for Discovery Sessions 473 The negotiation of the key ErrorRecoveryLevel is not required 474 for Discovery sessions � i.e. for sessions that negotiated 475 "SessionType=Discovery" � because the default value of 0 is 476 necessary and sufficient for Discovery sessions. It is however 477 possible that some legacy iSCSI implementations might attempt to 478 negotiate the ErrorRecoveryLevel key on Discovery sessions. 479 When such a negotiation attempt is made by the remote side, a 480 compliant iSCSI implementation MUST propose a value of 0 (zero) 481 in response. The operational ErrorRecoveryLevel for Discovery 482 sessions thus MUST be 0. This naturally follows from the 483 functionality constraints [RFC3720] imposes on Discovery 484 sessions. 486 5.2 Reinstatement Semantics of Discovery Sessions 488 Discovery sessions are intended to be relatively short-lived. 489 Initiators are not expected to establish multiple Discovery 490 sessions to the same iSCSI Network Portal (see [RFC3720]). An 491 initiator may use the same iSCSI Initiator Name and ISID when 492 establishing different unique sessions with different targets 493 and/or different portal groups. This behavior is discussed in 494 Section 9.1.1 of [RFC3720] and is, in fact, encouraged as 495 conservative reuse of ISIDs. ISID RULE in [RFC3720] states that 496 there must not be more than one session with a matching 4-tuple: 497 . While 498 the spirit of the ISID RULE applies to Discovery sessions the 499 same as it does for Normal sessions, note that some Discovery 500 sessions differ from the Normal sessions in two important 501 aspects: 503 Because [RFC3720] allows a Discovery session to be 504 established without specifying a TargetName key in the 505 Login Request PDU (let us call such a session an "Unnamed" 506 Discovery session), there is no Target Node context to 507 enforce the ISID RULE. 509 Portal Groups are defined only in the context of a Target 510 Node. When the TargetName key is NULL-valued (i.e. not 511 specified), the TargetPortalGroupTag thus cannot be 512 ascertained to enforce the ISID RULE. 514 The following sections describe the two scenarios � Named 515 Discovery sessions and Unnamed Discovery sessions � separately. 517 5.2.1 Unnamed Discovery Sessions 519 For Unnamed Discovery sessions, neither the TargetName nor the 520 TargetPortalGroupTag is available to the targets in order to 521 enforce the ISID RULE. So the following rule applies. 523 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 524 following 4-tuple for Unnamed Discovery sessions: 525 . The following 526 semantics are implied by this uniqueness requirement. 528 Targets SHOULD allow concurrent establishment of one Discovery 529 session with each of its Network Portals by the same initiator 530 port with a given iSCSI Node Name and an ISID. Each of the 531 concurrent Discovery sessions, if established by the same 532 initiator port to other Network Portals, MUST be treated as 533 independent sessions � i.e. one session MUST NOT reinstate the 534 other. 536 A new Unnamed Discovery session that has a matching 537 to an existing 538 discovery session MUST reinstate the existing Unnamed Discovery 539 session. Note thus that only an Unnamed Discovery session may 540 reinstate an Unnamed Discovery session. 542 5.2.2 Named Discovery Sessions 544 For a Named Discovery session, the TargetName key is specified 545 by the initiator and thus the target can unambiguously ascertain 546 the TargetPortalGroupTag as well. Since all the four elements 547 of the 4-tuple are known, the ISID RULE MUST be enforced by 548 targets with no changes from [RFC3720] semantics. A new session 549 with a matching thus will reinstate an existing session. 551 Note in this case that any new iSCSI session (Discovery or 552 Normal) with the matching 4-tuple may reinstate an existing 553 Named Discovery iSCSI session. 555 5.3 TPGT Values 557 SAM-2 and SAM-3 specifications incorrectly note in their 558 informative text that TPGT value should be non-zero, although 559 [RFC3720} allows the value of zero for TPGT. This section is to 560 clarify that zero value is expressly allowed as a legal value 561 for TPGT. A future revision of SAM will be corrected to address 562 this discrepancy. 564 6 iSCSI Error Handling and Recovery 566 6.1 ITT 568 Section 10.19 in [RFC3720] mentions this in passing but noted 569 here again for making it obvious since the semantics apply to 570 the initiators in general. An ITT value of 0xffffffff is 571 reserved and MUST NOT be assigned for a task by the initiator. 572 The only instance it may be seen on the wire is in a target- 573 initiated NOP-In PDU (and in the initiator response to that PDU 574 if necessary). 576 6.2 Format Errors 578 Section 6.6 of [RFC3720] discusses format error handling. This 579 section elaborates on the "inconsistent" PDU field contents 580 noted in [RFC3720]. 582 All initiator-detected PDU construction errors MUST be 583 considered as format errors. Some examples of such errors are: 585 - NOP-In with a valid TTT but an invalid LUN 587 - NOP-In with a valid ITT (i.e. a NOP-In response) and also a 588 valid TTT 590 - SCSI Response PDU with Status=CHECK CONDITION, but 591 DataSegmentLength = 0 593 6.3 Digest Errors 595 Section 6.7 of [RFC3720] discusses digest error handling. It 596 states that "No further action is necessary for initiators if the discarded 597 PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a 598 payload digest error. This is incorrect. 600 An Asynchronous Message PDU or a Reject PDU carries the next 601 StatSN value on an iSCSI connection, advancing the StatSN. When 602 an initiator discards one of these PDUs due to a payload digest 603 error, the entire PDU including the header MUST be discarded. 604 Consequently, the initiator MUST treat the exception like a loss 605 of any other solicited response PDU � i.e. it MUST use one of 606 the following options noted in [RFC3720]: 608 a) Request PDU retransmission with a status SNACK. 610 b) Logout the connection for recovery and continue the 611 tasks on a different connection instance. 613 c) Logout to close the connection (abort all the commands 614 associated with the connection). 616 7 Security Considerations 618 This document does not introduce any new security considerations 619 other than those already noted in [RFC3720]. Consequently, all 620 the iSCSI-related security text in [RFC3723] is also directly 621 applicable to this document. 623 8 IANA Considerations 625 This draft does not have any specific IANA considerations other 626 than those already noted in [RFC3720]. 628 9 References and Bibliography 630 9.1 Normative References 632 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 633 M., and E. Zeidner, "Internet Small Computer Systems 634 Interface (iSCSI)", RFC 3720, April 2004. 636 [RFC3722] Bakke, M., "String Profile for Internet Small 637 Computer Systems Interface (iSCSI) Names", RFC 3722, April 638 2004. 640 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and 641 F. Travostino, "Securing Block Storage Protocols over IP", 642 RFC 3723, April 2004. 644 [SPC3] T10/1416-D, SCSI Primary Commands-3. 646 9.2 Informative References 648 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., 649 and M. Krueger, "Internet Small Computer Systems Interface 650 (iSCSI) Naming and Discovery", RFC 3721, April 2004. 652 [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, 653 P., J. Hufferd, "iSCSI Extensions for RDMA", IETF 654 Internet Draft draft-ietf-ips-iser-04.txt (work in 655 progress), June 2005. 657 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, March 1997. 660 [SAM2] ANSI X3.366-2003, SCSI Architecture Model-2 (SAM-2). 662 10 Editor's Address 664 Mallikarjun Chadalapaka 665 Hewlett-Packard Company 666 8000 Foothills Blvd. 667 Roseville, CA 95747-5668, USA 668 Phone: +1-916-785-5621 669 E-mail: cbm@rose.hp.com 671 11 Acknowledgements 673 The IP Storage (ips) Working Group in the Transport Area of 674 IETF has been responsible for defining the iSCSI protocol 675 (apart from a host of other relevant IP Storage protocols). 676 The editor acknowledges the contributions of the entire 677 working group. 679 The following individuals directly contributed to identifying 680 [RFC3720] issues and/or suggesting resolutions to the issues 681 clarified in this document: David Black (REPORT LUNS/overflow 682 semantics), Gwendal Grignou (TMF scope), Mike Ko (digest 683 error handling for Asynchronous Message), Dmitry Fomichev 684 (reserved ITT), Bill Studenmund (residual handling, discovery 685 semantics), Ken Sandars (discovery semantics), Bob Russell 686 (discovery semantics), Julian Satran (discovery semantics), 687 Rob Elliott (T10 liaison, R2T ordering), Joseph Pittman(TMF 688 scope). This document benefited from all these 689 contributions. 691 12 Full Copyright Statement 693 Copyright (C) The Internet Society (2005). This document is 694 subject to the rights, licenses and restrictions contained in 695 BCP 78, and except as set forth therein, the authors retain 696 all their rights. 698 This document and the information contained herein are 699 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 700 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 701 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 702 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 703 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 705 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 13 Intellectual Property Statement 709 The IETF takes no position regarding the validity or scope of 710 any Intellectual Property Rights or other rights that might 711 be claimed to pertain to the implementation or use of the 712 technology described in this document or the extent to which 713 any license under such rights might or might not be 714 available; nor does it represent that it has made any 715 independent effort to identify any such rights. Information 716 on the procedures with respect to rights in RFC documents can 717 be found in BCP 78 and BCP 79. 719 Copies of IPR disclosures made to the IETF Secretariat and 720 any assurances of licenses to be made available, or the 721 result of an attempt made to obtain a general license or 722 permission for the use of such proprietary rights by 723 implementers or users of this specification can be obtained 724 from the IETF on-line IPR repository at 725 http://www.ietf.org/ipr. 727 The IETF invites any interested party to bring to its 728 attention any copyrights, patents or patent applications, 729 or other proprietary rights that may cover technology that 730 may be required to implement this standard. Please address 731 the information to the IETF at ietf-ipr@ietf.org.