idnits 2.17.1 draft-ietf-storm-iscsi-cons-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The abstract seems to indicate that this document obsoletes RFC3720, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC3980, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC5048, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC4850, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC3721, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3723, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC5048, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4850, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2867 -- Looks like a reference, but probably isn't: '0' on line 6742 -- Looks like a reference, but probably isn't: '7' on line 6742 == Missing Reference: 'MaxMissingDPDU' is mentioned on line 11876, but not defined == Missing Reference: 'MaxOutStandingR2T' is mentioned on line 11884, but not defined == Missing Reference: 'MaxMissingSPDU' is mentioned on line 11897, but not defined == Missing Reference: 'MaxSupportedConns' is mentioned on line 11907, but not defined == Unused Reference: 'RFC791' is defined on line 10840, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 10843, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 10846, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 10849, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 10861, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 10888, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 10918, but no explicit reference was found in the text == Unused Reference: 'RFC5646' is defined on line 10930, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 10933, but no explicit reference was found in the text == Unused Reference: 'CRC' is defined on line 10970, but no explicit reference was found in the text == Unused Reference: 'RFC3347' is defined on line 10981, but no explicit reference was found in the text == Unused Reference: 'RFC3980' is defined on line 10995, but no explicit reference was found in the text == Unused Reference: 'RFC4173' is defined on line 11007, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 11029, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OUI' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM4' -- Possible downref: Non-RFC (?) normative reference: ref. 'SBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SPC3' -- Possible downref: Non-RFC (?) normative reference: ref. 'UML' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 3980 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 4850 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 5046 (Obsoleted by RFC 7145) -- Obsolete informational reference (is this intentional?): RFC 5048 (Obsoleted by RFC 7143) Summary: 4 errors (**), 0 flaws (~~), 21 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Storage Maintenance (storm) WG Mallikarjun Chadalapaka 2 Internet Draft Microsoft 3 draft-ietf-storm-iscsi-cons-04.txt 4 Intended status: Proposed Standard Julian Satran 5 Expires: April 2012 Infinidat Ltd. 6 Obsoletes: 3720, 3980, 4850, 5048 7 Updates: 3721, 3723 Kalman Meth 8 IBM 10 David Black 11 EMC 13 iSCSI Protocol (Consolidated) 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on April 27, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document describes a transport protocol for SCSI that works 56 on top of TCP. The iSCSI protocol aims to be fully compliant with 57 the standardized SCSI Architecture Model (SAM-2). RFC 3720 58 defined the original iSCSI protocol. RFC 3721 discusses iSCSI 59 Naming examples and discovery techniques. Subsequently, RFC 3980 60 added an additional naming format to iSCSI protocol. RFC 4850 61 followed up by adding a new public extension key to iSCSI. RFC 62 5048 offered a number of clarifications and a few improvements and 63 corrections to the original iSCSI protocol. 65 This document obsoletes RFCs 3720, 3980, 4850 and 5048 by 66 consolidating them into a single document and making additional 67 updates to the consolidated specification. This document also 68 updates RFC 3721 and RFC 3723. The text in this document thus 69 supersedes the text in all the noted RFCs wherever there is a 70 difference in semantics. 72 1. Introduction.................................................... 14 74 2. Definitions, Acronyms, and Document Summary..................... 15 75 2.1. Definitions ................................................. 15 76 2.2. Acronyms .................................................... 21 77 2.3. Summary of Changes .......................................... 23 78 2.4. Conventions ................................................. 24 79 2.4.1. Word Rule ............................................... 25 80 2.4.2. Half-Word Rule .......................................... 25 81 2.4.3. Byte Rule ............................................... 25 82 3. UML Conventions................................................. 27 83 3.1. UML Conventions Overview ...................................27 84 3.2. Multiplicity Notion ........................................27 85 3.3. Class Diagram Conventions ..................................28 86 3.4. Class Diagram Notation for Associations ....................29 87 3.5. Class Diagram Notation for Aggregations ....................30 88 3.6. Class Diagram Notation for Generalizations .................30 89 4. Overview........................................................ 32 90 4.1. SCSI Concepts ............................................... 32 91 4.2. iSCSI Concepts and Functional Overview ...................... 33 92 4.2.1. Layers and Sessions ..................................... 34 93 4.2.2. Ordering and iSCSI Numbering ............................ 34 94 4.2.2.1. Command Numbering and Acknowledging ..................35 95 4.2.2.2. Response/Status Numbering and Acknowledging ..........39 96 4.2.2.3. Response Ordering ....................................40 97 4.2.2.3.1. Need for Response Ordering .......................40 98 4.2.2.3.2. Response Ordering Model Description ..............40 99 4.2.2.3.3. iSCSI Semantics with the Interface Model .........41 100 4.2.2.3.4. Current List of Fenced Response Use Cases ........41 101 4.2.2.4. Data Sequencing ......................................43 102 4.2.3. iSCSI Task Management ................................... 43 103 4.2.3.1. Task Management Overview .............................43 104 4.2.3.2. Notion of Affected Tasks .............................44 105 4.2.3.3. Standard Multi-task Abort Semantics ..................44 106 4.2.3.4. FastAbort Multi-task Abort Semantics ................46 107 4.2.3.5. Affected Tasks Shared across Standard and FastAbort 108 Sessions .....................................................48 109 4.2.3.6. Rationale behind the FastAbort Semantics ............49 110 4.2.4. iSCSI Login .............................................50 111 4.2.5. iSCSI Full Feature Phase ................................52 112 4.2.5.1. Command Connection Allegiance .......................52 113 4.2.5.2. Data Transfer Overview ..............................53 114 4.2.5.3. Tags and Integrity Checks ...........................55 115 4.2.5.4. Task Management .....................................55 116 4.2.6. iSCSI Connection Termination ............................56 117 4.2.7. iSCSI Names .............................................56 118 4.2.7.1. iSCSI Name Properties ...............................57 119 4.2.7.2. iSCSI Name Encoding .................................59 120 4.2.7.3. iSCSI Name Structure ................................60 121 4.2.7.4. Type "iqn." (iSCSI Qualified Name) ..................61 122 4.2.7.5. Type "eui." (IEEE EUI-64 format) ....................63 123 4.2.7.6. Type "naa." - Network Address Authority .............64 124 4.2.8. Persistent State ........................................65 125 4.2.9. Message Synchronization and Steering ....................65 126 4.2.9.1. Sync/Steering and iSCSI PDU Length ..................66 127 4.3. iSCSI Session Types .........................................67 128 4.4. SCSI to iSCSI Concepts Mapping Model ........................67 129 4.4.1. iSCSI Architecture Model ................................68 130 4.4.2. SCSI Architecture Model .................................71 131 4.4.3. Consequences of the Model ...............................73 132 4.4.3.1. I_T Nexus State .....................................75 133 4.5. iSCSI UML Model .............................................75 134 4.6. Request/Response Summary ....................................78 135 4.6.1. Request/Response Types Carrying SCSI Payload ............78 136 4.6.1.1. SCSI-Command ........................................78 137 4.6.1.2. SCSI-Response .......................................79 138 4.6.1.3. Task Management Function Request ....................79 139 4.6.1.4. Task Management Function Response ...................80 140 4.6.1.5. SCSI Data-out and SCSI Data-in ......................80 141 4.6.1.6. Ready To Transfer (R2T) .............................81 143 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload ......82 144 4.6.2.1. Asynchronous Message ................................82 145 4.6.3. Requests/Responses Carrying iSCSI Only Payload ..........82 146 4.6.3.1. Text Request and Text Response ......................82 147 4.6.3.2. Login Request and Login Response ....................83 148 4.6.3.3. Logout Request and Response .........................84 149 4.6.3.4. SNACK Request .......................................84 150 4.6.3.5. Reject ..............................................84 151 4.6.3.6. NOP-Out Request and NOP-In Response .................85 152 5. SCSI Mode Parameters for iSCSI.................................. 86 154 6. Login and Full Feature Phase Negotiation........................ 87 155 6.1. Text Format ................................................. 88 156 6.2. Text Mode Negotiation ....................................... 93 157 6.2.1. List negotiations ....................................... 97 158 6.2.2. Simple-value Negotiations ............................... 98 159 6.3. Login Phase ................................................. 99 160 6.3.1. Login Phase Start ...................................... 102 161 6.3.2. iSCSI Security Negotiation ............................. 105 162 6.3.3. Operational Parameter Negotiation During the Login Phase 106 163 6.3.4. Connection Reinstatement ............................... 107 164 6.3.5. Session Reinstatement, Closure, and Timeout ............ 107 165 6.3.5.1. Loss of Nexus Notification .......................... 108 166 6.3.6. Session Continuation and Failure ....................... 109 167 6.4. Operational Parameter Negotiation Outside the Login Phase .. 109 168 7. iSCSI Error Handling and Recovery.............................. 111 169 7.1. Overview .................................................. 111 170 7.1.1. Background ............................................ 111 171 7.1.2. Goals ................................................. 111 172 7.1.3. Protocol Features and State Expectations .............. 112 173 7.1.4. Recovery Classes ...................................... 113 174 7.1.4.1. Recovery Within-command ........................... 114 175 7.1.4.2. Recovery Within-connection ........................ 115 176 7.1.4.3. Connection Recovery ............................... 116 177 7.1.4.4. Session Recovery .................................. 117 179 7.1.5. Error Recovery Hierarchy .............................. 117 180 7.2. Retry and Reassign in Recovery ............................ 119 181 7.2.1. Usage of Retry ........................................ 120 182 7.2.2. Allegiance Reassignment ............................... 120 183 7.3. Usage Of Reject PDU in Recovery ........................... 122 184 7.4. Error Recovery Considerations for Discovery Sessions ...... 122 185 7.4.1. ErrorRecoveryLevel for Discovery Sessions ............. 122 186 7.4.2. Reinstatement Semantics for Discovery Sessions ........ 123 187 7.4.2.1. Unnamed Discovery Sessions ........................ 124 188 7.4.2.2. Named Discovery Session ........................... 124 189 7.4.3. Target PDUs During Discovery .......................... 124 190 7.5. Connection Timeout Management ............................. 125 191 7.5.1. Timeouts on Transport Exception Events ................ 125 192 7.5.2. Timeouts on Planned Decommissioning ................... 125 193 7.6. Implicit Termination of Tasks ............................. 126 194 7.7. Format Errors ............................................. 127 195 7.8. Digest Errors ............................................. 127 196 7.9. Sequence Errors ........................................... 129 197 7.10. Message Error Checking ................................... 130 198 7.11. SCSI Timeouts ............................................ 130 199 7.12. Negotiation Failures ..................................... 131 200 7.13. Protocol Errors .......................................... 132 201 7.14. Connection Failures ...................................... 132 202 7.15. Session Errors ........................................... 133 203 8. State Transitions.............................................. 135 204 8.1. Standard Connection State Diagrams ........................ 135 205 8.1.1. State Descriptions for Initiators and Targets ......... 135 206 8.1.2. State Transition Descriptions for Initiators and Targets 136 207 8.1.3. Standard Connection State Diagram for an Initiator .... 140 208 8.1.4. Standard Connection State Diagram for a Target ........ 142 209 8.2. Connection Cleanup State Diagram for Initiators and Targets 144 210 8.2.1. State Descriptions for Initiators and Targets ......... 146 211 8.2.2. State Transition Descriptions for Initiators and Targets 147 212 8.3. Session State Diagrams .................................... 149 213 8.3.1. Session State Diagram for an Initiator ................ 149 214 8.3.2. Session State Diagram for a Target ..................... 150 215 8.3.3. State Descriptions for Initiators and Targets .......... 151 216 8.3.4. State Transition Descriptions for Initiators and Targets 152 217 9. Security Considerations........................................ 154 218 9.1. iSCSI Security Mechanisms ................................. 154 219 9.2. In-band Initiator-Target Authentication ................... 155 220 9.2.1. CHAP Considerations ................................... 156 221 9.2.2. SRP Considerations .................................... 158 222 9.3. IPsec ..................................................... 159 223 9.3.1. Data Integrity and Authentication ..................... 159 224 9.3.2. Confidentiality ....................................... 160 225 9.3.3. Policy, Security Associations, and Cryptographic Key 226 Management ................................................... 161 227 9.4. Security Considerations for the X#NodeArchitecture Key .... 163 228 10. Notes to Implementers......................................... 166 229 10.1. Multiple Network Adapters ................................. 166 230 10.1.1. Conservative Reuse of ISIDs ........................... 166 231 10.1.2. iSCSI Name, ISID, and TPGT Use ........................ 167 232 10.2. Autosense and Auto Contingent Allegiance (ACA) ............ 169 233 10.3. iSCSI Timeouts ............................................ 169 234 10.4. Command Retry and Cleaning Old Command Instances .......... 170 235 10.5. Synch and Steering Layer and Performance .................. 171 236 10.6. Considerations for State-dependent Devices and Long-lasting 237 SCSI Operations ................................................. 171 238 10.6.1. Determining the Proper ErrorRecoveryLevel ............. 172 239 10.7. Multi-task Abort Implementation Considerations ............ 173 240 11. iSCSI PDU Formats............................................. 174 241 11.1. iSCSI PDU Length and Padding ............................. 174 242 11.2. PDU Template, Header, and Opcodes ........................ 174 243 11.2.1. Basic Header Segment (BHS) ........................... 175 244 11.2.1.1. I ................................................ 176 245 11.2.1.2. Opcode ........................................... 176 246 11.2.1.3. Final (F) bit .................................... 178 247 11.2.1.4. Opcode-specific Fields ........................... 178 248 11.2.1.5. TotalAHSLength ................................... 178 249 11.2.1.6. DataSegmentLength ................................ 178 250 11.2.1.7. LUN .............................................. 178 251 11.2.1.8. Initiator Task Tag ............................... 179 252 11.2.2. Additional Header Segment (AHS) ...................... 179 253 11.2.2.1. AHSType .......................................... 179 254 11.2.2.2. AHSLength ........................................ 180 255 11.2.2.3. Extended CDB AHS ................................. 180 256 11.2.2.4. Bidirectional Expected Read-Data Length AHS ...... 180 257 11.2.3. Header Digest and Data Digest ........................ 181 258 11.2.4. Data Segment ......................................... 181 259 11.3. SCSI Command ............................................. 181 260 11.3.1. Flags and Task Attributes (byte 1) ................... 182 261 11.3.2. CmdSN - Command Sequence Number ...................... 183 262 11.3.3. ExpStatSN ............................................ 184 263 11.3.4. Expected Data Transfer Length ........................ 184 264 11.3.5. CDB - SCSI Command Descriptor Block .................. 185 265 11.3.6. Data Segment - Command Data .......................... 185 266 11.4. SCSI Response ............................................ 185 267 11.4.1. Flags (byte 1) ....................................... 186 268 11.4.2. Status ............................................... 187 269 11.4.3. Response ............................................. 188 270 11.4.4. SNACK Tag ............................................ 189 271 11.4.5. Residual Count ....................................... 189 272 11.4.5.1. Field Semantics .................................. 189 273 11.4.5.2. Residuals Concepts Overview ...................... 190 274 11.4.5.3. SCSI REPORT LUNS and Residual Overflow ........... 190 275 11.4.6. Bidirectional Read Residual Count .................... 192 276 11.4.7. Data Segment - Sense and Response Data Segment ....... 192 277 11.4.7.1. SenseLength ...................................... 193 278 11.4.7.2. Sense Data ....................................... 193 279 11.4.8. ExpDataSN ............................................ 194 280 11.4.9. StatSN - Status Sequence Number ...................... 194 281 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator .. 195 282 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator ........ 195 283 11.5. Task Management Function Request ......................... 196 284 11.5.1. Function ............................................. 196 285 11.5.2. TotalAHSLength and DataSegmentLength ................. 200 286 11.5.3. LUN .................................................. 200 287 11.5.4. Referenced Task Tag .................................. 200 288 11.5.5. RefCmdSN ............................................. 200 289 11.5.6. ExpDataSN ............................................ 201 290 11.6. Task Management Function Response ........................ 201 291 11.6.1. Response ............................................. 202 292 11.6.2. TotalAHSLength and DataSegmentLength ................. 204 293 11.7. SCSI Data-out & SCSI Data-in ............................. 204 294 11.7.1. F (Final) Bit ........................................ 207 295 11.7.2. A (Acknowledge) bit .................................. 207 296 11.7.3. Flags (byte 1) ....................................... 208 297 11.7.4. Target Transfer Tag and LUN .......................... 209 298 11.7.5. DataSN ............................................... 209 299 11.7.6. Buffer Offset ........................................ 209 300 11.7.7. DataSegmentLength .................................... 210 301 11.8. Ready To Transfer (R2T) .................................. 211 302 11.8.1. TotalAHSLength and DataSegmentLength ................. 213 303 11.8.2. R2TSN ................................................ 213 304 11.8.3. StatSN ............................................... 213 305 11.8.4. Desired Data Transfer Length and Buffer Offset ....... 213 306 11.8.5. Target Transfer Tag .................................. 213 307 11.9. Asynchronous Message ..................................... 214 308 11.9.1. AsyncEvent ........................................... 216 309 11.9.2. AsyncVCode ........................................... 219 310 11.9.3. LUN .................................................. 219 311 11.9.4. Sense Data and iSCSI Event Data ...................... 219 312 11.9.4.1. SenseLength ...................................... 219 313 11.10. Text Request ............................................ 220 314 11.10.1. F (Final) Bit ....................................... 221 315 11.10.2. C (Continue) Bit .................................... 221 316 11.10.3. Initiator Task Tag .................................. 221 317 11.10.4. Target Transfer Tag ................................. 221 318 11.10.5. Text ................................................ 222 319 11.11. Text Response ........................................... 223 320 11.11.1. F (Final) Bit ....................................... 224 321 11.11.2. C (Continue) Bit .................................... 225 322 11.11.3. Initiator Task Tag .................................. 225 323 11.11.4. Target Transfer Tag ................................. 225 324 11.11.5. StatSN .............................................. 226 325 11.11.6. Text Response Data .................................. 226 326 11.12. Login Request ........................................... 226 327 11.12.1. T (Transit) Bit ..................................... 227 328 11.12.2. C (Continue) Bit .................................... 228 329 11.12.3. CSG and NSG ......................................... 228 330 11.12.4. Version ............................................. 228 331 11.12.4.1. Version-max ..................................... 228 332 11.12.4.2. Version-min ..................................... 229 333 11.12.5. ISID ................................................ 229 334 11.12.6. TSIH ................................................ 231 335 11.12.7. Connection ID - CID ................................. 231 336 11.12.8. CmdSN ............................................... 231 337 11.12.9. ExpStatSN ........................................... 232 338 11.12.10. Login Parameters ................................... 232 339 11.13. Login Response .......................................... 233 340 11.13.1. Version-max ......................................... 233 341 11.13.2. Version-active ...................................... 234 342 11.13.3. TSIH ................................................ 234 343 11.13.4. StatSN .............................................. 234 344 11.13.5. Status-Class and Status-Detail ...................... 235 345 11.13.6. T (Transit) bit ..................................... 238 346 11.13.7. C (Continue) Bit .................................... 239 347 11.13.8. Login Parameters .................................... 239 348 11.14. Logout Request .......................................... 239 349 11.14.1. Reason Code ......................................... 242 350 11.14.2. TotalAHSLength and DataSegmentLength ................ 243 351 11.14.3. CID ................................................. 243 352 11.14.4. ExpStatSN ........................................... 243 353 11.14.5. Implicit termination of tasks ....................... 243 354 11.15. Logout Response ......................................... 244 355 11.15.1. Response ............................................ 245 356 11.15.2. TotalAHSLength and DataSegmentLength ................ 246 357 11.15.3. Time2Wait ........................................... 246 358 11.15.4. Time2Retain ......................................... 246 359 11.16. SNACK Request ........................................... 248 360 11.16.1. Type ................................................ 249 361 11.16.2. Data Acknowledgement ................................ 250 362 11.16.3. Resegmentation ...................................... 250 363 11.16.4. Initiator Task Tag .................................. 251 364 11.16.5. Target Transfer Tag or SNACK Tag .................... 251 365 11.16.6. BegRun .............................................. 252 366 11.16.7. RunLength ........................................... 252 367 11.17. Reject .................................................. 253 368 11.17.1. Reason .............................................. 254 369 11.17.2. DataSN/R2TSN ........................................ 255 370 11.17.3. StatSN, ExpCmdSN and MaxCmdSN ....................... 255 371 11.17.4. Complete Header of Bad PDU .......................... 256 372 11.18. NOP-Out ................................................. 256 373 11.18.1. Initiator Task Tag .................................. 257 374 11.18.2. Target Transfer Tag ................................. 257 375 11.18.3. Ping Data ........................................... 258 376 11.19. NOP-In .................................................. 259 377 11.19.1. Target Transfer Tag ................................. 260 378 11.19.2. StatSN .............................................. 260 379 11.19.3. LUN ................................................. 260 380 12. iSCSI Security Text Keys and Authentication Methods........... 261 381 12.1. AuthMethod ............................................... 261 382 12.1.1. Kerberos ............................................. 263 383 12.1.2. Secure Remote Password (SRP) ......................... 264 384 12.1.3. Challenge Handshake Authentication Protocol (CHAP) ... 265 385 13. Login/Text Operational Text Keys.............................. 268 386 13.1. HeaderDigest and DataDigest ............................ 268 387 13.2. MaxConnections ......................................... 271 388 13.3. SendTargets ............................................ 271 389 13.4. TargetName ............................................. 272 390 13.5. InitiatorName .......................................... 272 391 13.6. TargetAlias ..............................................273 392 13.7. InitiatorAlias ...........................................273 393 13.8. TargetAddress ............................................274 394 13.9. TargetPortalGroupTag .....................................275 395 13.10. InitialR2T ..............................................276 396 13.11. ImmediateData ...........................................276 397 13.12. MaxRecvDataSegmentLength ................................277 398 13.13. MaxBurstLength ..........................................278 399 13.14. FirstBurstLength ........................................278 400 13.15. DefaultTime2Wait ........................................279 401 13.16. DefaultTime2Retain ......................................279 402 13.17. MaxOutstandingR2T .......................................280 403 13.18. DataPDUInOrder ..........................................280 404 13.19. DataSequenceInOrder .....................................281 405 13.20. ErrorRecoveryLevel ......................................282 406 13.21. SessionType .............................................282 407 13.22. The Private or Public Extension Key Format ..............283 408 13.23. Task Reporting ..........................................283 409 13.24. iSCSIProtocolLevel Negotiation ..........................284 410 13.25. Obsoleted Keys ..........................................285 411 13.26. X#NodeArchitecture ......................................285 412 13.26.1. Definition ..........................................285 413 13.26.2. Implementation Requirements .........................286 414 14. IANA Considerations..........................................287 416 Appendix A. Examples ............................................293 417 Read Operation Example .........................................293 418 Write Operation Example ........................................294 419 R2TSN/DataSN Use Examples ......................................294 420 CRC Examples ...................................................298 421 Appendix B. Login Phase Examples ................................300 423 Appendix C. SendTargets Operation ...............................310 425 Appendix D. Algorithmic Presentation of Error Recovery Classes ..315 426 D.2.1. Procedure Descriptions ................................318 427 Appendix E. Clearing Effects of Various Events on Targets .......334 428 1. Introduction 430 The Small Computer Systems Interface (SCSI) is a popular family of 431 protocols for communicating with I/O devices, especially storage 432 devices. SCSI is a client-server architecture. Clients of a SCSI 433 interface are called "initiators". Initiators issue SCSI 434 "commands" to request services from components, logical units of a 435 server known as a "target". A "SCSI transport" maps the client- 436 server SCSI protocol to a specific interconnect. An Initiator is 437 one endpoint of a SCSI transport and a target is the other 438 endpoint. 440 The SCSI protocol has been mapped over various transports, 441 including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre 442 Channel. These transports are I/O specific and have limited 443 distance capabilities. 445 The iSCSI protocol defined in this document describes a means of 446 transporting of the SCSI packets over TCP/IP, providing for an 447 interoperable solution which can take advantage of existing 448 Internet infrastructure, Internet management facilities and 449 address distance limitations. 451 2. Definitions, Acronyms, and Document Summary 453 2.1. Definitions 455 - Alias: An alias string can also be associated with an iSCSI 456 Node. The alias allows an organization to associate a user- 457 friendly string with the iSCSI Name. However, the alias string is 458 not a substitute for the iSCSI Name. 460 - CID (Connection ID): Connections within a session are identified 461 by a connection ID. It is a unique ID for this connection within 462 the session for the initiator. It is generated by the initiator 463 and presented to the target during login requests and during 464 logouts that close connections. 466 - Connection: A connection is a TCP connection. Communication 467 between the initiator and target occurs over one or more TCP 468 connections. The TCP connections carry control messages, SCSI 469 commands, parameters, and data within iSCSI Protocol Data Units 470 (iSCSI PDUs). 472 - I/O Buffer:A buffer that is used in a SCSI Read or Write 473 operation so SCSI data may be sent from or received into that 474 buffer. For a read or write data transfer to take place for a 475 task, an I/O Buffer is required on the initiator and at least one 476 is required on the 477 target. 479 - INCITS: INCITS stands for InterNational Committee of Information 480 Technology Standards. The INCITS has a broad standardization scope 481 within the field of Information and Communications Technologies 482 (ICT), encompassing storage, processing, transfer, display, 483 management, organization, and retrieval of information. INCITS 484 serves as ANSI's Technical Advisory Group for the ISO/IEC Joint 485 Technical Committee 1 (JTC 1). See http://www.incits.org. 487 - InfiniBand: An I/O architecture originally intended to replace 488 PCI and to address high performance server interconnectivity [IB]. 490 - iSCSI Device: A SCSI Device using an iSCSI service delivery 491 subsystem. Service Delivery Subsystem is defined by [SAM2] as a 492 transport mechanism for SCSI commands and responses. 494 - iSCSI Initiator Name: The iSCSI Initiator Name specifies the 495 worldwide unique name of the initiator. 497 - iSCSI Initiator Node: The "initiator" device. The word 498 "initiator" has been appropriately qualified as either a port or a 499 device in the rest of the document when the context is ambiguous. 500 All unqualified usages of "initiator" refer to an initiator port 501 (or device) depending on the context. 503 - iSCSI Layer: This layer builds/receives iSCSI PDUs and 504 relays/receives them to/from one or more TCP connections that form 505 an initiator-target "session". 507 - iSCSI Name: The name of an iSCSI initiator or iSCSI target. 509 - iSCSI Node: The iSCSI Node represents a single iSCSI initiator 510 or iSCSI target or a single instance of each. There are one or 511 more iSCSI Nodes within a Network Entity. The iSCSI Node is 512 accessible via one or more Network Portals. An iSCSI Node is 513 identified by its iSCSI Name. The separation of the iSCSI Name 514 from the addresses used by and for the iSCSI Node allows multiple 515 iSCSI nodes to use the same address, and the same iSCSI node to 516 use multiple addresses. 518 - iSCSI Target Name: The iSCSI Target Name specifies the worldwide 519 unique name of the target. 521 - iSCSI Target Node: The "target" device. The word "target" has 522 been appropriately qualified as either a port or a device in the 523 rest of the document when the context is ambiguous. All 524 unqualified usages of "target" refer to a target port (or device) 525 depending on the context. 527 - iSCSI Task: An iSCSI task is an iSCSI request for which a 528 response is expected. 530 - iSCSI Transfer Direction: The iSCSI transfer direction is 531 defined with regard to the initiator. Outbound or outgoing 532 transfers are transfers from the initiator to the target, while 533 inbound or incoming transfers are from the target to the 534 initiator. 536 - ISID: The initiator part of the Session Identifier. It is 537 explicitly specified by the initiator during Login. 539 - I_T nexus: According to [SAM2], the I_T nexus is a relationship 540 between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, 541 this relationship is a session, defined as a relationship between 542 an iSCSI Initiator's end of the session (SCSI Initiator Port) and 543 the iSCSI Target's Portal Group. The I_T nexus can be identified 544 by the conjunction of the SCSI port names; that is, the I_T nexus 545 identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI 546 Target Name + ',t,'+ Portal Group Tag). 548 - NAA: Network Address Authority, a naming format defined by the 549 INCITS T11 Fibre Channel protocols [FC-FS]. 551 - Network Entity: The Network Entity represents a device or 552 gateway that is accessible from the IP network. A Network Entity 553 must have one or more Network Portals, each of which can be used 554 to gain access to the IP network by some iSCSI Nodes contained in 555 that Network Entity. 557 - Network Portal: The Network Portal is a component of a Network 558 Entity that has a TCP/IP network address and that may be used by 559 an iSCSI Node within that Network Entity for the connection(s) 560 within one of its iSCSI sessions. A Network Portal in an initiator 561 is identified by its IP address. A Network Portal in a target is 562 identified by its IP address and its listening TCP port. 564 - Originator: In a negotiation or exchange, the party that 565 initiates the negotiation or exchange. 567 - PDU (Protocol Data Unit): The initiator and target divide their 568 communications into messages. The term "iSCSI protocol data unit" 569 (iSCSI PDU) is used for these messages. 571 - Portal Groups: iSCSI supports multiple connections within the 572 same session; some implementations will have the ability to 573 combine connections in a session across multiple Network Portals. 575 A Portal Group defines a set of Network Portals within an iSCSI 576 Network Entity that collectively supports the capability of 577 coordinating a session with connections spanning these portals. 578 Not all Network Portals within a Portal Group need participate in 579 every session connected through that Portal Group. One or more 580 Portal Groups may provide access to an iSCSI Node. Each Network 581 Portal, as utilized by a given iSCSI Node, belongs to exactly one 582 portal group within that node. 584 - Portal Group Tag: This 16-bit quantity identifies a Portal Group 585 within an iSCSI Node. All Network Portals with the same portal 586 group tag in the context of a given iSCSI Node are in the same 587 Portal Group. 589 - Recovery R2T: An R2T generated by a target upon detecting the 590 loss of one or more Data-Out PDUs through one of the following 591 means: a digest error, a sequence error, or a sequence reception 592 timeout. A recovery R2T carries the next unused R2TSN, but 593 requests all or part of the data burst that an earlier R2T (with a 594 lower R2TSN) had already requested. 596 - Responder: In a negotiation or exchange, the party that responds 597 to the originator of the negotiation or exchange. 599 - SAS: Serial Attached SCSI. The Serial Attached SCSI (SAS) 600 standard 601 contains both a physical layer compatible with Serial ATA, and 602 protocols for transporting SCSI commands to SAS devices and ATA 603 commands to SATA devices [SAS]. 605 - SCSI Device: This is the SAM2 term for an entity that contains 606 one or more SCSI ports that are connected to a service delivery 607 subsystem and supports a SCSI application protocol. For example, a 608 SCSI Initiator Device contains one or more SCSI Initiator Ports 609 and zero or more application clients. A Target Device contains one 610 or more SCSI Target Ports and one or more device servers and 611 associated logical units. For iSCSI, the SCSI Device is the 612 component within an iSCSI Node that provides the SCSI 613 functionality. As such, there can be, at most, one SCSI Device 614 within a given iSCSI Node. Access to the SCSI Device can only be 615 achieved in an iSCSI normal operational session. The SCSI Device 616 Name is defined to be the iSCSI Name of the node. 618 - SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor 619 Blocks) and relays/receives them with the remaining command 620 execute [SAM2] parameters to/from the iSCSI Layer. 622 - Session: The group of TCP connections that link an initiator 623 with a target form a session (loosely equivalent to a SCSI I-T 624 nexus). TCP connections can be added and removed from a session. 625 Across all connections within a session, an initiator sees one and 626 the same target. 628 - SCSI Initiator Port: This maps to the endpoint of an iSCSI 629 normal operational session. An iSCSI normal operational session is 630 negotiated through the login process between an iSCSI initiator 631 node and an iSCSI target node. At successful completion of this 632 process, a SCSI Initiator Port is created within the SCSI 633 Initiator Device. The SCSI Initiator Port Name and SCSI Initiator 634 Port Identifier are both defined to be the iSCSI Initiator Name 635 together with (a) a label that identifies it as an initiator port 636 name/identifier and (b) the ISID portion of the session 637 identifier. 639 - SCSI Port: This is the SAM2 term for an entity in a SCSI Device 640 that provides the SCSI functionality to interface with a service 641 delivery subsystem. For iSCSI, the definition of the SCSI 642 Initiator Port and the SCSI Target Port are different. 644 - SCSI Port Name: A name made up as UTF-8 characters and includes 645 the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag. 647 - SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 648 aggregate data length of the data that the SCSI layer logically 649 "presents" to the iSCSI layer for a Data-In or Data-Out transfer 650 in the context of a SCSI task. For a bidirectional task, there are 651 two SPDTL values -- one for Data-In and one for Data-Out. Note 652 that the notion of "presenting" includes immediate data per the 653 data transfer model in [SAM2], and excludes overlapping data 654 transfers, if any, requested by the SCSI layer. 656 - SCSI Target Port: This maps to an iSCSI Target Portal Group. 658 - SCSI Target Port Name and SCSI Target Port Identifier: These are 659 both defined to be the iSCSI Target Name together with (a) a label 660 that identifies it as a target port name/identifier and (b) the 661 portal group tag. 663 - SRP: SCSI RDMA Protocol. SRP defines a SCSI protocol mapping 664 onto the InfiniBand (tm) Architecture and/or functionally similar 665 Remote DMA-capable protocols [SRP]. 667 - SSID (Session ID): A session between an iSCSI initiator and an 668 iSCSI target is defined by a session ID that is a tuple composed 669 of an initiator part (ISID) and a target part (Target Portal Group 670 Tag). The ISID is explicitly specified by the initiator at session 671 establishment. The Target Portal Group Tag is implied by the 672 initiator through the selection of the TCP endpoint at connection 673 establishment. The TargetPortalGroupTag key must also be returned 674 by the target as a confimation during connection establishment. 676 - T10: A technical committee within INCITS that develops standards 677 and technical reports on I/O interfaces, particularly the series 678 of SCSI (Small Computer Systems Interface) standards. See 679 http://www.t10.org. 681 - T11: A technical committee within INCITS responsible for 682 standards development in the areas of Intelligent Peripheral 683 Interface (IPI), High-Performance Parallel Interface (HIPPI) and 684 Fibre Channel (FC). See http://www.t11.org. 686 - Target Portal Group Tag: A numerical identifier (16-bit) for an 687 iSCSI Target Portal Group. 689 - Third-party: A term used in this document to denote nexus 690 objects (I_T or I_T_L) and iSCSI sessions that reap the side 691 effects of actions that take place in the context of a separate 692 iSCSI session, while being third parties to the action that caused 693 the side effects. One example of a third-party session is an 694 iSCSI session hosting an I_T_L nexus to an LU that is reset with 695 an LU Reset TMF via a separate I_T nexus. 697 - TSIH (Target Session Identifying Handle): A target assigned tag 698 for a session with a specific named initiator. The target 699 generates it during session establishment. Other than defining it 700 as a 16 bit binary string, its internal format and content are not 701 defined by this protocol but for the all 0 value that is reserved 702 and used by the initiator to indicate a new session. It is given 703 to the target during additional connection establishment for the 704 same session. 706 2.2. Acronyms 708 Acronym Definition 709 -------------------------------------------------------------- 710 3DES Triple Data Encryption Standard 711 ACA Auto Contingent Allegiance 712 AEN Asynchronous Event Notification 713 AES Advanced Encryption Standard 714 AH Additional Header (not the IPsec AH!) 715 AHS Additional Header Segment 716 API Application Programming Interface 717 ASC Additional Sense Code 718 ASCII American Standard Code for Information Interchange 719 ASCQ Additional Sense Code Qualifier 720 BHS Basic Header Segment 721 CBC Cipher Block Chaining 722 CD Compact Disk 723 CDB Command Descriptor Block 724 CHAP Challenge Handshake Authentication Protocol 725 CID Connection ID 726 CO Connection Only 727 CRC Cyclic Redundancy Check 728 CRL Certificate Revocation List 729 CSG Current Stage 730 CSM Connection State Machine 731 DES Data Encryption Standard 732 DNS Domain Name Server 733 DOI Domain of Interpretation 734 DVD Digital Versatile Disk 735 EDTL Expected Data Transfer Length 736 ESP Encapsulating Security Payload 737 EUI Extended Unique Identifier 738 FFP Full Feature Phase 740 FFPO Full Feature Phase Only 741 Gbps Gigabits per Second 742 HBA Host Bus Adapter 743 HMAC Hashed Message Authentication Code 744 I_T Initiator_Target 745 I_T_L Initiator_Target_LUN 746 IANA Internet Assigned Numbers Authority 747 IB InfiniBand 748 ID Identifier 749 IDN Internationalized Domain Name 750 IEEE Institute of Electrical & Electronics Engineers 751 IETF Internet Engineering Task Force 752 IKE Internet Key Exchange 753 I/O Input-Output 754 IO Initialize Only 755 IP Internet Protocol 756 IPsec Internet Protocol Security 757 IPv4 Internet Protocol Version 4 758 IPv6 Internet Protocol Version 6 759 IQN iSCSI Qualified Name 760 iSCSI Internet SCSI 761 iSER iSCSI Extensions for RDMA 762 ISID Initiator Session ID 763 iSNS Internet Storage Name Service (see [RFC4171]) 764 ITN iSCSI Target Name 765 ITT Initiator Task Tag 766 KRB5 Kerberos V5 767 LFL Lower Functional Layer 768 LTDS Logical-Text-Data-Segment 769 LO Leading Only 770 LU Logical Unit 771 LUN Logical Unit Number 772 MAC Message Authentication Codes 773 NA Not Applicable 774 NAA Network Address Authority 775 NIC Network Interface Card 776 NOP No Operation 777 NSG Next Stage 778 OS Operating System 779 PDU Protocol Data Unit 780 PKI Public Key Infrastructure 781 R2T Ready To Transfer 782 R2TSN Ready To Transfer Sequence Number 783 RDMA Remote Direct Memory Access 784 RFC Request For Comments 785 SAM SCSI Architecture Model 786 SAM2 SCSI Architecture Model - 2 787 SAN Storage Area Network 788 SAS Serial Attached SCSI 789 SCSI Small Computer Systems Interface 790 SN Sequence Number 791 SNACK Selective Negative Acknowledgment - also 792 Sequence Number Acknowledgement for data 793 SPDTL SCSI-Presented Data Transfer Length 794 SPKM Simple Public-Key Mechanism 795 SRP Secure Remote Password, also SCSI RDMA Protocol 796 SSID Session ID 797 SW Session Wide 798 TCB Task Control Block 799 TCP Transmission Control Protocol 800 TMF Task Management Function 801 TPGT Target Portal Group Tag 802 TSIH Target Session Identifying Handle 803 TTT Target Transfer Tag 804 UA Unit Attention 805 UFL Upper Functional Layer 806 ULP Upper Level Protocol 807 URN Uniform Resource Names 808 UTF Universal Transformation Format 809 WG Working Group 811 2.3. Summary of Changes 813 1) Consolidated RFCs 3720, 3980, 4850 and 5048, and made the 814 necessary editorial changes 815 2) iSCSIProtocolLevel is specified as "1" in section 13.24, and 816 added a related normative reference to [iSCSI-SAM] draft 817 3) Markers and related keys were removed 818 4) SPKM authentication and related keys were removed 819 5) Added a new section 13.25 on responding to obsoleted keys 820 6) Have explicitly allowed initiator+target implementations 821 throughout the text 823 7) Clarified in section 4.2.7 that implementations SHOULD NOT 824 rely on SLP-based discovery 825 8) Added UML diagrams, and related conventions in section 3 826 9) FastAbort implementation is made a "SHOULD" requirement in 827 section 4.2.3.4 from the previous "MUST" requirement. 828 10) Clarified in section 6.2 that validity of NotUnderstood 829 response depends on iSCSIProtocolLevel 830 11) Required in section 4.2.7.1 that iSCSI Target Name must be 831 the same as iSCSI Initiator Name for SCSI (composite) devices 832 with both roles 833 12) Clarified in section 10.2 that ACA is a SHOULD requirement 834 only for iSCSI targets 835 13) Updated section 9.3 to require the following: MUST implement 836 IPsec, 2400-series RFCs (IPsec v2, IKEv1) and SHOULD implement 837 IPsec, 4300-series RFCs (IPsec v3, IKEv2). 839 2.4. Conventions 841 In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator 842 and target respectively. 844 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 845 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 846 in this document are to be interpreted as described in RFC 2119 847 [RFC2119]. 849 iSCSI messages - PDUs - are represented by diagrams as in the 850 following example: 852 Byte/ 0 | 1 | 2 | 3 853 | 854 / | | | 855 | 856 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 857 +---------------+---------------+---------------+---------------+ 858 0| Basic Header Segment (BHS) | 859 +---------------+---------------+---------------+---------------+ 860 ---------- 861 +| | 862 +---------------+---------------+---------------+---------------+ 863 The diagrams include byte and bit numbering. 865 The following representation and ordering rules are observed in 866 this document: 868 - Word Rule 870 - Half-word Rule 872 - Byte Rule 874 2.4.1. Word Rule 876 A word holds four consecutive bytes. Whenever a word has numeric 877 content, it is considered an unsigned number in base 2 positional 878 representation with the lowest numbered byte (e.g., byte 0) bit 0 879 representing 2**31 and bit 1 representing 2**30 through lowest 880 numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0. 882 Decimal and hexadecimal representation of word values map this 883 representation to decimal or hexadecimal positional notation. 885 2.4.2. Half-Word Rule 887 A half-word holds two consecutive bytes. Whenever a half-word has 888 numeric content it is considered an unsigned number in base 2 889 positional representation with the lowest numbered byte (e.g., 890 byte 0) bit 0 representing 2**15 and bit 1 representing 2**14 891 through lowest numbered byte + 1 (e.g., byte 1) bit 7 representing 892 2**0. 894 Decimal and hexadecimal representation of half-word values map 895 this representation to decimal or hexadecimal positional notation. 897 2.4.3. Byte Rule 899 For every PDU, bytes are sent and received in increasing numbered 900 order (network order). 902 Whenever a byte has numerical content it is considered an unsigned 903 number in base 2 positional representation with bit 0 representing 904 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0. 906 3. UML Conventions 908 3.1. UML Conventions Overview 910 The SCSI Architecture Model (SAM) uses class diagrams and object 911 diagrams with notation that is based on the Unified Modeling 912 Language [UML]. Therefore, this document also uses UML to model 913 the relationships for SCSI and iSCSI objects. 915 A treatise on the graphical notation used in UML is beyond the 916 scope of this document. However, given the use of ASCII drawing 917 for UML static class diagrams, a description of the notational 918 conventions used in this document is included in the remainder of 919 this section. 921 3.2. Multiplicity Notion 923 Not specified The number of instances of an attribute is not 924 specified. 926 1 One instance of the class or attribute exists. 928 0..* Zero or more instances of the class or attribute exist. 930 1..* One or more instances of the class or attribute exist. 932 0..1 Zero or one instance of the class or attribute exists. 934 n..m n to m instances of the class or attribute exist 935 (e.g., 2..8). 937 x, n..m Multiple disjoint instances of the class or 938 attribute exist (e.g., 2, 8..15). 940 3.3. Class Diagram Conventions 942 +--------------+ +--------------+ +--------------+ 943 | Class Name | | Class Name | | Class Name | 944 +--------------+ +--------------+ +--------------+ 945 | | | | 946 +--------------+ +--------------+ 947 | | 948 +--------------+ 949 The previous three diagrams are examples of a class with no 950 attributes and with no operations. 952 +-------------------+ +-------------------+ 953 | Class Name | | Class Name | 954 +-------------------+ +-------------------+ 955 | attribute 01[1] | | attribute 01[1] | 956 | attribute 02[1] | | attribute 02[1] | 957 +-------------------+ +-------------------+ 958 | | 959 +-------------------+ 960 The preceding two diagrams are examples of a class with attributes 961 and with no operations. 963 +------------------------+ 964 | Class Name | 965 +------------------------+ 966 | attribute 01[1..*] | 967 | attribute 02[1] | 968 +------------------------+ 969 | operation 01() | 970 | operation 02() | 971 +------------------------+ 972 The preceding diagram is an example of a class with attributes 973 that have a specified multiplicity and operations. 975 3.4. Class Diagram Notation for Associations 977 +-----------------+ 978 | Class A | 979 +-----------------+ association_name +-----------------+ 980 | attribute 01[1] |<------------------>| Class B | 981 | attribute 02[1] | 1..* 0..1 +-----------------+ 982 +-----------------+ | attribute 03[1] | 983 | operation 1() | +-----------------+ 984 +-----------------+ 985 The preceding diagram is an example where Class A knows about 986 Class B (i.e., read as "Class A association_name ClassB") and 987 Class B knows about Class A (i.e., read as "Class B 988 association_name Class A"). The use of association_name is 989 optional. The multiplicity notation (1..* and 0..1) indicates the 990 number of instances of the object. 992 +--------------------+ 993 | Class A | 994 +--------------------+ +--------------------+ 995 | attribute 01[1] |<-------------| Class B | 996 | attribute 02[1] | 1 0..1 +--------------------+ 997 +--------------------+ | attribute 03[1] | 998 | operation 1() | +--------------------+ 999 +--------------------+ 1000 The preceding diagram is an example where Class B knows about 1001 Class A (i.e., read as "Class B knows about Class A") but Class A 1002 does not know about Class B. 1004 +----------------------+ 1005 | Class A | 1006 +----------------------+ +--------------------+ 1007 | attribute 01[1] |----------->| Class B | 1008 | attribute 02[1] | 0..* 1 +--------------------+ 1009 +----------------------+ | attribute 03[1] | 1010 | operation 1() | +--------------------+ 1011 +----------------------+ 1012 The preceding diagram is an example where Class A knows about 1013 Class B (i.e., read as "Class A knows about Class B") but Class B 1014 does not know about Class A. 1016 3.5. Class Diagram Notation for Aggregations 1018 +---------------+ +--------------+ 1019 | Class whole |o------------| Class part | 1020 +---------------+ +--------------+ 1021 The preceding diagram is an example where Class whole is an 1022 aggregate that contains Class part and where Class part may 1023 continue to exist even if Class whole is removed (i.e., read as 1024 "the whole contains the part"). 1026 +---------------+ +--------------+ 1027 | Class whole |@------------| Class part | 1028 +---------------+ +--------------+ 1029 The preceding diagram is an example where Class whole is an 1030 aggregate that contains Class part where Class part shall only 1031 belong to one Class whole, and the Class part shall not continue 1032 to exist if the Class whole is removed (i.e., read as "the whole 1033 contains the part"). 1035 +-------------+ 1036 | | 1037 +-------------+ 1038 | | 1039 + =(a)= + 1040 | | 1041 The preceding diagram is an example where there is a constraint 1042 between the associations where the (a) footnote describes the 1043 constraint. 1045 3.6. Class Diagram Notation for Generalizations 1047 +---------------+ 1048 | Superclass | 1049 +-------^-------+ 1050 /_\ 1051 | 1052 +---------------+ 1053 | Subclass | 1054 +---------------+ 1055 The preceding diagram is an example where the subclass is a kind 1056 of superclass. A subclass shares all the attributes and 1057 operations of the superclass (i.e., the subclass inherits from the 1058 superclass). 1060 4. Overview 1062 4.1. SCSI Concepts 1064 The SCSI Architecture Model-2 [SAM2] describes in detail the 1065 architecture of the SCSI family of I/O protocols. This section 1066 provides a brief background of the SCSI architecture and is 1067 intended to familiarize readers with its terminology. 1069 At the highest level, SCSI is a family of interfaces for 1070 requesting services from I/O devices, including hard drives, tape 1071 drives, CD and DVD drives, printers, and scanners. In SCSI 1072 terminology, an individual I/O device is called a "logical unit" 1073 (LU). 1075 SCSI is a client-server architecture. Clients of a SCSI interface 1076 are called "initiators". Initiators issue SCSI "commands" to 1077 request services from components, logical units, of a server known 1078 as a "target". The "device server" on the logical unit accepts 1079 SCSI commands and processes them. 1081 A "SCSI transport" maps the client-server SCSI protocol to a 1082 specific interconnect. Initiator is one endpoint of a SCSI 1083 transport. The "target" is the other endpoint. A target can 1084 contain multiple Logical Units (LUs). Each Logical Unit has an 1085 address within a target called a Logical Unit Number (LUN). 1087 A SCSI task is a SCSI command or possibly a linked set of SCSI 1088 commands. Some LUs support multiple pending (queued) tasks, but 1089 the queue of tasks is managed by the logical unit. The target uses 1090 an initiator provided "task tag" to distinguish between tasks. 1091 Only one command in a task can be outstanding at any given time. 1093 Each SCSI command results in an optional data phase and a required 1094 response phase. In the data phase, information can travel from the 1095 initiator to target (e.g., WRITE), target to initiator (e.g., 1096 READ), or in both directions. In the response phase, the target 1097 returns the final status of the operation, including any errors. 1099 Command Descriptor Blocks (CDB) are the data structures used to 1100 contain the command parameters that an initiator sends to a 1102 target. The CDB content and structure is defined by [SAM2] and 1103 device-type specific SCSI standards. 1105 4.2. iSCSI Concepts and Functional Overview 1107 The iSCSI protocol is a mapping of the SCSI command, event and 1108 task management model (see [SAM2]) over the TCP protocol. SCSI 1109 commands are carried by iSCSI requests and SCSI responses and 1110 status are carried by iSCSI responses. iSCSI also uses the request 1111 response mechanism for iSCSI protocol mechanisms. 1113 For the remainder of this document, the terms "initiator" and 1114 "target" refer to "iSCSI initiator node" and "iSCSI target node", 1115 respectively (see iSCS) unless otherwise qualified. 1117 In keeping with similar protocols, the initiator and target divide 1118 their communications into messages. This document uses the term 1119 "iSCSI protocol data unit" (iSCSI PDU) for these messages. 1121 For performance reasons, iSCSI allows a "phase-collapse". A 1122 command and its associated data may be shipped together from 1123 initiator to target, and data and responses may be shipped 1124 together from targets. 1126 The iSCSI transfer direction is defined with respect to the 1127 initiator. Outbound or outgoing transfers are transfers from an 1128 initiator to a target, while inbound or incoming transfers are 1129 from a target to an initiator. 1131 An iSCSI task is an iSCSI request for which a response is 1132 expected. 1134 In this document "iSCSI request", "iSCSI command", request, or 1135 (unqualified) command have the same meaning. Also, unless 1136 otherwise specified, status, response, or numbered response have 1137 the same meaning. 1139 4.2.1. Layers and Sessions 1141 The following conceptual layering model is used to specify 1142 initiator and target actions and the way in which they relate to 1143 transmitted and received Protocol Data Units: 1145 the SCSI layer builds/receives SCSI CDBs (Command Descriptor 1146 Blocks) and passes/receives them with the remaining command 1147 execute parameters ([SAM2]) to/from 1148 the iSCSI layer that builds/receives iSCSI PDUs and 1149 relays/receives them to/from one or more TCP connections; 1150 the group of connections form an initiator-target 1151 "session". 1153 Communication between the initiator and target occurs over one or 1154 more TCP connections. The TCP connections carry control messages, 1155 SCSI commands, parameters, and data within iSCSI Protocol Data 1156 Units (iSCSI PDUs). The group of TCP connections that link an 1157 initiator with a target form a session (equivalent to a SCSI I_T 1158 nexus, see SCSI ). A session is defined by a session ID that is 1159 composed of an initiator part and a target part. TCP connections 1160 can be added and removed from a session. Each connection within a 1161 session is identified by a connection ID (CID). 1163 Across all connections within a session, an initiator sees one 1164 "target image". All target identifying elements, such as LUN, are 1165 the same. A target also sees one "initiator image" across all 1166 connections within a session. Initiator-identifying elements, such 1167 as the Initiator Task Tag, are global across the session 1168 regardless of the connection on which they are sent or received. 1170 iSCSI targets and initiators MUST support at least one TCP 1171 connection and MAY support several connections in a session. For 1172 error recovery purposes, targets and initiators that support a 1173 single active connection in a session SHOULD support two 1174 connections during recovery. 1176 4.2.2. Ordering and iSCSI Numbering 1178 iSCSI uses Command and Status numbering schemes and a Data 1179 sequencing scheme. 1181 Command numbering is session-wide and is used for ordered command 1182 delivery over multiple connections. It can also be used as a 1183 mechanism for command flow control over a session. 1185 Status numbering is per connection and is used to enable missing 1186 status detection and recovery in the presence of transient or 1187 permanent communication errors. 1189 Data sequencing is per command or part of a command (R2T-triggered 1190 sequence) and is used to detect missing data and/or R2T PDUs due 1191 to header digest errors. 1193 Typically, fields in the iSCSI PDUs communicate the Sequence 1194 Numbers between the initiator and target. During periods when 1195 traffic on a connection is unidirectional, iSCSI NOP-Out/In PDUs 1196 may be utilized to synchronize the command and status ordering 1197 counters of the target and initiator. 1199 The iSCSI session abstraction is equivalent to the SCSI I_T nexus, 1200 and the iSCSI session provides an ordered command delivery from 1201 the SCSI initiator to the SCSI target. For detailed design 1202 considerations that led to the iSCSI session model as it is 1203 defined here and how it relates the SCSI command ordering features 1204 defined in SCSI specifications to the iSCSI concepts see 1205 [RFC3783]. 1207 4.2.2.1. Command Numbering and Acknowledging 1209 iSCSI performs ordered command delivery within a session. All 1210 commands (initiator-to-target PDUs) in transit from the initiator 1211 to the target are numbered. 1213 iSCSI considers a task to be instantiated on the target in 1214 response to every request issued by the initiator. A set of task 1215 management operations including abort and reassign (see Section 1216 11.5"Task Management Function Request") may be performed on any 1217 iSCSI task. 1219 Some iSCSI tasks are SCSI tasks, and many SCSI activities are 1220 related to a SCSI task ([SAM2]). In all cases, the task is 1221 identified by the Initiator Task Tag for the life of the task. 1223 The command number is carried by the iSCSI PDU as CmdSN (Command- 1224 Sequence-Number). The numbering is session-wide. Outgoing iSCSI 1225 PDUs carry this number. The iSCSI initiator allocates CmdSNs with 1226 a 32-bit unsigned counter (modulo 2**32). Comparisons and 1227 arithmetic on CmdSN use Serial Number Arithmetic as defined in 1228 [RFC1982] where SERIAL_BITS = 32. 1230 Commands meant for immediate delivery are marked with an immediate 1231 delivery flag; they MUST also carry the current CmdSN. CmdSN does 1232 not advance after a command marked for immediate delivery is sent. 1234 Command numbering starts with the first login request on the first 1235 connection of a session (the leading login on the leading 1236 connection) and command numbers are incremented by 1 for every 1237 non-immediate command issued afterwards. 1239 If immediate delivery is used with task management commands, these 1240 commands may reach the target before the tasks on which they are 1241 supposed to act. However their CmdSN serves as a marker of their 1242 position in the stream of commands. The initiator and target must 1243 ensure that the task management commands act as specified by 1244 [SAM2]. For example, both commands and responses appear as if 1245 delivered in order. Whenever CmdSN for an outgoing PDU is not 1246 specified by an explicit rule, CmdSN will carry the current value 1247 of the local CmdSN variable (see later in this section). 1249 The means by which an implementation decides to mark a PDU for 1250 immediate delivery or by which iSCSI decides by itself to mark a 1251 PDU for immediate delivery are beyond the scope of this document. 1253 The number of commands used for immediate delivery is not limited 1254 and their delivery to execution is not acknowledged through the 1255 numbering scheme. Immediate commands MAY be rejected by the iSCSI 1256 target layer due to lack of resources. An iSCSI target MUST be 1257 able to handle at least one immediate task management command and 1258 one immediate non-task-management iSCSI command per connection at 1259 any time. 1261 In this document, delivery for execution means delivery to the 1262 SCSI execution engine or an iSCSI protocol specific execution 1263 engine (e.g., for text requests with public or private extension 1264 keys involving an execution component). With the exception of the 1265 commands marked for immediate delivery, the iSCSI target layer 1266 MUST deliver the commands for execution in the order specified by 1267 CmdSN. Commands marked for immediate delivery may be delivered by 1268 the iSCSI target layer for execution as soon as detected. iSCSI 1269 may avoid delivering some commands to the SCSI target layer if 1270 required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET 1271 Task Management request received before all the commands on which 1272 it was supposed to act). 1274 On any connection, the iSCSI initiator MUST send the commands in 1275 increasing order of CmdSN, except for commands that are 1276 retransmitted due to digest error recovery and connection 1277 recovery. 1279 For the numbering mechanism, the initiator and target maintain the 1280 following three variables for each session: 1282 - CmdSN - the current command Sequence Number, advanced by 1 1283 on each command shipped except for commands marked for 1284 immediate delivery. CmdSN always contains the number to be 1285 assigned to the next Command PDU. 1287 - ExpCmdSN - the next expected command by the target. The 1288 target acknowledges all commands up to, but not including, 1289 this number. The initiator treats all commands with CmdSN 1290 less than ExpCmdSN as acknowledged. The target iSCSI layer 1291 sets the ExpCmdSN to the largest non-immediate CmdSN that it 1292 can deliver for execution "plus 1" per [RFC1982]. There 1293 MUST NOT be any holes in the acknowledged CmdSN sequence. 1295 - MaxCmdSN - the maximum number to be shipped. The queuing 1296 capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN 1297 + 1. 1299 The initiator's ExpCmdSN and MaxCmdSN are derived from target-to- 1300 initiator PDU fields. Comparisons and arithmetic on ExpCmdSN and 1301 MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] 1302 where SERIAL_BITS = 32. 1304 The target MUST NOT transmit a MaxCmdSN that is less than 1305 ExpCmdSN-1. For non-immediate commands, the CmdSN field can take 1306 any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST 1307 silently ignore any non-immediate command outside of this range or 1308 non-immediate duplicates within the range. The CmdSN carried by 1309 immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. 1310 For example, if the initiator has previously sent a non-immediate 1311 command carrying the CmdSN equal to MaxCmdSN, the target window is 1312 closed. For group task management commands issued as immediate 1313 commands, CmdSN indicates the scope of the group action (e.g., on 1314 ABORT TASK SET indicates which commands are to be aborted). 1316 MaxCmdSN and ExpCmdSN fields are processed by the initiator as 1317 follows: 1319 -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in 1320 Serial Arithmetic Sense), they are both ignored. 1322 -If the PDU MaxCmdSN is greater than the local MaxCmdSN (in 1323 Serial Arithmetic Sense), it updates the local MaxCmdSN; 1324 otherwise, it is ignored. 1326 -If the PDU ExpCmdSN is greater than the local ExpCmdSN (in 1327 Serial Arithmetic Sense), it updates the local ExpCmdSN; 1328 otherwise, it is ignored. 1330 This sequence is required because updates may arrive out of order 1331 (e.g., the updates are sent on different TCP connections). 1333 iSCSI initiators and targets MUST support the command numbering 1334 scheme. 1336 A numbered iSCSI request will not change its allocated CmdSN, 1337 regardless of the number of times and circumstances in which it is 1338 reissued (see Section 7.2.1"Usage of Retry"). At the target, CmdSN 1339 is only relevant while the command has not created any state 1340 related to its execution (execution state); afterwards, CmdSN 1341 becomes irrelevant. Testing for the execution state (represented 1342 by identifying the Initiator Task Tag) MUST precede any other 1343 action at the target. If no execution state is found, it is 1344 followed by ordering and delivery. If an execution state is found, 1345 it is followed by delivery if it has not already been delivered. 1347 If an initiator issues a command retry for a command with CmdSN R 1348 on 1349 a connection when the session CmdSN value is Q, it MUST NOT 1350 advance the CmdSN past R + 2**31 -1 unless the connection is no 1351 longer operational (i.e., it has returned to the FREE state, see 1352 Section 8.1.3 "Standard Connection State Diagram for an 1353 Initiator"), the connection has been reinstated (see Section 6.3.4 1354 "Connection Reinstatement"), or a non-immediate command with CmdSN 1355 equal or greater than Q was issued subsequent to the command retry 1356 on the same connection and the reception of that command is 1357 acknowledged by the target (see Section 10.4"Command Retry and 1358 Cleaning Old Command Instances"). 1360 A target command response or Data-in PDU with status MUST NOT 1361 precede the command acknowledgement. However, the acknowledgement 1362 MAY be included in the response or the Data-in PDU. 1364 4.2.2.2. Response/Status Numbering and Acknowledging 1366 Responses in transit from the target to the initiator are 1367 numbered. The StatSN (Status Sequence Number) is used for this 1368 purpose. StatSN is a counter maintained per connection. ExpStatSN 1369 is used by the initiator to acknowledge status. The status 1370 sequence number space is 32-bit unsigned-integers and the 1371 arithmetic operations are the regular mod(2**32) arithmetic. 1373 Status numbering starts with the Login response to the first Login 1374 request of the connection. The Login response includes an initial 1375 value for status numbering (any initial value is valid). 1377 To enable command recovery, the target MAY maintain enough state 1378 information for data and status recovery after a connection 1379 failure. A target doing so can safely discard all of the state 1380 information maintained for recovery of a command after the 1381 delivery of the status for the command (numbered StatSN) is 1382 acknowledged through ExpStatSN. 1384 A large absolute difference between StatSN and ExpStatSN may 1385 indicate a failed connection. Initiators MUST undertake recovery 1386 actions if the difference is greater than an implementation 1387 defined constant that MUST NOT exceed 2**31-1. 1389 Initiators and Targets MUST support the response-numbering scheme. 1391 4.2.2.3. Response Ordering 1393 4.2.2.3.1. Need for Response Ordering 1395 Whenever an iSCSI session is composed of multiple connections, the 1396 Response PDUs (task responses or TMF responses) originating in 1397 the target SCSI layer are distributed onto the multiple 1398 connections by the target iSCSI layer according to iSCSI 1399 connection allegiance rules. This process generally may not 1400 preserve the ordering of the responses by the time they are 1401 delivered to the initiator SCSI layer. 1403 Since ordering is not expected across SCSI responses anyway, this 1404 approach works fine in the general case. However, to address the 1405 special cases where some ordering is desired by the SCSI layer, 1406 the following "Response Fence" semantics are defined with respect 1407 to handling SCSI response messages as they are handed off from the 1408 SCSI protocol layer to the iSCSI layer. 1410 4.2.2.3.2. Response Ordering Model Description 1412 The target SCSI protocol layer hands off the SCSI response 1413 messages to the target iSCSI layer by invoking the "Send Command 1414 Complete" protocol data service ([SAM2], clause 5.4.2) and "Task 1415 Management Function Executed" ([SAM2], clause 6.9) service. On 1416 receiving the SCSI response message, the iSCSI layer exhibits the 1417 Response Fence behavior for certain SCSI response messages 1418 (Section 4.2.2.3.4 describes the specific instances where the 1419 semantics must be realized). 1421 Whenever the Response Fence behavior is required for a SCSI 1422 response message, the target iSCSI layer MUST ensure that the 1423 following conditions are met in delivering the response message to 1424 the initiator iSCSI layer: 1426 Response with Response Fence MUST be delivered chronologically 1427 after all the "preceding" responses on the I_T_L nexus, if 1428 the preceding responses are delivered at all, to the 1429 initiator iSCSI layer. 1430 Response with Response Fence MUST be delivered chronologically 1431 prior to all the "following" responses on the I_T_L nexus. 1433 The "preceding" and "following" notions refer to the order of 1434 handoff of a response message from the target SCSI protocol layer 1435 to the target iSCSI layer. 1437 4.2.2.3.3. iSCSI Semantics with the Interface Model 1439 Whenever the TaskReporting key (Section 13.23"Task Reporting") is 1440 negotiated to ResponseFence or FastAbort for an iSCSI session and 1441 the Response Fence behavior is required for a SCSI response 1442 message, the target iSCSI layer MUST perform the actions described 1443 in this section for that session. 1445 If it is a single-connection session, no special processing is 1446 required. The standard SCSI Response PDU build and dispatch 1447 process happens. 1448 If it is a multi-connection session, the target iSCSI layer 1449 takes note of the last-sent and unacknowledged StatSN on 1450 each of the connections in the iSCSI session, and waits for 1451 an acknowledgement (NOP-In PDUs MAY be used to solicit 1452 acknowledgements as needed in order to accelerate this 1453 process) of each such StatSN to clear the fence. The SCSI 1454 response requiring Response Fence behavior MUST NOT be sent 1455 to the initiator before acknowledgements are received for 1456 each of the unacknowledged StatSNs. 1457 The target iSCSI layer must wait for an acknowledgement of the 1458 SCSI Response PDU that carried the SCSI response requiring 1459 the Response Fence behavior. The fence MUST be considered 1460 cleared only after receiving the acknowledgement. 1461 All further status processing for the LU is resumed only after 1462 clearing the fence. If any new responses for the I_T_L 1463 nexus are received from the SCSI layer before the fence is 1464 cleared, those Response PDUs MUST be held and queued at the 1465 iSCSI layer until the fence is cleared. 1467 4.2.2.3.4. Current List of Fenced Response Use Cases 1468 This section lists the fenced response use cases that iSCSI 1469 implementations MUST comply with. However, this is not an 1470 exhaustive enumeration. It is expected that as SCSI protocol 1471 specifications evolve, the specifications will specify when 1472 response fencing is required on a case-by-case basis. 1474 Whenever the TaskReporting key (Section 13.23) is negotiated to 1475 ResponseFence or FastAbort for an iSCSI session, the target iSCSI 1476 layer MUST assume that the Response Fence is required for the 1477 following SCSI completion messages: 1479 1. The first completion message carrying the UA after the 1480 multi-task abort on issuing and third-party sessions. See 1481 Section 4.2.3.2 for related TMF discussion. 1483 2. The TMF Response carrying the multi-task TMF Response on 1484 the issuing session. 1486 3. The completion message indicating ACA establishment on the 1487 issuing session. 1489 4. The first completion message carrying the ACA ACTIVE status 1490 after ACA establishment on issuing and third-party 1491 sessions. 1493 5. The TMF Response carrying the Clear ACA response on the 1494 issuing session. 1496 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 1497 command. 1499 Note: 1500 - Due to the absence of ACA-related fencing requirements in 1501 [RFC3720], initiator implementations SHOULD NOT use ACA on 1502 multi-connection iSCSI sessions with targets complying only 1503 with [RFC3720]. 1505 - Initiators that want to employ ACA on multi-connection iSCSI 1506 sessions SHOULD first assess response-fencing behavior via 1507 negotiating for ResponseFence or FastAbort values for the 1508 TaskReporting (Section 13.23) key. 1510 4.2.2.4. Data Sequencing 1512 Data and R2T PDUs transferred as part of some command execution 1513 MUST be sequenced. The DataSN field is used for data sequencing. 1514 For input (read) data PDUs, DataSN starts with 0 for the first 1515 data PDU of an input command and advances by 1 for each subsequent 1516 data PDU. For output data PDUs, DataSN starts with 0 for the first 1517 data PDU of a sequence (the initial unsolicited sequence or any 1518 data PDU sequence issued to satisfy an R2T) and advances by 1 for 1519 each subsequent data PDU. R2Ts are also sequenced per command. For 1520 example, the first R2T has an R2TSN of 0 and advances by 1 for 1521 each subsequent R2T. For bidirectional commands, the target uses 1522 the DataSN/R2TSN to sequence Data-In and R2T PDUs in one 1523 continuous sequence (undifferentiated). Unlike command and status, 1524 data PDUs and R2Ts are not acknowledged by a field in regular 1525 outgoing PDUs. Data-In PDUs can be acknowledged on demand by a 1526 special form of the SNACK PDU. Data and R2T PDUs are implicitly 1527 acknowledged by status for the command. The DataSN/R2TSN field 1528 enables the initiator to detect missing data or R2T PDUs. 1530 For any read or bidirectional command, a target MUST issue less 1531 than 2**32 combined R2T and Data-In PDUs. Any output data sequence 1532 MUST contain less than 2**32 Data-Out PDUs. 1534 4.2.3. iSCSI Task Management 1536 4.2.3.1. Task Management Overview 1538 iSCSI task management features allow an initiator to control the 1539 active iSCSI tasks on an operational iSCSI session that it has 1540 with an iSCSI target. Section 11.5 defines the task management 1541 function types that this specification defines - ABORT TASK, ABORT 1542 TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET 1543 WARM RESET, TARGET COLD RESET, and TASK REASSIGN. 1545 Out of these function types, ABORT TASK and TASK REASSIGN 1546 functions manage a single active task, whereas ABORT TASK SET, 1547 CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET and TARGET 1548 COLD RESET functions can each potentially affect multiple active 1549 tasks. 1551 4.2.3.2. Notion of Affected Tasks 1553 This section defines the notion of "affected tasks" in multi-task 1554 abort scenarios. Scope definitions in this section apply to both 1555 the Standard Multi-task Abort semantics (Section 4.2.3.3) and the 1556 FastAbort Multi-task Abort semantics behavior (Section 4.2.3.4). 1558 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 1559 identified by the LUN field in the ABORT TASK SET TMF Request PDU 1560 (Section 11.5). 1562 CLEAR TASK SET: All outstanding tasks in the task set for the LU 1563 identified by the LUN field in the CLEAR TASK SET TMF Request PDU. 1564 See [SPC3] for the definition of a "task set". 1566 LOGICAL UNIT RESET: All outstanding tasks from all initiators for 1567 the LU identified by the LUN field in the LOGICAL UNIT RESET 1568 Request PDU. 1570 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from 1571 all initiators across all LUs to which the TMF-issuing session has 1572 access on the SCSI target device hosting the iSCSI session. 1574 Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text 1575 is an iSCSI TMF Request PDU with the "Function" field set to 1576 "ABORT TASK SET" as defined in Section 11.5. Similar usage is 1577 employed for other scope descriptions. 1579 4.2.3.3. Standard Multi-task Abort Semantics 1581 All iSCSI implementations MUST support the protocol behavior 1582 defined in this section as the default behavior. The execution of 1583 ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM 1584 RESET, and TARGET COLD RESET TMF Requests consists of the 1585 following sequence of actions in the specified order on the 1586 specified party. 1588 The initiator iSCSI layer: 1589 a. MUST continue to respond to each TTT received for the 1590 affected tasks. 1591 b. SHOULD process any responses received for affected tasks in 1592 the normal fashion. This is acceptable because the 1593 responses are guaranteed to have been sent prior to the TMF 1594 response. 1595 c. SHOULD receive the TMF Response concluding all the tasks in 1596 the set of affected tasks unless the initiator has done 1597 something (e.g., LU reset, connection drop) that may 1598 prevent the TMF Response from being sent or received. The 1599 initiator MUST thus conclude all affected tasks as part of 1600 this step in either case, and MUST discard any TMF Response 1601 received after the affected tasks are concluded. 1603 The target iSCSI layer: 1604 a. MUST wait for responses on currently valid target-transfer 1605 tags of the affected tasks from the issuing initiator. MAY 1606 wait for responses on currently valid target-transfer tags 1607 of the affected tasks from third-party initiators. 1608 b. MUST wait (concurrent with the wait in Step a) for all 1609 commands of the affected tasks to be received based on the 1610 CmdSN ordering. SHOULD NOT wait for new commands on third- 1611 party affected sessions -- only the instantiated tasks have 1612 to be considered for the purpose of determining the 1613 affected tasks. In the case of target-scoped requests 1614 (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the 1615 commands that are not yet received on the issuing session 1616 in the command stream however can be considered to have 1617 been received with no command waiting period -- i.e., the 1618 entire CmdSN space up to the CmdSN of the task management 1619 function can be "plugged". 1620 c. MUST propagate the TMF request to and receive the response 1621 from the target SCSI layer. 1622 d. MUST provide the Response Fence behavior for the TMF 1623 Response on the issuing session as specified in Section 1624 4.2.2.3.2. 1625 e. MUST provide the Response Fence behavior on the first post- 1626 TMF Response on third-party sessions as specified in 1627 Section 4.2.2.3.3. If some tasks originate from non-iSCSI 1628 I_T_L nexuses, then the means by which the target ensures 1629 that all affected tasks have returned their status to the 1630 initiator are defined by the specific non-iSCSI transport 1631 protocol(s). 1633 Technically, the TMF servicing is complete in Step d. Data 1634 transfers corresponding to terminated tasks may however still be 1635 in progress on third-party iSCSI sessions even at the end of Step 1636 e. The TMF Response MUST NOT be sent by the target iSCSI layer 1637 before the end of Step d, and MAY be sent at the end of Step d 1638 despite these outstanding data transfers until after Step e. 1640 4.2.3.4. FastAbort Multi-task Abort Semantics 1642 Protocol behavior defined in this section SHOULD be implemented by 1643 all iSCSI implementations complying with this document. Protocol 1644 behavior defined in this section MUST be exhibited by iSCSI 1645 implementations on an iSCSI session when they negotiate the 1646 TaskReporting (Section 13.23) key to "FastAbort" on that session. 1647 The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT 1648 RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests 1649 consists of the following sequence of actions in the specified 1650 order on the specified party. 1652 The initiator iSCSI layer: 1653 a. MUST NOT send any more Data-Out PDUs for affected tasks on 1654 the issuing connection of the issuing iSCSI session once 1655 the TMF is sent to the target. 1656 b. SHOULD process any responses received for affected tasks in 1657 the normal fashion. This is acceptable because the 1658 responses are guaranteed to have been sent prior to the TMF 1659 response. 1660 c. MUST respond to each Async Message PDU with FAST_ABORT 1661 AsyncEvent as defined in Section 11.9. 1662 d. MUST treat the TMF response as terminating all affected 1663 tasks for which responses have not been received, and MUST 1664 discard any responses for affected tasks received after the 1665 TMF response is passed to the SCSI layer (although the 1666 semantics defined in this section ensure that such an out- 1667 of-order scenario will never happen with a compliant target 1668 implementation). 1670 The target iSCSI layer: 1671 a. MUST wait for all commands of the affected tasks to be 1672 received based on the CmdSN ordering on the issuing 1673 session. SHOULD NOT wait for new commands on third-party 1674 affected sessions - only the instantiated tasks have to be 1675 considered for the purpose of determining the affected 1676 tasks. In the case of target-scoped requests (i.e., TARGET 1677 WARM RESET and TARGET COLD RESET), all the commands that 1678 are not yet received on the issuing session in the command 1679 stream can be considered to have been received with no 1680 command waiting period -- i.e., the entire CmdSN space up 1681 to the CmdSN of the task management function can be 1682 "plugged". 1683 b. MUST propagate the TMF request to and receive the response 1684 from the target SCSI layer. 1685 c. MUST leave all active "affected TTTs" (i.e., active TTTs 1686 associated with affected tasks) valid. 1687 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 1688 (Section 11.9) on: 1689 i) each connection of each third-party session to 1690 which at least one affected task is allegiant if 1691 TaskReporting=FastAbort is operational on that third- 1692 party session, and, 1693 ii) each connection except the issuing connection of 1694 the issuing session that has at least one allegiant 1695 affected task. 1696 If there are multiple affected LUs (say, due to a target 1697 reset), then one Async Message PDU MUST be sent for each 1698 such LU on each connection that has at least one allegiant 1699 affected task. The LUN field in the Asynchronous Message PDU 1700 MUST be set to match the LUN for each such LU. 1701 e. MUST address the Response Fence flag on the TMF Response on 1702 the issuing session as defined in Section 4.2.2.3.3. 1703 f. MUST address the Response Fence flag on the first post-TMF 1704 Response on third-party sessions as defined in Section 1705 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L 1706 nexuses, then the means by which the target ensures that 1707 all affected tasks have returned their status to the 1708 initiator are defined by the specific non-iSCSI transport 1709 protocol(s). 1710 g. MUST free up the affected TTTs (and STags, if applicable) 1711 and the corresponding buffers, if any, once it receives 1712 each associated NOP-Out acknowledgement that the initiator 1713 generated in response to each Async Message. 1715 Technically, the TMF servicing is complete in Step e. Data 1716 transfers corresponding to terminated tasks may however still be 1717 in progress even at the end of Step f. A TMF Response MUST NOT be 1718 sent by the target iSCSI layer before the end of Step e, and MAY 1719 be sent at the end of Step e despite these outstanding Data 1720 transfers until Step g. Step g specifies an event to free up any 1721 such resources that may have been reserved to support outstanding 1722 data transfers. 1724 4.2.3.5. Affected Tasks Shared across Standard and FastAbort Sessions 1726 If an iSCSI target implementation is capable of supporting 1727 TaskReporting=FastAbort functionality (Section 13.23), it may end 1728 up in a situation where some sessions have TaskReporting=RFC3720 1729 operational (RFC 3720 sessions) while some other sessions have 1730 TaskReporting=FastAbort operational (FastAbort sessions) even 1731 while accessing a shared set of affected tasks (Section 4.2.3.2). 1732 If the issuing session is an RFC 3720 session, the iSCSI target 1733 implementation is FastAbort-capable, and the third-party affected 1734 session is a FastAbort session, the following behavior SHOULD be 1735 exhibited by the iSCSI target layer: 1736 a. Between Steps c and d of the target behavior in Section 1737 4.2.3.3, send an Asynchronous Message PDU with AsyncEvent=5 1738 (Section 11.9) on each connection of each third-party 1739 session to which at least one affected task is allegiant. 1740 If there are multiple affected LUs, then send one Async 1741 Message PDU for each such LU on each connection that has at 1742 least one allegiant affected task. When sent, the LUN field 1743 in the Asynchronous Message PDU MUST be set to match the 1744 LUN for each such LU. 1745 b. After Step e of the target behavior in Section 4.2.3.3, 1746 free up the affected TTTs (and STags, if applicable) and 1747 the corresponding buffers, if any, once each associated 1748 NOP-Out acknowledgement is received that the third-party 1749 initiator generated in response to each Async Message sent 1750 in Step a. 1752 If the issuing session is a FastAbort session, the iSCSI target 1753 implementation is FastAbort-capable, and the third-party affected 1754 session is an RFC 3720 session, the following behavior MUST be 1755 exhibited by the iSCSI target layer: Asynchronous Message PDUs 1756 MUST NOT be sent on the third-party session to prompt the 1757 FastAbort behavior. 1759 If the third-party affected session is a FastAbort session and the 1760 issuing session is a FastAbort session, the initiator in the 1761 third-party role MUST respond to each Async Message PDU with 1762 AsyncEvent=5 as defined in Section 11.9. Note that an initiator 1763 MAY thus receive these Async Messages on a third-party affected 1764 session even if the session is a single-connection session. 1766 4.2.3.6. Rationale behind the FastAbort Semantics 1768 There are fundamentally three basic objectives behind the 1769 semantics 1770 specified in Sections 4.2.3.3 and 4.2.3.4. 1771 1. Maintaining an ordered command flow I_T nexus abstraction 1772 to the target SCSI layer even with multi-connection 1773 sessions. 1774 - Target iSCSI processing of a TMF request must 1775 maintain the single flow illusion. Target behavior in 1776 Step b of Section 4.2.3.3 and Step aof Section 4.2.3.4 1777 correspond to this objective. 1778 2. Maintaining a single ordered response flow I_T nexus 1779 abstraction to the initiator SCSI layer even with multi- 1780 connection sessions when one response (i.e., TMF response) 1781 could imply the status of other unfinished tasks from the 1782 initiator's perspective. 1783 - The target must ensure that the initiator does not 1784 see "old" task responses (that were placed on the wire 1785 chronologically earlier than the TMF Response) after 1786 seeing the TMF response. The target behavior in Step d 1787 of Section 4.2.3.3 and Step e of Section 4.2.3.4 1788 correspond to this objective. 1789 - Whenever the result of a TMF action is visible across 1790 multiple I_T_L nexuses, [SAM2] requires the SCSI device 1791 server to trigger a UA on each of the other I_T_L 1792 nexuses. Once an initiator is notified of such an UA, 1793 the application client on the receiving initiator is 1794 required to clear its task state (clause 5.5 in [SAM2]) 1795 for the affected tasks. It would thus be inappropriate 1796 to deliver a SCSI Response for a task after the task 1797 state is cleared on the initiator, i.e., after the UA 1798 is notified. The UA notification contained in the first 1799 SCSI Response PDU on each affected Third-party I_T_L 1800 nexus after the TMF action thus MUST NOT pass the 1801 affected task responses on any of the iSCSI sessions 1802 accessing the LU. The target behavior in Step e of 1803 Section 4.2.3.3 and Step f of Section 4.2.3.4 1804 correspond to this objective. 1805 3. Draining all active TTTs corresponding to affected tasks in 1806 a deterministic fashion. 1807 - Data-Out PDUs with stale TTTs arriving after the 1808 tasks are terminated can create a buffer management 1809 problem even for traditional iSCSI implementations, and 1810 is fatal for the connection for iSCSI/iSER 1811 implementations. Either the termination of affected 1812 tasks should be postponed until the TTTs are retired 1813 (as in Step a of Section 4.2.3.3), or the TTTs and the 1814 buffers should stay allocated beyond task termination 1815 to be deterministically freed up later (as in Steps c 1816 and g of Section 4.2.3.4). 1818 The only other notable optimization is the plugging. If all tasks 1819 on an I_T nexus will be aborted anyway (as with a target reset), 1820 there is no need to wait to receive all commands to plug the CmdSN 1821 holes. The target iSCSI layer can simply plug all missing CmdSN 1822 slots and move on with TMF processing. The first objective 1823 (maintaining a single ordered command flow) is still met with this 1824 optimization because the target SCSI layer only sees ordered 1825 commands. 1827 4.2.4. iSCSI Login 1829 The purpose of the iSCSI login is to enable a TCP connection for 1830 iSCSI use, authentication of the parties, negotiation of the 1831 session's parameters and marking of the connection as belonging to 1832 an iSCSI session. 1834 A session is used to identify to a target all the connections with 1835 a given initiator that belong to the same I_T nexus. (For more 1837 details on how a session relates to an I_T nexus, see section 1838 4.4.2). 1840 The targets listen on a well-known TCP port or other TCP port for 1841 incoming connections. The initiator begins the login process by 1842 connecting to one of these TCP ports. 1844 As part of the login process, the initiator and target SHOULD 1845 authenticate each other and MAY set a security association 1846 protocol for the session. This can occur in many different ways 1847 and is subject to negotiation. 1849 To protect the TCP connection, an IPsec security association MAY 1850 be established before the Login request. For information on using 1851 IPsec security for iSCSI see Chapter 8 and [RFC3723]. 1853 The iSCSI Login Phase is carried through Login requests and 1854 responses. Once suitable authentication has occurred and 1855 operational parameters have been set, the session transitions to 1856 Full Feature Phase and the initiator may start to send SCSI 1857 commands. The security policy for whether, and by what means, a 1858 target chooses to authorize an initiator is beyond the scope of 1859 this document. For a more detailed description of the Login Phase, 1860 see Chapter 5. 1862 The login PDU includes the ISID part of the session ID (SSID). The 1863 target portal group that services the login is implied by the 1864 selection of the connection endpoint. For a new session, the TSIH 1865 is zero. As part of the response, the target generates a TSIH. 1867 During session establishment, the target identifies the SCSI 1868 initiator port (the "I" in the "I_T nexus") through the value pair 1869 (InitiatorName, ISID). We describe InitiatorName later in this 1870 section. Any persistent state (e.g., persistent reservations) on 1871 the target that is associated with a SCSI initiator port is 1872 identified based on this value pair. Any state associated with the 1873 SCSI target port (the "T" in the "I_T nexus") is identified 1874 externally by the TargetName and portal group tag (see Section 1875 4.4.1). ISID is subject to reuse restrictions because it is used 1876 to identify a persistent state (see Section 4.4.3). 1878 Before the Full Feature Phase is established, only Login Request 1879 and Login Response PDUs are allowed. Login requests and responses 1880 MUST be used exclusively during Login. On any connection, the 1881 login phase MUST immediately follow TCP connection establishment 1882 and a subsequent Login Phase MUST NOT occur before tearing down a 1883 connection. 1885 A target receiving any PDU except a Login request before the Login 1886 phase is started MUST immediately terminate the connection on 1887 which the PDU was received. Once the Login phase has started, if 1888 the target receives any PDU except a Login request, it MUST send a 1889 Login reject (with Status "invalid during login") and then 1890 disconnect. If the initiator receives any PDU except a Login 1891 response, it MUST immediately terminate the connection. 1893 4.2.5. iSCSI Full Feature Phase 1895 Once the initiator is authorized to do so, the iSCSI session is in 1896 the iSCSI Full Feature Phase. A session is in Full Feature Phase 1897 after successfully finishing the Login Phase on the first 1898 (leading) connection of a session. A connection is in Full Feature 1899 Phase if the session is in Full Feature Phase and the connection 1900 login has completed successfully. An iSCSI connection is not in 1901 Full Feature Phase 1903 when it does not have an established transport connection, 1904 OR 1905 when it has a valid transport connection, but a successful 1906 login was not performed or the connection is currently 1907 logged out. 1909 In a normal Full Feature Phase, the initiator may send SCSI 1910 commands and data to the various LUs on the target by 1911 encapsulating them in iSCSI PDUs that go over the established 1912 iSCSI session. 1914 4.2.5.1. Command Connection Allegiance 1916 For any iSCSI request issued over a TCP connection, the 1917 corresponding response and/or other related PDU(s) MUST be sent 1918 over the same connection. We call this "connection allegiance". If 1919 the original connection fails before the command is completed, the 1920 connection allegiance of the command may be explicitly reassigned 1921 to a different transport connection as described in detail in 1922 Section 7.2 "Retry and Reassign in Recovery". 1924 Thus, if an initiator issues a READ command, the target MUST send 1925 the requested data, if any, followed by the status to the 1926 initiator over the same TCP connection that was used to deliver 1927 the SCSI command. If an initiator issues a WRITE command, the 1928 initiator MUST send the data, if any, for that command over the 1929 same TCP connection that was used to deliver the SCSI command. The 1930 target MUST return Ready To Transfer (R2T), if any, and the status 1931 over the same TCP connection that was used to deliver the SCSI 1932 command. Retransmission requests (SNACK PDUs) and the data and 1933 status that they generate MUST also use the same connection. 1935 However, consecutive commands that are part of a SCSI linked 1936 command-chain task (see [SAM2]) MAY use different connections. 1937 Connection allegiance is strictly per-command and not per-task. 1938 During the iSCSI Full Feature Phase, the initiator and target MAY 1939 interleave unrelated SCSI commands, their SCSI Data, and responses 1940 over the session. 1942 4.2.5.2. Data Transfer Overview 1944 Outgoing SCSI data (initiator to target user data or command 1945 parameters) is sent as either solicited data or unsolicited data. 1946 Solicited data are sent in response to R2T PDUs. Unsolicited data 1947 can be sent as part of an iSCSI command PDU ("immediate data") or 1948 in separate iSCSI data PDUs. 1950 Immediate data are assumed to originate at offset 0 in the 1951 initiator SCSI write-buffer (outgoing data buffer). All other Data 1952 PDUs have the buffer offset set explicitly in the PDU header. 1954 An initiator may send unsolicited data up to FirstBurstLength as 1955 immediate (up to the negotiated maximum PDU length), in a separate 1956 PDU sequence or both. All subsequent data MUST be solicited. The 1957 maximum length of an individual data PDU or the immediate-part of 1958 the first unsolicited burst MAY be negotiated at login. 1960 The maximum amount of unsolicited data that can be sent with a 1961 command is negotiated at login through the FirstBurstLength key. A 1962 target MAY separately enable immediate data (through the 1963 ImmediateData key) without enabling the more general (separate 1964 data PDUs) form of unsolicited data (through the InitialR2T key). 1966 Unsolicited data on write are meant to reduce the effect of 1967 latency on throughput (no R2T is needed to start sending data). In 1968 addition, immediate data is meant to reduce the protocol overhead 1969 (both bandwidth and execution time). 1971 An iSCSI initiator MAY choose not to send unsolicited data, only 1972 immediate data or FirstBurstLength bytes of unsolicited data with 1973 a command. If any non-immediate unsolicited data is sent, the 1974 total unsolicited data MUST be either FirstBurstLength, or all of 1975 the data if the total amount is less than the FirstBurstLength. 1977 It is considered an error for an initiator to send unsolicited 1978 data PDUs to a target that operates in R2T mode (only solicited 1979 data are allowed). It is also an error for an initiator to send 1980 more unsolicited data, whether immediate or as separate PDUs, than 1981 FirstBurstLength. 1983 An initiator MUST honor an R2T data request for a valid 1984 outstanding command (i.e., carrying a valid Initiator Task Tag) 1985 and deliver all the requested data provided the command is 1986 supposed to deliver outgoing data and the R2T specifies data 1987 within the command bounds. The initiator action is unspecified for 1988 receiving an R2T request that specifies data, all or part, outside 1989 of the bounds of the command. 1991 A target SHOULD NOT silently discard data and then request 1992 retransmission through R2T. Initiators SHOULD NOT keep track of 1993 the data transferred to or from the target (scoreboarding). SCSI 1994 targets perform residual count calculation to check how much data 1995 was actually transferred to or from the device by a command. This 1996 may differ from the amount the initiator sent and/or received for 1997 reasons such as retransmissions and errors. Read or bidirectional 1998 commands implicitly solicit the transmission of the entire amount 1999 of data covered by the command. SCSI data packets are matched to 2000 their corresponding SCSI commands by using tags specified in the 2001 protocol. 2003 In addition, iSCSI initiators and targets MUST enforce some 2004 ordering rules. When unsolicited data is used, the order of the 2005 unsolicited data on each connection MUST match the order in which 2006 the commands on that connection are sent. Command and unsolicited 2007 data PDUs may be interleaved on a single connection as long as the 2008 ordering requirements of each are maintained (e.g., command N+1 2009 MAY be sent before the unsolicited Data-Out PDUs for command N, 2010 but the unsolicited Data-Out PDUs for command N MUST precede the 2011 unsolicited Data-Out PDUs of command N+1). A target that receives 2012 data out of order MAY terminate the session. 2014 4.2.5.3. Tags and Integrity Checks 2016 Initiator tags for pending commands are unique initiator-wide for 2017 a session. Target tags are not strictly specified by the protocol. 2018 It is assumed that target tags are used by the target to tag 2019 (alone or in combination with the LUN) the solicited data. Target 2020 tags are generated by the target and "echoed" by the initiator. 2021 These mechanisms are designed to accomplish efficient data 2022 delivery along with a large degree of control over the data flow. 2024 As the Initiator Task Tag is used to identify a task during its 2025 execution the iSCSI initiator and target MUST verify that all 2026 other fields used in task related PDUs have values that are 2027 consistent with the values used at the task instantiation based on 2028 Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the 2029 same as the one used in the SCSI command PDU used to instantiate 2030 the task). Using inconsistent field values is considered a 2031 protocol error. 2033 4.2.5.4. Task Management 2035 SCSI task management assumes that individual tasks and task groups 2036 can be aborted solely based on the task tags (for individual 2037 tasks) or the timing of the task management command (for task 2038 groups) and that the task management action is executed 2039 synchronously - i.e, no message involving an aborted task will be 2040 seen by the SCSI initiator after receiving the task management 2041 response. In iSCSI initiators and targets interact asynchronously 2042 over several connections. iSCSI specifies the protocol mechanism 2043 and implementation requirements needed to present a synchronous 2044 view while using an asynchronous infrastructure. 2046 4.2.6. iSCSI Connection Termination 2048 An iSCSI connection may be terminated by use of a transport 2049 connection shutdown or a transport reset. Transport reset is 2050 assumed to be an exceptional event. 2052 Graceful TCP connection shutdowns are done by sending TCP FINs. A 2053 graceful transport connection shutdown SHOULD only be initiated by 2054 either party when the connection is not in iSCSI Full Feature 2055 Phase. A target MAY terminate a Full Feature Phase connection on 2056 internal exception events, but it SHOULD announce the fact through 2057 an Asynchronous Message PDU. Connection termination with 2058 outstanding commands may require recovery actions. 2060 If a connection is terminated while in Full Feature Phase, 2061 connection cleanup (see section 7) is required prior to recovery. 2062 By doing connection cleanup before starting recovery, the 2063 initiator and target will avoid receiving stale PDUs after 2064 recovery. 2066 4.2.7. iSCSI Names 2068 Both targets and initiators require names for the purpose of 2069 identification. In addition, names enable iSCSI storage resources 2070 to be managed regardless of location (address). An iSCSI node name 2071 is also the SCSI device name contained in the iSCSI Node. The 2072 iSCSI name of a SCSI device is the principal object used in 2073 authentication of targets to initiators and initiators to targets. 2074 This name is also used to identify and manage iSCSI storage 2075 resources. 2077 iSCSI names must be unique within the operation domain of the end 2078 user. However, because the operation domain of an IP network is 2079 potentially worldwide, the iSCSI name formats are architected to 2080 be worldwide unique. To assist naming authorities in the 2081 construction of worldwide unique names, iSCSI provides three name 2082 formats for different types of naming authorities. 2084 iSCSI names are associated with iSCSI nodes, and not iSCSI network 2085 adapter cards, to ensure that the replacement of network adapter 2087 cards does not require reconfiguration of all SCSI and iSCSI 2088 resource allocation information. 2090 Some SCSI commands require that protocol-specific identifiers be 2091 communicated within SCSI CDBs. See SCSI for the definition of the 2092 SCSI port name/identifier for iSCSI ports. 2094 An initiator may discover the iSCSI Target Names to which it has 2095 access, along with their addresses, using the SendTargets text 2096 request, or other techniques discussed in [RFC3721]. 2098 iSCSI equipment that needs discovery functions beyond SendTargets 2099 SHOULD implement iSNS (see [RFC4171]) for extended discovery 2100 management capabilities and interoperability. Although [RFC3721] 2101 implies an SLP implementation requirement, SLP has not been widely 2102 implemented or deployed for use with iSCSI in practice. iSCSI 2103 implementations therefore SHOULD NOT rely on SLP-based discovery 2104 interoperability. 2106 4.2.7.1. iSCSI Name Properties 2108 Each iSCSI node, whether it is an initiator or target or both, 2109 MUST have an iSCSI name. Whenever an iSCSI Node contains an iSCSI 2110 Initiator Node and an iSCSI Target Node, the iSCSI Initiator Name 2111 MUST be the same as the iSCSI Target Name for the contained Nodes 2112 such that there is only one iSCSI Node Name for the iSCSI Node 2113 overall. Note the related requirements in section 9.2.1 on how to 2114 map CHAP names to iSCSI Names in such a scenario. 2116 Initiators and targets MUST support the receipt of iSCSI names of 2117 up to the maximum length of 223 bytes. 2119 The initiator MUST present both its iSCSI Initiator Name and the 2120 iSCSI Target Name to which it wishes to connect in the first login 2121 request of a new session or connection. The only exception is if a 2122 discovery session (see Section 4.3 iSCSI Session Types) is to be 2123 established. In this case, the iSCSI Initiator Name is still 2124 required, but the iSCSI Target Name MAY be omitted. 2126 iSCSI names have the following properties: 2128 iSCSI names are globally unique. No two initiators or targets 2129 can have the same name. 2130 iSCSI names are permanent. An iSCSI initiator node or target 2131 node has the same name for its lifetime. 2132 iSCSI names do not imply a location or address. An iSCSI 2133 initiator or target can move, or have multiple addresses. A 2134 change of address does not imply a change of name. 2135 iSCSI names do not rely on a central name broker; the naming 2136 authority is distributed. 2137 iSCSI names support integration with existing unique naming 2138 schemes. 2139 iSCSI names rely on existing naming authorities. iSCSI does 2140 not create any new naming authority. 2142 The encoding of an iSCSI name has the following properties: 2144 iSCSI names have the same encoding method regardless of the 2145 underlying protocols. 2146 iSCSI names are relatively simple to compare. The algorithm 2147 for comparing two iSCSI names for equivalence does not rely 2148 on an external server. 2149 iSCSI names are composed only of displayable characters. iSCSI 2150 names allow the use of international character sets but are 2151 not case sensitive. No whitespace characters are used in 2152 iSCSI names. 2153 iSCSI names may be transported using both binary and ASCII- 2154 based protocols. 2156 An iSCSI name really names a logical software entity, and is not 2157 tied to a port or other hardware that can be changed. For 2158 instance, an initiator name should name the iSCSI initiator node, 2159 not a particular NIC or HBA. When multiple NICs are used, they 2160 should generally all present the same iSCSI initiator name to the 2161 targets, because they are simply paths to the same SCSI layer. In 2162 most operating systems, the named entity is the operating system 2163 image. 2165 Similarly, a target name should not be tied to hardware interfaces 2166 that can be changed. A target name should identify the logical 2167 target and must be the same for the target regardless of the 2168 physical portion being addressed. This assists iSCSI initiators in 2169 determining that the two targets it has discovered are really two 2170 paths to the same target. 2172 The iSCSI name is designed to fulfill the functional requirements 2173 for Uniform Resource Names (URN) [RFC1737]. For example, it is 2174 required that the name have a global scope, be independent of 2175 address or location, and be persistent and globally unique. Names 2176 must be extensible and scalable with the use of naming 2177 authorities. The name encoding should be both human and machine 2178 readable. See [RFC1737] for further requirements. 2180 4.2.7.2. iSCSI Name Encoding 2182 An iSCSI name MUST be a UTF-8 encoding of a string of Unicode 2183 characters with the following properties: 2185 - It is in Normalization Form C (see "Unicode Normalization 2186 Forms" [UNICODE]). 2188 - It only contains characters allowed by the output of the 2189 iSCSI stringprep template (described in [RFC3722]). 2191 - The following characters are used for formatting iSCSI 2192 names: 2194 - dash ('-'=U+002d) 2195 - dot ('.'=U+002e) 2196 - colon (':'=U+003a) 2198 - The UTF-8 encoding of the name is not larger than 223 bytes. 2200 The stringprep process is described in [RFC3454]; iSCSI's use of 2201 the stringprep process is described in [RFC3722]. Stringprep is a 2202 method designed by the Internationalized Domain Name (IDN) working 2203 group to translate human-typed strings into a format that can be 2204 compared as opaque strings. Strings MUST NOT include punctuation, 2205 spacing, diacritical marks, or other characters that could get in 2206 the way of readability. The stringprep process also converts 2207 strings into equivalent strings of lower-case characters. 2209 The stringprep process does not need to be implemented if the 2210 names are only generated using numeric and lower-case (any 2211 character set) alphabetic characters. 2213 Once iSCSI names encoded in UTF-8 are "normalized" they may be 2214 safely compared byte-for-byte. 2216 4.2.7.3. iSCSI Name Structure 2218 An iSCSI name consists of two parts--a type designator followed by 2219 a unique name string. 2221 iSCSI uses three existing naming authorities in constructing 2222 globally unique iSCSI names. Type designator in an iSCSI name 2223 indicates the naming authority on which the name is based. The 2224 three iSCSI name formats are the following: 2226 iSCSI-Qualified Name: it is based on domain names to identify 2227 a naming authority, 2228 NAA format Name: it is based on a naming format defined by 2229 [FC-FS] for constructing globally unique identifiers, 2230 referred to as the Network Address Authority (NAA), and, 2231 EUI format Name: it is based on EUI names where the IEEE 2232 Registration Authority assists in the formation of 2233 worldwide unique names (EUI-64 format). 2235 The corresponding type designator strings currently defined are: 2237 iqn. - iSCSI Qualified name 2239 naa. - Remainder of the string is an INCITS T11-defined 2240 Network Address Authority identifier, in ASCII-encoded 2241 hexadecimal. 2243 eui. - Remainder of the string is an IEEE EUI-64 identifier, 2244 in ASCII-encoded hexadecimal. 2246 These three naming authority designators were considered 2247 sufficient at the time of writing this document. The creation of 2248 additional naming type designators for iSCSI may be considered by 2249 the IETF and detailed in separate RFCs. 2251 The following table summarizes the current SCSI transport 2252 protocols and their naming formats. 2254 SCSI Transport Protocol Naming Format 2255 +----------------------------+-------+-----+----+ 2256 | | EUI-64| NAA |IQN | 2257 |----------------------------|-------|-----|----| 2258 | iSCSI (Internet SCSI) | X | X | X | 2259 |----------------------------|-------|-----|----| 2260 | FCP (Fibre Channel) | | X | | 2261 |----------------------------|-------|-----|----| 2262 | SAS (Serial Attached SCSI) | | X | | 2263 |----------------------------|-------|-----|----| 2264 | SRP (for InfiniBand) | X | | | 2265 +----------------------------+-------+-----+----+ 2267 4.2.7.4. Type "iqn." (iSCSI Qualified Name) 2269 This iSCSI name type can be used by any organization that owns a 2270 domain name. This naming format is useful when an end user or 2271 service provider wishes to assign iSCSI names for targets and/or 2272 initiators. 2274 To generate names of this type, the person or organization 2275 generating the name must own a registered domain name. This domain 2276 name does not have to be active, and does not have to resolve to 2277 an address; it just needs to be reserved to prevent others from 2278 generating iSCSI names using the same domain name. 2280 Since a domain name can expire, be acquired by another entity, or 2281 may be used to generate iSCSI names by both owners, the domain 2282 name must be additionally qualified by a date during which the 2283 naming authority owned the domain name. A date code is provided as 2284 part of the "iqn." format for this reason. 2286 The iSCSI qualified name string consists of: 2288 - The string "iqn.", used to distinguish these names from 2289 "eui." formatted names. 2291 - A date code, in yyyy-mm format. This date MUST be a date 2292 during which the naming authority owned the domain name used 2293 in this format, and SHOULD be the first month in which the 2294 domain name was owned by this naming authority at 00:01 GMT 2295 of the first day of the month. This date code uses the 2296 Gregorian calendar. All four digits in the year must be 2297 present. Both digits of the month must be present, with 2298 January == "01" and December == "12". The dash must be 2299 included. 2301 - A dot "." 2303 - The reversed domain name of the naming authority (person or 2304 organization) creating this iSCSI name. 2306 - An optional, colon (:) prefixed, string within the character 2307 set and length boundaries that the owner of the domain name 2308 deems appropriate. This may contain product types, serial 2309 numbers, host identifiers, or software keys (e.g, it may 2310 include colons to separate organization boundaries). With 2311 the exception of the colon prefix, the owner of the domain 2312 name can assign everything after the reversed domain name as 2313 desired. It is the responsibility of the entity that is the 2314 naming authority to ensure that the iSCSI names it assigns 2315 are worldwide unique. For example, "Example Storage Arrays, 2316 Inc.", might own the domain name "example.com". 2318 The following are examples of iSCSI qualified names that might be 2319 generated by "EXAMPLE Storage Arrays, Inc." 2320 Naming String defined by 2321 Type Date Auth "example.com" naming authority 2322 +--++-----+ +---------+ +--------------------------------+ 2323 | || | | | | | 2325 iqn.2001-04.com.example:storage:diskarrays-sn-a8675309 2326 iqn.2001-04.com.example 2327 iqn.2001-04.com.example:storage.tape1.sys1.xyz 2328 iqn.2001-04.com.example:storage.disk2.sys1.xyz 2330 4.2.7.5. Type "eui." (IEEE EUI-64 format) 2332 The IEEE Registration Authority provides a service for assigning 2333 globally unique identifiers [EUI]. The EUI-64 format is used to 2334 build a global identifier in other network protocols. For example, 2335 Fibre Channel defines a method of encoding it into a 2336 WorldWideName. For more information on registering for EUI 2337 identifiers, see [OUI]. 2339 The format is "eui." followed by an EUI-64 identifier (16 ASCII- 2340 encoded hexadecimal digits). 2342 Example iSCSI name: 2344 Type EUI-64 identifier (ASCII-encoded hexadecimal) 2346 +--++--------------+ 2348 | || | 2350 eui.02004567A425678D 2352 The IEEE EUI-64 iSCSI name format might be used when a 2353 manufacturer is already registered with the IEEE Registration 2354 Authority and uses EUI-64 formatted worldwide unique names for its 2355 products. 2357 More examples of name construction are discussed in [RFC3721]. 2359 4.2.7.6. Type "naa." - Network Address Authority 2361 The INCITS T11 Framing and Signaling Specification [FC-FS] defines 2362 a format called the Network Address Authority (NAA) format for 2363 constructing worldwide unique identifiers that use various 2364 identifier registration authorities. This identifier format is 2365 used by the Fibre Channel and SAS SCSI transport protocols. As FC 2366 and SAS constitute a large fraction of networked SCSI ports, the 2367 NAA format is a widely used format for SCSI transports. The 2368 objective behind iSCSI supporting a direct representation of an 2369 NAA-format name is to facilitate construction of a target device 2370 name that translates easily across multiple namespaces for a SCSI 2371 storage device containing ports served by different transports. 2372 More specifically, this format allows implementations wherein one 2373 NAA identifier can be assigned as the basis for the SCSI device 2374 name for a SCSI target with both SAS ports and iSCSI ports. 2376 The iSCSI NAA naming format is "naa.", followed by an NAA 2377 identifier represented in ASCII-encoded hexadecimal digits. 2379 An example of an iSCSI name with a 64-bit NAA value follows: 2381 Type NAA identifier (ASCII-encoded hexadecimal) 2382 +--++--------------+ 2383 | || | 2384 naa.52004567BA64678D 2386 An example of an iSCSI name with a 128-bit NAA value follows: 2388 Type NAA identifier (ASCII-encoded hexadecimal) 2389 +--++------------------------------+ 2390 | || | 2391 naa.62004567BA64678D0123456789ABCDEF 2393 The iSCSI NAA naming format might be used in an implementation 2394 when the infrastructure for generating NAA worldwide unique names 2395 is already in place because the device contains both SAS and iSCSI 2396 SCSI ports. 2398 The NAA identifier formatted in an ASCII-hexadecimal 2399 representation has a maximum size of 32 characters (128 bit NAA 2400 format). As a result, there is no issue with this naming format 2401 exceeding the maximum size for iSCSI node names. 2403 4.2.8. Persistent State 2405 iSCSI does not require any persistent state maintenance across 2406 sessions. However, in some cases, SCSI requires persistent 2407 identification of the SCSI initiator port name (See Section 4.4.2 2408 and Section 4.4.3). 2410 iSCSI sessions do not persist through power cycles and boot 2411 operations. 2413 All iSCSI session and connection parameters are re-initialized on 2414 session and connection creation. 2416 Commands persist beyond connection termination if the session 2417 persists and command recovery within the session is supported. 2418 However, when a connection is dropped, command execution, as 2419 perceived by iSCSI (i.e., involving iSCSI protocol exchanges for 2420 the affected task), is suspended until a new allegiance is 2421 established by the 'task reassign' task management function. (See 2422 Section 11.5"Task Management Function Request".) 2424 4.2.9. Message Synchronization and Steering 2426 iSCSI presents a mapping of the SCSI protocol onto TCP. This 2427 encapsulation is accomplished by sending iSCSI PDUs of varying 2428 lengths. Unfortunately, TCP does not have a built-in mechanism for 2429 signaling message boundaries at the TCP layer. iSCSI overcomes 2430 this obstacle by placing the message length in the iSCSI message 2431 header. This serves to delineate the end of the current message as 2432 well as the beginning of the next message. 2434 In situations where IP packets are delivered in order from the 2435 network, iSCSI message framing is not an issue and messages are 2436 processed one after the other. In the presence of IP packet 2437 reordering (i.e., frames being dropped), legacy TCP 2438 implementations store the "out of order" TCP segments in temporary 2439 buffers until the missing TCP segments arrive, upon which the data 2440 must be copied to the application buffers. In iSCSI, it is 2441 desirable to steer the SCSI data within these out of order TCP 2442 segments into the pre-allocated SCSI buffers rather than store 2443 them in temporary buffers. This decreases the need for dedicated 2444 reassembly buffers as well as the latency and bandwidth related to 2445 extra copies. 2447 Relying solely on the "message length" information from the iSCSI 2448 message header may make it impossible to find iSCSI message 2449 boundaries in subsequent TCP segments due to the loss of a TCP 2450 segment that contains the iSCSI message length. The missing TCP 2451 segment(s) must be received before any of the following segments 2452 can be steered to the correct SCSI buffers (due to the inability 2453 to determine the iSCSI message boundaries). Since these segments 2454 cannot be steered to the correct location, they must be saved in 2455 temporary buffers that must then be copied to the SCSI buffers. 2457 Different schemes can be used to recover synchronization. The 2458 details of any such schemes are beyond this protocol 2459 specification, but it suffices to note that [RFC4297] provides an 2460 overview of the direct data placement problem on IP networks, and 2461 [RFC5046] specifies a protocol extension for iSCSI that 2462 facilitates this direct data placement objective. 2464 Under normal circumstances (no PDU loss or data reception out of 2465 order), iSCSI data steering can be accomplished by using the 2466 identifying tag and the data offset fields in the iSCSI header in 2467 addition to the TCP sequence number from the TCP header. The 2468 identifying tag helps associate the PDU with a SCSI buffer address 2469 while the data offset and TCP sequence number are used to 2470 determine the offset within the buffer. 2472 4.2.9.1. Sync/Steering and iSCSI PDU Length 2474 When a large iSCSI message is sent, the TCP segment(s) that 2475 contain the iSCSI header may be lost. The remaining TCP segment(s) 2476 up to the next iSCSI message must be buffered (in temporary 2477 buffers) because the iSCSI header that indicates to which SCSI 2478 buffers the data are to be steered was lost. To minimize the 2479 amount of buffering, it is recommended that the iSCSI PDU length 2480 be restricted to a small value (perhaps a few TCP segments in 2481 length). During login, each end of the iSCSI session specifies the 2482 maximum iSCSI PDU length it will accept. 2484 4.3. iSCSI Session Types 2486 iSCSI defines two types of sessions: 2488 Normal operational session - an unrestricted session. 2490 Discovery-session - a session only opened for target 2491 discovery. The target MUST ONLY accept text requests with 2492 the SendTargets key and a logout request with reason "close 2493 the session". All other requests MUST be rejected. 2495 The session type is defined during login with key=value parameter 2496 in the login command. 2498 4.4. SCSI to iSCSI Concepts Mapping Model 2500 The following diagram shows an example of how multiple iSCSI Nodes 2501 (targets in this case) can coexist within the same Network Entity 2502 and can share Network Portals (IP addresses and TCP ports). Other 2503 more complex configurations are also possible. For detailed 2504 descriptions of the components of these diagrams, see section 2505 4.4.1. 2507 +-----------------------------------+ 2508 | Network Entity (iSCSI Client) | 2509 | | 2510 | +-------------+ | 2511 | | iSCSI Node | | 2512 | | (Initiator) | | 2513 | +-------------+ | 2514 | | | | 2515 | +--------------+ +--------------+ | 2516 | |Network Portal| |Network Portal| | 2517 | | 192.0.2.4 | | 192.0.2.5 | | 2518 +-+--------------+-+--------------+-+ 2519 | | 2520 | IP Networks | 2521 | | 2522 +-+--------------+-+--------------+-+ 2523 | |Network Portal| |Network Portal| | 2524 | |198.51.100.21 | |198.51.100.3 | | 2525 | | TCP Port 3260| | TCP Port 3260| | 2526 | +--------------+ +--------------+ | 2527 | | | | 2528 | ----------------- | 2529 | | | | 2530 | +-------------+ +--------------+ | 2531 | | iSCSI Node | | iSCSI Node | | 2532 | | (Target) | | (Target) | | 2533 | +-------------+ +--------------+ | 2534 | | 2535 | Network Entity (iSCSI Server) | 2536 +-----------------------------------+ 2538 4.4.1. iSCSI Architecture Model 2540 This section describes the part of the iSCSI architecture model 2541 that has the most bearing on the relationship between iSCSI and 2542 the SCSI Architecture Model. 2544 Network Entity - represents a device or gateway that is 2545 accessible from the IP network. A Network Entity must have 2546 one or more Network Portals (see a following item), each of 2547 which can be used by some iSCSI Nodes (see the following 2548 item) contained in that Network Entity to gain access to 2549 the IP network. 2551 iSCSI Node - represents a single iSCSI initiator or iSCSI 2552 target or an instance of each. There are one or more iSCSI 2553 Nodes within a Network Entity. The iSCSI Node is accessible 2554 via one or more Network Portals (see item d). An iSCSI Node 2555 is identified by its iSCSI Name (see Section 4.2.7 and 2556 Section 13). The separation of the iSCSI Name from the 2557 addresses used by and for the iSCSI node allows multiple 2558 iSCSI nodes to use the same addresses, and the same iSCSI 2559 node to use multiple addresses. 2561 An alias string may also be associated with an iSCSI Node. The 2562 alias allows an organization to associate a user friendly 2563 string with the iSCSI Name. However, the alias string is 2564 not a substitute for the iSCSI Name. 2566 Network Portal - a component of a Network Entity that has a 2567 TCP/IP network address and that may be used by an iSCSI 2568 Node within that Network Entity for the connection(s) 2569 within one of its iSCSI sessions. In an initiator, it is 2570 identified by its IP address. In a target, it is identified 2571 by its IP address and its listening TCP port. 2573 Portal Groups - iSCSI supports multiple connections within the 2574 same session; some implementations will have the ability to 2575 combine connections in a session across multiple Network 2576 Portals. A Portal Group defines a set of Network Portals 2577 within an iSCSI Node that collectively supports the 2578 capability of coordinating a session with connections that 2579 span these portals. Not all Network Portals within a Portal 2580 Group need to participate in every session connected 2581 through that Portal Group. One or more Portal Groups may 2582 provide access to an iSCSI Node. Each Network Portal, as 2583 utilized by a given iSCSI Node, belongs to exactly one 2584 portal group within that node. Portal Groups are identified 2585 within an iSCSI Node by a portal group tag, a simple 2586 unsigned-integer between 0 and 65535 (see Section 13.3 2587 "SendTargets"). All Network Portals with the same portal 2588 group tag in the context of a given iSCSI Node are in the 2589 same Portal Group. 2591 Both iSCSI Initiators and iSCSI Targets have portal groups, 2592 though only the iSCSI Target Portal Groups are used 2593 directly in the iSCSI protocol (e.g., in SendTargets). For 2594 references to the Initiator Portal Groups, see Section 2595 10.1.1. 2597 Portals within a Portal Group should support similar session 2598 parameters, because they may participate in a common 2599 session. 2601 The following diagram shows an example of one such configuration 2602 on a target and how a session that shares Network Portals within a 2603 Portal Group may be established. 2605 ----------------------------IP Network--------------------- 2606 | | | 2607 +----|---------------|-----+ +----|---------+ 2608 | +---------+ +---------+ | | +---------+ | 2609 | | Network | | Network | | | | Network | | 2610 | | Portal | | Portal | | | | Portal | | 2611 | +--|------+ +---------+ | | +---------+ | 2612 | | | | | | | 2613 | | Portal | | | | Portal | 2614 | | Group 1 | | | | Group 2 | 2615 +--------------------------+ +--------------+ 2616 | | | 2617 +--------|---------------|--------------------|------------------- 2618 + 2619 | | | | 2620 | 2621 | +----------------------------+ +----------------------------- 2622 +| 2623 | | iSCSI Session (Target side)| | iSCSI Session (Target side) 2624 || 2625 | | | | 2626 || 2627 | | (TSIH = 56) | | (TSIH = 48) 2628 || 2629 | +----------------------------+ +----------------------------- 2630 +| 2631 | 2632 | 2633 | iSCSI Target Node 2634 | 2635 | (within Network Entity, not shown) 2636 | 2637 +----------------------------------------------------------------- 2638 + 2640 4.4.2. SCSI Architecture Model 2642 This section describes the relationship between the SCSI 2643 Architecture Model [SAM2] and constructs of the SCSI device, SCSI 2644 port and I_T nexus, and the iSCSI constructs described in Section 2645 4.4.1. 2647 This relationship implies implementation requirements in order to 2648 conform to the SAM2 model and other SCSI operational functions. 2649 These requirements are detailed in Section 4.4.3. 2651 The following list outlines mappings of SCSI architectural 2652 elements to iSCSI. 2654 SCSI Device - the SAM2 term for an entity that contains one or 2655 more SCSI ports that are connected to a service delivery 2656 subsystem and supports a SCSI application protocol. For 2657 example, a SCSI Initiator Device contains one or more SCSI 2658 Initiator Ports and zero or more application clients. A 2659 SCSI Target Device contains one or more SCSI Target Ports 2660 and one or more logical units. For iSCSI, the SCSI Device 2661 is the component within an iSCSI Node that provides the 2662 SCSI functionality. As such, there can be one SCSI Device, 2663 at most, within an iSCSI Node. Access to the SCSI Device 2664 can only be achieved in an iSCSI normal operational session 2665 (see Section 4.3). The SCSI Device Name is defined to be 2666 the iSCSI Name of the node and MUST be used in the iSCSI 2667 protocol. 2669 SCSI Port - the SAM2 term for an entity in a SCSI Device that 2670 provides the SCSI functionality to interface with a service 2671 delivery subsystem or transport. For iSCSI, the definition 2672 of SCSI Initiator Port and SCSI Target Port are different. 2674 SCSI Initiator Port: This maps to one endpoint of an iSCSI 2675 normal operational session (see Section 4.3). An iSCSI 2676 normal operational session is negotiated through the login 2677 process between an iSCSI initiator node and an iSCSI target 2678 node. At successful completion of this process, a SCSI 2679 Initiator Port is created within the SCSI Initiator Device. 2680 The SCSI Initiator Port Name and SCSI Initiator Port 2681 Identifier are both defined to be the iSCSI Initiator Name 2682 together with (a) a label that identifies it as an 2683 initiator port name/identifier and (b) the ISID portion of 2684 the session identifier. 2686 SCSI Target Port: This maps to an iSCSI Target Portal 2687 Group. The SCSI Target Port Name and the SCSI Target Port 2688 Identifier are both defined to be the iSCSI Target Name 2689 together with (a) a label that identifies it as a target 2690 port name/identifier and (b) the portal group tag. 2692 The SCSI Port Name MUST be used in iSCSI. When used in SCSI 2693 parameter data, the SCSI port name MUST be encoded as: 2694 - The iSCSI Name in UTF-8 format, followed by 2695 - a comma separator (1 byte), followed by 2696 - the ASCII character 'i' (for SCSI Initiator Port) or the 2697 ASCII character 't' (for SCSI Target Port) (1 byte), 2698 followed by 2699 - a comma separator (1 byte), followed by 2700 - a text encoding as a hex-constant (see Section 6.1 "Text 2701 Format") of the ISID (for SCSI initiator port) or the 2702 portal group tag (for SCSI target port) including the 2703 initial 0X or 0x and the terminating null (14 bytes). 2705 The ASCII character 'i' or 't' is the label that 2706 identifies this port as either a SCSI Initiator Port or a 2707 SCSI Target Port. 2709 I_T nexus - a relationship between a SCSI Initiator Port and a 2710 SCSI Target Port, according to [SAM2]. For iSCSI, this 2711 relationship is a session, defined as a relationship 2712 between an iSCSI Initiator's end of the session (SCSI 2713 Initiator Port) and the iSCSI Target's Portal Group. The 2714 I_T nexus can be identified by the conjunction of the SCSI 2715 port names or by the iSCSI session identifier SSID. iSCSI 2716 defines the I_T nexus identifier to be the tuple (iSCSI 2717 Initiator Name + 'i' + ISID, iSCSI Target Name + 't' + 2718 Portal Group Tag). 2720 NOTE: The I_T nexus identifier is not equal to the session 2721 identifier (SSID). 2723 4.4.3. Consequences of the Model 2725 This section describes implementation and behavioral requirements 2726 that result from the mapping of SCSI constructs to the iSCSI 2727 constructs defined above. Between a given SCSI initiator port and 2728 a given SCSI target port, only one I_T nexus (session) can exist. 2729 No more than one nexus relationship (parallel nexus) is allowed by 2730 [SAM2]. Therefore, at any given time, only one session with the 2731 same session identifier (SSID) can exist between a given iSCSI 2732 initiator node and an iSCSI target node. 2734 These assumptions lead to the following conclusions and 2735 requirements: 2737 ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal 2738 Group (SCSI target port), there can only be one session with a 2739 given value for ISID that identifies the SCSI initiator port. See 2740 Section 11.12.5"ISID". 2742 The structure of the ISID that contains a naming authority 2743 component (see Section 11.12.5"ISID" and [RFC3721]) provides a 2744 mechanism to facilitate compliance with the ISID rule. (See 2745 Section 10.1.1 "Conservative Reuse of ISIDs".) 2747 The iSCSI Initiator Node should manage the assignment of ISIDs 2748 prior to session initiation. The "ISID RULE" does not preclude the 2749 use of the same ISID from the same iSCSI Initiator with different 2750 Target Portal Groups on the same iSCSI target or on other iSCSI 2751 targets (see Section 10.1.1 "Conservative Reuse of ISIDs"). 2752 Allowing this would be analogous to a single SCSI Initiator Port 2753 having relationships (nexus) with multiple SCSI target ports on 2754 the same SCSI target device or SCSI target ports on other SCSI 2755 target devices. It is also possible to have multiple sessions with 2756 different ISIDs to the same Target Portal Group. Each such session 2757 would be considered to be with a different initiator even when the 2758 sessions originate from the same initiator device. The same ISID 2759 may be used by a different iSCSI initiator because it is the iSCSI 2760 Name together with the ISID that identifies the SCSI Initiator 2761 Port. 2763 NOTE: A consequence of the ISID RULE and the specification for the 2764 I_T nexus identifier is that two nexus with the same identifier 2765 should never exist at the same time. 2767 TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH 2768 at session creation (when an initiator presents a 0 value at 2769 Login). After being selected, the same TSIH value MUST be used 2770 whenever initiator or target refers to the session and a TSIH is 2771 required. 2773 4.4.3.1. I_T Nexus State 2775 Certain nexus relationships contain an explicit state (e.g., 2776 initiator-specific mode pages) that may need to be preserved by 2777 the device server [SAM2] in a logical unit through changes or 2778 failures in the iSCSI layer (e.g., session failures). In order for 2779 that state to be restored, the iSCSI initiator should reestablish 2780 its session (re-login) to the same Target Portal Group using the 2781 previous ISID. That is, it should perform session recovery as 2782 described in Chapter 6. This is because the SCSI initiator port 2783 identifier and the SCSI target port identifier (or relative target 2784 port) form the datum that the SCSI logical unit device server uses 2785 to identify the I_T nexus. 2787 4.5. iSCSI UML Model 2789 This section presents the application of the UML modeling concepts 2790 discussed in Section 3 to the iSCSI and SCSI architecture model 2791 discussed in Section 4.4. 2793 +----------------+ 2794 | Network Entity | 2795 +----------------+ 2796 @ 1 @ 1 2797 | | 2798 +--------------------+ | 2799 | | 2800 | | 0..* 2801 | +------------------+ 2802 | | iSCSI Node | 2803 | +------------------+ 2804 | @ @ 2805 | | | 2806 | +-----------+ =(a)= +-----------+ 2807 | | | 2808 | | 0..1 | 0..1 2809 | +------------------------+ +----------------------+ 2810 | | iSCSI Target Node | | iSCSI Initiator Node | 2811 | +------------------------+ +----------------------+ 2812 | @ 1 @ 1 2813 | +--------------+ | 2814 | 1..* | | 1..* 2815 | +-----------------------------+ 2816 | | Portal Group | 2817 | +-----------------------------+ 2818 | O 1 2819 | | 2820 | | 1..* 2821 | 1..* +------------------------+ 2822 +-------------------| Network Portal | 2823 +------------------------+ 2825 (a) Each instance of an iSCSI Node class MUST contain one iSCSI 2826 Target Node instance or one iSCSI Initiator Node instance, or 2827 both. 2829 +----------------+ 2830 | Network Entity | 2831 +----------------+ 2832 @ 1 @ 1 2833 | | +-------------------+ 2834 +---------------------+ | | iSCSI Session | 2835 | | +-------------------+ 2836 | | 0..* | SSID[1] | 2837 | +--------------------+ | ISID[1] | 2838 | | iSCSI Node | +-------------------+ 2839 | +--------------------+ @ 1 2840 | | iSCSI Node Name[1] | | 2841 | | Alias [0..1] | | 0..* 2842 | +--------------------+ +------------------+ 2843 | | | | iSCSI Connection | 2844 | +--------------------+ +------------------+ 2845 | @ 1 @ 1 | CID[1] | 2846 | | | +------------------+ 2847 | +-------------+ ==(b)== +----------+ 0..* | 2848 | | 1 | 1 | 2849 | +------------------------+ +------------------------+ | 2850 | | iSCSI Target Node | | iSCSI Initiator Node | | 2851 | +------------------------+ +------------------------+ | 2852 | | iSCSI Target name [1] | |iSCSI Initiator Name [1]| | 2853 | +------------------------+ +------------------------+ | 2854 | @ 1 @ 1 | 2855 | | 1..* | 1..* | 2856 | +--------------------------+ +------------------------+ | 2857 | | Target Portal Group | | Initiator Portal Group | | 2858 | +--------------------------+ +------------------------+ | 2859 | |Target Portal Group Tag[1]| | Portal group tag[1] | | 2860 | +--------------------------+ +------------------------+ | 2861 | o 1 o 1 | 2862 | +------------+ +---------+ | 2863 | 1..* | | 1..* | 2864 | +-------------------------+ | 2865 | | Network Portal | | 2866 | +-------------------------+ | 2867 | 1..* | IP Address [1] | 1 | 2868 +----------------| TCP Port [0..1] |<----------------------+ 2869 +-------------------------+ 2871 (b) Each instance of an iSCSI Node class MUST contain one iSCSI 2872 Target Node instance or one iSCSI Initiator Node instance, or 2873 both. However, in all scenarios, note that an iSCSI Node MUST 2874 only have a single iSCSI Name. Note the related requirement in 2875 section 4.2.7.1. 2877 4.6. Request/Response Summary 2879 This section lists and briefly describes all the iSCSI PDU types 2880 (request and responses). 2882 All iSCSI PDUs are built as a set of one or more header segments 2883 (basic and auxiliary) and zero or one data segments. The header 2884 group and the data segment may each be followed by a CRC (digest). 2886 The basic header segment has a fixed length of 48 bytes. 2888 4.6.1. Request/Response Types Carrying SCSI Payload 2890 4.6.1.1. SCSI-Command 2892 This request carries the SCSI CDB and all the other SCSI execute 2893 command procedure call (see [SAM2]) IN arguments such as task 2894 attributes, Expected Data Transfer Length for one or both transfer 2895 directions (the latter for bidirectional commands), and Task Tag 2896 (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the 2897 initiator and target from the LUN field in the request and the I_T 2898 nexus is implicit in the session identification. 2900 In addition, the SCSI-command PDU carries information required for 2901 the proper operation of the iSCSI protocol - the command sequence 2902 number (CmdSN) and the expected status number (ExpStatSN) on the 2903 connection it is issued. 2905 All or part of the SCSI output (write) data associated with the 2906 SCSI command may be sent as part of the SCSI-Command PDU as a data 2907 segment. 2909 4.6.1.2. SCSI-Response 2911 The SCSI-Response carries all the SCSI execute-command procedure 2912 call (see [SAM2]) OUT arguments and the SCSI execute-command 2913 procedure call return value. 2915 The SCSI-Response contains the residual counts from the operation, 2916 if any, an indication of whether the counts represent an overflow 2917 or an underflow, and the SCSI status if the status is valid or a 2918 response code (a non-zero return value for the execute-command 2919 procedure call) if the status is not valid. 2921 For a valid status that indicates that the command has been 2922 processed, but resulted in an exception (e.g., a SCSI CHECK 2923 CONDITION), the PDU data segment contains the associated sense 2924 data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI. 2926 Some data segment content may also be associated (in the data 2927 segment) with a non-zero response code. 2929 In addition, the SCSI-Response PDU carries information required 2930 for the proper operation of the iSCSI protocol: 2932 - The number of Data-In PDUs that a target has sent (to enable 2933 the initiator to check that all have arrived). 2935 - StatSN - the Status Sequence Number on this connection. 2937 - ExpCmdSN - the next Expected Command Sequence Number at the 2938 target. 2940 - MaxCmdSN - the maximum CmdSN acceptable at the target from 2941 this initiator. 2943 4.6.1.3. Task Management Function Request 2945 The Task Management function request provides an initiator with a 2946 way to explicitly control the execution of one or more SCSI Tasks 2947 or iSCSI functions. The PDU carries a function identifier (which 2948 task management function to perform) and enough information to 2949 unequivocally identify the task or task-set on which to perform 2950 the action, even if the task(s) to act upon has not yet arrived or 2951 has been discarded due to an error. 2953 The referenced tag identifies an individual task if the function 2954 refers to an individual task. 2956 The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is 2957 identified by the LUN and the session identification (the session 2958 identifies an I_T nexus). 2960 For task sets, the CmdSN of the Task Management function request 2961 helps identify the tasks upon which to act, namely all tasks 2962 associated with a LUN and having a CmdSN preceding the Task 2963 Management function request CmdSN. 2965 For a Task Management function, the coordination between responses 2966 to the tasks affected and the Task Management function response is 2967 done by the target. 2969 4.6.1.4. Task Management Function Response 2971 The Task Management function response carries an indication of 2972 function completion for a Task Management function request 2973 including how it completed (response and qualifier) and additional 2974 information for failure responses. 2976 After the Task Management response indicates Task Management 2977 function completion, the initiator will not receive any additional 2978 responses from the affected tasks. 2980 4.6.1.5. SCSI Data-out and SCSI Data-in 2982 SCSI Data-out and SCSI Data-in are the main vehicles by which SCSI 2983 data payload is carried between initiator and target. Data payload 2984 is associated with a specific SCSI command through the Initiator 2985 Task Tag. For target convenience, outgoing solicited data also 2986 carries a Target Transfer Tag (copied from R2T) and the LUN. Each 2987 PDU contains the payload length and the data offset relative to 2988 the buffer address contained in the SCSI execute command procedure 2989 call. 2991 In each direction, the data transfer is split into "sequences". An 2992 end-of-sequence is indicated by the F bit. 2994 An outgoing sequence is either unsolicited (only the first 2995 sequence can be unsolicited) or consists of all the Data-Out PDUs 2996 sent in response to an R2T. 2998 Input sequences enable the switching of direction for 2999 bidirectional commands as required. 3001 For input, the target may request positive acknowledgement of 3002 input data. This is limited to sessions that support error 3003 recovery and is implemented through the A bit in the SCSI Data-in 3004 PDU header. 3006 Data-in and Data-out PDUs also carry the DataSN to enable the 3007 initiator and target to detect missing PDUs (discarded due to an 3008 error). 3010 In addition, StatSN is carried by the Data-In PDUs. 3012 To enable a SCSI command to be processed while involving a minimum 3013 number of messages, the last SCSI Data-in PDU passed for a command 3014 may also contain the status if the status indicates termination 3015 with no exceptions (no sense or response involved). 3017 4.6.1.6. Ready To Transfer (R2T) 3019 R2T is the mechanism by which the SCSI target "requests" the 3020 initiator for output data. R2T specifies to the initiator the 3021 offset of the requested data relative to the buffer address from 3022 the execute command procedure call and the length of the solicited 3023 data. 3025 To help the SCSI target associate the resulting Data-out with an 3026 R2T, the R2T carries a Target Transfer Tag that will be copied by 3027 the initiator in the solicited SCSI Data-out PDUs. There are no 3028 protocol specific requirements with regard to the value of these 3029 tags, but it is assumed that together with the LUN, they will 3030 enable the target to associate data with an R2T. 3032 R2T also carries information required for proper operation of the 3033 iSCSI protocol, such as: 3035 - R2TSN (to enable an initiator to detect a missing R2T) 3037 - StatSN 3039 - ExpCmdSN 3041 - MaxCmdSN 3043 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload 3045 4.6.2.1. Asynchronous Message 3047 Asynchronous Messages are used to carry SCSI asynchronous events 3048 (AEN) and iSCSI asynchronous messages. 3050 When carrying an AEN, the event details are reported as sense data 3051 in the data segment. 3053 4.6.3. Requests/Responses Carrying iSCSI Only Payload 3055 4.6.3.1. Text Request and Text Response 3057 Text requests and responses are designed as a parameter 3058 negotiation vehicle and as a vehicle for future extension. 3060 In the data segment Text Requests/Responses carry text information 3061 using a simple "key=value" syntax. 3063 Text Request/Responses may form extended sequences using the same 3064 Initiator Task Tag. The initiator uses the F (Final) flag bit in 3065 the text request header to indicate its readiness to terminate a 3066 sequence. The target uses the F (Final) flag bit in the text 3067 response header to indicate its consent to sequence termination. 3069 Text Request and Responses also use the Target Transfer Tag to 3070 indicate continuation of an operation or a new beginning. A target 3071 that wishes to continue an operation will set the Target Transfer 3072 Tag in a Text Response to a value different from the default 3073 0xffffffff. An initiator willing to continue will copy this value 3074 into the Target Transfer Tag of the next Text Request. If the 3075 initiator wants to restart the current target negotiation (start 3076 fresh) will set the Target Transfer Tag to 0xffffffff. 3078 Although a complete exchange is always started by the initiator, 3079 specific parameter negotiations may be initiated by the initiator 3080 or target. 3082 4.6.3.2. Login Request and Login Response 3084 Login Requests and Responses are used exclusively during the Login 3085 Phase of each connection to set up the session and connection 3086 parameters. (The Login Phase consists of a sequence of login 3087 requests and responses carrying the same Initiator Task Tag.) 3089 A connection is identified by an arbitrarily selected connection- 3090 ID (CID) that is unique within a session. 3092 Similar to the Text Requests and Responses, Login 3093 Requests/Responses carry key=value text information with a simple 3094 syntax in the data segment. 3096 The Login Phase proceeds through several stages (security 3097 negotiation, operational parameter negotiation) that are selected 3098 with two binary coded fields in the header -- the "current stage" 3099 (CSG) and the "next stage" (NSG) with the appearance of the latter 3100 being signaled by the "transit" flag (T). 3102 The first Login Phase of a session plays a special role, called 3103 the leading login, which determines some header fields (e.g., the 3104 version number, the maximum number of connections, and the session 3105 identification). 3107 The CmdSN initial value is also set by the leading login. 3109 StatSN for each connection is initiated by the connection login. 3111 A login request may indicate an implied logout (cleanup) of the 3112 connection to be logged in (a connection restart) by using the 3113 same Connection ID (CID) as an existing connection as well as the 3114 same session identifying elements of the session to which the old 3115 connection was associated. 3117 4.6.3.3. Logout Request and Response 3119 Logout Requests and Responses are used for the orderly closing of 3120 connections for recovery or maintenance. The logout request may be 3121 issued following a target prompt (through an asynchronous message) 3122 or at an initiators initiative. When issued on the connection to 3123 be logged out no other request may follow it. 3125 The Logout response indicates that the connection or session 3126 cleanup is completed and no other responses will arrive on the 3127 connection (if received on the logging out connection). In 3128 addition, the Logout Response indicates how long the target will 3129 continue to hold resources for recovery (e.g., command execution 3130 that continues on a new connection) in the text key Time2Retain 3131 and how long the initiator must wait before proceeding with 3132 recovery in the text key Time2Wait. 3134 4.6.3.4. SNACK Request 3136 With the SNACK Request, the initiator requests retransmission of 3137 numbered-responses or data from the target. A single SNACK request 3138 covers a contiguous set of missing items, called a run, of a given 3139 type of items. The type is indicated in a type field in the PDU 3140 header. The run is composed of an initial item (StatSN, DataSN, 3141 R2TSN) and the number of missed Status, Data, or R2T PDUs. For 3142 long data-in sequences, the target may request (at predefined 3143 minimum intervals) a positive acknowledgement for the data sent. A 3144 SNACK request with a type field that indicates ACK and the number 3145 of Data-In PDUs acknowledged conveys this positive 3146 acknowledgement. 3148 4.6.3.5. Reject 3150 Reject enables the target to report an iSCSI error condition 3151 (e.g., protocol, unsupported option) that uses a Reason field in 3152 the PDU header and includes the complete header of the bad PDU in 3153 the Reject PDU data segment. 3155 4.6.3.6. NOP-Out Request and NOP-In Response 3157 This request/response pair may be used by an initiator and target 3158 as a "ping" mechanism to verify that a connection/session is still 3159 active and all of its components are operational. Such a ping may 3160 be triggered by the initiator or target. The triggering party 3161 indicates that it wants a reply by setting a value different from 3162 the default 0xffffffff in the corresponding Initiator/Target 3163 Transfer Tag. 3165 NOP-In/NOP-Out may also be used "unidirectional" to convey to the 3166 initiator/target command, status or data counter values when there 3167 is no other "carrier" and there is a need to update the 3168 initiator/target. 3170 5. SCSI Mode Parameters for iSCSI 3172 There are no iSCSI specific mode pages. 3174 6. Login and Full Feature Phase Negotiation 3176 iSCSI parameters are negotiated at session or connection 3177 establishment by using Login Requests and Responses (see Section 3178 4.2.4 - "iSCSI Login") and during Full Feature Phase (Section 3179 4.2.5- "iSCSI Full Feature Phase") by using Text Requests and 3180 Responses. In both cases the mechanism used is an exchange of 3181 iSCSI-text-key=value pairs. For brevity, iSCSI-text-keys are 3182 called just keys in the rest of this document. 3184 Keys are either declarative or require negotiation and the key 3185 description indicates if the key is declarative or requires 3186 negotiation. 3188 For the declarative keys the declaring party sets a value for the 3189 key. The key specification indicates if the key can be declared by 3190 the initiator, target or both. 3192 For the keys that require negotiation, one of the parties (the 3193 proposing party) proposes a value or set of values by including 3194 the key=value in the data part of a Login or Text Request or 3195 Response. The other party (the accepting party) makes a selection 3196 based on the value or list of values proposed and includes the 3197 selected value in a key=value in the data part of the following 3198 Login or Text Response or Request. For most of the keys, both the 3199 initiator and target can be proposing parties. 3201 The login process proceeds in two stages - the security 3202 negotiation stage and the operational parameter negotiation stage. 3203 Both stages are optional but at least one of them has to be 3204 present to enable setting some mandatory parameters. 3206 If present, the security negotiation stage precedes the 3207 operational parameter negotiation stage. 3209 Progression from stage to stage is controlled by the T 3210 (Transition) bit in the Login Request/Response PDU header. Through 3211 the T bit set to 1, the initiator indicates that it would like to 3212 transition. The target agrees to the transition (and selects the 3213 next stage) when ready. A field in the Login PDU header indicates 3214 the current stage (CSG) and during transition, another field 3215 indicates the next stage (NSG) proposed (initiator) and selected 3216 (target). 3218 The Text negotiation process is used to negotiate or declare 3219 operational parameters. The negotiation process is controlled by 3220 the F (final) bit in the PDU header. During text negotiations, the 3221 F bit is used by the initiator to indicate that it is ready to 3222 finish the negotiation and by the Target to acquiesce the end of 3223 negotiation. 3225 Since some key=value pairs may not fit entirely in a single PDU, 3226 the C (continuation) bit is used (both in Login and Text) to 3227 indicate that "more follows". 3229 The text negotiation uses an additional mechanism by which a 3230 target may deliver larger amounts of data to an enquiring 3231 initiator. The target sets a Target Task Tag to be used as a 3232 bookmark which when returned by the initiator, means "go on". If 3233 reset to a "neutral value", it means "forget about the rest". 3235 This chapter details types of keys and values used, the syntax 3236 rules for parameter formation, and the negotiation schemes to be 3237 used with different types of parameters. 3239 6.1. Text Format 3241 The initiator and target send a set of key=value pairs encoded in 3242 UTF-8 Unicode. All the text keys and text values specified in this 3243 document are to be presented and interpreted in the case in which 3244 they appear in this document. They are case sensitive. 3246 The following character symbols are used in this document for text 3247 items (the hexadecimal values represent Unicode code points): 3249 (a-z, A-Z) - letters 3250 (0-9) - digits 3251 " " (0x20) - space 3252 "." (0x2e) - dot 3253 "-" (0x2d) - minus 3254 "+" (0x2b) - plus 3255 "@" (0x40) - commercial at 3256 "_" (0x5f) - underscore 3258 "=" (0x3d) - equal 3259 ":" (0x3a) - colon 3260 "/" (0x2f) - solidus or slash 3261 "[" (0x5b) - left bracket 3262 "]" (0x5d) - right bracket 3263 null (0x00) - null separator 3264 "," (0x2c) - comma 3265 "~" (0x7e) - tilde 3267 Key=value pairs may span PDU boundaries. An initiator or target 3268 that sends partial key=value text within a PDU indicates that more 3269 text follows by setting the C bit in the Text or Login Request or 3270 Text or Login Response to 1. Data segments in a series of PDUs 3271 that have the C bit set to 1 and end with a PDU that have the C 3272 bit set to 0, or include a single PDU that has the C bit set to 0 3273 have to be considered as forming a single logical-text-data- 3274 segment (LTDS). 3276 Every key=value pair, including the last or only pair in a LTDS, 3277 MUST be followed by one null (0x00) delimiter. 3279 A key-name is whatever precedes the first = in the key=value pair. 3280 The term key is used frequently in this document in place of key- 3281 name. 3283 A value is whatever follows the first = in the key=value pair up 3284 to the end of the key=value pair, but not including the null 3285 delimiter. 3287 The following definitions will be used in the rest of this 3288 document: 3290 standard-label: A string of one or more characters that 3291 consist of letters, digits, dot, minus, plus, commercial at, 3292 or underscore. A standard-label MUST begin with a capital 3293 letter and must not exceed 63 characters. 3295 key-name: A standard-label. 3297 text-value: A string of zero or more characters that consist 3298 of letters, digits, dot, minus, plus, commercial at, 3299 underscore, slash, left bracket, right bracket, or colon. 3301 iSCSI-name-value: A string of one or more characters that 3302 consist of minus, dot, colon, or any character allowed by 3303 the output of the iSCSI string-prep template as specified in 3304 [RFC3722] (see also Section 4.2.7.2- "iSCSI Name Encoding"). 3306 iSCSI-local-name-value: A UTF-8 string; no null characters are 3307 allowed in the string. This encoding is to be used for 3308 localized (internationalized) aliases. 3310 boolean-value: The string "Yes" or "No". 3312 hex-constant: A hexadecimal constant encoded as a string that 3313 starts with "0x" or "0X" followed by one or more digits or 3314 the letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex- 3315 constants are used to encode numerical values or binary 3316 strings. When used to encode numerical values, the excessive 3317 use of leading 0 digits is discouraged. The string following 3318 0X (or 0x) represents a base16 number that starts with the 3319 most significant base16 digit, followed by all other digits 3320 in decreasing order of significance and ending with the 3321 least-significant base16 digit. When used to encode binary 3322 strings, hexadecimal constants have an implicit byte-length 3323 that includes four bits for every hexadecimal digit of the 3324 constant, including leading zeroes. For example, a hex- 3325 constant of n hexadecimal digits has a byte-length of (the 3326 integer part of) (n+1)/2. 3328 decimal-constant: An unsigned decimal number with the digit 0 3329 or a string of one or more digits that start with a non-zero 3331 digit. Decimal-constants are used to encode numerical 3332 values or binary strings. Decimal constants can only be used 3333 to encode binary strings if the string length is explicitly 3334 specified. There is no implicit length for decimal strings. 3335 Decimal-constant MUST NOT be used for parameter values if 3336 the values can be equal or greater than 2**64 (numerical) or 3337 for binary strings that can be longer than 64 bits. 3339 base64-constant: base64 constant encoded as a string that 3340 starts with "0b" or "0B" followed by 1 or more digits or 3341 letters or plus or slash or equal. The encoding is done 3342 according to [RFC2045] and each character, except equal, 3343 represents a base64 digit or a 6-bit binary string. Base64- 3344 constants are used to encode numerical-values or binary 3345 strings. When used to encode numerical values, the excessive 3346 use of leading 0 digits (encoded as A) is discouraged. The 3347 string following 0B (or 0b) represents a base64 number that 3348 starts with the most significant base64 digit, followed by 3349 all other digits in decreasing order of significance and 3350 ending with the least-significant base64 digit; the least 3351 significant base64 digit may be optionally followed by pad 3352 digits (encoded as equal) that are not considered as part of 3353 the number. When used to encode binary strings, base64- 3354 constants have an implicit byte-length that includes six 3355 bits for every character of the constant, excluding trailing 3356 equals (i.e., a base64-constant of n base64 characters 3357 excluding the trailing equals has a byte-length of ((the 3358 integer part of) (n*3/4)). Correctly encoded base64 strings 3359 cannot have n values of 1, 5 ... k*4+1. 3361 numerical-value: An unsigned integer always less than 2**64 3362 encoded as a decimal-constant or a hex-constant. Unsigned 3363 integer arithmetic applies to numerical-values. 3365 large-numerical-value: An unsigned integer that can be larger 3366 than or equal to 2**64 encoded as a hex constant, or base64- 3367 constant. Unsigned integer arithmetic applies to large- 3368 numeric-values. 3370 numeric-range: Two numerical-values separated by a tilde where 3371 the value to the right of tilde must not be lower than the 3372 value to the left. 3374 regular-binary-value: A binary string not longer than 64 bits 3375 encoded as a decimal constant, hex constant, or base64- 3376 constant. The length of the string is either specified by 3377 the key definition or is the implicit byte-length of the 3378 encoded string. 3380 large-binary-value: A binary string longer than 64 bits 3381 encoded as a hex-constant or base64-constant. The length of 3382 the string is either specified by the key definition or is 3383 the implicit byte-length of the encoded string. 3385 binary-value: A regular-binary-value or a large-binary-value. 3386 Operations on binary values are key specific. 3388 simple-value: Text-value, iSCSI-name-value, boolean-value, 3389 numeric-value, a numeric-range, or a binary-value. 3391 list-of-values: A sequence of text-values separated by a 3392 comma. 3394 If not otherwise specified, the maximum length of a simple-value 3395 (not its encoded representation) is 255 bytes not including the 3396 delimiter (comma or zero byte). 3398 Any iSCSI target or initiator MUST support receiving at least 8192 3399 bytes of key=value data in a negotiation sequence. When proposing 3400 or accepting authentication methods that explicitly require 3401 support for very long authentication items, the initiator and 3402 target MUST support receiving of at least 64 kilobytes of 3403 key=value data. 3405 6.2. Text Mode Negotiation 3407 During login, and thereafter, some session or connection 3408 parameters are either declared or negotiated through an exchange 3409 of textual information. 3411 The initiator starts the negotiation and/or declaration through a 3412 Text or Login request and indicates when it is ready for 3413 completion (by setting the F bit to 1 and keeping it to 1 in a 3414 Text Request or the T bit in the Login Request). As negotiation 3415 text may span PDU boundaries, a Text or Login Request or Text or 3416 Login Response PDU that have the C bit set to 1 MUST NOT have the 3417 F/T bit set to 1. 3419 A target receiving a Text or Login Request with the C bit set to 1 3420 MUST answer with a Text or Login Response with no data segment 3421 (DataSegmentLength 0). An initiator receiving a Text or Login 3422 Response with the C bit set to 1 MUST answer with a Text or Login 3423 Request with no data segment (DataSegmentLength 0). 3425 A target or initiator SHOULD NOT use a Text or Login Response or 3426 Text or Login Request with no data segment (DataSegmentLength 0) 3427 unless explicitly required by a general or a key-specific 3428 negotiation rule. 3430 There MUST NOT be more than one outstanding Text Request, or Text 3431 Response PDU on an iSCSI connection. An outstanding PDU in this 3432 context is one that has not been acknowledged by the remote iSCSI 3433 side. 3435 The format of a declaration is: 3437 Declarer-> = 3439 The general format of text negotiation is: 3441 Proposer-> = 3443 Acceptor-> ={|NotUnderstood|Irrelevant|Reject} 3445 Thus a declaration is a one-way textual exchange (unless the key 3446 is not understood by the receiver) while a negotiation is a two- 3447 way exchange. 3449 The proposer or declarer can either be the initiator or the 3450 target, and the acceptor can either be the target or initiator, 3451 respectively. Targets are not limited to respond to key=value 3452 pairs as proposed by the initiator. The target may propose 3453 key=value pairs of its own. 3455 All negotiations are explicit (i.e., the result MUST only be based 3456 on newly exchanged or declared values). There are no implicit 3457 proposals. If a proposal is not made, then a reply cannot be 3458 expected. Conservative design also requires that default values 3459 should not be relied upon when use of some other value has serious 3460 consequences. 3462 The value proposed or declared can be a numerical-value, a 3463 numerical-range defined by lower and upper value with both 3464 integers separated by tilde, a binary value, a text-value, an 3465 iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes 3466 or No), or a list of comma separated text-values. A range, a 3467 large-numerical-value, an iSCSI-name-value and an iSCSI-local- 3468 name-value MAY ONLY be used if it is explicitly allowed. An 3469 accepted value can be a numerical-value, a large-numerical-value, 3470 a text-value, or a boolean-value. 3472 If a specific key is not relevant for the current negotiation, the 3473 acceptor may answer with the constant "Irrelevant" for all types 3474 of negotiation. However the negotiation is not considered as 3475 failed if the answer is "Irrelevant". The "Irrelevant" answer is 3476 meant for those cases in which several keys are presented by a 3477 proposing party but the selection made by the acceptor for one of 3478 the keys makes other keys irrelevant. The following example 3479 illustrates the use of "Irrelevant": 3481 I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192 3482 T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant 3484 I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb) 3485 T->I X#vkey1=None,X#vkey2=Irrelevant 3487 Any key not understood by the acceptor may be ignored by the 3488 acceptor without affecting the basic function. However, the answer 3489 for a key not understood MUST be key=NotUnderstood. Note that 3490 NotUnderstood is a valid answer for both declarative and 3491 negotiated keys. The general iSCSI philosophy is that 3492 comprehension precedes processing for any iSCSI key. A proposer 3493 of an iSCSI key, negotiated or declarative, in a text key exchange 3494 MUST thus be able to properly handle a NotUnderstood response. 3496 The proper way to handle a NotUnderstood response depends on where 3497 the key is specified and whether the key is declarative vs. 3498 negotiated. An iSCSI implementation MUST comprehend all text keys 3499 defined in iSCSI Protocol specifications from [RFC3720] through 3500 the RFC associated with the highest protocol version that the 3501 implementation has offered (or has negotiated, in the case of an 3502 acceptor) for the iSCSIProtocolLevel key in a negotiation. 3503 Returning a NotUnderstood response on any of these text keys 3504 therefore MUST be considered a protocol error and handled 3505 accordingly. For all other "later" keys, i.e. text keys defined 3506 in specifications associated with higher values of 3507 iSCSIProtocolLevel, a NotUnderstood answer concludes the 3508 negotiation for a negotiated key whereas for a declarative key, a 3509 NotUnderstood answer simply informs the declarer of a lack of 3510 comprehension by the receiver. 3512 In either case, a NotUnderstood answer always requires that the 3513 protocol behavior associated with that key not be used within the 3514 scope of the key (connection/session) by either side. 3516 The constants "None", "Reject", "Irrelevant", and "NotUnderstood" 3517 are reserved and MUST ONLY be used as described here. Violation of 3518 this rule is a protocol error (in particular the use of "Reject", 3519 "Irrelevant", and "NotUnderstood" as proposed values). 3521 Reject or Irrelevant are legitimate negotiation options where 3522 allowed but their excessive use is discouraged. A negotiation is 3523 considered complete when the acceptor has sent the key value pair 3524 even if the value is "Reject", "Irrelevant", or "NotUnderstood". 3525 Sending the key again would be a re-negotiation and is forbidden 3526 for many keys. 3528 If the acceptor sends "Reject" as an answer the negotiated key is 3529 left at its current value (or default if no value was set). If the 3530 current value is not acceptable to the proposer on the connection 3531 or to the session it is sent, the proposer MAY choose to terminate 3532 the connection or session. 3534 All keys in this document, except for the X extension formats, 3535 MUST be supported by iSCSI initiators and targets when used as 3536 specified here. If used as specified, these keys MUST NOT be 3537 answered with NotUnderstood. 3539 Implementers may introduce new keys by prefixing them with X- 3540 followed by their (reversed) domain name, or with new keys 3541 registered with IANA prefixing them with X#. For example, the 3542 entity owning the domain example.com can issue: 3544 X-com.example.bar.foo.do_something=3 3546 or a new registered key may be used as in: 3548 X#SuperCalyPhraGilistic=Yes 3550 Implementers MAY also introduce new values, but ONLY for new keys 3551 or authentication methods (see Section 12 - "iSCSI Security Text 3552 Keys and Authentication Methods"), or digests (see Section 13.1 - 3553 "HeaderDigest and DataDigest"). 3555 Whenever parameter action or acceptance are dependent on other 3556 parameters, the dependency rules and parameter sequence must be 3557 specified with the parameters. 3559 In the Login Phase (see Login Phase), every stage is a separate 3560 negotiation. In the FullFeaturePhase, a Text Request Response 3561 sequence is a negotiation. Negotiations MUST be handled as atomic 3562 operations. For example, all negotiated values go into effect 3563 after the negotiation concludes in agreement or are ignored if the 3564 negotiation fails. 3566 Some parameters may be subject to integrity rules (e.g., 3567 parameter-x must not exceed parameter-y or parameter-u not 1 3568 implies parameter-v be Yes). Whenever required, integrity rules 3569 are specified with the keys. Checking for compliance with the 3570 integrity rule must only be performed after all the parameters are 3571 available (the existent and the newly negotiated). An iSCSI target 3572 MUST perform integrity checking before the new parameters take 3573 effect. An initiator MAY perform integrity checking. 3575 An iSCSI initiator or target MAY terminate a negotiation that does 3576 not end within a reasonable time or number of exchanges. 3578 6.2.1. List negotiations 3580 In list negotiation, the originator sends a list of values (which 3581 may include "None") in its order of preference. 3583 The responding party MUST respond with the same key and the first 3584 value that it supports (and is allowed to use for the specific 3585 originator) selected from the originator list. 3587 The constant "None" MUST always be used to indicate a missing 3588 function. However, "None" is only a valid selection if it is 3589 explicitly proposed. 3591 If an acceptor does not understand any particular value in a list, 3592 it MUST ignore it. If an acceptor does not support, does not 3593 understand, or is not allowed to use any of the proposed options 3594 with a specific originator, it may use the constant "Reject" or 3595 terminate the negotiation. The selection of a value not proposed 3596 MUST be handled as a protocol error. 3598 6.2.2. Simple-value Negotiations 3600 For simple-value negotiations, the accepting party MUST answer 3601 with the same key. The value it selects becomes the negotiation 3602 result. 3604 Proposing a value not admissible (e.g., not within the specified 3605 bounds) MAY be answered with the constant "Reject" or the acceptor 3606 MAY select an admissible value. 3608 The selection, by the acceptor, of a value not admissible under 3609 the selection rules is considered a protocol error. The selection 3610 rules are key-specific. 3612 For a numerical range the value selected must be an integer within 3613 the proposed range or "Reject" (if the range is unacceptable). 3615 For Boolean negotiations (i.e., keys taking the values Yes or No), 3616 the accepting party MUST answer with the same key and the result 3617 of the negotiation when the received value does not determine that 3618 result by itself. The last value transmitted becomes the 3619 negotiation result. The rules for selecting the value to answer 3620 with are expressed as Boolean functions of the value received, and 3621 the value that the accepting party would have selected if given a 3622 choice. 3624 Specifically, the two cases in which answers are OPTIONAL are: 3626 - The Boolean function is "AND" and the value "No" is 3627 received. The outcome of the negotiation is "No". 3629 - The Boolean function is "OR" and the value "Yes" is 3630 received. The outcome of the negotiation is "Yes". 3632 Responses are REQUIRED in all other cases, and the value chosen 3633 and sent by the acceptor becomes the outcome of the negotiation. 3635 6.3. Login Phase 3637 The Login Phase establishes an iSCSI connection between an 3638 initiator and a target; it creates also a new session or 3639 associates the connection to an existing session. The Login Phase 3640 sets the iSCSI protocol parameters, security parameters, and 3641 authenticates the initiator and target to each other. 3643 The Login Phase is only implemented via Login request and 3644 responses. The whole Login Phase is considered as a single task 3645 and has a single Initiator Task Tag (similar to the linked SCSI 3646 commands). 3648 There MUST NOT be more than one outstanding Login Request, or 3649 Login Response on an iSCSI connection. An outstanding PDU in this 3650 context is one that has not been acknowledged by the remote iSCSI 3651 side. 3653 The default MaxRecvDataSegmentLength is used during Login. 3655 The Login Phase sequence of requests and responses proceeds as 3656 follows: 3658 - Login initial request 3660 - Login partial response (optional) 3662 - More Login requests and responses (optional) 3664 - Login Final-Response (mandatory) 3666 The initial login request of any connection MUST include the 3667 InitiatorName key=value pair. The initial login request of the 3668 first connection of a session MAY also include the SessionType 3669 key=value pair. For any connection within a session whose type is 3670 not "Discovery", the first login request MUST also include the 3671 TargetName key=value pair. 3673 The Login Final-response accepts or rejects the Login request. 3675 The Login Phase MAY include a SecurityNegotiation stage and a 3676 LoginOperationalNegotiation stage and MUST include at least one of 3677 them, but the included stage MAY be empty except for the mandatory 3678 names. 3680 The login requests and responses contain a field (CSG) that 3681 indicates the current negotiation stage (SecurityNegotiation or 3682 LoginOperationalNegotiation). If both stages are used, the 3683 SecurityNegotiation MUST precede the LoginOperationalNegotiation. 3685 Some operational parameters can be negotiated outside the login 3686 through Text requests and responses. 3688 Security MUST be completely negotiated within the Login Phase. The 3689 use of underlying IPsec security is specified in Chapter 8 and in 3690 [RFC3723]. iSCSI support for security within the protocol only 3691 consists of authentication in the Login Phase. 3693 In some environments, a target or an initiator is not interested 3694 in authenticating its counterpart. It is possible to bypass 3695 authentication through the Login request and response. 3697 The initiator and target MAY want to negotiate iSCSI 3698 authentication parameters. Once this negotiation is completed, the 3699 channel is considered secure. 3701 Most of the negotiation keys are only allowed in a specific stage. 3702 The SecurityNegotiation keys appear in Chapter 11 and the 3703 LoginOperationalNegotiation keys appear in Chapter 12. Only a 3704 limited set of keys (marked as Any-Stage in Chapter 12) may be 3705 used in any of the two stages. 3707 Any given Login request or response belongs to a specific stage; 3708 this determines the negotiation keys allowed with the request or 3709 response. It is considered to be a protocol error to send a key 3710 not allowed in the current stage. 3712 Stage transition is performed through a command exchange 3713 (request/response) that carries the T bit and the same CSG code. 3714 During this exchange, the next stage is selected by the target 3715 through the "next stage" code (NSG). The selected NSG MUST NOT 3716 exceed the value stated by the initiator. The initiator can 3717 request a transition whenever it is ready, but a target can only 3718 respond with a transition after one is proposed by the initiator. 3720 In a negotiation sequence, the T bit settings in one pair of login 3721 request-responses have no bearing on the T bit settings of the 3722 next pair. An initiator that has a T bit set to 1 in one pair and 3723 is answered with a T bit setting of 0 may issue the next request 3724 with T bit set to 0. 3726 When a transition is requested by the initiator and acknowledged 3727 by the target, both the initiator and target switch to the 3728 selected stage. 3730 Targets MUST NOT submit parameters that require an additional 3731 initiator login request in a login response with the T bit set to 3732 1. 3734 Stage transitions during login (including entering and exit) are 3735 only possible as outlined in the following table: 3737 +-----------------------------------------------------------+ 3738 |From To -> | Security | Operational | FullFeature | 3739 | | | | | | 3740 | V | | | | 3741 +-----------------------------------------------------------+ 3742 | (start) | yes | yes | no | 3743 +-----------------------------------------------------------+ 3744 | Security | no | yes | yes | 3745 +-----------------------------------------------------------+ 3746 | Operational | no | no | yes | 3747 +-----------------------------------------------------------+ 3749 The Login Final-Response that accepts a Login Request can only 3750 come as a response to a Login request with the T bit set to 1, 3751 and both the request and response MUST indicate FullFeaturePhase 3752 as the next phase via the NSG field. 3754 Neither the initiator nor the target should attempt to declare or 3755 negotiate a parameter more than once during login except for 3756 responses to specific keys that explicitly allow repeated key 3757 declarations (e.g., TargetAddress). An attempt to 3758 renegotiate/redeclare parameters not specifically allowed MUST be 3759 detected by the initiator and target. If such an attempt is 3760 detected by the target, the target MUST respond with Login reject 3761 (initiator error); if detected by the initiator, the initiator 3762 MUST drop the connection. 3764 6.3.1. Login Phase Start 3766 The Login Phase starts with a login request from the initiator to 3767 the target. The initial login request includes: 3769 -Protocol version supported by the initiator. 3771 -iSCSI Initiator Name and iSCSI Target Name 3773 -ISID, TSIH, and connection Ids 3775 -Negotiation stage that the initiator is ready to enter. 3777 A login may create a new session or it may add a connection to an 3778 existing session. Between a given iSCSI Initiator Node (selected 3779 only by an InitiatorName) and a given iSCSI target defined by an 3780 iSCSI TargetName and a Target Portal Group Tag, the login results 3781 are defined by the following table: 3783 +----------------------------------------------------------------+ 3784 |ISID | TSIH | CID | Target action | 3785 +----------------------------------------------------------------+ 3786 |new | non-zero | any | fail the login | 3787 | | | | ("session does not exist") | 3788 +----------------------------------------------------------------+ 3789 |new | zero | any | instantiate a new session | 3790 +----------------------------------------------------------------+ 3791 |existing| zero | any | do session reinstatement | 3792 | | | | (see Section 6.3.5) | 3793 +----------------------------------------------------------------+ 3794 |existing| non-zero | new | add a new connection to | 3795 | | existing | | the session | 3796 +----------------------------------------------------------------+ 3797 |existing| non-zero |existing| do connection reinstatement| 3798 | | existing | | (see Section 7.1.4.3) | 3799 +----------------------------------------------------------------+ 3800 |existing| non-zero | any | fail the login | 3801 | | new | | ("session does not exist") | 3802 +----------------------------------------------------------------+ 3804 Determination of "existing" or "new" are made by the target. 3806 Optionally, the login request may include: 3808 -Security parameters 3809 OR 3811 -iSCSI operational parameters 3812 AND/OR 3814 -The next negotiation stage that the initiator is ready to 3815 enter. 3817 The target can answer the login in the following ways: 3819 -Login Response with Login reject. This is an immediate 3820 rejection from the target that causes the connection to 3821 terminate and the session to terminate if this is the first 3822 (or only) connection of a new session. The T bit and the CSG 3823 and NSG fields are reserved. 3825 -Login Response with Login accept as a final response (T bit 3826 set to 1 and the NSG in both request and response are set to 3827 FullFeaturePhase). The response includes the protocol 3828 version supported by the target and the session ID, and may 3829 include iSCSI operational or security parameters (that 3830 depend on the current stage). 3832 -Login Response with Login Accept as a partial response (NSG 3833 not set to FullFeaturePhase in both request and response) 3835 that indicates the start of a negotiation sequence. The 3836 response includes the protocol version supported by the 3837 target and either security or iSCSI parameters (when no 3838 security mechanism is chosen) supported by the target. 3840 If the initiator decides to forego the SecurityNegotiation stage, 3841 it issues the Login with the CSG set to 3842 LoginOperationalNegotiation and the target may reply with a Login 3843 Response that indicates that it is unwilling to accept the 3844 connection (see Section 11.13 - "Login Response") without 3845 SecurityNegotiation and will terminate the connection with a 3846 response of Authentication failure (see Section 11.13.5 - "Status- 3847 Class and Status-Detail"). 3849 If the initiator is willing to negotiate iSCSI security, but is 3850 unwilling to make the initial parameter proposal and may accept a 3851 connection without iSCSI security, it issues the Login with the T 3852 bit set to 1, the CSG set to SecurityNegotiation, and NSG set to 3853 LoginOperationalNegotiation. If the target is also ready to skip 3854 security, the login response only contains the 3855 TargetPortalGroupTag key (see Section 13.9- 3856 "TargetPortalGroupTag"), the T bit set to 1, the CSG set to 3857 SecurityNegotiation, and NSG set to LoginOperationalNegotiation. 3859 An initiator that chooses to operate without iSCSI security and 3860 with all the operational parameters taking the default values 3861 issues the Login with the T bit set to 1, the CSG set to 3862 LoginOperationalNegotiation, and NSG set to FullFeaturePhase. If 3863 the target is also ready to forego security and can finish its 3864 LoginOperationalNegotiation, the Login response has T bit set to 3865 1, the CSG set to LoginOperationalNegotiation, and NSG set to 3866 FullFeaturePhase in the next stage. 3868 During the Login Phase the iSCSI target MUST return the 3869 TargetPortalGroupTag key with the first Login Response PDU with 3870 which it is allowed to do so (i.e., the first Login Response 3871 issued after the first Login Request with the C bit set to 0) for 3872 all session types. The TargetPortalGroupTag key value indicates 3873 the iSCSI portal group servicing the Login Request PDU. If the 3874 reconfiguration of iSCSI portal groups is a concern in a given 3875 environment, the iSCSI initiator should use this key to ascertain 3876 that it had indeed initiated the Login Phase with the intended 3877 target portal group. 3879 6.3.2. iSCSI Security Negotiation 3881 The security exchange sets the security mechanism and 3882 authenticates 3883 the initiator user and the target to each other. The exchange 3884 proceeds according to the authentication method chosen in the 3885 negotiation phase and is conducted using the login requests' and 3886 responses' key=value parameters. 3888 An initiator directed negotiation proceeds as follows: 3890 -The initiator sends a login request with an ordered list of 3891 the options it supports (authentication algorithm). The 3892 options are listed in the initiator's order of preference. 3893 The initiator MAY also send private or public extension 3894 options. 3896 -The target MUST reply with the first option in the list it 3897 supports and is allowed to use for the specific initiator 3898 unless it does not support any in which case it MUST answer 3899 with "Reject" (see Text Mode Negotiation). The parameters 3900 are encoded in UTF8 as key=value. For security parameters, 3901 see Chapter 11. 3903 -When the initiator considers that it is ready to conclude the 3904 SecurityNegotiation stage, it sets the T bit to 1 and the 3905 NSG to what it would like the next stage to be. The target 3906 will then set the T bit to 1 and set NSG to the next stage 3907 in the Login response when it finishes sending its security 3908 keys. The next stage selected will be the one the target 3909 selected. If the next stage is FullFeaturePhase, the target 3910 MUST respond with a Login Response with the TSIH value. 3912 If the security negotiation fails at the target, then the target 3913 MUST send the appropriate Login Response PDU. If the security 3914 negotiation fails at the initiator, the initiator SHOULD close the 3915 connection. 3917 It should be noted that the negotiation might also be directed by 3918 the target if the initiator does support security, but is not 3919 ready to direct the negotiation (propose options). 3921 6.3.3. Operational Parameter Negotiation During the Login Phase 3923 Operational parameter negotiation during the login MAY be done: 3925 - Starting with the first Login request if the initiator does 3926 not propose any security/ integrity option. 3928 - Starting immediately after the security negotiation if the 3929 initiator and target perform such a negotiation. 3931 Operational parameter negotiation MAY involve several Login 3932 request-response exchanges started and terminated by the 3933 initiator. The initiator MUST indicate its intent to terminate the 3934 negotiation by setting the T bit to 1; the target sets the T bit 3935 to 1 on the last response. 3937 If the target responds to a Login request that has the T bit set 3938 to 1 with a Login response that has the T bit set to 0, the 3939 initiator should keep sending the Login request (even empty) with 3940 the T bit set to 1, while it still wants to switch stage, until it 3941 receives the Login Response that has the T bit set to 1 or it 3942 receives a key that requires it to set the T bit to 0. 3944 Some session specific parameters can only be specified during the 3945 Login Phase of the first connection of a session (i.e., begun by a 3946 login request that contains a zero-valued TSIH) - the leading 3947 Login Phase (e.g., the maximum number of connections that can be 3948 used for this session). 3950 A session is operational once it has at least one connection in 3951 FullFeaturePhase. New or replacement connections can only be added 3952 to a session after the session is operational. 3954 For operational parameters, see Chapter 12. 3956 6.3.4. Connection Reinstatement 3958 Connection reinstatement is the process of an initiator logging in 3959 with a ISID-TSIH-CID combination that is possibly active from the 3960 target's perspective, which causes the implicit logging out of the 3961 connection corresponding to the CID and reinstating a new Full 3962 Feature Phase iSCSI connection in its place (with the same CID). 3963 Thus, the TSIH in the Login Request PDU MUST be non-zero and CID 3964 does not change during a connection reinstatement. The Login 3965 request performs the logout function of the old connection if an 3966 explicit logout was not performed earlier. In sessions with a 3967 single connection, this may imply the opening of a second 3968 connection with the sole purpose of cleaning up the first. Targets 3969 MUST support opening a second connection even when they do not 3970 support multiple connections in Full Feature Phase if 3971 ErrorRecoveryLevel is 2 and SHOULD support opening a second 3972 connection if ErrorRecoveryLevel is less than 2. 3974 If the operational ErrorRecoveryLevel is 2, connection 3975 reinstatement enables future task reassignment. If the operational 3976 ErrorRecoveryLevel is less than 2, connection reinstatement is the 3977 replacement of the old CID without enabling task reassignment. In 3978 this case, all the tasks that were active on the old CID must be 3979 immediately terminated without further notice to the initiator. 3981 The initiator connection state MUST be CLEANUP_WAIT (section 3982 8.1.3) when the initiator attempts a connection reinstatement. 3984 In practical terms, in addition to the implicit logout of the old 3985 connection, reinstatement is equivalent to a new connection login. 3987 6.3.5. Session Reinstatement, Closure, and Timeout 3989 Session reinstatement is the process of the initiator logging in 3990 with an ISID that is possibly active from the target's 3991 perspective. Thus implicitly logging out the session that 3992 corresponds to the ISID and reinstating a new iSCSI session in its 3993 place (with the same ISID). Therefore, the TSIH in the Login PDU 3994 MUST be zero to signal session reinstatement. Session 3995 reinstatement causes all the tasks that were active on the old 3996 session to be immediately terminated by the target without further 3997 notice to the initiator. 3999 The initiator session state MUST be FAILED (Section 8.3- "Session 4000 State Diagrams") when the initiator attempts a session 4001 reinstatement. 4003 Session closure is an event defined to be one of the following: 4005 - A successful "session close" logout. 4007 - A successful "connection close" logout for the last Full 4008 Feature Phase connection when no other connection in the 4009 session is waiting for cleanup (Section 8.2- "Connection 4010 Cleanup State Diagram for Initiators and Targets") and no 4011 tasks in the session are waiting for reassignment. 4013 Session timeout is an event defined to occur when the last 4014 connection state timeout expires and no tasks are waiting for 4015 reassignment. This takes the session to the FREE state (N6 4016 transition in the session state diagram). 4018 6.3.5.1. Loss of Nexus Notification 4020 The iSCSI layer provides the SCSI layer with the "I_T nexus loss" 4021 notification when any one of the following events happens: 4023 Successful completion of session reinstatement. 4024 Session closure event. 4025 Session timeout event. 4027 Certain SCSI object clearing actions may result due to the 4028 notification in the SCSI end nodes, as documented in Appendix F. - 4029 Clearing Effects of Various Events on Targets. 4031 6.3.6. Session Continuation and Failure 4033 Session continuation is the process by which the state of a 4034 preexisting session continues to be used by connection 4035 reinstatement (Section 6.3.4), or by adding a connection with a 4036 new CID. Either of these actions associates the new transport 4037 connection with the session state. 4039 Session failure is an event where the last Full Feature Phase 4040 connection reaches the CLEANUP_WAIT state (Section 8.2), or 4041 completes a successful recovery logout thus causing all active 4042 tasks (that are formerly allegiant to the connection) to start 4043 waiting for task reassignment. 4045 6.4. Operational Parameter Negotiation Outside the Login Phase 4047 Some operational parameters MAY be negotiated outside (after) the 4048 Login Phase. 4050 Parameter negotiation in Full Feature Phase is done through Text 4051 requests and responses. Operational parameter negotiation MAY 4052 involve several Text request-response exchanges, which the 4053 initiator always starts, terminates, and uses the same Initiator 4054 Task Tag. The initiator MUST indicate its intent to terminate the 4055 negotiation by setting the F bit to 1; the target sets the F bit 4056 to 1 on the last response. 4058 If the target responds to a Text request with the F bit set to 1 4059 with a Text response with the F bit set to 0, the initiator should 4060 keep sending the Text request (even empty) with the F bit set to 4061 1, while it still wants to finish the negotiation, until it 4062 receives the Text response with the F bit set to 1. Responding to 4063 a Text request with the F bit set to 1 with an empty (no key=value 4064 pairs) response with the F bit set to 0 is discouraged. 4066 Targets MUST NOT submit parameters that require an additional 4067 initiator Text request in a Text response with the F bit set to 1. 4069 In a negotiation sequence, the F bit settings in one pair of Text 4070 request-responses have no bearing on the F bit settings of the 4071 next pair. An initiator that has the F bit set to 1 in a request 4072 and is being answered with an F bit setting of 0 may issue the 4073 next request with the F bit set to 0. 4075 Whenever the target responds with the F bit set to 0, it MUST set 4076 the Target Transfer Tag to a value other than the default 4077 0xffffffff. 4079 An initiator MAY reset an operational parameter negotiation by 4080 issuing a Text request with the Target Transfer Tag set to the 4081 value 0xffffffff after receiving a response with the Target 4082 Transfer Tag set to a value other than 0xffffffff. A target may 4083 reset an operational parameter negotiation by answering a Text 4084 request with a Reject PDU. 4086 Neither the initiator nor the target should attempt to declare or 4087 negotiate a parameter more than once during any negotiation 4088 sequence, except for responses to specific keys that explicitly 4089 allow repeated key declarations (e.g., TargetAddress). If detected 4090 by the target, this MUST result in a Reject PDU with a reason of 4091 "protocol error". The initiator MUST reset the negotiation as 4092 outlined above. 4094 Parameters negotiated by a text exchange negotiation sequence only 4095 become effective after the negotiation sequence is completed. 4097 7. iSCSI Error Handling and Recovery 4099 7.1. Overview 4101 7.1.1. Background 4103 The following two considerations prompted the design of much of 4104 the error recovery functionality in iSCSI: 4106 An iSCSI PDU may fail the digest check and be dropped, despite 4107 being received by the TCP layer. The iSCSI layer must 4108 optionally be allowed to recover such dropped PDUs. 4110 A TCP connection may fail at any time during the data 4111 transfer. All the active tasks must optionally be allowed 4112 to be continued on a different TCP connection within the 4113 same session. 4115 Implementations have considerable flexibility in deciding what 4116 degree of error recovery to support, when to use it and by which 4117 mechanisms to achieve the required behavior. Only the externally 4118 visible actions of the error recovery mechanisms must be 4119 standardized to ensure interoperability. 4121 This chapter describes a general model for recovery in support of 4122 interoperability. See Appendix E. - "Algorithmic Presentation of 4123 Error Recovery Classes" for further detail on how the described 4124 model may be implemented. Compliant implementations do not have to 4125 match the implementation details of this model as presented, but 4126 the external behavior of such implementations must correspond to 4127 the externally observable characteristics of the presented model. 4129 7.1.2. Goals 4131 The major design goals of the iSCSI error recovery scheme are as 4132 follows: 4134 Allow iSCSI implementations to meet different requirements 4135 by defining a collection of error recovery mechanisms that 4136 implementations may choose from. 4137 Ensure interoperability between any two implementations 4138 supporting different sets of error recovery capabilities. 4140 Define the error recovery mechanisms to ensure command 4141 ordering even in the face of errors, for initiators that 4142 demand ordering. 4143 Do not make additions in the fast path, but allow moderate 4144 complexity in the error recovery path. 4145 Prevent both the initiator and target from attempting to 4146 recover the same set of PDUs at the same time. For example, 4147 there must be a clear "error recovery functionality 4148 distribution" between the initiator and target. 4150 7.1.3. Protocol Features and State Expectations 4152 The initiator mechanisms defined in connection with error recovery 4153 are: 4155 NOP-OUT to probe sequence numbers of the target (Section 4156 11.18) 4157 Command retry (Section 7.2.1) 4158 Recovery R2T support (Section 7.8) 4159 Requesting retransmission of status/data/R2T using the SNACK 4160 facility (section 11.16) 4161 Acknowledging the receipt of the data (section 11.16) 4162 Reassigning the connection allegiance of a task to a 4163 different TCP connection (Section 7.2.2) 4164 Terminating the entire iSCSI session to start afresh (Session 4165 Recovery) 4167 The target mechanisms defined in connection with error recovery 4168 are: 4170 NOP-IN to probe sequence numbers of the initiator (section 4171 11.19) 4172 Requesting retransmission of data using the recovery R2T 4173 feature (iSCSI Erro) 4174 SNACK support (section 11.16) 4175 Requesting that parts of read data be acknowledged (section 4176 11.7.2) 4177 Allegiance reassignment support (Section 7.2.2) 4178 Terminating the entire iSCSI session to force the initiator 4179 to start over (Session Recovery) 4181 For any outstanding SCSI command, it is assumed that iSCSI, in 4182 conjunction with SCSI at the initiator, is able to keep enough 4183 information to be able to rebuild the command PDU, and that 4184 outgoing data is available (in host memory) for retransmission 4185 while the command is outstanding. It is also assumed that at the 4186 target, incoming data (read data) MAY be kept for recovery or it 4187 can be reread from a device server. 4189 It is further assumed that a target will keep the "status & sense" 4190 for a command it has executed if it supports status 4191 retransmission. 4192 A target that agrees to support data retransmission is expected to 4193 be prepared to retransmit the outgoing data (i.e., Data-In) on 4194 request until either the status for the completed command is 4195 acknowledged, or the data in question has been separately 4196 acknowledged. 4198 7.1.4. Recovery Classes 4200 iSCSI enables the following classes of recovery (in the order of 4201 increasing scope of affected iSCSI tasks): 4203 - Within a command (i.e., without requiring command restart). 4205 - Within a connection (i.e., without requiring the connection 4206 to be rebuilt, but perhaps requiring command restart). 4208 - Connection recovery (i.e., perhaps requiring connections to 4209 be rebuilt and commands to be reissued). 4211 - Session recovery. 4213 The recovery scenarios detailed in the rest of this section are 4214 representative rather than exclusive. In every case, they detail 4215 the lowest class recovery that MAY be attempted. The implementer 4216 is left to decide under which circumstances to escalate to the 4217 next recovery class and/or what recovery classes to implement. 4218 Both the iSCSI target and initiator MAY escalate the error 4219 handling to an error recovery class, which impacts a larger number 4220 of iSCSI tasks in any of the cases identified in the following 4221 discussion. 4223 In all classes, the implementer has the choice of deferring errors 4224 to the SCSI initiator (with an appropriate response code), in 4225 which case the task, if any, has to be removed from the target and 4226 all the side-effects, such as ACA, must be considered. 4228 Use of within-connection and within-command recovery classes MUST 4229 NOT be attempted before the connection is in Full Feature Phase. 4231 In the detailed description of the recover classes the 4232 mandating terms (MUST, SHOULD, MAY, etc.) indicate normative 4233 actions to be executed if the recovery class is supported and 4234 used. 4236 7.1.4.1. Recovery Within-command 4238 At the target, the following cases lend themselves to within- 4239 command recovery: 4241 - Lost data PDU - realized through one of the following: 4243 Data digest error - dealt with as specified in Section 7.8, 4244 using the option of a recovery R2T. 4245 Sequence reception timeout (no data or partial-data-and-no-F- 4246 bit) - considered an implicit sequence error and dealt with 4247 as specified in Section 7.9, using the option of a recovery 4248 R2T. 4249 Header digest error, which manifests as a sequence reception 4250 timeout or a sequence error - dealt with as specified in 4251 Section 7.9, using the option of a recovery R2T. 4253 At the initiator, the following cases lend themselves to within- 4254 command recovery: 4256 Lost data PDU or lost R2T - realized through one of the 4257 following: 4259 Data digest error - dealt with as specified in Section 7.8, 4260 using the option of a SNACK. 4262 Sequence reception timeout (no status) or response reception 4263 timeout - dealt with as specified in Section 7.9, using the 4264 option of a SNACK. 4265 Header digest error, which manifests as a sequence reception 4266 timeout or a sequence error - dealt with as specified in 4267 Section 7.9, using the option of a SNACK. 4269 To avoid a race with the target, which may already have a recovery 4270 R2T or a termination response on its way, an initiator SHOULD NOT 4271 originate a SNACK for an R2T based on its internal timeouts (if 4272 any). Recovery in this case is better left to the target. 4274 The timeout values used by the initiator and target are outside 4275 the scope of this document. Sequence reception timeout is 4276 generally a large enough value to allow the data sequence transfer 4277 to be complete. 4279 7.1.4.2. Recovery Within-connection 4281 At the initiator, the following cases lend themselves to within- 4282 connection recovery: 4284 - Requests not acknowledged for a long time. Requests are 4285 acknowledged explicitly through ExpCmdSN or implicitly by 4286 receiving data and/or status. The initiator MAY retry non- 4287 acknowledged commands as specified in Retry an. 4289 - Lost iSCSI numbered Response. It is recognized by either 4290 identifying a data digest error on a Response PDU or a Data- 4291 In PDU carrying the status, or by receiving a Response PDU 4292 with a higher StatSN than expected. In the first case, 4293 digest error handling is done as specified in Section 7.8 4294 using the option of a SNACK. In the second case, sequence 4295 error handling is done as specified in Section 7.9, using 4296 the option of a SNACK. 4298 At the target, the following cases lend themselves to within- 4299 connection recovery: 4301 - Status/Response not acknowledged for a long time. The target 4302 MAY issue a NOP-IN (with a valid Target Transfer Tag or 4303 otherwise) that carries the next status sequence number it 4304 is going to use in the StatSN field. This helps the 4305 initiator detect any missing StatSN(s) and issue a SNACK for 4306 the status. 4308 The timeout values used by the initiator and the target are 4309 outside the scope of this document. 4311 7.1.4.3. Connection Recovery 4313 At an iSCSI initiator, the following cases lend themselves to 4314 connection recovery: 4316 - TCP connection failure: The initiator MUST close the 4317 connection. It then MUST either implicitly or explicitly 4318 logout the failed connection with the reason code "remove 4319 the connection for recovery" and reassign connection 4320 allegiance for all commands still in progress associated 4321 with the failed connection on one or more connections (some 4322 or all of which MAY be newly established connections) using 4323 the "Task reassign" task management function (see Section 4324 11.5.1- "Function"). For an initiator, a command is in 4325 progress as long as it has not received a response or a 4326 Data-In PDU including status. 4328 Note: The logout function is mandatory. However, a new 4329 connection establishment is only mandatory if the failed 4330 connection was the last or only connection in the session. 4332 - Receiving an Asynchronous Message that indicates one or all 4333 connections in a session has been dropped. The initiator 4334 MUST handle it as a TCP connection failure for the 4335 connection(s) referred to in the Message. 4337 At an iSCSI target, the following cases lend themselves to 4338 connection recovery: 4340 - TCP connection failure. The target MUST close the connection 4341 and, if more than one connection is available, the target 4342 SHOULD send an Asynchronous Message that indicates it has 4343 dropped the connection. Then, the target will wait for the 4344 initiator to continue recovery. 4346 7.1.4.4. Session Recovery 4348 Session recovery should be performed when all other recovery 4349 attempts have failed. Very simple initiators and targets MAY 4350 perform session recovery on all iSCSI errors and rely on recovery 4351 on the SCSI layer and above. 4353 Session recovery implies the closing of all TCP connections, 4354 internally aborting all executing and queued tasks for the given 4355 initiator at the target, terminating all outstanding SCSI commands 4356 with an appropriate SCSI service response at the initiator, and 4357 restarting a session on a new set of connection(s) (TCP connection 4358 establishment and login on all new connections). 4360 For possible clearing effects of session recovery on SCSI and 4361 iSCSI objects, refer to Appendix F. - "Clearing Effects of Various 4362 Events on Targets". 4364 7.1.5. Error Recovery Hierarchy 4366 The error recovery classes described so far are organized into a 4367 hierarchy for ease in understanding and to limit the 4368 implementation complexity. With few and well defined recovery 4369 levels interoperability is easier to achieve. The attributes of 4370 this hierarchy are as follows: 4372 Each level is a superset of the capabilities of the previous 4373 level. For example, Level 1 support implies supporting all 4374 capabilities of Level 0 and more. 4376 As a corollary, supporting a higher error recovery level means 4377 increased sophistication and possibly an increase in 4378 resource requirements. 4379 Supporting error recovery level "n" is advertised and 4380 negotiated by each iSCSI entity by exchanging the text key 4381 "ErrorRecoveryLevel=n". The lower of the two exchanged 4382 values is the operational ErrorRecoveryLevel for the 4383 session. 4385 The following diagram represents the error recovery hierarchy. 4387 + 4388 / \ 4389 / 2 \ <-- Connection recovery 4390 +-----+ 4391 / 1 \ <-- Digest failure recovery 4392 +---------+ 4393 / 0 \ <-- Session failure recovery 4394 +-------------+ 4396 The following table lists the error recovery capabilities expected 4397 from the implementations that support each error recovery level. 4399 +-------------------+--------------------------------------------+ 4400 |ErrorRecoveryLevel | Associated Error recovery capabilities | 4401 +-------------------+--------------------------------------------+ 4402 | 0 | Session recovery class | 4403 | | (Session Recovery) | 4404 +-------------------+--------------------------------------------+ 4405 | 1 | Digest failure recovery (See Note below.) | 4406 | | plus the capabilities of ER Level 0 | 4407 +-------------------+--------------------------------------------+ 4408 | 2 | Connection recovery class | 4409 | | (Connection Recovery) | 4410 | | plus the capabilities of ER Level 1 | 4411 +-------------------+--------------------------------------------+ 4413 Note: Digest failure recovery is comprised of two recovery 4414 classes: Within-Connection recovery class (Recovery Within- 4415 connection) and Within-Command recovery class (Recovery Within- 4416 command ). 4418 When a defined value of ErrorRecoveryLevel is proposed by an 4419 originator in a text negotiation, the originator MUST support the 4420 functionality defined for the proposed value and additionally, 4421 functionality corresponding to any defined value numerically less 4422 than the proposed. When a defined value of ErrorRecoveryLevel is 4423 returned by a responder in a text negotiation, the responder MUST 4424 support the functionality corresponding to the ErrorRecoveryLevel 4425 it is accepting. 4427 When either party attempts to use error recovery functionality 4428 beyond what is negotiated, the recovery attempts MAY fail unless 4429 an apriori agreement outside the scope of this document exists 4430 between the two parties to provide such support. 4432 Implementations MUST support error recovery level "0", while the 4433 rest are OPTIONAL to implement. In implementation terms, the 4434 above striation means that the following incremental 4435 sophistication with each level is required. 4437 +-------------------+--------------------------------------------- 4438 + 4439 |Level transition | Incremental requirement 4440 | 4441 +-------------------+--------------------------------------------- 4442 + 4443 | 0->1 | PDU retransmissions on the same connection 4444 | 4445 +-------------------+--------------------------------------------- 4446 + 4447 | 1->2 | Retransmission across connections and 4448 | 4449 | | allegiance reassignment 4450 | 4451 +-------------------+--------------------------------------------- 4452 + 4454 7.2. Retry and Reassign in Recovery 4456 This section summarizes two important and somewhat related iSCSI 4457 protocol features used in error recovery. 4459 7.2.1. Usage of Retry 4461 By resending the same iSCSI command PDU ("retry") in the absence 4462 of a command acknowledgement (by way of an ExpCmdSN update) or a 4463 response, an initiator attempts to "plug" (what it thinks are) the 4464 discontinuities in CmdSN ordering on the target end. Discarded 4465 command PDUs, due to digest errors, may have created these 4466 discontinuities. 4468 Retry MUST NOT be used for reasons other than plugging command 4469 sequence gaps, and in particular, cannot be used for requesting 4470 PDU retransmissions from a target. Any such PDU retransmission 4471 requests for a currently allegiant command in progress may be made 4472 using the SNACK mechanism described in section 11.16, although the 4473 usage of SNACK is OPTIONAL. 4475 If initiators, as part of plugging command sequence gaps as 4476 described above, inadvertently issue retries for allegiant 4477 commands already in progress (i.e., targets did not see the 4478 discontinuities in CmdSN ordering), the duplicate commands are 4479 silently ignored by targets as specified in section 4.2.2.1. 4481 When an iSCSI command is retried, the command PDU MUST carry the 4482 original Initiator Task Tag and the original operational 4483 attributes (e.g., flags, function names, LUN, CDB etc.) as well as 4484 the original CmdSN. The command being retried MUST be sent on the 4485 same connection as the original command unless the original 4486 connection was already successfully logged out. 4488 7.2.2. Allegiance Reassignment 4490 By issuing a "task reassign" task management request (Section 4491 11.5.1 - "Function"), the initiator signals its intent to continue 4492 an already active command (but with no current connection 4493 allegiance) as part of connection recovery. This means that a new 4494 connection allegiance is requested for the command, which seeks to 4495 associate it to the connection on which the task management 4496 request is being issued. Before the allegiance reassignment is 4497 attempted for a task, an implicit or explicit Logout with the 4498 reason code "remove the connection for recovery" (see section 4499 11.14.1) MUST be successfully completed for the previous 4500 connection to which the task was allegiant. 4502 In reassigning connection allegiance for a command, the targets 4503 SHOULD continue the command from its current state. For example, 4504 when reassigning read commands, the target SHOULD take advantage 4505 of the ExpDataSN field provided by the Task Management function 4506 request (which must be set to zero if there was no data transfer) 4507 and bring the read command to completion by sending the remaining 4508 data and sending (or resending) the status. ExpDataSN 4509 acknowledges all data sent up to, but not including, the Data-In 4510 PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However, 4511 targets may choose to send/receive all unacknowledged data or all 4512 of the data on a reassignment of connection allegiance if unable 4513 to recover or maintain accurate an state. Initiators MUST NOT 4514 subsequently request data retransmission through Data SNACK for 4515 PDUs numbered less than ExpDataSN (i.e., prior to the acknowledged 4516 sequence number). For all types of commands, a reassignment 4517 request implies that the task is still considered in progress by 4518 the initiator and the target must conclude the task appropriately 4519 if the target returns the "Function Complete" response to the 4520 reassignment request. This might possibly involve retransmission 4521 of data/R2T/status PDUs as necessary, but MUST involve the 4522 (re)transmission of the status PDU. 4524 It is OPTIONAL for targets to support the allegiance reassignment. 4525 This capability is negotiated via the ErrorRecoveryLevel text key 4526 during the login time. When a target does not support allegiance 4527 reassignment, it MUST respond with a Task Management response code 4528 of "Allegiance reassignment not supported". If allegiance 4529 reassignment is supported by the target, but the task is still 4530 allegiant to a different connection, or a successful recovery 4531 Logout of the previously allegiant connection was not performed, 4532 the target MUST respond with a Task Management response code of 4533 "Task still allegiant". 4535 If allegiance reassignment is supported by the target, the Task 4536 Management response to the reassignment request MUST be issued 4537 before the reassignment becomes effective. 4539 If a SCSI Command that involves data input is reassigned, any 4540 SNACK Tag it holds for a final response from the original 4541 connection is deleted and the default value of 0 MUST be used 4542 instead. 4544 7.3. Usage Of Reject PDU in Recovery 4546 Targets MUST NOT implicitly terminate an active task by sending a 4547 Reject PDU for any PDU exchanged during the life of the task. If 4548 the target decides to terminate the task, a Response PDU (SCSI, 4549 Text, Task, etc.) must be returned by the target to conclude the 4550 task. If the task had never been active before the Reject (i.e., 4551 the Reject is on the command PDU), targets should not send any 4552 further responses because the command itself is being discarded. 4554 The above rule means that the initiator can eventually expect a 4555 response on receiving Rejects, if the received Reject is for a PDU 4556 other than the command PDU itself. The non-command Rejects only 4557 have diagnostic value in logging the errors, and they can be used 4558 for retransmission decisions by the initiators. 4560 The CmdSN of the rejected command PDU (if it is a non-immediate 4561 command) MUST NOT be considered received by the target (i.e., a 4562 command sequence gap must be assumed for the CmdSN), even though 4563 the CmdSN of the rejected command PDU may be reliably ascertained. 4564 Upon receiving the Reject, the initiator MUST plug the CmdSN gap 4565 in order to continue to use the session. The gap may be plugged 4566 either by transmitting a command PDU with the same CmdSN, or by 4567 aborting the task (see SCS on how an abort may plug a CmdSN gap). 4569 When a data PDU is rejected and its DataSN can be ascertained, a 4570 target MUST advance ExpDataSN for the current data burst if a 4571 recovery R2T is being generated. The target MAY advance its 4572 ExpDataSN if it does not attempt to recover the lost data PDU. 4574 7.4. Error Recovery Considerations for Discovery Sessions 4576 7.4.1. ErrorRecoveryLevel for Discovery Sessions 4578 The negotiation of the key ErrorRecoveryLevel is not required for 4579 Discovery sessions -- i.e., for sessions that negotiated 4580 "SessionType=Discovery" -- because the default value of 0 is 4581 necessary and sufficient for Discovery sessions. It is however 4582 possible that some legacy iSCSI implementations might attempt to 4583 negotiate the ErrorRecoveryLevel key on Discovery sessions. When 4584 such a negotiation attempt is made by the remote side, a compliant 4585 iSCSI implementation MUST propose a value of 0 (zero) in response. 4586 The operational ErrorRecoveryLevel for Discovery sessions thus 4587 MUST 4588 be 0. This naturally follows from the functionality constraints 4589 that Section 4.3 imposes on Discovery sessions. 4591 7.4.2. Reinstatement Semantics for Discovery Sessions 4593 Discovery sessions are intended to be relatively short-lived. 4594 Initiators are not expected to establish multiple Discovery 4595 sessions to the same iSCSI Network Portal. An initiator may use 4596 the same iSCSI Initiator Name and ISID when establishing different 4597 unique sessions with different targets and/or different portal 4598 groups. This behavior is discussed in Section 10.1.1 and is, in 4599 fact, encouraged as conservative reuse of ISIDs. 4601 The ISID RULE in Section 4.4.3 states that there must not be more 4602 than one session with a matching 4-tuple: . While the spirit of the ISID 4604 RULE applies to Discovery sessions the same as it does for Normal 4605 sessions, note that some Discovery sessions differ from the Normal 4606 sessions in two important aspects: 4608 Because Appendix D allows a Discovery session to be established 4609 without specifying a TargetName key in the Login Request PDU 4610 (let us call such a session an "Unnamed" Discovery session), 4611 there is no Target Node context to enforce the ISID RULE. 4613 Portal Groups are defined only in the context of a Target Node. 4614 When the TargetName key is NULL-valued (i.e., not specified), 4615 the TargetPortalGroupTag thus cannot be ascertained to enforce 4616 the ISID RULE. 4618 The following two sections describe each of the two scenarios -- 4619 Named Discovery sessions and Unnamed Discovery sessions. 4621 7.4.2.1. Unnamed Discovery Sessions 4623 For Unnamed Discovery sessions, neither the TargetName nor the 4624 TargetPortalGroupTag is available to the targets in order to 4625 enforce the ISID RULE. So the following rule applies. 4627 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 4628 following 4-tuple for Unnamed Discovery sessions: . The following semantics are implied by 4630 this uniqueness requirement. 4632 Targets SHOULD allow concurrent establishment of one Discovery 4633 session with each of its Network Portals by the same initiator 4634 port with a given iSCSI Node Name and an ISID. Each of the 4635 concurrent Discovery sessions, if established by the same 4636 initiator port to other Network Portals, MUST be treated as 4637 independent sessions -- i.e., one session MUST NOT reinstate the 4638 other. 4640 A new Unnamed Discovery session that has a matching 4641 to an existing 4642 Discovery session MUST reinstate the existing Unnamed Discovery 4643 session. Note thus that only an Unnamed Discovery session may 4644 reinstate an Unnamed Discovery session. 4646 7.4.2.2. Named Discovery Session 4648 For a Named Discovery session, the TargetName key is specified by 4649 the initiator and thus the target can unambiguously ascertain the 4650 TargetPortalGroupTag as well. Since all the four elements of the 4651 4-tuple are known, the ISID RULE MUST be enforced by targets with 4652 no changes from Section 4.4.3 semantics. A new session with a 4653 matching 4654 thus will reinstate an existing session. Note in this case that 4655 any new iSCSI session (Discovery or Normal) with the matching 4- 4656 tuple may reinstate an existing Named Discovery iSCSI session. 4658 7.4.3. Target PDUs During Discovery 4660 Targets SHOULD NOT send any responses other than a Text Response 4661 and Logout Response on a Discovery session, once in Full Feature 4662 Phase. 4664 Implementation Note: A target may simply drop the connection in a 4665 Discovery session when it would have requested a Logout via an 4666 Async Message on Normal sessions. 4668 7.5. Connection Timeout Management 4670 iSCSI defines two session-global timeout values (in seconds) - 4671 Time2Wait and Time2Retain - that are applicable when an iSCSI Full 4672 Feature Phase connection is taken out of service either 4673 intentionally or by an exception. Time2Wait is the initial 4674 "respite time" before attempting an explicit/implicit Logout for 4675 the CID in question or task reassignment for the affected tasks 4676 (if any). Time2Retain is the maximum time after the initial 4677 respite interval that the task and/or connection state(s) is/are 4678 guaranteed to be maintained on the target to cater to a possible 4679 recovery attempt. Recovery attempts for the connection and/or 4680 task(s) SHOULD NOT be made before Time2Wait seconds, but MUST be 4681 completed within Time2Retain seconds after that initial Time2Wait 4682 waiting period. 4684 7.5.1. Timeouts on Transport Exception Events 4686 A transport connection shutdown or a transport reset without any 4687 preceding iSCSI protocol interactions informing the end-points of 4688 the fact causes a Full Feature Phase iSCSI connection to be 4689 abruptly terminated. The timeout values to be used in this case 4690 are the negotiated values of defaultTime2Wait (Section 13.15 - 4691 "DefaultTime2Wait") and DefaultTime2Retain (Section 13.16 - 4692 "DefaultTime2Retain") text keys for the session. 4694 7.5.2. Timeouts on Planned Decommissioning 4696 Any planned decommissioning of a Full Feature Phase iSCSI 4697 connection is preceded by either a Logout Response PDU, or an 4698 Async Message PDU. The Time2Wait and Time2Retain field values 4699 (section 11.15) in a Logout Response PDU, and the Parameter2 and 4700 Parameter3 fields of an Async Message (AsyncEvent types "drop the 4701 connection" or "drop all the connections"; section 11.9.1) specify 4702 the timeout values to be used in each of these cases. 4704 These timeout values are only applicable for the affected 4705 connection, and the tasks active on that connection. These 4706 timeout values have no bearing on initiator timers (if any) that 4707 are already running on connections or tasks associated with that 4708 session. 4710 7.6. Implicit Termination of Tasks 4712 A target implicitly terminates the active tasks due to iSCSI 4713 protocol dynamics in the following cases: 4715 When a connection is implicitly or explicitly logged out with 4716 the reason code of "Close the connection" and there are 4717 active tasks allegiant to that connection. 4719 When a connection fails and eventually the connection state 4720 times out (state transition M1 in Section 8.2.2- "State 4721 Transition Descriptions for Initiators and Targets") and 4722 there are active tasks allegiant to that connection. 4724 When a successful Logout with the reason code of "remove the 4725 connection for recovery" is performed while there are 4726 active tasks allegiant to that connection, and those tasks 4727 eventually time out after the Time2Wait and Time2Retain 4728 periods without allegiance reassignment. 4730 When a connection is implicitly or explicitly logged out with 4731 the reason code of "Close the session" and there are active 4732 tasks in that session. 4734 If the tasks terminated in the above cases a), b, c) and d)are 4735 SCSI tasks, they must be internally terminated as if with CHECK 4736 CONDITION status. This status is only meaningful for appropriately 4737 handling the internal SCSI state and SCSI side effects with 4738 respect to ordering because this status is never communicated back 4739 as a terminating status to the initiator. However additional 4740 actions may have to be taken at SCSI level depending on the SCSI 4741 context as defined by the SCSI standards (e.g., queued commands 4742 and ACA, UA for the next command on the I_T nexus in cases a), b), 4743 and c) etc. - see [SAM2] and [SPC3]). 4745 7.7. Format Errors 4747 The following two explicit violations of PDU layout rules are 4748 format errors: 4750 Illegal contents of any PDU header field except the Opcode 4751 (legal values are specified in Section 11 - "iSCSI PDU 4752 Formats"). 4753 Inconsistent field contents (consistent field contents are 4754 specified in Section 11 - "iSCSI PDU Formats"). 4756 Format errors indicate a major implementation flaw in one of the 4757 parties. 4759 When a target or an initiator receives an iSCSI PDU with a format 4760 error, it MUST immediately terminate all transport connections in 4761 the session either with a connection close or with a connection 4762 reset and escalate the format error to session recovery (see 4763 Section Session Recovery). 4765 All initiator-detected PDU construction errors MUST be considered 4766 as format errors. Some examples of such errors are: 4767 - NOP-In with a valid TTT but an invalid LUN 4769 - NOP-In with a valid ITT (i.e., a NOP-In response) and also a 4770 valid TTT 4772 - SCSI Response PDU with Status=CHECK CONDITION, but 4773 DataSegmentLength = 0 4775 7.8. Digest Errors 4777 The discussion of the legal choices in handling digest errors 4778 below excludes session recovery as an explicit option, but either 4779 party detecting a digest error may choose to escalate the error to 4780 session recovery. 4782 When a target or an initiator receives any iSCSI PDU, with a 4783 header digest error, it MUST either discard the header and all 4784 data up to the beginning of a later PDU or close the connection. 4785 Because the digest error indicates that the length field of the 4787 header may have been corrupted, the location of the beginning of a 4788 later PDU needs to be reliably ascertained by other means such as 4789 the operation of a sync and steering layer. 4791 When a target receives any iSCSI PDU with a payload digest error, 4792 it MUST answer with a Reject PDU with a reason code of Data- 4793 Digest-Error and discard the PDU. 4795 - If the discarded PDU is a solicited or unsolicited iSCSI 4796 data PDU (for immediate data in a command PDU, non-data PDU 4797 rule below applies), the target MUST do one of the 4798 following: 4800 i) Request retransmission with a recovery R2T. 4801 ii) Terminate the task with a response PDU with a CHECK 4802 CONDITION Status and an iSCSI Condition of "protocol 4803 service CRC error" (Section 11.4.7.2 - "Sense Data"). 4804 If the target chooses to implement this option, it MUST 4805 wait to receive all the data (signaled by a Data PDU 4806 with the final bit set for all outstanding R2Ts) before 4807 sending the response PDU. A task management command 4808 (such as an abort task) from the initiator during this 4809 wait may also conclude the task. 4810 - No further action is necessary for targets if the discarded 4811 PDU is a non-data PDU. In case of immediate data being 4812 present on a discarded command, the immediate data is 4813 implicitly recovered when the task is retried (see Section 4814 7.2.1) followed by the entire data transfer for the task. 4816 When an initiator receives any iSCSI PDU with a payload digest 4817 error, it MUST discard the PDU. 4819 - If the discarded PDU is an iSCSI data PDU, the initiator 4820 MUST do one of the following: 4822 Request the desired data PDU through SNACK. In response to 4823 the SNACK, the target MUST either resend the data 4824 PDU or reject the SNACK with a Reject PDU with a 4825 reason code of "SNACK reject" in which case: 4827 If the status has not already been sent for the command, 4828 the target MUST terminate the command with a 4829 CHECK CONDITION Status and an iSCSI Condition of 4830 "SNACK rejected" (Section 11.4.7.2 - "Sense 4831 Data"). 4832 If the status was already sent, no further action is 4833 necessary for the target. The initiator in this 4834 case MUST wait for the status to be received and 4835 then discard it, so as to internally signal the 4836 completion with CHECK CONDITION Status and an 4837 iSCSI Condition of "protocol service CRC error" 4838 (Section 11.4.7.2- "Sense Data"). 4839 Abort the task and terminate the command with an error. 4841 - If the discarded PDU is a response PDU or an unsolicited PDU 4842 (e.g. Async, Reject), the initiator MUST do one of the 4843 following: 4845 Request PDU retransmission with a status SNACK. 4846 Logout the connection for recovery and continue the tasks 4847 on a different connection instance as described 4848 in Retry an. 4849 Logout to close the connection (abort all the commands 4850 associated with the connection). 4852 Note that an unsolicited PDU carries the next StatSN value on 4853 an iSCSI connection, thereby advancing the StatSN. When an 4854 initiator discards one of these PDUs due to a payload digest 4855 error, the entire PDU including the header MUST be discarded. 4856 Consequently, the initiator MUST treat the exception like a 4857 loss of any other solicited response PDU. 4859 7.9. Sequence Errors 4861 When an initiator receives an iSCSI R2T/data PDU with an out of 4862 order R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that 4863 implies missing data PDU(s), it means that the initiator must have 4864 detected a header or payload digest error on one or more earlier 4865 R2T/data PDUs. The initiator MUST address these implied digest 4866 errors as described in Section 7.8. When a target receives a data 4867 PDU with an out of order DataSN, it means that the target must 4868 have hit a header or payload digest error on at least one of the 4869 earlier data PDUs. The target MUST address these implied digest 4870 errors as described in Section 7.8. 4872 When an initiator receives an iSCSI status PDU with an out of 4873 order StatSN that implies missing responses, it MUST address the 4874 one or more missing status PDUs as described in Section 7.8. As a 4875 side effect of receiving the missing responses, the initiator may 4876 discover missing data PDUs. If the initiator wants to recover the 4877 missing data for a command, it MUST NOT acknowledge the received 4878 responses that start from the StatSN of the relevant command, 4879 until it has completed receiving all the data PDUs of the command. 4881 When an initiator receives duplicate R2TSNs (due to proactive 4882 retransmission of R2Ts by the target) or duplicate DataSNs (due to 4883 proactive SNACKs by the initiator), it MUST discard the 4884 duplicates. 4886 7.10. Message Error Checking 4888 In the iSCSI implementations till date, there has been some 4889 uncertainty on the extent to which incoming messages have to be 4890 checked for protocol errors, beyond what is strictly required for 4891 processing the inbound message. This section addresses this 4892 question. 4894 Unless this document requires it, an iSCSI implementation is not 4895 required to do an exhaustive protocol conformance check on an 4896 incoming iSCSI PDU. The iSCSI implementation especially is not 4897 required to double-check the remote iSCSI implementation's 4898 conformance to protocol requirements. 4900 7.11. SCSI Timeouts 4902 An iSCSI initiator MAY attempt to plug a command sequence gap on 4903 the target end (in the absence of an acknowledgement of the 4904 command by way of ExpCmdSN) before the ULP timeout by retrying the 4905 unacknowledged command, as described in Section 7.2. 4907 On a ULP timeout for a command (that carried a CmdSN of n), if the 4908 iSCSI initiator intends to continue the session it MUST abort the 4909 command by either using an appropriate Task Management function 4911 request for the specific command, or a "close the connection" 4912 Logout. When using an ABORT TASK, if the ExpCmdSN is still less 4913 than (n+1), the target may see the abort request while missing the 4914 original command itself due to one of the following reasons: 4916 - Original command was dropped due to digest error. 4918 - Connection on which the original command was sent was 4919 successfully logged out. On logout, the unacknowledged 4920 commands issued on the connection being logged out are 4921 discarded. 4923 If the abort request is received and the original command is 4924 missing, targets MUST consider the original command with that 4925 RefCmdSN to be received and issue a Task Management response with 4926 the response code: "Function Complete". This response concludes 4927 the task on both ends. If the abort request is received and the 4928 target can determine (based on the Referenced Task Tag) that the 4929 command was received and executed and also that the response was 4930 sent prior to the abort, then the target MUST respond with the 4931 response code of "Task Does Not Exist". 4933 7.12. Negotiation Failures 4935 Text request and response sequences, when used to set/negotiate 4936 operational parameters, constitute the negotiation/parameter 4937 setting. A negotiation failure is considered to be one or more of 4938 the following: 4940 - None of the choices, or the stated value, is acceptable to 4941 one of the sides in the negotiation. 4943 - The text request timed out and possibly terminated. 4945 - The text request was answered with a Reject PDU. 4947 The following two rules should be used to address negotiation 4948 failures: 4950 - During Login, any failure in negotiation MUST be considered 4951 a login process failure and the Login Phase must be 4952 terminated, and with it, the connection. If the target 4953 detects the failure, it must terminate the login with the 4954 appropriate login response code. 4956 - A failure in negotiation, while in the Full Feature Phase, 4957 will terminate the entire negotiation sequence that may 4958 consist of a series of text requests that use the same 4959 Initiator Task Tag. The operational parameters of the 4960 session or the connection MUST continue to be the values 4961 agreed upon during an earlier successful negotiation (i.e., 4962 any partial results of this unsuccessful negotiation MUST 4963 NOT take effect and MUST be discarded). 4965 7.13. Protocol Errors 4967 Mapping framed messages over a "stream" connection, such as TCP, 4968 makes the proposed mechanisms vulnerable to simple software 4969 framing errors. On the other hand, the introduction of framing 4970 mechanisms to limit the effects of these errors may be onerous on 4971 performance for simple implementations. Command Sequence Numbers 4972 and the above mechanisms for connection drop and reestablishment 4973 help handle this type of mapping errors. 4975 All violations of iSCSI PDU exchange sequences specified in this 4976 draft are also protocol errors. This category of errors can only 4977 be 4978 addressed by fixing the implementations; iSCSI defines Reject and 4979 response codes to enable this. 4981 7.14. Connection Failures 4983 iSCSI can keep a session in operation if it is able to 4984 keep/establish at least one TCP connection between the initiator 4985 and the target in a timely fashion. Targets and/or initiators may 4986 recognize a failing connection by either transport level means 4987 (TCP), a gap in the command sequence number, a response stream 4988 that is not filled for a long time, or by a failing iSCSI NOP 4989 (acting as a ping). The latter MAY be used periodically to 4990 increase the speed and likelihood of detecting connection 4991 failures. Initiators and targets MAY also use the keep-alive 4992 option on the TCP connection to enable early link failure 4993 detection on otherwise idle links. 4995 On connection failure, the initiator and target MUST do one of the 4996 following: 4998 - Attempt connection recovery within the session (Connection 4999 Recovery). 5001 - Logout the connection with the reason code "closes the 5002 connection" (Section 10.14.5 - "Implicit termination of 5003 tasks"), re-issue missing commands, and implicitly terminate 5004 all active commands. This option requires support for the 5005 within-connection recovery class (Recovery Within- 5006 connection). 5008 - Perform session recovery (Session Recovery). 5010 Either side may choose to escalate to session recovery (via the 5011 initiator dropping all the connections, or via an Async Message 5012 that announces the similar intent from a target), and the other 5013 side MUST give it precedence. On a connection failure, a target 5014 MUST terminate and/or discard all of the active immediate commands 5015 regardless of which of the above options is used (i.e., immediate 5016 commands are not recoverable across connection failures). 5018 7.15. Session Errors 5020 If all of the connections of a session fail and cannot be 5021 reestablished in a short time, or if initiators detect protocol 5022 errors repeatedly, an initiator may choose to terminate a session 5023 and establish a new session. 5025 In this case, the initiator takes the following actions: 5027 - Resets or closes all the transport connections. 5029 - Terminates all outstanding requests with an appropriate 5030 response before initiating a new session. If the same I_T 5031 nexus is intended to be reestablished, the initiator MUST 5032 employ session reinstatement (see section 6.3.5). 5034 When the session timeout (the connection state timeout for the 5035 last failed connection) happens on the target, it takes the 5036 following actions: 5038 - Resets or closes the TCP connections (closes the session). 5040 - Terminates all active tasks that were allegiant to the 5041 connection(s) that constituted the session. 5043 A target MUST also be prepared to handle a session reinstatement 5044 request from the initiator that may be addressing session errors. 5046 8. State Transitions 5048 iSCSI connections and iSCSI sessions go through several well- 5049 defined states from the time they are created to the time they are 5050 cleared. 5052 The connection state transitions are described in two separate but 5053 dependent state diagrams for ease in understanding. The first 5054 diagram, "standard connection state diagram", describes the 5055 connection state transitions when the iSCSI connection is not 5056 waiting for, or undergoing, a cleanup by way of an explicit or 5057 implicit Logout. The second diagram, "connection cleanup state 5058 diagram", describes the connection state transitions while 5059 performing the iSCSI connection cleanup. 5061 The "session state diagram" describes the state transitions an 5062 iSCSI session would go through during its lifetime, and it depends 5063 on the states of possibly multiple iSCSI connections that 5064 participate in the session. 5066 States and transitions are described in text, tables and diagrams. 5067 The diagrams are used for illustration. The text and the tables 5068 are the governing specification. 5070 8.1. Standard Connection State Diagrams 5072 8.1.1. State Descriptions for Initiators and Targets 5074 State descriptions for the standard connection state diagram are 5075 as follows: 5076 -S1: FREE 5077 -initiator: State on instantiation, or after successful 5078 connection closure. 5079 -target: State on instantiation, or after successful 5080 connection closure. 5081 -S2: XPT_WAIT 5082 -initiator: Waiting for a response to its transport 5083 connection establishment request. 5084 -target: Illegal 5085 -S3: XPT_UP 5086 -initiator: Illegal 5087 -target: Waiting for the Login process to commence. 5089 -S4: IN_LOGIN 5090 -initiator: Waiting for the Login process to conclude, 5091 possibly involving several PDU exchanges. 5092 -target: Waiting for the Login process to conclude, 5093 possibly involving several PDU exchanges. 5094 -S5: LOGGED_IN 5095 -initiator: In Full Feature Phase, waiting for all 5096 internal, iSCSI, and transport events. 5097 -target: In Full Feature Phase, waiting for all internal, 5098 iSCSI, and transport events. 5099 -S6: IN_LOGOUT 5100 -initiator: Waiting for a Logout response. 5101 -target: Waiting for an internal event signaling completion 5102 of logout processing. 5103 -S7: LOGOUT_REQUESTED 5104 -initiator: Waiting for an internal event signaling 5105 readiness to proceed with Logout. 5106 -target: Waiting for the Logout process to start after 5107 having requested a Logout via an Async Message. 5108 -S8: CLEANUP_WAIT 5109 -initiator: Waiting for the context and/or resources to 5110 initiate the cleanup processing for this CSM. 5111 -target: Waiting for the cleanup process to start for this 5112 CSM. 5113 8.1.2. State Transition Descriptions for Initiators and Targets 5115 -T1: 5116 -initiator: Transport connect request was made (e.g., TCP 5117 SYN sent). 5118 -target: Illegal 5119 -T2: 5120 -initiator: Transport connection request timed out, a 5121 transport reset was received, or an internal event of 5122 receiving a Logout response (success) on another connection 5123 for a "close the session" Logout request was received. 5124 -target:Illegal 5125 -T3: 5126 -initiator: Illegal 5127 -target: Received a valid transport connection request that 5128 establishes the transport connection. 5129 -T4: 5131 -initiator: Transport connection established, thus 5132 prompting the initiator to start the iSCSI Login. 5133 -target: Initial iSCSI Login request was received. 5134 -T5: 5135 -initiator: The final iSCSI Login response with a Status- 5136 Class of zero was received. 5137 -target: The final iSCSI Login request to conclude the 5138 Login Phase was received, thus prompting the target to send 5139 the final iSCSI Login response with a Status-Class of zero. 5140 -T6: 5141 -initiator: Illegal 5142 -target: Timed out waiting for an iSCSI Login, transport 5143 disconnect indication was received, transport reset was 5144 received, or an internal event indicating a transport 5145 timeout was received. In all these cases, the connection is 5146 to be closed. 5147 -T7: 5148 -initiator - one of the following events caused the 5149 transition: 5150 - The final iSCSI Login response was received with a 5151 non-zero Status-Class. 5152 - Login timed out. 5153 - A transport disconnect indication was received. 5154 - A transport reset was received. 5155 - An internal event indicating a transport timeout was 5156 received. 5157 - An internal event of receiving a Logout response 5158 (success) on another connection for a "close the 5159 session" Logout request was received. 5161 In all these cases, the transport connection is closed. 5163 -target - one of the following events caused the 5164 transition: 5165 - The final iSCSI Login request to conclude the Login 5166 Phase was received, prompting the target to send the 5167 final iSCSI Login response with a non-zero Status- 5168 Class. 5169 - Login timed out. 5170 - Transport disconnect indication was received. 5172 - Transport reset was received. 5173 - An internal event indicating a transport timeout was 5174 received . 5175 - On another connection a "close the session" 5176 Logout request was received. 5178 In all these cases, the connection is to be closed. 5179 -T8: 5180 -initiator: An internal event of receiving a Logout 5181 response (success) on another connection for a "close the 5182 session" Logout request was received, thus closing this 5183 connection requiring no further cleanup. 5184 -target: An internal event of sending a Logout response 5185 (success) on another connection for a "close the session" 5186 Logout request was received, or an internal event of a 5187 successful connection/session reinstatement is received, 5188 thus prompting the target to close this connection cleanly. 5189 -T9, T10: 5190 -initiator: An internal event that indicates the readiness 5191 to start the Logout process was received, thus prompting an 5192 iSCSI Logout to be sent by the initiator. 5193 -target: An iSCSI Logout request was received. 5194 -T11, T12: 5195 -initiator: Async PDU with AsyncEvent "Request Logout" was 5196 received. 5197 -target: An internal event that requires the 5198 decommissioning of the connection is received, thus causing 5199 an Async PDU with an AsyncEvent "Request Logout" to be 5200 sent. 5201 -T13: 5202 -initiator: An iSCSI Logout response (success) was 5203 received, or an internal event of receiving a Logout 5204 response (success) on another connection for a "close the 5205 session" Logout request was received. 5206 -target: An internal event was received that indicates 5207 successful processing of the Logout, which prompts an iSCSI 5208 Logout response (success) to be sent; an internal event of 5209 sending a Logout response (success) on another connection 5210 for a "close the session" Logout request was received; or 5211 an internal event of a successful connection/session 5212 reinstatement is received. In all these cases, the 5213 transport connection is closed. 5215 -T14: 5216 -initiator: Async PDU with AsyncEvent "Request Logout" was 5217 received again. 5218 -target: Illegal 5219 -T15, T16: 5220 -initiator: One or more of the following events caused this 5221 transition: 5222 -Internal event that indicates a transport connection 5223 timeout was received thus prompting transport RESET or 5224 transport connection closure. 5225 -A transport RESET. 5226 -A transport disconnect indication. 5227 -Async PDU with AsyncEvent "Drop connection" (for this 5228 CID). 5229 -Async PDU with AsyncEvent "Drop all connections". 5230 -target: One or more of the following events caused this 5231 transition: 5232 -Internal event that indicates a transport connection 5233 timeout was received, thus prompting transport RESET or 5234 transport connection closure. 5235 -An internal event of a failed connection/session 5236 reinstatement is received. 5237 -A transport RESET. 5238 -A transport disconnect indication. 5239 -Internal emergency cleanup event was received which 5240 prompts an Async PDU with AsyncEvent "Drop connection" 5241 (for this CID), or event "Drop all connections". 5243 -T17: 5244 -initiator: One or more of the following events caused this 5245 transition: 5246 -Logout response, (failure i.e., a non-zero status) was 5247 received, or Logout timed out. 5248 -Any of the events specified for T15 and T16. 5249 -target: One or more of the following events caused this 5250 transition: 5252 -Internal event that indicates a failure of the Logout 5253 processing was received, which prompts a Logout 5254 response (failure, i.e., a non-zero status) to be sent. 5255 -Any of the events specified for T15 and T16. 5256 -T18: 5257 -initiator: An internal event of receiving a Logout 5258 response (success) on another connection for a "close the 5259 session" Logout request was received. 5261 -target: An internal event of sending a Logout response 5262 (success) on another connection for a "close the session" 5263 Logout request was received, or an internal event of a 5264 successful connection/session reinstatement is received. 5265 In both these cases, the connection is closed. 5267 The CLEANUP_WAIT state (S8) implies that there are possible iSCSI 5268 tasks that have not reached conclusion and are still considered 5269 busy. 5271 8.1.3. Standard Connection State Diagram for an Initiator 5273 Symbolic names for States: 5275 S1: FREE 5277 S2: XPT_WAIT 5279 S4: IN_LOGIN 5281 S5: LOGGED_IN 5283 S6: IN_LOGOUT 5285 S7: LOGOUT_REQUESTED 5287 S8: CLEANUP_WAIT 5289 States S5, S6, and S7 constitute the Full Feature Phase operation 5290 of the connection. 5292 The state diagram is as follows: 5294 -------<-------------+ 5295 +--------->/ S1 \<----+ | 5296 T13| +->\ /<-+ \ | 5297 | / ---+--- \ \ | 5298 | / | T2 \ | | 5299 | T8 | |T1 | | | 5300 | | | / |T7 | 5301 | | | / | | 5302 | | | / | | 5303 | | V / / | 5304 | | ------- / / | 5305 | | / S2 \ / | 5306 | | \ / / | 5307 | | ---+--- / | 5308 | | |T4 / | 5309 | | V / | T18 5310 | | ------- / | 5311 | | / S4 \ | 5312 | | \ / | 5313 | | ---+--- | T15 5314 | | |T5 +--------+---------+ 5315 | | | /T16+-----+------+ | 5316 | | | / -+-----+--+ | | 5317 | | | / / S7 \ |T12| | 5318 | | | / +->\ /<-+ V V 5319 | | | / / -+----- ------- 5320 | | | / /T11 |T10 / S8 \ 5321 | | V / / V +----+ \ / 5322 | | ---+-+- ----+-- | ------- 5323 | | / S5 \T9 / S6 \<+ ^ 5324 | +-----\ /--->\ / T14 | 5325 | ------- --+----+------+T17 5326 +---------------------------+ 5328 The following state transition table represents the above diagram. 5329 Each row represents the starting state for a given transition, 5330 which after taking a transition marked in a table cell would end 5331 in the state represented by the column of the cell. For example, 5332 from state S1, the connection takes the T1 transition to arrive at 5333 state S2. The fields marked "-" correspond to undefined 5334 transitions. 5336 +----+---+---+---+---+----+---+ 5337 |S1 |S2 |S4 |S5 |S6 |S7 |S8 | 5338 ---+----+---+---+---+---+----+---+ 5339 S1| - |T1 | - | - | - | - | - | 5340 ---+----+---+---+---+---+----+---+ 5341 S2|T2 |- |T4 | - | - | - | - | 5342 ---+----+---+---+---+---+----+---+ 5343 S4|T7 |- |- |T5 | - | - | - | 5344 ---+----+---+---+---+---+----+---+ 5345 S5|T8 |- |- | - |T9 |T11 |T15| 5346 ---+----+---+---+---+---+----+---+ 5347 S6|T13 |- |- | - |T14|- |T17| 5348 ---+----+---+---+---+---+----+---+ 5349 S7|T18 |- |- | - |T10|T12 |T16| 5350 ---+----+---+---+---+---+----+---+ 5351 S8| - |- |- | - | - | - | - | 5352 ---+----+---+---+---+---+----+---+ 5354 8.1.4. Standard Connection State Diagram for a Target 5356 Symbolic names for States: 5357 S1: FREE 5359 S3: XPT_UP 5361 S4: IN_LOGIN 5363 S5: LOGGED_IN 5365 S6: IN_LOGOUT 5367 S7: LOGOUT_REQUESTED 5369 S8: CLEANUP_WAIT 5371 States S5, S6, and S7 constitute the Full Feature Phase operation 5372 of the connection. 5374 The state diagram is as follows: 5375 -------<-------------+ 5376 +--------->/ S1 \<----+ | 5377 T13| +->\ /<-+ \ | 5378 | / ---+--- \ \ | 5379 | / | T6 \ | | 5380 | T8 | |T3 | | | 5381 | | | / |T7 | 5382 | | | / | | 5383 | | | / | | 5384 | | V / / | 5385 | | ------- / / | 5386 | | / S3 \ / | 5387 | | \ / / | T18 5388 | | ---+--- / | 5389 | | |T4 / | 5390 | | V / | 5391 | | ------- / | 5392 | | / S4 \ | 5393 | | \ / | 5394 | | ---+--- T15 | 5395 | | |T5 +--------+---------+ 5396 | | | /T16+-----+------+ | 5397 | | | / -+-----+---+ | | 5398 | | | / / S7 \ |T12| | 5399 | | | / +->\ /<-+ V V 5400 | | | / / -+----- ------- 5401 | | | / /T11 |T10 / S8 \ 5402 | | V / / V \ / 5403 | | ---+-+- ------- ------- 5404 | | / S5 \T9 / S6 \ ^ 5405 | +-----\ /--->\ / | 5406 | ------- --+----+--------+T17 5407 +---------------------------+ 5409 The following state transition table represents the above diagram, 5410 and follows the conventions described for the initiator diagram. 5412 +----+---+---+---+---+----+---+ 5413 |S1 |S3 |S4 |S5 |S6 |S7 |S8 | 5414 ---+----+---+---+---+---+----+---+ 5415 S1| - |T3 | - | - | - | - | - | 5416 ---+----+---+---+---+---+----+---+ 5417 S3|T6 |- |T4 | - | - | - | - | 5418 ---+----+---+---+---+---+----+---+ 5419 S4|T7 |- |- |T5 | - | - | - | 5420 ---+----+---+---+---+---+----+---+ 5421 S5|T8 |- |- | - |T9 |T11 |T15| 5422 ---+----+---+---+---+---+----+---+ 5423 S6|T13 |- |- | - |- |- |T17| 5424 ---+----+---+---+---+---+----+---+ 5425 S7|T18 |- |- | - |T10|T12 |T16| 5426 ---+----+---+---+---+---+----+---+ 5427 S8| - |- |- | - | - | - | - | 5428 ---+----+---+---+---+---+----+---+ 5430 8.2. Connection Cleanup State Diagram for Initiators and Targets 5432 Symbolic names for states: 5434 R1: CLEANUP_WAIT (same as S8) 5436 R2: IN_CLEANUP 5438 R3: FREE (same as S1) 5440 Whenever a connection state machine in cleanup (let's call it CSM- 5441 C) enters the CLEANUP_WAIT state (S8), it must go through the 5442 state transitions described in the connection cleanup state 5443 diagram either a) using a separate full-feature phase connection 5444 (let's call it CSM-E, for explicit) in the LOGGED_IN state in the 5445 same session, or b) using a new transport connection (let's call 5446 it CSM-I, for implicit) in the FREE state that is to be added to 5447 the same session. In the CSM-E case, an explicit logout for the 5448 CID that corresponds to CSM-C (either as a connection or session 5449 logout) needs to be performed to complete the cleanup. In the CSM- 5450 I case, an implicit logout for the CID that corresponds to CSM-C 5451 needs to be performed by way of connection reinstatement (section 5452 6.3.4) for that CID. In either case, the protocol exchanges on 5453 CSM-E or CSM-I determine the state transitions for CSM-C. 5454 Therefore, this cleanup state diagram is only applicable to the 5455 instance of the connection in cleanup (i.e., CSM-C). In the case 5456 of an implicit logout for example, CSM-C reaches FREE (R3) at the 5457 time CSM-I reaches LOGGED_IN. In the case of an explicit logout, 5458 CSM-C reaches FREE (R3) when CSM-E receives a successful logout 5459 response while continuing to be in the LOGGED_IN state. 5461 An initiator must initiate an explicit or implicit connection 5462 logout for a connection in the CLEANUP_WAIT state, if the 5463 initiator intends to continue using the associated iSCSI session. 5465 The following state diagram applies to both initiators and 5466 targets. 5468 ------- 5469 / R1 \ 5470 +--\ /<-+ 5471 / ---+--- \ 5472 / | \ M3 5473 M1 | |M2 | 5474 | | / 5475 | | / 5476 | | / 5477 | V / 5478 | ------- / 5479 | / R2 \ 5480 | \ / 5481 | ------- 5482 | | 5483 | |M4 5484 | | 5485 | | 5486 | | 5487 | V 5488 | ------- 5489 | / R3 \ 5490 +---->\ / 5491 ------- 5493 The following state transition table represents the above diagram, 5494 and follows the same conventions as in earlier sections. 5496 +----+----+----+ 5497 |R1 |R2 |R3 | 5498 -----+----+----+----+ 5499 R1 | - |M2 |M1 | 5500 -----+----+----+----+ 5501 R2 |M3 | - |M4 | 5502 -----+----+----+----+ 5503 R3 | - | - | - | 5504 -----+----+----+----+ 5506 8.2.1. State Descriptions for Initiators and Targets 5508 -R1: CLEANUP_WAIT (Same as S8) 5509 -initiator: Waiting for the internal event to initiate the 5510 cleanup processing for CSM-C. 5511 -target: Waiting for the cleanup process to start for CSM- 5512 C. 5513 -R2: IN_CLEANUP 5514 -initiator: Waiting for the connection cleanup process to 5515 conclude for CSM-C. 5516 -target: Waiting for the connection cleanup process to 5517 conclude for CSM-C. 5518 -R3: FREE (Same as S1) 5519 -initiator: End state for CSM-C. 5520 -target: End state for CSM-C. 5522 8.2.2. State Transition Descriptions for Initiators and Targets 5524 -M1: One or more of the following events was received: 5525 -initiator: 5526 -An internal event that indicates connection state 5527 timeout. 5528 -An internal event of receiving a successful Logout 5529 response on a different connection for a "close the 5530 session" Logout. 5531 -target: 5532 -An internal event that indicates connection state 5533 timeout. 5534 -An internal event of sending a Logout response 5535 (success) on a different connection for a "close the 5536 session" Logout request. 5538 -M2: An implicit/explicit logout process was initiated by the 5539 initiator. 5540 -In CSM-I usage: 5541 -initiator: An internal event requesting the connection 5542 (or session) reinstatement was received, thus prompting 5543 a connection (or session) reinstatement Login to be 5544 sent transitioning CSM-I to state IN_LOGIN. 5545 -target: A connection/session reinstatement Login was 5546 received while in state XPT_UP. 5547 -In CSM-E usage: 5549 -initiator: An internal event that indicates that an 5550 explicit logout was sent for this CID in state 5551 LOGGED_IN. 5552 -target: An explicit logout was received for this CID 5553 in state LOGGED_IN. 5554 -M3: Logout failure detected 5555 -In CSM-I usage: 5556 -initiator: CSM-I failed to reach LOGGED_IN and arrived 5557 into FREE instead. 5558 -target: CSM-I failed to reach LOGGED_IN and arrived 5559 into FREE instead. 5560 -In CSM-E usage: 5561 -initiator: CSM-E either moved out of LOGGED_IN, or 5562 Logout timed out and/or aborted, or Logout response 5563 (failure) was received. 5564 -target: CSM-E either moved out of LOGGED_IN, Logout 5565 timed out and/or aborted, or an internal event that 5566 indicates a failed Logout processing was received. A 5567 Logout response (failure) was sent in the last case. 5569 -M4: Successful implicit/explicit logout was performed. 5570 - In CSM-I usage: 5571 -initiator: CSM-I reached state LOGGED_IN, or an 5572 internal event of receiving a Logout response (success) 5573 on another connection for a "close the session" Logout 5574 request was received. 5575 -target: CSM-I reached state LOGGED_IN, or an internal 5576 event of sending a Logout response (success) on a 5577 different connection for a "close the session" Logout 5578 request was received. 5579 - In CSM-E usage: 5580 -initiator: CSM-E stayed in LOGGED_IN and received a 5581 Logout response (success), or an internal event of 5582 receiving a Logout response (success) on another 5583 connection for a "close the session" Logout request was 5584 received. 5585 -target: CSM-E stayed in LOGGED_IN and an internal 5586 event indicating a successful Logout processing was 5587 received, or an internal event of sending a Logout 5588 response (success) on a different connection for a 5589 "close the session" Logout request was received. 5591 8.3. Session State Diagrams 5593 8.3.1. Session State Diagram for an Initiator 5595 Symbolic Names for States: 5597 Q1: FREE 5599 Q3: LOGGED_IN 5601 Q4: FAILED 5603 State Q3 represents the Full Feature Phase operation of the 5604 session. 5606 The state diagram is as follows: 5608 ------- 5609 / Q1 \ 5610 +------>\ /<-+ 5611 / ---+--- | 5612 / | |N3 5613 N6 | |N1 | 5614 | | | 5615 | N4 | | 5616 | +----------+ | / 5617 | | | | / 5618 | | | | / 5619 | | V V / 5620 -+--+-- -----+- 5621 / Q4 \ N5 ---/ Q3 \ 5622 \ /<------\ / 5623 ------- ------- 5625 The state transition table is as follows: 5627 +----+----+----+ 5628 |Q1 |Q3 |Q4 | 5629 -----+----+----+----+ 5630 Q1 | - |N1 | - | 5631 -----+----+----+----+ 5632 Q3 |N3 | - |N5 | 5633 -----+----+----+----+ 5634 Q4 |N6 |N4 | - | 5635 -----+----+----+----+ 5637 8.3.2. Session State Diagram for a Target 5639 Symbolic Names for States: 5641 Q1: FREE 5643 Q2: ACTIVE 5645 Q3: LOGGED_IN 5647 Q4: FAILED 5649 Q5: IN_CONTINUE 5651 State Q3 represents the Full Feature Phase operation of the 5652 session. 5654 The state diagram is as follows: 5656 ------- 5657 +------------------>/ Q1 \ 5658 / +-------------->\ /<-+ 5659 | | ---+--- | 5660 | | ^ | |N3 5661 N 6 | |N11 N9| V N1 | 5662 | | +------ | 5663 | | / Q2 \ | 5664 | | \ / | 5665 | --+---- +--+--- | 5666 | / Q5 \ | | 5667 | \ / N10 | | 5668 | +-+---+------------+ | N2 / 5669 | ^ | | | / 5670 | N7| |N8 | | / 5671 | | | | V / 5672 -+---+-V V------+- 5673 / Q4 \ N5 / Q3 \ 5674 \ /<-------------\ / 5675 ------- ------- 5677 The state transition table is as follows: 5679 +----+----+----+----+----+ 5680 |Q1 |Q2 |Q3 |Q4 |Q5 | 5681 -----+----+----+----+----+----+ 5682 Q1 | - |N1 | - | - | - | 5683 -----+----+----+----+----+----+ 5684 Q2 |N9 | - |N2 | - | - | 5685 -----+----+----+----+----+----+ 5686 Q3 |N3 | - | - |N5 | - | 5687 -----+----+----+----+----+----+ 5688 Q4 |N6 | - | - | - |N7 | 5689 -----+----+----+----+----+----+ 5690 Q5 |N11 | - |N10 |N8 | - | 5691 -----+----+----+----+----+----+ 5693 8.3.3. State Descriptions for Initiators and Targets 5695 -Q1: FREE 5696 -initiator: State on instantiation or after cleanup. 5698 -target: State on instantiation or after cleanup. 5699 -Q2: ACTIVE 5700 -initiator: Illegal. 5701 -target: The first iSCSI connection in the session 5702 transitioned to IN_LOGIN, waiting for it to complete the 5703 login process. 5704 -Q3: LOGGED_IN 5705 -initiator: Waiting for all session events. 5706 -target: Waiting for all session events. 5707 -Q4: FAILED 5708 -initiator: Waiting for session recovery or session 5709 continuation. 5710 -target: Waiting for session recovery or session 5711 continuation. 5712 -Q5: IN_CONTINUE 5713 -initiator: Illegal. 5714 -target: Waiting for session continuation attempt to reach 5715 a conclusion. 5717 8.3.4. State Transition Descriptions for Initiators and Targets 5719 -N1: 5720 -initiator: At least one transport connection reached the 5721 LOGGED_IN state. 5722 -target: The first iSCSI connection in the session had 5723 reached the IN_LOGIN state. 5724 -N2: 5725 -initiator: Illegal. 5726 -target: At least one iSCSI connection reached the 5727 LOGGED_IN state. 5728 -N3: 5729 -initiator: Graceful closing of the session via session 5730 closure (Section 6.3.6 - "Session Continuation and 5731 Failure"). 5732 -target: Graceful closing of the session via session 5733 closure (Section 6.3.6 - "Session Continuation and 5734 Failure") or a successful session reinstatement cleanly 5735 closed the session. 5736 -N4: 5737 -initiator: A session continuation attempt succeeded. 5739 -target: Illegal. 5740 -N5: 5741 -initiator: Session failure (Section 6.3.6 - "Session 5742 Continuation and Failure") occurred. 5743 -target: Session failure (Section 6.3.6- "Session 5744 Continuation and Failure") occurred. 5745 -N6: 5746 -initiator: Session state timeout occurred, or a session 5747 reinstatement cleared this session instance. This results 5748 in the freeing of all associated resources and the session 5749 state is discarded. 5750 -target: Session state timeout occurred, or a session 5751 reinstatement cleared this session instance. This results 5752 in the freeing of all associated resources and the session 5753 state is discarded. 5754 -N7: 5755 -initiator: Illegal. 5756 -target: A session continuation attempt is initiated. 5757 -N8: 5758 -initiator: Illegal. 5759 -target: The last session continuation attempt failed. 5760 -N9: 5761 -initiator: Illegal. 5762 -target: Login attempt on the leading connection failed. 5763 -N10: 5764 -initiator: Illegal. 5765 -target: A session continuation attempt succeeded. 5766 -N11: 5767 -initiator: Illegal. 5768 -target: A successful session reinstatement cleanly closed 5769 the session. 5771 9. Security Considerations 5773 Historically, native storage systems have not had to consider 5774 security because their environments offered minimal security 5775 risks. That is, these environments consisted of storage devices 5776 either directly attached to hosts or connected via a Storage Area 5777 Network (SAN) distinctly separate from the communications network. 5778 The use of storage protocols, such as SCSI, over IP-networks 5779 requires that security concerns be addressed. iSCSI 5780 implementations MUST provide means of protection against active 5781 attacks (e.g., pretending to be another identity, message 5782 insertion, deletion, modification, and replaying) and passive 5783 attacks (e.g.,eavesdropping, gaining advantage by analyzing the 5784 data sent over the line). 5786 Although technically possible, iSCSI SHOULD NOT be configured 5787 without security. iSCSI configured without security should be 5788 confined, in extreme cases, to closed environments without any 5789 security risk. [RFC3723] specifies the mechanisms that must be 5790 used in order to mitigate risks fully described in that document. 5792 The following section describes the security mechanisms provided 5793 by an iSCSI implementation. 5795 9.1. iSCSI Security Mechanisms 5797 The entities involved in iSCSI security are the initiator, target, 5798 and the IP communication end points. iSCSI scenarios in which 5799 multiple initiators or targets share a single communication end 5800 point are expected. To accommodate such scenarios, iSCSI uses two 5801 separate security mechanisms: In-band authentication between the 5802 initiator and the target at the iSCSI connection level (carried 5803 out by exchange of iSCSI Login PDUs), and packet protection 5804 (integrity, authentication, and confidentiality) by IPsec at the 5805 IP level. The two security mechanisms complement each other. The 5806 in-band authentication provides end-to-end trust (at login time) 5807 between the iSCSI initiator and the target while IPsec provides a 5808 secure channel between the IP communication end points. 5810 Further details on typical iSCSI scenarios and the relation 5811 between the initiators, targets, and the communication end points 5812 can be found in [RFC3723]. 5814 9.2. In-band Initiator-Target Authentication 5816 During login, the target MAY authenticate the initiator and the 5817 initiator MAY authenticate the target. The authentication is 5818 performed on every new iSCSI connection by an exchange of iSCSI 5819 Login PDUs using a negotiated authentication method. 5821 The authentication method cannot assume an underlying IPsec 5822 protection, because IPsec is optional to use. An attacker should 5823 gain as little advantage as possible by inspecting the 5824 authentication phase PDUs. Therefore, a method using clear text 5825 (or equivalent) passwords is not acceptable; on the other hand, 5826 identity protection is not strictly required. 5828 The authentication mechanism protects against an unauthorized 5829 login to storage resources by using a false identity (spoofing). 5830 Once the authentication phase is completed, if the underlying 5831 IPsec is not used, all PDUs are sent and received in clear. The 5832 authentication mechanism alone (without underlying IPsec) should 5833 only be used when there is no risk of eavesdropping, message 5834 insertion, deletion, modification, and replaying. 5836 Section 11 - "iSCSI Security Text Keys and Authentication Methods" 5837 defines several authentication methods and the exact steps that 5838 must be followed in each of them, including the iSCSI-text-keys 5839 and their allowed values in each step. Whenever an iSCSI initiator 5840 gets a response whose keys, or their values, are not according to 5841 the step definition, it MUST abort the connection. Whenever an 5842 iSCSI target gets a response whose keys, or their values, are not 5843 according to the step definition, it MUST answer with a Login 5844 reject with the "Initiator Error" or "Missing Parameter" status. 5845 These statuses are not intended for cryptographically incorrect 5846 values such as the CHAP response, for which "Authentication 5847 Failure" status MUST be specified. The importance of this rule can 5848 be illustrated in CHAP with target authentication (see Section 5849 12.1.3- "Challenge Handshake Authentication Protocol (CHAP)") 5850 where the initiator would have been able to conduct a reflection 5851 attack by omitting his response key (CHAP_R) using the same CHAP 5852 challenge as the target and reflecting the target's response back 5853 to the target. In CHAP, this is prevented because the target must 5854 answer the missing CHAP_R key with a Login reject with the 5855 "Missing Parameter" status. 5857 For some of the authentication methods, a key specifies the 5858 identity of the iSCSI initiator or target for authentication 5859 purposes. The value associated with that key MAY be different from 5860 the iSCSI name and SHOULD be configurable. (CHAP_N, see Section 5861 12.1.3 - "Challenge Handshake Authentication Protocol (CHAP)" and 5862 SRP_U, see Section 12.1.2- "Secure Remote Password (SRP)"). 5864 9.2.1. CHAP Considerations 5866 Compliant iSCSI initiators and targets MUST implement the CHAP 5867 authentication method [RFC1994] (according to Section 12.1.3 - 5868 "Challenge Handshake Authentication Protocol (CHAP)" including the 5869 target authentication option). 5871 When CHAP is performed over a non-encrypted channel, it is 5872 vulnerable to an off-line dictionary attack. Implementations MUST 5873 support use of up to 128 bit random CHAP secrets, including the 5874 means to generate such secrets and to accept them from an external 5875 generation source. Implementations MUST NOT provide secret 5876 generation (or expansion) means other than random generation. 5878 An administrative entity of an environment in which CHAP is used 5879 with a secret that has less than 96 random bits MUST enforce IPsec 5880 encryption (according to the implementation requirements in 5881 Confidentiality) to protect the connection. Moreover, in this case 5882 IKE authentication with group pre-shared cryptographic keys SHOULD 5883 NOT be used unless it is not essential to protect group members 5884 against off-line dictionary attacks by other members. 5886 CHAP secrets MUST be an integral number of bytes (octets). A 5887 compliant implementation SHOULD NOT continue with the login step 5888 in which it should send a CHAP response (CHAP_R, Section 12.1.3- 5889 "Challenge Handshake Authentication Protocol (CHAP)") unless it 5890 can verify that the CHAP secret is at least 96 bits, or that IPsec 5891 encryption is being used to protect the connection. 5893 Any CHAP secret used for initiator authentication MUST NOT be 5894 configured for authentication of any target, and any CHAP secret 5895 used for target authentication MUST NOT be configured for 5896 authentication of any initiator. If the CHAP response received by 5897 one end of an iSCSI connection is the same as the CHAP response 5898 that the receiving endpoint would have generated for the same CHAP 5899 challenge, the response MUST be treated as an authentication 5900 failure and cause the connection to close (this ensures that the 5901 same CHAP secret is not used for authentication in both 5902 directions). Also, if an iSCSI implementation can function as 5903 both initiator and target, different CHAP secrets and identities 5904 MUST be configured for these two roles. The following is an 5905 example of the attacks prevented by the above requirements: 5907 Rogue wants to impersonate Storage to Alice, and knows that a 5908 single secret is used for both directions of Storage-Alice 5909 authentication. 5911 Rogue convinces Alice to open two connections to Rogue, and 5912 Rogue identifies itself as Storage on both connections. 5914 Rogue issues a CHAP challenge on connection 1, waits for Alice 5915 to respond, and then reflects Alice's challenge as the 5916 initial challenge to Alice on connection 2. 5918 If Alice doesn't check for the reflection across connections, 5919 Alice's response on connection 2 enables Rogue to 5920 impersonate Storage on connection 1, even though Rogue does 5921 not know the Alice-Storage CHAP secret. 5923 Originators MUST NOT reuse the CHAP challenge sent by the 5924 Responder for the other direction of a bidirectional 5925 authentication. Responders MUST check for this condition and close 5926 the iSCSI TCP connection if it occurs. 5928 The same CHAP secret SHOULD NOT be configured for authentication 5929 of multiple initiators or multiple targets, as this enables any of 5930 them to impersonate any other one of them, and compromising one of 5931 them enables the attacker to impersonate any of them. It is 5932 recommended that iSCSI implementations check for use of identical 5933 CHAP secrets by different peers when this check is feasible, and 5934 take appropriate measures to warn users and/or administrators when 5935 this is detected. 5937 When an iSCSI initiator or target authenticates itself to 5938 counterparts in multiple administrative domains, it SHOULD use a 5939 different CHAP secret for each administrative domain to avoid 5940 propagating security compromises across domains. 5942 Within a single administrative domain: 5943 - A single CHAP secret MAY be used for authentication of an 5944 initiator to multiple targets. 5946 - A single CHAP secret MAY be used for an authentication of a 5947 target to multiple initiators when the initiators use an 5948 external server (e.g., RADIUS) to verify the target's CHAP 5949 responses and do not know the target's CHAP secret. 5951 If an external response verification server (e.g., RADIUS) is not 5952 used, employing a single CHAP secret for authentication of a 5953 target to multiple initiators requires that all such initiators 5954 know that target secret. Any of these initiators can impersonate 5955 the target to any other such initiator, and compromise of such an 5956 initiator enables an attacker to impersonate the target to all 5957 such initiators. Targets SHOULD use separate CHAP secrets for 5958 authentication to each initiator when such risks are of concern; 5959 in this situation it may be useful to configure a separate logical 5960 iSCSI target with its own iSCSI Node Name for each initiator or 5961 group of initiators among which such separation is desired. 5963 9.2.2. SRP Considerations 5965 The strength of the SRP authentication method (specified in 5966 [RFC2945]) is dependent on the characteristics of the group being 5967 used (i.e., the prime modulus N and generator g). As described in 5968 [RFC2945], N is required to be a Sophie-German prime (of the form 5969 N = 2q + 1, where q is also prime) and the generator g is a 5970 primitive root of GF(n). In iSCSI authentication, the prime 5971 modulus N MUST be at least 768 bits. 5973 The list of allowed SRP groups is provided in [RFC3723]. 5975 9.3. IPsec 5977 iSCSI uses the IPsec mechanism for packet protection 5978 (cryptographic integrity, authentication, and confidentiality) at 5979 the IP level between the iSCSI communicating end points. The 5980 following sections describe the IPsec protocols that must be 5981 implemented for data integrity and authentication, 5982 confidentiality, and cryptographic key management. 5984 An iSCSI initiator or target may provide the required IPsec 5985 support fully integrated or in conjunction with an IPsec front-end 5986 device. In the latter case, the compliance requirements with 5987 regard to IPsec support apply to the "combined device". Only the 5988 "combined device" is to be considered an iSCSI device. 5990 Detailed considerations and recommendations for using IPsec for 5991 iSCSI are provided in [RFC3723]. 5993 This document updates RFC 3723 to add requirements for IPsec v3 5994 as specified in [RFC4301] and related RFCs. The IPsec v2 "MUST 5995 implement" requirements from [RFC3723] are left unchanged by this 5996 document; this document adds requirements that IPsec v3, as 5997 specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), 5998 SHOULD be implemented. The mandatory requirement for IPsec v2 5999 preserves interoperability with existing implementations, and the 6000 strong recommendation for IPsec v3 encourages implementers to move 6001 forward to that newer version of IPsec. 6003 9.3.1. Data Integrity and Authentication 6005 Data authentication and integrity is provided by a cryptographic 6006 keyed Message Authentication Code in every sent packet. This code 6007 protects against message insertion, deletion, and modification. 6008 Protection against message replay is realized by using a sequence 6009 counter. 6011 An iSCSI-compliant initiator or target MUST provide data integrity 6012 and authentication by implementing IPsec v2 [RFC2401] with ESPv2 6013 [RFC2406] in tunnel mode, SHOULD provide data integrity and 6014 authentication by implementing IPsec v3 [RFC4301] with ESPv3 6015 [RFC4303] in tunnel mode, and MAY provide data integrity and 6017 authentication by implementing either IPsec v2 or v3 with the 6018 appropriate version of ESP in transport mode. The IPsec 6019 implementation MUST fulfill the following iSCSI specific 6020 requirements: 6022 - HMAC-SHA1 MUST be implemented [RFC2404]. 6024 - AES CBC MAC with XCBC extensions SHOULD be implemented 6025 [RFC3566]. 6027 - Implementations that support IKEv2 [RFC5996] SHOULD also 6028 implement AES GMAC [RFC4543] 6030 The ESP anti-replay service MUST also be implemented. 6032 At the high speeds iSCSI is expected to operate, a single IPsec SA 6033 could rapidly cycle through the ESP 32-bit sequence number space. 6034 In view of this, an iSCSI implementation that is capable of 6035 operating at speeds of 1 Gbps and that implements both IKEv2 6036 [RFC5996] and ESPv3 [RFC4303] MUST also implement extended (64- 6037 bit) sequence numbers for ESPv3 and SHOULD use ESPv3 extended 6038 sequence numbers for all security associations that use ESPv3 to 6039 protect iSCSI connections. 6040 9.3.2. Confidentiality 6042 Confidentiality is provided by encrypting the data in every 6043 packet. When confidentiality is used it MUST be accompanied by 6044 data integrity and authentication to provide comprehensive 6045 protection against eavesdropping, message insertion, deletion, 6046 modification, and replaying. 6048 An iSCSI compliant initiator or target MUST provide 6049 confidentiality by implementing IPsec v2 [RFC2401] with ESPv2 6050 [RFC2406] in tunnel mode, SHOULD provide confidentiality by 6051 implementing IPsec v3 [RFC4301] with ESPv3 [RFC4303] in tunnel 6052 mode and MAY provide confidentiality by implementing either IPsec 6053 v2 or v3 with the appropriate version of ESP in transport mode, 6054 with the following iSCSI specific requirements that apply to IPsec 6055 v2 and IPsec v3: 6056 - 3DES in CBC mode MUST be implemented [RFC2451]. 6058 - AES in Counter mode SHOULD be implemented [RFC3686]. 6060 - Implementations that support IKEv2 [RFC5996] SHOULD also 6061 implement AES GCM [RFC4106] 6063 DES in CBC mode MUST NOT be used due to its inherent weakness. 6065 The NULL encryption algorithm MUST also be implemented. 6067 9.3.3. Policy, Security Associations, and Cryptographic Key 6068 Management 6070 A compliant iSCSI implementation MUST meet the cryptographic key 6071 management requirements of the IPsec protocol suite. 6072 Authentication, security association negotiation, and 6073 cryptographic key management MUST be provided by implementing IKE 6074 [RFC5996] using the IPsec DOI [RFC5996] with the following iSCSI 6075 specific requirements: 6077 - Peer authentication using a pre-shared cryptographic key 6078 MUST be supported. Certificate-based peer authentication 6079 using digital signatures MAY be supported. For IKEv1 6080 ([RFC2409]), peer authentication using the public key 6081 encryption methods outlined in IKE sections 5.2 and 5.3 of 6082 [RFC2409] SHOULD NOT be used. 6084 - When digital signatures are used to achieve authentication, 6085 an IKE negotiator SHOULD use IKE Certificate Request 6086 Payload(s) to specify the certificate authority. IKE 6087 negotiators SHOULD check the pertinent Certificate 6088 Revocation List (CRL) before accepting a PKI certificate for 6089 use in IKE authentication procedures. 6091 - Conformant iSCSI implementations of IKEv1 MUST support Main 6092 Mode and SHOULD support Aggressive Mode. Main Mode with pre- 6093 shared key authentication method SHOULD NOT be used when 6094 either the initiator or the target uses dynamically assigned 6096 addresses. While in many cases pre-shared keys offer good 6097 security, situations in which dynamically assigned addresses 6098 are used force the use of a group pre-shared key, which 6099 creates vulnerability to a man-in-the-middle attack. 6101 - In the IKEv1 Phase 2 Quick Mode, exchanges for creating the 6102 Phase 2 SA, the Identification Payload MUST be present. 6104 - The following identification type requirements apply to IKEv1. 6105 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports 6106 IPv6) and ID_FQDN Identification Types MUST be supported; 6107 ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address 6108 Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types 6109 SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT 6110 be used. 6112 - If IKEv2 is supported, the following identification requirements 6113 apply. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack 6114 supports IPv6) and ID_FQDN Identification Types MUST be 6115 supported; ID_RFC822_ADDR SHOULD be supported. The 6116 ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD 6117 NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. 6119 Manual cryptographic keying MUST NOT be used because it does not 6120 provide the necessary re-keying support. 6122 When DH groups are used, a DH group of at least 2048 bits SHOULD 6123 be offered as a part of all proposals to create IPsec Security 6124 Associations to protect iSCSI traffic. 6126 When IPsec is used, the receipt of an IKEv1 Phase 2 delete message 6127 or an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT 6128 be interpreted as a reason for tearing down the iSCSI TCP 6129 connection. If additional traffic is sent on it, a new IKE SA will 6130 be created to protect it. 6132 The method used by the initiator to determine whether the target 6133 should be connected using IPsec is regarded as an issue of IPsec 6134 policy administration, and thus not defined in the iSCSI standard. 6136 The method used by an initiator that supports both IPsec v2 and v3 6137 to determine which versions of IPsec are supported by the target 6138 is also regarded as an issue of IPsec policy administration, and 6139 thus not defined in the iSCSI standard. If both IPsec v2 and v3 6140 are supported by both the initiator and target, use of IPsec v3 is 6141 recommended. 6143 If an iSCSI target is discovered via a SendTargets request in a 6144 discovery session not using IPsec, the initiator should assume 6145 that it does not need IPsec to establish a session to that target. 6146 If an iSCSI target is discovered using a discovery session that 6147 does use IPsec, the initiator SHOULD use IPsec when establishing a 6148 session to that target. 6150 9.4. Security Considerations for the X#NodeArchitecture Key 6152 The security considerations in this section are specific to the 6153 X#NodeArchitecture discussed in Section 13.26 - 6154 "X#NodeArchitecture". 6156 This extension key transmits specific implementation details about 6157 the node that sends it; such details may be considered sensitive 6158 in some environments. For example, if a certain software or 6159 firmware version is known to contain security weaknesses, 6160 announcing the presence of that version via this key may not be 6161 desirable. The countermeasures for this security concern are: 6163 - sending less detailed information in the key values, 6164 - not sending the extension key, or 6165 - using IPsec ([RFC4303]) to provide confidentiality for 6166 the iSCSI connection on which the key is sent 6167 To support the first and second countermeasures, all 6168 implementations of this extension key MUST provide an 6169 administrative mechanism to disable sending the key. In addition, 6170 all implementations SHOULD provide an administrative mechanism to 6171 configure a verbosity level of the key value, thereby controlling 6172 the amount of information sent. 6174 For example, a lower verbosity might enable transmission of node 6175 architecture component names only, but no version numbers. The 6176 choice of which countermeasure is most appropriate depends on the 6177 environment. However, sending less detailed information in the key 6178 values may be an acceptable countermeasure in many environments, 6179 since it provides a compromise between sending too much 6180 information and the other more complete countermeasures of not 6181 sending the key at all or using IPsec. 6183 In addition to security considerations involving transmission of 6184 the key contents, any logging method(s) used for the key values 6185 MUST keep the information secure from intruders. For all 6186 implementations, the requirements to address this security concern 6187 are: 6189 - Display of the log MUST only be possible with administrative 6190 rights to the node. 6192 - Options to disable logging to disk and to keep logs for a 6193 fixed duration SHOULD be provided. 6195 Finally, it is important to note that different nodes may have 6196 different levels of risk, and these differences may affect the 6197 implementation. The components of risk include assets, threats, 6198 and vulnerabilities. Consider the following example iSCSI nodes, 6199 which demonstrate differences in assets and vulnerabilities of the 6200 nodes, and as a result, differences in implementation: 6202 One iSCSI target based on a special-purpose operating system: 6203 Since the iSCSI target controls access to the data storage 6204 containing company assets, the asset level is seen as very 6205 high. Also, because of the special-purpose operating 6206 system, in which vulnerabilities are less well-known, the 6207 vulnerability level is viewed as low. 6209 Multiple iSCSI initiators in a blade farm, each running a 6210 general purpose operating system: The asset level of each 6211 node is viewed as low, since blades are replaceable and low 6212 cost. However, the vulnerability level is viewed as high, 6213 since there may be many wellknown vulnerabilities to that 6214 general-purpose operating system. For this target, an 6215 appropriate implementation might be logging of received key 6216 values, but no transmission of the key. For this initiator, 6217 an appropriate implementation might be transmission of the 6218 key, but no logging of received key values. 6220 10. Notes to Implementers 6222 This section notes some of the performance and reliability 6223 considerations of the iSCSI protocol. This protocol was designed 6224 to allow efficient silicon and software implementations. The iSCSI 6225 task tag mechanism was designed to enable Direct Data Placement 6226 (DDP - a DMA form) at the iSCSI level or lower. 6228 The guiding assumption made throughout the design of this protocol 6229 is that targets are resource constrained relative to initiators. 6231 Implementers are also advised to consider the implementation 6232 consequences of the iSCSI to SCSI mapping model as outlined in 6233 Section 4.4.3 - "Consequences of the Model". 6235 10.1. Multiple Network Adapters 6237 The iSCSI protocol allows multiple connections, not all of which 6238 need to go over the same network adapter. If multiple network 6239 connections are to be utilized with hardware support, the iSCSI 6240 protocol command-data-status allegiance to one TCP connection 6241 ensures that there is no need to replicate information across 6242 network adapters or otherwise require them to cooperate. 6244 However, some task management commands may require some loose form 6245 of cooperation or replication at least on the target. 6247 10.1.1. Conservative Reuse of ISIDs 6249 Historically, the SCSI model (and implementations and applications 6250 based on that model) has assumed that SCSI ports are static, 6251 physical entities. Recent extensions to the SCSI model have taken 6252 advantage of persistent worldwide unique names for these ports. In 6253 iSCSI however, the SCSI initiator ports are the endpoints of 6254 dynamically created sessions, so the presumptions of "static and 6255 physical" do not apply. In any case, the model clauses 6256 (particularly, Section 4.4.1- "SCSI Architecture Model") provide 6257 for persistent, reusable names for the iSCSI-type SCSI initiator 6258 ports even though there does not need to be any physical entity 6259 bound to these names. 6261 To both minimize the disruption of legacy applications and to 6262 better facilitate the SCSI features that rely on persistent names 6263 for SCSI ports, iSCSI implementations SHOULD attempt to provide a 6264 stable presentation of SCSI Initiator Ports (both to the upper OS- 6265 layers and to the targets to which they connect). This can be 6266 achieved in an initiator implementation by conservatively reusing 6267 ISIDs. In other words, the same ISID should be used in the Login 6268 process to multiple target portal groups (of the same iSCSI Target 6269 or different iSCSI Targets). The ISID RULE (Section 4.4.3- 6270 "Consequences of the Model") only prohibits reuse to the same 6271 target portal group. It does not "preclude" reuse to other target 6272 portal groups. 6273 The principle of conservative reuse "encourages" reuse to other 6274 target portal groups. When a SCSI target device sees the same 6275 (InitiatorName, ISID) pair in different sessions to different 6276 target portal groups, it can identify the underlying SCSI 6277 Initiator Port on each session as the same SCSI port. In effect, 6278 it can recognize multiple paths from the same source. 6280 10.1.2. iSCSI Name, ISID, and TPGT Use 6282 The designers of the iSCSI protocol are aware that legacy SCSI 6283 transports rely on initiator identity to assign access to storage 6284 resources. Although newer techniques are available and simplify 6285 access control, support for configuration and authentication 6286 schemes that are based on initiator identity is deemed important 6287 in order to support legacy systems and administration software. 6288 iSCSI thus supports the notion that it should be possible to 6289 assign access to storage resources based on "initiator device" 6290 identity. 6292 When there are multiple hardware or software components 6293 coordinated as a single iSCSI Node, there must be some (logical) 6294 entity that represents the iSCSI Node that makes the iSCSI Node 6295 Name available to all components involved in session creation and 6296 login. Similarly, this entity that represents the iSCSI Node must 6297 be able to coordinate session identifier resources (ISID for 6298 initiators) to enforce both the ISID and TSIH RULES (see Section 6299 4.4.3- "Consequences of the Model"). 6301 For targets, because of the closed environment, implementation of 6302 this entity should be straightforward. However, vendors of iSCSI 6303 hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide 6304 mechanisms for configuration of the iSCSI Node Name across the 6305 portal groups instantiated by multiple instances of these 6306 components within a target. 6308 However, complex targets making use of multiple Target Portal 6309 Group Tags may reconfigure them to achieve various quality goals. 6310 The initiators have two mechanisms at their disposal to discover 6311 and/or check reconfiguring targets - the discovery session type 6312 and a key returned by the target during login to confirm the TPGT. 6313 An initiator should attempt to "rediscover" the target 6314 configuration anytime a session is terminated unexpectedly. 6316 For initiators, in the long term, it is expected that operating 6317 system vendors will take on the role of this entity and provide 6318 standard APIs that can inform components of their iSCSI Node Name 6319 and can configure and/or coordinate ISID allocation, use, and 6320 reuse. 6322 Recognizing that such initiator APIs are not available today, 6323 other implementations of the role of this entity are possible. For 6324 example, a human may instantiate the (common) Node name as part of 6325 the installation process of each iSCSI component involved in 6326 session creation and login. This may be done either by pointing 6327 the component to a vendor-specific location for this datum or to a 6328 system-wide location. The structure of the ISID namespace (see 6329 Section 11.12.5 - "ISID" and [RFC3721]) facilitates implementation 6330 of the ISID coordination by allowing each component vendor to 6331 independently (of other vendor's components) coordinate 6332 allocation, use, and reuse of its own partition of the ISID 6333 namespace in a vendor-specific manner. Partitioning of the ISID 6334 namespace within initiator portal groups managed by that vendor 6335 allows each such initiator portal group to act independently of 6336 all other portal groups when selecting an ISID for a login; this 6337 facilitates enforcement of the ISID RULE (see Section 4.4.3- 6338 "Consequences of the Model") at the initiator. 6340 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use 6341 in initiators MUST implement a mechanism for configuring the iSCSI 6342 Node Name. Vendors, and administrators must ensure that iSCSI Node 6343 Names are unique worldwide. It is therefore important that when 6344 one chooses to reuse the iSCSI Node Name of a disabled unit, not 6345 to re-assign that name to the original unit unless its worldwide 6346 uniqueness can be ascertained again. 6348 In addition, a vendor of iSCSI hardware must implement a mechanism 6349 to configure and/or coordinate ISIDs for all sessions managed by 6350 multiple instances of that hardware within a given iSCSI Node. 6351 Such configuration might be either permanently pre-assigned at the 6352 factory (in a necessarily globally unique way), statically 6353 assigned (e.g., partitioned across all the NICs at initialization 6354 in a locally unique way), or dynamically assigned (e.g., on-line 6355 allocator, also in a locally unique way). In the latter two cases, 6356 the configuration may be via public APIs (perhaps driven by an 6357 independent vendor's software, such as the OS vendor) or via 6358 private APIs driven by the vendor's own software. 6360 The process of name assignment and coordination has to be as 6361 encompassing and automated as possible as years of legacy usage 6362 have shown it to be highly error-prone. It is to be mentioned 6363 that SCSI has today alternative schemes of access control that can 6364 be used by all transports and their security is not dependent on 6365 strict naming coordination. 6367 10.2. Autosense and Auto Contingent Allegiance (ACA) 6369 Autosense refers to the automatic return of sense data to the 6370 initiator in case a command did not complete successfully. iSCSI 6371 initiators and targets MUST support and use autosense. 6373 ACA helps preserve ordered command execution in the presence of 6374 errors. As there can be many commands in-flight between an 6375 initiator and a target, SCSI initiator functionality in some 6376 operating systems depends on ACA to enforce ordered command 6377 execution during error recovery, and hence iSCSI initiator 6378 implementations for those operating systems need to support ACA. 6379 In order to support error recovery for these operating systems and 6380 iSCSI initiators, iSCSI targets SHOULD support ACA. 6382 10.3. iSCSI Timeouts 6384 iSCSI recovery actions are often dependent on iSCSI time-outs 6385 being recognized and acted upon before SCSI time-outs. Determining 6386 the right time-outs to use for various iSCSI actions (command 6387 acknowledgements expected, status acknowledgements, etc.) is very 6388 much dependent on infrastructure (hardware, links, TCP/IP stack, 6389 iSCSI driver). As a guide, the implementer may use an average Nop- 6390 Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 6391 4) as a good estimate for the basic delay of the iSCSI stack for a 6392 given connection. The safety factor should account for the network 6393 load variability. For connection teardown the implementer may 6394 want to consider also TCP common practice for the given 6395 infrastructure. 6397 Text negotiations MAY also be subject to either time-limits or 6398 limits in the number of exchanges. Those SHOULD be generous enough 6399 to avoid affecting interoperability (e.g., allowing each key to be 6400 negotiated on a separate exchange). 6402 The relation between iSCSI timeouts and SCSI timeouts should also 6403 be considered. SCSI timeouts should be longer than iSCSI timeouts 6404 plus the time required for iSCSI recovery whenever iSCSI recovery 6405 is planned. Alternatively, an implementer may choose to interlock 6406 iSCSI timeouts and recovery with SCSI timeouts so that SCSI 6407 recovery will become active only where iSCSI is not planned to, or 6408 failed to, recover. 6410 The implementer may also want to consider the interaction between 6411 various iSCSI exception events - such as a digest failure - and 6412 subsequent timeouts. When iSCSI error recovery is active, a digest 6413 failure is likely to result in discovering a missing command or 6414 data PDU. In these cases, an implementer may want to lower the 6415 timeout values to enable faster initiation for recovery 6416 procedures. 6418 10.4. Command Retry and Cleaning Old Command Instances 6420 To avoid having old, retried command instances appear in a valid 6421 command window after a command sequence number wrap around, the 6422 protocol requires (see Section 4.2.2.1- "Command Numbering and 6423 Acknowledging") that on every connection on which a retry has been 6424 issued, a non-immediate command be issued and acknowledged within 6425 a 2**31-1 commands interval from the CmdSN of the retried command. 6426 This requirement can be fulfilled by an implementation in several 6427 ways. 6429 The simplest technique to use is to send a (non-retry) non- 6430 immediate SCSI command (or a NOP if no SCSI command is available 6431 for a while) after every command retry on the connection on which 6432 the retry was attempted. As errors are deemed rare events, this 6433 technique is probably the most effective, as it does not involve 6434 additional checks at the initiator when issuing commands. 6436 10.5. Synch and Steering Layer and Performance 6438 While a synch and steering layer is optional, an initiator/target 6439 that does not have it working against a target/initiator that 6440 demands synch and steering may experience performance degradation 6441 caused by packet reordering and loss. Providing a synch and 6442 steering mechanism is recommended for all high-speed 6443 implementations. 6445 10.6. Considerations for State-dependent Devices and Long-lasting 6446 SCSI Operations 6448 Sequential access devices operate on the principle that the 6449 position of the device is based on the last command processed. As 6450 such, command processing order and knowledge of whether or not the 6451 previous command was processed is of the utmost importance to 6452 maintain data integrity. For example, inadvertent retries of SCSI 6453 commands when it is not known if the previous SCSI command was 6454 processed is a potential data integrity risk. 6456 For a sequential access device, consider the scenario in which a 6457 SCSI SPACE command to backspace one filemark is issued and then 6458 re-issued due to no status received for the command. If the first 6459 SPACE command was actually processed, the re-issued SPACE command, 6460 if processed, will cause the position to change. Thus, a 6461 subsequent write operation will write data to the wrong position 6462 and any previous data at that position will be overwritten. 6464 For a medium changer device, consider the scenario in which an 6465 EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION 6466 ADDRESS are the same thus performing a swap) is issued and then 6467 re-issued due to no status received for the command. If the first 6468 EXCHANGE MEDIUM command was actually processed, the re-issued 6469 EXCHANGE MEDIUM command, if processed, will perform the swap 6470 again. The net effect is no swap was performed thus leaving a data 6471 integrity exposure. 6473 All commands that change the state of the device (as in SPACE 6474 commands for sequential access devices, and EXCHANGE MEDIUM for 6475 medium changer device), MUST be issued as non-immediate commands 6476 for deterministic and in order delivery to iSCSI targets. 6478 For many of those state changing commands, the execution model 6479 also assumes that the command is executed exactly once. Devices 6480 implementing READ POSITION and LOCATE provide a means for SCSI 6481 level command recovery and new tape-class devices 6482 should support those commands. In their absence a retry at SCSI 6483 level is difficult and error recovery at iSCSI level is advisable. 6485 Devices operating on long latency delivery subsystems and 6486 performing long lasting SCSI operations may need mechanisms that 6487 enable connection replacement while commands are running (e.g., 6488 during an extended copy operation). 6490 10.6.1. Determining the Proper ErrorRecoveryLevel 6492 The implementation and use of a specific ErrorRecoveryLevel should 6493 be determined based on the deployment scenarios of a given iSCSI 6494 implementation. Generally, the following factors must be 6495 considered before deciding on the proper level of recovery: 6497 Application resilience to I/O failures. 6498 Required level of availability in the face of transport 6499 connection failures. 6500 Probability of transport layer "checksum escape". This in turn 6501 decides the iSCSI digest failure frequency, and thus the 6502 criticality of iSCSI-level error recovery. The details of 6503 estimating this probability are outside the scope of this 6504 document. 6506 A consideration of the above factors for SCSI tape devices as an 6507 example suggests that implementations SHOULD use 6508 ErrorRecoveryLevel=1 when transport connection failure is not a 6509 concern and SCSI level recovery is unavailable, and 6510 ErrorRecoveryLevel=2 when the connection failure is also of high 6511 likelihood during a backup/retrieval. 6513 For extended copy operations, implementations SHOULD use 6514 ErrorRecoveryLevel=2 whenever there is a relatively high 6515 likelihood of connection failure. 6517 10.7. Multi-task Abort Implementation Considerations 6519 Multi-task abort operations are typically issued in emergencies - 6520 such as clearing a device lock-up, HA failover/failback etc. In 6521 these circumstances, it is desirable to rapidly go through the 6522 error handling process as opposed to the target waiting on 6523 multiple third-party initiators who may not even be functional 6524 anymore - especially if this emergency is triggered because of one 6525 such initiator failure. Therefore, both iSCSI target and 6526 initiator implementations SHOULD support FastAbort multi-task 6527 abort semantics (Section 4.2.3.4). 6529 Note that both in standard semantics (Section 4.2.3.3) and 6530 FastAbort semantics (Section 4.2.3.4), there may be outstanding 6531 data transfers even after the TMF completion is reported on the 6532 issuing session. In the case of iSCSI/iSER [iSER], these would be 6533 tagged data transfers for STags not owned by any active tasks. 6534 Whether or not real buffers support these data transfers is 6535 implementation-dependent. However, the data transfers logically 6536 MUST be silently discarded by the target iSCSI layer in all cases. 6537 A target MAY, on an implementation-defined internal timeout, also 6538 choose to drop the connections on which it did not receive the 6539 expected Data-Out sequences (Section 4.2.3.3) or NOP-Out 6540 acknowledgements (Section 4.2.3.4) so as to reclaim the associated 6541 buffer, STag, and TTT resources as appropriate. 6543 11. iSCSI PDU Formats 6545 All multi-byte integers that are specified in formats defined in 6546 this document are to be represented in network byte order (i.e., 6547 big endian). Any field that appears in this document assumes that 6548 the most significant byte is the lowest numbered byte and the most 6549 significant bit (within byte or field) is the lowest numbered bit 6550 unless specified otherwise. 6552 Any compliant sender MUST set all bits not defined and all 6553 reserved fields to zero unless specified otherwise. Any compliant 6554 receiver MUST ignore any bit not defined and all reserved fields 6555 unless specified otherwise. Receipt of reserved code values in 6556 defined fields MUST be reported as a protocol error. 6558 Reserved fields are marked by the word "reserved", some 6559 abbreviation of "reserved", or by "." for individual bits when no 6560 other form of marking is technically feasible. 6562 11.1. iSCSI PDU Length and Padding 6564 iSCSI PDUs are padded to the closest integer number of four byte 6565 words. The padding bytes SHOULD be sent as 0. 6567 11.2. PDU Template, Header, and Opcodes 6569 All iSCSI PDUs have one or more header segments and, optionally, a 6570 data segment. After the entire header segment group a header- 6571 digest MAY follow. The data segment MAY also be followed by a 6572 data-digest. 6574 The Basic Header Segment (BHS) is the first segment in all of the 6575 iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It 6576 MAY be followed by Additional Header Segments (AHS), a Header- 6577 Digest, a Data Segment, and/or a Data-Digest. 6579 The overall structure of an iSCSI PDU is as follows: 6581 Byte/ 0 | 1 | 2 | 3 | 6582 / | | | | 6583 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 6584 +---------------+---------------+---------------+--------------+ 6585 0/ Basic Header Segment (BHS) / 6586 +/ / 6587 +---------------+---------------+---------------+--------------+ 6588 48/ Additional Header Segment 1 (AHS) (optional) / 6589 +/ / 6590 +---------------+---------------+---------------+--------------+ 6591 / Additional Header Segment 2 (AHS) (optional) / 6592 +/ / 6593 +---------------+---------------+---------------+--------------+ 6594 ---- 6595 +---------------+---------------+---------------+--------------+ 6596 / Additional Header Segment n (AHS) (optional) / 6597 +/ / 6598 +---------------+---------------+---------------+--------------+ 6599 ---- 6600 +---------------+---------------+---------------+--------------+ 6601 k/ Header-Digest (optional) / 6602 +/ / 6603 +---------------+---------------+---------------+--------------+ 6604 l/ Data Segment(optional) / 6605 +/ / 6606 +---------------+---------------+---------------+--------------+ 6607 m/ Data-Digest (optional) / 6608 +/ / 6609 +---------------+---------------+---------------+--------------+ 6611 All PDU segments and digests are padded to the closest integer 6612 number of four byte words. For example, all PDU segments and 6613 digests start at a four byte word boundary and the padding ranges 6614 from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. 6616 iSCSI response PDUs do not have AH Segments. 6618 11.2.1. Basic Header Segment (BHS) 6620 The BHS is 48 bytes long. The Opcode and DataSegmentLength fields 6621 appear in all iSCSI PDUs. In addition, when used, the Initiator 6622 Task Tag and Logical Unit Number always appear in the same 6623 location in the header. 6625 The format of the BHS is: 6627 Byte/ 0 | 1 | 2 | 3 | 6628 / | | | | 6629 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 6630 +---------------+---------------+---------------+--------------+ 6631 0|.|I| Opcode |F| Opcode-specific fields | 6632 +---------------+---------------+---------------+--------------+ 6633 4|TotalAHSLength | DataSegmentLength | 6634 +---------------+---------------+---------------+--------------+ 6635 8| LUN or Opcode-specific fields | 6636 + + 6637 12| | 6638 +---------------+---------------+---------------+--------------+ 6639 16| Initiator Task Tag | 6640 +---------------+---------------+---------------+--------------+ 6641 20/ Opcode-specific fields / 6642 +/ / 6643 +---------------+---------------+---------------+--------------+ 6644 48 6646 11.2.1.1. I 6648 For request PDUs, the I bit set to 1 is an immediate delivery 6649 marker. 6651 11.2.1.2. Opcode 6653 The Opcode indicates the type of iSCSI PDU the header 6654 encapsulates. 6656 The Opcodes are divided into two categories: initiator opcodes and 6657 target opcodes. Initiator opcodes are in PDUs sent by the 6658 initiator (request PDUs). Target opcodes are in PDUs sent by the 6659 target (response PDUs). 6661 Initiators MUST NOT use target opcodes and targets MUST NOT use 6662 initiator opcodes. 6664 Initiator opcodes defined in this specification are: 6666 0x00 NOP-Out 6668 0x01 SCSI Command (encapsulates a SCSI Command Descriptor 6669 Block) 6671 0x02 SCSI Task Management function request 6673 0x03 Login Request 6675 0x04 Text Request 6677 0x05 SCSI Data-out (for WRITE operations) 6679 0x06 Logout Request 6681 0x10 SNACK Request 6683 0x1c-0x1e Vendor specific codes 6685 Target opcodes are: 6687 0x20 NOP-In 6689 0x21 SCSI Response - contains SCSI status and possibly sense 6690 information or other response information. 6692 0x22 SCSI Task Management function response 6694 0x23 Login Response 6696 0x24 Text Response 6698 0x25 SCSI Data-in - for READ operations. 6700 0x26 Logout Response 6701 0x31 Ready To Transfer (R2T) - sent by target when it is ready 6702 to receive data. 6704 0x32 Asynchronous Message - sent by target to indicate certain 6705 special conditions. 6707 0x3c-0x3e Vendor specific codes 6709 0x3f Reject 6711 All other opcodes are reserved. 6713 11.2.1.3. Final (F) bit 6715 When set to 1 it indicates the final (or only) PDU of a sequence. 6717 11.2.1.4. Opcode-specific Fields 6719 These fields have different meanings for different opcode types. 6721 11.2.1.5. TotalAHSLength 6723 Total length of all AHS header segments in units of four byte 6724 words including padding, if any. 6726 The TotalAHSLength is only used in PDUs that have an AHS and MUST 6727 be 0 in all other PDUs. 6729 11.2.1.6. DataSegmentLength 6731 This is the data segment payload length in bytes (excluding 6732 padding). The DataSegmentLength MUST be 0 whenever the PDU has no 6733 data segment. 6735 11.2.1.7. LUN 6737 Some opcodes operate on a specific Logical Unit. The Logical Unit 6738 Number (LUN) field identifies which Logical Unit. If the opcode 6739 does not relate to a Logical Unit, this field is either ignored or 6740 may be used in an opcode specific way. The LUN field is 64-bits 6741 and should be formatted in accordance with [SAM2]. For example, 6742 LUN[0] from [SAM2] is BHS byte 8 and so on up to LUN[7] from 6743 [SAM2], which is BHS byte 15. 6745 11.2.1.8. Initiator Task Tag 6747 The initiator assigns a Task Tag to each iSCSI task it issues. 6748 While a task exists, this tag MUST uniquely identify the task 6749 session-wide. SCSI may also use the initiator task tag as part of 6750 the SCSI task identifier when the timespan during which an iSCSI 6751 initiator task tag must be unique extends over the timespan during 6752 which a SCSI task tag must be unique. However, the iSCSI Initiator 6753 Task Tag must exist and be unique even for untagged SCSI commands. 6755 An ITT value of 0xffffffff is reserved and MUST NOT be assigned 6756 for a task by the initiator. The only instance in which it may be 6757 seen on the wire is in a target-initiated NOP-In PDU (Section 6758 11.19) and in the initiator response to that PDU, if necessary. 6760 11.2.2. Additional Header Segment (AHS) 6762 The general format of an AHS is: 6764 Byte/ 0 | 1 | 2 | 3 | 6765 / | | | | 6766 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 6767 +---------------+---------------+---------------+--------------+ 6768 0| AHSLength | AHSType | AHS-Specific | 6769 +---------------+---------------+---------------+--------------+ 6770 4/ AHS-Specific / 6771 +/ / 6772 +---------------+---------------+---------------+--------------+ 6773 x 6775 11.2.2.1. AHSType 6777 The AHSType field is coded as follows: 6779 bit 0-1 - Reserved 6781 bit 2-7 - AHS code 6783 0 - Reserved 6784 1 - Extended CDB 6786 2 - Expected Bidirectional Read Data Length 6788 3 - 63 Reserved 6790 11.2.2.2. AHSLength 6792 This field contains the effective length in bytes of the AHS 6793 excluding AHSType and AHSLength and padding, if any. The AHS is 6794 padded to the smallest integer number of 4 byte words (i.e., from 6795 0 up to 3 padding bytes). 6797 11.2.2.3. Extended CDB AHS 6799 The format of the Extended CDB AHS is: 6801 Byte/ 0 | 1 | 2 | 3 | 6802 / | | | | 6803 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 6804 +---------------+---------------+---------------+--------------+ 6805 0| AHSLength (CDBLength-15) | 0x01 | Reserved | 6806 +---------------+---------------+---------------+--------------+ 6807 4/ ExtendedCDB...+padding / 6808 +/ / 6809 +---------------+---------------+---------------+--------------+ 6810 x 6812 This type of AHS MUST NOT be used if the CDBLength is less than 6813 17. 6814 The length includes the reserved byte 3. 6816 11.2.2.4. Bidirectional Expected Read-Data Length AHS 6818 The format of the Bidirectional Read Expected Data Transfer Length 6819 AHS is: 6821 Byte/ 0 | 1 | 2 | 3 | 6822 / | | | | 6823 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 6824 +---------------+---------------+---------------+--------------+ 6825 0| AHSLength (0x0005) | 0x02 | Reserved | 6826 +---------------+---------------+---------------+--------------+ 6827 4| Expected Read-Data Length | 6828 +---------------+---------------+---------------+--------------+ 6829 8 6831 11.2.3. Header Digest and Data Digest 6833 Optional header and data digests protect the integrity of the 6834 header and data, respectively. The digests, if present, are 6835 located, respectively, after the header and PDU-specific data, and 6836 cover respectively the header and the PDU data, each including 6837 the padding bytes, if any. 6839 The existence and type of digests are negotiated during the Login 6840 Phase. 6842 The separation of the header and data digests is useful in iSCSI 6843 routing applications, in which only the header changes when a 6844 message is forwarded. In this case, only the header digest should 6845 be recalculated. 6847 Digests are not included in data or header length fields. 6849 A zero-length Data Segment also implies a zero-length data-digest. 6851 11.2.4. Data Segment 6853 The (optional) Data Segment contains PDU associated data. Its 6854 payload effective length is provided in the BHS field - 6855 DataSegmentLength. The Data Segment is also padded to an integer 6856 number of 4 byte words. 6858 11.3. SCSI Command 6860 The format of the SCSI Command PDU is: 6862 Byte/ 0 | 1 | 2 | 3 | 6863 / | | | | 6864 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 6865 +---------------+---------------+---------------+--------------+ 6866 0|.|I| 0x01 |F|R|W|. .|ATTR | Reserved | 6867 +---------------+---------------+---------------+--------------+ 6868 4|TotalAHSLength | DataSegmentLength | 6869 +---------------+---------------+---------------+--------------+ 6870 8| Logical Unit Number (LUN) | 6871 + + 6872 12| | 6873 +---------------+---------------+---------------+--------------+ 6874 16| Initiator Task Tag | 6875 +---------------+---------------+---------------+--------------+ 6876 20| Expected Data Transfer Length | 6877 +---------------+---------------+---------------+--------------+ 6878 24| CmdSN | 6879 +---------------+---------------+---------------+--------------+ 6880 28| ExpStatSN | 6881 +---------------+---------------+---------------+--------------+ 6882 32/ SCSI Command Descriptor Block (CDB) / 6883 +/ / 6884 +---------------+---------------+---------------+--------------+ 6885 48/ AHS (Optional) / 6886 +---------------+---------------+---------------+--------------+ 6887 x/ Header Digest (Optional) / 6888 +---------------+---------------+---------------+--------------+ 6889 y/ (DataSegment, Command Data) (Optional) / 6890 +/ / 6891 +---------------+---------------+---------------+--------------+ 6892 z/ Data Digest (Optional) / 6893 +---------------+---------------+---------------+--------------+ 6895 11.3.1. Flags and Task Attributes (byte 1) 6897 The flags for a SCSI Command are: 6899 bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs 6900 follow this PDU. When F=1 for a write and if Expected Data 6901 Transfer Length is larger than the DataSegmentLength, the 6902 target may solicit additional data through R2T. 6904 bit 1 (R) is set to 1 when the command is expected to input 6905 data. 6907 bit 2 (W) is set to 1 when the command is expected to output 6908 data. 6910 bit 3-4 Reserved. 6912 bit 5-7 contains Task Attributes. 6914 Task Attributes (ATTR) have one of the following integer values 6915 (see [SAM2] for details): 6917 0 - Untagged 6919 1 - Simple 6921 2 - Ordered 6923 3 - Head of Queue 6925 4 - ACA 6927 5-7 - Reserved 6929 Setting both the W and the F bit to 0 is an error. 6930 Either or both of R and W MAY be 1 when either the Expected Data 6931 Transfer Length and/or Bidirectional Read Expected Data Transfer 6932 Length are 0, but they MUST NOT both be 0 when the Expected Data 6933 Transfer Length and/or Bidirectional Read Expected Data Transfer 6934 Length are not 0 (i.e., when some data transfer is expected the 6935 transfer direction is indicated by the R and/or W bit). 6937 11.3.2. CmdSN - Command Sequence Number 6939 Enables ordered delivery across multiple connections in a single 6940 session. 6942 11.3.3. ExpStatSN 6944 Command responses up to ExpStatSN-1 (mod 2**32) have been received 6945 (acknowledges status) on the connection. 6947 11.3.4. Expected Data Transfer Length 6949 For unidirectional operations, the Expected Data Transfer Length 6950 field contains the number of bytes of data involved in this SCSI 6951 operation. For a unidirectional write operation (W flag set to 1 6952 and R flag set to 0), the initiator uses this field to specify the 6953 number of bytes of data it expects to transfer for this operation. 6954 For a unidirectional read operation (W flag set to 0 and R flag 6955 set to 1), the initiator uses this field to specify the number of 6956 bytes of data it expects the target to transfer to the initiator. 6957 It corresponds to the SAM2 byte count. 6959 For bidirectional operations (both R and W flags are set to 1), 6960 this field contains the number of data bytes involved in the write 6961 transfer. For bidirectional operations, an additional header 6962 segment MUST be present in the header sequence that indicates the 6963 Bidirectional Read Expected Data Transfer Length. The Expected 6964 Data Transfer Length field and the Bidirectional Read Expected 6965 Data Transfer Length field correspond to the SAM2 byte count. 6967 If the Expected Data Transfer Length for a write and the length of 6968 the immediate data part that follows the command (if any) are the 6969 same, then no more data PDUs are expected to follow. In this 6970 case, the F bit MUST be set to 1. 6972 If the Expected Data Transfer Length is higher than the 6973 FirstBurstLength (the negotiated maximum amount of unsolicited 6974 data the target will accept), the initiator MUST send the maximum 6975 amount of unsolicited data OR ONLY the immediate data, if any. 6977 Upon completion of a data transfer, the target informs the 6978 initiator (through residual counts) of how many bytes were 6979 actually processed (sent and/or received) by the target. 6981 11.3.5. CDB - SCSI Command Descriptor Block 6983 There are 16 bytes in the CDB field to accommodate the commonly 6984 used CDBs. Whenever the CDB is larger than 16 bytes, an Extended 6985 CDB AHS MUST be used to contain the CDB spillover. 6987 11.3.6. Data Segment - Command Data 6989 Some SCSI commands require additional parameter data to accompany 6990 the SCSI command. This data may be placed beyond the boundary of 6991 the iSCSI header in a data segment. Alternatively, user data 6992 (e.g., from a WRITE operation) can be placed in the data segment 6993 (both cases are referred to as immediate data). These data are 6994 governed by the rules for solicited vs. unsolicited data outlined 6995 in Section 4.2.5.2 - "Data Transfer Overview". 6997 11.4. SCSI Response 6999 The format of the SCSI Response PDU is: 7001 Byte/ 0 | 1 | 2 | 3 | 7002 / | | | | 7003 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 7004 +---------------+---------------+---------------+--------------+ 7005 0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status | 7006 +---------------+---------------+---------------+--------------+ 7007 4|TotalAHSLength | DataSegmentLength | 7008 +---------------+---------------+---------------+--------------+ 7009 8| Reserved | 7010 + + 7011 12| | 7012 +---------------+---------------+---------------+--------------+ 7013 16| Initiator Task Tag | 7014 +---------------+---------------+---------------+--------------+ 7015 20| SNACK Tag or Reserved | 7016 +---------------+---------------+---------------+--------------+ 7017 24| StatSN | 7018 +---------------+---------------+---------------+--------------+ 7019 28| ExpCmdSN | 7020 +---------------+---------------+---------------+--------------+ 7021 32| MaxCmdSN | 7022 +---------------+---------------+---------------+--------------+ 7023 36| ExpDataSN or Reserved | 7024 +---------------+---------------+---------------+--------------+ 7025 40| Bidirectional Read Residual Count or Reserved | 7026 +---------------+---------------+---------------+--------------+ 7027 44| Residual Count or Reserved | 7028 +---------------+---------------+---------------+--------------+ 7029 48| Header-Digest (Optional) | 7030 +---------------+---------------+---------------+--------------+ 7031 / Data Segment (Optional) / 7032 +/ / 7033 +---------------+---------------+---------------+--------------+ 7034 | Data-Digest (Optional) | 7035 +---------------+---------------+---------------+--------------+ 7037 11.4.1. Flags (byte 1) 7039 bit 1-2 Reserved. 7041 bit 3 - (o) set for Bidirectional Read Residual Overflow. In 7042 this case, the Bidirectional Read Residual Count indicates 7043 the number of bytes that were not transferred to the 7044 initiator because the initiator's Expected Bidirectional 7045 Read Data Transfer Length was not sufficient. 7047 bit 4 - (u) set for Bidirectional Read Residual Underflow. In 7048 this case, the Bidirectional Read Residual Count indicates 7049 the number of bytes that were not transferred to the 7050 initiator out of the number of bytes expected to be 7051 transferred. 7053 bit 5 - (O) set for Residual Overflow. In this case, the 7054 Residual Count indicates the number of bytes that were not 7055 transferred because the initiator's Expected Data Transfer 7056 Length was not sufficient. For a bidirectional operation, 7057 the Residual Count contains the residual for the write 7058 operation. 7060 bit 6 - (U) set for Residual Underflow. In this case, the 7061 Residual Count indicates the number of bytes that were not 7062 transferred out of the number of bytes that were expected to 7063 be transferred. For a bidirectional operation, the Residual 7064 Count contains the residual for the write operation. 7066 bit 7 - (0) Reserved. 7068 Bits O and U and bits o and u are mutually exclusive (i.e., having 7069 both o and u or O and U set to 1 is a protocol error). 7070 For a response other than "Command Completed at Target", bits 3-6 7071 MUST be 0. 7073 11.4.2. Status 7075 The Status field is used to report the SCSI status of the command 7076 (as specified in [SAM2]) and is only valid if the Response Code is 7077 Command Completed at target. 7079 Some of the status codes defined in [SAM2] are: 7081 0x00 GOOD 7082 0x02 CHECK CONDITION 7084 0x08 BUSY 7086 0x18 RESERVATION CONFLICT 7088 0x28 TASK SET FULL 7090 0x30 ACA ACTIVE 7092 0x40 TASK ABORTED 7094 See [SAM2] for the complete list and definitions. 7096 If a SCSI device error is detected while data from the initiator 7097 is still expected (the command PDU did not contain all the data 7098 and the target has not received a Data PDU with the final bit 7099 Set), the target MUST wait until it receives a Data PDU with the F 7100 bit set in the last expected sequence before sending the Response 7101 PDU. 7103 11.4.3. Response 7105 This field contains the iSCSI service response. 7107 iSCSI service response codes defined in this specification are: 7109 0x00 - Command Completed at Target 7111 0x01 - Target Failure 7113 0x80-0xff - Vendor specific 7115 All other response codes are reserved. 7117 The Response is used to report a Service Response. The mapping of 7118 the response code into a SCSI service response code value, if 7119 needed, is outside the scope of this document. However, in 7120 symbolic terms response value 0x00 maps to the SCSI service 7121 response (see [SAM2] and [SPC3]) of TASK COMPLETE or LINKED 7122 COMMAND COMPLETE. All other Response values map to the SCSI 7123 service response of SERVICE DELIVERY OR TARGET FAILURE. 7125 If a SCSI Response PDU does not arrive before the session is 7126 terminated, the SCSI service response is SERVICE DELIVERY OR 7127 TARGET FAILURE. 7129 A non-zero response field indicates a failure to execute the 7130 command in which case the Status and Flag fields are undefined. 7132 11.4.4. SNACK Tag 7134 This field contains a copy of the SNACK Tag of the last SNACK Tag 7135 accepted by the target on the same connection and for the command 7136 for which the response is issued. Otherwise it is reserved and 7137 should be set to 0. 7139 After issuing a R-Data SNACK the initiator must discard any SCSI 7140 status unless contained in an SCSI Response PDU carrying the same 7141 SNACK Tag as the last issued R-Data SNACK for the SCSI command on 7142 the current connection. 7144 For a detailed discussion on R-Data SNACK see SNACK. 7146 11.4.5. Residual Count 7148 11.4.5.1. Field Semantics 7150 The Residual Count field MUST be valid in the case where either 7151 the U bit or the O bit is set. If neither bit is set, the Residual 7152 Count field is reserved. Targets may set the residual count and 7153 initiators may use it when the response code is "completed at 7154 target" (even if the status returned is not GOOD). If the O bit is 7155 set, the Residual Count indicates the number of bytes that were 7156 not transferred because the initiator's Expected Data Transfer 7157 Length was not sufficient. If the U bit is set, the Residual Count 7158 indicates the number of bytes that were not transferred out of the 7159 number of bytes expected to be transferred. 7161 11.4.5.2. Residuals Concepts Overview 7163 SCSI-Presented Data Transfer Length (SPDTL) is the term this 7164 document uses (see Section 2.1for definition) to represent the 7165 aggregate data length that the target SCSI layer attempts to 7166 transfer using the local iSCSI layer for a task. Expected Data 7167 Transfer Length (EDTL) is the iSCSI term that represents the 7168 length of data that the iSCSI layer expects to transfer for a 7169 task. EDTL is specified in the SCSI Command PDU. 7171 When SPDTL = EDTL for a task, the target iSCSI layer completes the 7172 task with no residuals. Whenever SPDTL differs from EDTL for a 7173 task, that task is said to have a residual. 7175 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the 7176 SCSI Response PDU as specified in Section 11.4.5.1. The Residual 7177 Count MUST be set to the numerical value of (SPDTL - EDTL). 7179 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 7180 the SCSI Response PDU as specified in Section 11.4.5.1. The 7181 Residual Count MUST be set to the numerical value of (EDTL - 7182 SPDTL). 7184 Note that the Overflow and Underflow scenarios are independent of 7185 Data-In and Data-Out. Either scenario is logically possible in 7186 either direction of data transfer. 7188 11.4.5.3. SCSI REPORT LUNS and Residual Overflow 7190 This section discusses the residual overflow issues citing the 7191 example of the SCSI REPORT LUNS command. Note however that there 7192 are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH 7193 fields following the same underlying rules. The semantics in the 7194 rest of the section apply to all such SCSI commands. 7196 The specification of the SCSI REPORT LUNS command requires that 7197 the SCSI target limit the amount of data transferred to a maximum 7198 size (ALLOCATION LENGTH) provided by the initiator in the REPORT 7199 LUNS CDB. 7201 If the Expected Data Transfer Length (EDTL) in the iSCSI header of 7202 the SCSI Command PDU for a REPORT LUNS command is set to at least 7203 as large as that ALLOCATION LENGTH, the SCSI layer truncation 7204 prevents an iSCSI Residual Overflow from occurring. A SCSI 7205 initiator can detect that such truncation has occurred via other 7206 information at theS CSI layer. The rest of the section elaborates 7207 this required behavior. 7209 The SCSI REPORT LUNS command requests a target SCSI layer to 7210 return a logical unit inventory (LUN list) to the initiator SCSI 7211 layer (see Section 6.21 of [SPC3]). The size of this LUN list may 7212 not be known to the initiator SCSI layer when it issues the REPORT 7213 LUNS command; to avoid transferring more LUN list data than the 7214 initiator is prepared for, the REPORT LUNS CDB contains an 7215 ALLOCATION LENGTH field to specify the maximum amount of data to 7216 be transferred to the initiator for this command. If the initiator 7217 SCSI layer has underestimated the number of logical units at the 7218 target, it is possible that the complete logical unit inventory 7219 does not fit in the specified ALLOCATION LENGTH. In this 7220 situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI 7221 layer "shall terminate transfers to the Data-In Buffer" when the 7222 number of bytes specified by the ALLOCATION LENGTH field have been 7223 transferred. 7225 Therefore, in response to a REPORT LUNS command, the SCSI layer at 7226 the target presents at most ALLOCATION LENGTH bytes of data 7227 (logical unit inventory) to iSCSI for transfer to the initiator. 7228 For a REPORT LUNS command, if the iSCSI EDTL is at least as large 7229 as the ALLOCATION LENGTH, the SCSI truncation ensures that the 7230 EDTL will accommodate all of the data to be transferred. If all of 7231 the logical unit inventory data presented to the iSCSI layer -- 7232 i.e., the data remaining after any SCSI truncation -- is 7233 transferred to the initiator by the iSCSI layer, an iSCSI Residual 7234 Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in 7235 the SCSI Response or final SCSI Data-Out PDU. Note that this 7236 behavior is implied by the combination of Section 11.4.5.1 along 7237 with the specification of the REPORT LUNS command in [SPC3]. 7238 However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in 7239 this scenario, note that the iSCSI Underflow MUST be signaled in 7240 the SCSI Response PDU. An iSCSI Underflow MUST also be signaled 7241 when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the 7242 logical unit inventory data presented to the iSCSI layer is 7243 smaller than the ALLOCATION LENGTH. 7245 The LUN LIST LENGTH field in the logical unit inventory (the first 7246 field in the inventory) is not affected by truncation of the 7247 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 7248 initiator to determine that the received inventory is incomplete 7249 by noticing that the LUN LIST LENGTH in the inventory is larger 7250 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A 7251 common initiator behavior in this situation is to re-issue the 7252 REPORT LUNS command with a larger ALLOCATION LENGTH. 7254 11.4.6. Bidirectional Read Residual Count 7256 The Bidirectional Read Residual Count field MUST be valid in the 7257 case where either the u bit or the o bit is set. If neither bit is 7258 set, the Bidirectional Read Residual Count field is reserved. 7259 Targets may set the Bidirectional Read Residual Count and 7260 initiators may use it when the response code is "completed at 7261 target". If the o bit is set, the Bidirectional Read Residual 7262 Count indicates the number of bytes that were not transferred to 7263 the initiator because the initiator's Expected Bidirectional Read 7264 Transfer Length was not sufficient. If the u bit is set, the 7265 Bidirectional Read Residual Count indicates the number of bytes 7266 that were not transferred to the initiator out of the number of 7267 bytes expected to be transferred. 7269 11.4.7. Data Segment - Sense and Response Data Segment 7271 iSCSI targets MUST support and enable autosense. If Status is 7272 CHECK CONDITION (0x02), then the Data Segment MUST contain sense 7273 data for the failed command. 7275 For some iSCSI responses, the response data segment MAY contain 7276 some response related information, (e.g., for a target failure, it 7277 may contain a vendor specific detailed description of the 7278 failure). 7280 If the DataSegmentLength is not 0, the format of the Data Segment 7281 is as follows: 7283 Byte/ 0 | 1 | 2 | 3 | 7284 / | | | | 7285 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 7286 +---------------+---------------+---------------+--------------+ 7287 0|SenseLength | Sense Data | 7288 +---------------+---------------+---------------+--------------+ 7289 x/ Sense Data / 7290 +---------------+---------------+---------------+--------------+ 7291 y/ Response Data / 7292 / / 7293 +---------------+---------------+---------------+--------------+ 7294 z| 7295 11.4.7.1. SenseLength 7297 Length of Sense Data. 7299 11.4.7.2. Sense Data 7301 The Sense Data contains detailed information about a check 7302 condition and [SPC3] specifies the format and content of the Sense 7303 Data. 7305 Certain iSCSI conditions result in the command being terminated at 7306 the target (response Command Completed at Target) with a SCSI 7307 Check Condition Status as outlined in the next table: 7309 +--------------------------+----------+--------------------------+ 7310 | iSCSI Condition |Sense | Additional Sense Code & | 7311 | |Key | Qualifier | 7312 +--------------------------+----------+--------------------------+ 7313 | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c | 7314 | data |Command-0B| Write Error | 7315 +--------------------------+----------+--------------------------+ 7316 | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d | 7317 | |Command-0B| Write Error | 7318 +--------------------------+----------+--------------------------+ 7319 | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 | 7320 | error |Command-0B| CRC Error Detected | 7321 +--------------------------+----------+--------------------------+ 7322 | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 | 7323 | |Command-0B| Read Error | 7324 +--------------------------+----------+--------------------------+ 7326 The target reports the "Incorrect amount of data" condition if 7327 during data output the total data length to output is greater than 7328 FirstBurstLength and the initiator sent unsolicited non-immediate 7329 data but the total amount of unsolicited data is different than 7330 FirstBurstLength. The target reports the same error when the 7331 amount of data sent as a reply to an R2T does not match the amount 7332 requested. 7334 11.4.8. ExpDataSN 7336 The number of Data-In (read) PDUs the target has sent for the 7337 command. 7339 This field MUST be 0 if the response code is not Command Completed 7340 at Target or the target sent no Data-In PDUs for the command. 7341 11.4.9. StatSN - Status Sequence Number 7343 StatSN is a Sequence Number that the target iSCSI layer generates 7344 per connection and that in turn, enables the initiator to 7345 acknowledge status reception. StatSN is incremented by 1 for every 7346 response/status sent on a connection except for responses sent as 7347 a result of a retry or SNACK. In the case of responses sent due to 7348 a retransmission request, the StatSN MUST be the same as the first 7349 time the PDU was sent unless the connection has since been 7350 restarted. 7352 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator 7354 ExpCmdSN is a Sequence Number that the target iSCSI returns to the 7355 initiator to acknowledge command reception. It is used to update a 7356 local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1 7357 indicates that the target cannot accept new commands. 7359 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 7361 MaxCmdSN is a Sequence Number that the target iSCSI returns to the 7362 initiator to indicate the maximum CmdSN the initiator can send. It 7363 is used to update a local variable with the same name. If MaxCmdSN 7364 is equal to ExpCmdSN-1, this indicates to the initiator that the 7365 target cannot receive any additional commands. When MaxCmdSN 7366 changes at the target while the target has no pending PDUs to 7367 convey this information to the initiator, it MUST generate a NOP- 7368 IN to carry the new MaxCmdSN. 7370 11.5. Task Management Function Request 7372 Byte/ 0 | 1 | 2 | 3 | 7373 / | | | | 7374 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 7375 +---------------+---------------+---------------+--------------+ 7376 0|.|I| 0x02 |1| Function | Reserved | 7377 +---------------+---------------+---------------+--------------+ 7378 4|TotalAHSLength | DataSegmentLength | 7379 +---------------+---------------+---------------+--------------+ 7380 8| Logical Unit Number (LUN) or Reserved | 7381 + + 7382 12| | 7383 +---------------+---------------+---------------+--------------+ 7384 16| Initiator Task Tag | 7385 +---------------+---------------+---------------+--------------+ 7386 20| Referenced Task Tag or 0xffffffff | 7387 +---------------+---------------+---------------+--------------+ 7388 24| CmdSN | 7389 +---------------+---------------+---------------+--------------+ 7390 28| ExpStatSN | 7391 +---------------+---------------+---------------+--------------+ 7392 32| RefCmdSN or Reserved | 7393 +---------------+---------------+---------------+--------------+ 7394 36| ExpDataSN or Reserved | 7395 +---------------+---------------+---------------+--------------+ 7396 40/ Reserved / 7397 +/ / 7398 +---------------+---------------+---------------+--------------+ 7399 48| Header-Digest (Optional) | 7400 +---------------+---------------+---------------+--------------+ 7402 11.5.1. Function 7404 The Task Management functions provide an initiator with a way to 7405 explicitly control the execution of one or more Tasks (SCSI and 7406 iSCSI tasks). The Task Management function codes are listed below. 7407 For a more detailed description of SCSI task management, see 7408 [SAM2]. 7410 1 - ABORT TASK - aborts the task identified by the 7411 Referenced Task Tag field. 7413 2 - ABORT TASK SET - aborts all Tasks issued via this 7414 session on the logical unit. 7416 3 - CLEAR ACA - clears the Auto Contingent Allegiance 7417 condition. 7419 4 - CLEAR TASK SET - aborts all Tasks in the appropriate 7420 task set as defined by the TST field in the Control mode 7421 page (see [SPC3]). 7423 5 - LOGICAL UNIT RESET 7425 6 - TARGET WARM RESET 7427 7 - TARGET COLD RESET 7429 8 - TASK REASSIGN - reassigns connection allegiance for the 7430 task identified by the Initiator Task Tag field to this 7431 connection, thus resuming the iSCSI exchanges for the task. 7433 For all these functions, the Task Management function response 7434 MUST be returned as detailed in Section 11.6. All these functions 7435 apply to the referenced tasks regardless of whether they are 7436 proper SCSI tasks or tagged iSCSI operations. Task management 7437 requests must act on all the commands from the same session having 7438 a CmdSN lower than the task management CmdSN. LOGICAL UNIT RESET, 7439 TARGET WARM RESET and TARGET COLD RESET may affect commands from 7440 other sessions or commands from the same session regardless of 7441 their CmdSN value. 7443 If the task management request is marked for immediate delivery, 7444 it must be considered immediately for execution, but the 7445 operations involved (all or part of them) may be postponed to 7446 allow the target to receive all relevant tasks. According to 7447 [SAM2], for all the tasks covered by the Task Management response 7448 (i.e., with CmdSN lower than the task management command CmdSN) 7449 but except the Task Management response to a TASK REASSIGN, 7450 additional responses MUST NOT be delivered to the SCSI layer after 7451 the Task Management response. The iSCSI initiator MAY deliver to 7452 the SCSI layer all responses received before the Task Management 7453 response (i.e., it is a matter of implementation if the SCSI 7454 responses, received before the Task Management response but after 7455 the task management request was issued, are delivered to the SCSI 7456 layer by the iSCSI layer in the initiator). The iSCSI target MUST 7457 ensure that no responses for the tasks covered by a task 7458 management function are delivered to the iSCSI initiator after the 7459 Task Management response except for a task covered by a TASK 7460 REASSIGN. 7462 For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST 7463 continue to respond to all valid target transfer tags (received 7464 via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to 7465 the affected task set, even after issuing the task management 7466 request. The issuing initiator SHOULD however terminate (i.e., by 7467 setting the F-bit to 1) these response sequences as quickly as 7468 possible. The target on its part MUST wait for responses on all 7469 affected target transfer tags before acting on either of these two 7470 task management requests. In case all or part of the response 7471 sequence is not received (due to digest errors) for a valid TTT, 7472 the target MAY treat it as a case of within-command error recovery 7473 class (see Section 7.1.4.1 - "Recovery Within-command") if it is 7474 supporting ErrorRecoveryLevel >= 1, or alternatively may drop the 7475 connection to complete the requested task set function. 7477 If an ABORT TASK is issued for a task created by an immediate 7478 command then RefCmdSN MUST be that of the Task Management request 7479 itself (i.e. CmdSN and RefCmdSN are equal); otherwise RefCmdSN 7480 MUST be set to the CmdSN of the task to be aborted (lower than 7481 CmdSN). 7483 If the connection is still active (it is not undergoing an 7484 implicit or explicit logout), ABORT TASK MUST be issued on the 7485 same connection to which the task to be aborted is allegiant at 7486 the time the Task Management Request is issued. If the connection 7487 is implicitly or explicitly logged out (i.e., no other request 7488 will be issued on the failing connection and no other response 7489 will be received on the failing connection), then an ABORT TASK 7490 function request may be issued on another connection. This Task 7491 Management request will then establish a new allegiance for the 7492 command to be aborted as well as abort it (i.e., the task to be 7493 aborted will not have to be retried or reassigned, and its status, 7494 if sent but not acknowledged, will be resent followed by the Task 7495 Management response). 7497 At the target an ABORT TASK function MUST NOT be executed on a 7498 Task Management request; such a request MUST result in Task 7499 Management response of "Function rejected". 7501 For the LOGICAL UNIT RESET function, the target MUST behave as 7502 dictated by the Logical Unit Reset function in [SAM2]. 7504 The implementation of the TARGET WARM RESET function and the 7505 TARGET COLD RESET function is OPTIONAL and when implemented, 7506 should act as described below. The TARGET WARM RESET is also 7507 subject to SCSI access controls on the requesting initiator as 7508 defined in [SPC3]. When authorization fails at the target, the 7509 appropriate response as described in Targe MUST be returned by the 7510 target. The TARGET COLD RESET function is not subject to SCSI 7511 access controls, but its execution privileges may be managed by 7512 iSCSI mechanisms such as login authentication. 7514 When executing the TARGET WARM RESET and TARGET COLD RESET 7515 functions, the target cancels all pending operations on all 7516 Logical Units known by the issuing initiator. Both functions are 7517 equivalent to the Target Reset function specified by [SAM2]. They 7518 can affect many other initiators logged in with the servicing SCSI 7519 target port. 7521 The target MUST treat the TARGET COLD RESET function additionally 7522 as a power on event, thus terminating all of its TCP connections 7523 to all initiators (all sessions are terminated). For this reason, 7524 the Service Response (defined by [SAM2]) for this SCSI task 7525 management function may not be reliably delivered to the issuing 7526 initiator port. 7528 For the TASK REASSIGN function, the target should reassign the 7529 connection allegiance to this new connection (and thus resume 7530 iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received 7531 by the target after the connection on which the command was 7532 previously executing has been successfully logged-out. The Task 7533 Management response MUST be issued before the reassignment becomes 7534 effective. 7536 For additional usage semantics see Section 7.2- "Retry and 7537 Reassign in Recovery". 7539 At the target a TASK REASSIGN function request MUST NOT be 7540 executed to reassign the connection allegiance of a Task 7541 Management function request, an active text negotiation task, or a 7542 Logout task; such a request MUST result in Task Management 7543 response of "Function rejected". 7545 TASK REASSIGN MUST be issued as an immediate command. 7547 11.5.2. TotalAHSLength and DataSegmentLength 7549 For this PDU, TotalAHSLength and DataSegmentLength MUST be 0. 7551 11.5.3. LUN 7553 This field is required for functions that address a specific LU 7554 (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL 7555 UNIT RESET) and is reserved in all others. 7557 11.5.4. Referenced Task Tag 7559 The Initiator Task Tag of the task to be aborted for the ABORT 7560 TASK function or reassigned for the TASK REASSIGN function. For 7561 all the other functions this field MUST be set to the reserved 7562 value 0xffffffff. 7564 11.5.5. RefCmdSN 7566 If an ABORT TASK is issued for a task created by an immediate 7567 command then RefCmdSN MUST be that of the Task Management request 7568 itself (i.e. CmdSN and RefCmdSN are equal). 7570 For an ABORT TASK of a task created by non-immediate command 7571 RefCmdSN MUST be set to the CmdSN of the task identified by the 7572 Referenced Task Tag field. Targets must use this field as 7573 described in Res when the task identified by the Referenced Task 7574 Tag field is not with the target. 7576 Otherwise, this field is reserved. 7578 11.5.6. ExpDataSN 7580 For recovery purposes, the iSCSI target and initiator maintain a 7581 data acknowledgement reference number - the first input DataSN 7582 number unacknowledged by the initiator. When issuing a new 7583 command, this number is set to 0. If the function is TASK 7584 REASSIGN, which establishes a new connection allegiance for a 7585 previously issued Read or Bidirectional command, ExpDataSN will 7586 contain an updated data acknowledgement reference number or the 7587 value 0; the latter indicating that the data acknowledgement 7588 reference number is unchanged. The initiator MUST discard any data 7589 PDUs from the previous execution that it did not acknowledge and 7590 the target MUST transmit all Data-in PDUs (if any) starting with 7591 the data acknowledgement reference number. The number of 7592 retransmitted PDUs may or may not be the same as the original 7593 transmission depending on if there was a change in 7594 MaxRecvDataSegmentLength in the reassignment. The target MAY also 7595 send no more Data-In PDUs if all data has been acknowledged. 7597 The value of ExpDataSN MUST be 0 or higher than the DataSN of the 7598 last acknowledged Data-In PDU, but not larger than DataSN+1 of the 7599 last Data-IN PDU sent by the target. Any other value MUST be 7600 ignored by the target. 7602 For other functions this field is reserved. 7604 11.6. Task Management Function Response 7605 Byte/ 0 | 1 | 2 | 3 | 7606 / | | | | 7607 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 7608 +---------------+---------------+---------------+--------------+ 7609 0|.|.| 0x22 |1| Reserved | Response | Reserved | 7610 +---------------+---------------+---------------+--------------+ 7611 4|TotalAHSLength | DataSegmentLength | 7612 +--------------------------------------------------------------+ 7613 8/ Reserved / 7614 / / 7615 +---------------+---------------+---------------+--------------+ 7616 16| Initiator Task Tag | 7617 +---------------+---------------+---------------+--------------+ 7618 20| Reserved | 7619 +---------------+---------------+---------------+--------------+ 7620 24| StatSN | 7621 +---------------+---------------+---------------+--------------+ 7622 28| ExpCmdSN | 7623 +---------------+---------------+---------------+--------------+ 7624 32| MaxCmdSN | 7625 +---------------+---------------+---------------+--------------+ 7626 36/ Reserved / 7627 +/ / 7628 +---------------+---------------+---------------+--------------+ 7629 48| Header-Digest (Optional) | 7630 +---------------+---------------+---------------+--------------+ 7632 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR 7633 TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET 7634 and TASK REASSIGN, the target performs the requested Task 7635 Management function and sends a Task Management response back to 7636 the initiator. For TASK REASSIGN, the new connection allegiance 7637 MUST ONLY become effective at the target after the target issues 7638 the Task Management Response. 7640 11.6.1. Response 7642 The target provides a Response, which may take on the following 7643 values: 7645 0 - Function complete. 7646 1 - Task does not exist. 7648 2 - LUN does not exist. 7649 3 - Task still allegiant. 7650 4 - Task allegiance reassignment not supported. 7651 5 - Task management function not supported. 7652 6 - Function authorization failed. 7653 255 - Function rejected. 7655 All other values are reserved. 7657 For a discussion on usage of response codes 3 and 4, see Section 7658 7.2.2- "Allegiance Reassignment". 7660 For the TARGET COLD RESET and TARGET WARM RESET functions, the 7661 target cancels all pending operations across all Logical Units 7662 known to the issuing initiator. For the TARGET COLD RESET 7663 function, the target MUST then close all of its TCP connections to 7664 all initiators (terminates all sessions). 7666 The mapping of the response code into a SCSI service response code 7667 value, if needed, is outside the scope of this document. However, 7668 in symbolic terms Response values 0 and 1 map to the SCSI service 7669 response of FUNCTION COMPLETE. All other Response values map to 7670 the SCSI service response of FUNCTION REJECTED. If a Task 7671 Management function response PDU does not arrive before the 7672 session is terminated, the SCSI service response is SERVICE 7673 DELIVERY OR TARGET FAILURE. 7675 The response to ABORT TASK SET and CLEAR TASK SET MUST only be 7676 issued by the target after all of the commands affected have been 7677 received by the target, the corresponding task management 7678 functions have been executed by the SCSI target, and the delivery 7679 of all responses delivered until the task management function 7680 completion have been confirmed (acknowledged through ExpStatSN) by 7681 the initiator on all connections of this session. For the exact 7682 timeline of events, refer to Section 4.2.3.3 and Section 4.2.3.4. 7684 For the ABORT TASK function, 7686 If the Referenced Task Tag identifies a valid task leading to 7687 a successful termination, then targets must return the 7688 "Function complete" response. 7690 If the Referenced Task Tag does not identify an existing task, 7691 but if the CmdSN indicated by the RefCmdSN field in the 7692 Task Management function request is within the valid CmdSN 7693 window and less than the CmdSN of the Task Management 7694 function request itself, then targets must consider the 7695 CmdSN received and return the "Function complete" response. 7696 If the Referenced Task Tag does not identify an existing task 7697 and if the CmdSN indicated by the RefCmdSN field in the 7698 Task Management function request is outside the valid CmdSN 7699 window, then targets must return the "Task does not exist" 7700 response. 7702 For response semantics on function types that can potentially 7703 impact multiple active tasks on the target, see Section 4.2.3. 7705 11.6.2. TotalAHSLength and DataSegmentLength 7707 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7709 11.7. SCSI Data-out & SCSI Data-in 7711 The SCSI Data-out PDU for WRITE operations has the following 7712 format: 7714 Byte/ 0 | 1 | 2 | 3 | 7715 / | | | | 7716 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 7717 +---------------+---------------+---------------+--------------+ 7718 0|.|.| 0x05 |F| Reserved | 7719 +---------------+---------------+---------------+--------------+ 7720 4|TotalAHSLength | DataSegmentLength | 7721 +---------------+---------------+---------------+--------------+ 7722 8| LUN or Reserved | 7723 + + 7724 12| | 7725 +---------------+---------------+---------------+--------------+ 7726 16| Initiator Task Tag | 7727 +---------------+---------------+---------------+--------------+ 7728 20| Target Transfer Tag or 0xffffffff | 7729 +---------------+---------------+---------------+--------------+ 7730 24| Reserved | 7731 +---------------+---------------+---------------+--------------+ 7732 28| ExpStatSN | 7733 +---------------+---------------+---------------+--------------+ 7734 32| Reserved | 7735 +---------------+---------------+---------------+--------------+ 7736 36| DataSN | 7737 +---------------+---------------+---------------+--------------+ 7738 40| Buffer Offset | 7739 +---------------+---------------+---------------+--------------+ 7740 44| Reserved | 7741 +---------------+---------------+---------------+--------------+ 7742 48| Header-Digest (Optional) | 7743 +---------------+---------------+---------------+--------------+ 7744 / DataSegment / 7745 +/ / 7746 +---------------+---------------+---------------+--------------+ 7747 | Data-Digest (Optional) | 7748 +---------------+---------------+---------------+--------------+ 7750 The SCSI Data-in PDU for READ operations has the following format: 7752 Byte/ 0 | 1 | 2 | 3 | 7753 / | | | | 7754 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 7755 +---------------+---------------+---------------+--------------+ 7756 0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd| 7757 +---------------+---------------+---------------+--------------+ 7758 4|TotalAHSLength | DataSegmentLength | 7759 +---------------+---------------+---------------+--------------+ 7760 8| LUN or Reserved | 7761 + + 7762 12| | 7763 +---------------+---------------+---------------+--------------+ 7764 16| Initiator Task Tag | 7765 +---------------+---------------+---------------+--------------+ 7766 20| Target Transfer Tag or 0xffffffff | 7767 +---------------+---------------+---------------+--------------+ 7768 24| StatSN or Reserved | 7769 +---------------+---------------+---------------+--------------+ 7770 28| ExpCmdSN | 7771 +---------------+---------------+---------------+--------------+ 7772 32| MaxCmdSN | 7773 +---------------+---------------+---------------+--------------+ 7774 36| DataSN | 7775 +---------------+---------------+---------------+--------------+ 7776 40| Buffer Offset | 7777 +---------------+---------------+---------------+--------------+ 7778 44| Residual Count | 7779 +---------------+---------------+---------------+--------------+ 7780 48| Header-Digest (Optional) | 7781 +---------------+---------------+---------------+--------------+ 7782 / DataSegment / 7783 +/ / 7784 +---------------+---------------+---------------+--------------+ 7785 | Data-Digest (Optional) | 7786 +---------------+---------------+---------------+--------------+ 7788 Status can accompany the last Data-in PDU if the command did not 7789 end with an exception (i.e., the status is "good status" - GOOD, 7790 CONDITION MET or INTERMEDIATE CONDITION MET). The presence of 7791 status (and of a residual count) is signaled though the S flag 7792 bit. Although targets MAY choose to send even non-exception 7793 status in separate responses, initiators MUST support non- 7794 exception status in Data-In PDUs. 7796 11.7.1. F (Final) Bit 7798 For outgoing data, this bit is 1 for the last PDU of unsolicited 7799 data or the last PDU of a sequence that answers an R2T. 7801 For incoming data, this bit is 1 for the last input (read) data 7802 PDU of a sequence. Input can be split into several sequences, 7803 each having its own F bit. Splitting the data stream into 7804 sequences does not affect DataSN counting on Data-In PDUs. It MAY 7805 be used as a "change direction" indication for Bidirectional 7806 operations that need such a change. 7808 DataSegmentLength MUST NOT exceed MaxRecvDataSegmentLength for the 7809 direction it is sent and the total of all the DataSegmentLength of 7810 all PDUs in a sequence MUST NOT exceed MaxBurstLength (or 7811 FirstBurstLength for unsolicited data). However the number of 7812 individual PDUs in a sequence (or in total) may be higher than the 7813 MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength 7814 ratio (as PDUs may be limited in length by the sender 7815 capabilities). Using DataSegmentLength of 0 may increase beyond 7816 what is reasonable for the number of PDUs and should therefore be 7817 avoided. 7819 For Bidirectional operations, the F bit is 1 for both the end of 7820 the input sequences and the end of the output sequences. 7822 11.7.2. A (Acknowledge) bit 7824 For sessions with ErrorRecoveryLevel 1 or higher, the target sets 7825 this bit to 1 to indicate that it requests a positive 7826 acknowledgement from the initiator for the data received. The 7827 target should use the A bit moderately; it MAY only set the A bit 7828 to 1 once every MaxBurstLength bytes, or on the last Data-In PDU 7829 that concludes the entire requested read data transfer for the 7830 task from the target's perspective, and it MUST NOT do so more 7831 frequently. The target MUST NOT set to 1 the A bit for sessions 7832 with ErrorRecoveryLevel=0. The initiator MUST ignore the A bit set 7833 to 1 for sessions with ErrorRecoveryLevel=0. 7835 On receiving a Data-In PDU with the A bit set to 1 on a session 7836 with ErrorRecoveryLevel greater than 0, if there are no holes in 7837 the read data until that Data-In PDU, the initiator MUST issue a 7838 SNACK of type DataACK except when it is able to acknowledge the 7839 status for the task immediately via ExpStatSN on other outbound 7840 PDUs if the status for the task is also received. In the latter 7841 case (acknowledgement through ExpStatSN), sending a SNACK of type 7842 DataACK in response to the A bit is OPTIONAL, but if it is done, 7843 it must not be sent after the status acknowledgement through 7844 ExpStatSN. If the initiator has detected holes in the read data 7845 prior to that Data-In PDU, it MUST postpone issuing the SNACK of 7846 type DataACK until the holes are filled. An initiator also MUST 7847 NOT acknowledge the status for the task before those holes are 7848 filled. A status acknowledgement for a task that generated the 7849 Data-In PDUs is considered by the target as an implicit 7850 acknowledgement of the Data-In PDUs if such an acknowledgement was 7851 requested by the target. 7853 11.7.3. Flags (byte 1) 7855 The last SCSI Data packet sent from a target to an initiator for a 7856 SCSI command that completed successfully (with a status of GOOD, 7857 CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may 7858 also optionally contain the Status for the data transfer. In this 7859 case, Sense Data cannot be sent together with the Command Status. 7860 If the command is completed with an error, then the response and 7861 sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be 7862 sent in a SCSI Data packet). For Bidirectional commands, the 7863 status MUST be sent in a SCSI Response PDU. 7865 bit 2-4 - Reserved. 7867 bit 5-6 - used the same as in a SCSI Response. These bits are 7868 only valid when S is set to 1. For details see SNACK . 7870 bit 7 S (status)- set to indicate that the Command Status 7871 field contains status. If this bit is set to 1, the F bit 7872 MUST also be set to 1. 7874 The fields StatSN, Status, and Residual Count only have meaningful 7875 content if the S bit is set to 1 and their values are defined in 7876 SNACK . 7878 11.7.4. Target Transfer Tag and LUN 7880 On outgoing data, the Target Transfer Tag is provided to the 7881 target if the transfer is honoring an R2T. In this case, the 7882 Target Transfer Tag field is a replica of the Target Transfer Tag 7883 provided with the R2T. 7885 On incoming data, the Target Transfer Tag and LUN MUST be provided 7886 by the target if the A bit is set to 1; otherwise they are 7887 reserved. The Target Transfer Tag and LUN are copied by the 7888 initiator into the SNACK of type DataACK that it issues as a 7889 result of receiving a SCSI Data-in PDU with the A bit set to 1. 7891 The Target Transfer Tag values are not specified by this protocol 7892 except that the value 0xffffffff is reserved and means that the 7893 Target Transfer Tag is not supplied. If the Target Transfer Tag 7894 is provided, then the LUN field MUST hold a valid value and be 7895 consistent with whatever was specified with the command; 7896 otherwise, the LUN field is reserved. 7898 11.7.5. DataSN 7900 For input (read) or bidirectional Data-In PDUs, the DataSN is the 7901 input PDU number within the data transfer for the command 7902 identified by the Initiator Task Tag. 7904 R2T and Data-In PDUs, in the context of bidirectional commands, 7905 share the numbering sequence (see Section 4.2.2.4- "Data 7906 Sequencing"). 7908 For output (write) data PDUs, the DataSN is the Data-Out PDU 7909 number within the current output sequence. The current output 7910 sequence is either identified by the Initiator Task Tag (for 7911 unsolicited data) or is a data sequence generated for one R2T (for 7912 data solicited through R2T). 7914 11.7.6. Buffer Offset 7916 The Buffer Offset field contains the offset of this PDU payload 7917 data within the complete data transfer. The sum of the buffer 7919 offset and length should not exceed the expected transfer length 7920 for the command. 7922 The order of data PDUs within a sequence is determined by 7923 DataPDUInOrder. When set to Yes, it means that PDUs have to be in 7924 increasing Buffer Offset order and overlays are forbidden. 7926 The ordering between sequences is determined by 7927 DataSequenceInOrder. When set to Yes, it means that sequences have 7928 to be in increasing Buffer Offset order and overlays are 7929 forbidden. 7931 11.7.7. DataSegmentLength 7933 This is the data payload length of a SCSI Data-In or SCSI Data-Out 7934 PDU. The sending of 0 length data segments should be avoided, but 7935 initiators and targets MUST be able to properly receive 0 length 7936 data segments. 7938 The Data Segments of Data-in and Data-out PDUs SHOULD be filled to 7939 the integer number of 4 byte words (real payload) unless the F bit 7940 is set to 1. 7942 11.8. Ready To Transfer (R2T) 7944 Byte/ 0 | 1 | 2 | 3 | 7945 / | | | | 7946 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 7947 +---------------+---------------+---------------+--------------+ 7948 0|.|.| 0x31 |1| Reserved | 7949 +---------------+---------------+---------------+--------------+ 7950 4|TotalAHSLength | DataSegmentLength | 7951 +---------------+---------------+---------------+--------------+ 7952 8| LUN | 7953 + + 7954 12| | 7955 +---------------+---------------+---------------+--------------+ 7956 16| Initiator Task Tag | 7957 +---------------+---------------+---------------+--------------+ 7958 20| Target Transfer Tag | 7959 +---------------+---------------+---------------+--------------+ 7960 24| StatSN | 7961 +---------------+---------------+---------------+--------------+ 7962 28| ExpCmdSN | 7963 +---------------+---------------+---------------+--------------+ 7964 32| MaxCmdSN | 7965 +---------------+---------------+---------------+--------------+ 7966 36| R2TSN | 7967 +---------------+---------------+---------------+--------------+ 7968 40| Buffer Offset | 7969 +---------------+---------------+---------------+--------------+ 7970 44| Desired Data Transfer Length | 7971 +--------------------------------------------------------------+ 7972 48| Header-Digest (Optional) | 7973 +---------------+---------------+---------------+--------------+ 7975 When an initiator has submitted a SCSI Command with data that 7976 passes from the initiator to the target (WRITE), the target may 7977 specify which blocks of data it is ready to receive. The target 7978 may request that the data blocks be delivered in whichever order 7979 is convenient for the target at that particular instant. This 7980 information is passed from the target to the initiator in the 7981 Ready To Transfer (R2T) PDU. 7983 In order to allow write operations without an explicit initial 7984 R2T, the initiator and target MUST have negotiated the key 7985 InitialR2T to No during Login. 7987 An R2T MAY be answered with one or more SCSI Data-out PDUs with a 7988 matching Target Transfer Tag. If an R2T is answered with a single 7989 Data-out PDU, the Buffer Offset in the Data PDU MUST be the same 7990 as the one specified by the R2T, and the data length of the Data 7991 PDU MUST be the same as the Desired Data Transfer Length specified 7992 in the R2T. If the R2T is answered with a sequence of Data PDUs, 7993 the Buffer Offset and Length MUST be within the range of those 7994 specified by R2T, and the last PDU MUST have the F bit set to 1. 7995 If the last PDU (marked with the F bit) is received before the 7996 Desired Data Transfer Length is transferred, a target MAY choose 7997 to Reject that PDU with "Protocol error" reason code. 7998 DataPDUInOrder governs the Data-Out PDU ordering. If 7999 DataPDUInOrder is set to Yes, the Buffer Offsets and Lengths for 8000 consecutive PDUs MUST form a continuous non-overlapping range and 8001 the PDUs MUST be sent in increasing offset order. 8003 The target may send several R2T PDUs. It, therefore, can have a 8004 number of pending data transfers. The number of outstanding R2T 8005 PDUs are limited by the value of the negotiated key 8006 MaxOutstandingR2T. Within a task, outstanding R2Ts MUST be 8007 fulfilled by the initiator in the order in which they were 8008 received. 8010 R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T 8011 (Recovery-R2T) is generated by a target upon detecting the loss of 8012 one or more Data-Out PDUs due to: 8014 - Digest error 8016 - Sequence error 8018 - Sequence reception timeout 8020 A Recovery-R2T carries the next unused R2TSN, but requests part of 8021 or the entire data burst that an earlier R2T (with a lower R2TSN) 8022 had already requested. 8024 DataSequenceInOrder governs the buffer offset ordering in 8025 consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive 8026 R2Ts MUST refer to continuous non-overlapping ranges except for 8027 Recovery-R2Ts. 8029 11.8.1. TotalAHSLength and DataSegmentLength 8031 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 8033 11.8.2. R2TSN 8035 R2TSN is the R2T PDU input PDU number within the command 8036 identified by the Initiator Task Tag. 8038 For bidirectional commands R2T and Data-In PDUs share the input 8039 PDU numbering sequence (see Section 4.2.2.4- "Data Sequencing"). 8041 11.8.3. StatSN 8043 The StatSN field will contain the next StatSN. The StatSN for this 8044 connection is not advanced after this PDU is sent. 8046 11.8.4. Desired Data Transfer Length and Buffer Offset 8048 The target specifies how many bytes it wants the initiator to send 8049 because of this R2T PDU. The target may request the data from the 8050 initiator in several chunks, not necessarily in the original order 8051 of the data. The target, therefore, also specifies a Buffer Offset 8052 that indicates the point at which the data transfer should begin, 8053 relative to the beginning of the total data transfer. The Desired 8054 Data Transfer Length MUST NOT be 0 and MUST NOT exceed 8055 MaxBurstLength. 8057 11.8.5. Target Transfer Tag 8059 The target assigns its own tag to each R2T request that it sends 8060 to the initiator. This tag can be used by the target to easily 8061 identify the data it receives. The Target Transfer Tag and LUN are 8062 copied in the outgoing data PDUs and are only used by the target. 8063 There is no protocol rule about the Target Transfer Tag except 8064 that the value 0xffffffff is reserved and MUST NOT be sent by a 8065 target in an R2T. 8067 11.9. Asynchronous Message 8069 An Asynchronous Message may be sent from the target to the 8070 initiator without correspondence to a particular command. The 8071 target specifies the reason for the event and sense data. 8073 Byte/ 0 | 1 | 2 | 3 | 8074 / | | | | 8075 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 8076 +---------------+---------------+---------------+--------------+ 8077 0|.|.| 0x32 |1| Reserved | 8078 +---------------+---------------+---------------+--------------+ 8079 4|TotalAHSLength | DataSegmentLength | 8080 +---------------+---------------+---------------+--------------+ 8081 8| LUN or Reserved | 8082 + + 8083 12| | 8084 +---------------+---------------+---------------+--------------+ 8085 16| 0xffffffff | 8086 +---------------+---------------+---------------+--------------+ 8087 20| Reserved | 8088 +---------------+---------------+---------------+--------------+ 8089 24| StatSN | 8090 +---------------+---------------+---------------+--------------+ 8091 28| ExpCmdSN | 8092 +---------------+---------------+---------------+--------------+ 8093 32| MaxCmdSN | 8094 +---------------+---------------+---------------+--------------+ 8095 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | 8096 +---------------+---------------+---------------+--------------+ 8097 40| Parameter2 or Reserved | Parameter3 or Reserved | 8098 +---------------+---------------+---------------+--------------+ 8099 44| Reserved | 8100 +---------------+---------------+---------------+--------------+ 8101 48| Header-Digest (Optional) | 8102 +---------------+---------------+---------------+--------------+ 8103 / DataSegment - Sense Data and iSCSI Event Data / 8104 +/ / 8105 +---------------+---------------+---------------+--------------+ 8106 | Data-Digest (Optional) | 8107 +---------------+---------------+---------------+--------------+ 8109 Some Asynchronous Messages are strictly related to iSCSI while 8110 others are related to SCSI [SAM2]. 8112 StatSN counts this PDU as an acknowledgeable event (StatSN is 8113 advanced), which allows for initiator and target state 8114 synchronization. 8116 11.9.1. AsyncEvent 8118 The codes used for iSCSI Asynchronous Messages (events) are: 8120 0 (SCSI_ASYNC) - a SCSI Asynchronous Event is reported in the 8121 sense data. Sense Data that accompanies the report, in the 8122 data segment, identifies the condition. The sending of a 8123 SCSI Event (Asynchronous Event Reporting in SCSI 8124 terminology) is dependent on the target support for SCSI 8125 asynchronous event reporting (see [SAM2]) as indicated in 8126 the standard INQUIRY data (see [SPC3]). Its use may be 8127 enabled by parameters in the SCSI Control mode page (see 8128 [SPC3]). 8130 1 (REQUEST_LOGOUT) - target requests Logout. This Async 8131 Message MUST be sent on the same connection as the one 8132 requesting to be logged out. The initiator MUST honor this 8133 request by issuing a Logout as early as possible, but no 8134 later than Parameter3 seconds. Initiator MUST send a 8135 Logout with a reason code of "Close the connection" OR 8136 "Close the session" to close all the connections. Once this 8137 message is received, the initiator SHOULD NOT issue new 8138 iSCSI commands on the connection to be logged out. The 8139 target MAY reject any new I/O requests that it receives 8140 after this Message with the reason code "Waiting for 8141 Logout". If the initiator does not Logout in Parameter3 8142 seconds, the target should send an Async PDU with iSCSI 8143 event code "Dropped the connection" if possible, or simply 8144 terminate the transport connection. Parameter1 and 8145 Parameter2 are reserved. 8147 2 (CONNECTION_DROP) - target indicates it will drop the 8148 connection. 8149 The Parameter1 field indicates the CID of the connection 8150 going to be dropped. 8152 The Parameter2 field (Time2Wait) indicates, in seconds, the 8153 minimum time to wait before attempting to reconnect or 8154 reassign. 8156 The Parameter3 field (Time2Retain) indicates the maximum 8157 time allowed to reassign commands after the initial wait (in 8158 Parameter2). 8160 If the initiator does not attempt to reconnect and/or 8161 reassign the outstanding commands within the time specified 8162 by Parameter3, or if Parameter3 is 0, the target will 8163 terminate all outstanding commands on this connection. In 8164 this case, no other responses should be expected from the 8165 target for the outstanding commands on this connection. 8167 A value of 0 for Parameter2 indicates that reconnect can be 8168 attempted immediately. 8170 3 (SESSION_DROP) - target indicates it will drop all the 8171 connections of this session. 8173 Parameter1 field is reserved. 8175 The Parameter2 field (Time2Wait) indicates, in seconds, the 8176 minimum time to wait before attempting to reconnect. 8177 The Parameter3 field (Time2Retain) indicates the maximum 8178 time allowed to reassign commands after the initial wait (in 8179 Parameter2). 8181 If the initiator does not attempt to reconnect and/or 8182 reassign the outstanding commands within the time specified 8183 by Parameter3, or if Parameter3 is 0, the session is 8184 terminated. In this case, the target will terminate all 8185 outstanding commands in this session; no other responses 8186 should be expected from the target for the outstanding 8187 commands in this session. A value of 0 for Parameter2 8188 indicates that reconnect can be attempted immediately. 8190 4 (RENEGOTIATE) - target requests parameter negotiation on 8191 this connection. The initiator MUST honor this request by 8192 issuing a Text Request (that can be empty) on the same 8193 connection as early as possible, but no later than 8194 Parameter3 seconds, unless a Text Request is already pending 8195 on the connection, or by issuing a Logout Request. If the 8196 initiator does not issue a Text Request the target may 8197 reissue the Asynchronous Message requesting parameter 8198 negotiation. 8200 5 (FAST_ABORT) - all active tasks for LU with a matching LUN 8201 field in the Async Message PDU are being terminated. The 8202 receiving initiator iSCSI layer MUST respond to this Message 8203 by taking the following steps in order. 8205 - Stop Data-Out transfers on that connection for all active 8206 TTTs for the affected LUN quoted in the Async Message 8207 PDU. 8208 - Acknowledge the StatSN of the Async Message PDU via a NOP- 8209 Out PDU with ITT=0xffffffff (i.e., non-ping flavor), 8210 while copying the LUN field from the Async Message to 8211 NOP-Out. 8213 This value of AsyncEvent however MUST NOT be used on an 8214 iSCSI session unless the new TaskReporting text key defined 8215 in Section 13.23 was negotiated to FastAbort on the session. 8217 255 - vendor-specific iSCSI Event. The AsyncVCode details the 8218 vendor code, and data MAY accompany the report. 8220 All other event codes are reserved. 8222 11.9.2. AsyncVCode 8224 AsyncVCode is a vendor specific detail code that is only valid if 8225 the AsyncEvent field indicates a vendor specific event. Otherwise, 8226 it is reserved. 8228 11.9.3. LUN 8230 The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this 8231 field is reserved. 8232 11.9.4. Sense Data and iSCSI Event Data 8234 For a SCSI event, this data accompanies the report in the data 8235 segment and identifies the condition. 8237 For an iSCSI event, additional vendor-unique data MAY accompany 8238 the Async event. Initiators MAY ignore the data when not 8239 understood while processing the rest of the PDU. 8241 If the DataSegmentLength is not 0, the format of the DataSegment 8242 is as follows: 8243 Byte/ 0 | 1 | 2 | 3 | 8244 / | | | | 8245 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 8246 +---------------+---------------+---------------+--------------+ 8247 0|SenseLength | Sense Data | 8248 +---------------+---------------+---------------+--------------+ 8249 x/ Sense Data / 8250 +---------------+---------------+---------------+--------------+ 8251 y/ iSCSI Event Data / 8252 / / 8253 +---------------+---------------+---------------+--------------+ 8254 z| 8256 11.9.4.1. SenseLength 8258 This is the length of Sense Data. When the Sense Data field is 8259 empty (e.g., the event is not a SCSI event) SenseLength is 0. 8261 11.10. Text Request 8263 The Text Request is provided to allow for the exchange of 8264 information and for future extensions. It permits the initiator to 8265 inform a target of its capabilities or to request some special 8266 operations. 8268 Byte/ 0 | 1 | 2 | 3 | 8269 / | | | | 8270 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 8271 +---------------+---------------+---------------+--------------+ 8272 0|.|I| 0x04 |F|C| Reserved | 8273 +---------------+---------------+---------------+--------------+ 8274 4|TotalAHSLength | DataSegmentLength | 8275 +---------------+---------------+---------------+--------------+ 8276 8| LUN or Reserved | 8277 + + 8278 12| | 8279 +---------------+---------------+---------------+--------------+ 8280 16| Initiator Task Tag | 8281 +---------------+---------------+---------------+--------------+ 8282 20| Target Transfer Tag or 0xffffffff | 8283 +---------------+---------------+---------------+--------------+ 8284 24| CmdSN | 8285 +---------------+---------------+---------------+--------------+ 8286 28| ExpStatSN | 8287 +---------------+---------------+---------------+--------------+ 8288 32/ Reserved / 8289 +/ / 8290 +---------------+---------------+---------------+--------------+ 8291 48| Header-Digest (Optional) | 8292 +---------------+---------------+---------------+--------------+ 8293 / DataSegment (Text) / 8294 +/ / 8295 +---------------+---------------+---------------+--------------+ 8296 | Data-Digest (Optional) | 8297 +---------------+---------------+---------------+--------------+ 8299 An initiator MUST NOT have more than one outstanding Text Request 8300 on a connection at any given time. 8302 On a connection failure, an initiator must either explicitly abort 8303 any active allegiant text negotiation task or must cause such a 8304 task to be implicitly terminated by the target. 8306 11.10.1. F (Final) Bit 8308 When set to 1, indicates that this is the last or only text 8309 request in a sequence of Text Requests; otherwise, it indicates 8310 that more Text Requests will follow. 8312 11.10.2. C (Continue) Bit 8314 When set to 1, indicates that the text (set of key=value pairs) 8315 in this Text Request is not complete (it will be continued on 8316 subsequent Text Requests); otherwise, it indicates that this Text 8317 Request ends a set of key=value pairs. A Text Request with the C 8318 bit set to 1 MUST have the F bit set to 0. 8320 11.10.3. Initiator Task Tag 8322 The initiator assigned identifier for this Text Request. If the 8323 command is sent as part of a sequence of text requests and 8324 responses, the Initiator Task Tag MUST be the same for all the 8325 requests within the sequence (similar to linked SCSI commands). 8326 The I bit for all requests in a sequence also MUST be the same. 8328 11.10.4. Target Transfer Tag 8330 When the Target Transfer Tag is set to the reserved value 8331 0xffffffff, it tells the target that this is a new request and the 8332 target resets any internal state associated with the Initiator 8333 Task Tag (resets the current negotiation state). 8335 The target sets the Target Transfer Tag in a text response to a 8336 value other than the reserved value 0xffffffff whenever it 8337 indicates that it has more data to send or more operations to 8338 perform that are associated with the specified Initiator Task Tag. 8339 It MUST do so whenever it sets the F bit to 0 in the response. By 8340 copying the Target Transfer Tag from the response to the next Text 8341 Request, the initiator tells the target to continue the operation 8342 for the specific Initiator Task Tag. The initiator MUST ignore the 8343 Target Transfer Tag in the Text Response when the F bit is set to 8344 1. 8346 This mechanism allows the initiator and target to transfer a large 8347 amount of textual data over a sequence of text-command/text- 8348 response exchanges, or to perform extended negotiation sequences. 8350 If the Target Transfer Tag is not 0xffffffff, the LUN field MUST 8351 be sent by the target in the Text Response. 8353 A target MAY reset its internal negotiation state if an exchange 8354 is stalled by the initiator for a long time or if it is running 8355 out of resources. 8357 Long text responses are handled as in the following example: 8359 I->T Text SendTargets=All (F=1,TTT=0xffffffff) 8361 T->I Text (F=0,TTT=0x12345678) 8363 I->T Text (F=1, TTT=0x12345678) 8365 T->I Text (F=0, TTT=0x12345678) 8367 I->T Text (F=1, TTT=0x12345678) 8369 ... 8371 T->I Text (F=1, TTT=0xffffffff) 8373 11.10.5. Text 8375 The data lengths of a text request MUST NOT exceed the iSCSI 8376 target MaxRecvDataSegmentLength (a per connection and per 8377 direction negotiated parameter). The text format is specified in 8378 Section 6.2- "Text Mode Negotiation". 8380 Chapter 11 and Chapter 12 list some basic Text key=value pairs, 8381 some of which can be used in Login Request/Response and some in 8382 Text Request/Response. 8384 A key=value pair can span Text request or response boundaries. A 8385 key=value pair can start in one PDU and continue on the next. In 8386 other words the end of a PDU does not necessarily signal the end 8387 of a key=value pair. 8389 The target responds by sending its response back to the initiator. 8390 The response text format is similar to the request text format. 8391 The text response MAY refer to key=value pairs presented in an 8392 earlier text request and the text in the request may refer to 8393 earlier responses. 8395 Chapter 5 details the rules for the Text Requests and Responses. 8397 Text operations are usually meant for parameter 8398 setting/negotiations, but can also be used to perform some long 8399 lasting operations. 8401 Text operations that take a long time should be placed in their 8402 own Text request. 8404 11.11. Text Response 8406 The Text Response PDU contains the target's responses to the 8407 initiator's Text request. The format of the Text field matches 8408 that of the Text request. 8410 Byte/ 0 | 1 | 2 | 3 | 8411 / | | | | 8412 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 8413 +---------------+---------------+---------------+--------------+ 8414 0|.|.| 0x24 |F|C| Reserved | 8415 +---------------+---------------+---------------+--------------+ 8416 4|TotalAHSLength | DataSegmentLength | 8417 +---------------+---------------+---------------+--------------+ 8418 8| LUN or Reserved | 8419 + + 8420 12| | 8421 +---------------+---------------+---------------+--------------+ 8422 16| Initiator Task Tag | 8423 +---------------+---------------+---------------+--------------+ 8424 20| Target Transfer Tag or 0xffffffff | 8425 +---------------+---------------+---------------+--------------+ 8426 24| StatSN | 8427 +---------------+---------------+---------------+--------------+ 8428 28| ExpCmdSN | 8429 +---------------+---------------+---------------+--------------+ 8430 32| MaxCmdSN | 8431 +---------------+---------------+---------------+--------------+ 8432 36/ Reserved / 8433 +/ / 8434 +---------------+---------------+---------------+--------------+ 8435 48| Header-Digest (Optional) | 8436 +---------------+---------------+---------------+--------------+ 8437 / DataSegment (Text) / 8438 +/ / 8439 +---------------+---------------+---------------+--------------+ 8440 | Data-Digest (Optional) | 8441 +---------------+---------------+---------------+--------------+ 8443 11.11.1. F (Final) Bit 8445 When set to 1, in response to a Text Request with the Final bit 8446 set to 1, the F bit indicates that the target has finished the 8447 whole operation. Otherwise, if set to 0 in response to a Text 8448 Request with the Final Bit set to 1, it indicates that the target 8449 has more work to do (invites a follow-on text request). A Text 8450 Response with the F bit set to 1 in response to a Text Request 8451 with the F bit set to 0 is a protocol error. 8453 A Text Response with the F bit set to 1 MUST NOT contain key=value 8454 pairs that may require additional answers from the initiator. 8456 A Text Response with the F bit set to 1 MUST have a Target 8457 Transfer Tag field set to the reserved value of 0xffffffff. 8459 A Text Response with the F bit set to 0 MUST have a Target 8460 Transfer Tag field set to a value other than the reserved 8461 0xffffffff. 8463 11.11.2. C (Continue) Bit 8465 When set to 1, indicates that the text (set of key=value pairs) in 8466 this Text Response is not complete (it will be continued on 8467 subsequent Text Responses); otherwise, it indicates that this Text 8468 Response ends a set of key=value pairs. A Text Response with the C 8469 bit set to 1 MUST have the F bit set to 0. 8471 11.11.3. Initiator Task Tag 8473 The Initiator Task Tag matches the tag used in the initial Text 8474 Request. 8476 11.11.4. Target Transfer Tag 8478 When a target has more work to do (e.g., cannot transfer all the 8479 remaining text data in a single Text Response or has to continue 8480 the negotiation) and has enough resources to proceed, it MUST set 8481 the Target Transfer Tag to a value other than the reserved value 8482 of 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to 8483 0xffffffff. 8485 When the Target Transfer Tag is not 0xffffffff, the LUN field may 8486 be significant. 8488 The initiator MUST copy the Target Transfer Tag and LUN in its 8489 next request to indicate that it wants the rest of the data. 8491 When the target receives a Text Request with the Target Transfer 8492 Tag set to the reserved value of 0xffffffff, it resets its 8493 internal information (resets state) associated with the given 8494 Initiator Task Tag (restarts the negotiation). 8496 When a target cannot finish the operation in a single Text 8497 Response, and does not have enough resources to continue, it 8498 rejects the Text Request with the appropriate Reject code. 8500 A target may reset its internal state associated with an Initiator 8501 Task Tag (the current negotiation state), state expressed through 8502 the Target Transfer Tag if the initiator fails to continue the 8503 exchange for some time. The target may reject subsequent Text 8504 Requests with the Target Transfer Tag set to the "stale" value. 8506 11.11.5. StatSN 8508 The target StatSN variable is advanced by each Text Response sent. 8510 11.11.6. Text Response Data 8512 The data lengths of a text response MUST NOT exceed the iSCSI 8513 initiator MaxRecvDataSegmentLength (a per connection and per 8514 direction negotiated parameter). 8516 The text in the Text Response Data is governed by the same rules 8517 as the text in the Text Request Data (see C (Con). 8519 Although the initiator is the requesting party and controls the 8520 request-response initiation and termination, the target can offer 8521 key=value pairs of its own as part of a sequence and not only in 8522 response to the initiator. 8524 11.12. Login Request 8526 After establishing a TCP connection between an initiator and a 8527 target, the initiator MUST start a Login Phase to gain further 8528 access to the target's resources. 8530 The Login Phase (see Chapter 5) consists of a sequence of Login 8531 requests and responses that carry the same Initiator Task Tag. 8533 Login requests are always considered as immediate. 8535 Byte/ 0 | 1 | 2 | 3 | 8536 / | | | | 8537 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 8538 +---------------+---------------+---------------+--------------+ 8539 0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min | 8540 +---------------+---------------+---------------+--------------+ 8541 4|TotalAHSLength | DataSegmentLength | 8542 +---------------+---------------+---------------+--------------+ 8543 8| ISID | 8544 + +---------------+--------------+ 8545 12| | TSIH | 8546 +---------------+---------------+---------------+--------------+ 8547 16| Initiator Task Tag | 8548 +---------------+---------------+---------------+--------------+ 8549 20| CID | Reserved | 8550 +---------------+---------------+---------------+--------------+ 8551 24| CmdSN | 8552 +---------------+---------------+---------------+--------------+ 8553 28| ExpStatSN or Reserved | 8554 +---------------+---------------+---------------+--------------+ 8555 32| Reserved | 8556 +---------------+---------------+---------------+--------------+ 8557 36| Reserved | 8558 +---------------+---------------+---------------+--------------+ 8559 40/ Reserved / 8560 +/ / 8561 +---------------+---------------+---------------+--------------+ 8562 48/ DataSegment - Login Parameters in Text request Format / 8563 +/ / 8564 +---------------+---------------+---------------+--------------+ 8566 11.12.1. T (Transit) Bit 8568 If set to 1, indicates that the initiator is ready to transit to 8569 the next stage. 8571 If the T bit is set to 1 and NSG is FullFeaturePhase, then this 8572 also indicates that the initiator is ready for the Final Login 8573 Response (see Chapter 5). 8575 11.12.2. C (Continue) Bit 8577 When set to 1, indicates that the text (set of key=value pairs) 8578 in this Login Request is not complete (it will be continued on 8579 subsequent Login Requests); otherwise, it indicates that this 8580 Login Request ends a set of key=value pairs. A Login Request with 8581 the C bit set to 1 MUST have the T bit set to 0. 8583 11.12.3. CSG and NSG 8585 Through these fields, Current Stage (CSG) and Next Stage (NSG), 8586 the Login negotiation requests and responses are associated with a 8587 specific stage in the session (SecurityNegotiation, 8588 LoginOperationalNegotiation, FullFeaturePhase) and may indicate 8589 the next stage to which they want to move (see Chapter 5). The 8590 next stage value is only valid when the T bit is 1; otherwise, it 8591 is reserved. 8593 The stage codes are: 8595 - 0 - SecurityNegotiation 8597 - 1 - LoginOperationalNegotiation 8599 - 3 - FullFeaturePhase 8601 All other codes are reserved. 8603 11.12.4. Version 8605 The version number of the current draft is 0x00. As such, all 8606 devices MUST carry version 0x00 for both Version-min and Version- 8607 max. 8609 11.12.4.1. Version-max 8611 Maximum Version number supported. 8613 All Login requests within the Login Phase MUST carry the same 8614 Version-max. 8616 The target MUST use the value presented with the first login 8617 request. 8619 11.12.4.2. Version-min 8621 All Login requests within the Login Phase MUST carry the same 8622 Version-min. The target MUST use the value presented with the 8623 first login request. 8625 11.12.5. ISID 8627 This is an initiator-defined component of the session identifier 8628 and is structured as follows (see Section 10.1.1 for details): 8630 Byte/ 0 | 1 | 2 | 3 | 8631 / | | | | 8632 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 8633 +---------------+---------------+---------------+--------------+ 8634 8| T | A | B | C | 8635 +---------------+---------------+---------------+--------------+ 8636 12| D | 8637 +---------------+---------------+ 8639 The T field identifies the format and usage of A, B, C, and D as 8640 indicated below: 8642 T 8644 00b OUI-Format 8646 A&B are a 22 bit OUI 8648 (the I/G & U/L bits are omitted) 8650 C&D 24 bit qualifier 8652 01b EN - Format (IANA Enterprise Number) 8654 A - Reserved 8656 B&C EN (IANA Enterprise Number) 8658 D - Qualifier 8660 10b "Random" 8662 A - Reserved 8664 B&C Random 8666 D - Qualifier 8668 11b A,B,C&D Reserved 8670 For the T field values 00b and 01b, a combination of A and B (for 8671 00b) or B and C (for 01b) identifies the vendor or organization 8672 whose component (software or hardware) generates this ISID. A 8673 vendor or organization with one or more OUIs, or one or more 8674 Enterprise Numbers, MUST use at least one of these numbers and 8675 select the appropriate value for the T field when its components 8676 generate ISIDs. An OUI or EN MUST be set in the corresponding 8677 fields in network byte order (byte big-endian). 8679 If the T field is 10b, B and C are set to a random 24-bit unsigned 8680 integer value in network byte order (byte big-endian). See 8681 [RFC3721] for how this affects the principle of "conservative 8682 reuse". 8684 The Qualifier field is a 16 or 24-bit unsigned integer value that 8685 provides a range of possible values for the ISID within the 8686 selected namespace. It may be set to any value within the 8687 constraints specified in the iSCSI protocol (see Section 4.4.3 - 8688 "Consequences of the Model" and Section 10.1.1- "Conservative 8689 Reuse of ISIDs"). 8691 The T field value of 11b is reserved. 8693 If the ISID is derived from something assigned to a hardware 8694 adapter or interface by a vendor, as a preset default value, it 8695 MUST be configurable to a value assigned according to the SCSI 8696 port behavior desired by the system in which it is installed (see 8697 Section 10.1.1- "Conservative Reuse of ISIDs" and Section 10.1.2 - 8698 "iSCSI Name, ISID, and TPGT Use"). The resultant ISID MUST also be 8699 persistent over power cycles, reboot, card swap, etc. 8701 11.12.6. TSIH 8703 TSIH must be set in the first Login Request. The reserved value 0 8704 MUST be used on the first connection for a new session. Otherwise, 8705 the TSIH sent by the target at the conclusion of the successful 8706 login of the first connection for this session MUST be used. The 8707 TSIH identifies to the target the associated existing session for 8708 this new connection. 8710 All Login requests within a Login Phase MUST carry the same TSIH. 8712 The target MUST check the value presented with the first login 8713 request and act as specified in Section 5.3.1 - "Login Phase 8714 Start". 8716 11.12.7. Connection ID - CID 8718 A unique ID for this connection within the session. 8720 All Login requests within the Login Phase MUST carry the same CID. 8722 The target MUST use the value presented with the first login 8723 request. 8725 A Login request with a non-zero TSIH and a CID equal to that of an 8726 existing connection implies a logout of the connection followed by 8727 a Login (see Section 6.3.4). For the details of the implicit 8728 Logout Request, see Section 11.14. 8730 11.12.8. CmdSN 8732 CmdSN is either the initial command sequence number of a session 8733 (for the first Login request of a session - the "leading" login), 8734 or the command sequence number in the command stream if the login 8735 is for a new connection in an existing session. 8737 Examples: 8739 - Login on a leading connection - if the leading login carries 8740 the CmdSN 123, all other login requests in the same login 8741 phase carry the CmdSN 123 and the first non-immediate 8742 command in FullFeaturePhase also carries the CmdSN 123. 8744 - Login on other than a leading connection - if the current 8745 CmdSN at the time the first login on the connection is 8746 issued is 500, then that PDU carries CmdSN=500. Subsequent 8747 login requests that are needed to complete this login phase 8748 may carry a CmdSN higher than 500 if non-immediate requests 8749 that were issued on other connections in the same session 8750 advance CmdSN. 8752 If the login request is a leading login request, the target MUST 8753 use the value presented in CmdSN as the target value for ExpCmdSN. 8755 11.12.9. ExpStatSN 8757 For the first Login Request on a connection this is ExpStatSN for 8758 the old connection and this field is only valid if the Login 8759 request restarts a connection (see Section 6.3.4- "Connection 8760 Reinstatement"). 8762 For subsequent Login Requests it is used to acknowledge the Login 8763 Responses with their increasing StatSN values. 8765 11.12.10. Login Parameters 8767 The initiator MUST provide some basic parameters in order to 8768 enable the target to determine if the initiator may use the 8769 target's resources and the initial text parameters for the 8770 security exchange. 8772 All the rules specified in Section 11.10.5 for text requests also 8773 hold for login requests. Keys and their explanations are listed 8774 in Chapter 12 (security negotiation keys) and Section 13 8775 (operational parameter negotiation keys). All keys in Section 13, 8776 except for the X extension formats, MUST be supported by iSCSI 8777 initiators and targets. Keys in Section 12 only need to be 8779 supported when the function to which they refer is mandatory to 8780 implement. 8782 11.13. Login Response 8784 The Login Response indicates the progress and/or end of the Login 8785 Phase. 8787 Byte/ 0 | 1 | 2 | 3 | 8788 / | | | | 8789 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 8790 +---------------+---------------+---------------+--------------+ 8791 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max |Version-active| 8792 +---------------+---------------+---------------+--------------+ 8793 4|TotalAHSLength | DataSegmentLength | 8794 +---------------+---------------+---------------+--------------+ 8795 8| ISID | 8796 + +---------------+--------------+ 8797 12| | TSIH | 8798 +---------------+---------------+---------------+--------------+ 8799 16| Initiator Task Tag | 8800 +---------------+---------------+---------------+--------------+ 8801 20| Reserved | 8802 +---------------+---------------+---------------+--------------+ 8803 24| StatSN | 8804 +---------------+---------------+---------------+--------------+ 8805 28| ExpCmdSN | 8806 +---------------+---------------+---------------+--------------+ 8807 32| MaxCmdSN | 8808 +---------------+---------------+---------------+--------------+ 8809 36| Status-Class | Status-Detail | Reserved | 8810 +---------------+---------------+---------------+--------------+ 8811 40/ Reserved / 8812 +/ / 8813 +---------------+---------------+---------------+--------------+ 8814 48/ DataSegment - Login Parameters in Text request Format / 8815 +/ / 8816 +---------------+---------------+---------------+--------------+ 8818 11.13.1. Version-max 8820 This is the highest version number supported by the target. 8822 All Login responses within the Login Phase MUST carry the same 8823 Version-max. 8825 The initiator MUST use the value presented as a response to the 8826 first login request. 8828 11.13.2. Version-active 8830 Indicates the highest version supported by the target and 8831 initiator. If the target does not support a version within the 8832 range specified by the initiator, the target rejects the login and 8833 this field indicates the lowest version supported by the target. 8835 All Login responses within the Login Phase MUST carry the same 8836 Version-active. 8838 The initiator MUST use the value presented as a response to the 8839 first login request. 8841 11.13.3. TSIH 8843 The TSIH is the target assigned session identifying handle. Its 8844 internal format and content are not defined by this protocol 8845 except for the value 0 that is reserved. With the exception of the 8846 Login Final-Response in a new session, this field should be set to 8847 the TSIH provided by the initiator in the Login Request. For a 8848 new session, the target MUST generate a non-zero TSIH and ONLY 8849 return it in the Login Final-Response (see Section 6.3 - "Login 8850 Phase"). 8852 11.13.4. StatSN 8854 For the first Login Response (the response to the first Login 8855 Request), this is the starting status Sequence Number for the 8856 connection. The next response of any kind, including the next 8857 login response, if any, in the same Login Phase, will carry this 8858 number + 1. This field is only valid if the Status-Class is 0. 8860 11.13.5. Status-Class and Status-Detail 8862 The Status returned in a Login Response indicates the execution 8863 status of the Login Phase. The status includes: 8865 Status-Class 8867 Status-Detail 8869 0 Status-Class indicates success. 8871 A non-zero Status-Class indicates an exception. In this case, 8872 Status-Class is sufficient for a simple initiator to use when 8873 handling exceptions, without having to look at the Status-Detail. 8874 The Status-Detail allows finer-grained exception handling for more 8875 sophisticated initiators and for better information for logging. 8877 The status classes are as follows: 8879 0 - Success - indicates that the iSCSI target successfully 8880 received, understood, and accepted the request. The 8881 numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid 8882 if Status-Class is 0. 8884 1 - Redirection - indicates that the initiator must take 8885 further action to complete the request. This is usually due 8886 to the target moving to a different address. All of the 8887 redirection status class responses MUST return one or more 8888 text key parameters of the type "TargetAddress", which 8889 indicates the target's new address. A redirection response 8890 MAY be issued by a target prior or after completing a 8891 security negotiation if a security negotiation is required. 8892 A redirection SHOULD be accepted by an initiator even 8893 without having the target complete a security negotiation if 8894 any security negotiation is required, and MUST be accepted 8895 by the initiator after the completion of the security 8896 negotiation if any security negotiation is required. 8898 2 - Initiator Error (not a format error) - indicates that the 8899 initiator most likely caused the error. This MAY be due to a 8901 request for a resource for which the initiator does not have 8902 permission. The request should not be tried again. 8904 3 - Target Error - indicates that the target sees no errors in 8905 the initiator's login request, but is currently incapable of 8906 fulfilling the request. The initiator may re-try the same 8907 login request later. 8909 The table below shows all of the currently allocated status codes. 8910 The codes are in hexadecimal; the first byte is the status class 8911 and the second byte is the status detail. 8913 ----------------------------------------------------------------- 8914 Status | Code | Description 8915 |(hex) | 8916 ----------------------------------------------------------------- 8917 Success | 0000 | Login is proceeding OK (*1). 8918 ----------------------------------------------------------------- 8919 Target moved | 0101 | The requested iSCSI Target Name (ITN) 8920 temporarily | | has temporarily moved 8921 | | to the address provided. 8922 ----------------------------------------------------------------- 8923 Target moved | 0102 | The requested ITN has permanently moved 8924 permanently | | to the address provided. 8925 ----------------------------------------------------------------- 8926 Initiator | 0200 | Miscellaneous iSCSI initiator 8927 error | | errors. 8928 ---------------------------------------------------------------- 8929 Authentication| 0201 | The initiator could not be 8930 failure | | successfully authenticated or target 8931 | | authentication is not supported. 8932 ----------------------------------------------------------------- 8933 Authorization | 0202 | The initiator is not allowed access 8934 failure | | to the given target. 8935 ----------------------------------------------------------------- 8936 Not found | 0203 | The requested ITN does not 8937 | | exist at this address. 8938 ----------------------------------------------------------------- 8939 Target removed| 0204 | The requested ITN has been removed and 8940 | |no forwarding address is provided. 8941 ----------------------------------------------------------------- 8942 Unsupported | 0205 | The requested iSCSI version range is 8943 version | | not supported by the target. 8944 ----------------------------------------------------------------- 8945 Too many | 0206 | Too many connections on this SSID. 8946 connections | | 8947 ----------------------------------------------------------------- 8948 Missing | 0207 | Missing parameters (e.g., iSCSI 8949 parameter | | Initiator and/or Target Name). 8950 ----------------------------------------------------------------- 8951 Can't include | 0208 | Target does not support session 8952 in session | | spanning to this connection (address). 8953 ----------------------------------------------------------------- 8954 Session type | 0209 | Target does not support this type of 8955 not supported | | of session or not from this Initiator. 8956 ----------------------------------------------------------------- 8957 Session does | 020a | Attempt to add a connection 8958 not exist | | to a non-existent session. 8959 ----------------------------------------------------------------- 8960 Invalid during| 020b | Invalid Request type during Login. 8961 login | | 8962 ----------------------------------------------------------------- 8963 Target error | 0300 | Target hardware or software error. 8964 ----------------------------------------------------------------- 8965 Service | 0301 | The iSCSI service or target is not 8966 unavailable | | currently operational. 8967 ----------------------------------------------------------------- 8968 Out of | 0302 | The target has insufficient session, 8969 resources | | connection, or other resources. 8970 ----------------------------------------------------------------- 8972 (*1)If the response T bit is 1 in both the request and the 8973 matching response, and the NSG is FullFeaturePhase in both the 8974 request and the matching response, the Login Phase is finished and 8975 the initiator may proceed to issue SCSI commands. 8977 If the Status Class is not 0, the initiator and target MUST close 8978 the TCP connection. 8980 If the target wishes to reject the login request for more than one 8981 reason, it should return the primary reason for the rejection. 8983 11.13.6. T (Transit) bit 8985 The T bit is set to 1 as an indicator of the end of the stage. If 8986 the T bit is set to 1 and NSG is FullFeaturePhase, then this is 8987 also the Final Login Response (see Chapter 5). A T bit of 0 8988 indicates a "partial" response, which means "more negotiation 8989 needed". 8991 A login response with a T bit set to 1 MUST NOT contain key=value 8992 pairs that may require additional answers from the initiator 8993 within the same stage. 8995 If the status class is 0, the T bit MUST NOT be set to 1 if the T 8996 bit in the request was set to 0. 8998 11.13.7. C (Continue) Bit 9000 When set to 1, indicates that the text (set of key=value pairs) in 9001 this Login Response is not complete (it will be continued on 9002 subsequent Login Responses); otherwise, it indicates that this 9003 Login Response ends a set of key=value pairs. A Login Response 9004 with the C bit set to 1 MUST have the T bit set to 0. 9006 11.13.8. Login Parameters 9008 The target MUST provide some basic parameters in order to enable 9009 the initiator to determine if it is connected to the correct port 9010 and the initial text parameters for the security exchange. 9012 All the rules specified in Section 11.11.6 for text responses also 9013 hold for login responses. Keys and their explanations are listed 9014 in Chapter 11 (security negotiation keys) and Chapter 12 9015 (operational parameter negotiation keys). All keys in Section 13, 9016 except for the X extension formats, MUST be supported by iSCSI 9017 initiators and targets. Keys in Section 12, only need to be 9018 supported when the function to which they refer is mandatory to 9019 implement. 9021 11.14. Logout Request 9023 The Logout request is used to perform a controlled closing of a 9024 connection. 9026 An initiator MAY use a logout request to remove a connection from 9027 a session or to close an entire session. 9029 After sending the Logout request PDU, an initiator MUST NOT send 9030 any new iSCSI requests on the closing connection. If the Logout 9031 request is intended to close the session, new iSCSI requests MUST 9032 NOT be sent on any of the connections participating in the 9033 session. 9035 When receiving a Logout request with the reason code of "close the 9036 connection" or "close the session", the target MUST terminate all 9037 pending commands, whether acknowledged via ExpCmdSN or not, on 9038 that connection or session respectively. 9040 When receiving a Logout request with the reason code "remove 9041 connection for recovery", the target MUST discard all requests not 9042 yet acknowledged via ExpCmdSN that were issued on the specified 9043 connection, and suspend all data/status/R2T transfers on behalf of 9044 pending commands on the specified connection. 9046 The target then issues the Logout response and half-closes the TCP 9047 connection (sends FIN). After receiving the Logout response and 9048 attempting to receive the FIN (if still possible), the initiator 9049 MUST completely close the logging-out connection. For the 9050 terminated commands, no additional responses should be expected. 9052 A Logout for a CID may be performed on a different transport 9053 connection when the TCP connection for the CID has already been 9054 terminated. In such a case, only a logical "closing" of the iSCSI 9055 connection for the CID is implied with a Logout. 9057 All commands that were not terminated or not completed (with 9058 status) and acknowledged when the connection is closed completely 9059 can be reassigned to a new connection if the target supports 9060 connection recovery. 9062 If an initiator intends to start recovery for a failing 9063 connection, it MUST use the Logout request to "clean-up" the 9064 target end of a failing connection and enable recovery to start, 9065 or the Login request with a non-zero TSIH and the same CID on a 9066 new connection for the same effect. In sessions with a single 9067 connection, the connection can be closed and then a new connection 9068 reopened. A connection reinstatement login can be used for 9069 recovery (see Section 6.3.4- "Connection Reinstatement"). 9071 A successful completion of a logout request with the reason code 9072 of "close the connection" or "remove the connection for recovery" 9073 results at the target in the discarding of unacknowledged commands 9074 received on the connection being logged out. These are commands 9075 that have arrived on the connection being logged out, but have not 9076 been delivered to SCSI because one or more commands with a smaller 9077 CmdSN has not been received by iSCSI. See Section 4.2.2.1 - 9078 "Command Numbering and Acknowledging". The resulting holes in the 9079 command sequence numbers will have to be handled by appropriate 9080 recovery (see Chapter 6) unless the session is also closed. 9082 The entire logout discussion in this section is also applicable 9083 for an implicit Logout realized by way of a connection 9084 reinstatement or session reinstatement. When a Login Request 9085 performs an implicit Logout, the implicit Logout is performed as 9086 if having the reason codes specified below: 9088 Reason code Type of implicit Logout 9090 ------------------------------------------- 9092 0 session reinstatement 9094 1 connection reinstatement when the operational 9095 ErrorRecoveryLevel < 2 9097 2 connection reinstatement when the operational 9098 ErrorRecoveryLevel = 2 9100 Byte/ 0 | 1 | 2 | 3 | 9101 / | | | | 9102 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 9103 +---------------+---------------+---------------+--------------+ 9104 0|.|I| 0x06 |1| Reason Code | Reserved | 9105 +---------------+---------------+---------------+--------------+ 9106 4|TotalAHSLength | DataSegmentLength | 9107 +--------------------------------------------------------------+ 9108 8/ Reserved / 9109 +/ / 9110 +---------------+---------------+---------------+--------------+ 9111 16| Initiator Task Tag | 9112 +---------------+---------------+---------------+--------------+ 9113 20| CID or Reserved | Reserved | 9114 +---------------+---------------+---------------+--------------+ 9115 24| CmdSN | 9116 +---------------+---------------+---------------+--------------+ 9117 28| ExpStatSN | 9118 +---------------+---------------+---------------+--------------+ 9119 32/ Reserved / 9120 +/ / 9121 +---------------+---------------+---------------+--------------+ 9122 48| Header-Digest (Optional) | 9123 +---------------+---------------+---------------+--------------+ 9125 11.14.1. Reason Code 9127 Reason Code indicates the reason for Logout as follows: 9129 0 - close the session. All commands associated with the 9130 session (if any) are terminated. 9132 1 - close the connection. All commands associated with 9133 connection (if any) are terminated. 9135 2 - remove the connection for recovery. Connection is closed 9136 and all commands associated with it, if any, are to be 9137 prepared for a new allegiance. 9139 All other values are reserved. 9141 11.14.2. TotalAHSLength and DataSegmentLength 9143 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9145 11.14.3. CID 9147 This is the connection ID of the connection to be closed 9148 (including closing the TCP stream). This field is only valid if 9149 the reason code is not "close the session". 9151 11.14.4. ExpStatSN 9153 This is the last ExpStatSN value for the connection to be closed. 9155 11.14.5. Implicit termination of tasks 9157 A target implicitly terminates the active tasks due to the iSCSI 9158 protocol in the following cases: 9160 When a connection is implicitly or explicitly logged out with 9161 the reason code of "Close the connection" and there are 9162 active tasks allegiant to that connection. 9164 When a connection fails and eventually the connection state 9165 times out (state transition M1 in Section 8.2.2- "State 9166 Transition Descriptions for Initiators and Targets") and 9167 there are active tasks allegiant to that connection. 9169 When a successful recovery Logout is performed while there are 9170 active tasks allegiant to that connection, and those tasks 9171 eventually time out after the Time2Wait and Time2Retain 9172 periods without allegiance reassignment. 9174 When a connection is implicitly or explicitly logged out with 9175 the reason code of "Close the session" and there are active 9176 tasks in that session. 9178 If the tasks terminated in any of the above cases are SCSI tasks, 9179 they must be internally terminated as if with CHECK CONDITION 9180 status. This status is only meaningful for appropriately handling 9181 the internal SCSI state and SCSI side effects with respect to 9182 ordering because this status is never communicated back as a 9183 terminating status to the initiator. However additional actions 9184 may have to be taken at SCSI level depending on the SCSI context 9185 as defined by the SCSI standards (e.g., queued commands and ACA, 9186 UA for the next command on the I_T nexus in cases a), b), and c), 9187 after the tasks are terminated, the target MUST report a Unit 9188 Attention condition on the next command processed on any 9189 connection for each affected I_T_L nexus with the status of CHECK 9190 CONDITION, and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS 9191 CLEARED BY ISCSI PROTOCOL EVENT" - etc. - see [SAM4] and [SPC3]). 9193 11.15. Logout Response 9195 The logout response is used by the target to indicate if the 9196 cleanup operation for the connection(s) has completed. 9198 After Logout, the TCP connection referred by the CID MUST be 9199 closed at both ends (or all connections must be closed if the 9200 logout reason was session close). 9202 Byte/ 0 | 1 | 2 | 3 | 9203 / | | | | 9204 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 9205 +---------------+---------------+---------------+--------------+ 9206 0|.|.| 0x26 |1| Reserved | Response | Reserved | 9207 +---------------+---------------+---------------+--------------+ 9208 4|TotalAHSLength | DataSegmentLength | 9209 +--------------------------------------------------------------+ 9210 8/ Reserved / 9211 +/ / 9212 +---------------+---------------+---------------+--------------+ 9213 16| Initiator Task Tag | 9214 +---------------+---------------+---------------+--------------+ 9215 20| Reserved | 9216 +---------------+---------------+---------------+--------------+ 9217 24| StatSN | 9218 +---------------+---------------+---------------+--------------+ 9219 28| ExpCmdSN | 9220 +---------------+---------------+---------------+--------------+ 9221 32| MaxCmdSN | 9222 +---------------+---------------+---------------+--------------+ 9223 36| Reserved | 9224 +--------------------------------------------------------------+ 9225 40| Time2Wait | Time2Retain | 9226 +---------------+---------------+---------------+--------------+ 9227 44| Reserved | 9228 +---------------+---------------+---------------+--------------+ 9229 48| Header-Digest (Optional) | 9230 +---------------+---------------+---------------+--------------+ 9232 11.15.1. Response 9234 Logout response: 9236 0 - connection or session closed successfully. 9238 1 - CID not found. 9240 2 - connection recovery is not supported. If Logout reason 9241 code was recovery and target does not support it as 9242 indicated by the ErrorRecoveryLevel. 9244 3 - cleanup failed for various reasons. 9246 11.15.2. TotalAHSLength and DataSegmentLength 9248 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9250 11.15.3. Time2Wait 9252 If the Logout response code is 0 and if the operational 9253 ErrorRecoveryLevel is 2, this is the minimum amount of time, in 9254 seconds, to wait before attempting task reassignment. If the 9255 Logout response code is 0 and if the operational 9256 ErrorRecoveryLevel is less than 2, this field is to be ignored. 9258 This field is invalid if the Logout response code is 1. 9260 If the Logout response code is 2 or 3, this field specifies the 9261 minimum time to wait before attempting a new implicit or explicit 9262 logout. 9264 If Time2Wait is 0, the reassignment or a new Logout may be 9265 attempted immediately. 9267 11.15.4. Time2Retain 9269 If the Logout response code is 0 and if the operational 9270 ErrorRecoveryLevel is 2, this is the maximum amount of time, in 9271 seconds, after the initial wait (Time2Wait), the target waits for 9272 the allegiance reassignment for any active task after which the 9273 task state is discarded. If the Logout response code is 0 and if 9274 the operational ErrorRecoveryLevel is less than 2, this field is 9275 to be ignored. 9277 This field is invalid if the Logout response code is 1. 9279 If the Logout response code is 2 or 3, this field specifies the 9280 maximum amount of time, in seconds, after the initial wait 9281 (Time2Wait), the target waits for a new implicit or explicit 9282 logout. 9284 If it is the last connection of a session, the whole session state 9285 is discarded after Time2Retain. 9287 If Time2Retain is 0, the target has already discarded the 9288 connection (and possibly the session) state along with the task 9289 states. No reassignment or Logout is required in this case. 9291 11.16. SNACK Request 9293 Byte/ 0 | 1 | 2 | 3 | 9294 / | | | 9295 | 9296 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 9297 +---------------+---------------+---------------+--------------+ 9298 0|.|.| 0x10 |1|.|.|.| Type | Reserved | 9299 +---------------+---------------+---------------+--------------+ 9300 4|TotalAHSLength | DataSegmentLength | 9301 +---------------+---------------+---------------+--------------+ 9302 8| LUN or Reserved | 9303 + + 9304 12| | 9305 +---------------+---------------+---------------+--------------+ 9306 16| Initiator Task Tag or 0xffffffff | 9307 +---------------+---------------+---------------+--------------+ 9308 20| Target Transfer Tag or SNACK Tag or 0xffffffff | 9309 +---------------+---------------+---------------+--------------+ 9310 24| Reserved | 9311 +---------------+---------------+---------------+--------------+ 9312 28| ExpStatSN | 9313 +---------------+---------------+---------------+--------------+ 9314 32/ Reserved / 9315 +/ / 9316 +---------------+---------------+---------------+--------------+ 9317 40| BegRun | 9318 +--------------------------------------------------------------+ 9319 44| RunLength | 9320 +--------------------------------------------------------------+ 9321 48| Header-Digest (Optional) | 9322 +---------------+---------------+---------------+--------------+ 9324 If the implementation supports ErrorRecoveryLevel greater than 9325 zero, it MUST support all SNACK types. 9327 The SNACK is used by the initiator to request the retransmission 9328 of numbered-responses, data, or R2T PDUs from the target. The 9329 SNACK request indicates the numbered-responses or data "runs" 9330 whose retransmission is requested by the target, where the run 9331 starts with the first StatSN, DataSN, or R2TSN whose 9332 retransmission is requested and indicates the number of Status, 9333 Data, or R2T PDUs requested including the first. 0 has special 9334 meaning when used as a starting number and length: 9336 - When used in RunLength, it means all PDUs starting with the 9337 initial. 9339 - When used in both BegRun and RunLength, it means all 9340 unacknowledged PDUs. 9342 The numbered-response(s) or R2T(s), requested by a SNACK, MUST be 9343 delivered as exact replicas of the ones that the target 9344 transmitted originally except for the fields ExpCmdSN, MaxCmdSN, 9345 and ExpDataSN, which MUST carry the current values. 9346 R2T(s)requested by SNACK MUST also carry the current value of 9347 StatSN. 9349 The numbered Data-In PDUs, requested by a Data SNACK MUST be 9350 delivered as exact replicas of the ones that the target 9351 transmitted originally except for the fields ExpCmdSN and 9352 MaxCmdSN, which MUST carry the current values and except for 9353 resegmentation (see Resegmentation). 9355 Any SNACK that requests a numbered-response, Data, or R2T that was 9356 not sent by the target or was already acknowledged by the 9357 initiator, MUST be rejected with a reason code of "Protocol 9358 error". 9360 11.16.1. Type 9362 This field encodes the SNACK function as follows: 9364 0-Data/R2T SNACK - requesting retransmission of one or more 9365 Data-In or R2T PDUs. 9367 1-Status SNACK - requesting retransmission of one or more 9368 numbered responses. 9370 2-DataACK - positively acknowledges Data-In PDUs. 9372 3-R-Data SNACK - requesting retransmission of Data-In PDUs 9373 with possible resegmentation and status tagging. 9375 All other values are reserved. 9377 Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST 9378 precede status acknowledgement for the given command. 9380 11.16.2. Data Acknowledgement 9382 If an initiator operates at ErrorRecoveryLevel 1 or higher, it 9383 MUST issue a SNACK of type DataACK after receiving a Data-In PDU 9384 with the A bit set to 1. However, if the initiator has detected 9385 holes in the input sequence, it MUST postpone issuing the SNACK of 9386 type DataACK until the holes are filled. An initiator MAY ignore 9387 the A bit if it deems that the bit is being set aggressively by 9388 the target (i.e., before the MaxBurstLength limit is 9389 reached). 9391 The DataACK is used to free resources at the target and not to 9392 request or imply data retransmission. 9394 An initiator MUST NOT request retransmission for any data it had 9395 already acknowledged. 9397 11.16.3. Resegmentation 9399 If the initiator MaxRecvDataSegmentLength changed between the 9400 original transmission and the time the initiator requests 9401 retransmission, the initiator MUST issue a R-Data SNACK (see 9402 Type). With R-Data SNACK, the initiator indicates that it discards 9403 all the unacknowledged data and expects the target to resend it. 9404 It also expects resegmentation. In this case, the retransmitted 9405 Data-In PDUs MAY be different from the ones originally sent in 9406 order to reflect changes in MaxRecvDataSegmentLength. Their DataSN 9407 starts with the BegRun of the last DataACK received by the target 9408 if any was received; otherwise it starts with 0 and is increased 9409 by 1 for each resent Data-In PDU. 9411 A target that has received a R-Data SNACK MUST return a SCSI 9412 Response that contains a copy of the SNACK Tag field from the R- 9413 Data SNACK in the SCSI Response SNACK Tag field as its last or 9414 only Response. For example, if it has already sent a response 9415 containing another value in the SNACK Tag field or had the status 9416 included in the last Data-In PDU, it must send a new SCSI Response 9417 PDU. If a target sends more than one SCSI Response PDU due to this 9418 rule, all SCSI responses must carry the same StatSN (see SNACK ). 9419 If an initiator attempts to recover a lost SCSI Response (with a 9420 Status-SNACK, see Type) when more than one response has been sent, 9421 the target will send the SCSI Response with the latest content 9422 known to the target, including the last SNACK Tag for the command. 9424 For considerations in allegiance reassignment of a task to a 9425 connection with a different MaxRecvDataSegmentLength, refer to 9426 Section 7.2.2 - "Allegiance Reassignment". 9428 11.16.4. Initiator Task Tag 9430 For Status SNACK and DataACK, the Initiator Task Tag MUST be set 9431 to the reserved value 0xffffffff. In all other cases, the 9432 Initiator Task Tag field MUST be set to the Initiator Task Tag of 9433 the referenced command. 9435 11.16.5. Target Transfer Tag or SNACK Tag 9437 For an R-Data SNACK, this field MUST contain a value that is 9438 different from 0 or 0xffffffff and is unique for the task 9439 (identified by the Initiator Task Tag). This value MUST be copied 9440 by the iSCSI target in the last or only SCSI Response PDU it 9441 issues for the command. 9443 For DataACK, the Target Transfer Tag MUST contain a copy of the 9444 Target Transfer Tag and LUN provided with the SCSI Data-In PDU 9445 with the A bit set to 1. 9447 In all other cases, the Target Transfer Tag field MUST be set to 9448 the reserved value of 0xffffffff. 9450 11.16.6. BegRun 9452 The DataSN, R2TSN, or StatSN of the first PDU whose retransmission 9453 is requested (Data/R2T and Status SNACK), or the next expected 9454 DataSN (DataACK SNACK). 9456 BegRun 0 when used in conjunction with RunLength 0 means resend 9457 all unacknowledged Data-In, R2T or Response PDUs. 9459 BegRun MUST be 0 for a R-Data SNACK. 9461 11.16.7. RunLength 9463 The number of PDUs whose retransmission is requested. 9465 RunLength 0 signals that all Data-In, R2T, or Response PDUs 9466 carrying the numbers equal to or greater than BegRun have to be 9467 resent. 9469 The RunLength MUST also be 0 for a DataACK SNACK in addition to R- 9470 Data SNACK. 9472 11.17. Reject 9474 Byte/ 0 | 1 | 2 | 3 | 9475 / | | | | 9476 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 9477 +---------------+---------------+---------------+--------------+ 9478 0|.|.| 0x3f |1| Reserved | Reason | Reserved | 9479 +---------------+---------------+---------------+--------------+ 9480 4|TotalAHSLength | DataSegmentLength | 9481 +---------------+---------------+---------------+--------------+ 9482 8/ Reserved / 9483 +/ / 9484 +---------------+---------------+---------------+--------------+ 9485 16| 0xffffffff | 9486 +---------------+---------------+---------------+--------------+ 9487 20| Reserved | 9488 +---------------+---------------+---------------+--------------+ 9489 24| StatSN | 9490 +---------------+---------------+---------------+--------------+ 9491 28| ExpCmdSN | 9492 +---------------+---------------+---------------+--------------+ 9493 32| MaxCmdSN | 9494 +---------------+---------------+---------------+--------------+ 9495 36| DataSN/R2TSN or Reserved | 9496 +---------------+---------------+---------------+--------------+ 9497 40| Reserved | 9498 +---------------+---------------+---------------+--------------+ 9499 44| Reserved | 9500 +---------------+---------------+---------------+--------------+ 9501 48| Header-Digest (Optional) | 9502 +---------------+---------------+---------------+--------------+ 9503 xx/ Complete Header of Bad PDU / 9504 +/ / 9505 +---------------+---------------+---------------+--------------+ 9506 yy/Vendor specific data (if any) / 9507 / / 9508 +---------------+---------------+---------------+--------------+ 9509 zz| Data-Digest (Optional) | 9510 +---------------+---------------+---------------+--------------+ 9512 Reject is used to indicate an iSCSI error condition (protocol, 9513 unsupported option, etc.). 9515 11.17.1. Reason 9517 The reject Reason is coded as follows: 9519 +------+----------------------------------------+----------------+ 9520 | Code | Explanation |Can the original| 9521 | (hex)| |PDU be re-sent? | 9522 +------+----------------------------------------+----------------+ 9523 | 0x01 | Reserved | no | 9524 | | | | 9525 | 0x02 | Data (payload) Digest Error | yes (Note 1) | 9526 | | | | 9527 | 0x03 | SNACK Reject | yes | 9528 | | | | 9529 | 0x04 | Protocol Error (e.g., SNACK request for| no | 9530 | | a status that was already acknowledged)| | 9531 | | | | 9532 | 0x05 | Command not supported | no | 9533 | | | | 9534 | 0x06 | Immediate Command Reject - too many | yes | 9535 | | immediate commands | | 9536 | | | | 9537 | 0x07 | Task in progress | no | 9538 | | | | 9539 | 0x08 | Invalid Data ACK | no | 9540 | | | | 9541 | 0x09 | Invalid PDU field | no (Note 2) | 9542 | | | | 9543 | 0x0a | Long Operation Reject - Can't generate | yes | 9544 | | Target Transfer Tag - out of resources | | 9545 | | | | 9546 | 0x0c | Waiting for Logout | no | 9547 +------+----------------------------------------+----------------+ 9549 Note 1: For iSCSI, Data-Out PDU retransmission is only done if the 9550 target requests retransmission with a recovery R2T. However, if 9551 this is the data digest error on immediate data, the initiator may 9552 choose to retransmit the whole PDU including the immediate data. 9554 Note 2: A target should use this reason code for all invalid 9555 values of PDU fields that are meant to describe a task, a 9556 response, or a data transfer. Some examples are invalid TTT/ITT, 9557 buffer offset, LUN qualifying a TTT, and an invalid sequence 9558 number in a SNACK. 9560 Note 3: Reason code 0x0b ("Negotiation reset") defined in 9561 [RFC3720] is deprecated and MUST NOT be used by implementations. 9562 An implementation receiving reason code 0x0b MUST treat it as a 9563 negotiation failure that terminates the Login Phase and the TCP 9564 connection, as specified in Section 7.12. 9566 All other values for Reason are reserved. 9568 In all the cases in which a pre-instantiated SCSI task is 9569 terminated because of the reject, the target MUST issue a proper 9570 SCSI command response with CHECK CONDITION as described in Section 9571 11.4.3. In these cases in which a status for the SCSI task was 9572 already sent before the reject, no additional status is required. 9573 If the error is detected while data from the initiator is still 9574 expected (i.e., the command PDU did not contain all the data and 9575 the target has not received a Data-out PDU with the Final bit set 9576 to 1 for the unsolicited data, if any, and all outstanding R2Ts, 9577 if any), the target MUST wait until it receives the last expected 9578 Data-out PDUs with the F bit set to 1 before sending the Response 9579 PDU. 9581 For additional usage semantics of Reject PDU, see Section 7.3 - 9582 "Usage Of Reject PDU in Recovery". 9584 11.17.2. DataSN/R2TSN 9586 This field is only valid if the rejected PDU is a Data/R2T SNACK 9587 and the Reject reason code is "Protocol error" (see SNACK). The 9588 DataSN/R2TSN is the next Data/R2T sequence number that the target 9589 would send for the task, if any. 9591 11.17.3. StatSN, ExpCmdSN and MaxCmdSN 9593 These fields carry their usual values and are not related to the 9594 rejected command. StatSN is advanced after a Reject. 9596 11.17.4. Complete Header of Bad PDU 9598 The target returns the header (not including digest) of the PDU in 9599 error as the data of the response. 9601 11.18. NOP-Out 9603 Byte/ 0 | 1 | 2 | 3 | 9604 / | | | | 9605 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 9606 +---------------+---------------+---------------+--------------+ 9607 0|.|I| 0x00 |1| Reserved | 9608 +---------------+---------------+---------------+--------------+ 9609 4|TotalAHSLength | DataSegmentLength | 9610 +---------------+---------------+---------------+--------------+ 9611 8| LUN or Reserved | 9612 + + 9613 12| | 9614 +---------------+---------------+---------------+--------------+ 9615 16| Initiator Task Tag or 0xffffffff | 9616 +---------------+---------------+---------------+--------------+ 9617 20| Target Transfer Tag or 0xffffffff | 9618 +---------------+---------------+---------------+--------------+ 9619 24| CmdSN | 9620 +---------------+---------------+---------------+--------------+ 9621 28| ExpStatSN | 9622 +---------------+---------------+---------------+--------------+ 9623 32/ Reserved / 9624 +/ / 9625 +---------------+---------------+---------------+--------------+ 9626 48| Header-Digest (Optional) | 9627 +---------------+---------------+---------------+--------------+ 9628 / DataSegment - Ping Data (optional) / 9629 +/ / 9630 +---------------+---------------+---------------+--------------+ 9631 | Data-Digest (Optional) | 9632 +---------------+---------------+---------------+--------------+ 9634 A NOP-Out may be used by an initiator as a "ping request" to 9635 verify that a connection/session is still active and all its 9637 components are operational. The NOP-In response is the "ping 9638 echo". 9640 A NOP-Out is also sent by an initiator in response to a NOP-In. 9642 A NOP-Out may also be used to confirm a changed ExpStatSN if 9643 another PDU will not be available for a long time. 9645 Upon receipt of a NOP-In with the Target Transfer Tag set to a 9646 valid value (not the reserved 0xffffffff), the initiator MUST 9647 respond with a NOP-Out. In this case, the NOP-Out Target Transfer 9648 Tag MUST contain a copy of the NOP-In Target Transfer Tag. 9650 11.18.1. Initiator Task Tag 9652 The NOP-Out MUST have the Initiator Task Tag set to a valid value 9653 only if a response in the form of NOP-In is requested (i.e., the 9654 NOP-Out is used as a ping request). Otherwise, the Initiator Task 9655 Tag MUST be set to 0xffffffff. 9657 When a target receives the NOP-Out with a valid Initiator Task 9658 Tag, it MUST respond with a Nop-In Response (see Login and Full 9659 Feature Phase Negotiation). 9661 If the Initiator Task Tag contains 0xffffffff, the I bit MUST be 9662 set to 1 and the CmdSN is not advanced after this PDU is sent. 9664 11.18.2. Target Transfer Tag 9666 A target assigned identifier for the operation. 9668 The NOP-Out MUST only have the Target Transfer Tag set if it is 9669 issued in response to a NOP-In with a valid Target Transfer Tag. 9670 In this case, it copies the Target Transfer Tag from the NOP-In 9671 PDU. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff. 9673 When the Target Transfer Tag is set to a value other than 9674 0xffffffff, the LUN field MUST also be copied from the NOP-In. 9676 11.18.3. Ping Data 9678 Ping data are reflected in the NOP-In Response. The length of the 9679 reflected data are limited to MaxRecvDataSegmentLength. The length 9680 of ping data are indicated by the DataSegmentLength. 0 is a valid 9681 value for the DataSegmentLength and indicates the absence of ping 9682 data. 9684 11.19. NOP-In 9686 Byte/ 0 | 1 | 2 | 3 | 9687 / | | | | 9688 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 67| 9689 +---------------+---------------+---------------+--------------+ 9690 0|.|.| 0x20 |1| Reserved | 9691 +---------------+---------------+---------------+--------------+ 9692 4|TotalAHSLength | DataSegmentLength | 9693 +---------------+---------------+---------------+--------------+ 9694 8| LUN or Reserved | 9695 + + 9696 12| | 9697 +---------------+---------------+---------------+--------------+ 9698 16| Initiator Task Tag or 0xffffffff | 9699 +---------------+---------------+---------------+--------------+ 9700 20| Target Transfer Tag or 0xffffffff | 9701 +---------------+---------------+---------------+--------------+ 9702 24| StatSN | 9703 +---------------+---------------+---------------+--------------+ 9704 28| ExpCmdSN | 9705 +---------------+---------------+---------------+--------------+ 9706 32| MaxCmdSN | 9707 +---------------+---------------+---------------+--------------+ 9708 36/ Reserved / 9709 +/ / 9710 +---------------+---------------+---------------+--------------+ 9711 48| Header-Digest (Optional) | 9712 +---------------+---------------+---------------+--------------+ 9713 / DataSegment - Return Ping Data / 9714 +/ / 9715 +---------------+---------------+---------------+--------------+ 9716 | Data-Digest (Optional) | 9717 +---------------+---------------+---------------+--------------+ 9719 NOP-In is either sent by a target as a response to a NOP-Out, as a 9720 "ping" to an initiator, or as a means to carry a changed ExpCmdSN 9721 and/or MaxCmdSN if another PDU will not be available for a long 9722 time (as determined by the target). 9724 When a target receives the NOP-Out with a valid Initiator Task Tag 9725 (not the reserved value 0xffffffff), it MUST respond with a NOP-In 9726 with the same Initiator Task Tag that was provided in the NOP-Out 9727 request. It MUST also duplicate up to the first 9728 MaxRecvDataSegmentLength bytes of the initiator provided Ping 9729 Data. For such a response, the Target Transfer Tag MUST be 9730 0xffffffff. 9732 Otherwise, when a target sends a NOP-In that is not a response to 9733 a Nop-Out received from the initiator, the Initiator Task Tag MUST 9734 be set to 0xffffffff and the Data Segment MUST NOT contain any 9735 data (DataSegmentLength MUST be 0). 9737 11.19.1. Target Transfer Tag 9739 If the target is responding to a NOP-Out, this is set to the 9740 reserved value 0xffffffff. 9742 If the target is sending a NOP-In as a Ping (intending to receive 9743 a corresponding NOP-Out), this field is set to a valid value (not 9744 the reserved 0xffffffff). 9746 If the target is initiating a NOP-In without wanting to receive a 9747 corresponding NOP-Out, this field MUST hold the reserved value of 9748 0xffffffff. 9750 11.19.2. StatSN 9752 The StatSN field will always contain the next StatSN. However, 9753 when the Initiator Task Tag is set to 0xffffffff StatSN for the 9754 connection is not advanced after this PDU is sent. 9756 11.19.3. LUN 9758 A LUN MUST be set to a correct value when the Target Transfer Tag 9759 is valid (not the reserved value 0xffffffff). 9761 12. iSCSI Security Text Keys and Authentication Methods 9763 Only the following keys are used during the SecurityNegotiation 9764 stage of the Login Phase: 9766 SessionType 9768 InitiatorName 9770 TargetName 9772 TargetAddress 9774 InitiatorAlias 9776 TargetAlias 9778 TargetPortalGroupTag 9780 AuthMethod and the keys used by the authentication methods 9781 specified under Section 12.1 along with all of their 9782 associated keys as well as Vendor Specific Authentication 9783 Methods. 9785 Other keys MUST NOT be used. 9787 SessionType, InitiatorName, TargetName, InitiatorAlias, 9788 TargetAlias, and TargetPortalGroupTag are described in Section 13 9789 as they can be used also in the OperationalNegotiation stage. 9791 All security keys have connection-wide applicability. 9793 12.1. AuthMethod 9795 Use: During Login - Security Negotiation 9796 Senders: Initiator and Target 9797 Scope: connection 9799 AuthMethod = 9801 The main item of security negotiation is the authentication method 9802 (AuthMethod). 9804 The authentication methods that can be used (appear in the list- 9805 of-values) are either those listed in the following table or are 9806 vendor-unique methods: 9808 +------------------------------------------------------------+ 9809 | Name | Description | 9810 +------------------------------------------------------------+ 9811 | KRB5 | Kerberos V5 - defined in [RFC4120] | 9812 +------------------------------------------------------------+ 9813 | SRP | Secure Remote Password | 9814 | | defined in [RFC2945] | 9815 +------------------------------------------------------------+ 9816 | CHAP | Challenge Handshake Authentication Protocol| 9817 | | defined in [RFC1994] | 9818 +------------------------------------------------------------+ 9819 | None | No authentication | 9820 +------------------------------------------------------------+ 9822 The AuthMethod selection is followed by an "authentication 9823 exchange" specific to the authentication method selected. 9825 The authentication method proposal may be made by either the 9826 initiator or the target. However the initiator MUST make the first 9827 step specific to the selected authentication method as soon as it 9828 is selected. It follows that if the target makes the 9829 authentication method proposal the initiator sends the first 9830 key(s) of the exchange together with its authentication method 9831 selection. 9833 The authentication exchange authenticates the initiator to the 9834 target, and optionally, the target to the initiator. 9835 Authentication is OPTIONAL to use but MUST be supported by the 9836 target and initiator. 9838 The initiator and target MUST implement CHAP. All other 9839 authentication methods are OPTIONAL. 9841 Private or public extension algorithms MAY also be negotiated for 9842 authentication methods. Whenever a private or public extension 9843 algorithm is part of the default offer (the offer made in absence 9844 of explicit administrative action) the implementer MUST ensure 9845 that CHAP is listed as an alternative in the default offer and 9846 "None" is not part of the default offer. 9848 Extension authentication methods MUST be named using one of the 9849 following two formats: 9851 i) Z-reversed.vendor.dns_name.do_something= 9852 ii) Z<#>= 9854 Authentication methods named using the Z- format are used as 9855 private extensions. Authentication methods named using the Z# 9856 format are used as public extensions that must be registered with 9857 IANA and MUST be described by a standards track RFC, an 9858 experimental RFC, or an informational RFC. 9860 For all of the public or private extension authentication methods, 9861 the method specific keys MUST conform to the format specified in 9862 Section 6.1- "Text Format" for standard-label. 9864 To identify the vendor for private extension authentication 9865 methods, we suggest you use the reversed DNS-name as a prefix to 9866 the proper digest names. 9868 The part of digest-name following Z- and Z# MUST conform to the 9869 format for standard-label specified in Section 6.1 - "Text 9870 Format". 9872 Support for public or private extension authentication methods is 9873 OPTIONAL. 9875 The following subsections define the specific exchanges for each 9876 of the standardized authentication methods. As mentioned earlier 9877 the first step is always done by the initiator. 9879 12.1.1. Kerberos 9881 For KRB5 (Kerberos V5) [RFC4120] and [RFC1964], the initiator MUST 9882 use: 9884 KRB_AP_REQ= 9886 where KRB_AP_REQ is the client message as defined in [RFC4120]. 9888 The default principal name assumed by an iSCSI initiator or target 9889 (prior to any administrative configuration action) MUST be the 9890 iSCSI Initiator Name or iSCSI Target Name respectively, prefixed 9891 by the string "iscsi/". 9893 If the initiator authentication fails, the target MUST respond 9894 with a Login reject with "Authentication Failure" status. 9895 Otherwise, if the initiator has selected the mutual authentication 9896 option (by setting MUTUAL-REQUIRED in the ap-options field of the 9897 KRB_AP_REQ), the target MUST reply with: 9899 KRB_AP_REP= 9901 where KRB_AP_REP is the server's response message as defined in 9902 [RFC4120]. 9904 If mutual authentication was selected and target authentication 9905 fails, the initiator MUST close the connection. 9907 KRB_AP_REQ and KRB_AP_REP are binary-values and their binary 9908 length (not the length of the character string that represents 9909 them in encoded form) MUST NOT exceed 65536 bytes. 9911 12.1.2. Secure Remote Password (SRP) 9913 For SRP [RFC2945], the initiator MUST use: 9915 SRP_U= TargetAuth=Yes /* or TargetAuth=No */ 9917 The target MUST answer with a Login reject with the "Authorization 9918 Failure" status or reply with: 9920 SRP_GROUP= SRP_s= 9922 Where G1,G2... are proposed groups, in order of preference. 9924 The initiator MUST either close the connection or continue with: 9926 SRP_A= SRP_GROUP= 9928 Where G is one of G1,G2... that were proposed by the target. 9930 The target MUST answer with a Login reject with the 9931 "Authentication Failure" status or reply with: 9933 SRP_B= 9935 The initiator MUST close the connection or continue with: 9937 SRP_M= 9939 If the initiator authentication fails, the target MUST answer with 9940 a Login reject with "Authentication Failure" status. Otherwise, if 9941 the initiator sent TargetAuth=Yes in the first message (requiring 9942 target authentication), the target MUST reply with: 9944 SRP_HM= 9946 If the target authentication fails, the initiator MUST close the 9947 connection. 9949 Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] 9950 (using the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn 9951 stands for G1,G2...) are identifiers of SRP groups specified in 9952 [RFC3723]. G, Gn, and U are text strings, s,A,B,M, and H(A | M | 9953 K) are binary-values. The length of s,A,B,M and H(A | M | K) in 9954 binary form (not the length of the character string that 9955 represents them in encoded form) MUST NOT exceed 1024 bytes. 9957 For the SRP_GROUP, all the groups specified in [RFC3723] up to 9958 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be 9959 supported by initiators and targets. To guarantee 9960 interoperability, targets MUST always offer "SRP-1536" as one of 9961 the proposed groups. 9963 12.1.3. Challenge Handshake Authentication Protocol (CHAP) 9965 For CHAP [RFC1994], the initiator MUST use: 9967 CHAP_A= 9969 Where A1,A2... are proposed algorithms, in order of preference. 9971 The target MUST answer with a Login reject with the 9972 "Authentication Failure" status or reply with: 9974 CHAP_A= CHAP_I= CHAP_C= 9976 Where A is one of A1,A2... that were proposed by the initiator. 9978 The initiator MUST continue with: 9980 CHAP_N= CHAP_R= 9982 or, if it requires target authentication, with: 9984 CHAP_N= CHAP_R= CHAP_I= CHAP_C= 9986 If the initiator authentication fails, the target MUST answer with 9987 a Login reject with "Authentication Failure" status. Otherwise, if 9988 the initiator required target authentication, the target MUST 9989 either answer with a Login reject with "Authentication Failure" or 9990 reply with: 9992 CHAP_N= CHAP_R= 9994 If target authentication fails, the initiator MUST close the 9995 connection. 9997 Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, 9998 Algorithm, Identifier, Challenge, and Response as defined in 9999 [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C 10000 and R are binary-values and their binary length (not the length of 10001 the character string that represents them in encoded form) MUST 10002 NOT exceed 1024 bytes. 10004 For the Algorithm, as stated in [RFC1994], one value is required 10005 to be implemented: 10007 5 (CHAP with MD5) 10009 To guarantee interoperability, initiators MUST always offer it as 10010 one of the proposed algorithms. 10012 13. Login/Text Operational Text Keys 10014 Some session specific parameters MUST only be carried on the 10015 leading connection and cannot be changed after the leading 10016 connection login (e.g., MaxConnections, the maximum number of 10017 connections). This holds for a single connection session with 10018 regard to connection restart. The keys that fall into this 10019 category have the use: LO (Leading Only). 10021 Keys that can only be used during login have the use: IO 10022 (initialize only), while those that can be used in both the Login 10023 Phase and Full Feature Phase have the use: ALL. 10025 Keys that can only be used during Full Feature Phase use FFPO 10026 (Full Feature Phase only). 10028 Keys marked as Any-Stage may also appear in the 10029 SecurityNegotiation stage while all other keys described in this 10030 chapter are operational keys. 10032 Keys that do not require an answer are marked as Declarative. 10034 Key scope is indicated as session-wide (SW) or connection-only 10035 (CO). 10037 Result function, wherever mentioned, states the function that can 10038 be applied to check the validity of the responder selection. 10039 Minimum means that the selected value cannot exceed the offered 10040 value. Maximum means that the selected value cannot be lower than 10041 the offered value. AND means that the selected value must be a 10042 possible result of a Boolean "and" function with an arbitrary 10043 Boolean value (e.g., if the offered value is No the selected value 10044 must be No). OR means that the selected value must be a possible 10045 result of a Boolean "or" function with an arbitrary Boolean value 10046 (e.g., if the offered value is Yes the selected value must be 10047 Yes). 10049 13.1. HeaderDigest and DataDigest 10051 Use: IO 10052 Senders: Initiator and Target 10053 Scope: CO 10054 HeaderDigest = 10055 DataDigest = 10057 Default is None for both HeaderDigest and DataDigest. 10059 Digests enable the checking of end-to-end, non-cryptographic data 10060 integrity beyond the integrity checks provided by the link layers 10061 and the covering of the whole communication path including all 10062 elements that may change the network level PDUs such as routers, 10063 switches, and proxies. 10065 The following table lists cyclic integrity checksums that can be 10066 negotiated for the digests and that MUST be implemented by every 10067 iSCSI initiator and target. These digest options only have error 10068 detection significance. 10070 +---------------------------------------------+ 10071 | Name | Description | Generator | 10072 +---------------------------------------------+ 10073 | CRC32C | 32 bit CRC |0x11edc6f41| 10074 +---------------------------------------------+ 10075 | None | no digest | 10076 +---------------------------------------------+ 10078 The generator polynomial for this digest is given in hex-notation 10079 (e.g., 0x3b stands for 0011 1011 and the polynomial is 10080 x**5+X**4+x**3+x+1). 10082 When the Initiator and Target agree on a digest, this digest MUST 10083 be used for every PDU in Full Feature Phase. 10085 Padding bytes, when present in a segment covered by a CRC, SHOULD 10086 be set to 0 and are included in the CRC. 10088 The CRC MUST be calculated by a method that produces the same 10089 results as the following process: 10091 - The PDU bits are considered as the coefficients of a 10092 polynomial M(x) of degree n-1; bit 7 of the lowest numbered 10093 byte is considered the most significant bit (x^n-1), 10095 followed by bit 6 of the lowest numbered byte through bit 0 10096 of the highest numbered byte (x^0). 10098 - The most significant 32 bits are complemented. 10100 - The polynomial is multiplied by x^32 then divided by G(x). 10101 The generator polynomial produces a remainder R(x) of degree 10102 <= 31. 10104 - The coefficients of R(x) are considered a 32 bit sequence. 10106 - The bit sequence is complemented and the result is the CRC. 10108 - The CRC bits are mapped into the digest word. The x^31 10109 coefficient in bit 7 of the lowest numbered byte of the 10110 digest continuing through to the byte up to the x^24 10111 coefficient in bit 0 of the lowest numbered byte, continuing 10112 with the x^23 coefficient in bit 7 of next byte through x^0 10113 in bit 0 of the highest numbered byte. 10115 - Computing the CRC over any segment (data or header) extended 10116 to include the CRC built using the generator 0x11edc6f41 10117 will always get the value 0x1c2d19ed as its final remainder 10118 (R(x)). This value is given here in its polynomial form 10119 (i.e., not mapped as the digest word). 10121 For a discussion about selection criteria for the CRC, see 10122 [RFC3385]. For a detailed analysis of the iSCSI polynomial, see 10123 [Castagnoli93]. 10125 Private or public extension algorithms MAY also be negotiated for 10126 digests. Whenever a private or public digest extension algorithm 10127 is part of the default offer (the offer made in absence of 10128 explicit administrative action) the implementer MUST ensure that 10129 CRC32C is listed as an alternative in the default offer and "None" 10130 is not part of the default offer. 10132 Extension digest algorithms MUST be named using one of the 10133 following two formats: 10135 iii) Y-reversed.vendor.dns_name.do_something= 10136 iv) Y<#>= 10138 Digests named using the Y- format are used for private purposes 10139 (unregistered). Digests named using the Y# format (public 10140 extension) must be registered with IANA and MUST be described by a 10141 standards track RFC, an experimental RFC, or an informational RFC. 10143 For private extension digests, to identify the vendor, we suggest 10144 you use the reversed DNS-name as a prefix to the proper digest 10145 names. 10147 The part of digest-name following Y- and Y# MUST conform to the 10148 format for standard-label specified in Section 6.1. 10150 Support for public or private extension digests is OPTIONAL. 10152 13.2. MaxConnections 10154 Use: LO 10155 Senders: Initiator and Target 10156 Scope: SW 10157 Irrelevant when: SessionType=Discovery 10159 MaxConnections= 10161 Default is 1. 10162 Result function is Minimum. 10164 Initiator and target negotiate the maximum number of connections 10165 requested/acceptable. 10167 13.3. SendTargets 10169 Use: FFPO 10170 Senders: Initiator 10171 Scope: SW 10173 For a complete description, see Appendix D. - "SendTargets 10174 Operation". 10176 13.4. TargetName 10178 Use: IO by initiator, FFPO by target - only as response to a 10179 SendTargets, Declarative, Any-Stage 10180 Senders: Initiator and Target 10181 Scope: SW 10183 TargetName= 10185 Examples: 10187 TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 10189 TargetName=eui.020000023B040506 10191 TargetName=naa.62004567BA64678D0123456789ABCDEF 10193 The initiator of the TCP connection MUST provide this key to the 10194 remote endpoint in the first login request if the initiator is not 10195 establishing a discovery session. The iSCSI Target Name specifies 10196 the worldwide unique name of the target. 10198 The TargetName key may also be returned by the "SendTargets" text 10199 request (which is its only use when issued by a target). 10201 TargetName MUST NOT be redeclared within the login phase. 10203 13.5. InitiatorName 10205 Use: IO, Declarative, Any-Stage 10206 Senders: Initiator 10207 Scope: SW 10209 InitiatorName= 10211 Examples: 10213 InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345 10215 InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90 10216 InitiatorName=naa.52004567BA64678D 10218 The initiator of the TCP connection MUST provide this key to the 10219 remote endpoint at the first Login of the Login Phase for every 10220 connection. The InitiatorName key enables the initiator to 10221 identify itself to the remote endpoint. 10223 InitiatorName MUST NOT be redeclared within the login phase. 10225 13.6. TargetAlias 10227 Use: ALL, Declarative, Any-Stage 10228 Senders: Target 10229 Scope: SW 10231 TargetAlias= 10233 Examples: 10235 TargetAlias=Bob-s Disk 10237 TargetAlias=Database Server 1 Log Disk 10239 TargetAlias=Web Server 3 Disk 20 10241 If a target has been configured with a human-readable name or 10242 description, this name SHOULD be communicated to the initiator 10243 during a Login Response PDU if SessionType=Normal (see 13.21). 10244 This string is not used as an identifier, nor is it meant to be 10245 used for authentication or authorization decisions. It can be 10246 displayed by the initiator's user interface in a list of targets 10247 to which it is connected. 10249 13.7. InitiatorAlias 10251 Use: ALL, Declarative, Any-Stage 10252 Senders: Initiator 10253 Scope: SW 10255 InitiatorAlias= 10256 Examples: 10258 InitiatorAlias=Web Server 4 10260 InitiatorAlias=spyalley.nsa.gov 10262 InitiatorAlias=Exchange Server 10264 If an initiator has been configured with a human-readable name or 10265 description, it SHOULD be communicated to the target during a 10266 Login Request PDU. If not, the host name can be used instead. This 10267 string is not used as an identifier, nor is meant to be used for 10268 authentication or authorization decisions. It can be displayed by 10269 the target's user interface in a list of initiators to which it is 10270 connected. 10272 13.8. TargetAddress 10274 Use: ALL, Declarative, Any-Stage 10275 Senders: Target 10276 Scope: SW 10278 TargetAddress=domainname[:port][,portal-group-tag] 10280 The domainname can be specified as either a DNS host name, a 10281 dotted-decimal IPv4 address, or a bracketed IPv6 address as 10282 specified in [RFC3986]. 10284 If the TCP port is not specified, it is assumed to be the IANA- 10285 assigned default port for iSCSI (see Section 14 -"IANA 10286 Considerations"). 10288 If the TargetAddress is returned as the result of a redirect 10289 status in a login response, the comma and portal group tag MUST be 10290 omitted. 10292 If the TargetAddress is returned within a SendTargets response, 10293 the portal group tag MUST be included. 10295 Examples: 10297 TargetAddress=10.0.0.1:5003,1 10299 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 10301 TargetAddress=[1080::8:800:200C:417A]:5003,1 10303 TargetAddress=computingcenter.example.com,23 10305 Use of the portal-group-tag is described in Appendix D. - 10306 "SendTargets Operation". The formats for the port and portal- 10307 group-tag are the same as the one specified in 10308 TargetPortalGroupTag. 10310 13.9. TargetPortalGroupTag 10312 Use: IO by target, Declarative, Any-Stage 10313 Senders: Target 10314 Scope: SW 10316 TargetPortalGroupTag=<16-bit-binary-value> 10318 Examples: 10319 TargetPortalGroupTag=1 10321 The target portal group tag is a 16-bit binary-value that uniquely 10322 identifies a portal group within an iSCSI target node. This key 10323 carries the value of the tag of the portal group that is servicing 10324 the Login request. The iSCSI target returns this key to the 10325 initiator in the Login Response PDU to the first Login Request PDU 10326 that has the C bit set to 0 when TargetName is given by the 10327 initiator. 10329 [SAM2] and [SAM3] specifications note in their informative text 10330 that TPGT value should be non-zero, note that it is incorrect. A 10331 zero value is allowed as a legal value for TPGT. This discrepancy 10332 currently stands corrected in [SAM4]. 10334 For the complete usage expectations of this key see Section 6.3. 10336 13.10. InitialR2T 10338 Use: LO 10339 Senders: Initiator and Target 10340 Scope: SW 10341 Irrelevant when: SessionType=Discovery 10343 InitialR2T= 10345 Examples: 10347 I->InitialR2T=No 10349 T->InitialR2T=No 10351 Default is Yes. 10352 Result function is OR. 10354 The InitialR2T key is used to turn off the default use of R2T for 10355 unidirectional and the output part of bidirectional commands, thus 10356 allowing an initiator to start sending data to a target as if it 10357 has received an initial R2T with Buffer Offset=Immediate Data 10358 Length and Desired Data Transfer Length=(min(FirstBurstLength, 10359 Expected Data Transfer Length) - Received Immediate Data Length). 10361 The default action is that R2T is required, unless both the 10362 initiator and the target send this key-pair attribute specifying 10363 InitialR2T=No. Only the first outgoing data burst (immediate data 10364 and/or separate PDUs) can be sent unsolicited (i.e., not requiring 10365 an explicit R2T). 10367 13.11. ImmediateData 10369 Use: LO 10370 Senders: Initiator and Target 10371 Scope: SW 10372 Irrelevant when: SessionType=Discovery 10374 ImmediateData= 10376 Default is Yes. 10378 Result function is AND. 10380 The initiator and target negotiate support for immediate data. To 10381 turn immediate data off, the initiator or target must state its 10382 desire to do so. ImmediateData can be turned on if both the 10383 initiator and target have ImmediateData=Yes. 10385 If ImmediateData is set to Yes and InitialR2T is set to Yes 10386 (default), then only immediate data are accepted in the first 10387 burst. 10389 If ImmediateData is set to No and InitialR2T is set to Yes, then 10390 the initiator MUST NOT send unsolicited data and the target MUST 10391 reject unsolicited data with the corresponding response code. 10393 If ImmediateData is set to No and InitialR2T is set to No, then 10394 the initiator MUST NOT send unsolicited immediate data, but MAY 10395 send one unsolicited burst of Data-OUT PDUs. 10397 If ImmediateData is set to Yes and InitialR2T is set to No, then 10398 the initiator MAY send unsolicited immediate data and/or one 10399 unsolicited burst of Data-OUT PDUs. 10401 The following table is a summary of unsolicited data options: 10403 +----------+-------------+------------------+--------------+ 10404 |InitialR2T|ImmediateData| Unsolicited |Immediate Data| 10405 | | | Data Out PDUs | | 10406 +----------+-------------+------------------+--------------+ 10407 | No | No | Yes | No | 10408 +----------+-------------+------------------+--------------+ 10409 | No | Yes | Yes | Yes | 10410 +----------+-------------+------------------+--------------+ 10411 | Yes | No | No | No | 10412 +----------+-------------+------------------+--------------+ 10413 | Yes | Yes | No | Yes | 10414 +----------+-------------+------------------+--------------+ 10416 13.12. MaxRecvDataSegmentLength 10418 Use: ALL, Declarative 10419 Senders: Initiator and Target 10420 Scope: CO 10422 MaxRecvDataSegmentLength= 10424 Default is 8192 bytes. 10426 The initiator or target declares the maximum data segment length 10427 in bytes it can receive in an iSCSI PDU. 10429 The transmitter (initiator or target) is required to send PDUs 10430 with a data segment that does not exceed MaxRecvDataSegmentLength 10431 of the receiver. 10433 A target receiver is additionally limited by MaxBurstLength for 10434 solicited data and FirstBurstLength for unsolicited data. An 10435 initiator MUST NOT send solicited PDUs exceeding MaxBurstLength 10436 nor unsolicited PDUs exceeding FirstBurstLength (or 10437 FirstBurstLength-Immediate Data Length if immediate data were 10438 sent). 10440 13.13. MaxBurstLength 10442 Use: LO 10443 Senders: Initiator and Target 10444 Scope: SW 10445 Irrelevant when: SessionType=Discovery 10447 MaxBurstLength= 10449 Default is 262144 (256 Kbytes). 10450 Result function is Minimum. 10452 The initiator and target negotiate maximum SCSI data payload in 10453 bytes in a Data-In or a solicited Data-Out iSCSI sequence. A 10454 sequence consists of one or more consecutive Data-In or Data-Out 10455 PDUs that end with a Data-In or Data-Out PDU with the F bit set to 10456 one. 10458 13.14. FirstBurstLength 10460 Use: LO 10461 Senders: Initiator and Target 10462 Scope: SW 10463 Irrelevant when: SessionType=Discovery 10464 Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) 10466 FirstBurstLength= 10468 Default is 65536 (64 Kbytes). 10469 Result function is Minimum. 10471 The initiator and target negotiate the maximum amount in bytes of 10472 unsolicited data an iSCSI initiator may send to the target during 10473 the execution of a single SCSI command. This covers the immediate 10474 data (if any) and the sequence of unsolicited Data-Out PDUs (if 10475 any) that follow the command. 10477 FirstBurstLength MUST NOT exceed MaxBurstLength. 10479 13.15. DefaultTime2Wait 10481 Use: LO 10482 Senders: Initiator and Target 10483 Scope: SW 10485 DefaultTime2Wait= 10487 Default is 2. 10488 Result function is Maximum. 10490 The initiator and target negotiate the minimum time, in seconds, 10491 to wait before attempting an explicit/implicit logout or an active 10492 task reassignment after an unexpected connection termination or a 10493 connection reset. 10495 A value of 0 indicates that logout or active task reassignment can 10496 be attempted immediately. 10498 13.16. DefaultTime2Retain 10500 Use: LO 10501 Senders: Initiator and Target 10502 Scope: SW 10503 DefaultTime2Retain= 10505 Default is 20. 10506 Result function is Minimum. 10508 The initiator and target negotiate the maximum time, in seconds 10509 after an initial wait (Time2Wait), before which an active task 10510 reassignment is still possible after an unexpected connection 10511 termination or a connection reset. 10513 This value is also the session state timeout if the connection in 10514 question is the last LOGGED_IN connection in the session. 10516 A value of 0 indicates that connection/task state is immediately 10517 discarded by the target. 10519 13.17. MaxOutstandingR2T 10521 Use: LO 10522 Senders: Initiator and Target 10523 Scope: SW 10525 MaxOutstandingR2T= 10526 Irrelevant when: SessionType=Discovery 10528 Default is 1. 10529 Result function is Minimum. 10531 Initiator and target negotiate the maximum number of outstanding 10532 R2Ts per task, excluding any implied initial R2T that might be 10533 part of that task. An R2T is considered outstanding until the last 10534 data PDU (with the F bit set to 1) is transferred, or a sequence 10535 reception timeout (Section 7.1.4.1) is encountered for that data 10536 sequence. 10538 13.18. DataPDUInOrder 10540 Use: LO 10541 Senders: Initiator and Target 10542 Scope: SW 10543 Irrelevant when: SessionType=Discovery 10544 DataPDUInOrder= 10546 Default is Yes. 10547 Result function is OR. 10549 No is used by iSCSI to indicate that the data PDUs within 10550 sequences can be in any order. Yes is used to indicate that data 10551 PDUs within sequences have to be at continuously increasing 10552 addresses and overlays are forbidden. 10554 13.19. DataSequenceInOrder 10556 Use: LO 10557 Senders: Initiator and Target 10558 Scope: SW 10559 Irrelevant when: SessionType=Discovery 10561 DataSequenceInOrder= 10563 Default is Yes. 10564 Result function is OR. 10566 A Data Sequence is a sequence of Data-In or Data-Out PDUs that end 10567 with a Data-In or Data-Out PDU with the F bit set to one. A Data- 10568 out sequence is sent either unsolicited or in response to an R2T. 10569 Sequences cover an offset-range. 10571 If DataSequenceInOrder is set to No, Data PDU sequences may be 10572 transferred in any order. 10574 If DataSequenceInOrder is set to Yes, Data Sequences MUST be 10575 transferred using continuously non-decreasing sequence offsets 10576 (R2T buffer offset for writes, or the smallest SCSI Data-In buffer 10577 offset within a read data sequence). 10579 If DataSequenceInOrder is set to Yes, a target may retry at most 10580 the last R2T, and an initiator may at most request retransmission 10581 for the last read data sequence. For this reason, if 10582 ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes 10583 then MaxOustandingR2T MUST be set to 1. 10585 13.20. ErrorRecoveryLevel 10587 Use: LO 10588 Senders: Initiator and Target 10589 Scope: SW 10591 ErrorRecoveryLevel= 10593 Default is 0. 10594 Result function is Minimum. 10596 The initiator and target negotiate the recovery level supported. 10598 Recovery levels represent a combination of recovery capabilities. 10599 Each recovery level includes all the capabilities of the lower 10600 recovery levels and adds some new ones to them. 10602 In the description of recovery mechanisms, certain recovery 10603 classes are specified. Section 7.1.5 describes the mapping between 10604 the classes and the levels. 10606 13.21. SessionType 10608 Use: LO, Declarative, Any-Stage 10609 Senders: Initiator 10610 Scope: SW 10612 SessionType= 10614 Default is Normal. 10616 The Initiator indicates the type of session it wants to create. 10617 The target can either accept it or reject it. 10619 A Discovery session indicates to the Target that the only purpose 10620 of this Session is discovery. The only requests a target accepts 10621 in this type of session are a text request with a SendTargets key 10622 and a logout request with reason "close the session". 10624 The Discovery session implies MaxConnections = 1 and overrides 10625 both the default and an explicit setting. As section 7.4.1 10627 states, ErrorRecoveryLevel MUST be 0 (zero) for Discovery 10628 sessions. 10630 Depending on the type of the session, a target may decide on 10631 resources to allocate and the security to enforce, etc. for the 10632 session. If the SessionType key is thus going to be offered as 10633 "Discovery", it SHOULD be offered in the initial Login request by 10634 the initiator. 10636 13.22. The Private or Public Extension Key Format 10638 Use: ALL 10639 Senders: Initiator and Target 10640 Scope: specific key dependent 10642 X-reversed.vendor.dns_name.do_something= 10644 or 10646 X<#>= 10648 Keys with this format are used for public or private extension 10649 purposes. These keys always start with X- if unregistered with 10650 IANA (private) or X# if registered with IANA (public). 10652 For unregistered keys, to identify the vendor, we suggest you use 10653 the reversed DNS-name as a prefix to the key-proper. 10655 The part of key-name following X- and X# MUST conform to the 10656 format for key-name specified in Section 6.1-"Text Format". 10658 For IANA registered keys the string following X# must be 10659 registered with IANA and the use of the key MUST be described by a 10660 standards track RFC, an experimental RFC, or an informational RFC. 10662 Vendor specific keys MUST ONLY be used in normal sessions. 10664 Support for public or private extension keys is OPTIONAL. 10666 13.23. Task Reporting 10668 Use: LO 10669 Senders: Initiator and Target 10670 Scope: SW 10671 Irrelevant when: SessionType=Discovery 10672 TaskReporting= 10674 Default is RFC3720. 10675 Result function is AND. 10677 This key is used to negotiate the task completion reporting 10678 semantics from the SCSI target. The following table describes the 10679 semantics that an iSCSI target MUST support for respective 10680 negotiated key values. Whenever this key is negotiated, at least 10681 the RFC3720 and ResponseFence values MUST be offered as options by 10682 the negotiation originator. 10683 +--------------+------------------------------------------+ 10684 | Name | Description | 10685 +--------------+------------------------------------------+ 10686 | RFC3720 | RFC 3720-compliant semantics. Response | 10687 | | fencing is not guaranteed and fast | 10688 | | completion of multi-task aborting is not | 10689 | | supported | 10690 +--------------+------------------------------------------+ 10691 | ResponseFence| Response Fence (section 4.2.2.3.3) | 10692 | | semantics MUST be supported in reporting | 10693 | | task completions | 10694 +--------------+------------------------------------------+ 10695 | FastAbort | Updated fast multi-task abort semantics | 10696 | | defined in Section 4.2.3.4 MUST be | 10697 | | supported. Support for Response Fence is | 10698 | | implied -- i.e., (Section 4.2.2.3.3) | 10699 | | semantics MUST be supported as well | 10700 +--------------+------------------------------------------+ 10701 When TaskReporting is not negotiated to FastAbort, the standard 10702 multi-task abort semantics in Section 4.2.3.3 MUST be used. 10704 13.24. iSCSIProtocolLevel Negotiation 10706 The iSCSIProtocolLevel associated with this document is "1". As a 10707 responder or an originator in a negotiation of this key, an iSCSI 10708 implementation compliant to this document alone, without any 10709 future protocol extensions, MUST use this value as defined by the 10710 [iSCSI-SAM] document. 10712 13.25. Obsoleted Keys 10714 This document obsoletes the following keys defined in [RFC3720]: 10715 IFMarker, OFMarker, OFMarkInt, IFMarkInt. However, iSCSI 10716 implementations compliant to this document may still receive these 10717 obsoleted keys - i.e. in a responder role - in a text negotiation. 10719 When IFMarker or OFMarker key is received, a compliant iSCSI 10720 implementation SHOULD respond with the constant "Reject" value. 10721 The implementation MAY alternatively respond with a "No" value. 10722 However, the implementation MUST NOT respond with a 10723 "NotUnderstood" value for either of these keys. 10725 When IFMarkInt or OFMarkInt key is received, a compliant iSCSI 10726 implementation MUST respond with the constant "Reject" value. 10727 The implementation MUST NOT respond with a "NotUnderstood" value 10728 for either of these keys. 10730 13.26. X#NodeArchitecture 10732 13.26.1. Definition 10734 Use: LO, Declarative 10735 Senders: Initiator and Target 10736 Scope: SW 10738 X#NodeArchitecture= 10740 Default is none. 10742 Examples: 10743 X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a 10744 X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 10745 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 10747 This document does not define the structure or content of the list 10748 of values. 10750 The initiator or target declares the details of its iSCSI node 10751 architecture to the remote endpoint. These details may include, 10752 but are not limited to, iSCSI vendor software, firmware, or 10754 hardware versions, the OS version, or hardware architecture. This 10755 key may be declared on a Discovery session or a Normal session. 10757 The length of the key value (total length of the list-of-values) 10758 MUST NOT be greater than 255 bytes. 10760 X#NodeArchitecture MUST NOT be redeclared during the login phase. 10762 13.26.2. Implementation Requirements 10764 Functional behavior of the iSCSI node (this includes the iSCSI 10765 protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT 10766 depend on the presence, absence, or content of the 10767 X#NodeArchitecture key. The key MUST NOT be used by iSCSI nodes 10768 for interoperability, or exclusion of other nodes. To ensure 10769 proper use, key values SHOULD be set by the node itself, and there 10770 SHOULD NOT be provisions for the key values to contain user- 10771 defined text. 10773 Nodes implementing this key MUST choose one of the following 10774 implementation options: 10776 only transmit the key, 10777 only log the key values received from other nodes, or 10778 both transmit and log the key values. 10779 Each node choosing to implement transmission of the key values 10780 MUST be prepared to handle the response of iSCSI Nodes that do not 10781 understand the key. 10783 Nodes that implement transmission and/or logging of the key values 10784 may also implement administrative mechanisms that disable and/or 10785 change the logging and key transmission detail (see Section 9.4 - 10786 "Security Considerations for the X#NodeArchitecture Key"). Thus, a 10787 valid behavior for this key may be that a node is completely 10788 silent (the node does not transmit any key value, and simply 10789 discards any key values it receives without issuing a 10790 NotUnderstood response). 10792 14. IANA Considerations 10794 The well-known TCP port number for iSCSI connections assigned by 10795 IANA is 3260 and this is the default iSCSI port. Implementations 10796 needing a system TCP port number may use port 860, the port 10797 assigned by IANA as the iSCSI system port; however in order to use 10798 port 860, it MUST be explicitly specified - implementations MUST 10799 NOT default to use of port 860, as 3260 is the only allowed 10800 default. 10802 [RFC3720] instructs that three text key registries be set up, one 10803 for each of Extension keys, authentication methods, or digest keys 10804 - with the stipulation that the key prefix (X#, Y# or Z#) be not 10805 recorded. However, [RFC4850] indicates that the key prefix was 10806 recorded by IANA as part of the key name. Consequently, storm 10807 working group (which published this document) instructs IANA that: 10808 (i) It maintain a single text key registry for iSCSI keys, and, 10809 (ii) MUST always record the key prefix as part of the recorded 10810 string 10812 This is being done with the intent to not have to change what IANA 10813 already did while publishing [RFC4850]. 10815 All the other IANA considerations stated in [RFC3720] and 10816 [RFC5048] remain unchanged. 10818 This document obsoletes the SPKM1 and SPKM2 key values for the 10819 AuthMethod text key. Consequently, the SPKM_ text key prefix MUST 10820 be treated as obsolete and be not reused. 10822 References 10824 Normative References 10826 [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", 10827 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 10829 [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling 10830 Interface (FC-FS). 10832 [iSCSI-SAM] Knight, F., Chadalapaka, M., "Internet Small 10833 Computer Systems Interface (iSCSI) SCSI Architecture 10834 Features Update", draft-ietf-storm-iscsi-sam-04.txt (work in 10835 progress), August 2011 10837 [OUI] "IEEE OUI and Company_Id Assignments", 10838 http://standards.ieee.org/regauth/oui 10840 [RFC791] INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL 10841 SPECIFICATION, September 1981. 10843 [RFC793] TRANSMISSION CONTROL PROTOCOL, DARPA INTERNET PROGRAM 10844 PROTOCOL SPECIFICATION, September 1981. 10846 [RFC1035] P. Mockapetris, DOMAIN NAMES - IMPLEMENTATION AND 10847 SPECIFICATION, November 1987. 10849 [RFC1122] Requirements for Internet Hosts-Communication Layer 10850 RFC1122, R. Braden (editor). 10852 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 10853 June 1996. 10855 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", 10856 August 1996. 10858 [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication 10859 Protocol (CHAP)", August 1996. 10861 [RFC2025] C. Adams, "The Simple Public-Key GSS-API Mechanism 10862 (SPKM)", October 1996. 10864 [RFC2045] N. Borenstein, N. Freed, "MIME (Multipurpose 10865 Internet Mail Extensions) Part One: Mechanisms for 10866 Specifying and Describing the Format of Internet Message 10867 Bodies", November 1996. 10869 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 10870 Requirement Levels", BCP 14, March 1997. 10872 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 10873 within ESP and AH", November 1998. 10875 [RFC2451] R. Pereira, R. Adams "The ESP CBC-Mode Cipher 10876 Algorithms". 10878 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange 10879 System", September 2000. 10881 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 10882 Internationalized Strings ("stringprep")", RFC 3454, 10883 December 2002. 10885 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 10886 Algorithm and Its Use With IPsec", RFC 3566, September 2003. 10888 [RFC3629] Yergeau, F., "UTF-8, a Transformation Format of ISO 10889 10646", RFC 3629, November 2003 10891 [RFC3686] Housley, R., "Using Advanced Encryption Standard 10892 (AES) Counter Mode with IPsec Encapsulating Security Payload 10893 (ESP)", RFC 3686, January 2004. 10895 [RFC3722] Bakke, M., "String Profile for Internet Small 10896 Computer Systems Interface (iSCSI) Names", RFC 3722, March 10897 2004. 10899 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. 10900 Travostino, "Securing Block Storage Protocols over IP", RFC 10901 3723, March 2004. 10903 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter "Uniform 10904 Resource Identifier (URI): Generic Syntax", January 2005. 10906 [RFC4106] J. Viega, D. McGrew, "The Use of Galois/Counter Mode 10907 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 10908 4106, June 2005. 10910 [RFC4120] Neuman, C., Yu, T., Hartman, S., Raeburn, K, "The 10911 Kerberos Network Authentication Service (V5)", RFC 4120, 10912 July 2005. 10914 [RFC4171] J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. 10915 Souza, "Internet Storage Name Service (iSNS)", September 10916 2005. 10918 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10919 Architecture", February 2006. 10921 [RFC4301] S. Kent, K.Seo, "Security Architecture for the 10922 Internet Protocol", December 2005. 10924 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 10925 RFC 4303, December 2005 10927 [RFC4543] D. McGrew, J. Viega, "The Use of Galois Message 10928 Authentication Code (GMAC) in IPsec ESP and AH", May 2006 10930 [RFC5646] A. Phillips, M. Davis, "Tags for Identifying 10931 Languages ", RFC 5646, September 2009. 10933 [RFC5226] T. Narten, and H. Avestrand, "Guidelines for 10934 Writing an IANA Considerations Section in RFCs.", May 2008. 10936 [RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet 10937 Key Exchange Protocol Version 2 (IKEv2) ", RFC 5996, 10938 September 2010. 10940 [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). 10942 [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). 10944 [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). 10946 [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC). 10948 [SPC3] T10/1416-D, SCSI Primary Commands-3. 10950 [UML] ISO/IEC 19501, Unified Modeling Language 10951 Specification Version 1.4.2. 10953 [UNICODE] Unicode Standard Annex #15, "Unicode Normalization 10954 Forms", http://www.unicode.org/unicode/reports/tr15 10956 Informative References 10958 [RFC1737] K. Sollins, L. Masinter "Functional Requirements for 10959 Uniform Resource Names". 10961 [IB] InfiniBand{tm} Architecture Specification, Vol. 1, 10962 Rel.1.0.a, InfiniBand 10963 TradezAssociation(http://www.infinibandta.org). 10965 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman 10966 "Optimization of Cyclic Redundancy-Check Codes with 24 and 10967 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, 10968 No. 6, June 1993. 10970 [CRC] ISO 3309, High-Level Data Link Control (CRC 32). 10972 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 10973 Internet Protocol ", November 1998. 10975 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security 10976 Payload (ESP)", November 1998. 10978 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange 10979 (IKE)", November 1998. 10981 [RFC3347] Krueger, M., Haagens, R., Sapuntzakis, C. and M. 10982 Bakke, "Small Computer Systems Interface protocol over the 10983 Internet (iSCSI) Requirements and Design Considerations", 10984 RFC 3347, July 2002. 10986 [RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. 10987 Cavanna, "Internet Protocol Small Computer System Interface 10988 (iSCSI) Cyclic Redundancy Check (CRC)/Checksum 10989 Considerations", RFC 3385, September 2002. 10991 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 10992 M., and E. Zeidner, "Internet Small Computer Systems 10993 Interface (iSCSI)", RFC 3720, April 2004. 10995 [RFC3980] Krueger, M., Chadalapaka, M., Elliott, R., "T11 10996 Network Address Authority (NAA) Naming Format for iSCSI Node 10997 Names", RFC 3980, February 2005. 10999 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. 11000 and M. Krueger, "Internet Small Computer Systems Interface 11001 (iSCSI) Naming and Discovery", RFC 3721, March 2004 11003 [RFC3783] M. Chadalapaka, R. Elliott, "Small Computer Systems 11004 Interface (SCSI) Command Ordering Considerations with 11005 iSCSI", RFC 3783, May 2004. 11007 [RFC4173] P. Sarkar, D. Missimer, C. Sapuntzakis, 11008 "Bootstrapping Clients using the Internet Small Computer 11009 System Interface (iSCSI) Protocol", RFC 4173, September 11010 2005. 11012 [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, 11013 "Remote Direct Memory Access (RDMA) over IP Problem 11014 Statement", RFC 4297, October 2004 11016 [RFC4850] Wysochanski, D., "Declarative Public Extension Key 11017 for Internet Small Computer Systems Interface (iSCSI) Node 11018 Architecture", RFC 4850, April 2007. 11020 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., 11021 Shah, H., and P. Thaler, "Internet Small Computer System 11022 Interface (iSCSI) Extensions for Remote Direct Memory Access 11023 (RDMA)", RFC 5046, October 2007 11025 [RFC5048] Chadalapaka, M., "Internet Small Computer Systems 11026 Interface (iSCSI) Corrections and Clarifications", RFC 5048, 11027 October 2007. 11029 [Schneier] B. Schneier, "Applied Cryptography: Protocols, 11030 Algorithms, and Source Code in C", 2nd edition, John Wiley & 11031 Sons, New York, NY, 1996. 11033 [SAS] INCITS 376-2003, Serial Attached SCSI (SAS). 11035 [SRP] INCITS 365-2002, SCSI RDMA Protocol (SRP). 11037 Appendix A. Examples 11039 Read Operation Example 11041 +------------------+-----------------------+---------------------+ 11042 |Initiator Function| PDU Type | Target Function | 11043 +------------------+-----------------------+---------------------+ 11044 | Command request |SCSI Command (READ)>>> | | 11045 | (read) | | | 11046 +------------------+-----------------------+---------------------+ 11047 | | |Prepare Data Transfer| 11048 +------------------+-----------------------+---------------------+ 11049 | Receive Data | <<< SCSI Data-in | Send Data | 11050 +------------------+-----------------------+---------------------+ 11051 | Receive Data | <<< SCSI Data-in | Send Data | 11052 +------------------+-----------------------+---------------------+ 11053 | Receive Data | <<< SCSI Data-in | Send Data | 11054 +------------------+-----------------------+---------------------+ 11055 | | <<< SCSI Response |Send Status and Sense| 11056 +------------------+-----------------------+---------------------+ 11057 | Command Complete | | | 11058 +------------------+-----------------------+---------------------+ 11060 Write Operation Example 11062 +------------------+-----------------------+---------------------+ 11063 |Initiator Function| PDU Type | Target Function | 11064 +------------------+-----------------------+---------------------+ 11065 | Command request |SCSI Command (WRITE)>>>| Receive command | 11066 | (write) | | and queue it | 11067 +------------------+-----------------------+---------------------+ 11068 | | | Process old commands| 11069 +------------------+-----------------------+---------------------+ 11070 | | | Ready to process | 11071 | | <<< R2T | WRITE command | 11072 +------------------+-----------------------+---------------------+ 11073 | Send Data | SCSI Data-out >>> | Receive Data | 11074 +------------------+-----------------------+---------------------+ 11075 | | <<< R2T | Ready for data | 11076 +------------------+-----------------------+---------------------+ 11077 | | <<< R2T | Ready for data | 11078 +------------------+-----------------------+---------------------+ 11079 | Send Data | SCSI Data-out >>> | Receive Data | 11080 +------------------+-----------------------+---------------------+ 11081 | Send Data | SCSI Data-out >>> | Receive Data | 11082 +------------------+-----------------------+---------------------+ 11083 | | <<< SCSI Response |Send Status and Sense| 11084 +------------------+-----------------------+---------------------+ 11085 | Command Complete | | | 11086 +------------------+-----------------------+---------------------+ 11088 R2TSN/DataSN Use Examples 11090 Output (write) data DataSN/R2TSN Example 11091 +------------------+-----------------------+---------------------+ 11092 |Initiator Function| PDU Type & Content | Target Function | 11093 +------------------+-----------------------+---------------------+ 11094 | Command request |SCSI Command (WRITE)>>>| Receive command | 11095 | (write) | | and queue it | 11096 +------------------+-----------------------+---------------------+ 11097 | | | Process old commands| 11098 +------------------+-----------------------+---------------------+ 11099 | | <<< R2T | Ready for data | 11100 | | R2TSN = 0 | | 11101 +------------------+-----------------------+---------------------+ 11102 | | <<< R2T | Ready for more data | 11103 | | R2TSN = 1 | | 11104 +------------------+-----------------------+---------------------+ 11105 | Send Data | SCSI Data-out >>> | Receive Data | 11106 | for R2TSN 0 | DataSN = 0, F=0 | | 11107 +------------------+-----------------------+---------------------+ 11108 | Send Data | SCSI Data-out >>> | Receive Data | 11109 | for R2TSN 0 | DataSN = 1, F=1 | | 11110 +------------------+-----------------------+---------------------+ 11111 | Send Data | SCSI Data >>> | Receive Data | 11112 | for R2TSN 1 | DataSN = 0, F=1 | | 11113 +------------------+-----------------------+---------------------+ 11114 | | <<< SCSI Response |Send Status and Sense| 11115 | | ExpDataSN = 0 | | 11116 +------------------+-----------------------+---------------------+ 11117 | Command Complete | | | 11118 +------------------+-----------------------+---------------------+ 11120 Input (read) data DataSN Example 11122 +------------------+-----------------------+---------------------+ 11123 |Initiator Function| PDU Type | Target Function | 11124 +------------------+-----------------------+---------------------+ 11125 | Command request |SCSI Command (READ)>>> | | 11126 | (read) | | | 11127 +------------------+-----------------------+---------------------+ 11128 | | |Prepare Data Transfer| 11129 +------------------+-----------------------+---------------------+ 11130 | Receive Data | <<< SCSI Data-in | Send Data | 11131 | | DataSN = 0, F=0 | | 11132 +------------------+-----------------------+---------------------+ 11133 | Receive Data | <<< SCSI Data-in | Send Data | 11134 | | DataSN = 1, F=0 | | 11135 +------------------+-----------------------+---------------------+ 11136 | Receive Data | <<< SCSI Data-in | Send Data | 11137 | | DataSN = 2, F=1 | | 11138 +------------------+-----------------------+---------------------+ 11139 | | <<< SCSI Response |Send Status and Sense| 11140 | | ExpDataSN = 3 | | 11141 +------------------+-----------------------+---------------------+ 11142 | Command Complete | | | 11143 +------------------+-----------------------+---------------------+ 11145 Bidirectional DataSN Example 11147 +------------------+-----------------------+---------------------+ 11148 |Initiator Function| PDU Type | Target Function | 11149 +------------------+-----------------------+---------------------+ 11150 | Command request |SCSI Command >>> | | 11151 | (Read-Write) | Read-Write | | 11152 +------------------+-----------------------+---------------------+ 11153 | | | Process old commands| 11154 +------------------+-----------------------+---------------------+ 11155 | | <<< R2T | Ready to process | 11156 | | R2TSN = 0 | WRITE command | 11157 +------------------+-----------------------+---------------------+ 11158 | * Receive Data | <<< SCSI Data-in | Send Data | 11159 | | DataSN = 0, F=0 | | 11160 +------------------+-----------------------+---------------------+ 11161 | * Receive Data | <<< SCSI Data-in | Send Data | 11162 | | DataSN = 1, F=1 | | 11163 +------------------+-----------------------+---------------------+ 11164 | * Send Data | SCSI Data-out >>> | Receive Data | 11165 | for R2TSN 0 | DataSN = 0, F=1 | | 11166 +------------------+-----------------------+---------------------+ 11167 | | <<< SCSI Response |Send Status and Sense| 11168 | | ExpDataSN = 2 | | 11169 +------------------+-----------------------+---------------------+ 11170 | Command Complete | | | 11171 +------------------+-----------------------+---------------------+ 11173 *) Send data and Receive Data may be transferred simultaneously as 11174 in an atomic Read-Old-Write-New or sequentially as in an atomic 11175 Read-Update-Write (in the latter case the R2T may follow the 11176 received data). 11178 Unsolicited and immediate output (write) data with DataSN Example 11179 +------------------+-----------------------+---------------------+ 11180 |Initiator Function| PDU Type & Content | Target Function | 11181 +------------------+-----------------------+---------------------+ 11182 | Command request |SCSI Command (WRITE)>>>| Receive command | 11183 | (write) |F=0 | and data | 11184 |+ immediate data | | and queue it | 11185 +------------------+-----------------------+---------------------+ 11186 | Send Unsolicited | SCSI Write Data >>> | Receive more Data | 11187 | Data | DataSN = 0, F=1 | | 11188 +------------------+-----------------------+---------------------+ 11189 | | | Process old commands| 11190 +------------------+-----------------------+---------------------+ 11191 | | <<< R2T | Ready for more data | 11192 | | R2TSN = 0 | | 11193 +------------------+-----------------------+---------------------+ 11194 | Send Data | SCSI Write Data >>> | Receive Data | 11195 | for R2TSN 0 | DataSN = 0, F=1 | | 11196 +------------------+-----------------------+---------------------+ 11197 | | <<< SCSI Response |Send Status and Sense| 11198 | | | | 11199 +------------------+-----------------------+---------------------+ 11200 | Command Complete | | | 11201 +------------------+-----------------------+---------------------+ 11203 CRC Examples 11205 N.B. all Values are Hexadecimal 11207 32 bytes of zeroes: 11209 Byte: 0 1 2 3 11211 0: 00 00 00 00 11212 ... 11213 28: 00 00 00 00 11215 CRC: aa 36 91 8a 11217 32 bytes of ones: 11219 Byte: 0 1 2 3 11220 0: ff ff ff ff 11221 ... 11222 28: ff ff ff ff 11224 CRC: 43 ab a8 62 11226 32 bytes of incrementing 00..1f: 11228 Byte: 0 1 2 3 11230 0: 00 01 02 03 11231 ... 11232 28: 1c 1d 1e 1f 11234 CRC: 4e 79 dd 46 11236 32 bytes of decrementing 1f..00: 11238 Byte: 0 1 2 3 11240 0: 1f 1e 1d 1c 11241 ... 11242 28: 03 02 01 00 11244 CRC: 5c db 3f 11 11246 An iSCSI - SCSI Read (10) Command PDU 11248 Byte: 0 1 2 3 11250 0: 01 c0 00 00 11251 4: 00 00 00 00 11252 8: 00 00 00 00 11253 12: 00 00 00 00 11254 16: 14 00 00 00 11255 20: 00 00 04 00 11256 24: 00 00 00 14 11257 28: 00 00 00 18 11258 32: 28 00 00 00 11259 36: 00 00 00 00 11260 40: 02 00 00 00 11261 44: 00 00 00 00 11263 CRC: 56 3a 96 d9 11265 Appendix B. Login Phase Examples 11267 In the first example, the initiator and target authenticate each 11268 other via Kerberos: 11270 I-> Login (CSG,NSG=0,1 T=1) 11271 InitiatorName=iqn.1999-07.com.os:hostid.77 11272 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11273 AuthMethod=KRB5,SRP,None 11275 T-> Login (CSG,NSG=0,0 T=0) 11276 AuthMethod=KRB5 11278 I-> Login (CSG,NSG=0,1 T=1) 11279 KRB_AP_REQ= 11281 (krb_ap_req contains the Kerberos V5 ticket and authenticator with 11282 MUTUAL-REQUIRED set in the ap-options field) 11284 If the authentication is successful, the target proceeds with: 11286 T-> Login (CSG,NSG=0,1 T=1) 11287 KRB_AP_REP= 11289 (krb_ap_rep is the Kerberos V5 mutual authentication reply) 11291 If the authentication is successful, the initiator may proceed 11292 with: 11294 I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192 11295 T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096 11296 MaxBurstLength=8192 11297 I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192 11298 ... more iSCSI Operational Parameters 11300 T-> Login (CSG,NSG=1,0 T=0) 11301 ... more iSCSI Operational Parameters 11303 And at the end: 11305 I-> Login (CSG,NSG=1,3 T=1) 11306 optional iSCSI parameters 11308 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11310 If the initiator's authentication by the target is not successful, 11311 the target responds with: 11313 T-> Login "login reject" 11315 instead of the Login KRB_AP_REP message, and terminates the 11316 connection. 11318 If the target's authentication by the initiator is not successful, 11319 the initiator terminates the connection (without responding to the 11320 Login KRB_AP_REP message). 11322 In the next example only the initiator is authenticated by the 11323 target via Kerberos: 11325 I-> Login (CSG,NSG=0,1 T=1) 11326 InitiatorName=iqn.1999-07.com.os:hostid.77 11327 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11328 AuthMethod=SRP,KRB5,None 11330 T-> Login-PR (CSG,NSG=0,0 T=0) 11331 AuthMethod=KRB5 11333 I-> Login (CSG,NSG=0,1 T=1) 11334 KRB_AP_REQ=krb_ap_req 11336 (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req) 11338 If the authentication is successful, the target proceeds with: 11340 T-> Login (CSG,NSG=0,1 T=1) 11342 I-> Login (CSG,NSG=1,0 T=0) 11343 ... iSCSI parameters 11345 T-> Login (CSG,NSG=1,0 T=0) 11346 ... iSCSI parameters 11348 . . . 11350 T-> Login (CSG,NSG=1,3 T=1)"login accept" 11352 In the next example, the initiator and target authenticate each 11353 other via SRP: 11355 I-> Login (CSG,NSG=0,1 T=1) 11356 InitiatorName=iqn.1999-07.com.os:hostid.77 11357 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11358 AuthMethod=KRB5,SRP,None 11360 T-> Login-PR (CSG,NSG=0,0 T=0) 11361 AuthMethod=SRP 11363 I-> Login (CSG,NSG=0,0 T=0) 11364 SRP_U= 11365 TargetAuth=Yes 11367 T-> Login (CSG,NSG=0,0 T=0) 11368 SRP_N= 11369 SRP_g= 11370 SRP_s= 11372 I-> Login (CSG,NSG=0,0 T=0) 11373 SRP_A= 11375 T-> Login (CSG,NSG=0,0 T=0) 11376 SRP_B= 11378 I-> Login (CSG,NSG=0,1 T=1) 11379 SRP_M= 11381 If the initiator authentication is successful, the target 11382 proceeds: 11384 T-> Login (CSG,NSG=0,1 T=1) 11385 SRP_HM= 11387 Where N, g, s, A, B, M, and H(A | M | K) are defined in 11388 [RFC2945]. 11390 If the target authentication is not successful, the initiator 11391 terminates the connection; otherwise, it proceeds. 11393 I-> Login (CSG,NSG=1,0 T=0) 11394 ... iSCSI parameters 11396 T-> Login (CSG,NSG=1,0 T=0) 11397 ... iSCSI parameters 11399 And at the end: 11401 I-> Login (CSG,NSG=1,3 T=1) 11402 optional iSCSI parameters 11404 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11406 If the initiator authentication is not successful, the target 11407 responds with: 11409 T-> Login "login reject" 11411 Instead of the T-> Login SRP_HM= message and 11412 terminates the connection. 11414 In the next example, only the initiator is authenticated by the 11415 target via SRP: 11417 I-> Login (CSG,NSG=0,1 T=1) 11418 InitiatorName=iqn.1999-07.com.os:hostid.77 11419 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11420 AuthMethod=KRB5,SRP,None 11422 T-> Login-PR (CSG,NSG=0,0 T=0) 11423 AuthMethod=SRP 11425 I-> Login (CSG,NSG=0,0 T=0) 11426 SRP_U= 11427 TargetAuth=No 11429 T-> Login (CSG,NSG=0,0 T=0) 11430 SRP_N= 11431 SRP_g= 11432 SRP_s= 11434 I-> Login (CSG,NSG=0,0 T=0) 11435 SRP_A= 11437 T-> Login (CSG,NSG=0,0 T=0) 11438 SRP_B= 11440 I-> Login (CSG,NSG=0,1 T=1) 11441 SRP_M= 11443 If the initiator authentication is successful, the target 11444 proceeds: 11446 T-> Login (CSG,NSG=0,1 T=1) 11448 I-> Login (CSG,NSG=1,0 T=0) 11450 ... iSCSI parameters 11452 T-> Login (CSG,NSG=1,0 T=0) 11454 ... iSCSI parameters 11456 And at the end: 11458 I-> Login (CSG,NSG=1,3 T=1) 11460 optional iSCSI parameters 11462 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11464 In the next example the initiator and target authenticate each 11465 other via CHAP: 11467 I-> Login (CSG,NSG=0,0 T=0) 11469 InitiatorName=iqn.1999-07.com.os:hostid.77 11471 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11473 AuthMethod=KRB5,CHAP,None 11475 T-> Login-PR (CSG,NSG=0,0 T=0) 11477 AuthMethod=CHAP 11479 I-> Login (CSG,NSG=0,0 T=0) 11481 CHAP_A= 11483 T-> Login (CSG,NSG=0,0 T=0) 11484 CHAP_A= 11485 CHAP_I= 11486 CHAP_C= 11488 I-> Login (CSG,NSG=0,1 T=1) 11490 CHAP_N= 11492 CHAP_R= 11494 CHAP_I= 11496 CHAP_C= 11498 If the initiator authentication is successful, the target 11499 proceeds: 11501 T-> Login (CSG,NSG=0,1 T=1) 11503 CHAP_N= 11505 CHAP_R= 11507 If the target authentication is not successful, the initiator 11508 aborts the connection; otherwise, it proceeds. 11510 I-> Login (CSG,NSG=1,0 T=0) 11512 ... iSCSI parameters 11514 T-> Login (CSG,NSG=1,0 T=0) 11516 ... iSCSI parameters 11518 And at the end: 11520 I-> Login (CSG,NSG=1,3 T=1) 11522 optional iSCSI parameters 11524 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11526 If the initiator authentication is not successful, the target 11527 responds with: 11529 T-> Login "login reject" 11531 Instead of the Login CHAP_R= "proceed and change 11532 stage" message and terminates the connection. 11534 In the next example, only the initiator is authenticated by the 11535 target via CHAP: 11537 I-> Login (CSG,NSG=0,1 T=0) 11539 InitiatorName=iqn.1999-07.com.os:hostid.77 11541 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11543 AuthMethod=KRB5,CHAP,None 11545 T-> Login-PR (CSG,NSG=0,0 T=0) 11547 AuthMethod=CHAP 11549 I-> Login (CSG,NSG=0,0 T=0) 11551 CHAP_A= 11553 T-> Login (CSG,NSG=0,0 T=0) 11554 CHAP_A= 11555 CHAP_I= 11556 CHAP_C= 11558 I-> Login (CSG,NSG=0,1 T=1) 11560 CHAP_N= 11562 CHAP_R= 11564 If the initiator authentication is successful, the target 11565 proceeds: 11567 T-> Login (CSG,NSG=0,1 T=1) 11569 I-> Login (CSG,NSG=1,0 T=0) 11571 ... iSCSI parameters 11573 T-> Login (CSG,NSG=1,0 T=0) 11575 ... iSCSI parameters 11577 And at the end: 11579 I-> Login (CSG,NSG=1,3 T=1) 11581 optional iSCSI parameters 11583 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11585 In the next example, the initiator does not offer any security 11586 parameters. It therefore may offer iSCSI parameters on the Login 11587 PDU with the T bit set to 1, and the target may respond with a 11588 final Login Response PDU immediately: 11590 I-> Login (CSG,NSG=1,3 T=1) 11592 InitiatorName=iqn.1999-07.com.os:hostid.77 11594 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11596 ... iSCSI parameters 11598 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11600 ... ISCSI parameters 11602 In the next example, the initiator does offer security 11603 parameters on the Login PDU, but the target does not choose 11604 any (i.e., chooses the "None" values): 11606 I-> Login (CSG,NSG=0,1 T=1) 11608 InitiatorName=iqn.1999-07.com.os:hostid.77 11610 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11612 AuthMethod=KRB5,SRP,None 11614 T-> Login-PR (CSG,NSG=0,1 T=1) 11616 AuthMethod=None 11618 I-> Login (CSG,NSG=1,0 T=0) 11620 ... iSCSI parameters 11622 T-> Login (CSG,NSG=1,0 T=0) 11624 ... iSCSI parameters 11626 And at the end: 11628 I-> Login (CSG,NSG=1,3 T=1) 11630 optional iSCSI parameters 11632 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11634 Appendix C. SendTargets Operation 11636 To reduce the amount of configuration required on an initiator, 11637 iSCSI provides the SendTargets text request. The initiator uses 11638 the SendTargets request to get a list of targets to which it may 11639 have access, as well as the list of addresses (IP address and TCP 11640 port) on which these targets may be accessed. 11642 To make use of SendTargets, an initiator must first establish one 11643 of two types of sessions. If the initiator establishes 11644 the session using the key "SessionType=Discovery", the session is 11645 a discovery session, and a target name does not need to be 11646 specified. Otherwise, the session is a normal, operational 11647 session. The SendTargets command MUST only be sent during the 11648 Full Feature Phase of a normal or discovery session. 11650 A system that contains targets MUST support discovery sessions on 11651 each of its iSCSI IP address-port pairs, and MUST support the 11652 SendTargets command on the discovery session. In a discovery 11653 session, a target MUST return all path information (IP address- 11654 port pairs and portal group tags) for the targets on the target 11655 network entity which the requesting initiator is authorized to 11656 access. 11658 A target MUST support the SendTargets command on operational 11659 sessions; these will only return path information about the target 11660 to which the session is connected, and do not need to return 11661 information about other target names that may be defined in the 11662 responding system. 11664 An initiator MAY make use of the SendTargets as it sees fit. 11666 A SendTargets command consists of a single Text request PDU. 11667 This PDU contains exactly one text key and value. The text key 11668 MUST be SendTargets. The expected response depends upon the 11669 value, as well as whether the session is a discovery or 11670 operational session. 11672 The value must be one of: 11674 All 11676 The initiator is requesting that information on all relevant 11677 targets known to the implementation be returned. This value 11678 MUST be supported on a discovery session, and MUST NOT be 11679 supported on an operational session. 11681 11682 If an iSCSI target name is specified, the session should 11683 respond with addresses for only the named target, if 11684 possible. This value MUST be supported on discovery 11685 sessions. A discovery session MUST be capable of returning 11686 addresses for those targets that would have been returned 11687 had value=All been designated. 11689 11691 The session should only respond with addresses for the target 11692 to which the session is logged in. This MUST be supported 11693 on operational sessions, and MUST NOT return targets other 11694 than the one to which the session is logged in. 11696 The response to this command is a text response that contains a 11697 list of zero or more targets and, optionally, their addresses. 11698 Each target is returned as a target record. A target record 11699 begins with the TargetName text key, followed by a list of 11700 TargetAddress text keys, and bounded by the end of the text 11701 response or the next TargetName key, which begins a new record. 11702 No text keys other than TargetName and TargetAddress are permitted 11703 within a SendTargets response. 11705 For the format of the TargetName, see Section 13.4 - "TargetName". 11707 A discovery session MAY respond to a SendTargets request with its 11708 complete list of targets, or with a list of targets that is based 11709 on the name of the initiator logged in to the session. 11711 A SendTargets response MUST NOT contain target names if there are 11712 no targets for the requesting initiator to access. 11714 Each target record returned includes zero or more TargetAddress 11715 fields. 11717 Each target record starts with one text key of the form: 11719 TargetName= 11721 Followed by zero or more address keys of the form: 11723 TargetAddress=[:], 11726 The hostname-or-ipaddress contains a domain name, IPv4 address, or 11727 IPv6 address, as specified for the TargetAddress key. 11729 A hostname-or-ipaddress duplicated in TargetAddress responses for 11730 a given node (the port is absent or equal) would probably indicate 11731 that multiple address families are in use at once (IPv6 and IPv4). 11733 Each TargetAddress belongs to a portal group, identified by its 11734 numeric portal group tag (as in Section 13.9- 11735 "TargetPortalGroupTag"). The iSCSI target name, together with this 11736 tag, constitutes the SCSI port identifier; the tag only needs to 11737 be unique within a given target's name list of addresses. 11739 Multiple-connection sessions can span iSCSI addresses that belong 11740 to the same portal group. 11742 Multiple-connection sessions cannot span iSCSI addresses that 11743 belong to different portal groups. 11745 If a SendTargets response reports an iSCSI address for a target, 11746 it SHOULD also report all other addresses in its portal group in 11747 the same response. 11749 A SendTargets text response can be longer than a single Text 11750 Response PDU, and makes use of the long text responses as 11751 specified. 11753 After obtaining a list of targets from the discovery target 11754 session, 11755 an iSCSI initiator may initiate new sessions to log in to the 11756 discovered targets for full operation. The initiator MAY keep the 11757 discovery session open, and MAY send subsequent SendTargets 11758 commands to discover new targets. 11760 Examples: 11762 This example is the SendTargets response from a single target that 11763 has no other interface ports. 11765 Initiator sends text request that contains: 11767 SendTargets=All 11769 Target sends a text response that contains: 11771 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11773 All the target had to return in the simple case was the target 11774 name. It is assumed by the initiator that the IP address and TCP 11775 port for this target are the same as used on the current 11776 connection to the default iSCSI target. 11778 The next example has two internal iSCSI targets, each accessible 11779 via two different ports with different IP addresses. The 11780 following is the text response: 11782 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11784 TargetAddress=10.1.0.45:3000,1 11786 TargetAddress=10.1.1.45:3000,2 11788 TargetName=iqn.1993-11.com.example:diskarray.sn.1234567 11790 TargetAddress=10.1.0.45:3000,1 11792 TargetAddress=10.1.1.45:3000,2 11794 Both targets share both addresses; the multiple addresses are 11795 likely used to provide multi-path support. The initiator may 11796 connect to either target name on either address. Each of the 11797 addresses has its own portal group tag; they do not support 11798 spanning multiple-connection sessions with each other. Keep in 11799 mind that the portal group tags for the two named targets are 11800 independent of one another; portal group "1" on the first target 11801 is not necessarily the same as portal group "1" on the second 11802 target. 11804 In the above example, a DNS host name or an IPv6 address could 11805 have been returned instead of an IPv4 address. 11807 The next text response shows a target that supports spanning 11808 sessions across multiple addresses, and further illustrates the 11809 use of the portal group tags: 11811 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11813 TargetAddress=10.1.0.45:3000,1 11815 TargetAddress=10.1.1.46:3000,1 11817 TargetAddress=10.1.0.47:3000,2 11819 TargetAddress=10.1.1.48:3000,2 11821 TargetAddress=10.1.1.49:3000,3 11823 In this example, any of the target addresses can be used to reach 11824 the same target. A single-connection session can be established 11825 to any of these TCP addresses. A multiple-connection session 11826 could span addresses .45 and .46 or .47 and .48, but cannot span 11827 any other combination. A TargetAddress with its own tag (.49) 11828 cannot be combined with any other address within the same session. 11830 This SendTargets response does not indicate whether .49 supports 11831 multiple connections per session; it is communicated via the 11832 MaxConnections text key upon login to the target. 11834 Appendix D. Algorithmic Presentation of Error Recovery Classes 11836 This appendix illustrates the error recovery classes using a 11837 pseudo-programming-language. The procedure names are chosen to be 11838 obvious to most implementers. Each of the recovery classes 11839 described has initiator procedures as well as target procedures. 11840 These algorithms focus on outlining the mechanics of error 11841 recovery classes, and do not exhaustively describe all other 11842 aspects/cases. Examples of this approach are: 11844 - Handling for only certain Opcode types is shown. 11846 - Only certain reason codes (e.g., Recovery in Logout command) 11847 are outlined. 11849 - Resultant cases, such as recovery of Synchronization on a 11850 header digest error are considered out-of-scope in these 11851 algorithms. In this particular example, a header digest 11852 error may lead to connection recovery if some type of sync 11853 and steering layer is not implemented. 11855 These algorithms strive to convey the iSCSI error recovery 11856 concepts in the simplest terms, and are not designed to be 11857 optimal. 11859 D.1. General Data Structure and 11860 Procedure Description 11862 This section defines the procedures and data structures that are 11863 commonly used by all the error recovery algorithms. The structures 11864 may not be the exhaustive representations of what is required for 11865 a typical implementation. 11867 Data structure definitions - 11868 struct TransferContext { 11869 int TargetTransferTag; 11870 int ExpectedDataSN; 11871 }; 11873 struct TCB { /* task control block */ 11874 Boolean SoFarInOrder; 11875 int ExpectedDataSN; /* used for both R2Ts, and Data */ 11876 int MissingDataSNList[MaxMissingDPDU]; 11877 Boolean FbitReceived; 11878 Boolean StatusXferd; 11879 Boolean CurrentlyAllegiant; 11880 int ActiveR2Ts; 11881 int Response; 11882 char *Reason; 11883 struct TransferContext 11884 TransferContextList[MaxOutStandingR2T]; 11885 int InitiatorTaskTag; 11886 int CmdSN; 11887 int SNACK_Tag; 11888 }; 11890 struct Connection { 11891 struct Session SessionReference; 11892 Boolean SoFarInOrder; 11893 int CID; 11894 int State; 11895 int CurrentTimeout; 11896 int ExpectedStatSN; 11897 int MissingStatSNList[MaxMissingSPDU]; 11898 Boolean PerformConnectionCleanup; 11899 }; 11901 struct Session { 11902 int NumConnections; 11903 int CmdSN; 11904 int Maxconnections; 11905 int ErrorRecoveryLevel; 11906 struct iSCSIEndpoint OtherEndInfo; 11907 struct Connection ConnectionList[MaxSupportedConns]; 11908 }; 11910 Procedure descriptions - 11911 Receive-a-In-PDU(transport connection, inbound PDU); 11912 check-basic-validity(inbound PDU); 11913 Start-Timer(timeout handler, argument, timeout value); 11914 Build-And-Send-Reject(transport connection, bad PDU, reason 11915 code); 11916 D.2. Within-command Error Recovery 11917 Algorithms 11919 D.2.1. Procedure Descriptions 11921 Recover-Data-if-Possible(last required DataSN, task control 11922 block); 11923 Build-And-Send-DSnack(task control block); 11924 Build-And-Send-RDSnack(task control block); 11925 Build-And-Send-Abort(task control block); 11926 SCSI-Task-Completion(task control block); 11927 Build-And-Send-A-Data-Burst(transport connection, data- 11928 descriptor, 11929 task control 11930 block); 11931 Build-And-Send-R2T(transport connection, data-descriptor, 11932 task control 11933 block); 11934 Build-And-Send-Status(transport connection, task control block); 11935 Transfer-Context-Timeout-Handler(transfer context); 11937 Notes: 11939 - One procedure used in this section: Handle-Status-SNACK- 11940 request is defined in Within-connection recovery algorithms. 11942 - The Response processing pseudo-code, shown in the target 11943 algorithms, applies to all solicited PDUs that carry StatSN 11944 - SCSI Response, Text Response etc. 11946 D.2.2. Initiator Algorithms 11948 Recover-Data-if-Possible(LastRequiredDataSN, TCB) 11949 { 11950 if (operational ErrorRecoveryLevel > 0) { 11951 if (# of missing PDUs is trackable) { 11952 Note the missing DataSNs in TCB. 11953 if (the task spanned a change in 11954 MaxRecvDataSegmentLength) { 11956 if (TCB.StatusXferd is TRUE) 11957 drop the status PDU; 11958 Build-And-Send-RDSnack(TCB); 11959 } else { 11960 Build-And-Send-DSnack(TCB); 11961 } 11962 } else { 11963 TCB.Reason = "Protocol service CRC error"; 11964 } 11965 } else { 11966 TCB.Reason = "Protocol service CRC error"; 11967 } 11968 if (TCB.Reason == "Protocol service CRC error") { 11969 Clear the missing PDU list in the TCB. 11970 if (TCB.StatusXferd is not TRUE) 11971 Build-And-Send-Abort(TCB); 11972 } 11973 } 11975 Receive-a-In-PDU(Connection, CurrentPDU) 11976 { 11977 check-basic-validity(CurrentPDU); 11978 if (Header-Digest-Bad) discard, return; 11979 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11980 if ((CurrentPDU.type == Data) 11981 or (CurrentPDU.type = R2T)) { 11982 if (Data-Digest-Bad for Data) { 11983 send-data-SNACK = TRUE; 11984 LastRequiredDataSN = CurrentPDU.DataSN; 11985 } else { 11986 if (TCB.SoFarInOrder = TRUE) { 11987 if (current DataSN is expected) { 11988 Increment TCB.ExpectedDataSN. 11989 } else { 11990 TCB.SoFarInOrder = FALSE; 11991 send-data-SNACK = TRUE; 11992 } 11993 } else { 11994 if (current DataSN was considered 11995 missing) { 11996 remove current DataSN from missing 11997 PDU list. 11998 } else if (current DataSN is higher than 11999 expected) { 12000 send-data-SNACK = TRUE; 12001 } else { 12002 discard, return; 12003 } 12004 Adjust TCB.ExpectedDataSN if 12005 appropriate. 12006 } 12007 LastRequiredDataSN = CurrentPDU.DataSN - 1; 12008 } 12009 if (send-data-SNACK is TRUE and 12010 task is not already considered failed) { 12011 Recover-Data-if-Possible(LastRequiredDataSN, TCB); 12012 } 12013 if (missing data PDU list is empty) { 12014 TCB.SoFarInOrder = TRUE; 12015 } 12016 if (CurrentPDU.type == R2T) { 12017 Increment ActiveR2Ts for this task. 12018 Create a data-descriptor for the data burst. 12019 Build-And-Send-A-Data-Burst(Connection, data- 12020 descriptor, 12021 TCB); 12022 } 12023 } else if (CurrentPDU.type == Response) { 12024 if (Data-Digest-Bad) { 12025 send-status-SNACK = TRUE; 12026 } else { 12027 TCB.StatusXferd = TRUE; 12028 Store the status information in TCB. 12029 if (ExpDataSN does not match) { 12030 TCB.SoFarInOrder = FALSE; 12031 Recover-Data-if-Possible(current DataSN, TCB); 12032 } 12033 if (missing data PDU list is empty) { 12034 TCB.SoFarInOrder = TRUE; 12035 } 12037 } 12038 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 12039 SHOWN */ 12040 } 12041 if ((TCB.SoFarInOrder == TRUE) and 12042 (TCB.StatusXferd == TRUE)) { 12043 SCSI-Task-Completion(TCB); 12044 } 12045 } 12047 D.2.3. Target Algorithms 12049 Receive-a-In-PDU(Connection, CurrentPDU) 12050 { 12051 check-basic-validity(CurrentPDU); 12052 if (Header-Digest-Bad) discard, return; 12053 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12054 if (CurrentPDU.type == Data) { 12055 Retrieve TContext from CurrentPDU.TargetTransferTag; 12056 if (Data-Digest-Bad) { 12057 Build-And-Send-Reject(Connection, CurrentPDU, 12058 Payload-Digest-Error); 12059 Note the missing data PDUs in MissingDataRange[]. 12060 send-recovery-R2T = TRUE; 12061 } else { 12062 if (current DataSN is not expected) { 12063 Note the missing data PDUs in MissingDataRange[]. 12064 send-recovery-R2T = TRUE; 12065 } 12066 if (CurrentPDU.Fbit == TRUE) { 12067 if (current PDU is solicited) { 12068 Decrement TCB.ActiveR2Ts. 12069 } 12070 if ((current PDU is unsolicited and 12071 data received is less than I/O length and 12072 data received is less than 12073 FirstBurstLength) 12074 or (current PDU is solicited and the length of 12075 this burst is less than expected)) { 12076 send-recovery-R2T = TRUE; 12077 Note the missing data in MissingDataRange[]. 12078 } 12079 } 12080 } 12081 Increment TContext.ExpectedDataSN. 12082 if (send-recovery-R2T is TRUE and 12083 task is not already considered failed) { 12084 if (operational ErrorRecoveryLevel > 0) { 12085 Increment TCB.ActiveR2Ts. 12086 Create a data-descriptor for the data burst 12087 from MissingDataRange. 12088 Build-And-Send-R2T(Connection, data-descriptor, 12089 TCB); 12090 } else { 12091 if (current PDU is the last unsolicited) 12092 TCB.Reason = "Not enough unsolicited data"; 12093 else 12094 TCB.Reason = "Protocol service CRC error"; 12095 } 12096 } 12097 if (TCB.ActiveR2Ts == 0) { 12098 Build-And-Send-Status(Connection, TCB); 12099 } 12100 } else if (CurrentPDU.type == SNACK) { 12101 snack-failure = FALSE; 12102 if (operational ErrorRecoveryLevel > 0) { 12103 if (CurrentPDU.type == Data/R2T) { 12104 if (the request is satisfiable) { 12105 if (request for Data) { 12106 Create a data-descriptor for the data burst 12107 from BegRun and RunLength. 12108 Build-And-Send-A-Data-Burst(Connection, 12109 data-descriptor, TCB); 12110 } else { /* R2T */ 12111 Create a data-descriptor for the data burst 12112 from BegRun and RunLength. 12113 Build-And-Send-R2T(Connection, data- 12114 descriptor, 12115 TCB); 12116 } 12117 } else { 12118 snack-failure = TRUE; 12119 } 12120 } else if (CurrentPDU.type == status) { 12121 Handle-Status-SNACK-request(Connection, 12122 CurrentPDU); 12123 } else if (CurrentPDU.type == DataACK) { 12124 Consider all data upto CurrentPDU.BegRun as 12125 acknowledged. 12126 Free up the retransmission resources for that data. 12127 } else if (CurrentPDU.type == R-Data SNACK) { 12128 Create a data descriptor for a data burst 12129 covering 12130 all unacknowledged data. 12131 Build-And-Send-A-Data-Burst(Connection, 12132 data-descriptor, TCB); 12133 TCB.SNACK_Tag = CurrentPDU.SNACK_Tag; 12134 if (there's no more data to send) { 12135 Build-And-Send-Status(Connection, TCB); 12136 } 12137 } 12138 } else { /* operational ErrorRecoveryLevel = 0 */ 12139 snack-failure = TRUE; 12140 } 12141 if (snack-failure == TRUE) { 12142 Build-And-Send-Reject(Connection, CurrentPDU, 12143 SNACK-Reject); 12144 if (TCB.StatusXferd != TRUE) { 12145 TCB.Reason = "SNACK Rejected"; 12146 Build-And-Send-Status(Connection, TCB); 12147 } 12148 } 12150 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 12151 SHOWN */ 12152 } 12153 } 12155 Transfer-Context-Timeout-Handler(TContext) 12156 { 12157 Retrieve TCB and Connection from TContext. 12158 Decrement TCB.ActiveR2Ts. 12160 if (operational ErrorRecoveryLevel > 0 and 12161 task is not already considered failed) { 12162 Note the missing data PDUs in MissingDataRange[]. 12163 Create a data-descriptor for the data burst 12164 from MissingDataRange[]. 12165 Build-And-Send-R2T(Connection, data-descriptor, TCB); 12166 } else { 12167 TCB.Reason = "Protocol service CRC error"; 12168 if (TCB.ActiveR2Ts = 0) { 12169 Build-And-Send-Status(Connection, TCB); 12170 } 12171 } 12172 } 12174 D.3. Within-connection Recovery 12175 Algorithms 12177 D.3.1. Procedure Descriptions 12179 Procedure descriptions: 12180 Recover-Status-if-Possible(transport connection, 12181 currently received PDU); 12182 Evaluate-a-StatSN(transport connection, currently received PDU); 12183 Retransmit-Command-if-Possible(transport connection, CmdSN); 12184 Build-And-Send-SSnack(transport connection); 12185 Build-And-Send-Command(transport connection, task control 12186 block); 12187 Command-Acknowledge-Timeout-Handler(task control block); 12188 Status-Expect-Timeout-Handler(transport connection); 12189 Build-And-Send-Nop-Out(transport connection); 12190 Handle-Status-SNACK-request(transport connection, status SNACK 12191 PDU); 12192 Retransmit-Status-Burst(status SNACK, task control block); 12193 Is-Acknowledged(beginning StatSN, run length); 12195 Implementation-specific tunables: 12196 InitiatorProactiveSNACKEnabled 12198 Notes: 12199 - The initiator algorithms only deal with unsolicited Nop-In 12200 PDUs for generating status SNACKs. A solicited Nop-In PDU 12201 has an assigned StatSN, which, when out of order, could 12202 trigger the out of order StatSN handling in Within-command 12203 algorithms, again leading to Recover-Status-if-Possible. 12205 - The pseudo-code shown may result in the retransmission of 12206 unacknowledged commands in more cases than necessary. This 12207 will not, however, affect the correctness of the operation 12208 because the target is required to discard the duplicate 12209 CmdSNs. 12211 - The procedure Build-And-Send-Async is defined in the 12212 Connection recovery algorithms. 12214 - The procedure Status-Expect-Timeout-Handler describes how 12215 initiators may proactively attempt to retrieve the Status if 12216 they so choose. This procedure is assumed to be triggered 12217 much before the standard ULP timeout. 12219 D.3.2. Initiator Algorithms 12221 Recover-Status-if-Possible(Connection, CurrentPDU) 12222 { 12223 if ((Connection.state == LOGGED_IN) and 12224 connection is not already considered 12225 failed) { 12226 if (operational ErrorRecoveryLevel > 0) { 12227 if (# of missing PDUs is trackable) { 12228 Note the missing StatSNs in Connection 12229 that were not already requested with SNACK; 12230 Build-And-Send-SSnack(Connection); 12231 } else { 12232 Connection.PerformConnectionCleanup = TRUE; 12233 } 12234 } else { 12235 Connection.PerformConnectionCleanup = TRUE; 12237 } 12238 if (Connection.PerformConnectionCleanup == TRUE) { 12239 Start-Timer(Connection-Cleanup-Handler, Connection, 12240 0); 12241 } 12242 } 12243 } 12245 Retransmit-Command-if-Possible(Connection, CmdSN) 12246 { 12247 if (operational ErrorRecoveryLevel > 0) { 12248 Retrieve the InitiatorTaskTag, and thus TCB for the 12249 CmdSN. 12250 Build-And-Send-Command(Connection, TCB); 12251 } 12252 } 12254 Evaluate-a-StatSN(Connection, CurrentPDU) 12255 { 12256 send-status-SNACK = FALSE; 12257 if (Connection.SoFarInOrder == TRUE) { 12258 if (current StatSN is the expected) { 12259 Increment Connection.ExpectedStatSN. 12260 } else { 12261 Connection.SoFarInOrder = FALSE; 12262 send-status-SNACK = TRUE; 12263 } 12264 } else { 12265 if (current StatSN was considered missing) { 12266 remove current StatSN from the missing list. 12267 } else { 12268 if (current StatSN is higher than expected){ 12269 send-status-SNACK = TRUE; 12270 } else { 12271 send-status-SNACK = FALSE; 12272 discard the PDU; 12273 } 12274 } 12275 Adjust Connection.ExpectedStatSN if appropriate. 12276 if (missing StatSN list is empty) { 12277 Connection.SoFarInOrder = TRUE; 12278 } 12279 } 12280 return send-status-SNACK; 12281 } 12283 Receive-a-In-PDU(Connection, CurrentPDU) 12284 { 12285 check-basic-validity(CurrentPDU); 12286 if (Header-Digest-Bad) discard, return; 12287 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12288 if (CurrentPDU.type == Nop-In) { 12289 if (the PDU is unsolicited) { 12290 if (current StatSN is not expected) { 12291 Recover-Status-if-Possible(Connection, 12292 CurrentPDU); 12293 } 12294 if (current ExpCmdSN is not Session.CmdSN) { 12295 Retransmit-Command-if-Possible(Connection, 12296 CurrentPDU.ExpCmdSN); 12297 } 12298 } 12299 } else if (CurrentPDU.type == Reject) { 12300 if (it is a data digest error on immediate data) { 12301 Retransmit-Command-if-Possible(Connection, 12303 CurrentPDU.BadPDUHeader.CmdSN); 12304 } 12305 } else if (CurrentPDU.type == Response) { 12306 send-status-SNACK = Evaluate-a-StatSN(Connection, 12307 CurrentPDU); 12308 if (send-status-SNACK == TRUE) 12309 Recover-Status-if-Possible(Connection, CurrentPDU); 12310 } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY, 12311 * NOT SHOWN */ 12312 } 12313 } 12315 Command-Acknowledge-Timeout-Handler(TCB) 12316 { 12317 Retrieve the Connection for TCB. 12318 Retransmit-Command-if-Possible(Connection, TCB.CmdSN); 12319 } 12321 Status-Expect-Timeout-Handler(Connection) 12322 { 12323 if (operational ErrorRecoveryLevel > 0) { 12324 Build-And-Send-Nop-Out(Connection); 12325 } else if (InitiatorProactiveSNACKEnabled){ 12326 if ((Connection.state == LOGGED_IN) and 12327 connection is not already considered 12328 failed) { 12329 Build-And-Send-SSnack(Connection); 12330 } 12331 } 12332 } 12334 E.3.3 Target Algorithms 12336 Handle-Status-SNACK-request(Connection, CurrentPDU) 12337 { 12338 if (operational ErrorRecoveryLevel > 0) { 12339 if (request for an acknowledged run) { 12340 Build-And-Send-Reject(Connection, CurrentPDU, 12341 Protocol-Error); 12342 } else if (request for an untransmitted run) { 12343 discard, return; 12344 } else { 12345 Retransmit-Status-Burst(CurrentPDU, TCB); 12346 } 12347 } else { 12348 Build-And-Send-Async(Connection, DroppedConnection, 12349 DefaultTime2Wait, 12350 DefaultTime2Retain); 12351 } 12352 } 12353 D.4. Connection Recovery Algorithms 12355 D.4.1. Procedure Descriptions 12357 Build-And-Send-Async(transport connection, reason code, 12358 minimum time, maximum time); 12359 Pick-A-Logged-In-Connection(session); 12360 Build-And-Send-Logout(transport connection, logout connection 12361 identifier, reason code); 12362 PerformImplicitLogout(transport connection, logout connection 12363 identifier, target information); 12364 PerformLogin(transport connection, target information); 12365 CreateNewTransportConnection(target information); 12366 Build-And-Send-Command(transport connection, task control 12367 block); 12368 Connection-Cleanup-Handler(transport connection); 12369 Connection-Resource-Timeout-Handler(transport connection); 12370 Quiesce-And-Prepare-for-New-Allegiance(session, task control 12371 block); 12372 Build-And-Send-Logout-Response(transport connection, 12373 CID of connection in recovery, reason 12374 code); 12375 Build-And-Send-TaskMgmt-Response(transport connection, 12376 task mgmt command PDU, response code); 12377 Establish-New-Allegiance(task control block, transport 12378 connection); 12379 Schedule-Command-To-Continue(task control block); 12381 Notes: 12382 - Transport exception conditions, such as unexpected 12383 connection termination, connection reset, and hung 12384 connection while the connection is in the full-feature 12385 phase, are all assumed to be asynchronously signaled to the 12386 iSCSI layer using the Transport_Exception_Handler procedure. 12388 D.4.2. Initiator Algorithms 12390 Receive-a-In-PDU(Connection, CurrentPDU) 12391 { 12392 check-basic-validity(CurrentPDU); 12393 if (Header-Digest-Bad) discard, return; 12394 Retrieve TCB from CurrentPDU.InitiatorTaskTag. 12395 if (CurrentPDU.type == Async) { 12396 if (CurrentPDU.AsyncEvent == ConnectionDropped) { 12397 Retrieve the AffectedConnection for 12398 CurrentPDU.Parameter1. 12399 AffectedConnection.CurrentTimeout = 12400 CurrentPDU.Parameter3; 12401 AffectedConnection.State = CLEANUP_WAIT; 12402 Start-Timer(Connection-Cleanup-Handler, 12403 AffectedConnection, 12404 CurrentPDU.Parameter2); 12405 } else if (CurrentPDU.AsyncEvent == LogoutRequest)) { 12406 AffectedConnection = Connection; 12407 AffectedConnection.State = LOGOUT_REQUESTED; 12408 AffectedConnection.PerformConnectionCleanup = TRUE; 12409 AffectedConnection.CurrentTimeout = 12410 CurrentPDU.Parameter3; 12411 Start-Timer(Connection-Cleanup-Handler, 12412 AffectedConnection, 0); 12413 } else if (CurrentPDU.AsyncEvent == SessionDropped)) { 12414 for (each Connection) { 12415 Connection.State = CLEANUP_WAIT; 12416 Connection.CurrentTimeout = CurrentPDU.Parameter3; 12417 Start-Timer(Connection-Cleanup-Handler, 12418 Connection, CurrentPDU.Parameter2); 12419 } 12420 Session.state = FAILED; 12421 } 12423 } else if (CurrentPDU.type == LogoutResponse) { 12424 Retrieve the CleanupConnection for CurrentPDU.CID. 12425 if (CurrentPDU.Response = failure) { 12426 CleanupConnection.State = CLEANUP_WAIT; 12427 } else { 12428 CleanupConnection.State = FREE; 12429 } 12430 } else if (CurrentPDU.type == LoginResponse) { 12431 if (this is a response to an implicit Logout) { 12432 Retrieve the CleanupConnection. 12433 if (successful) { 12434 CleanupConnection.State = FREE; 12435 Connection.State = LOGGED_IN; 12436 } else { 12437 CleanupConnection.State = CLEANUP_WAIT; 12438 DestroyTransportConnection(Connection); 12439 } 12440 } 12441 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12442 * NOT SHOWN */ 12443 } 12444 if (CleanupConnection.State == FREE) { 12445 for (each command that was active on CleanupConnection) { 12446 /* Establish new connection allegiance */ 12447 NewConnection = Pick-A-Logged-In- 12448 Connection(Session); 12449 Build-And-Send-Command(NewConnection, TCB); 12450 } 12451 } 12452 } 12454 Connection-Cleanup-Handler(Connection) 12455 { 12456 Retrieve Session from Connection. 12457 if (Connection can still exchange iSCSI PDUs) { 12458 NewConnection = Connection; 12459 } else { 12460 Start-Timer(Connection-Resource-Timeout-Handler, 12461 Connection, Connection.CurrentTimeout); 12462 if (there are other logged-in connections) { 12463 NewConnection = Pick-A-Logged-In- 12464 Connection(Session); 12465 } else { 12466 NewConnection = 12468 CreateTransportConnection(Session.OtherEndInfo); 12469 Initiate an implicit Logout on NewConnection for 12470 Connection.CID. 12471 return; 12473 } 12474 } 12475 Build-And-Send-Logout(NewConnection, Connection.CID, 12476 RecoveryRemove); 12477 } 12479 Transport_Exception_Handler(Connection) 12480 { 12481 Connection.PerformConnectionCleanup = TRUE; 12482 if (the event is an unexpected transport disconnect) { 12483 Connection.State = CLEANUP_WAIT; 12484 Connection.CurrentTimeout = DefaultTime2Retain; 12485 Start-Timer(Connection-Cleanup-Handler, Connection, 12486 DefaultTime2Wait); 12488 } else { 12489 Connection.State = FREE; 12490 } 12491 } 12493 D.4.3. Target Algorithms 12495 Receive-a-In-PDU(Connection, CurrentPDU) 12496 { 12497 check-basic-validity(CurrentPDU); 12498 if (Header-Digest-Bad) discard, return; 12499 else if (Data-Digest-Bad) { 12500 Build-And-Send-Reject(Connection, CurrentPDU, 12501 Payload-Digest-Error); 12502 discard, return; 12503 } 12504 Retrieve TCB and Session. 12505 if (CurrentPDU.type == Logout) { 12506 if (CurrentPDU.ReasonCode = RecoveryRemove) { 12507 Retrieve the CleanupConnection from CurrentPDU.CID). 12508 for (each command active on CleanupConnection) { 12509 Quiesce-And-Prepare-for-New-Allegiance(Session, 12510 TCB); 12511 TCB.CurrentlyAllegiant = FALSE; 12512 } 12513 Cleanup-Connection-State(CleanupConnection); 12514 if ((quiescing successful) and (cleanup successful)) 12515 { 12516 Build-And-Send-Logout-Response(Connection, 12517 CleanupConnection.CID, 12518 Success); 12519 } else { 12520 Build-And-Send-Logout-Response(Connection, 12521 CleanupConnection.CID, 12522 Failure); 12523 } 12524 } 12525 } else if ((CurrentPDU.type == Login) and 12526 operational ErrorRecoveryLevel == 2) { 12527 Retrieve the CleanupConnection from CurrentPDU.CID). 12528 for (each command active on CleanupConnection) { 12529 Quiesce-And-Prepare-for-New-Allegiance(Session, 12530 TCB); 12531 TCB.CurrentlyAllegiant = FALSE; 12532 } 12533 Cleanup-Connection-State(CleanupConnection); 12534 if ((quiescing successful) and (cleanup successful)) 12535 { 12536 Continue with the rest of the Login processing; 12537 } else { 12538 Build-And-Send-Login-Response(Connection, 12539 CleanupConnection.CID, Target 12540 Error); 12541 } 12542 } 12543 } else if (CurrentPDU.type == TaskManagement) { 12544 if (CurrentPDU.function == "TaskReassign") { 12545 if (Session.ErrorRecoveryLevel < 2) { 12546 Build-And-Send-TaskMgmt-Response(Connection, 12547 CurrentPDU, "Allegiance reassignment 12548 not supported"); 12549 } else if (task is not found) { 12550 Build-And-Send-TaskMgmt-Response(Connection, 12551 CurrentPDU, "Task not in task set"); 12552 } else if (task is currently allegiant) { 12553 Build-And-Send-TaskMgmt-Response(Connection, 12554 CurrentPDU, "Task still allegiant"); 12555 } else { 12556 Establish-New-Allegiance(TCB, Connection); 12557 TCB.CurrentlyAllegiant = TRUE; 12558 Schedule-Command-To-Continue(TCB); 12559 } 12560 } 12561 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12562 * NOT SHOWN */ 12563 } 12564 } 12566 Transport_Exception_Handler(Connection) 12567 { 12568 Connection.PerformConnectionCleanup = TRUE; 12569 if (the event is an unexpected transport disconnect) { 12570 Connection.State = CLEANUP_WAIT; 12571 Start-Timer(Connection-Resource-Timeout-Handler, 12572 Connection, 12574 (DefaultTime2Wait+DefaultTime2Retain)); 12575 if (this Session has full-feature phase connections 12576 left) { 12577 DifferentConnection = 12578 Pick-A-Logged-In-Connection(Session); 12579 Build-And-Send-Async(DifferentConnection, 12580 DroppedConnection, DefaultTime2Wait, 12581 DefaultTime2Retain); 12582 } 12583 } else { 12584 Connection.State = FREE; 12585 } 12586 } 12587 Appendix E. Clearing Effects of Various Events on Targets 12589 E.1. Clearing Effects on iSCSI Objects 12591 The following tables describe the target behavior on receiving the 12592 events specified in the rows of the table. The second table is 12594 an extension of the first table and defines clearing actions for 12595 more objects on the same events. The legend is: 12597 Y = Yes (cleared/discarded/reset on the event specified in 12598 the row). Unless otherwise noted, the clearing action is 12599 only applicable for the issuing initiator port. 12601 N = No (not affected on the event specified in the row, 12602 i.e., stays at previous value). 12604 NA = Not Applicable or Not Defined. 12606 +-----+-----+-----+-----+-----+ 12607 |IT(1)|IC(2)|CT(5)|ST(6)|PP(7)| 12608 +---------------------+-----+-----+-----+-----+-----+ 12609 |connection failure(8)|Y |Y |N |N |Y | 12610 +---------------------+-----+-----+-----+-----+-----+ 12611 |connection state |NA |NA |Y |N |NA | 12612 |timeout (9) | | | | | | 12613 +---------------------+-----+-----+-----+-----+-----+ 12614 |session timeout/ |Y |Y |Y |Y |Y(14)| 12615 |closure/reinstatement| | | | | | 12616 |(10) | | | | | | 12617 +---------------------+-----+-----+-----+-----+-----+ 12618 |session continuation |NA |NA |N(11)|N |NA | 12619 |(12) | | | | | | 12620 +---------------------+-----+-----+-----+-----+-----+ 12621 |successful connection|Y |Y |Y |N |Y(13)| 12622 |close logout | | | | | | 12623 +---------------------+-----+-----+-----+-----+-----+ 12624 |session failure (18) |Y |Y |N |N |Y | 12625 +---------------------+-----+-----+-----+-----+-----+ 12626 |successful recovery |Y |Y |N |N |Y(13)| 12627 |Logout | | | | | | 12628 +---------------------+-----+-----+-----+-----+-----+ 12629 |failed Logout |Y |Y |N |N |Y | 12630 +---------------------+-----+-----+-----+-----+-----+ 12631 |connection Login |NA |NA |NA |Y(15)|NA | 12632 |(leading) | | | | | | 12633 +---------------------+-----+-----+-----+-----+-----+ 12634 |connection Login |NA |NA |N(11)|N |Y | 12635 |(non-leading) | | | | | | 12636 +---------------------+-----+-----+-----+-----+-----+ 12637 |target cold reset(16)|Y(20)|Y |Y |Y |Y | 12638 +---------------------+-----+-----+-----+-----+-----+ 12639 |target warm reset(16)|Y(20)|Y |Y |Y |Y | 12640 +---------------------+-----+-----+-----+-----+-----+ 12641 |LU reset(19) |Y(20)|Y |Y |Y |Y | 12642 +---------------------+-----+-----+-----+-----+-----+ 12643 |powercycle(16) |Y |Y |Y |Y |Y | 12644 +---------------------+-----+-----+-----+-----+-----+ 12646 1. Incomplete TTTs - Target Transfer Tags on which the target is 12647 still expecting PDUs to be received. Examples include TTTs 12648 received via R2T, NOP-IN, etc. 12650 2. Immediate Commands - immediate commands, but waiting for 12651 execution on a target. For example, Abort Task Set. 12653 5. Connection Tasks - tasks that are active on the iSCSI connection 12654 in question. 12656 6. Session Tasks - tasks that are active on the entire iSCSI 12657 session. A union of "connection tasks" on all participating 12658 connections. 12660 7. Partial PDUs (if any) - PDUs that are partially sent and waiting 12661 for transport window credit to complete the transmission. 12663 8. Connection failure is a connection exception condition - one of 12664 the transport connections shutdown, transport connections 12665 reset, or transport connections timed out, which abruptly 12666 terminated the iSCSI full-feature phase connection. A 12667 connection failure always takes the connection state machine to 12668 the CLEANUP_WAIT state. 12670 9. Connection state timeout happens if a connection spends more 12671 time than agreed upon during Login negotiation in the 12672 CLEANUP_WAIT state, and this takes the connection to the FREE 12673 state (M1 transition in connection cleanup state diagram). 12675 10.These are defined in Section 6.3.5. 12677 11.This clearing effect is "Y" only if it is a connection 12678 reinstatement and the operational ErrorRecoveryLevel is less 12679 than 2. 12681 12.Session continuation is defined in Section 6.3.5. 12683 13.This clearing effect is only valid if the connection is being 12684 logged out on a different connection and when the connection 12685 being logged out on the target may have some partial PDUs 12686 pending to be sent. In all other cases, the effect is "NA". 12687 14.This clearing effect is only valid for a "close the session" 12688 logout in a multi-connection session. In all other cases, the 12689 effect is "NA". 12690 15.Only applicable if this leading connection login is a session 12691 reinstatement. If this is not the case, it is "NA". 12692 16.This operation affects all logged-in initiators. 12693 18.Session failure is defined in Section 6.3.5. 12694 19.This operation affects all logged-in initiators and the clearing 12695 effects are only applicable to the LU being reset. 12697 20.With Standard multi-task abort semantics (Section 4.2.3.3), a 12698 target warm reset or a target cold reset or an LU reset would 12699 clear the active TTTs upon completion. However, the FastAbort 12700 multi-task abort semantics defined by Section 4.2.3.4 do not 12701 guarantee that the active TTTs are cleared by the end of the 12702 reset operations. In fact, the FastAbort semantics are designed 12703 to allow clearing the TTTs in a "lazy" fashion after the TMF 12704 Response is delivered. Thus, when TaskReporting=FastAbort 12705 (Section 13.23) is operational on a session, the clearing 12706 effects of reset operations on "Incomplete TTTs" is "N". 12708 +-----+-----+-----+-----+-----+ 12709 |DC(1)|DD(2)|SS(3)|CS(4)|DS(5)| 12710 +---------------------+-----+-----+-----+-----+-----+ 12711 |connection failure |N |Y |N |N |N | 12712 +---------------------+-----+-----+-----+-----+-----+ 12713 |connection state |Y |NA |Y |N |NA | 12714 |timeout | | | | | | 12715 +---------------------+-----+-----+-----+-----+-----+ 12716 |session timeout/ |Y |Y |Y(7) |Y |NA | 12717 |closure/reinstatement| | | | | | 12718 +---------------------+-----+-----+-----+-----+-----+ 12719 |session continuation |N(11)|NA*12|NA |N |NA*13| 12720 +---------------------+-----+-----+-----+-----+-----+ 12721 |successful connection|Y |Y |Y |N |NA | 12722 |close Logout | | | | | | 12723 +---------------------+-----+-----+-----+-----+-----+ 12724 |session failure |N |Y |N |N |N | 12725 +---------------------+-----+-----+-----+-----+-----+ 12726 |successful recovery |Y |Y |Y |N |N | 12727 |Logout | | | | | | 12728 +---------------------+-----+-----+-----+-----+-----+ 12729 |failed Logout |N |Y(9) |N |N |N | 12730 +---------------------+-----+-----+-----+-----+-----+ 12731 |connection Login |NA |NA |N(8) |N(8) |NA | 12732 |(leading | | | | | | 12733 +---------------------+-----+-----+-----+-----+-----+ 12734 |connection Login |N(11)|NA*12|N(8) |N |NA*13| 12735 |(non-leading) | | | | | | 12736 +---------------------+-----+-----+-----+-----+-----+ 12737 |target cold reset |Y |Y |Y |Y(10)|NA | 12738 +---------------------+-----+-----+-----+-----+-----+ 12739 |target warm reset |Y |Y |N |N |NA | 12740 +---------------------+-----+-----+-----+-----+-----+ 12741 |LU reset |N |Y |N |N |N | 12742 +---------------------+-----+-----+-----+-----+-----+ 12743 |powercycle |Y |Y |Y |Y(10)|NA | 12744 +---------------------+-----+-----+-----+-----+-----+ 12746 1. Discontiguous Commands - commands allegiant to the connection 12747 in question and waiting to be reordered in the iSCSI layer. All 12748 "Y"s in this column assume that the task causing the event (if 12749 indeed the event is the result of a task) is issued as an 12750 immediate command, because the discontiguities can be ahead of the 12751 task. 12753 2. Discontiguous Data - data PDUs received for the task in 12754 question and waiting to be reordered due to prior discontiguities 12755 in DataSN. 12757 3. StatSN 12759 4. CmdSN 12761 5. DataSN 12763 7. It clears the StatSN on all the connections. 12765 8. This sequence number is instantiated on this event. 12767 9. A logout failure drives the connection state machine to the 12768 CLEANUP_WAIT state, similar to the connection failure event. 12769 Hence, it has a similar effect on this and several other protocol 12770 aspects. 12772 10. This is cleared by virtue of the fact that all sessions with 12773 all initiators are terminated. 12775 11. This clearing effect is "Y" if it is a connection 12776 reinstatement. 12778 12. This clearing effect is "Y" only if it is a connection 12779 reinstatement and the operational ErrorRecoveryLevel is 2. 12781 13. This clearing effect is "N" only if it is a connection 12782 reinstatement and the operational ErrorRecoveryLevel is 2. 12784 E.2. Clearing Effects on SCSI Objects 12786 The only iSCSI protocol action that can effect clearing actions on 12787 SCSI objects is the "I_T nexus loss" notification (Section 6.3.5.1 12788 Loss of Nexus notification). [SPC3] describes the clearing effects 12789 of this notification on a variety of SCSI attributes. In addition, 12790 SCSI standards documents (such as [SAM2] and [SBC]) define 12791 additional clearing actions that may take place for several SCSI 12792 objects on SCSI events such as LU resets and power-on resets. 12794 Since iSCSI defines a target cold reset as a protocol-equivalent 12795 to a target power-cycle, the iSCSI target cold reset must also be 12796 considered as the power-on reset event in interpreting the actions 12797 defined in the SCSI standards. 12799 When the iSCSI session is reconstructed (between the same SCSI 12800 ports with the same nexus identifier) reestablishing the same I_T 12801 nexus, all SCSI objects that are defined to not clear on the "I_T 12802 nexus loss" notification event, such as persistent reservations, 12803 are automatically associated to this new session. 12805 Acknowledgments 12807 Several individuals on the original IPS Working Group made 12808 significant contributions to the original RFCs 3720, 3980, 4850 12809 and 5048. 12811 Specifically, the authors of the original RFCs - which this draft 12812 consolidates into a single document - were the following: 12814 RFC 3720: Julian Satran, Kalman Meth, Costa Sapuntzakis, 12815 Mallikarjun Chadalapaka, Efri Zeidner 12817 RFC 3980: Marjorie Krueger, Mallikarjun Chadalapaka, Rob Elliott 12819 RFC 4850: David Wysochanski 12821 RFC 5048: Mallikarjun Chadalapaka 12823 Many thanks to Fred Knight for contributing to the UML notations 12824 and drawings in this draft. 12826 We would in addition like to acknowledge the following individuals 12827 who contributed to this revised draft: David Black, David 12828 Harrington, Paul Koning, Mark Edwards. 12830 Authors' Addresses 12832 Mallikarjun Chadalapaka 12833 Microsoft 12834 One Microsoft Way 12835 Redmond WA 98052 USA 12836 E-mail: cbm@chadalapaka.com 12838 Julian Satran 12839 Infinidat Ltd. 12840 E-mail: julians@infinidat.com, julian@satran.net 12842 Kalman Meth 12843 IBM Haifa Research Lab 12844 Haifa University Campus - Mount Carmel 12845 Haifa 31905, Israel 12846 Phone +972.4.829.6341 12847 E-mail: meth@il.ibm.com 12849 David L. Black, 12850 EMC Corporation, 12851 176 South St., Hopkinton, MA 01748 12852 Phone +1 (508) 293-7953 12853 Email: david.black@emc.com 12855 Comments may be sent to Mallikarjun Chadalapaka 12857 Acknowledgement 12859 Funding for the RFC Editor function is currently provided by the 12860 Internet Society