idnits 2.17.1 draft-ietf-storm-iscsi-cons-06.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 2 instances 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 2888 -- Looks like a reference, but probably isn't: '0' on line 6771 -- Looks like a reference, but probably isn't: '7' on line 6771 == Missing Reference: 'RFC 4850' is mentioned on line 10833, but not defined ** Obsolete undefined reference: RFC 4850 (Obsoleted by RFC 7143) == Missing Reference: 'RFCyyyy' is mentioned on line 10922, but not defined == Missing Reference: 'MaxMissingDPDU' is mentioned on line 11960, but not defined == Missing Reference: 'MaxOutStandingR2T' is mentioned on line 11968, but not defined == Missing Reference: 'MaxMissingSPDU' is mentioned on line 11981, but not defined == Missing Reference: 'MaxSupportedConns' is mentioned on line 11991, but not defined == Unused Reference: 'RFC4850' is defined on line 11098, 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 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. 'SBC2' -- 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 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 (~~), 10 warnings (==), 31 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-06.txt 4 Intended status: Proposed Standard Julian Satran 5 Expires: January 2013 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 January 15, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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. Acronyms, Definitions and Document Summary...................... 15 75 2.1. Acronyms .................................................... 15 76 2.2. Definitions ................................................. 17 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 ............................................... 26 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 ............................ 35 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 ....... 42 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 .............................................51 111 4.2.5. iSCSI Full Feature Phase ................................52 112 4.2.5.1. Command Connection Allegiance .......................53 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 .....................................56 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 ...............................74 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 ............ 108 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 Targets136 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 Targets147 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 Extension Key Format ........................283 408 13.23. TaskReporting ...........................................283 409 13.24. iSCSIProtocolLevel Negotiation ..........................284 410 13.25. Obsoleted Keys ..........................................284 411 13.26. X#NodeArchitecture ......................................285 412 13.26.1. Definition ..........................................285 413 13.26.2. Implementation Requirements .........................286 414 14. Rationale for revised IANA Considerations..................... 287 416 15. IANA Considerations........................................... 289 418 Appendix A. Examples ............................................. 295 419 Read Operation Example .........................................295 420 Write Operation Example ........................................296 421 R2TSN/DataSN Use Examples ......................................296 422 CRC Examples ...................................................300 423 Appendix B. Login Phase Examples ................................. 302 425 Appendix C. SendTargets Operation ................................ 312 426 Appendix D. Algorithmic Presentation of Error Recovery Classes ... 317 427 D.2.1. Procedure Descriptions ................................. 320 428 Appendix E. Clearing Effects of Various Events on Targets ........ 336 429 1. Introduction 431 The Small Computer Systems Interface (SCSI) is a popular family of 432 protocols for communicating with I/O devices, especially storage 433 devices. SCSI is a client-server architecture. Clients of a SCSI 434 interface are called "initiators". Initiators issue SCSI 435 "commands" to request services from components, logical units of a 436 server known as a "target". A "SCSI transport" maps the client- 437 server SCSI protocol to a specific interconnect. An Initiator is 438 one endpoint of a SCSI transport and a target is the other 439 endpoint. 441 The SCSI protocol has been mapped over various transports, 442 including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre 443 Channel. These transports are I/O specific and have limited 444 distance capabilities. 446 The iSCSI protocol defined in this document describes a means of 447 transporting of the SCSI packets over TCP/IP, providing for an 448 interoperable solution which can take advantage of existing 449 Internet infrastructure, Internet management facilities and 450 address distance limitations. 452 2. Acronyms, Definitions and Document Summary 454 2.1. Acronyms 456 Acronym Definition 457 -------------------------------------------------------------- 458 3DES Triple Data Encryption Standard 459 ACA Auto Contingent Allegiance 460 AEN Asynchronous Event Notification 461 AES Advanced Encryption Standard 462 AH Additional Header (not the IPsec AH!) 463 AHS Additional Header Segment 464 API Application Programming Interface 465 ASC Additional Sense Code 466 ASCII American Standard Code for Information Interchange 467 ASCQ Additional Sense Code Qualifier 468 BHS Basic Header Segment 469 CBC Cipher Block Chaining 470 CD Compact Disk 471 CDB Command Descriptor Block 472 CHAP Challenge Handshake Authentication Protocol 473 CID Connection ID 474 CO Connection Only 475 CRC Cyclic Redundancy Check 476 CRL Certificate Revocation List 477 CSG Current Stage 478 CSM Connection State Machine 479 DES Data Encryption Standard 480 DNS Domain Name Server 481 DOI Domain of Interpretation 482 DVD Digital Versatile Disk 483 EDTL Expected Data Transfer Length 484 ESP Encapsulating Security Payload 485 EUI Extended Unique Identifier 486 FFP Full Feature Phase 487 FFPO Full Feature Phase Only 488 Gbps Gigabits per Second 489 HBA Host Bus Adapter 490 HMAC Hashed Message Authentication Code 491 I_T Initiator_Target 493 I_T_L Initiator_Target_LUN 494 IANA Internet Assigned Numbers Authority 495 IB InfiniBand 496 ID Identifier 497 IDN Internationalized Domain Name 498 IEEE Institute of Electrical & Electronics Engineers 499 IETF Internet Engineering Task Force 500 IKE Internet Key Exchange 501 I/O Input-Output 502 IO Initialize Only 503 IP Internet Protocol 504 IPsec Internet Protocol Security 505 IPv4 Internet Protocol Version 4 506 IPv6 Internet Protocol Version 6 507 IQN iSCSI Qualified Name 508 iSCSI Internet SCSI 509 iSER iSCSI Extensions for RDMA 510 ISID Initiator Session ID 511 iSNS Internet Storage Name Service (see [RFC4171]) 512 ITN iSCSI Target Name 513 ITT Initiator Task Tag 514 KRB5 Kerberos V5 515 LFL Lower Functional Layer 516 LTDS Logical-Text-Data-Segment 517 LO Leading Only 518 LU Logical Unit 519 LUN Logical Unit Number 520 MAC Message Authentication Codes 521 NA Not Applicable 522 NAA Network Address Authority 523 NIC Network Interface Card 524 NOP No Operation 525 NSG Next Stage 526 OS Operating System 527 PDU Protocol Data Unit 528 PKI Public Key Infrastructure 529 R2T Ready To Transfer 530 R2TSN Ready To Transfer Sequence Number 531 RDMA Remote Direct Memory Access 532 RFC Request For Comments 533 SAM SCSI Architecture Model 534 SAM2 SCSI Architecture Model - 2 535 SAN Storage Area Network 536 SAS Serial Attached SCSI 537 SCSI Small Computer Systems Interface 538 SN Sequence Number 539 SNACK Selective Negative Acknowledgment - also 540 Sequence Number Acknowledgement for data 541 SPDTL SCSI-Presented Data Transfer Length 542 SPKM Simple Public-Key Mechanism 543 SRP Secure Remote Password, also SCSI RDMA Protocol 544 SSID Session ID 545 SW Session-Wide 546 TCB Task Control Block 547 TCP Transmission Control Protocol 548 TMF Task Management Function 549 TPGT Target Portal Group Tag 550 TSIH Target Session Identifying Handle 551 TTT Target Transfer Tag 552 UA Unit Attention 553 UFL Upper Functional Layer 554 ULP Upper Level Protocol 555 URN Uniform Resource Names 556 UTF Universal Transformation Format 557 WG Working Group 559 2.2. Definitions 561 - Alias: An alias string can also be associated with an iSCSI 562 Node. The alias allows an organization to associate a user- 563 friendly string with the iSCSI Name. However, the alias string is 564 not a substitute for the iSCSI Name. 566 - CID (Connection ID): Connections within a session are identified 567 by a connection ID. It is a unique ID for this connection within 568 the session for the initiator. It is generated by the initiator 569 and presented to the target during login requests and during 570 logouts that close connections. 572 - Connection: A connection is a TCP connection. Communication 573 between the initiator and target occurs over one or more TCP 574 connections. The TCP connections carry control messages, SCSI 576 commands, parameters, and data within iSCSI Protocol Data Units 577 (iSCSI PDUs). 579 - I/O Buffer:A buffer that is used in a SCSI Read or Write 580 operation so SCSI data may be sent from or received into that 581 buffer. For a read or write data transfer to take place for a 582 task, an I/O Buffer is required on the initiator and at least one 583 is required on the 584 target. 586 - INCITS: INCITS stands for InterNational Committee of Information 587 Technology Standards. The INCITS has a broad standardization scope 588 within the field of Information and Communications Technologies 589 (ICT), encompassing storage, processing, transfer, display, 590 management, organization, and retrieval of information. INCITS 591 serves as ANSI's Technical Advisory Group for the ISO/IEC Joint 592 Technical Committee 1 (JTC 1). See http://www.incits.org. 594 - InfiniBand: An I/O architecture originally intended to replace 595 PCI and to address high performance server interconnectivity [IB]. 597 - iSCSI Device: A SCSI Device using an iSCSI service delivery 598 subsystem. Service Delivery Subsystem is defined by [SAM2] as a 599 transport mechanism for SCSI commands and responses. 601 - iSCSI Initiator Name: The iSCSI Initiator Name specifies the 602 worldwide unique name of the initiator. 604 - iSCSI Initiator Node: The "initiator" device. The word 605 "initiator" has been appropriately qualified as either a port or a 606 device in the rest of the document when the context is ambiguous. 607 All unqualified usages of "initiator" refer to an initiator port 608 (or device) depending on the context. 610 - iSCSI Layer: This layer builds/receives iSCSI PDUs and 611 relays/receives them to/from one or more TCP connections that form 612 an initiator-target "session". 614 - iSCSI Name: The name of an iSCSI initiator or iSCSI target. 616 - iSCSI Node: The iSCSI Node represents a single iSCSI initiator 617 or iSCSI target or a single instance of each. There are one or 618 more iSCSI Nodes within a Network Entity. The iSCSI Node is 619 accessible via one or more Network Portals. An iSCSI Node is 620 identified by its iSCSI Name. The separation of the iSCSI Name 621 from the addresses used by and for the iSCSI Node allows multiple 622 iSCSI nodes to use the same address, and the same iSCSI node to 623 use multiple addresses. 625 - iSCSI Target Name: The iSCSI Target Name specifies the worldwide 626 unique name of the target. 628 - iSCSI Target Node: The "target" device. The word "target" has 629 been appropriately qualified as either a port or a device in the 630 rest of the document when the context is ambiguous. All 631 unqualified usages of "target" refer to a target port (or device) 632 depending on the context. 634 - iSCSI Task: An iSCSI task is an iSCSI request for which a 635 response is expected. 637 - iSCSI Transfer Direction: The iSCSI transfer direction is 638 defined with regard to the initiator. Outbound or outgoing 639 transfers are transfers from the initiator to the target, while 640 inbound or incoming transfers are from the target to the 641 initiator. 643 - ISID: The initiator part of the Session Identifier. It is 644 explicitly specified by the initiator during Login. 646 - I_T nexus: According to [SAM2], the I_T nexus is a relationship 647 between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, 648 this relationship is a session, defined as a relationship between 649 an iSCSI Initiator's end of the session (SCSI Initiator Port) and 650 the iSCSI Target's Portal Group. The I_T nexus can be identified 651 by the conjunction of the SCSI port names; that is, the I_T nexus 652 identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI 653 Target Name + ',t,'+ Portal Group Tag). 655 - NAA: Network Address Authority, a naming format defined by the 656 INCITS T11 Fibre Channel protocols [FC-FS]. 658 - Network Entity: The Network Entity represents a device or 659 gateway that is accessible from the IP network. A Network Entity 660 must have one or more Network Portals, each of which can be used 661 to gain access to the IP network by some iSCSI Nodes contained in 662 that Network Entity. 664 - Network Portal: The Network Portal is a component of a Network 665 Entity that has a TCP/IP network address and that may be used by 666 an iSCSI Node within that Network Entity for the connection(s) 667 within one of its iSCSI sessions. A Network Portal in an initiator 668 is identified by its IP address. A Network Portal in a target is 669 identified by its IP address and its listening TCP port. 671 - Originator: In a negotiation or exchange, the party that 672 initiates the negotiation or exchange. 674 - PDU (Protocol Data Unit): The initiator and target divide their 675 communications into messages. The term "iSCSI protocol data unit" 676 (iSCSI PDU) is used for these messages. 678 - Portal Groups: iSCSI supports multiple connections within the 679 same session; some implementations will have the ability to 680 combine connections in a session across multiple Network Portals. 681 A Portal Group defines a set of Network Portals within an iSCSI 682 Network Entity that collectively supports the capability of 683 coordinating a session with connections spanning these portals. 684 Not all Network Portals within a Portal Group need participate in 685 every session connected through that Portal Group. One or more 686 Portal Groups may provide access to an iSCSI Node. Each Network 687 Portal, as utilized by a given iSCSI Node, belongs to exactly one 688 portal group within that node. 690 - Portal Group Tag: This 16-bit quantity identifies a Portal Group 691 within an iSCSI Node. All Network Portals with the same portal 692 group tag in the context of a given iSCSI Node are in the same 693 Portal Group. 695 - Recovery R2T: An R2T generated by a target upon detecting the 696 loss of one or more Data-Out PDUs through one of the following 697 means: a digest error, a sequence error, or a sequence reception 698 timeout. A recovery R2T carries the next unused R2TSN, but 699 requests all or part of the data burst that an earlier R2T (with a 700 lower R2TSN) had already requested. 702 - Responder: In a negotiation or exchange, the party that responds 703 to the originator of the negotiation or exchange. 705 - SAS: Serial Attached SCSI. The Serial Attached SCSI (SAS) 706 standard contains both a physical layer compatible with Serial 707 ATA, and protocols for transporting SCSI commands to SAS devices 708 and ATA commands to SATA devices [SAS]. 710 - SCSI Device: This is the SAM2 term for an entity that contains 711 one or more SCSI ports that are connected to a service delivery 712 subsystem and supports a SCSI application protocol. For example, a 713 SCSI Initiator Device contains one or more SCSI Initiator Ports 714 and zero or more application clients. A Target Device contains one 715 or more SCSI Target Ports and one or more device servers and 716 associated logical units. For iSCSI, the SCSI Device is the 717 component within an iSCSI Node that provides the SCSI 718 functionality. As such, there can be, at most, one SCSI Device 719 within a given iSCSI Node. Access to the SCSI Device can only be 720 achieved in an iSCSI normal operational session. The SCSI Device 721 Name is defined to be the iSCSI Name of the node. 723 - SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor 724 Blocks) and relays/receives them with the remaining command 725 execute [SAM2] parameters to/from the iSCSI Layer. 727 - Session: The group of TCP connections that link an initiator 728 with a target form a session (loosely equivalent to a SCSI I-T 729 nexus). TCP connections can be added and removed from a session. 730 Across all connections within a session, an initiator sees one and 731 the same target. 733 - SCSI Port: This is the SAM2 term for an entity in a SCSI Device 734 that provides the SCSI functionality to interface with a service 735 delivery subsystem. For iSCSI, the definition of the SCSI 736 Initiator Port and the SCSI Target Port are different. 738 - SCSI Initiator Port: This maps to the endpoint of an iSCSI 739 normal operational session. An iSCSI normal operational session is 740 negotiated through the login process between an iSCSI initiator 741 node and an iSCSI target node. At successful completion of this 742 process, a SCSI Initiator Port is created within the SCSI 743 Initiator Device. The SCSI Initiator Port Name and SCSI Initiator 744 Port Identifier are both defined to be the iSCSI Initiator Name 745 together with (a) a label that identifies it as an initiator port 746 name/identifier and (b) the ISID portion of the session 747 identifier. 749 - SCSI Port Name: A name made up as UTF-8 characters and includes 750 the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag. 752 - SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 753 aggregate data length of the data that the SCSI layer logically 754 "presents" to the iSCSI layer for a Data-In or Data-Out transfer 755 in the context of a SCSI task. For a bidirectional task, there are 756 two SPDTL values -- one for Data-In and one for Data-Out. Note 757 that the notion of "presenting" includes immediate data per the 758 data transfer model in [SAM2], and excludes overlapping data 759 transfers, if any, requested by the SCSI layer. 761 - SCSI Target Port: This maps to an iSCSI Target Portal Group. 763 - SCSI Target Port Name and SCSI Target Port Identifier: These are 764 both defined to be the iSCSI Target Name together with (a) a label 765 that identifies it as a target port name/identifier and (b) the 766 portal group tag. 768 - SRP: SCSI RDMA Protocol. SRP defines a SCSI protocol mapping 769 onto the InfiniBand (tm) Architecture and/or functionally similar 770 Remote DMA-capable protocols [SRP]. 772 - SSID (Session ID): A session between an iSCSI initiator and an 773 iSCSI target is defined by a session ID that is a tuple composed 774 of an initiator part (ISID) and a target part (Target Portal Group 775 Tag). The ISID is explicitly specified by the initiator at session 776 establishment. The Target Portal Group Tag is implied by the 777 initiator through the selection of the TCP endpoint at connection 778 establishment. The TargetPortalGroupTag key must also be returned 779 by the target as a confimation during connection establishment. 781 - T10: A technical committee within INCITS that develops standards 782 and technical reports on I/O interfaces, particularly the series 783 of SCSI (Small Computer Systems Interface) standards. See 784 http://www.t10.org. 786 - T11: A technical committee within INCITS responsible for 787 standards development in the areas of Intelligent Peripheral 788 Interface (IPI), High-Performance Parallel Interface (HIPPI) and 789 Fibre Channel (FC). See http://www.t11.org. 791 - Target Portal Group Tag: A numerical identifier (16-bit) for an 792 iSCSI Target Portal Group. 794 - Third-party: A term used in this document to denote nexus 795 objects (I_T or I_T_L) and iSCSI sessions that reap the side 796 effects of actions that take place in the context of a separate 797 iSCSI session, while being third parties to the action that caused 798 the side effects. One example of a third-party session is an 799 iSCSI session hosting an I_T_L nexus to an LU that is reset with 800 an LU Reset TMF via a separate I_T nexus. 802 - TSIH (Target Session Identifying Handle): A target assigned tag 803 for a session with a specific named initiator. The target 804 generates it during session establishment. Other than defining it 805 as a 16 bit binary string, its internal format and content are not 806 defined by this protocol but for the all 0 value that is reserved 807 and used by the initiator to indicate a new session. It is given 808 to the target during additional connection establishment for the 809 same session. 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 822 7) Clarified in Section 4.2.7 that implementations SHOULD NOT 823 rely on SLP-based discovery 824 8) Added UML diagrams, and related conventions in Section 3 825 9) FastAbort implementation is made a "SHOULD" requirement in 826 Section 4.2.3.4 from the previous "MUST" requirement. 827 10) Clarified in Section 6.2 that validity of NotUnderstood 828 response depends on iSCSIProtocolLevel 829 11) Required in Section 4.2.7.1 that iSCSI Target Name must be 830 the same as iSCSI Initiator Name for SCSI (composite) devices 831 with both roles 832 12) Clarified in Section 10.2 that ACA is a SHOULD requirement 833 only for iSCSI targets 834 13) Updated Section 9.3 to require the following: MUST implement 835 IPsec, 2400-series RFCs (IPsec v2, IKEv1) and SHOULD implement 836 IPsec, 4300-series RFCs (IPsec v3, IKEv2). 837 14) Prohibited usage of X# name prefix for new public keys in 838 Section 6.2 839 15) Prohibited usage of Y# name prefix for new digest extensions 840 in Section 13.1, and Z# name prefix for new authentication 841 method extensions in Section 12.1 842 16) Added a SHOULD requirement in Section 6.2 that initiators and 843 targets support at least six (6) exchanges during text 844 negotiation. 845 17) Added a clarification that Appendix.C is normative. 847 2.4. Conventions 849 In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator 850 and target respectively. 852 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 853 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 854 in this document are to be interpreted as described in RFC 2119 855 [RFC2119]. 857 iSCSI messages - PDUs - are represented by diagrams as in the 858 following example: 860 Byte/ 0 | 1 | 2 | 3 861 | 862 / | | | 863 | 864 |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| 865 +---------------+---------------+---------------+---------------+ 866 0| Basic Header Segment (BHS) | 867 +---------------+---------------+---------------+---------------+ 868 ---------- 869 +| | 870 +---------------+---------------+---------------+---------------+ 872 The diagrams include byte and bit numbering. 874 The following representation and ordering rules are observed in 875 this document: 877 - Word Rule 879 - Half-word Rule 881 - Byte Rule 883 2.4.1. Word Rule 885 A word holds four consecutive bytes. Whenever a word has numeric 886 content, it is considered an unsigned number in base 2 positional 887 representation with the lowest numbered byte (e.g., byte 0) bit 0 888 representing 2**31 and bit 1 representing 2**30 through lowest 889 numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0. 891 Decimal and hexadecimal representation of word values map this 892 representation to decimal or hexadecimal positional notation. 894 2.4.2. Half-Word Rule 896 A half-word holds two consecutive bytes. Whenever a half-word has 897 numeric content it is considered an unsigned number in base 2 898 positional representation with the lowest numbered byte (e.g., 899 byte 0) bit 0 representing 2**15 and bit 1 representing 2**14 900 through lowest numbered byte + 1 (e.g., byte 1) bit 7 representing 901 2**0. 903 Decimal and hexadecimal representation of half-word values map 904 this representation to decimal or hexadecimal positional notation. 906 2.4.3. Byte Rule 908 For every PDU, bytes are sent and received in increasing numbered 909 order (network order). 911 Whenever a byte has numerical content it is considered an unsigned 912 number in base 2 positional representation with bit 0 representing 913 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0. 915 3. UML Conventions 917 3.1. UML Conventions Overview 919 The SCSI Architecture Model (SAM) uses class diagrams and object 920 diagrams with notation that is based on the Unified Modeling 921 Language [UML]. Therefore, this document also uses UML to model 922 the relationships for SCSI and iSCSI objects. 924 A treatise on the graphical notation used in UML is beyond the 925 scope of this document. However, given the use of ASCII drawing 926 for UML static class diagrams, a description of the notational 927 conventions used in this document is included in the remainder of 928 this section. 930 3.2. Multiplicity Notion 932 Not specified The number of instances of an attribute is not 933 specified. 935 1 One instance of the class or attribute exists. 937 0..* Zero or more instances of the class or attribute exist. 939 1..* One or more instances of the class or attribute exist. 941 0..1 Zero or one instance of the class or attribute exists. 943 n..m n to m instances of the class or attribute exist 944 (e.g., 2..8). 946 x, n..m Multiple disjoint instances of the class or 947 attribute exist (e.g., 2, 8..15). 949 3.3. Class Diagram Conventions 951 +--------------+ +--------------+ +--------------+ 952 | Class Name | | Class Name | | Class Name | 953 +--------------+ +--------------+ +--------------+ 954 | | | | 955 +--------------+ +--------------+ 956 | | 957 +--------------+ 958 The previous three diagrams are examples of a class with no 959 attributes and with no operations. 961 +-------------------+ +-------------------+ 962 | Class Name | | Class Name | 963 +-------------------+ +-------------------+ 964 | attribute 01[1] | | attribute 01[1] | 965 | attribute 02[1] | | attribute 02[1] | 966 +-------------------+ +-------------------+ 967 | | 968 +-------------------+ 969 The preceding two diagrams are examples of a class with attributes 970 and with no operations. 972 +------------------------+ 973 | Class Name | 974 +------------------------+ 975 | attribute 01[1..*] | 976 | attribute 02[1] | 977 +------------------------+ 978 | operation 01() | 979 | operation 02() | 980 +------------------------+ 981 The preceding diagram is an example of a class with attributes 982 that have a specified multiplicity and operations. 984 3.4. Class Diagram Notation for Associations 986 +-----------------+ 987 | Class A | 988 +-----------------+ association_name +-----------------+ 989 | attribute 01[1] |<------------------>| Class B | 990 | attribute 02[1] | 1..* 0..1 +-----------------+ 991 +-----------------+ | attribute 03[1] | 992 | operation 1() | +-----------------+ 993 +-----------------+ 994 The preceding diagram is an example where Class A knows about 995 Class B (i.e., read as "Class A association_name ClassB") and 996 Class B knows about Class A (i.e., read as "Class B 997 association_name Class A"). The use of association_name is 998 optional. The multiplicity notation (1..* and 0..1) indicates the 999 number of instances of the object. 1001 +--------------------+ 1002 | Class A | 1003 +--------------------+ +--------------------+ 1004 | attribute 01[1] |<-------------| Class B | 1005 | attribute 02[1] | 1 0..1 +--------------------+ 1006 +--------------------+ | attribute 03[1] | 1007 | operation 1() | +--------------------+ 1008 +--------------------+ 1009 The preceding diagram is an example where Class B knows about 1010 Class A (i.e., read as "Class B knows about Class A") but Class A 1011 does not know about Class B. 1013 +----------------------+ 1014 | Class A | 1015 +----------------------+ +--------------------+ 1016 | attribute 01[1] |----------->| Class B | 1017 | attribute 02[1] | 0..* 1 +--------------------+ 1018 +----------------------+ | attribute 03[1] | 1019 | operation 1() | +--------------------+ 1020 +----------------------+ 1021 The preceding diagram is an example where Class A knows about 1022 Class B (i.e., read as "Class A knows about Class B") but Class B 1023 does not know about Class A. 1025 3.5. Class Diagram Notation for Aggregations 1027 +---------------+ +--------------+ 1028 | Class whole |o------------| Class part | 1029 +---------------+ +--------------+ 1030 The preceding diagram is an example where Class whole is an 1031 aggregate that contains Class part and where Class part may 1032 continue to exist even if Class whole is removed (i.e., read as 1033 "the whole contains the part"). 1035 +---------------+ +--------------+ 1036 | Class whole |@------------| Class part | 1037 +---------------+ +--------------+ 1038 The preceding diagram is an example where Class whole is an 1039 aggregate that contains Class part where Class part shall only 1040 belong to one Class whole, and the Class part shall not continue 1041 to exist if the Class whole is removed (i.e., read as "the whole 1042 contains the part"). 1044 +-------------+ 1045 | | 1046 +-------------+ 1047 | | 1048 + =(a)= + 1049 | | 1050 The preceding diagram is an example where there is a constraint 1051 between the associations where the (a) footnote describes the 1052 constraint. 1054 3.6. Class Diagram Notation for Generalizations 1056 +---------------+ 1057 | Superclass | 1058 +-------^-------+ 1059 /_\ 1060 | 1061 +---------------+ 1062 | Subclass | 1063 +---------------+ 1064 The preceding diagram is an example where the subclass is a kind 1065 of superclass. A subclass shares all the attributes and 1066 operations of the superclass (i.e., the subclass inherits from the 1067 superclass). 1069 4. Overview 1071 4.1. SCSI Concepts 1073 The SCSI Architecture Model-2 [SAM2] describes in detail the 1074 architecture of the SCSI family of I/O protocols. This Section 1075 provides a brief background of the SCSI architecture and is 1076 intended to familiarize readers with its terminology. 1078 At the highest level, SCSI is a family of interfaces for 1079 requesting services from I/O devices, including hard drives, tape 1080 drives, CD and DVD drives, printers, and scanners. In SCSI 1081 terminology, an individual I/O device is called a "logical unit" 1082 (LU). 1084 SCSI is a client-server architecture. Clients of a SCSI interface 1085 are called "initiators". Initiators issue SCSI "commands" to 1086 request services from components, logical units, of a server known 1087 as a "target". The "device server" on the logical unit accepts 1088 SCSI commands and processes them. 1090 A "SCSI transport" maps the client-server SCSI protocol to a 1091 specific interconnect. Initiator is one endpoint of a SCSI 1092 transport. The "target" is the other endpoint. A target can 1093 contain multiple Logical Units (LUs). Each Logical Unit has an 1094 address within a target called a Logical Unit Number (LUN). 1096 A SCSI task is a SCSI command or possibly a linked set of SCSI 1097 commands. Some LUs support multiple pending (queued) tasks, but 1098 the queue of tasks is managed by the logical unit. The target uses 1099 an initiator provided "task tag" to distinguish between tasks. 1100 Only one command in a task can be outstanding at any given time. 1102 Each SCSI command results in an optional data phase and a required 1103 response phase. In the data phase, information can travel from the 1104 initiator to target (e.g., WRITE), target to initiator (e.g., 1105 READ), or in both directions. In the response phase, the target 1106 returns the final status of the operation, including any errors. 1108 Command Descriptor Blocks (CDB) are the data structures used to 1109 contain the command parameters that an initiator sends to a 1111 target. The CDB content and structure is defined by [SAM2] and 1112 device-type specific SCSI standards. 1114 4.2. iSCSI Concepts and Functional Overview 1116 The iSCSI protocol is a mapping of the SCSI command, event and 1117 task management model (see [SAM2]) over the TCP protocol. SCSI 1118 commands are carried by iSCSI requests and SCSI responses and 1119 status are carried by iSCSI responses. iSCSI also uses the request 1120 response mechanism for iSCSI protocol mechanisms. 1122 For the remainder of this document, the terms "initiator" and 1123 "target" refer to "iSCSI initiator node" and "iSCSI target node", 1124 respectively (see iSCS) unless otherwise qualified. 1126 In keeping with similar protocols, the initiator and target divide 1127 their communications into messages. This document uses the term 1128 "iSCSI protocol data unit" (iSCSI PDU) for these messages. 1130 For performance reasons, iSCSI allows a "phase-collapse". A 1131 command and its associated data may be shipped together from 1132 initiator to target, and data and responses may be shipped 1133 together from targets. 1135 The iSCSI transfer direction is defined with respect to the 1136 initiator. Outbound or outgoing transfers are transfers from an 1137 initiator to a target, while inbound or incoming transfers are 1138 from a target to an initiator. 1140 An iSCSI task is an iSCSI request for which a response is 1141 expected. 1143 In this document "iSCSI request", "iSCSI command", request, or 1144 (unqualified) command have the same meaning. Also, unless 1145 otherwise specified, status, response, or numbered response have 1146 the same meaning. 1148 4.2.1. Layers and Sessions 1150 The following conceptual layering model is used to specify 1151 initiator and target actions and the way in which they relate to 1152 transmitted and received Protocol Data Units: 1154 the SCSI layer builds/receives SCSI CDBs (Command Descriptor 1155 Blocks) and passes/receives them with the remaining command 1156 execute parameters ([SAM2]) to/from 1157 the iSCSI layer that builds/receives iSCSI PDUs and 1158 relays/receives them to/from one or more TCP connections; 1159 the group of connections form an initiator-target 1160 "session". 1162 Communication between the initiator and target occurs over one or 1163 more TCP connections. The TCP connections carry control messages, 1164 SCSI commands, parameters, and data within iSCSI Protocol Data 1165 Units (iSCSI PDUs). The group of TCP connections that link an 1166 initiator with a target form a session (equivalent to a SCSI I_T 1167 nexus, see Section 4.4.2). A session is defined by a session ID 1168 that is composed of an initiator part and a target part. TCP 1169 connections can be added and removed from a session. Each 1170 connection within a session is identified by a connection ID 1171 (CID). 1173 Across all connections within a session, an initiator sees one 1174 "target image". All target identifying elements, such as LUN, are 1175 the same. A target also sees one "initiator image" across all 1176 connections within a session. Initiator-identifying elements, such 1177 as the Initiator Task Tag, are global across the session 1178 regardless of the connection on which they are sent or received. 1180 iSCSI targets and initiators MUST support at least one TCP 1181 connection and MAY support several connections in a session. For 1182 error recovery purposes, targets and initiators that support a 1183 single active connection in a session SHOULD support two 1184 connections during recovery. 1186 4.2.2. Ordering and iSCSI Numbering 1188 iSCSI uses Command and Status numbering schemes and a Data 1189 sequencing scheme. 1191 Command numbering is session-wide and is used for ordered command 1192 delivery over multiple connections. It can also be used as a 1193 mechanism for command flow control over a session. 1195 Status numbering is per connection and is used to enable missing 1196 status detection and recovery in the presence of transient or 1197 permanent communication errors. 1199 Data sequencing is per command or part of a command (R2T-triggered 1200 sequence) and is used to detect missing data and/or R2T PDUs due 1201 to header digest errors. 1203 Typically, fields in the iSCSI PDUs communicate the Sequence 1204 Numbers between the initiator and target. During periods when 1205 traffic on a connection is unidirectional, iSCSI NOP-Out/In PDUs 1206 may be utilized to synchronize the command and status ordering 1207 counters of the target and initiator. 1209 The iSCSI session abstraction is equivalent to the SCSI I_T nexus, 1210 and the iSCSI session provides an ordered command delivery from 1211 the SCSI initiator to the SCSI target. For detailed design 1212 considerations that led to the iSCSI session model as it is 1213 defined here and how it relates the SCSI command ordering features 1214 defined in SCSI specifications to the iSCSI concepts see 1215 [RFC3783]. 1217 4.2.2.1. Command Numbering and Acknowledging 1219 iSCSI performs ordered command delivery within a session. All 1220 commands (initiator-to-target PDUs) in transit from the initiator 1221 to the target are numbered. 1223 iSCSI considers a task to be instantiated on the target in 1224 response to every request issued by the initiator. A set of task 1225 management operations including abort and reassign (see Section 1226 11.5) may be performed on an iSCSI task - however an abort 1227 operation may not be performed on a task management operation, and 1228 usage of reassign operation has certain constraints. See Section 1229 11.5.1 for the details. 1231 Some iSCSI tasks are SCSI tasks, and many SCSI activities are 1232 related to a SCSI task ([SAM2]). In all cases, the task is 1233 identified by the Initiator Task Tag for the life of the task. 1235 The command number is carried by the iSCSI PDU as CmdSN (Command- 1236 Sequence-Number). The numbering is session-wide. Outgoing iSCSI 1237 PDUs carry this number. The iSCSI initiator allocates CmdSNs with 1238 a 32-bit unsigned counter (modulo 2**32). Comparisons and 1239 arithmetic on CmdSN use Serial Number Arithmetic as defined in 1240 [RFC1982] where SERIAL_BITS = 32. 1242 Commands meant for immediate delivery are marked with an immediate 1243 delivery flag; they MUST also carry the current CmdSN. CmdSN MUST 1244 NOT advance after a command marked for immediate delivery is sent. 1246 Command numbering starts with the first login request on the first 1247 connection of a session (the leading login on the leading 1248 connection) and CmdSN MUST be incremented by 1, in a Serial Number 1249 Arithmetic sense as defined in [RFC1982], for every non-immediate 1250 command issued afterwards. 1252 If immediate delivery is used with task management commands, these 1253 commands may reach the target before the tasks on which they are 1254 supposed to act. However their CmdSN serves as a marker of their 1255 position in the stream of commands. The initiator and target MUST 1256 ensure that the SCSI task management functions specified in [SAM2] 1257 act in accordance with the [SAM2] specification. For example, both 1258 commands and responses appear as if delivered in order. Whenever 1259 CmdSN for an outgoing PDU is not specified by an explicit rule, 1260 CmdSN will carry the current value of the local CmdSN variable 1261 (see later in this section). 1263 The means by which an implementation decides to mark a PDU for 1264 immediate delivery or by which iSCSI decides by itself to mark a 1265 PDU for immediate delivery are beyond the scope of this document. 1267 The number of commands used for immediate delivery is not limited 1268 and their delivery to execution is not acknowledged through the 1269 numbering scheme. An iSCSI target MAY reject immediate commands, 1270 e.g., due to lack of resources to accommodate additional commands. 1271 An iSCSI target MUST be able to handle at least one immediate task 1272 management command and one immediate non-task-management iSCSI 1273 command per connection at any time. 1275 In this document, delivery for execution means delivery to the 1276 SCSI execution engine or an iSCSI protocol specific execution 1277 engine (e.g., for text requests with public or private extension 1278 keys involving an execution component). With the exception of the 1279 commands marked for immediate delivery, the iSCSI target layer 1280 MUST deliver the commands for execution in the order specified by 1281 CmdSN. Commands marked for immediate delivery may be delivered by 1282 the iSCSI target layer for execution as soon as detected. iSCSI 1283 may avoid delivering some commands to the SCSI target layer if 1284 required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET 1285 Task Management request received before all the commands on which 1286 it was supposed to act). 1288 On any connection, the iSCSI initiator MUST send the commands in 1289 increasing order of CmdSN, except for commands that are 1290 retransmitted due to digest error recovery and connection 1291 recovery. 1293 For the numbering mechanism, the initiator and target maintain the 1294 following three variables for each session: 1296 - CmdSN - the current command Sequence Number, advanced by 1 1297 on each command shipped except for commands marked for 1298 immediate delivery (see Section 4.2.2.1). CmdSN always 1299 contains the number to be assigned to the next Command PDU. 1301 - ExpCmdSN - the next expected command by the target. The 1302 target acknowledges all commands up to, but not including, 1303 this number. The initiator treats all commands with CmdSN 1304 less than ExpCmdSN as acknowledged. The target iSCSI layer 1305 sets the ExpCmdSN to the largest non-immediate CmdSN that it 1306 can deliver for execution "plus 1" per [RFC1982]. There 1307 MUST NOT be any holes in the acknowledged CmdSN sequence. 1309 - MaxCmdSN - the maximum number to be shipped. The queuing 1310 capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN 1311 + 1. 1313 The initiator's ExpCmdSN and MaxCmdSN are derived from target-to- 1314 initiator PDU fields. Comparisons and arithmetic on ExpCmdSN and 1315 MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] 1316 where SERIAL_BITS = 32. 1318 The target MUST NOT transmit a MaxCmdSN that is less than 1319 ExpCmdSN-1. For non-immediate commands, the CmdSN field can take 1320 any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST 1321 silently ignore any non-immediate command outside of this range or 1322 non-immediate duplicates within the range. The CmdSN carried by 1323 immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. 1324 For example, if the initiator has previously sent a non-immediate 1325 command carrying the CmdSN equal to MaxCmdSN, the target window is 1326 closed. For group task management commands issued as immediate 1327 commands, CmdSN indicates the scope of the group action (e.g., on 1328 ABORT TASK SET indicates which commands are to be aborted). 1330 MaxCmdSN and ExpCmdSN fields are processed by the initiator as 1331 follows: 1333 -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in 1334 Serial Arithmetic Sense), they are both ignored. 1336 -If the PDU MaxCmdSN is greater than the local MaxCmdSN (in 1337 Serial Arithmetic Sense), it updates the local MaxCmdSN; 1338 otherwise, it is ignored. 1340 -If the PDU ExpCmdSN is greater than the local ExpCmdSN (in 1341 Serial Arithmetic Sense), it updates the local ExpCmdSN; 1342 otherwise, it is ignored. 1344 This sequence is required because updates may arrive out of order 1345 (e.g., the updates are sent on different TCP connections). 1347 iSCSI initiators and targets MUST support the command numbering 1348 scheme. 1350 A numbered iSCSI request will not change its allocated CmdSN, 1351 regardless of the number of times and circumstances in which it is 1352 reissued (see Section 7.2.1"Usage of Retry"). At the target, CmdSN 1353 is only relevant while the command has not created any state 1354 related to its execution (execution state); afterwards, CmdSN 1355 becomes irrelevant. Testing for the execution state (represented 1356 by identifying the Initiator Task Tag) MUST precede any other 1357 action at the target. If no execution state is found, it is 1358 followed by ordering and delivery. If an execution state is found, 1359 it is followed by delivery if it has not already been delivered. 1361 If an initiator issues a command retry for a command with CmdSN R 1362 on 1363 a connection when the session CmdSN value is Q, it MUST NOT 1364 advance the CmdSN past R + 2**31 -1 unless the connection is no 1365 longer operational (i.e., it has returned to the FREE state, see 1366 Section 8.1.3 "Standard Connection State Diagram for an 1367 Initiator"), the connection has been reinstated (see Section 6.3.4 1368 "Connection Reinstatement"), or a non-immediate command with CmdSN 1369 equal or greater than Q was issued subsequent to the command retry 1370 on the same connection and the reception of that command is 1371 acknowledged by the target (see Section 10.4). 1373 A target command response or Data-in PDU with status MUST NOT 1374 precede the command acknowledgement. However, the acknowledgement 1375 MAY be included in the response or the Data-in PDU. 1377 4.2.2.2. Response/Status Numbering and Acknowledging 1379 Responses in transit from the target to the initiator are 1380 numbered. The StatSN (Status Sequence Number) is used for this 1381 purpose. StatSN is a counter maintained per connection. ExpStatSN 1382 is used by the initiator to acknowledge status. The status 1383 sequence number space is 32-bit unsigned-integers and the 1384 arithmetic operations are the regular mod(2**32) arithmetic. 1386 Status numbering starts with the Login response to the first Login 1387 request of the connection. The Login response includes an initial 1388 value for status numbering (any initial value is valid). 1390 To enable command recovery, the target MAY maintain enough state 1391 information for data and status recovery after a connection 1392 failure. A target doing so can safely discard all of the state 1393 information maintained for recovery of a command after the 1394 delivery of the status for the command (numbered StatSN) is 1395 acknowledged through ExpStatSN. 1397 A large absolute difference between StatSN and ExpStatSN may 1398 indicate a failed connection. Initiators MUST undertake recovery 1399 actions if the difference is greater than an implementation 1400 defined constant that MUST NOT exceed 2**31-1. 1402 Initiators and Targets MUST support the response-numbering scheme. 1404 4.2.2.3. Response Ordering 1406 4.2.2.3.1. Need for Response Ordering 1408 Whenever an iSCSI session is composed of multiple connections, the 1409 Response PDUs (task responses or TMF responses) originating in 1410 the target SCSI layer are distributed onto the multiple 1411 connections by the target iSCSI layer according to iSCSI 1412 connection allegiance rules. This process generally may not 1413 preserve the ordering of the responses by the time they are 1414 delivered to the initiator SCSI layer. 1416 Since ordering is not expected across SCSI responses anyway, this 1417 approach works fine in the general case. However, to address the 1418 special cases where some ordering is desired by the SCSI layer, 1419 the following "Response Fence" semantics are defined with respect 1420 to handling SCSI response messages as they are handed off from the 1421 SCSI protocol layer to the iSCSI layer. 1423 4.2.2.3.2. Response Ordering Model Description 1425 The target SCSI protocol layer hands off the SCSI response 1426 messages to the target iSCSI layer by invoking the "Send Command 1427 Complete" protocol data service ([SAM2], clause 5.4.2) and "Task 1428 Management Function Executed" ([SAM2], clause 6.9) service. On 1429 receiving the SCSI response message, the iSCSI layer exhibits the 1430 Response Fence behavior for certain SCSI response messages 1431 (Section 4.2.2.3.4 describes the specific instances where the 1432 semantics must be realized). 1434 Whenever the Response Fence behavior is required for a SCSI 1435 response message, the target iSCSI layer MUST ensure that the 1436 following conditions are met in delivering the response message to 1437 the initiator iSCSI layer: 1439 Response with Response Fence MUST be delivered chronologically 1440 after all the "preceding" responses on the I_T_L nexus, if 1441 the preceding responses are delivered at all, to the 1442 initiator iSCSI layer. 1443 Response with Response Fence MUST be delivered chronologically 1444 prior to all the "following" responses on the I_T_L nexus. 1446 The "preceding" and "following" notions refer to the order of 1447 handoff of a response message from the target SCSI protocol layer 1448 to the target iSCSI layer. 1450 4.2.2.3.3. iSCSI Semantics with the Interface Model 1452 Whenever the TaskReporting key (Section 13.23"Task Reporting") is 1453 negotiated to ResponseFence or FastAbort for an iSCSI session and 1454 the Response Fence behavior is required for a SCSI response 1455 message, the target iSCSI layer MUST perform the actions described 1456 in this Section for that session. 1458 If it is a single-connection session, no special processing is 1459 required. The standard SCSI Response PDU build and dispatch 1460 process happens. 1461 If it is a multi-connection session, the target iSCSI layer 1462 takes note of the last-sent and unacknowledged StatSN on 1463 each of the connections in the iSCSI session, and waits for 1464 an acknowledgement (NOP-In PDUs MAY be used to solicit 1465 acknowledgements as needed in order to accelerate this 1466 process) of each such StatSN to clear the fence. The SCSI 1467 response requiring Response Fence behavior MUST NOT be sent 1468 to the initiator before acknowledgements are received for 1469 each of the unacknowledged StatSNs. 1470 The target iSCSI layer must wait for an acknowledgement of the 1471 SCSI Response PDU that carried the SCSI response requiring 1472 the Response Fence behavior. The fence MUST be considered 1473 cleared only after receiving the acknowledgement. 1475 All further status processing for the LU is resumed only after 1476 clearing the fence. If any new responses for the I_T_L 1477 nexus are received from the SCSI layer before the fence is 1478 cleared, those Response PDUs MUST be held and queued at the 1479 iSCSI layer until the fence is cleared. 1481 4.2.2.3.4. Current List of Fenced Response Use Cases 1483 This Section lists the fenced response use cases that iSCSI 1484 implementations MUST comply with. However, this is not an 1485 exhaustive enumeration. It is expected that as SCSI protocol 1486 specifications evolve, the specifications will specify when 1487 response fencing is required on a case-by-case basis. 1489 Whenever the TaskReporting key (Section 13.23) is negotiated to 1490 ResponseFence or FastAbort for an iSCSI session, the target iSCSI 1491 layer MUST assume that the Response Fence is required for the 1492 following SCSI completion messages: 1494 1. The first completion message carrying the UA after the 1495 multi-task abort on issuing and third-party sessions. See 1496 Section 4.2.3.2 for related TMF discussion. 1498 2. The TMF Response carrying the multi-task TMF Response on 1499 the issuing session. 1501 3. The completion message indicating ACA establishment on the 1502 issuing session. 1504 4. The first completion message carrying the ACA ACTIVE status 1505 after ACA establishment on issuing and third-party 1506 sessions. 1508 5. The TMF Response carrying the Clear ACA response on the 1509 issuing session. 1511 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 1512 command. 1514 Note: 1515 - Due to the absence of ACA-related fencing requirements in 1516 [RFC3720], initiator implementations SHOULD NOT use ACA on 1517 multi-connection iSCSI sessions with targets complying only 1518 with [RFC3720]. 1520 - Initiators that want to employ ACA on multi-connection iSCSI 1521 sessions SHOULD first assess response-fencing behavior via 1522 negotiating for ResponseFence or FastAbort values for the 1523 TaskReporting (Section 13.23) key. 1525 4.2.2.4. Data Sequencing 1527 Data and R2T PDUs transferred as part of some command execution 1528 MUST be sequenced. The DataSN field is used for data sequencing. 1529 For input (read) data PDUs, DataSN starts with 0 for the first 1530 data PDU of an input command and advances by 1 for each subsequent 1531 data PDU. For output data PDUs, DataSN starts with 0 for the first 1532 data PDU of a sequence (the initial unsolicited sequence or any 1533 data PDU sequence issued to satisfy an R2T) and advances by 1 for 1534 each subsequent data PDU. R2Ts are also sequenced per command. For 1535 example, the first R2T has an R2TSN of 0 and advances by 1 for 1536 each subsequent R2T. For bidirectional commands, the target uses 1537 the DataSN/R2TSN to sequence Data-In and R2T PDUs in one 1538 continuous sequence (undifferentiated). Unlike command and status, 1539 data PDUs and R2Ts are not acknowledged by a field in regular 1540 outgoing PDUs. Data-In PDUs can be acknowledged on demand by a 1541 special form of the SNACK PDU. Data and R2T PDUs are implicitly 1542 acknowledged by status for the command. The DataSN/R2TSN field 1543 enables the initiator to detect missing data or R2T PDUs. 1545 For any read or bidirectional command, a target MUST issue less 1546 than 2**32 combined R2T and Data-In PDUs. Any output data sequence 1547 MUST contain less than 2**32 Data-Out PDUs. 1549 4.2.3. iSCSI Task Management 1551 4.2.3.1. Task Management Overview 1553 iSCSI task management features allow an initiator to control the 1554 active iSCSI tasks on an operational iSCSI session that it has 1555 with an iSCSI target. Section 11.5 defines the task management 1556 function types that this specification defines - ABORT TASK, ABORT 1557 TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET 1558 WARM RESET, TARGET COLD RESET, and TASK REASSIGN. 1560 Out of these function types, ABORT TASK and TASK REASSIGN 1561 functions manage a single active task, whereas ABORT TASK SET, 1562 CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET and TARGET 1563 COLD RESET functions can each potentially affect multiple active 1564 tasks. 1566 4.2.3.2. Notion of Affected Tasks 1568 This Section defines the notion of "affected tasks" in multi-task 1569 abort scenarios. Scope definitions in this Section apply to both 1570 the Standard Multi-task Abort semantics (Section 4.2.3.3) and the 1571 FastAbort Multi-task Abort semantics behavior (Section 4.2.3.4). 1573 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 1574 identified by the LUN field in the ABORT TASK SET TMF Request PDU 1575 (Section 11.5). 1577 CLEAR TASK SET: All outstanding tasks in the task set for the LU 1578 identified by the LUN field in the CLEAR TASK SET TMF Request PDU. 1579 See [SPC3] for the definition of a "task set". 1581 LOGICAL UNIT RESET: All outstanding tasks from all initiators for 1582 the LU identified by the LUN field in the LOGICAL UNIT RESET 1583 Request PDU. 1585 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from 1586 all initiators across all LUs to which the TMF-issuing session has 1587 access on the SCSI target device hosting the iSCSI session. 1589 Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text 1590 is an iSCSI TMF Request PDU with the "Function" field set to 1591 "ABORT TASK SET" as defined in Section 11.5. Similar usage is 1592 employed for other scope descriptions. 1594 4.2.3.3. Standard Multi-task Abort Semantics 1596 All iSCSI implementations MUST support the protocol behavior 1597 defined in this Section as the default behavior. The execution of 1598 ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM 1599 RESET, and TARGET COLD RESET TMF Requests consists of the 1600 following sequence of actions in the specified order on the 1601 specified party. 1603 The initiator iSCSI layer: 1604 a. MUST continue to respond to each TTT received for the 1605 affected tasks. 1606 b. SHOULD process any responses received for affected tasks in 1607 the normal fashion. This is acceptable because the 1608 responses are guaranteed to have been sent prior to the TMF 1609 response. 1610 c. SHOULD receive the TMF Response concluding all the tasks in 1611 the set of affected tasks unless the initiator has done 1612 something (e.g., LU reset, connection drop) that may 1613 prevent the TMF Response from being sent or received. The 1614 initiator MUST thus conclude all affected tasks as part of 1615 this step in either case, and MUST discard any TMF Response 1616 received after the affected tasks are concluded. 1618 The target iSCSI layer: 1619 a. MUST wait for responses on currently valid target-transfer 1620 tags of the affected tasks from the issuing initiator. MAY 1621 wait for responses on currently valid target-transfer tags 1622 of the affected tasks from third-party initiators. 1623 b. MUST wait (concurrent with the wait in Step a) for all 1624 commands of the affected tasks to be received based on the 1625 CmdSN ordering. SHOULD NOT wait for new commands on third- 1626 party affected sessions -- only the instantiated tasks have 1627 to be considered for the purpose of determining the 1628 affected tasks. In the case of target-scoped requests 1629 (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the 1630 commands that are not yet received on the issuing session 1631 in the command stream however can be considered to have 1632 been received with no command waiting period -- i.e., the 1633 entire CmdSN space up to the CmdSN of the task management 1634 function can be "plugged". 1635 c. MUST propagate the TMF request to and receive the response 1636 from the target SCSI layer. 1637 d. MUST provide the Response Fence behavior for the TMF 1638 Response on the issuing session as specified in Section 1639 4.2.2.3.2. 1641 e. MUST provide the Response Fence behavior on the first post- 1642 TMF Response on third-party sessions as specified in 1643 Section 4.2.2.3.3. If some tasks originate from non-iSCSI 1644 I_T_L nexuses, then the means by which the target ensures 1645 that all affected tasks have returned their status to the 1646 initiator are defined by the specific non-iSCSI transport 1647 protocol(s). 1649 Technically, the TMF servicing is complete in Step d. Data 1650 transfers corresponding to terminated tasks may however still be 1651 in progress on third-party iSCSI sessions even at the end of Step 1652 e. The TMF Response MUST NOT be sent by the target iSCSI layer 1653 before the end of Step d, and MAY be sent at the end of Step d 1654 despite these outstanding data transfers until after Step e. 1656 4.2.3.4. FastAbort Multi-task Abort Semantics 1658 Protocol behavior defined in this Section SHOULD be implemented by 1659 all iSCSI implementations complying with this document. Protocol 1660 behavior defined in this Section MUST be exhibited by iSCSI 1661 implementations on an iSCSI session when they negotiate the 1662 TaskReporting (Section 13.23) key to "FastAbort" on that session. 1663 The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT 1664 RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests 1665 consists of the following sequence of actions in the specified 1666 order on the specified party. 1668 The initiator iSCSI layer: 1669 a. MUST NOT send any more Data-Out PDUs for affected tasks on 1670 the issuing connection of the issuing iSCSI session once 1671 the TMF is sent to the target. 1672 b. SHOULD process any responses received for affected tasks in 1673 the normal fashion. This is acceptable because the 1674 responses are guaranteed to have been sent prior to the TMF 1675 response. 1676 c. MUST respond to each Async Message PDU with FAST_ABORT 1677 AsyncEvent as defined in Section 11.9. 1678 d. MUST treat the TMF response as terminating all affected 1679 tasks for which responses have not been received, and MUST 1680 discard any responses for affected tasks received after the 1681 TMF response is passed to the SCSI layer (although the 1682 semantics defined in this Section ensure that such an out- 1683 of-order scenario will never happen with a compliant target 1684 implementation). 1686 The target iSCSI layer: 1687 a. MUST wait for all commands of the affected tasks to be 1688 received based on the CmdSN ordering on the issuing 1689 session. SHOULD NOT wait for new commands on third-party 1690 affected sessions - only the instantiated tasks have to be 1691 considered for the purpose of determining the affected 1692 tasks. In the case of target-scoped requests (i.e., TARGET 1693 WARM RESET and TARGET COLD RESET), all the commands that 1694 are not yet received on the issuing session in the command 1695 stream can be considered to have been received with no 1696 command waiting period -- i.e., the entire CmdSN space up 1697 to the CmdSN of the task management function can be 1698 "plugged". 1699 b. MUST propagate the TMF request to and receive the response 1700 from the target SCSI layer. 1701 c. MUST leave all active "affected TTTs" (i.e., active TTTs 1702 associated with affected tasks) valid. 1703 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 1704 (Section 11.9) on: 1705 i) each connection of each third-party session to 1706 which at least one affected task is allegiant if 1707 TaskReporting=FastAbort is operational on that third- 1708 party session, and, 1709 ii) each connection except the issuing connection of 1710 the issuing session that has at least one allegiant 1711 affected task. 1712 If there are multiple affected LUs (say, due to a target 1713 reset), then one Async Message PDU MUST be sent for each 1714 such LU on each connection that has at least one allegiant 1715 affected task. The LUN field in the Asynchronous Message PDU 1716 MUST be set to match the LUN for each such LU. 1717 e. MUST address the Response Fence flag on the TMF Response on 1718 the issuing session as defined in Section 4.2.2.3.3. 1719 f. MUST address the Response Fence flag on the first post-TMF 1720 Response on third-party sessions as defined in Section 1721 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L 1722 nexuses, then the means by which the target ensures that 1723 all affected tasks have returned their status to the 1724 initiator are defined by the specific non-iSCSI transport 1725 protocol(s). 1726 g. MUST free up the affected TTTs (and STags, if applicable) 1727 and the corresponding buffers, if any, once it receives 1728 each associated NOP-Out acknowledgement that the initiator 1729 generated in response to each Async Message. 1731 Technically, the TMF servicing is complete in Step e. Data 1732 transfers corresponding to terminated tasks may however still be 1733 in progress even at the end of Step f. A TMF Response MUST NOT be 1734 sent by the target iSCSI layer before the end of Step e, and MAY 1735 be sent at the end of Step e despite these outstanding Data 1736 transfers until Step g. Step g specifies an event to free up any 1737 such resources that may have been reserved to support outstanding 1738 data transfers. 1740 4.2.3.5. Affected Tasks Shared across Standard and FastAbort Sessions 1742 If an iSCSI target implementation is capable of supporting 1743 TaskReporting=FastAbort functionality (Section 13.23), it may end 1744 up in a situation where some sessions have TaskReporting=RFC3720 1745 operational (RFC 3720 sessions) while some other sessions have 1746 TaskReporting=FastAbort operational (FastAbort sessions) even 1747 while accessing a shared set of affected tasks (Section 4.2.3.2). 1748 If the issuing session is an RFC 3720 session, the iSCSI target 1749 implementation is FastAbort-capable, and the third-party affected 1750 session is a FastAbort session, the following behavior SHOULD be 1751 exhibited by the iSCSI target layer: 1752 a. Between Steps c and d of the target behavior in Section 1753 4.2.3.3, send an Asynchronous Message PDU with AsyncEvent=5 1754 (Section 11.9) on each connection of each third-party 1755 session to which at least one affected task is allegiant. 1756 If there are multiple affected LUs, then send one Async 1757 Message PDU for each such LU on each connection that has at 1758 least one allegiant affected task. When sent, the LUN field 1759 in the Asynchronous Message PDU MUST be set to match the 1760 LUN for each such LU. 1761 b. After Step e of the target behavior in Section 4.2.3.3, 1762 free up the affected TTTs (and STags, if applicable) and 1763 the corresponding buffers, if any, once each associated 1764 NOP-Out acknowledgement is received that the third-party 1765 initiator generated in response to each Async Message sent 1766 in Step a. 1768 If the issuing session is a FastAbort session, the iSCSI target 1769 implementation is FastAbort-capable, and the third-party affected 1770 session is an RFC 3720 session, the following behavior MUST be 1771 exhibited by the iSCSI target layer: Asynchronous Message PDUs 1772 MUST NOT be sent on the third-party session to prompt the 1773 FastAbort behavior. 1775 If the third-party affected session is a FastAbort session and the 1776 issuing session is a FastAbort session, the initiator in the 1777 third-party role MUST respond to each Async Message PDU with 1778 AsyncEvent=5 as defined in Section 11.9. Note that an initiator 1779 MAY thus receive these Async Messages on a third-party affected 1780 session even if the session is a single-connection session. 1782 4.2.3.6. Rationale behind the FastAbort Semantics 1784 There are fundamentally three basic objectives behind the 1785 semantics 1786 specified in Sections 4.2.3.3 and 4.2.3.4. 1787 1. Maintaining an ordered command flow I_T nexus abstraction 1788 to the target SCSI layer even with multi-connection 1789 sessions. 1790 - Target iSCSI processing of a TMF request must 1791 maintain the single flow illusion. Target behavior in 1792 Step b of Section 4.2.3.3 and Step aof Section 4.2.3.4 1793 correspond to this objective. 1794 2. Maintaining a single ordered response flow I_T nexus 1795 abstraction to the initiator SCSI layer even with multi- 1796 connection sessions when one response (i.e., TMF response) 1797 could imply the status of other unfinished tasks from the 1798 initiator's perspective. 1799 - The target must ensure that the initiator does not 1800 see "old" task responses (that were placed on the wire 1801 chronologically earlier than the TMF Response) after 1802 seeing the TMF response. The target behavior in Step d 1803 of Section 4.2.3.3 and Step e of Section 4.2.3.4 1804 correspond to this objective. 1805 - Whenever the result of a TMF action is visible across 1806 multiple I_T_L nexuses, [SAM2] requires the SCSI device 1807 server to trigger a UA on each of the other I_T_L 1808 nexuses. Once an initiator is notified of such an UA, 1809 the application client on the receiving initiator is 1810 required to clear its task state (clause 5.5 in [SAM2]) 1811 for the affected tasks. It would thus be inappropriate 1812 to deliver a SCSI Response for a task after the task 1813 state is cleared on the initiator, i.e., after the UA 1814 is notified. The UA notification contained in the first 1815 SCSI Response PDU on each affected Third-party I_T_L 1816 nexus after the TMF action thus MUST NOT pass the 1817 affected task responses on any of the iSCSI sessions 1818 accessing the LU. The target behavior in Step e of 1819 Section 4.2.3.3 and Step f of Section 4.2.3.4 1820 correspond to this objective. 1821 3. Draining all active TTTs corresponding to affected tasks in 1822 a deterministic fashion. 1823 - Data-Out PDUs with stale TTTs arriving after the 1824 tasks are terminated can create a buffer management 1825 problem even for traditional iSCSI implementations, and 1826 is fatal for the connection for iSCSI/iSER 1827 implementations. Either the termination of affected 1828 tasks should be postponed until the TTTs are retired 1829 (as in Step a of Section 4.2.3.3), or the TTTs and the 1830 buffers should stay allocated beyond task termination 1831 to be deterministically freed up later (as in Steps c 1832 and g of Section 4.2.3.4). 1834 The only other notable optimization is the plugging. If all tasks 1835 on an I_T nexus will be aborted anyway (as with a target reset), 1836 there is no need to wait to receive all commands to plug the CmdSN 1837 holes. The target iSCSI layer can simply plug all missing CmdSN 1838 slots and move on with TMF processing. The first objective 1839 (maintaining a single ordered command flow) is still met with this 1840 optimization because the target SCSI layer only sees ordered 1841 commands. 1843 4.2.4. iSCSI Login 1845 The purpose of the iSCSI login is to enable a TCP connection for 1846 iSCSI use, authentication of the parties, negotiation of the 1847 session's parameters and marking of the connection as belonging to 1848 an iSCSI session. 1850 A session is used to identify to a target all the connections with 1851 a given initiator that belong to the same I_T nexus. (For more 1852 details on how a session relates to an I_T nexus, see Section 1853 4.4.2). 1855 The targets listen on a well-known TCP port or other TCP port for 1856 incoming connections. The initiator begins the login process by 1857 connecting to one of these TCP ports. 1859 As part of the login process, the initiator and target SHOULD 1860 authenticate each other and MAY set a security association 1861 protocol for the session. This can occur in many different ways 1862 and is subject to negotiation. 1864 To protect the TCP connection, an IPsec security association MAY 1865 be established before the Login request. For information on using 1866 IPsec security for iSCSI see Chapter 8 and [RFC3723]. 1868 The iSCSI Login Phase is carried through Login requests and 1869 responses. Once suitable authentication has occurred and 1870 operational parameters have been set, the session transitions to 1871 Full Feature Phase and the initiator may start to send SCSI 1872 commands. The security policy for whether, and by what means, a 1873 target chooses to authorize an initiator is beyond the scope of 1874 this document. For a more detailed description of the Login Phase, 1875 see Chapter 5. 1877 The login PDU includes the ISID part of the session ID (SSID). The 1878 target portal group that services the login is implied by the 1879 selection of the connection endpoint. For a new session, the TSIH 1880 is zero. As part of the response, the target generates a TSIH. 1882 During session establishment, the target identifies the SCSI 1883 initiator port (the "I" in the "I_T nexus") through the value pair 1884 (InitiatorName, ISID). We describe InitiatorName later in this 1886 section. Any persistent state (e.g., persistent reservations) on 1887 the target that is associated with a SCSI initiator port is 1888 identified based on this value pair. Any state associated with the 1889 SCSI target port (the "T" in the "I_T nexus") is identified 1890 externally by the TargetName and portal group tag (see Section 1891 4.4.1). ISID is subject to reuse restrictions because it is used 1892 to identify a persistent state (see Section 4.4.3). 1894 Before the Full Feature Phase is established, only Login Request 1895 and Login Response PDUs are allowed. Login requests and responses 1896 MUST be used exclusively during Login. On any connection, the 1897 login phase MUST immediately follow TCP connection establishment 1898 and a subsequent Login Phase MUST NOT occur before tearing down a 1899 connection. 1901 A target receiving any PDU except a Login request before the Login 1902 phase is started MUST immediately terminate the connection on 1903 which the PDU was received. Once the Login phase has started, if 1904 the target receives any PDU except a Login request, it MUST send a 1905 Login reject (with Status "invalid during login") and then 1906 disconnect. If the initiator receives any PDU except a Login 1907 response, it MUST immediately terminate the connection. 1909 4.2.5. iSCSI Full Feature Phase 1911 Once the initiator is authorized to do so, the iSCSI session is in 1912 the iSCSI Full Feature Phase. A session is in Full Feature Phase 1913 after successfully finishing the Login Phase on the first 1914 (leading) connection of a session. A connection is in Full Feature 1915 Phase if the session is in Full Feature Phase and the connection 1916 login has completed successfully. An iSCSI connection is not in 1917 Full Feature Phase 1919 when it does not have an established transport connection, 1920 OR 1921 when it has a valid transport connection, but a successful 1922 login was not performed or the connection is currently 1923 logged out. 1925 In a normal Full Feature Phase, the initiator may send SCSI 1926 commands and data to the various LUs on the target by 1927 encapsulating them in iSCSI PDUs that go over the established 1928 iSCSI session. 1930 4.2.5.1. Command Connection Allegiance 1932 For any iSCSI request issued over a TCP connection, the 1933 corresponding response and/or other related PDU(s) MUST be sent 1934 over the same connection. We call this "connection allegiance". If 1935 the original connection fails before the command is completed, the 1936 connection allegiance of the command may be explicitly reassigned 1937 to a different transport connection as described in detail in 1938 Section 7.2 "Retry and Reassign in Recovery". 1940 Thus, if an initiator issues a READ command, the target MUST send 1941 the requested data, if any, followed by the status to the 1942 initiator over the same TCP connection that was used to deliver 1943 the SCSI command. If an initiator issues a WRITE command, the 1944 initiator MUST send the data, if any, for that command over the 1945 same TCP connection that was used to deliver the SCSI command. The 1946 target MUST return Ready To Transfer (R2T), if any, and the status 1947 over the same TCP connection that was used to deliver the SCSI 1948 command. Retransmission requests (SNACK PDUs) and the data and 1949 status that they generate MUST also use the same connection. 1951 However, consecutive commands that are part of a SCSI linked 1952 command-chain task (see [SAM2]) MAY use different connections. 1953 Connection allegiance is strictly per-command and not per-task. 1954 During the iSCSI Full Feature Phase, the initiator and target MAY 1955 interleave unrelated SCSI commands, their SCSI Data, and responses 1956 over the session. 1958 4.2.5.2. Data Transfer Overview 1960 Outgoing SCSI data (initiator to target user data or command 1961 parameters) is sent as either solicited data or unsolicited data. 1962 Solicited data are sent in response to R2T PDUs. Unsolicited data 1963 can be sent as part of an iSCSI command PDU ("immediate data") or 1964 in separate iSCSI data PDUs. 1966 Immediate data are assumed to originate at offset 0 in the 1967 initiator SCSI write-buffer (outgoing data buffer). All other Data 1968 PDUs have the buffer offset set explicitly in the PDU header. 1970 An initiator may send unsolicited data up to FirstBurstLength 1971 (see Section 13.14) as immediate (up to the negotiated maximum PDU 1972 length), in a separate PDU sequence or both. All subsequent data 1973 MUST be solicited. The maximum length of an individual data PDU or 1974 the immediate-part of the first unsolicited burst MAY be 1975 negotiated at login. 1977 The maximum amount of unsolicited data that can be sent with a 1978 command is negotiated at login through the FirstBurstLength (see 1979 Section 13.14) key. A target MAY separately enable immediate data 1980 (through the ImmediateData key) without enabling the more general 1981 (separate data PDUs) form of unsolicited data (through the 1982 InitialR2T key). 1984 Unsolicited data on write are meant to reduce the effect of 1985 latency on throughput (no R2T is needed to start sending data). In 1986 addition, immediate data is meant to reduce the protocol overhead 1987 (both bandwidth and execution time). 1989 An iSCSI initiator MAY choose not to send unsolicited data, only 1990 immediate data or FirstBurstLength bytes of unsolicited data with 1991 a command. If any non-immediate unsolicited data is sent, the 1992 total unsolicited data MUST be either FirstBurstLength, or all of 1993 the data if the total amount is less than the FirstBurstLength. 1995 It is considered an error for an initiator to send unsolicited 1996 data PDUs to a target that operates in R2T mode (only solicited 1997 data are allowed). It is also an error for an initiator to send 1998 more unsolicited data, whether immediate or as separate PDUs, than 1999 FirstBurstLength. 2001 An initiator MUST honor an R2T data request for a valid 2002 outstanding command (i.e., carrying a valid Initiator Task Tag) 2003 and deliver all the requested data provided the command is 2004 supposed to deliver outgoing data and the R2T specifies data 2005 within the command bounds. The initiator action is unspecified for 2006 receiving an R2T request that specifies data, all or part, outside 2007 of the bounds of the command. 2009 A target SHOULD NOT silently discard data and then request 2010 retransmission through R2T. Initiators SHOULD NOT keep track of 2011 the data transferred to or from the target (scoreboarding). SCSI 2012 targets perform residual count calculation to check how much data 2013 was actually transferred to or from the device by a command. This 2014 may differ from the amount the initiator sent and/or received for 2015 reasons such as retransmissions and errors. Read or bidirectional 2016 commands implicitly solicit the transmission of the entire amount 2017 of data covered by the command. SCSI data packets are matched to 2018 their corresponding SCSI commands by using tags specified in the 2019 protocol. 2021 In addition, iSCSI initiators and targets MUST enforce some 2022 ordering rules. When unsolicited data is used, the order of the 2023 unsolicited data on each connection MUST match the order in which 2024 the commands on that connection are sent. Command and unsolicited 2025 data PDUs may be interleaved on a single connection as long as the 2026 ordering requirements of each are maintained (e.g., command N+1 2027 MAY be sent before the unsolicited Data-Out PDUs for command N, 2028 but the unsolicited Data-Out PDUs for command N MUST precede the 2029 unsolicited Data-Out PDUs of command N+1). A target that receives 2030 data out of order MAY terminate the session. 2032 4.2.5.3. Tags and Integrity Checks 2034 Initiator tags for pending commands are unique initiator-wide for 2035 a session. Target tags are not strictly specified by the protocol. 2036 It is assumed that target tags are used by the target to tag 2037 (alone or in combination with the LUN) the solicited data. Target 2038 tags are generated by the target and "echoed" by the initiator. 2039 These mechanisms are designed to accomplish efficient data 2040 delivery along with a large degree of control over the data flow. 2042 As the Initiator Task Tag is used to identify a task during its 2043 execution the iSCSI initiator and target MUST verify that all 2044 other fields used in task related PDUs have values that are 2045 consistent with the values used at the task instantiation based on 2046 Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the 2047 same as the one used in the SCSI command PDU used to instantiate 2048 the task). Using inconsistent field values is considered a 2049 protocol error. 2051 4.2.5.4. Task Management 2053 SCSI task management assumes that individual tasks and task groups 2054 can be aborted solely based on the task tags (for individual 2055 tasks) or the timing of the task management command (for task 2056 groups) and that the task management action is executed 2057 synchronously - i.e, no message involving an aborted task will be 2058 seen by the SCSI initiator after receiving the task management 2059 response. In iSCSI initiators and targets interact asynchronously 2060 over several connections. iSCSI specifies the protocol mechanism 2061 and implementation requirements needed to present a synchronous 2062 view while using an asynchronous infrastructure. 2064 4.2.6. iSCSI Connection Termination 2066 An iSCSI connection may be terminated by use of a transport 2067 connection shutdown or a transport reset. Transport reset is 2068 assumed to be an exceptional event. 2070 Graceful TCP connection shutdowns are done by sending TCP FINs. A 2071 graceful transport connection shutdown SHOULD only be initiated by 2072 either party when the connection is not in iSCSI Full Feature 2073 Phase. A target MAY terminate a Full Feature Phase connection on 2074 internal exception events, but it SHOULD announce the fact through 2075 an Asynchronous Message PDU. Connection termination with 2076 outstanding commands may require recovery actions. 2078 If a connection is terminated while in Full Feature Phase, 2079 connection cleanup (see Section 7) is required prior to recovery. 2080 By doing connection cleanup before starting recovery, the 2081 initiator and target will avoid receiving stale PDUs after 2082 recovery. 2084 4.2.7. iSCSI Names 2086 Both targets and initiators require names for the purpose of 2087 identification. In addition, names enable iSCSI storage resources 2088 to be managed regardless of location (address). An iSCSI node name 2089 is also the SCSI device name contained in the iSCSI Node. The 2090 iSCSI name of a SCSI device is the principal object used in 2091 authentication of targets to initiators and initiators to targets. 2093 This name is also used to identify and manage iSCSI storage 2094 resources. 2096 iSCSI names must be unique within the operation domain of the end 2097 user. However, because the operation domain of an IP network is 2098 potentially worldwide, the iSCSI name formats are architected to 2099 be worldwide unique. To assist naming authorities in the 2100 construction of worldwide unique names, iSCSI provides three name 2101 formats for different types of naming authorities. 2103 iSCSI names are associated with iSCSI nodes, and not iSCSI network 2104 adapter cards, to ensure that the replacement of network adapter 2105 cards does not require reconfiguration of all SCSI and iSCSI 2106 resource allocation information. 2108 Some SCSI commands require that protocol-specific identifiers be 2109 communicated within SCSI CDBs. See SCSI for the definition of the 2110 SCSI port name/identifier for iSCSI ports. 2112 An initiator may discover the iSCSI Target Names to which it has 2113 access, along with their addresses, using the SendTargets text 2114 request, or other techniques discussed in [RFC3721]. 2116 iSCSI equipment that needs discovery functions beyond SendTargets 2117 SHOULD implement iSNS (see [RFC4171]) for extended discovery 2118 management capabilities and interoperability. Although [RFC3721] 2119 implies an SLP implementation requirement, SLP has not been widely 2120 implemented or deployed for use with iSCSI in practice. iSCSI 2121 implementations therefore SHOULD NOT rely on SLP-based discovery 2122 interoperability. 2124 4.2.7.1. iSCSI Name Properties 2126 Each iSCSI node, whether it is an initiator or target or both, 2127 MUST have an iSCSI name. Whenever an iSCSI Node contains an iSCSI 2128 Initiator Node and an iSCSI Target Node, the iSCSI Initiator Name 2129 MUST be the same as the iSCSI Target Name for the contained Nodes 2130 such that there is only one iSCSI Node Name for the iSCSI Node 2131 overall. Note the related requirements in Section 9.2.1 on how to 2132 map CHAP names to iSCSI Names in such a scenario. 2134 Initiators and targets MUST support the receipt of iSCSI names of 2135 up to the maximum length of 223 bytes. 2137 The initiator MUST present both its iSCSI Initiator Name and the 2138 iSCSI Target Name to which it wishes to connect in the first login 2139 request of a new session or connection. The only exception is if a 2140 discovery session (see Section 4.3) is to be established. In this 2141 case, the iSCSI Initiator Name is still required, but the iSCSI 2142 Target Name MAY be omitted. 2144 iSCSI names have the following properties: 2146 iSCSI names are globally unique. No two initiators or targets 2147 can have the same name. 2148 iSCSI names are permanent. An iSCSI initiator node or target 2149 node has the same name for its lifetime. 2150 iSCSI names do not imply a location or address. An iSCSI 2151 initiator or target can move, or have multiple addresses. A 2152 change of address does not imply a change of name. 2153 iSCSI names do not rely on a central name broker; the naming 2154 authority is distributed. 2155 iSCSI names support integration with existing unique naming 2156 schemes. 2157 iSCSI names rely on existing naming authorities. iSCSI does 2158 not create any new naming authority. 2160 The encoding of an iSCSI name has the following properties: 2162 iSCSI names have the same encoding method regardless of the 2163 underlying protocols. 2164 iSCSI names are relatively simple to compare. The algorithm 2165 for comparing two iSCSI names for equivalence does not rely 2166 on an external server. 2167 iSCSI names are composed only of displayable characters. iSCSI 2168 names allow the use of international character sets but are 2169 not case sensitive. No whitespace characters are used in 2170 iSCSI names. 2171 iSCSI names may be transported using both binary and ASCII- 2172 based protocols. 2174 An iSCSI name really names a logical software entity, and is not 2175 tied to a port or other hardware that can be changed. For 2176 instance, an initiator name should name the iSCSI initiator node, 2177 not a particular NIC or HBA. When multiple NICs are used, they 2178 should generally all present the same iSCSI initiator name to the 2179 targets, because they are simply paths to the same SCSI layer. In 2180 most operating systems, the named entity is the operating system 2181 image. 2183 Similarly, a target name should not be tied to hardware interfaces 2184 that can be changed. A target name should identify the logical 2185 target and must be the same for the target regardless of the 2186 physical portion being addressed. This assists iSCSI initiators in 2187 determining that the two targets it has discovered are really two 2188 paths to the same target. 2190 The iSCSI name is designed to fulfill the functional requirements 2191 for Uniform Resource Names (URN) [RFC1737]. For example, it is 2192 required that the name have a global scope, be independent of 2193 address or location, and be persistent and globally unique. Names 2194 must be extensible and scalable with the use of naming 2195 authorities. The name encoding should be both human and machine 2196 readable. See [RFC1737] for further requirements. 2198 4.2.7.2. iSCSI Name Encoding 2200 An iSCSI name MUST be a UTF-8 (see [RFC3629]) encoding of a string 2201 of Unicode characters with the following properties: 2203 - It is in Normalization Form C (see "Unicode Normalization 2204 Forms" [UNICODE]). 2206 - It only contains characters allowed by the output of the 2207 iSCSI stringprep template (described in [RFC3722]). 2209 - The following characters are used for formatting iSCSI 2210 names: 2212 - dash ('-'=U+002d) 2213 - dot ('.'=U+002e) 2214 - colon (':'=U+003a) 2216 - The UTF-8 encoding of the name is not larger than 223 bytes. 2218 The stringprep process is described in [RFC3454]; iSCSI's use of 2219 the stringprep process is described in [RFC3722]. Stringprep is a 2220 method designed by the Internationalized Domain Name (IDN) working 2221 group to translate human-typed strings into a format that can be 2222 compared as opaque strings. Strings MUST NOT include punctuation, 2223 spacing, diacritical marks, or other characters that could get in 2224 the way of readability. The stringprep process also converts 2225 strings into equivalent strings of lower-case characters. 2227 The stringprep process does not need to be implemented if the 2228 names are only generated using numeric and lower-case (any 2229 character set) alphabetic characters. 2231 Once iSCSI names encoded in UTF-8 are "normalized" they may be 2232 safely compared byte-for-byte. 2234 4.2.7.3. iSCSI Name Structure 2236 An iSCSI name consists of two parts--a type designator followed by 2237 a unique name string. 2239 iSCSI uses three existing naming authorities in constructing 2240 globally unique iSCSI names. Type designator in an iSCSI name 2241 indicates the naming authority on which the name is based. The 2242 three iSCSI name formats are the following: 2244 iSCSI-Qualified Name: it is based on domain names to identify 2245 a naming authority, 2246 NAA format Name: it is based on a naming format defined by 2247 [FC-FS] for constructing globally unique identifiers, 2248 referred to as the Network Address Authority (NAA), and, 2249 EUI format Name: it is based on EUI names where the IEEE 2250 Registration Authority assists in the formation of 2251 worldwide unique names (EUI-64 format). 2253 The corresponding type designator strings currently defined are: 2255 iqn. - iSCSI Qualified name 2257 naa. - Remainder of the string is an INCITS T11-defined 2258 Network Address Authority identifier, in ASCII-encoded 2259 hexadecimal. 2261 eui. - Remainder of the string is an IEEE EUI-64 identifier, 2262 in ASCII-encoded hexadecimal. 2264 These three naming authority designators were considered 2265 sufficient at the time of writing this document. The creation of 2266 additional naming type designators for iSCSI may be considered by 2267 the IETF and detailed in separate RFCs. 2269 The following table summarizes the current SCSI transport 2270 protocols and their naming formats. 2272 SCSI Transport Protocol Naming Format 2273 +----------------------------+-------+-----+----+ 2274 | | EUI-64| NAA |IQN | 2275 |----------------------------|-------|-----|----| 2276 | iSCSI (Internet SCSI) | X | X | X | 2277 |----------------------------|-------|-----|----| 2278 | FCP (Fibre Channel) | | X | | 2279 |----------------------------|-------|-----|----| 2280 | SAS (Serial Attached SCSI) | | X | | 2281 |----------------------------|-------|-----|----| 2282 | SRP (for InfiniBand) | X | | | 2283 +----------------------------+-------+-----+----+ 2285 4.2.7.4. Type "iqn." (iSCSI Qualified Name) 2287 This iSCSI name type can be used by any organization that owns a 2288 domain name. This naming format is useful when an end user or 2289 service provider wishes to assign iSCSI names for targets and/or 2290 initiators. 2292 To generate names of this type, the person or organization 2293 generating the name must own a registered domain name. This domain 2294 name does not have to be active, and does not have to resolve to 2295 an address; it just needs to be reserved to prevent others from 2296 generating iSCSI names using the same domain name. 2298 Since a domain name can expire, be acquired by another entity, or 2299 may be used to generate iSCSI names by both owners, the domain 2300 name must be additionally qualified by a date during which the 2301 naming authority owned the domain name. A date code is provided as 2302 part of the "iqn." format for this reason. 2304 The iSCSI qualified name string consists of: 2306 - The string "iqn.", used to distinguish these names from 2307 "eui." formatted names. 2309 - A date code, in yyyy-mm format. This date MUST be a date 2310 during which the naming authority owned the domain name used 2311 in this format, and SHOULD be the first month in which the 2312 domain name was owned by this naming authority at 00:01 GMT 2313 of the first day of the month. This date code uses the 2314 Gregorian calendar. All four digits in the year must be 2315 present. Both digits of the month must be present, with 2316 January == "01" and December == "12". The dash must be 2317 included. 2319 - A dot "." 2321 - The reversed domain name of the naming authority (person or 2322 organization) creating this iSCSI name. 2324 - An optional, colon (:) prefixed, string within the character 2325 set and length boundaries that the owner of the domain name 2326 deems appropriate. This may contain product types, serial 2327 numbers, host identifiers, or software keys (e.g, it may 2328 include colons to separate organization boundaries). With 2329 the exception of the colon prefix, the owner of the domain 2330 name can assign everything after the reversed domain name as 2331 desired. It is the responsibility of the entity that is the 2332 naming authority to ensure that the iSCSI names it assigns 2334 are worldwide unique. For example, "Example Storage Arrays, 2335 Inc.", might own the domain name "example.com". 2337 The following are examples of iSCSI qualified names that might be 2338 generated by "EXAMPLE Storage Arrays, Inc." 2340 Naming String defined by 2341 Type Date Auth "example.com" naming authority 2342 +--++-----+ +---------+ +--------------------------------+ 2343 | || | | | | | 2345 iqn.2001-04.com.example:storage:diskarrays-sn-a8675309 2346 iqn.2001-04.com.example 2347 iqn.2001-04.com.example:storage.tape1.sys1.xyz 2348 iqn.2001-04.com.example:storage.disk2.sys1.xyz 2350 4.2.7.5. Type "eui." (IEEE EUI-64 format) 2352 The IEEE Registration Authority provides a service for assigning 2353 globally unique identifiers [EUI]. The EUI-64 format is used to 2354 build a global identifier in other network protocols. For example, 2355 Fibre Channel defines a method of encoding it into a 2356 WorldWideName. For more information on registering for EUI 2357 identifiers, see [OUI]. 2359 The format is "eui." followed by an EUI-64 identifier (16 ASCII- 2360 encoded hexadecimal digits). 2362 Example iSCSI name: 2364 Type EUI-64 identifier (ASCII-encoded hexadecimal) 2366 +--++--------------+ 2368 | || | 2370 eui.02004567A425678D 2372 The IEEE EUI-64 iSCSI name format might be used when a 2373 manufacturer is already registered with the IEEE Registration 2374 Authority and uses EUI-64 formatted worldwide unique names for its 2375 products. 2377 More examples of name construction are discussed in [RFC3721]. 2379 4.2.7.6. Type "naa." - Network Address Authority 2381 The INCITS T11 Framing and Signaling Specification [FC-FS] defines 2382 a format called the Network Address Authority (NAA) format for 2383 constructing worldwide unique identifiers that use various 2384 identifier registration authorities. This identifier format is 2385 used by the Fibre Channel and SAS SCSI transport protocols. As FC 2386 and SAS constitute a large fraction of networked SCSI ports, the 2387 NAA format is a widely used format for SCSI transports. The 2388 objective behind iSCSI supporting a direct representation of an 2389 NAA-format name is to facilitate construction of a target device 2390 name that translates easily across multiple namespaces for a SCSI 2391 storage device containing ports served by different transports. 2392 More specifically, this format allows implementations wherein one 2393 NAA identifier can be assigned as the basis for the SCSI device 2394 name for a SCSI target with both SAS ports and iSCSI ports. 2396 The iSCSI NAA naming format is "naa.", followed by an NAA 2397 identifier represented in ASCII-encoded hexadecimal digits. 2399 An example of an iSCSI name with a 64-bit NAA value follows: 2401 Type NAA identifier (ASCII-encoded hexadecimal) 2402 +--++--------------+ 2403 | || | 2404 naa.52004567BA64678D 2406 An example of an iSCSI name with a 128-bit NAA value follows: 2408 Type NAA identifier (ASCII-encoded hexadecimal) 2409 +--++------------------------------+ 2410 | || | 2411 naa.62004567BA64678D0123456789ABCDEF 2412 The iSCSI NAA naming format might be used in an implementation 2413 when the infrastructure for generating NAA worldwide unique names 2414 is already in place because the device contains both SAS and iSCSI 2415 SCSI ports. 2417 The NAA identifier formatted in an ASCII-hexadecimal 2418 representation has a maximum size of 32 characters (128 bit NAA 2419 format). As a result, there is no issue with this naming format 2420 exceeding the maximum size for iSCSI node names. 2422 4.2.8. Persistent State 2424 iSCSI does not require any persistent state maintenance across 2425 sessions. However, in some cases, SCSI requires persistent 2426 identification of the SCSI initiator port name (See Section 4.4.2 2427 and Section 4.4.3). 2429 iSCSI sessions do not persist through power cycles and boot 2430 operations. 2432 All iSCSI session and connection parameters are re-initialized on 2433 session and connection creation. 2435 Commands persist beyond connection termination if the session 2436 persists and command recovery within the session is supported. 2437 However, when a connection is dropped, command execution, as 2438 perceived by iSCSI (i.e., involving iSCSI protocol exchanges for 2439 the affected task), is suspended until a new allegiance is 2440 established by the 'task reassign' task management function. (See 2441 Section 11.5.) 2443 4.2.9. Message Synchronization and Steering 2445 iSCSI presents a mapping of the SCSI protocol onto TCP. This 2446 encapsulation is accomplished by sending iSCSI PDUs of varying 2447 lengths. Unfortunately, TCP does not have a built-in mechanism for 2448 signaling message boundaries at the TCP layer. iSCSI overcomes 2449 this obstacle by placing the message length in the iSCSI message 2450 header. This serves to delineate the end of the current message as 2451 well as the beginning of the next message. 2453 In situations where IP packets are delivered in order from the 2454 network, iSCSI message framing is not an issue and messages are 2455 processed one after the other. In the presence of IP packet 2456 reordering (i.e., frames being dropped), legacy TCP 2457 implementations store the "out of order" TCP segments in temporary 2458 buffers until the missing TCP segments arrive, upon which the data 2459 must be copied to the application buffers. In iSCSI, it is 2460 desirable to steer the SCSI data within these out of order TCP 2461 segments into the pre-allocated SCSI buffers rather than store 2462 them in temporary buffers. This decreases the need for dedicated 2463 reassembly buffers as well as the latency and bandwidth related to 2464 extra copies. 2466 Relying solely on the "message length" information from the iSCSI 2467 message header may make it impossible to find iSCSI message 2468 boundaries in subsequent TCP segments due to the loss of a TCP 2469 segment that contains the iSCSI message length. The missing TCP 2470 segment(s) must be received before any of the following segments 2471 can be steered to the correct SCSI buffers (due to the inability 2472 to determine the iSCSI message boundaries). Since these segments 2473 cannot be steered to the correct location, they must be saved in 2474 temporary buffers that must then be copied to the SCSI buffers. 2476 Different schemes can be used to recover synchronization. The 2477 details of any such schemes are beyond this protocol 2478 specification, but it suffices to note that [RFC4297] provides an 2479 overview of the direct data placement problem on IP networks, and 2480 [RFC5046] specifies a protocol extension for iSCSI that 2481 facilitates this direct data placement objective. 2483 Under normal circumstances (no PDU loss or data reception out of 2484 order), iSCSI data steering can be accomplished by using the 2485 identifying tag and the data offset fields in the iSCSI header in 2486 addition to the TCP sequence number from the TCP header. The 2487 identifying tag helps associate the PDU with a SCSI buffer address 2488 while the data offset and TCP sequence number are used to 2489 determine the offset within the buffer. 2491 4.2.9.1. Sync/Steering and iSCSI PDU Length 2493 When a large iSCSI message is sent, the TCP segment(s) that 2494 contain the iSCSI header may be lost. The remaining TCP segment(s) 2495 up to the next iSCSI message must be buffered (in temporary 2496 buffers) because the iSCSI header that indicates to which SCSI 2497 buffers the data are to be steered was lost. To minimize the 2498 amount of buffering, it is recommended that the iSCSI PDU length 2499 be restricted to a small value (perhaps a few TCP segments in 2500 length). During login, each end of the iSCSI session specifies the 2501 maximum iSCSI PDU length it will accept. 2503 4.3. iSCSI Session Types 2505 iSCSI defines two types of sessions: 2507 Normal operational session - an unrestricted session. 2509 Discovery-session - a session only opened for target 2510 discovery. The target MUST ONLY accept text requests with 2511 the SendTargets key and a logout request with reason "close 2512 the session". All other requests MUST be rejected. 2514 The session type is defined during login with key=value parameter 2515 in the login command. 2517 4.4. SCSI to iSCSI Concepts Mapping Model 2519 The following diagram shows an example of how multiple iSCSI Nodes 2520 (targets in this case) can coexist within the same Network Entity 2521 and can share Network Portals (IP addresses and TCP ports). Other 2522 more complex configurations are also possible. For detailed 2523 descriptions of the components of these diagrams, see Section 2524 4.4.1. 2526 +-----------------------------------+ 2527 | Network Entity (iSCSI Client) | 2528 | | 2529 | +-------------+ | 2530 | | iSCSI Node | | 2531 | | (Initiator) | | 2532 | +-------------+ | 2533 | | | | 2534 | +--------------+ +--------------+ | 2535 | |Network Portal| |Network Portal| | 2536 | | 192.0.2.4 | | 192.0.2.5 | | 2537 +-+--------------+-+--------------+-+ 2538 | | 2539 | IP Networks | 2540 | | 2541 +-+--------------+-+--------------+-+ 2542 | |Network Portal| |Network Portal| | 2543 | |198.51.100.21 | |198.51.100.3 | | 2544 | | TCP Port 3260| | TCP Port 3260| | 2545 | +--------------+ +--------------+ | 2546 | | | | 2547 | ----------------- | 2548 | | | | 2549 | +-------------+ +--------------+ | 2550 | | iSCSI Node | | iSCSI Node | | 2551 | | (Target) | | (Target) | | 2552 | +-------------+ +--------------+ | 2553 | | 2554 | Network Entity (iSCSI Server) | 2555 +-----------------------------------+ 2557 4.4.1. iSCSI Architecture Model 2559 This Section describes the part of the iSCSI architecture model 2560 that has the most bearing on the relationship between iSCSI and 2561 the SCSI Architecture Model. 2563 Network Entity - represents a device or gateway that is 2564 accessible from the IP network. A Network Entity must have 2565 one or more Network Portals (see a following item), each of 2566 which can be used by some iSCSI Nodes (see the following 2568 item) contained in that Network Entity to gain access to 2569 the IP network. 2571 iSCSI Node - represents a single iSCSI initiator or iSCSI 2572 target or an instance of each. There are one or more iSCSI 2573 Nodes within a Network Entity. The iSCSI Node is accessible 2574 via one or more Network Portals (see item d). An iSCSI Node 2575 is identified by its iSCSI Name (see Section 4.2.7 and 2576 Section 13). The separation of the iSCSI Name from the 2577 addresses used by and for the iSCSI node allows multiple 2578 iSCSI nodes to use the same addresses, and the same iSCSI 2579 node to use multiple addresses. 2581 An alias string may also be associated with an iSCSI Node. The 2582 alias allows an organization to associate a user friendly 2583 string with the iSCSI Name. However, the alias string is 2584 not a substitute for the iSCSI Name. 2586 Network Portal - a component of a Network Entity that has a 2587 TCP/IP network address and that may be used by an iSCSI 2588 Node within that Network Entity for the connection(s) 2589 within one of its iSCSI sessions. In an initiator, it is 2590 identified by its IP address. In a target, it is identified 2591 by its IP address and its listening TCP port. 2593 Portal Groups - iSCSI supports multiple connections within the 2594 same session; some implementations will have the ability to 2595 combine connections in a session across multiple Network 2596 Portals. A Portal Group defines a set of Network Portals 2597 within an iSCSI Node that collectively supports the 2598 capability of coordinating a session with connections that 2599 span these portals. Not all Network Portals within a Portal 2600 Group need to participate in every session connected 2601 through that Portal Group. One or more Portal Groups may 2602 provide access to an iSCSI Node. Each Network Portal, as 2603 utilized by a given iSCSI Node, belongs to exactly one 2604 portal group within that node. Portal Groups are identified 2605 within an iSCSI Node by a portal group tag, a simple 2606 unsigned-integer between 0 and 65535 (see Section 13.3 2607 "SendTargets"). All Network Portals with the same portal 2609 group tag in the context of a given iSCSI Node are in the 2610 same Portal Group. 2612 Both iSCSI Initiators and iSCSI Targets have portal groups, 2613 though only the iSCSI Target Portal Groups are used 2614 directly in the iSCSI protocol (e.g., in SendTargets). For 2615 references to the Initiator Portal Groups, see Section 2616 10.1.1. 2618 Portals within a Portal Group should support similar session 2619 parameters, because they may participate in a common 2620 session. 2622 The following diagram shows an example of one such configuration 2623 on a target and how a session that shares Network Portals within a 2624 Portal Group may be established. 2626 ----------------------------IP Network--------------------- 2627 | | | 2628 +----|---------------|-----+ +----|---------+ 2629 | +---------+ +---------+ | | +---------+ | 2630 | | Network | | Network | | | | Network | | 2631 | | Portal | | Portal | | | | Portal | | 2632 | +--|------+ +---------+ | | +---------+ | 2633 | | | | | | | 2634 | | Portal | | | | Portal | 2635 | | Group 1 | | | | Group 2 | 2636 +--------------------------+ +--------------+ 2637 | | | 2638 +--------|---------------|--------------------|------------------- 2639 + 2640 | | | | 2641 | 2642 | +----------------------------+ +----------------------------- 2643 +| 2644 | | iSCSI Session (Target side)| | iSCSI Session (Target side) 2645 || 2646 | | | | 2647 || 2648 | | (TSIH = 56) | | (TSIH = 48) 2649 || 2650 | +----------------------------+ +----------------------------- 2651 +| 2652 | 2653 | 2654 | iSCSI Target Node 2655 | 2656 | (within Network Entity, not shown) 2657 | 2658 +----------------------------------------------------------------- 2659 + 2661 4.4.2. SCSI Architecture Model 2663 This Section describes the relationship between the SCSI 2664 Architecture Model [SAM2] and constructs of the SCSI device, SCSI 2665 port and I_T nexus, and the iSCSI constructs described in Section 2666 4.4.1. 2668 This relationship implies implementation requirements in order to 2669 conform to the SAM2 model and other SCSI operational functions. 2670 These requirements are detailed in Section 4.4.3. 2672 The following list outlines mappings of SCSI architectural 2673 elements to iSCSI. 2675 SCSI Device - the SAM2 term for an entity that contains one or 2676 more SCSI ports that are connected to a service delivery 2677 subsystem and supports a SCSI application protocol. For 2678 example, a SCSI Initiator Device contains one or more SCSI 2679 Initiator Ports and zero or more application clients. A 2680 SCSI Target Device contains one or more SCSI Target Ports 2681 and one or more logical units. For iSCSI, the SCSI Device 2682 is the component within an iSCSI Node that provides the 2683 SCSI functionality. As such, there can be one SCSI Device, 2684 at most, within an iSCSI Node. Access to the SCSI Device 2685 can only be achieved in an iSCSI normal operational session 2686 (see Section 4.3). The SCSI Device Name is defined to be 2687 the iSCSI Name of the node and MUST be used in the iSCSI 2688 protocol. 2690 SCSI Port - the SAM2 term for an entity in a SCSI Device that 2691 provides the SCSI functionality to interface with a service 2692 delivery subsystem or transport. For iSCSI, the definition 2693 of SCSI Initiator Port and SCSI Target Port are different. 2695 SCSI Initiator Port: This maps to one endpoint of an iSCSI 2696 normal operational session (see Section 4.3). An iSCSI 2697 normal operational session is negotiated through the login 2698 process between an iSCSI initiator node and an iSCSI target 2699 node. At successful completion of this process, a SCSI 2700 Initiator Port is created within the SCSI Initiator Device. 2701 The SCSI Initiator Port Name and SCSI Initiator Port 2702 Identifier are both defined to be the iSCSI Initiator Name 2703 together with (a) a label that identifies it as an 2704 initiator port name/identifier and (b) the ISID portion of 2705 the session identifier. 2707 SCSI Target Port: This maps to an iSCSI Target Portal 2708 Group. The SCSI Target Port Name and the SCSI Target Port 2709 Identifier are both defined to be the iSCSI Target Name 2710 together with (a) a label that identifies it as a target 2711 port name/identifier and (b) the portal group tag. 2713 The SCSI Port Name MUST be used in iSCSI. When used in SCSI 2714 parameter data, the SCSI port name MUST be encoded as: 2715 - The iSCSI Name in UTF-8 format, followed by 2716 - a comma separator (1 byte), followed by 2717 - the ASCII character 'i' (for SCSI Initiator Port) or the 2718 ASCII character 't' (for SCSI Target Port) (1 byte), 2719 followed by 2720 - a comma separator (1 byte), followed by 2721 - a text encoding as a hex-constant (see Section 6.1 "Text 2722 Format") of the ISID (for SCSI initiator port) or the 2723 portal group tag (for SCSI target port) including the 2724 initial 0X or 0x and the terminating null (14 bytes). 2726 The ASCII character 'i' or 't' is the label that 2727 identifies this port as either a SCSI Initiator Port or a 2728 SCSI Target Port. 2730 I_T nexus - a relationship between a SCSI Initiator Port and a 2731 SCSI Target Port, according to [SAM2]. For iSCSI, this 2732 relationship is a session, defined as a relationship 2733 between an iSCSI Initiator's end of the session (SCSI 2734 Initiator Port) and the iSCSI Target's Portal Group. The 2735 I_T nexus can be identified by the conjunction of the SCSI 2736 port names or by the iSCSI session identifier SSID. iSCSI 2737 defines the I_T nexus identifier to be the tuple (iSCSI 2738 Initiator Name + ",i,0x" + ISID in text format, iSCSI 2739 Target Name + ",t,0x" + Portal Group Tag in text format) - 2740 an upper case hex prefix "0X" may alternatively be used in 2741 place of "0x". 2743 NOTE: The I_T nexus identifier is not equal to the session 2744 identifier (SSID). 2746 4.4.3. Consequences of the Model 2748 This Section describes implementation and behavioral requirements 2749 that result from the mapping of SCSI constructs to the iSCSI 2750 constructs defined above. Between a given SCSI initiator port and 2751 a given SCSI target port, only one I_T nexus (session) can exist. 2752 No more than one nexus relationship (parallel nexus) is allowed by 2753 [SAM2]. Therefore, at any given time, only one session with the 2754 same session identifier (SSID) can exist between a given iSCSI 2755 initiator node and an iSCSI target node. 2757 These assumptions lead to the following conclusions and 2758 requirements: 2760 ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal 2761 Group (SCSI target port), there can only be one session with a 2762 given value for ISID that identifies the SCSI initiator port. See 2763 Section 11.12.5. 2765 The structure of the ISID that contains a naming authority 2766 component (see Section 11.12.5 and [RFC3721]) provides a mechanism 2767 to facilitate compliance with the ISID rule. (See Section 10.1.1) 2769 The iSCSI Initiator Node should manage the assignment of ISIDs 2770 prior to session initiation. The "ISID RULE" does not preclude the 2771 use of the same ISID from the same iSCSI Initiator with different 2772 Target Portal Groups on the same iSCSI target or on other iSCSI 2773 targets (see Section 10.1.1). Allowing this would be analogous to 2774 a single SCSI Initiator Port having relationships (nexus) with 2775 multiple SCSI target ports on the same SCSI target device or SCSI 2776 target ports on other SCSI target devices. It is also possible to 2777 have multiple sessions with different ISIDs to the same Target 2778 Portal Group. Each such session would be considered to be with a 2779 different initiator even when the sessions originate from the same 2780 initiator device. The same ISID may be used by a different iSCSI 2781 initiator because it is the iSCSI Name together with the ISID that 2782 identifies the SCSI Initiator Port. 2784 NOTE: A consequence of the ISID RULE and the specification for the 2785 I_T nexus identifier is that two nexus with the same identifier 2786 should never exist at the same time. 2788 TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH 2789 at session creation (when an initiator presents a 0 value at 2790 Login). After being selected, the same TSIH value MUST be used 2791 whenever initiator or target refers to the session and a TSIH is 2792 required. 2794 4.4.3.1. I_T Nexus State 2796 Certain nexus relationships contain an explicit state (e.g., 2797 initiator-specific mode pages) that may need to be preserved by 2798 the device server [SAM2] in a logical unit through changes or 2799 failures in the iSCSI layer (e.g., session failures). In order for 2800 that state to be restored, the iSCSI initiator should reestablish 2801 its session (re-login) to the same Target Portal Group using the 2802 previous ISID. That is, it should perform session recovery as 2803 described in Chapter 6. This is because the SCSI initiator port 2804 identifier and the SCSI target port identifier (or relative target 2805 port) form the datum that the SCSI logical unit device server uses 2806 to identify the I_T nexus. 2808 4.5. iSCSI UML Model 2810 This Section presents the application of the UML modeling concepts 2811 discussed in Section 3 to the iSCSI and SCSI architecture model 2812 discussed in Section 4.4. 2814 +----------------+ 2815 | Network Entity | 2816 +----------------+ 2817 @ 1 @ 1 2818 | | 2819 +--------------------+ | 2820 | | 2821 | | 0..* 2822 | +------------------+ 2823 | | iSCSI Node | 2824 | +------------------+ 2825 | @ @ 2826 | | | 2827 | +-----------+ =(a)= +-----------+ 2828 | | | 2829 | | 0..1 | 0..1 2830 | +------------------------+ +----------------------+ 2831 | | iSCSI Target Node | | iSCSI Initiator Node | 2832 | +------------------------+ +----------------------+ 2833 | @ 1 @ 1 2834 | +--------------+ | 2835 | 1..* | | 1..* 2836 | +-----------------------------+ 2837 | | Portal Group | 2838 | +-----------------------------+ 2839 | O 1 2840 | | 2841 | | 1..* 2842 | 1..* +------------------------+ 2843 +-------------------| Network Portal | 2844 +------------------------+ 2846 (a) Each instance of an iSCSI Node class MUST contain one iSCSI 2847 Target Node instance or one iSCSI Initiator Node instance, or 2848 both. 2850 +----------------+ 2851 | Network Entity | 2852 +----------------+ 2853 @ 1 @ 1 2854 | | +-------------------+ 2855 +---------------------+ | | iSCSI Session | 2856 | | +-------------------+ 2857 | | 0..* | SSID[1] | 2858 | +--------------------+ | ISID[1] | 2859 | | iSCSI Node | +-------------------+ 2860 | +--------------------+ @ 1 2861 | | iSCSI Node Name[1] | | 2862 | | Alias [0..1] | | 0..* 2863 | +--------------------+ +------------------+ 2864 | | | | iSCSI Connection | 2865 | +--------------------+ +------------------+ 2866 | @ 1 @ 1 | CID[1] | 2867 | | | +------------------+ 2868 | +-------------+ ==(b)== +----------+ 0..* | 2869 | | 1 | 1 | 2870 | +------------------------+ +------------------------+ | 2871 | | iSCSI Target Node | | iSCSI Initiator Node | | 2872 | +------------------------+ +------------------------+ | 2873 | | iSCSI Target name [1] | |iSCSI Initiator Name [1]| | 2874 | +------------------------+ +------------------------+ | 2875 | @ 1 @ 1 | 2876 | | 1..* | 1..* | 2877 | +--------------------------+ +------------------------+ | 2878 | | Target Portal Group | | Initiator Portal Group | | 2879 | +--------------------------+ +------------------------+ | 2880 | |Target Portal Group Tag[1]| | Portal group tag[1] | | 2881 | +--------------------------+ +------------------------+ | 2882 | o 1 o 1 | 2883 | +------------+ +---------+ | 2884 | 1..* | | 1..* | 2885 | +-------------------------+ | 2886 | | Network Portal | | 2887 | +-------------------------+ | 2888 | 1..* | IP Address [1] | 1 | 2889 +----------------| TCP Port [0..1] |<----------------------+ 2890 +-------------------------+ 2892 (b) Each instance of an iSCSI Node class MUST contain one iSCSI 2893 Target Node instance or one iSCSI Initiator Node instance, or 2894 both. However, in all scenarios, note that an iSCSI Node MUST 2895 only have a single iSCSI Name. Note the related requirement in 2896 Section 4.2.7.1. 2898 4.6. Request/Response Summary 2900 This Section lists and briefly describes all the iSCSI PDU types 2901 (request and responses). 2903 All iSCSI PDUs are built as a set of one or more header segments 2904 (basic and auxiliary) and zero or one data segments. The header 2905 group and the data segment may each be followed by a CRC (digest) 2906 (see [CRC]). 2908 The basic header segment has a fixed length of 48 bytes. 2910 4.6.1. Request/Response Types Carrying SCSI Payload 2912 4.6.1.1. SCSI-Command 2914 This request carries the SCSI CDB and all the other SCSI execute 2915 command procedure call (see [SAM2]) IN arguments such as task 2916 attributes, Expected Data Transfer Length for one or both transfer 2917 directions (the latter for bidirectional commands), and Task Tag 2918 (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the 2919 initiator and target from the LUN field in the request and the I_T 2920 nexus is implicit in the session identification. 2922 In addition, the SCSI-command PDU carries information required for 2923 the proper operation of the iSCSI protocol - the command sequence 2924 number (CmdSN) and the expected status number (ExpStatSN) on the 2925 connection it is issued. 2927 All or part of the SCSI output (write) data associated with the 2928 SCSI command may be sent as part of the SCSI-Command PDU as a data 2929 segment. 2931 4.6.1.2. SCSI-Response 2933 The SCSI-Response carries all the SCSI execute-command procedure 2934 call (see [SAM2]) OUT arguments and the SCSI execute-command 2935 procedure call return value. 2937 The SCSI-Response contains the residual counts from the operation, 2938 if any, an indication of whether the counts represent an overflow 2939 or an underflow, and the SCSI status if the status is valid or a 2940 response code (a non-zero return value for the execute-command 2941 procedure call) if the status is not valid. 2943 For a valid status that indicates that the command has been 2944 processed, but resulted in an exception (e.g., a SCSI CHECK 2945 CONDITION), the PDU data segment contains the associated sense 2946 data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI. 2948 Some data segment content may also be associated (in the data 2949 segment) with a non-zero response code. 2951 In addition, the SCSI-Response PDU carries information required 2952 for the proper operation of the iSCSI protocol: 2954 - The number of Data-In PDUs that a target has sent (to enable 2955 the initiator to check that all have arrived). 2957 - StatSN - the Status Sequence Number on this connection. 2959 - ExpCmdSN - the next Expected Command Sequence Number at the 2960 target. 2962 - MaxCmdSN - the maximum CmdSN acceptable at the target from 2963 this initiator. 2965 4.6.1.3. Task Management Function Request 2967 The Task Management function request provides an initiator with a 2968 way to explicitly control the execution of one or more SCSI Tasks 2969 or iSCSI functions. The PDU carries a function identifier (which 2970 task management function to perform) and enough information to 2971 unequivocally identify the task or task-set on which to perform 2972 the action, even if the task(s) to act upon has not yet arrived or 2973 has been discarded due to an error. 2975 The referenced tag identifies an individual task if the function 2976 refers to an individual task. 2978 The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is 2979 identified by the LUN and the session identification (the session 2980 identifies an I_T nexus). 2982 For task sets, the CmdSN of the Task Management function request 2983 helps identify the tasks upon which to act, namely all tasks 2984 associated with a LUN and having a CmdSN preceding the Task 2985 Management function request CmdSN. 2987 For a Task Management function, the coordination between responses 2988 to the tasks affected and the Task Management function response is 2989 done by the target. 2991 4.6.1.4. Task Management Function Response 2993 The Task Management function response carries an indication of 2994 function completion for a Task Management function request 2995 including how it completed (response and qualifier) and additional 2996 information for failure responses. 2998 After the Task Management response indicates Task Management 2999 function completion, the initiator will not receive any additional 3000 responses from the affected tasks. 3002 4.6.1.5. SCSI Data-out and SCSI Data-in 3004 SCSI Data-out and SCSI Data-in are the main vehicles by which SCSI 3005 data payload is carried between initiator and target. Data payload 3006 is associated with a specific SCSI command through the Initiator 3007 Task Tag. For target convenience, outgoing solicited data also 3008 carries a Target Transfer Tag (copied from R2T) and the LUN. Each 3009 PDU contains the payload length and the data offset relative to 3010 the buffer address contained in the SCSI execute command procedure 3011 call. 3013 In each direction, the data transfer is split into "sequences". An 3014 end-of-sequence is indicated by the F bit. 3016 An outgoing sequence is either unsolicited (only the first 3017 sequence can be unsolicited) or consists of all the Data-Out PDUs 3018 sent in response to an R2T. 3020 Input sequences enable the switching of direction for 3021 bidirectional commands as required. 3023 For input, the target may request positive acknowledgement of 3024 input data. This is limited to sessions that support error 3025 recovery and is implemented through the A bit in the SCSI Data-in 3026 PDU header. 3028 Data-in and Data-out PDUs also carry the DataSN to enable the 3029 initiator and target to detect missing PDUs (discarded due to an 3030 error). 3032 In addition, StatSN is carried by the Data-In PDUs. 3034 To enable a SCSI command to be processed while involving a minimum 3035 number of messages, the last SCSI Data-in PDU passed for a command 3036 may also contain the status if the status indicates termination 3037 with no exceptions (no sense or response involved). 3039 4.6.1.6. Ready To Transfer (R2T) 3041 R2T is the mechanism by which the SCSI target "requests" the 3042 initiator for output data. R2T specifies to the initiator the 3043 offset of the requested data relative to the buffer address from 3044 the execute command procedure call and the length of the solicited 3045 data. 3047 To help the SCSI target associate the resulting Data-out with an 3048 R2T, the R2T carries a Target Transfer Tag that will be copied by 3049 the initiator in the solicited SCSI Data-out PDUs. There are no 3050 protocol specific requirements with regard to the value of these 3051 tags, but it is assumed that together with the LUN, they will 3052 enable the target to associate data with an R2T. 3054 R2T also carries information required for proper operation of the 3055 iSCSI protocol, such as: 3057 - R2TSN (to enable an initiator to detect a missing R2T) 3059 - StatSN 3061 - ExpCmdSN 3063 - MaxCmdSN 3065 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload 3067 4.6.2.1. Asynchronous Message 3069 Asynchronous Messages are used to carry SCSI asynchronous events 3070 (AEN) and iSCSI asynchronous messages. 3072 When carrying an AEN, the event details are reported as sense data 3073 in the data segment. 3075 4.6.3. Requests/Responses Carrying iSCSI Only Payload 3077 4.6.3.1. Text Request and Text Response 3079 Text requests and responses are designed as a parameter 3080 negotiation vehicle and as a vehicle for future extension. 3082 In the data segment Text Requests/Responses carry text information 3083 using a simple "key=value" syntax. 3085 Text Request/Responses may form extended sequences using the same 3086 Initiator Task Tag. The initiator uses the F (Final) flag bit in 3087 the text request header to indicate its readiness to terminate a 3088 sequence. The target uses the F (Final) flag bit in the text 3089 response header to indicate its consent to sequence termination. 3091 Text Request and Responses also use the Target Transfer Tag to 3092 indicate continuation of an operation or a new beginning. A target 3093 that wishes to continue an operation will set the Target Transfer 3094 Tag in a Text Response to a value different from the default 3095 0xffffffff. An initiator willing to continue will copy this value 3096 into the Target Transfer Tag of the next Text Request. If the 3097 initiator wants to restart the current target negotiation (start 3098 fresh) will set the Target Transfer Tag to 0xffffffff. 3100 Although a complete exchange is always started by the initiator, 3101 specific parameter negotiations may be initiated by the initiator 3102 or target. 3104 4.6.3.2. Login Request and Login Response 3106 Login Requests and Responses are used exclusively during the Login 3107 Phase of each connection to set up the session and connection 3108 parameters. (The Login Phase consists of a sequence of login 3109 requests and responses carrying the same Initiator Task Tag.) 3111 A connection is identified by an arbitrarily selected connection- 3112 ID (CID) that is unique within a session. 3114 Similar to the Text Requests and Responses, Login 3115 Requests/Responses carry key=value text information with a simple 3116 syntax in the data segment. 3118 The Login Phase proceeds through several stages (security 3119 negotiation, operational parameter negotiation) that are selected 3120 with two binary coded fields in the header -- the "current stage" 3121 (CSG) and the "next stage" (NSG) with the appearance of the latter 3122 being signaled by the "transit" flag (T). 3124 The first Login Phase of a session plays a special role, called 3125 the leading login, which determines some header fields (e.g., the 3126 version number, the maximum number of connections, and the session 3127 identification). 3129 The CmdSN initial value is also set by the leading login. 3131 StatSN for each connection is initiated by the connection login. 3133 A login request may indicate an implied logout (cleanup) of the 3134 connection to be logged in (a connection restart) by using the 3135 same Connection ID (CID) as an existing connection as well as the 3136 same session identifying elements of the session to which the old 3137 connection was associated. 3139 4.6.3.3. Logout Request and Response 3141 Logout Requests and Responses are used for the orderly closing of 3142 connections for recovery or maintenance. The logout request may be 3143 issued following a target prompt (through an asynchronous message) 3144 or at an initiators initiative. When issued on the connection to 3145 be logged out no other request may follow it. 3147 The Logout response indicates that the connection or session 3148 cleanup is completed and no other responses will arrive on the 3149 connection (if received on the logging out connection). In 3150 addition, the Logout Response indicates how long the target will 3151 continue to hold resources for recovery (e.g., command execution 3152 that continues on a new connection) in the text key Time2Retain 3153 and how long the initiator must wait before proceeding with 3154 recovery in the text key Time2Wait. 3156 4.6.3.4. SNACK Request 3158 With the SNACK Request, the initiator requests retransmission of 3159 numbered-responses or data from the target. A single SNACK request 3160 covers a contiguous set of missing items, called a run, of a given 3161 type of items. The type is indicated in a type field in the PDU 3162 header. The run is composed of an initial item (StatSN, DataSN, 3163 R2TSN) and the number of missed Status, Data, or R2T PDUs. For 3164 long data-in sequences, the target may request (at predefined 3165 minimum intervals) a positive acknowledgement for the data sent. A 3166 SNACK request with a type field that indicates ACK and the number 3167 of Data-In PDUs acknowledged conveys this positive 3168 acknowledgement. 3170 4.6.3.5. Reject 3172 Reject enables the target to report an iSCSI error condition 3173 (e.g., protocol, unsupported option) that uses a Reason field in 3174 the PDU header and includes the complete header of the bad PDU in 3175 the Reject PDU data segment. 3177 4.6.3.6. NOP-Out Request and NOP-In Response 3179 This request/response pair may be used by an initiator and target 3180 as a "ping" mechanism to verify that a connection/session is still 3181 active and all of its components are operational. Such a ping may 3182 be triggered by the initiator or target. The triggering party 3183 indicates that it wants a reply by setting a value different from 3184 the default 0xffffffff in the corresponding Initiator/Target 3185 Transfer Tag. 3187 NOP-In/NOP-Out may also be used "unidirectional" to convey to the 3188 initiator/target command, status or data counter values when there 3189 is no other "carrier" and there is a need to update the 3190 initiator/target. 3192 5. SCSI Mode Parameters for iSCSI 3194 There are no iSCSI specific mode pages. 3196 6. Login and Full Feature Phase Negotiation 3198 iSCSI parameters are negotiated at session or connection 3199 establishment by using Login Requests and Responses (see Section 3200 4.2.4 - "iSCSI Login") and during Full Feature Phase (Section 3201 4.2.5- "iSCSI Full Feature Phase") by using Text Requests and 3202 Responses. In both cases the mechanism used is an exchange of 3203 iSCSI-text-key=value pairs. For brevity, iSCSI-text-keys are 3204 called just keys in the rest of this document. 3206 Keys are either declarative or require negotiation and the key 3207 description indicates if the key is declarative or requires 3208 negotiation. 3210 For the declarative keys the declaring party sets a value for the 3211 key. The key specification indicates if the key can be declared by 3212 the initiator, target or both. 3214 For the keys that require negotiation, one of the parties (the 3215 proposing party) proposes a value or set of values by including 3216 the key=value in the data part of a Login or Text Request or 3217 Response. The other party (the accepting party) makes a selection 3218 based on the value or list of values proposed and includes the 3219 selected value in a key=value in the data part of the following 3220 Login or Text Response or Request. For most of the keys, both the 3221 initiator and target can be proposing parties. 3223 The login process proceeds in two stages - the security 3224 negotiation stage and the operational parameter negotiation stage. 3225 Both stages are optional but at least one of them has to be 3226 present to enable setting some mandatory parameters. 3228 If present, the security negotiation stage precedes the 3229 operational parameter negotiation stage. 3231 Progression from stage to stage is controlled by the T 3232 (Transition) bit in the Login Request/Response PDU header. Through 3233 the T bit set to 1, the initiator indicates that it would like to 3234 transition. The target agrees to the transition (and selects the 3235 next stage) when ready. A field in the Login PDU header indicates 3236 the current stage (CSG) and during transition, another field 3237 indicates the next stage (NSG) proposed (initiator) and selected 3238 (target). 3240 The Text negotiation process is used to negotiate or declare 3241 operational parameters. The negotiation process is controlled by 3242 the F (final) bit in the PDU header. During text negotiations, the 3243 F bit is used by the initiator to indicate that it is ready to 3244 finish the negotiation and by the Target to acquiesce the end of 3245 negotiation. 3247 Since some key=value pairs may not fit entirely in a single PDU, 3248 the C (continuation) bit is used (both in Login and Text) to 3249 indicate that "more follows". 3251 The text negotiation uses an additional mechanism by which a 3252 target may deliver larger amounts of data to an enquiring 3253 initiator. The target sets a Target Task Tag to be used as a 3254 bookmark which when returned by the initiator, means "go on". If 3255 reset to a "neutral value", it means "forget about the rest". 3257 This chapter details types of keys and values used, the syntax 3258 rules for parameter formation, and the negotiation schemes to be 3259 used with different types of parameters. 3261 6.1. Text Format 3263 The initiator and target send a set of key=value pairs encoded in 3264 UTF-8 Unicode. All the text keys and text values specified in this 3265 document are to be presented and interpreted in the case in which 3266 they appear in this document. They are case sensitive. 3268 The following character symbols are used in this document for text 3269 items (the hexadecimal values represent Unicode code points): 3271 (a-z, A-Z) - letters 3272 (0-9) - digits 3273 " " (0x20) - space 3274 "." (0x2e) - dot 3275 "-" (0x2d) - minus 3276 "+" (0x2b) - plus 3277 "@" (0x40) - commercial at 3278 "_" (0x5f) - underscore 3280 "=" (0x3d) - equal 3281 ":" (0x3a) - colon 3282 "/" (0x2f) - solidus or slash 3283 "[" (0x5b) - left bracket 3284 "]" (0x5d) - right bracket 3285 null (0x00) - null separator 3286 "," (0x2c) - comma 3287 "~" (0x7e) - tilde 3289 Key=value pairs may span PDU boundaries. An initiator or target 3290 that sends partial key=value text within a PDU indicates that more 3291 text follows by setting the C bit in the Text or Login Request or 3292 Text or Login Response to 1. Data segments in a series of PDUs 3293 that have the C bit set to 1 and end with a PDU that have the C 3294 bit set to 0, or include a single PDU that has the C bit set to 0 3295 have to be considered as forming a single logical-text-data- 3296 segment (LTDS). 3298 Every key=value pair, including the last or only pair in a LTDS, 3299 MUST be followed by one null (0x00) delimiter. 3301 A key-name is whatever precedes the first = in the key=value pair. 3302 The term key is used frequently in this document in place of key- 3303 name. 3305 A value is whatever follows the first = in the key=value pair up 3306 to the end of the key=value pair, but not including the null 3307 delimiter. 3309 The following definitions will be used in the rest of this 3310 document: 3312 standard-label: A string of one or more characters that 3313 consist of letters, digits, dot, minus, plus, commercial at, 3314 or underscore. A standard-label MUST begin with a capital 3315 letter and must not exceed 63 characters. 3317 key-name: A standard-label. 3319 text-value: A string of zero or more characters that consist 3320 of letters, digits, dot, minus, plus, commercial at, 3321 underscore, slash, left bracket, right bracket, or colon. 3323 iSCSI-name-value: A string of one or more characters that 3324 consist of minus, dot, colon, or any character allowed by 3325 the output of the iSCSI string-prep template as specified in 3326 [RFC3722] (see also Section 4.2.7.2- "iSCSI Name Encoding"). 3328 iSCSI-local-name-value: A UTF-8 string; no null characters are 3329 allowed in the string. This encoding is to be used for 3330 localized (internationalized) aliases. 3332 boolean-value: The string "Yes" or "No". 3334 hex-constant: A hexadecimal constant encoded as a string that 3335 starts with "0x" or "0X" followed by one or more digits or 3336 the letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex- 3337 constants are used to encode numerical values or binary 3338 strings. When used to encode numerical values, the excessive 3339 use of leading 0 digits is discouraged. The string following 3340 0X (or 0x) represents a base16 number that starts with the 3341 most significant base16 digit, followed by all other digits 3342 in decreasing order of significance and ending with the 3343 least-significant base16 digit. When used to encode binary 3344 strings, hexadecimal constants have an implicit byte-length 3345 that includes four bits for every hexadecimal digit of the 3346 constant, including leading zeroes. For example, a hex- 3347 constant of n hexadecimal digits has a byte-length of (the 3348 integer part of) (n+1)/2. 3350 decimal-constant: An unsigned decimal number with the digit 0 3351 or a string of one or more digits that start with a non-zero 3353 digit. Decimal-constants are used to encode numerical 3354 values or binary strings. Decimal constants can only be used 3355 to encode binary strings if the string length is explicitly 3356 specified. There is no implicit length for decimal strings. 3357 Decimal-constant MUST NOT be used for parameter values if 3358 the values can be equal or greater than 2**64 (numerical) or 3359 for binary strings that can be longer than 64 bits. 3361 base64-constant: base64 constant encoded as a string that 3362 starts with "0b" or "0B" followed by 1 or more digits or 3363 letters or plus or slash or equal. The encoding is done 3364 according to [RFC2045] and each character, except equal, 3365 represents a base64 digit or a 6-bit binary string. Base64- 3366 constants are used to encode numerical-values or binary 3367 strings. When used to encode numerical values, the excessive 3368 use of leading 0 digits (encoded as A) is discouraged. The 3369 string following 0B (or 0b) represents a base64 number that 3370 starts with the most significant base64 digit, followed by 3371 all other digits in decreasing order of significance and 3372 ending with the least-significant base64 digit; the least 3373 significant base64 digit may be optionally followed by pad 3374 digits (encoded as equal) that are not considered as part of 3375 the number. When used to encode binary strings, base64- 3376 constants have an implicit byte-length that includes six 3377 bits for every character of the constant, excluding trailing 3378 equals (i.e., a base64-constant of n base64 characters 3379 excluding the trailing equals has a byte-length of ((the 3380 integer part of) (n*3/4)). Correctly encoded base64 strings 3381 cannot have n values of 1, 5 ... k*4+1. 3383 numerical-value: An unsigned integer always less than 2**64 3384 encoded as a decimal-constant or a hex-constant. Unsigned 3385 integer arithmetic applies to numerical-values. 3387 large-numerical-value: An unsigned integer that can be larger 3388 than or equal to 2**64 encoded as a hex constant, or base64- 3389 constant. Unsigned integer arithmetic applies to large- 3390 numeric-values. 3392 numeric-range: Two numerical-values separated by a tilde where 3393 the value to the right of tilde must not be lower than the 3394 value to the left. 3396 regular-binary-value: A binary string not longer than 64 bits 3397 encoded as a decimal constant, hex constant, or base64- 3398 constant. The length of the string is either specified by 3399 the key definition or is the implicit byte-length of the 3400 encoded string. 3402 large-binary-value: A binary string longer than 64 bits 3403 encoded as a hex-constant or base64-constant. The length of 3404 the string is either specified by the key definition or is 3405 the implicit byte-length of the encoded string. 3407 binary-value: A regular-binary-value or a large-binary-value. 3408 Operations on binary values are key specific. 3410 simple-value: Text-value, iSCSI-name-value, boolean-value, 3411 numeric-value, a numeric-range, or a binary-value. 3413 list-of-values: A sequence of text-values separated by a 3414 comma. 3416 If not otherwise specified, the maximum length of a simple-value 3417 (not its encoded representation) is 255 bytes not including the 3418 delimiter (comma or zero byte). 3420 Any iSCSI target or initiator MUST support receiving at least 8192 3421 bytes of key=value data in a negotiation sequence. When proposing 3422 or accepting authentication methods that explicitly require 3423 support for very long authentication items, the initiator and 3424 target MUST support receiving of at least 64 kilobytes of 3425 key=value data. 3427 6.2. Text Mode Negotiation 3429 During login, and thereafter, some session or connection 3430 parameters are either declared or negotiated through an exchange 3431 of textual information. 3433 The initiator starts the negotiation and/or declaration through a 3434 Text or Login request and indicates when it is ready for 3435 completion (by setting the F bit to 1 and keeping it to 1 in a 3436 Text Request or the T bit in the Login Request). As negotiation 3437 text may span PDU boundaries, a Text or Login Request or Text or 3438 Login Response PDU that have the C bit set to 1 MUST NOT have the 3439 F/T bit set to 1. 3441 A target receiving a Text or Login Request with the C bit set to 1 3442 MUST answer with a Text or Login Response with no data segment 3443 (DataSegmentLength 0). An initiator receiving a Text or Login 3444 Response with the C bit set to 1 MUST answer with a Text or Login 3445 Request with no data segment (DataSegmentLength 0). 3447 A target or initiator SHOULD NOT use a Text or Login Response or 3448 Text or Login Request with no data segment (DataSegmentLength 0) 3449 unless explicitly required by a general or a key-specific 3450 negotiation rule. 3452 There MUST NOT be more than one outstanding Text Request, or Text 3453 Response PDU on an iSCSI connection. An outstanding PDU in this 3454 context is one that has not been acknowledged by the remote iSCSI 3455 side. 3457 The format of a declaration is: 3459 Declarer-> = 3461 The general format of text negotiation is: 3463 Proposer-> = 3465 Acceptor-> ={|NotUnderstood|Irrelevant|Reject} 3467 Thus a declaration is a one-way textual exchange (unless the key 3468 is not understood by the receiver) while a negotiation is a two- 3469 way exchange. 3471 The proposer or declarer can either be the initiator or the 3472 target, and the acceptor can either be the target or initiator, 3473 respectively. Targets are not limited to respond to key=value 3474 pairs as proposed by the initiator. The target may propose 3475 key=value pairs of its own. 3477 All negotiations are explicit (i.e., the result MUST only be based 3478 on newly exchanged or declared values). There are no implicit 3479 proposals. If a proposal is not made, then a reply cannot be 3480 expected. Conservative design also requires that default values 3481 should not be relied upon when use of some other value has serious 3482 consequences. 3484 The value proposed or declared can be a numerical-value, a 3485 numerical-range defined by lower and upper value with both 3486 integers separated by tilde, a binary value, a text-value, an 3487 iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes 3488 or No), or a list of comma separated text-values. A range, a 3489 large-numerical-value, an iSCSI-name-value and an iSCSI-local- 3490 name-value MAY ONLY be used if it is explicitly allowed. An 3491 accepted value can be a numerical-value, a large-numerical-value, 3492 a text-value, or a boolean-value. 3494 If a specific key is not relevant for the current negotiation, the 3495 acceptor may answer with the constant "Irrelevant" for all types 3496 of negotiation. However the negotiation is not considered as 3497 failed if the answer is "Irrelevant". The "Irrelevant" answer is 3498 meant for those cases in which several keys are presented by a 3499 proposing party but the selection made by the acceptor for one of 3500 the keys makes other keys irrelevant. The following example 3501 illustrates the use of "Irrelevant": 3503 I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192 3504 T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant 3506 I->T X-rdname-vkey1=(bla,alb,None), X-rdname-vkey2=(bla,alb) 3507 T->I X-rdname-vkey1=None, X-rdname-vkey2=Irrelevant 3509 Any key not understood by the acceptor may be ignored by the 3510 acceptor without affecting the basic function. However, the answer 3511 for a key not understood MUST be key=NotUnderstood. Note that 3512 NotUnderstood is a valid answer for both declarative and 3513 negotiated keys. The general iSCSI philosophy is that 3514 comprehension precedes processing for any iSCSI key. A proposer 3515 of an iSCSI key, negotiated or declarative, in a text key exchange 3516 MUST thus be able to properly handle a NotUnderstood response. 3518 The proper way to handle a NotUnderstood response depends on where 3519 the key is specified and whether the key is declarative vs. 3520 negotiated. An iSCSI implementation MUST comprehend all text keys 3521 defined in iSCSI Protocol specifications from [RFC3720] through 3522 the RFC associated with the highest protocol version that the 3523 implementation has offered (or has negotiated, in the case of an 3524 acceptor) for the iSCSIProtocolLevel key in a negotiation. 3525 Returning a NotUnderstood response on any of these text keys 3526 therefore MUST be considered a protocol error and handled 3527 accordingly. For all other "later" keys, i.e. text keys defined 3528 in specifications associated with higher values of 3529 iSCSIProtocolLevel, a NotUnderstood answer concludes the 3530 negotiation for a negotiated key whereas for a declarative key, a 3531 NotUnderstood answer simply informs the declarer of a lack of 3532 comprehension by the receiver. 3534 In either case, a NotUnderstood answer always requires that the 3535 protocol behavior associated with that key not be used within the 3536 scope of the key (connection/session) by either side. 3538 The constants "None", "Reject", "Irrelevant", and "NotUnderstood" 3539 are reserved and MUST ONLY be used as described here. Violation of 3540 this rule is a protocol error (in particular the use of "Reject", 3541 "Irrelevant", and "NotUnderstood" as proposed values). 3543 Reject or Irrelevant are legitimate negotiation options where 3544 allowed but their excessive use is discouraged. A negotiation is 3545 considered complete when the acceptor has sent the key value pair 3546 even if the value is "Reject", "Irrelevant", or "NotUnderstood". 3547 Sending the key again would be a re-negotiation and is forbidden 3548 for many keys. 3550 If the acceptor sends "Reject" as an answer the negotiated key is 3551 left at its current value (or default if no value was set). If the 3552 current value is not acceptable to the proposer on the connection 3553 or to the session it is sent, the proposer MAY choose to terminate 3554 the connection or session. 3556 All keys in this document MUST be supported by iSCSI initiators 3557 and targets when used as specified here. If used as specified, 3558 these keys MUST NOT be answered with NotUnderstood. 3560 Implementers may introduce new private keys by prefixing them with 3561 X- followed by their (reversed) domain name, or with new public 3562 keys registered with IANA. For example, the entity owning the 3563 domain example.com can issue: 3565 X-com.example.bar.foo.do_something=3 3567 Each new public key in the course of standardization MUST define 3568 the acceptable responses to the key, including NotUnderstood as 3569 appropriate. Unlike [RFC3720], note that this document prohibits 3570 the X# prefix for new public keys. Based on iSCSI implementation 3571 experience, we know that there is no longer a need for a standard 3572 name prefix for keys that allow NotUnderstood response. Note that 3573 NotUnderstood will generally have to be allowed for new public 3574 keys for backwards compatibility, as well as for private X- keys. 3575 Thus the name prefix "X#" in new public key names does not carry 3576 any significance. New public key names MUST NOT begin with "X#" 3577 prefix to avoid confusion. 3579 Implementers MAY also introduce new values, but ONLY for new keys 3580 or authentication methods (see Section 12), or digests (see 3581 Section 13.1). 3583 Whenever parameter action or acceptance are dependent on other 3584 parameters, the dependency rules and parameter sequence must be 3585 specified with the parameters. 3587 In the Login Phase (see Section 6.3), every stage is a separate 3588 negotiation. In the FullFeaturePhase, a Text Request Response 3589 sequence is a negotiation. Negotiations MUST be handled as atomic 3590 operations. For example, all negotiated values go into effect 3591 after the negotiation concludes in agreement or are ignored if the 3592 negotiation fails. 3594 Some parameters may be subject to integrity rules (e.g., 3595 parameter-x must not exceed parameter-y or parameter-u not 1 3596 implies parameter-v be Yes). Whenever required, integrity rules 3597 are specified with the keys. Checking for compliance with the 3598 integrity rule must only be performed after all the parameters are 3599 available (the existent and the newly negotiated). An iSCSI target 3600 MUST perform integrity checking before the new parameters take 3601 effect. An initiator MAY perform integrity checking. 3603 An iSCSI initiator or target MAY terminate a negotiation that does 3604 not terminate within an implementation-specific reasonable time or 3605 number of exchanges, but SHOULD allow at least six (6) exchanges. 3606 6.2.1. List negotiations 3608 In list negotiation, the originator sends a list of values (which 3609 may include "None") in its order of preference. 3611 The responding party MUST respond with the same key and the first 3612 value that it supports (and is allowed to use for the specific 3613 originator) selected from the originator list. 3615 The constant "None" MUST always be used to indicate a missing 3616 function. However, "None" is only a valid selection if it is 3617 explicitly proposed. 3619 If an acceptor does not understand any particular value in a list, 3620 it MUST ignore it. If an acceptor does not support, does not 3621 understand, or is not allowed to use any of the proposed options 3622 with a specific originator, it may use the constant "Reject" or 3623 terminate the negotiation. The selection of a value not proposed 3624 MUST be handled as a protocol error. 3626 6.2.2. Simple-value Negotiations 3628 For simple-value negotiations, the accepting party MUST answer 3629 with the same key. The value it selects becomes the negotiation 3630 result. 3632 Proposing a value not admissible (e.g., not within the specified 3633 bounds) MAY be answered with the constant "Reject", otherwise the 3634 acceptor MUST select an admissible value. 3636 The selection, by the acceptor, of a value not admissible under 3637 the selection rules is considered a protocol error. The selection 3638 rules are key-specific. 3640 For a numerical range the value selected MUST be an integer within 3641 the proposed range or "Reject" (if the range is unacceptable). 3643 For Boolean negotiations (i.e., keys taking the values Yes or No), 3644 the accepting party MUST answer with the same key and the result 3645 of the negotiation when the received value does not determine that 3646 result by itself. The last value transmitted becomes the 3647 negotiation result. The rules for selecting the value to answer 3648 with are expressed as Boolean functions of the value received, and 3649 the value that the accepting party would have selected if given a 3650 choice. 3652 Specifically, the two cases in which answers are OPTIONAL are: 3654 - The Boolean function is "AND" and the value "No" is 3655 received. The outcome of the negotiation is "No". 3657 - The Boolean function is "OR" and the value "Yes" is 3658 received. The outcome of the negotiation is "Yes". 3660 Responses are REQUIRED in all other cases, and the value chosen 3661 and sent by the acceptor becomes the outcome of the negotiation. 3663 6.3. Login Phase 3665 The Login Phase establishes an iSCSI connection between an 3666 initiator and a target; it creates also a new session or 3667 associates the connection to an existing session. The Login Phase 3668 sets the iSCSI protocol parameters, security parameters, and 3669 authenticates the initiator and target to each other. 3671 The Login Phase is only implemented via Login request and 3672 responses. The whole Login Phase is considered as a single task 3673 and has a single Initiator Task Tag (similar to the linked SCSI 3674 commands). 3676 There MUST NOT be more than one outstanding Login Request, or 3677 Login Response on an iSCSI connection. An outstanding PDU in this 3678 context is one that has not been acknowledged by the remote iSCSI 3679 side. 3681 The default MaxRecvDataSegmentLength is used during Login. 3683 The Login Phase sequence of requests and responses proceeds as 3684 follows: 3686 - Login initial request 3688 - Login partial response (optional) 3690 - More Login requests and responses (optional) 3692 - Login Final-Response (mandatory) 3694 The initial login request of any connection MUST include the 3695 InitiatorName key=value pair. The initial login request of the 3696 first connection of a session MAY also include the SessionType 3697 key=value pair. For any connection within a session whose type is 3698 not "Discovery", the first login request MUST also include the 3699 TargetName key=value pair. 3701 The Login Final-response accepts or rejects the Login request. 3703 The Login Phase MAY include a SecurityNegotiation stage and a 3704 LoginOperationalNegotiation stage and MUST include at least one of 3705 them, but the included stage MAY be empty except for the mandatory 3706 names. 3708 The login requests and responses contain a field (CSG) that 3709 indicates the current negotiation stage (SecurityNegotiation or 3710 LoginOperationalNegotiation). If both stages are used, the 3711 SecurityNegotiation MUST precede the LoginOperationalNegotiation. 3713 Some operational parameters can be negotiated outside the login 3714 through Text requests and responses. 3716 Security MUST be completely negotiated within the Login Phase. The 3717 use of underlying IPsec security is specified in Chapter 8 and in 3718 [RFC3723]. iSCSI support for security within the protocol only 3719 consists of authentication in the Login Phase. 3721 In some environments, a target or an initiator is not interested 3722 in authenticating its counterpart. It is possible to bypass 3723 authentication through the Login request and response. 3725 The initiator and target MAY want to negotiate iSCSI 3726 authentication parameters. Once this negotiation is completed, the 3727 channel is considered secure. 3729 Most of the negotiation keys are only allowed in a specific stage. 3730 The SecurityNegotiation keys appear in Chapter 11 and the 3731 LoginOperationalNegotiation keys appear in Chapter 12. Only a 3732 limited set of keys (marked as Any-Stage in Chapter 12) may be 3733 used in any of the two stages. 3735 Any given Login request or response belongs to a specific stage; 3736 this determines the negotiation keys allowed with the request or 3737 response. It is considered to be a protocol error to send a key 3738 not allowed in the current stage. 3740 Stage transition is performed through a command exchange 3741 (request/response) that carries the T bit and the same CSG code. 3742 During this exchange, the next stage is selected by the target 3743 through the "next stage" code (NSG). The selected NSG MUST NOT 3744 exceed the value stated by the initiator. The initiator can 3745 request a transition whenever it is ready, but a target can only 3746 respond with a transition after one is proposed by the initiator. 3748 In a negotiation sequence, the T bit settings in one pair of login 3749 request-responses have no bearing on the T bit settings of the 3750 next pair. An initiator that has a T bit set to 1 in one pair and 3751 is answered with a T bit setting of 0 may issue the next request 3752 with T bit set to 0. 3754 When a transition is requested by the initiator and acknowledged 3755 by the target, both the initiator and target switch to the 3756 selected stage. 3758 Targets MUST NOT submit parameters that require an additional 3759 initiator login request in a login response with the T bit set to 3760 1. 3762 Stage transitions during login (including entering and exit) are 3763 only possible as outlined in the following table: 3765 +-----------------------------------------------------------+ 3766 |From To -> | Security | Operational | FullFeature | 3767 | | | | | | 3768 | V | | | | 3769 +-----------------------------------------------------------+ 3770 | (start) | yes | yes | no | 3771 +-----------------------------------------------------------+ 3772 | Security | no | yes | yes | 3773 +-----------------------------------------------------------+ 3774 | Operational | no | no | yes | 3775 +-----------------------------------------------------------+ 3777 The Login Final-Response that accepts a Login Request can only 3778 come as a response to a Login request with the T bit set to 1, 3779 and both the request and response MUST indicate FullFeaturePhase 3780 as the next phase via the NSG field. 3782 Neither the initiator nor the target should attempt to declare or 3783 negotiate a parameter more than once during login except for 3784 responses to specific keys that explicitly allow repeated key 3785 declarations (e.g., TargetAddress). An attempt to 3786 renegotiate/redeclare parameters not specifically allowed MUST be 3787 detected by the initiator and target. If such an attempt is 3788 detected by the target, the target MUST respond with Login reject 3789 (initiator error); if detected by the initiator, the initiator 3790 MUST drop the connection. 3792 6.3.1. Login Phase Start 3794 The Login Phase starts with a login request from the initiator to 3795 the target. The initial login request includes: 3797 -Protocol version supported by the initiator. 3799 -iSCSI Initiator Name and iSCSI Target Name 3801 -ISID, TSIH, and connection Ids 3803 -Negotiation stage that the initiator is ready to enter. 3805 A login may create a new session or it may add a connection to an 3806 existing session. Between a given iSCSI Initiator Node (selected 3807 only by an InitiatorName) and a given iSCSI target defined by an 3808 iSCSI TargetName and a Target Portal Group Tag, the login results 3809 are defined by the following table: 3811 +----------------------------------------------------------------+ 3812 |ISID | TSIH | CID | Target action | 3813 +----------------------------------------------------------------+ 3814 |new | non-zero | any | fail the login | 3815 | | | | ("session does not exist") | 3816 +----------------------------------------------------------------+ 3817 |new | zero | any | instantiate a new session | 3818 +----------------------------------------------------------------+ 3819 |existing| zero | any | do session reinstatement | 3820 | | | | (see Section 6.3.5) | 3821 +----------------------------------------------------------------+ 3822 |existing| non-zero | new | add a new connection to | 3823 | | existing | | the session | 3824 +----------------------------------------------------------------+ 3825 |existing| non-zero |existing| do connection reinstatement| 3826 | | existing | | (see Section 7.1.4.3) | 3827 +----------------------------------------------------------------+ 3828 |existing| non-zero | any | fail the login | 3829 | | new | | ("session does not exist") | 3830 +----------------------------------------------------------------+ 3832 Determination of "existing" or "new" are made by the target. 3834 Optionally, the login request may include: 3836 -Security parameters 3837 OR 3839 -iSCSI operational parameters 3840 AND/OR 3842 -The next negotiation stage that the initiator is ready to 3843 enter. 3845 The target can answer the login in the following ways: 3847 -Login Response with Login reject. This is an immediate 3848 rejection from the target that causes the connection to 3849 terminate and the session to terminate if this is the first 3850 (or only) connection of a new session. The T bit and the CSG 3851 and NSG fields are reserved. 3853 -Login Response with Login accept as a final response (T bit 3854 set to 1 and the NSG in both request and response are set to 3855 FullFeaturePhase). The response includes the protocol 3856 version supported by the target and the session ID, and may 3857 include iSCSI operational or security parameters (that 3858 depend on the current stage). 3860 -Login Response with Login Accept as a partial response (NSG 3861 not set to FullFeaturePhase in both request and response) 3863 that indicates the start of a negotiation sequence. The 3864 response includes the protocol version supported by the 3865 target and either security or iSCSI parameters (when no 3866 security mechanism is chosen) supported by the target. 3868 If the initiator decides to forego the SecurityNegotiation stage, 3869 it issues the Login with the CSG set to 3870 LoginOperationalNegotiation and the target may reply with a Login 3871 Response that indicates that it is unwilling to accept the 3872 connection (see Section 11.13 - "Login Response") without 3873 SecurityNegotiation and will terminate the connection with a 3874 response of Authentication failure (see Section 11.13.5 - "Status- 3875 Class and Status-Detail"). 3877 If the initiator is willing to negotiate iSCSI security, but is 3878 unwilling to make the initial parameter proposal and may accept a 3879 connection without iSCSI security, it issues the Login with the T 3880 bit set to 1, the CSG set to SecurityNegotiation, and NSG set to 3881 LoginOperationalNegotiation. If the target is also ready to skip 3882 security, the login response only contains the 3883 TargetPortalGroupTag key (see Section 13.9- 3884 "TargetPortalGroupTag"), the T bit set to 1, the CSG set to 3885 SecurityNegotiation, and NSG set to LoginOperationalNegotiation. 3887 An initiator that chooses to operate without iSCSI security and 3888 with all the operational parameters taking the default values 3889 issues the Login with the T bit set to 1, the CSG set to 3890 LoginOperationalNegotiation, and NSG set to FullFeaturePhase. If 3891 the target is also ready to forego security and can finish its 3892 LoginOperationalNegotiation, the Login response has T bit set to 3893 1, the CSG set to LoginOperationalNegotiation, and NSG set to 3894 FullFeaturePhase in the next stage. 3896 During the Login Phase the iSCSI target MUST return the 3897 TargetPortalGroupTag key with the first Login Response PDU with 3898 which it is allowed to do so (i.e., the first Login Response 3899 issued after the first Login Request with the C bit set to 0) for 3900 all session types. The TargetPortalGroupTag key value indicates 3901 the iSCSI portal group servicing the Login Request PDU. If the 3902 reconfiguration of iSCSI portal groups is a concern in a given 3903 environment, the iSCSI initiator should use this key to ascertain 3904 that it had indeed initiated the Login Phase with the intended 3905 target portal group. 3907 6.3.2. iSCSI Security Negotiation 3909 The security exchange sets the security mechanism and 3910 authenticates the initiator user and the target to each other. The 3911 exchange proceeds according to the authentication method chosen in 3912 the negotiation phase and is conducted using the login requests' 3913 and responses' key=value parameters. 3915 An initiator directed negotiation proceeds as follows: 3917 -The initiator sends a login request with an ordered list of 3918 the options it supports (authentication algorithm). The 3919 options are listed in the initiator's order of preference. 3920 The initiator MAY also send private or public extension 3921 options. 3923 -The target MUST reply with the first option in the list it 3924 supports and is allowed to use for the specific initiator 3925 unless it does not support any in which case it MUST answer 3926 with "Reject" (see Section 6.2). The parameters are encoded 3927 in UTF8 as key=value. For security parameters, see Section 3928 12. 3930 -When the initiator considers that it is ready to conclude the 3931 SecurityNegotiation stage, it sets the T bit to 1 and the 3932 NSG to what it would like the next stage to be. The target 3933 will then set the T bit to 1 and set NSG to the next stage 3934 in the Login response when it finishes sending its security 3935 keys. The next stage selected will be the one the target 3936 selected. If the next stage is FullFeaturePhase, the target 3937 MUST respond with a Login Response with the TSIH value. 3939 If the security negotiation fails at the target, then the target 3940 MUST send the appropriate Login Response PDU. If the security 3941 negotiation fails at the initiator, the initiator SHOULD close the 3942 connection. 3944 It should be noted that the negotiation might also be directed by 3945 the target if the initiator does support security, but is not 3946 ready to direct the negotiation (propose options). 3948 6.3.3. Operational Parameter Negotiation During the Login Phase 3950 Operational parameter negotiation during the login MAY be done: 3952 - Starting with the first Login request if the initiator does 3953 not propose any security/ integrity option. 3955 - Starting immediately after the security negotiation if the 3956 initiator and target perform such a negotiation. 3958 Operational parameter negotiation MAY involve several Login 3959 request-response exchanges started and terminated by the 3960 initiator. The initiator MUST indicate its intent to terminate the 3961 negotiation by setting the T bit to 1; the target sets the T bit 3962 to 1 on the last response. 3964 Even when the initiator indicates its intent to switch stage by 3965 setting the T bit to 1 in a Login request, the target MAY respond 3966 with a Login response with the T bit set to 0. In that case, the 3967 initiator SHOULD continue to set the T bit to 1 in subsequent 3968 Login requests (even empty) that it sends, until target sends a 3969 Login response with the T bit set to 1 or sends a key that 3970 requires initiator to set the T bit to 0. 3972 Some session specific parameters can only be specified during the 3973 Login Phase of the first connection of a session (i.e., begun by a 3974 login request that contains a zero-valued TSIH) - the leading 3975 Login Phase (e.g., the maximum number of connections that can be 3976 used for this session). 3978 A session is operational once it has at least one connection in 3979 FullFeaturePhase. New or replacement connections can only be added 3980 to a session after the session is operational. 3982 For operational parameters, see Chapter 12. 3984 6.3.4. Connection Reinstatement 3986 Connection reinstatement is the process of an initiator logging in 3987 with a ISID-TSIH-CID combination that is possibly active from the 3988 target's perspective, which causes the implicit logging out of the 3989 connection corresponding to the CID and reinstating a new Full 3990 Feature Phase iSCSI connection in its place (with the same CID). 3991 Thus, the TSIH in the Login Request PDU MUST be non-zero and CID 3992 does not change during a connection reinstatement. The Login 3993 request performs the logout function of the old connection if an 3994 explicit logout was not performed earlier. In sessions with a 3995 single connection, this may imply the opening of a second 3996 connection with the sole purpose of cleaning up the first. Targets 3997 MUST support opening a second connection even when they do not 3998 support multiple connections in Full Feature Phase if 3999 ErrorRecoveryLevel is 2 and SHOULD support opening a second 4000 connection if ErrorRecoveryLevel is less than 2. 4002 If the operational ErrorRecoveryLevel is 2, connection 4003 reinstatement enables future task reassignment. If the operational 4004 ErrorRecoveryLevel is less than 2, connection reinstatement is the 4005 replacement of the old CID without enabling task reassignment. In 4006 this case, all the tasks that were active on the old CID must be 4007 immediately terminated without further notice to the initiator. 4009 The initiator connection state MUST be CLEANUP_WAIT (Section 4010 8.1.3) when the initiator attempts a connection reinstatement. 4012 In practical terms, in addition to the implicit logout of the old 4013 connection, reinstatement is equivalent to a new connection login. 4015 6.3.5. Session Reinstatement, Closure, and Timeout 4017 Session reinstatement is the process of the initiator logging in 4018 with an ISID that is possibly active from the target's 4019 perspective. Thus implicitly logging out the session that 4020 corresponds to the ISID and reinstating a new iSCSI session in its 4021 place (with the same ISID). Therefore, the TSIH in the Login PDU 4022 MUST be zero to signal session reinstatement. Session 4023 reinstatement causes all the tasks that were active on the old 4024 session to be immediately terminated by the target without further 4025 notice to the initiator. 4027 The initiator session state MUST be FAILED (Section 8.3- "Session 4028 State Diagrams") when the initiator attempts a session 4029 reinstatement. 4031 Session closure is an event defined to be one of the following: 4033 - A successful "session close" logout. 4035 - A successful "connection close" logout for the last Full 4036 Feature Phase connection when no other connection in the 4037 session is waiting for cleanup (Section 8.2- "Connection 4038 Cleanup State Diagram for Initiators and Targets") and no 4039 tasks in the session are waiting for reassignment. 4041 Session timeout is an event defined to occur when the last 4042 connection state timeout expires and no tasks are waiting for 4043 reassignment. This takes the session to the FREE state (N6 4044 transition in the session state diagram). 4046 6.3.5.1. Loss of Nexus Notification 4048 The iSCSI layer provides the SCSI layer with the "I_T nexus loss" 4049 notification when any one of the following events happens: 4051 Successful completion of session reinstatement. 4052 Session closure event. 4053 Session timeout event. 4055 Certain SCSI object clearing actions may result due to the 4056 notification in the SCSI end nodes, as documented in Appendix F. - 4057 Clearing Effects of Various Events on Targets. 4059 6.3.6. Session Continuation and Failure 4061 Session continuation is the process by which the state of a 4062 preexisting session continues to be used by connection 4063 reinstatement (Section 6.3.4), or by adding a connection with a 4064 new CID. Either of these actions associates the new transport 4065 connection with the session state. 4067 Session failure is an event where the last Full Feature Phase 4068 connection reaches the CLEANUP_WAIT state (Section 8.2), or 4069 completes a successful recovery logout thus causing all active 4070 tasks (that are formerly allegiant to the connection) to start 4071 waiting for task reassignment. 4073 6.4. Operational Parameter Negotiation Outside the Login Phase 4075 Some operational parameters MAY be negotiated outside (after) the 4076 Login Phase. 4078 Parameter negotiation in Full Feature Phase is done through Text 4079 requests and responses. Operational parameter negotiation MAY 4080 involve several Text request-response exchanges, which the 4081 initiator always starts, terminates, and uses the same Initiator 4082 Task Tag. The initiator MUST indicate its intent to finish the 4083 negotiation by setting the F bit to 1; the target sets the F bit 4084 to 1 on the last response. 4086 If the target responds to a Text request with the F bit set to 1 4087 with a Text response with the F bit set to 0, the initiator should 4088 keep sending the Text request (even empty) with the F bit set to 4089 1, while it still wants to finish the negotiation, until it 4090 receives the Text response with the F bit set to 1. Responding to 4091 a Text request with the F bit set to 1 with an empty (no key=value 4092 pairs) response with the F bit set to 0 is discouraged. 4094 Even when the initiator indicates its intent to finish the 4095 negotiation by setting the F bit to 1 in a Text request, the 4096 target MAY respond with a Text response with the F bit set to 0. 4097 In that case, the initiator SHOULD continue to set the F bit to 1 4098 in subsequent Text requests (even empty) that it sends, until 4099 target sends the final Text response with the F bit set to 1. Note 4100 that in the same case of Text request with the F bit set to 1, 4101 target SHOULD NOT respond with an empty (no key=value pairs) Text 4102 response with the F bit set to 0, because such a response may 4103 cause the initiator to abandon negotiation. 4105 Targets MUST NOT submit parameters that require an additional 4106 initiator Text request in a Text response with the F bit set to 1. 4108 In a negotiation sequence, the F bit settings in one pair of Text 4109 request-responses have no bearing on the F bit settings of the 4110 next pair. An initiator that has the F bit set to 1 in a request 4111 and is being answered with an F bit setting of 0 may issue the 4112 next request with the F bit set to 0. 4114 Whenever the target responds with the F bit set to 0, it MUST set 4115 the Target Transfer Tag to a value other than the default 4116 0xffffffff. 4118 An initiator MAY reset an operational parameter negotiation by 4119 issuing a Text request with the Target Transfer Tag set to the 4120 value 0xffffffff after receiving a response with the Target 4121 Transfer Tag set to a value other than 0xffffffff. A target may 4122 reset an operational parameter negotiation by answering a Text 4123 request with a Reject PDU. 4125 Neither the initiator nor the target should attempt to declare or 4126 negotiate a parameter more than once during any negotiation 4127 sequence, except for responses to specific keys that explicitly 4128 allow repeated key declarations (e.g., TargetAddress). If detected 4129 by the target, this MUST result in a Reject PDU with a reason of 4130 "protocol error". The initiator MUST reset the negotiation as 4131 outlined above. 4133 Parameters negotiated by a text exchange negotiation sequence only 4134 become effective after the negotiation sequence is completed. 4136 7. iSCSI Error Handling and Recovery 4138 7.1. Overview 4140 7.1.1. Background 4142 The following two considerations prompted the design of much of 4143 the error recovery functionality in iSCSI: 4145 An iSCSI PDU may fail the digest check and be dropped, despite 4146 being received by the TCP layer. The iSCSI layer must 4147 optionally be allowed to recover such dropped PDUs. 4149 A TCP connection may fail at any time during the data 4150 transfer. All the active tasks must optionally be allowed 4151 to be continued on a different TCP connection within the 4152 same session. 4154 Implementations have considerable flexibility in deciding what 4155 degree of error recovery to support, when to use it and by which 4156 mechanisms to achieve the required behavior. Only the externally 4157 visible actions of the error recovery mechanisms must be 4158 standardized to ensure interoperability. 4160 This chapter describes a general model for recovery in support of 4161 interoperability. See Appendix E. - "Algorithmic Presentation of 4162 Error Recovery Classes" for further detail on how the described 4163 model may be implemented. Compliant implementations do not have to 4164 match the implementation details of this model as presented, but 4165 the external behavior of such implementations must correspond to 4166 the externally observable characteristics of the presented model. 4168 7.1.2. Goals 4170 The major design goals of the iSCSI error recovery scheme are as 4171 follows: 4173 Allow iSCSI implementations to meet different requirements 4174 by defining a collection of error recovery mechanisms that 4175 implementations may choose from. 4176 Ensure interoperability between any two implementations 4177 supporting different sets of error recovery capabilities. 4179 Define the error recovery mechanisms to ensure command 4180 ordering even in the face of errors, for initiators that 4181 demand ordering. 4182 Do not make additions in the fast path, but allow moderate 4183 complexity in the error recovery path. 4184 Prevent both the initiator and target from attempting to 4185 recover the same set of PDUs at the same time. For example, 4186 there must be a clear "error recovery functionality 4187 distribution" between the initiator and target. 4189 7.1.3. Protocol Features and State Expectations 4191 The initiator mechanisms defined in connection with error recovery 4192 are: 4194 NOP-OUT to probe sequence numbers of the target (Section 4195 11.18) 4196 Command retry (Section 7.2.1) 4197 Recovery R2T support (Section 7.8) 4198 Requesting retransmission of status/data/R2T using the SNACK 4199 facility (Section 11.16) 4200 Acknowledging the receipt of the data (Section 11.16) 4201 Reassigning the connection allegiance of a task to a 4202 different TCP connection (Section 7.2.2) 4203 Terminating the entire iSCSI session to start afresh (Section 4204 7.1.4.4) 4206 The target mechanisms defined in connection with error recovery 4207 are: 4209 NOP-IN to probe sequence numbers of the initiator (Section 4210 11.19) 4211 Requesting retransmission of data using the recovery R2T 4212 feature (Section 7) 4213 SNACK support (Section 11.16) 4214 Requesting that parts of read data be acknowledged (Section 4215 11.7.2) 4216 Allegiance reassignment support (Section 7.2.2) 4217 Terminating the entire iSCSI session to force the initiator 4218 to start over (Section 7.1.4.4) 4220 For any outstanding SCSI command, it is assumed that iSCSI, in 4221 conjunction with SCSI at the initiator, is able to keep enough 4222 information to be able to rebuild the command PDU, and that 4223 outgoing data is available (in host memory) for retransmission 4224 while the command is outstanding. It is also assumed that at the 4225 target, incoming data (read data) MAY be kept for recovery or it 4226 can be reread from a device server. 4228 It is further assumed that a target will keep the "status & sense" 4229 for a command it has executed if it supports status 4230 retransmission. 4231 A target that agrees to support data retransmission is expected to 4232 be prepared to retransmit the outgoing data (i.e., Data-In) on 4233 request until either the status for the completed command is 4234 acknowledged, or the data in question has been separately 4235 acknowledged. 4237 7.1.4. Recovery Classes 4239 iSCSI enables the following classes of recovery (in the order of 4240 increasing scope of affected iSCSI tasks): 4242 - Within a command (i.e., without requiring command restart). 4244 - Within a connection (i.e., without requiring the connection 4245 to be rebuilt, but perhaps requiring command restart). 4247 - Connection recovery (i.e., perhaps requiring connections to 4248 be rebuilt and commands to be reissued). 4250 - Session recovery. 4252 The recovery scenarios detailed in the rest of this Section are 4253 representative rather than exclusive. In every case, they detail 4254 the lowest class recovery that MAY be attempted. The implementer 4255 is left to decide under which circumstances to escalate to the 4256 next recovery class and/or what recovery classes to implement. 4257 Both the iSCSI target and initiator MAY escalate the error 4258 handling to an error recovery class, which impacts a larger number 4259 of iSCSI tasks in any of the cases identified in the following 4260 discussion. 4262 In all classes, the implementer has the choice of deferring errors 4263 to the SCSI initiator (with an appropriate response code), in 4264 which case the task, if any, has to be removed from the target and 4265 all the side-effects, such as ACA, must be considered. 4267 Use of within-connection and within-command recovery classes MUST 4268 NOT be attempted before the connection is in Full Feature Phase. 4270 In the detailed description of the recover classes the 4271 mandating terms (MUST, SHOULD, MAY, etc.) indicate normative 4272 actions to be executed if the recovery class is supported and 4273 used. 4275 7.1.4.1. Recovery Within-command 4277 At the target, the following cases lend themselves to within- 4278 command recovery: 4280 - Lost data PDU - realized through one of the following: 4282 Data digest error - dealt with as specified in Section 7.8, 4283 using the option of a recovery R2T. 4284 Sequence reception timeout (no data or partial-data-and-no-F- 4285 bit) - considered an implicit sequence error and dealt with 4286 as specified in Section 7.9, using the option of a recovery 4287 R2T. 4288 Header digest error, which manifests as a sequence reception 4289 timeout or a sequence error - dealt with as specified in 4290 Section 7.9, using the option of a recovery R2T. 4292 At the initiator, the following cases lend themselves to within- 4293 command recovery: 4295 Lost data PDU or lost R2T - realized through one of the 4296 following: 4298 Data digest error - dealt with as specified in Section 7.8, 4299 using the option of a SNACK. 4301 Sequence reception timeout (no status) or response reception 4302 timeout - dealt with as specified in Section 7.9, using the 4303 option of a SNACK. 4304 Header digest error, which manifests as a sequence reception 4305 timeout or a sequence error - dealt with as specified in 4306 Section 7.9, using the option of a SNACK. 4308 To avoid a race with the target, which may already have a recovery 4309 R2T or a termination response on its way, an initiator SHOULD NOT 4310 originate a SNACK for an R2T based on its internal timeouts (if 4311 any). Recovery in this case is better left to the target. 4313 The timeout values used by the initiator and target are outside 4314 the scope of this document. Sequence reception timeout is 4315 generally a large enough value to allow the data sequence transfer 4316 to be complete. 4318 7.1.4.2. Recovery Within-connection 4320 At the initiator, the following cases lend themselves to within- 4321 connection recovery: 4323 - Requests not acknowledged for a long time. Requests are 4324 acknowledged explicitly through ExpCmdSN or implicitly by 4325 receiving data and/or status. The initiator MAY retry non- 4326 acknowledged commands as specified in Retry an. 4328 - Lost iSCSI numbered Response. It is recognized by either 4329 identifying a data digest error on a Response PDU or a Data- 4330 In PDU carrying the status, or by receiving a Response PDU 4331 with a higher StatSN than expected. In the first case, 4332 digest error handling is done as specified in Section 7.8 4333 using the option of a SNACK. In the second case, sequence 4334 error handling is done as specified in Section 7.9, using 4335 the option of a SNACK. 4337 At the target, the following cases lend themselves to within- 4338 connection recovery: 4340 - Status/Response not acknowledged for a long time. The target 4341 MAY issue a NOP-IN (with a valid Target Transfer Tag or 4342 otherwise) that carries the next status sequence number it 4343 is going to use in the StatSN field. This helps the 4344 initiator detect any missing StatSN(s) and issue a SNACK for 4345 the status. 4347 The timeout values used by the initiator and the target are 4348 outside the scope of this document. 4350 7.1.4.3. Connection Recovery 4352 At an iSCSI initiator, the following cases lend themselves to 4353 connection recovery: 4355 - TCP connection failure: The initiator MUST close the 4356 connection. It then MUST either implicitly or explicitly 4357 logout the failed connection with the reason code "remove 4358 the connection for recovery" and reassign connection 4359 allegiance for all commands still in progress associated 4360 with the failed connection on one or more connections (some 4361 or all of which MAY be newly established connections) using 4362 the "Task reassign" task management function (see Section 4363 11.5.1). For an initiator, a command is in progress as long 4364 as it has not received a response or a Data-In PDU including 4365 status. 4367 Note: The logout function is mandatory. However, a new 4368 connection establishment is only mandatory if the failed 4369 connection was the last or only connection in the session. 4371 - Receiving an Asynchronous Message that indicates one or all 4372 connections in a session has been dropped. The initiator 4373 MUST handle it as a TCP connection failure for the 4374 connection(s) referred to in the Message. 4376 At an iSCSI target, the following cases lend themselves to 4377 connection recovery: 4379 - TCP connection failure. The target MUST close the connection 4380 and, if more than one connection is available, the target 4381 SHOULD send an Asynchronous Message that indicates it has 4382 dropped the connection. Then, the target will wait for the 4383 initiator to continue recovery. 4385 7.1.4.4. Session Recovery 4387 Session recovery should be performed when all other recovery 4388 attempts have failed. Very simple initiators and targets MAY 4389 perform session recovery on all iSCSI errors and rely on recovery 4390 on the SCSI layer and above. 4392 Session recovery implies the closing of all TCP connections, 4393 internally aborting all executing and queued tasks for the given 4394 initiator at the target, terminating all outstanding SCSI commands 4395 with an appropriate SCSI service response at the initiator, and 4396 restarting a session on a new set of connection(s) (TCP connection 4397 establishment and login on all new connections). 4399 For possible clearing effects of session recovery on SCSI and 4400 iSCSI objects, refer to Appendix F. - "Clearing Effects of Various 4401 Events on Targets". 4403 7.1.5. Error Recovery Hierarchy 4405 The error recovery classes described so far are organized into a 4406 hierarchy for ease in understanding and to limit the 4407 implementation complexity. With few and well defined recovery 4408 levels interoperability is easier to achieve. The attributes of 4409 this hierarchy are as follows: 4411 Each level is a superset of the capabilities of the previous 4412 level. For example, Level 1 support implies supporting all 4413 capabilities of Level 0 and more. 4415 As a corollary, supporting a higher error recovery level means 4416 increased sophistication and possibly an increase in 4417 resource requirements. 4418 Supporting error recovery level "n" is advertised and 4419 negotiated by each iSCSI entity by exchanging the text key 4420 "ErrorRecoveryLevel=n". The lower of the two exchanged 4421 values is the operational ErrorRecoveryLevel for the 4422 session. 4424 The following diagram represents the error recovery hierarchy. 4426 + 4427 / \ 4428 / 2 \ <-- Connection recovery 4429 +-----+ 4430 / 1 \ <-- Digest failure recovery 4431 +----------+ 4432 / 0 \ <-- Session failure recovery 4433 +---------------+ 4435 The following table lists the error recovery capabilities expected 4436 from the implementations that support each error recovery level. 4438 +-------------------+--------------------------------------------+ 4439 |ErrorRecoveryLevel | Associated Error recovery capabilities | 4440 +-------------------+--------------------------------------------+ 4441 | 0 | Session recovery class | 4442 | | (Session Recovery) | 4443 +-------------------+--------------------------------------------+ 4444 | 1 | Digest failure recovery (See Note below.) | 4445 | | plus the capabilities of ER Level 0 | 4446 +-------------------+--------------------------------------------+ 4447 | 2 | Connection recovery class | 4448 | | (Connection Recovery) | 4449 | | plus the capabilities of ER Level 1 | 4450 +-------------------+--------------------------------------------+ 4452 Note: Digest failure recovery is comprised of two recovery 4453 classes: Within-Connection recovery class (Recovery Within- 4454 connection) and Within-Command recovery class (Recovery Within- 4455 command ). 4457 When a defined value of ErrorRecoveryLevel is proposed by an 4458 originator in a text negotiation, the originator MUST support the 4459 functionality defined for the proposed value and additionally, 4460 functionality corresponding to any defined value numerically less 4461 than the proposed. When a defined value of ErrorRecoveryLevel is 4462 returned by a responder in a text negotiation, the responder MUST 4463 support the functionality corresponding to the ErrorRecoveryLevel 4464 it is accepting. 4466 When either party attempts to use error recovery functionality 4467 beyond what is negotiated, the recovery attempts MAY fail unless 4468 an apriori agreement outside the scope of this document exists 4469 between the two parties to provide such support. 4471 Implementations MUST support error recovery level "0", while the 4472 rest are OPTIONAL to implement. In implementation terms, the 4473 above striation means that the following incremental 4474 sophistication with each level is required. 4476 +-------------------+--------------------------------------------+ 4477 |Level transition | Incremental requirement | 4478 +-------------------+--------------------------------------------+ 4479 | 0->1 | PDU retransmissions on the same connection | 4480 +-------------------+--------------------------------------------+ 4481 | 1->2 | Retransmission across connections and | 4482 | | allegiance reassignment | 4483 +-------------------+--------------------------------------------+ 4485 7.2. Retry and Reassign in Recovery 4487 This Section summarizes two important and somewhat related iSCSI 4488 protocol features used in error recovery. 4490 7.2.1. Usage of Retry 4492 By resending the same iSCSI command PDU ("retry") in the absence 4493 of a command acknowledgement (by way of an ExpCmdSN update) or a 4494 response, an initiator attempts to "plug" (what it thinks are) the 4495 discontinuities in CmdSN ordering on the target end. Discarded 4496 command PDUs, due to digest errors, may have created these 4497 discontinuities. 4499 Retry MUST NOT be used for reasons other than plugging command 4500 sequence gaps, and in particular, cannot be used for requesting 4501 PDU retransmissions from a target. Any such PDU retransmission 4502 requests for a currently allegiant command in progress may be made 4503 using the SNACK mechanism described in Section 11.16, although the 4504 usage of SNACK is OPTIONAL. 4506 If initiators, as part of plugging command sequence gaps as 4507 described above, inadvertently issue retries for allegiant 4508 commands already in progress (i.e., targets did not see the 4509 discontinuities in CmdSN ordering), the duplicate commands are 4510 silently ignored by targets as specified in Section 4.2.2.1. 4512 When an iSCSI command is retried, the command PDU MUST carry the 4513 original Initiator Task Tag and the original operational 4514 attributes (e.g., flags, function names, LUN, CDB etc.) as well as 4515 the original CmdSN. The command being retried MUST be sent on the 4516 same connection as the original command unless the original 4517 connection was already successfully logged out. 4519 7.2.2. Allegiance Reassignment 4521 By issuing a "task reassign" task management request (Section 4522 11.5.1 - "Function"), the initiator signals its intent to continue 4523 an already active command (but with no current connection 4524 allegiance) as part of connection recovery. This means that a new 4525 connection allegiance is requested for the command, which seeks to 4526 associate it to the connection on which the task management 4527 request is being issued. Before the allegiance reassignment is 4528 attempted for a task, an implicit or explicit Logout with the 4529 reason code "remove the connection for recovery" (see Section 4530 11.14.1) MUST be successfully completed for the previous 4531 connection to which the task was allegiant. 4533 In reassigning connection allegiance for a command, the targets 4534 SHOULD continue the command from its current state. For example, 4535 when reassigning read commands, the target SHOULD take advantage 4536 of the ExpDataSN field provided by the Task Management function 4537 request (which must be set to zero if there was no data transfer) 4538 and bring the read command to completion by sending the remaining 4539 data and sending (or resending) the status. ExpDataSN 4540 acknowledges all data sent up to, but not including, the Data-In 4541 PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However, 4542 targets may choose to send/receive all unacknowledged data or all 4543 of the data on a reassignment of connection allegiance if unable 4544 to recover or maintain accurate an state. Initiators MUST NOT 4545 subsequently request data retransmission through Data SNACK for 4546 PDUs numbered less than ExpDataSN (i.e., prior to the acknowledged 4547 sequence number). For all types of commands, a reassignment 4548 request implies that the task is still considered in progress by 4549 the initiator and the target must conclude the task appropriately 4550 if the target returns the "Function Complete" response to the 4551 reassignment request. This might possibly involve retransmission 4552 of data/R2T/status PDUs as necessary, but MUST involve the 4553 (re)transmission of the status PDU. 4555 It is OPTIONAL for targets to support the allegiance reassignment. 4556 This capability is negotiated via the ErrorRecoveryLevel text key 4557 during the login time. When a target does not support allegiance 4558 reassignment, it MUST respond with a Task Management response code 4559 of "Allegiance reassignment not supported". If allegiance 4560 reassignment is supported by the target, but the task is still 4561 allegiant to a different connection, or a successful recovery 4562 Logout of the previously allegiant connection was not performed, 4563 the target MUST respond with a Task Management response code of 4564 "Task still allegiant". 4566 If allegiance reassignment is supported by the target, the Task 4567 Management response to the reassignment request MUST be issued 4568 before the reassignment becomes effective. 4570 If a SCSI Command that involves data input is reassigned, any 4571 SNACK Tag it holds for a final response from the original 4572 connection is deleted and the default value of 0 MUST be used 4573 instead. 4575 7.3. Usage Of Reject PDU in Recovery 4577 Targets MUST NOT implicitly terminate an active task by sending a 4578 Reject PDU for any PDU exchanged during the life of the task. If 4579 the target decides to terminate the task, a Response PDU (SCSI, 4580 Text, Task, etc.) must be returned by the target to conclude the 4581 task. If the task had never been active before the Reject (i.e., 4582 the Reject is on the command PDU), targets should not send any 4583 further responses because the command itself is being discarded. 4585 The above rule means that the initiator can eventually expect a 4586 response on receiving Rejects, if the received Reject is for a PDU 4587 other than the command PDU itself. The non-command Rejects only 4588 have diagnostic value in logging the errors, and they can be used 4589 for retransmission decisions by the initiators. 4591 The CmdSN of the rejected command PDU (if it is a non-immediate 4592 command) MUST NOT be considered received by the target (i.e., a 4593 command sequence gap must be assumed for the CmdSN), even though 4594 the CmdSN of the rejected command PDU may be reliably ascertained. 4595 Upon receiving the Reject, the initiator MUST plug the CmdSN gap 4596 in order to continue to use the session. The gap may be plugged 4597 either by transmitting a command PDU with the same CmdSN, or by 4598 aborting the task (see SCS on how an abort may plug a CmdSN gap). 4600 When a data PDU is rejected and its DataSN can be ascertained, a 4601 target MUST advance ExpDataSN for the current data burst if a 4602 recovery R2T is being generated. The target MAY advance its 4603 ExpDataSN if it does not attempt to recover the lost data PDU. 4605 7.4. Error Recovery Considerations for Discovery Sessions 4607 7.4.1. ErrorRecoveryLevel for Discovery Sessions 4609 The negotiation of the key ErrorRecoveryLevel is not required for 4610 Discovery sessions -- i.e., for sessions that negotiated 4611 "SessionType=Discovery" -- because the default value of 0 is 4612 necessary and sufficient for Discovery sessions. It is however 4613 possible that some legacy iSCSI implementations might attempt to 4614 negotiate the ErrorRecoveryLevel key on Discovery sessions. When 4615 such a negotiation attempt is made by the remote side, a compliant 4616 iSCSI implementation MUST propose a value of 0 (zero) in response. 4617 The operational ErrorRecoveryLevel for Discovery sessions thus 4618 MUST 4619 be 0. This naturally follows from the functionality constraints 4620 that Section 4.3 imposes on Discovery sessions. 4622 7.4.2. Reinstatement Semantics for Discovery Sessions 4624 Discovery sessions are intended to be relatively short-lived. 4625 Initiators are not expected to establish multiple Discovery 4626 sessions to the same iSCSI Network Portal. An initiator may use 4627 the same iSCSI Initiator Name and ISID when establishing different 4628 unique sessions with different targets and/or different portal 4629 groups. This behavior is discussed in Section 10.1.1 and is, in 4630 fact, encouraged as conservative reuse of ISIDs. 4632 The ISID RULE in Section 4.4.3 states that there must not be more 4633 than one session with a matching 4-tuple: . While the spirit of the ISID 4635 RULE applies to Discovery sessions the same as it does for Normal 4636 sessions, note that some Discovery sessions differ from the Normal 4637 sessions in two important aspects: 4639 Because Appendix D allows a Discovery session to be established 4640 without specifying a TargetName key in the Login Request PDU 4641 (let us call such a session an "Unnamed" Discovery session), 4642 there is no Target Node context to enforce the ISID RULE. 4644 Portal Groups are defined only in the context of a Target Node. 4645 When the TargetName key is NULL-valued (i.e., not specified), 4646 the TargetPortalGroupTag thus cannot be ascertained to enforce 4647 the ISID RULE. 4649 The following two sections describe each of the two scenarios -- 4650 Named Discovery sessions and Unnamed Discovery sessions. 4652 7.4.2.1. Unnamed Discovery Sessions 4654 For Unnamed Discovery sessions, neither the TargetName nor the 4655 TargetPortalGroupTag is available to the targets in order to 4656 enforce the ISID RULE. So the following rule applies. 4658 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 4659 following 4-tuple for Unnamed Discovery sessions: . The following semantics are implied by 4661 this uniqueness requirement. 4663 Targets SHOULD allow concurrent establishment of one Discovery 4664 session with each of its Network Portals by the same initiator 4665 port with a given iSCSI Node Name and an ISID. Each of the 4666 concurrent Discovery sessions, if established by the same 4667 initiator port to other Network Portals, MUST be treated as 4668 independent sessions -- i.e., one session MUST NOT reinstate the 4669 other. 4671 A new Unnamed Discovery session that has a matching 4672 to an existing 4673 Discovery session MUST reinstate the existing Unnamed Discovery 4674 session. Note thus that only an Unnamed Discovery session may 4675 reinstate an Unnamed Discovery session. 4677 7.4.2.2. Named Discovery Session 4679 For a Named Discovery session, the TargetName key is specified by 4680 the initiator and thus the target can unambiguously ascertain the 4681 TargetPortalGroupTag as well. Since all the four elements of the 4682 4-tuple are known, the ISID RULE MUST be enforced by targets with 4683 no changes from Section 4.4.3 semantics. A new session with a 4684 matching 4685 thus will reinstate an existing session. Note in this case that 4686 any new iSCSI session (Discovery or Normal) with the matching 4- 4687 tuple may reinstate an existing Named Discovery iSCSI session. 4689 7.4.3. Target PDUs During Discovery 4691 Targets SHOULD NOT send any responses other than a Text Response 4692 and Logout Response on a Discovery session, once in Full Feature 4693 Phase. 4695 Implementation Note: A target may simply drop the connection in a 4696 Discovery session when it would have requested a Logout via an 4697 Async Message on Normal sessions. 4699 7.5. Connection Timeout Management 4701 iSCSI defines two session-global timeout values (in seconds) - 4702 Time2Wait and Time2Retain - that are applicable when an iSCSI Full 4703 Feature Phase connection is taken out of service either 4704 intentionally or by an exception. Time2Wait is the initial 4705 "respite time" before attempting an explicit/implicit Logout for 4706 the CID in question or task reassignment for the affected tasks 4707 (if any). Time2Retain is the maximum time after the initial 4708 respite interval that the task and/or connection state(s) is/are 4709 guaranteed to be maintained on the target to cater to a possible 4710 recovery attempt. Recovery attempts for the connection and/or 4711 task(s) SHOULD NOT be made before Time2Wait seconds, but MUST be 4712 completed within Time2Retain seconds after that initial Time2Wait 4713 waiting period. 4715 7.5.1. Timeouts on Transport Exception Events 4717 A transport connection shutdown or a transport reset without any 4718 preceding iSCSI protocol interactions informing the end-points of 4719 the fact causes a Full Feature Phase iSCSI connection to be 4720 abruptly terminated. The timeout values to be used in this case 4721 are the negotiated values of defaultTime2Wait (Section 13.15 - 4722 "DefaultTime2Wait") and DefaultTime2Retain (Section 13.16 - 4723 "DefaultTime2Retain") text keys for the session. 4725 7.5.2. Timeouts on Planned Decommissioning 4727 Any planned decommissioning of a Full Feature Phase iSCSI 4728 connection is preceded by either a Logout Response PDU, or an 4729 Async Message PDU. The Time2Wait and Time2Retain field values 4730 (Section 11.15) in a Logout Response PDU, and the Parameter2 and 4731 Parameter3 fields of an Async Message (AsyncEvent types "drop the 4732 connection" or "drop all the connections"; Section 11.9.1) specify 4733 the timeout values to be used in each of these cases. 4735 These timeout values are only applicable for the affected 4736 connection, and the tasks active on that connection. These 4737 timeout values have no bearing on initiator timers (if any) that 4738 are already running on connections or tasks associated with that 4739 session. 4741 7.6. Implicit Termination of Tasks 4743 A target implicitly terminates the active tasks due to iSCSI 4744 protocol dynamics in the following cases: 4746 When a connection is implicitly or explicitly logged out with 4747 the reason code of "Close the connection" and there are 4748 active tasks allegiant to that connection. 4750 When a connection fails and eventually the connection state 4751 times out (state transition M1 in Section 8.2.2) and there 4752 are active tasks allegiant to that connection. 4754 When a successful Logout with the reason code of "remove the 4755 connection for recovery" is performed while there are 4756 active tasks allegiant to that connection, and those tasks 4757 eventually time out after the Time2Wait and Time2Retain 4758 periods without allegiance reassignment. 4760 When a connection is implicitly or explicitly logged out with 4761 the reason code of "Close the session" and there are active 4762 tasks in that session. 4764 If the tasks terminated in the above cases a), b, c) and d)are 4765 SCSI tasks, they must be internally terminated as if with CHECK 4766 CONDITION status. This status is only meaningful for appropriately 4767 handling the internal SCSI state and SCSI side effects with 4768 respect to ordering because this status is never communicated back 4769 as a terminating status to the initiator. However additional 4770 actions may have to be taken at SCSI level depending on the SCSI 4771 context as defined by the SCSI standards (e.g., queued commands 4772 and ACA, UA for the next command on the I_T nexus in cases a), b), 4773 and c) etc. - see [SAM2] and [SPC3]). 4775 7.7. Format Errors 4777 The following two explicit violations of PDU layout rules are 4778 format errors: 4780 Illegal contents of any PDU header field except the Opcode 4781 (legal values are specified in Section 11). 4782 Inconsistent field contents (consistent field contents are 4783 specified in Section 11). 4785 Format errors indicate a major implementation flaw in one of the 4786 parties. 4788 When a target or an initiator receives an iSCSI PDU with a format 4789 error, it MUST immediately terminate all transport connections in 4790 the session either with a connection close or with a connection 4791 reset and escalate the format error to session recovery (see 4792 Section 7.1.4.4). 4794 All initiator-detected PDU construction errors MUST be considered 4795 as format errors. Some examples of such errors are: 4796 - NOP-In with a valid TTT but an invalid LUN 4798 - NOP-In with a valid ITT (i.e., a NOP-In response) and also a 4799 valid TTT 4801 - SCSI Response PDU with Status=CHECK CONDITION, but 4802 DataSegmentLength = 0 4804 7.8. Digest Errors 4806 The discussion of the legal choices in handling digest errors 4807 below excludes session recovery as an explicit option, but either 4808 party detecting a digest error may choose to escalate the error to 4809 session recovery. 4811 When a target or an initiator receives any iSCSI PDU, with a 4812 header digest error, it MUST either discard the header and all 4813 data up to the beginning of a later PDU or close the connection. 4814 Because the digest error indicates that the length field of the 4815 header may have been corrupted, the location of the beginning of a 4817 later PDU needs to be reliably ascertained by other means such as 4818 the operation of a sync and steering layer. 4820 When a target receives any iSCSI PDU with a payload digest error, 4821 it MUST answer with a Reject PDU with a reason code of Data- 4822 Digest-Error and discard the PDU. 4824 - If the discarded PDU is a solicited or unsolicited iSCSI 4825 data PDU (for immediate data in a command PDU, non-data PDU 4826 rule below applies), the target MUST do one of the 4827 following: 4829 i) Request retransmission with a recovery R2T. 4830 ii) Terminate the task with a response PDU with a CHECK 4831 CONDITION Status and an iSCSI Condition of "protocol 4832 service CRC error" (Section 11.4.7.2 - "Sense Data"). 4833 If the target chooses to implement this option, it MUST 4834 wait to receive all the data (signaled by a Data PDU 4835 with the final bit set for all outstanding R2Ts) before 4836 sending the response PDU. A task management command 4837 (such as an abort task) from the initiator during this 4838 wait may also conclude the task. 4839 - No further action is necessary for targets if the discarded 4840 PDU is a non-data PDU. In case of immediate data being 4841 present on a discarded command, the immediate data is 4842 implicitly recovered when the task is retried (see Section 4843 7.2.1) followed by the entire data transfer for the task. 4845 When an initiator receives any iSCSI PDU with a payload digest 4846 error, it MUST discard the PDU. 4848 - If the discarded PDU is an iSCSI data PDU, the initiator 4849 MUST do one of the following: 4851 Request the desired data PDU through SNACK. In response to 4852 the SNACK, the target MUST either resend the data 4853 PDU or reject the SNACK with a Reject PDU with a 4854 reason code of "SNACK reject" in which case: 4855 If the status has not already been sent for the command, 4856 the target MUST terminate the command with a 4857 CHECK CONDITION Status and an iSCSI Condition of 4858 "SNACK rejected" (Section 11.4.7.2 - "Sense 4859 Data"). 4860 If the status was already sent, no further action is 4861 necessary for the target. The initiator in this 4862 case MUST wait for the status to be received and 4863 then discard it, so as to internally signal the 4864 completion with CHECK CONDITION Status and an 4865 iSCSI Condition of "protocol service CRC error" 4866 (Section 11.4.7.2- "Sense Data"). 4867 Abort the task and terminate the command with an error. 4869 - If the discarded PDU is a response PDU or an unsolicited PDU 4870 (e.g. Async, Reject), the initiator MUST do one of the 4871 following: 4873 Request PDU retransmission with a status SNACK. 4874 Logout the connection for recovery and continue the tasks 4875 on a different connection instance as described 4876 in Section 7.2. 4877 Logout to close the connection (abort all the commands 4878 associated with the connection). 4880 Note that an unsolicited PDU carries the next StatSN value on 4881 an iSCSI connection, thereby advancing the StatSN. When an 4882 initiator discards one of these PDUs due to a payload digest 4883 error, the entire PDU including the header MUST be discarded. 4884 Consequently, the initiator MUST treat the exception like a 4885 loss of any other solicited response PDU. 4887 7.9. Sequence Errors 4889 When an initiator receives an iSCSI R2T/data PDU with an out of 4890 order R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that 4891 implies missing data PDU(s), it means that the initiator must have 4892 detected a header or payload digest error on one or more earlier 4893 R2T/data PDUs. The initiator MUST address these implied digest 4894 errors as described in Section 7.8. When a target receives a data 4895 PDU with an out of order DataSN, it means that the target must 4896 have hit a header or payload digest error on at least one of the 4897 earlier data PDUs. The target MUST address these implied digest 4898 errors as described in Section 7.8. 4900 When an initiator receives an iSCSI status PDU with an out of 4901 order StatSN that implies missing responses, it MUST address the 4902 one or more missing status PDUs as described in Section 7.8. As a 4903 side effect of receiving the missing responses, the initiator may 4904 discover missing data PDUs. If the initiator wants to recover the 4905 missing data for a command, it MUST NOT acknowledge the received 4906 responses that start from the StatSN of the relevant command, 4907 until it has completed receiving all the data PDUs of the command. 4909 When an initiator receives duplicate R2TSNs (due to proactive 4910 retransmission of R2Ts by the target) or duplicate DataSNs (due to 4911 proactive SNACKs by the initiator), it MUST discard the 4912 duplicates. 4914 7.10. Message Error Checking 4916 In the iSCSI implementations till date, there has been some 4917 uncertainty on the extent to which incoming messages have to be 4918 checked for protocol errors, beyond what is strictly required for 4919 processing the inbound message. This Section addresses this 4920 question. 4922 Unless this document requires it, an iSCSI implementation is not 4923 required to do an exhaustive protocol conformance check on an 4924 incoming iSCSI PDU. The iSCSI implementation especially is not 4925 required to double-check the remote iSCSI implementation's 4926 conformance to protocol requirements. 4928 7.11. SCSI Timeouts 4930 An iSCSI initiator MAY attempt to plug a command sequence gap on 4931 the target end (in the absence of an acknowledgement of the 4932 command by way of ExpCmdSN) before the ULP timeout by retrying the 4933 unacknowledged command, as described in Section 7.2. 4935 On a ULP timeout for a command (that carried a CmdSN of n), if the 4936 iSCSI initiator intends to continue the session it MUST abort the 4937 command by either using an appropriate Task Management function 4938 request for the specific command, or a "close the connection" 4940 Logout. When using an ABORT TASK, if the ExpCmdSN is still less 4941 than (n+1), the target may see the abort request while missing the 4942 original command itself due to one of the following reasons: 4944 - Original command was dropped due to digest error. 4946 - Connection on which the original command was sent was 4947 successfully logged out. On logout, the unacknowledged 4948 commands issued on the connection being logged out are 4949 discarded. 4951 If the abort request is received and the original command is 4952 missing, targets MUST consider the original command with that 4953 RefCmdSN to be received and issue a Task Management response with 4954 the response code: "Function Complete". This response concludes 4955 the task on both ends. If the abort request is received and the 4956 target can determine (based on the Referenced Task Tag) that the 4957 command was received and executed and also that the response was 4958 sent prior to the abort, then the target MUST respond with the 4959 response code of "Task Does Not Exist". 4961 7.12. Negotiation Failures 4963 Text request and response sequences, when used to set/negotiate 4964 operational parameters, constitute the negotiation/parameter 4965 setting. A negotiation failure is considered to be one or more of 4966 the following: 4968 - None of the choices, or the stated value, is acceptable to 4969 one of the sides in the negotiation. 4971 - The text request timed out and possibly terminated. 4973 - The text request was answered with a Reject PDU. 4975 The following two rules should be used to address negotiation 4976 failures: 4978 - During Login, any failure in negotiation MUST be considered 4979 a login process failure and the Login Phase MUST be 4980 terminated, and with it, the connection. If the target 4981 detects the failure, it must terminate the login with the 4982 appropriate login response code. 4984 - A failure in negotiation, while in the Full Feature Phase, 4985 will terminate the entire negotiation sequence that may 4986 consist of a series of text requests that use the same 4987 Initiator Task Tag. The operational parameters of the 4988 session or the connection MUST continue to be the values 4989 agreed upon during an earlier successful negotiation (i.e., 4990 any partial results of this unsuccessful negotiation MUST 4991 NOT take effect and MUST be discarded). 4993 7.13. Protocol Errors 4995 Mapping framed messages over a "stream" connection, such as TCP, 4996 makes the proposed mechanisms vulnerable to simple software 4997 framing errors. On the other hand, the introduction of framing 4998 mechanisms to limit the effects of these errors may be onerous on 4999 performance for simple implementations. Command Sequence Numbers 5000 and the above mechanisms for connection drop and reestablishment 5001 help handle this type of mapping errors. 5003 All violations of iSCSI PDU exchange sequences specified in this 5004 draft are also protocol errors. This category of errors can only 5005 be 5006 addressed by fixing the implementations; iSCSI defines Reject and 5007 response codes to enable this. 5009 7.14. Connection Failures 5011 iSCSI can keep a session in operation if it is able to 5012 keep/establish at least one TCP connection between the initiator 5013 and the target in a timely fashion. Targets and/or initiators may 5014 recognize a failing connection by either transport level means 5015 (TCP), a gap in the command sequence number, a response stream 5016 that is not filled for a long time, or by a failing iSCSI NOP 5017 (acting as a ping). The latter MAY be used periodically to 5018 increase the speed and likelihood of detecting connection 5019 failures. Initiators and targets MAY also use the keep-alive 5020 option on the TCP connection to enable early link failure 5021 detection on otherwise idle links. 5023 On connection failure, the initiator and target MUST do one of the 5024 following: 5026 - Attempt connection recovery within the session (Connection 5027 Recovery). 5029 - Logout the connection with the reason code "closes the 5030 connection" (Section 10.14.5 - "Implicit termination of 5031 tasks"), re-issue missing commands, and implicitly terminate 5032 all active commands. This option requires support for the 5033 within-connection recovery class (Recovery Within- 5034 connection). 5036 - Perform session recovery (Session Recovery). 5038 Either side may choose to escalate to session recovery (via the 5039 initiator dropping all the connections, or via an Async Message 5040 that announces the similar intent from a target), and the other 5041 side MUST give it precedence. On a connection failure, a target 5042 MUST terminate and/or discard all of the active immediate commands 5043 regardless of which of the above options is used (i.e., immediate 5044 commands are not recoverable across connection failures). 5046 7.15. Session Errors 5048 If all of the connections of a session fail and cannot be 5049 reestablished in a short time, or if initiators detect protocol 5050 errors repeatedly, an initiator may choose to terminate a session 5051 and establish a new session. 5053 In this case, the initiator takes the following actions: 5055 - Resets or closes all the transport connections. 5057 - Terminates all outstanding requests with an appropriate 5058 response before initiating a new session. If the same I_T 5059 nexus is intended to be reestablished, the initiator MUST 5060 employ session reinstatement (see Section 6.3.5). 5062 When the session timeout (the connection state timeout for the 5063 last failed connection) happens on the target, it takes the 5064 following actions: 5066 - Resets or closes the TCP connections (closes the session). 5068 - Terminates all active tasks that were allegiant to the 5069 connection(s) that constituted the session. 5071 A target MUST also be prepared to handle a session reinstatement 5072 request from the initiator that may be addressing session errors. 5074 8. State Transitions 5076 iSCSI connections and iSCSI sessions go through several well- 5077 defined states from the time they are created to the time they are 5078 cleared. 5080 The connection state transitions are described in two separate but 5081 dependent state diagrams for ease in understanding. The first 5082 diagram, "standard connection state diagram", describes the 5083 connection state transitions when the iSCSI connection is not 5084 waiting for, or undergoing, a cleanup by way of an explicit or 5085 implicit Logout. The second diagram, "connection cleanup state 5086 diagram", describes the connection state transitions while 5087 performing the iSCSI connection cleanup. 5089 The "session state diagram" describes the state transitions an 5090 iSCSI session would go through during its lifetime, and it depends 5091 on the states of possibly multiple iSCSI connections that 5092 participate in the session. 5094 States and transitions are described in text, tables and diagrams. 5095 The diagrams are used for illustration. The text and the tables 5096 are the governing specification. 5098 8.1. Standard Connection State Diagrams 5100 8.1.1. State Descriptions for Initiators and Targets 5102 State descriptions for the standard connection state diagram are 5103 as follows: 5104 -S1: FREE 5105 -initiator: State on instantiation, or after successful 5106 connection closure. 5107 -target: State on instantiation, or after successful 5108 connection closure. 5109 -S2: XPT_WAIT 5110 -initiator: Waiting for a response to its transport 5111 connection establishment request. 5112 -target: Illegal 5113 -S3: XPT_UP 5114 -initiator: Illegal 5115 -target: Waiting for the Login process to commence. 5117 -S4: IN_LOGIN 5118 -initiator: Waiting for the Login process to conclude, 5119 possibly involving several PDU exchanges. 5120 -target: Waiting for the Login process to conclude, 5121 possibly involving several PDU exchanges. 5122 -S5: LOGGED_IN 5123 -initiator: In Full Feature Phase, waiting for all 5124 internal, iSCSI, and transport events. 5125 -target: In Full Feature Phase, waiting for all internal, 5126 iSCSI, and transport events. 5127 -S6: IN_LOGOUT 5128 -initiator: Waiting for a Logout response. 5129 -target: Waiting for an internal event signaling completion 5130 of logout processing. 5131 -S7: LOGOUT_REQUESTED 5132 -initiator: Waiting for an internal event signaling 5133 readiness to proceed with Logout. 5134 -target: Waiting for the Logout process to start after 5135 having requested a Logout via an Async Message. 5136 -S8: CLEANUP_WAIT 5137 -initiator: Waiting for the context and/or resources to 5138 initiate the cleanup processing for this CSM. 5139 -target: Waiting for the cleanup process to start for this 5140 CSM. 5141 8.1.2. State Transition Descriptions for Initiators and Targets 5143 -T1: 5144 -initiator: Transport connect request was made (e.g., TCP 5145 SYN sent). 5146 -target: Illegal 5147 -T2: 5148 -initiator: Transport connection request timed out, a 5149 transport reset was received, or an internal event of 5150 receiving a Logout response (success) on another connection 5151 for a "close the session" Logout request was received. 5152 -target:Illegal 5153 -T3: 5154 -initiator: Illegal 5155 -target: Received a valid transport connection request that 5156 establishes the transport connection. 5157 -T4: 5159 -initiator: Transport connection established, thus 5160 prompting the initiator to start the iSCSI Login. 5161 -target: Initial iSCSI Login request was received. 5162 -T5: 5163 -initiator: The final iSCSI Login response with a Status- 5164 Class of zero was received. 5165 -target: The final iSCSI Login request to conclude the 5166 Login Phase was received, thus prompting the target to send 5167 the final iSCSI Login response with a Status-Class of zero. 5168 -T6: 5169 -initiator: Illegal 5170 -target: Timed out waiting for an iSCSI Login, transport 5171 disconnect indication was received, transport reset was 5172 received, or an internal event indicating a transport 5173 timeout was received. In all these cases, the connection is 5174 to be closed. 5175 -T7: 5176 -initiator - one of the following events caused the 5177 transition: 5178 - The final iSCSI Login response was received with a 5179 non-zero Status-Class. 5180 - Login timed out. 5181 - A transport disconnect indication was received. 5182 - A transport reset was received. 5183 - An internal event indicating a transport timeout was 5184 received. 5185 - An internal event of receiving a Logout response 5186 (success) on another connection for a "close the 5187 session" Logout request was received. 5189 In all these cases, the transport connection is closed. 5191 -target - one of the following events caused the 5192 transition: 5193 - The final iSCSI Login request to conclude the Login 5194 Phase was received, prompting the target to send the 5195 final iSCSI Login response with a non-zero Status- 5196 Class. 5197 - Login timed out. 5198 - Transport disconnect indication was received. 5200 - Transport reset was received. 5201 - An internal event indicating a transport timeout was 5202 received . 5203 - On another connection a "close the session" 5204 Logout request was received. 5206 In all these cases, the connection is to be closed. 5207 -T8: 5208 -initiator: An internal event of receiving a Logout 5209 response (success) on another connection for a "close the 5210 session" Logout request was received, thus closing this 5211 connection requiring no further cleanup. 5212 -target: An internal event of sending a Logout response 5213 (success) on another connection for a "close the session" 5214 Logout request was received, or an internal event of a 5215 successful connection/session reinstatement is received, 5216 thus prompting the target to close this connection cleanly. 5217 -T9, T10: 5218 -initiator: An internal event that indicates the readiness 5219 to start the Logout process was received, thus prompting an 5220 iSCSI Logout to be sent by the initiator. 5221 -target: An iSCSI Logout request was received. 5222 -T11, T12: 5223 -initiator: Async PDU with AsyncEvent "Request Logout" was 5224 received. 5225 -target: An internal event that requires the 5226 decommissioning of the connection is received, thus causing 5227 an Async PDU with an AsyncEvent "Request Logout" to be 5228 sent. 5229 -T13: 5230 -initiator: An iSCSI Logout response (success) was 5231 received, or an internal event of receiving a Logout 5232 response (success) on another connection for a "close the 5233 session" Logout request was received. 5234 -target: An internal event was received that indicates 5235 successful processing of the Logout, which prompts an iSCSI 5236 Logout response (success) to be sent; an internal event of 5237 sending a Logout response (success) on another connection 5238 for a "close the session" Logout request was received; or 5239 an internal event of a successful connection/session 5240 reinstatement is received. In all these cases, the 5241 transport connection is closed. 5243 -T14: 5244 -initiator: Async PDU with AsyncEvent "Request Logout" was 5245 received again. 5246 -target: Illegal 5247 -T15, T16: 5248 -initiator: One or more of the following events caused this 5249 transition: 5250 -Internal event that indicates a transport connection 5251 timeout was received thus prompting transport RESET or 5252 transport connection closure. 5253 -A transport RESET. 5254 -A transport disconnect indication. 5255 -Async PDU with AsyncEvent "Drop connection" (for this 5256 CID). 5257 -Async PDU with AsyncEvent "Drop all connections". 5258 -target: One or more of the following events caused this 5259 transition: 5260 -Internal event that indicates a transport connection 5261 timeout was received, thus prompting transport RESET or 5262 transport connection closure. 5263 -An internal event of a failed connection/session 5264 reinstatement is received. 5265 -A transport RESET. 5266 -A transport disconnect indication. 5267 -Internal emergency cleanup event was received which 5268 prompts an Async PDU with AsyncEvent "Drop connection" 5269 (for this CID), or event "Drop all connections". 5271 -T17: 5272 -initiator: One or more of the following events caused this 5273 transition: 5274 -Logout response, (failure i.e., a non-zero status) was 5275 received, or Logout timed out. 5276 -Any of the events specified for T15 and T16. 5277 -target: One or more of the following events caused this 5278 transition: 5280 -Internal event that indicates a failure of the Logout 5281 processing was received, which prompts a Logout 5282 response (failure, i.e., a non-zero status) to be sent. 5283 -Any of the events specified for T15 and T16. 5284 -T18: 5285 -initiator: An internal event of receiving a Logout 5286 response (success) on another connection for a "close the 5287 session" Logout request was received. 5289 -target: An internal event of sending a Logout response 5290 (success) on another connection for a "close the session" 5291 Logout request was received, or an internal event of a 5292 successful connection/session reinstatement is received. 5293 In both these cases, the connection is closed. 5295 The CLEANUP_WAIT state (S8) implies that there are possible iSCSI 5296 tasks that have not reached conclusion and are still considered 5297 busy. 5299 8.1.3. Standard Connection State Diagram for an Initiator 5301 Symbolic names for States: 5303 S1: FREE 5305 S2: XPT_WAIT 5307 S4: IN_LOGIN 5309 S5: LOGGED_IN 5311 S6: IN_LOGOUT 5313 S7: LOGOUT_REQUESTED 5315 S8: CLEANUP_WAIT 5317 States S5, S6, and S7 constitute the Full Feature Phase operation 5318 of the connection. 5320 The state diagram is as follows: 5322 -------<-------------+ 5323 +--------->/ S1 \<----+ | 5324 T13| +->\ /<-+ \ | 5325 | / ---+--- \ \ | 5326 | / | T2 \ | | 5327 | T8 | |T1 | | | 5328 | | | / |T7 | 5329 | | | / | | 5330 | | | / | | 5331 | | V / / | 5332 | | ------- / / | 5333 | | / S2 \ / | 5334 | | \ / / | 5335 | | ---+--- / | 5336 | | |T4 / | 5337 | | V / | T18 5338 | | ------- / | 5339 | | / S4 \ | 5340 | | \ / | 5341 | | ---+--- | T15 5342 | | |T5 +--------+---------+ 5343 | | | /T16+-----+------+ | 5344 | | | / -+-----+--+ | | 5345 | | | / / S7 \ |T12| | 5346 | | | / +->\ /<-+ V V 5347 | | | / / -+----- ------- 5348 | | | / /T11 |T10 / S8 \ 5349 | | V / / V +----+ \ / 5350 | | ---+-+- ----+-- | ------- 5351 | | / S5 \T9 / S6 \<+ ^ 5352 | +-----\ /--->\ / T14 | 5353 | ------- --+----+------+T17 5354 +---------------------------+ 5356 The following state transition table represents the above diagram. 5357 Each row represents the starting state for a given transition, 5358 which after taking a transition marked in a table cell would end 5359 in the state represented by the column of the cell. For example, 5360 from state S1, the connection takes the T1 transition to arrive at 5361 state S2. The fields marked "-" correspond to undefined 5362 transitions. 5364 +----+---+---+---+---+----+---+ 5365 |S1 |S2 |S4 |S5 |S6 |S7 |S8 | 5366 ---+----+---+---+---+---+----+---+ 5367 S1| - |T1 | - | - | - | - | - | 5368 ---+----+---+---+---+---+----+---+ 5369 S2|T2 |- |T4 | - | - | - | - | 5370 ---+----+---+---+---+---+----+---+ 5371 S4|T7 |- |- |T5 | - | - | - | 5372 ---+----+---+---+---+---+----+---+ 5373 S5|T8 |- |- | - |T9 |T11 |T15| 5374 ---+----+---+---+---+---+----+---+ 5375 S6|T13 |- |- | - |T14|- |T17| 5376 ---+----+---+---+---+---+----+---+ 5377 S7|T18 |- |- | - |T10|T12 |T16| 5378 ---+----+---+---+---+---+----+---+ 5379 S8| - |- |- | - | - | - | - | 5380 ---+----+---+---+---+---+----+---+ 5382 8.1.4. Standard Connection State Diagram for a Target 5384 Symbolic names for States: 5385 S1: FREE 5387 S3: XPT_UP 5389 S4: IN_LOGIN 5391 S5: LOGGED_IN 5393 S6: IN_LOGOUT 5395 S7: LOGOUT_REQUESTED 5397 S8: CLEANUP_WAIT 5399 States S5, S6, and S7 constitute the Full Feature Phase operation 5400 of the connection. 5402 The state diagram is as follows: 5404 -------<-------------+ 5405 +--------->/ S1 \<----+ | 5406 T13| +->\ /<-+ \ | 5407 | / ---+--- \ \ | 5408 | / | T6 \ | | 5409 | T8 | |T3 | | | 5410 | | | / |T7 | 5411 | | | / | | 5412 | | | / | | 5413 | | V / / | 5414 | | ------- / / | 5415 | | / S3 \ / | 5416 | | \ / / | T18 5417 | | ---+--- / | 5418 | | |T4 / | 5419 | | V / | 5420 | | ------- / | 5421 | | / S4 \ | 5422 | | \ / | 5423 | | ---+--- T15 | 5424 | | |T5 +--------+---------+ 5425 | | | /T16+-----+------+ | 5426 | | | / -+-----+---+ | | 5427 | | | / / S7 \ |T12| | 5428 | | | / +->\ /<-+ V V 5429 | | | / / -+----- ------- 5430 | | | / /T11 |T10 / S8 \ 5431 | | V / / V \ / 5432 | | ---+-+- ------- ------- 5433 | | / S5 \T9 / S6 \ ^ 5434 | +-----\ /--->\ / | 5435 | ------- --+----+--------+T17 5436 +---------------------------+ 5438 The following state transition table represents the above diagram, 5439 and follows the conventions described for the initiator diagram. 5441 +----+---+---+---+---+----+---+ 5442 |S1 |S3 |S4 |S5 |S6 |S7 |S8 | 5443 ---+----+---+---+---+---+----+---+ 5444 S1| - |T3 | - | - | - | - | - | 5445 ---+----+---+---+---+---+----+---+ 5446 S3|T6 |- |T4 | - | - | - | - | 5447 ---+----+---+---+---+---+----+---+ 5448 S4|T7 |- |- |T5 | - | - | - | 5449 ---+----+---+---+---+---+----+---+ 5450 S5|T8 |- |- | - |T9 |T11 |T15| 5451 ---+----+---+---+---+---+----+---+ 5452 S6|T13 |- |- | - |- |- |T17| 5453 ---+----+---+---+---+---+----+---+ 5454 S7|T18 |- |- | - |T10|T12 |T16| 5455 ---+----+---+---+---+---+----+---+ 5456 S8| - |- |- | - | - | - | - | 5457 ---+----+---+---+---+---+----+---+ 5459 8.2. Connection Cleanup State Diagram for Initiators and Targets 5461 Symbolic names for states: 5463 R1: CLEANUP_WAIT (same as S8) 5465 R2: IN_CLEANUP 5467 R3: FREE (same as S1) 5469 Whenever a connection state machine in cleanup (let's call it CSM- 5470 C) enters the CLEANUP_WAIT state (S8), it must go through the 5471 state transitions described in the connection cleanup state 5472 diagram either a) using a separate full-feature phase connection 5473 (let's call it CSM-E, for explicit) in the LOGGED_IN state in the 5474 same session, or b) using a new transport connection (let's call 5475 it CSM-I, for implicit) in the FREE state that is to be added to 5476 the same session. In the CSM-E case, an explicit logout for the 5477 CID that corresponds to CSM-C (either as a connection or session 5478 logout) needs to be performed to complete the cleanup. In the CSM- 5479 I case, an implicit logout for the CID that corresponds to CSM-C 5480 needs to be performed by way of connection reinstatement (Section 5481 6.3.4) for that CID. In either case, the protocol exchanges on 5482 CSM-E or CSM-I determine the state transitions for CSM-C. 5483 Therefore, this cleanup state diagram is only applicable to the 5484 instance of the connection in cleanup (i.e., CSM-C). In the case 5485 of an implicit logout for example, CSM-C reaches FREE (R3) at the 5486 time CSM-I reaches LOGGED_IN. In the case of an explicit logout, 5487 CSM-C reaches FREE (R3) when CSM-E receives a successful logout 5488 response while continuing to be in the LOGGED_IN state. 5490 An initiator must initiate an explicit or implicit connection 5491 logout for a connection in the CLEANUP_WAIT state, if the 5492 initiator intends to continue using the associated iSCSI session. 5494 The following state diagram applies to both initiators and 5495 targets. 5497 ------- 5498 / R1 \ 5499 +--\ /<-+ 5500 / ---+--- \ 5501 / | \ M3 5502 M1 | |M2 | 5503 | | / 5504 | | / 5505 | | / 5506 | V / 5507 | ------- / 5508 | / R2 \ 5509 | \ / 5510 | ------- 5511 | | 5512 | |M4 5513 | | 5514 | | 5515 | | 5516 | V 5517 | ------- 5518 | / R3 \ 5519 +---->\ / 5520 ------- 5522 The following state transition table represents the above diagram, 5523 and follows the same conventions as in earlier sections. 5525 +----+----+----+ 5526 |R1 |R2 |R3 | 5527 -----+----+----+----+ 5528 R1 | - |M2 |M1 | 5529 -----+----+----+----+ 5530 R2 |M3 | - |M4 | 5531 -----+----+----+----+ 5532 R3 | - | - | - | 5533 -----+----+----+----+ 5535 8.2.1. State Descriptions for Initiators and Targets 5537 -R1: CLEANUP_WAIT (Same as S8) 5538 -initiator: Waiting for the internal event to initiate the 5539 cleanup processing for CSM-C. 5540 -target: Waiting for the cleanup process to start for CSM- 5541 C. 5542 -R2: IN_CLEANUP 5543 -initiator: Waiting for the connection cleanup process to 5544 conclude for CSM-C. 5545 -target: Waiting for the connection cleanup process to 5546 conclude for CSM-C. 5547 -R3: FREE (Same as S1) 5548 -initiator: End state for CSM-C. 5549 -target: End state for CSM-C. 5551 8.2.2. State Transition Descriptions for Initiators and Targets 5553 -M1: One or more of the following events was received: 5554 -initiator: 5555 -An internal event that indicates connection state 5556 timeout. 5557 -An internal event of receiving a successful Logout 5558 response on a different connection for a "close the 5559 session" Logout. 5560 -target: 5561 -An internal event that indicates connection state 5562 timeout. 5563 -An internal event of sending a Logout response 5564 (success) on a different connection for a "close the 5565 session" Logout request. 5567 -M2: An implicit/explicit logout process was initiated by the 5568 initiator. 5569 -In CSM-I usage: 5570 -initiator: An internal event requesting the connection 5571 (or session) reinstatement was received, thus prompting 5572 a connection (or session) reinstatement Login to be 5573 sent transitioning CSM-I to state IN_LOGIN. 5574 -target: A connection/session reinstatement Login was 5575 received while in state XPT_UP. 5576 -In CSM-E usage: 5578 -initiator: An internal event that indicates that an 5579 explicit logout was sent for this CID in state 5580 LOGGED_IN. 5581 -target: An explicit logout was received for this CID 5582 in state LOGGED_IN. 5583 -M3: Logout failure detected 5584 -In CSM-I usage: 5585 -initiator: CSM-I failed to reach LOGGED_IN and arrived 5586 into FREE instead. 5587 -target: CSM-I failed to reach LOGGED_IN and arrived 5588 into FREE instead. 5589 -In CSM-E usage: 5590 -initiator: CSM-E either moved out of LOGGED_IN, or 5591 Logout timed out and/or aborted, or Logout response 5592 (failure) was received. 5593 -target: CSM-E either moved out of LOGGED_IN, Logout 5594 timed out and/or aborted, or an internal event that 5595 indicates a failed Logout processing was received. A 5596 Logout response (failure) was sent in the last case. 5598 -M4: Successful implicit/explicit logout was performed. 5599 - In CSM-I usage: 5600 -initiator: CSM-I reached state LOGGED_IN, or an 5601 internal event of receiving a Logout response (success) 5602 on another connection for a "close the session" Logout 5603 request was received. 5604 -target: CSM-I reached state LOGGED_IN, or an internal 5605 event of sending a Logout response (success) on a 5606 different connection for a "close the session" Logout 5607 request was received. 5608 - In CSM-E usage: 5609 -initiator: CSM-E stayed in LOGGED_IN and received a 5610 Logout response (success), or an internal event of 5611 receiving a Logout response (success) on another 5612 connection for a "close the session" Logout request was 5613 received. 5614 -target: CSM-E stayed in LOGGED_IN and an internal 5615 event indicating a successful Logout processing was 5616 received, or an internal event of sending a Logout 5617 response (success) on a different connection for a 5618 "close the session" Logout request was received. 5620 8.3. Session State Diagrams 5622 8.3.1. Session State Diagram for an Initiator 5624 Symbolic Names for States: 5626 Q1: FREE 5628 Q3: LOGGED_IN 5630 Q4: FAILED 5632 State Q3 represents the Full Feature Phase operation of the 5633 session. 5635 The state diagram is as follows: 5637 ------- 5638 / Q1 \ 5639 +------>\ /<-+ 5640 / ---+--- | 5641 / | |N3 5642 N6 | |N1 | 5643 | | | 5644 | N4 | | 5645 | +----------+ | / 5646 | | | | / 5647 | | | | / 5648 | | V V / 5649 -+--+-- -----+- 5650 / Q4 \ N5 / Q3 \ 5651 \ /<------\ / 5652 ------- ------- 5654 The state transition table is as follows: 5656 +---+---+---+ 5657 |Q1 |Q3 |Q4 | 5658 -----+---+---+---+ 5659 Q1 | - |N1 | - | 5660 -----+---+---+---+ 5661 Q3 |N3 | - |N5 | 5662 -----+---+---+---+ 5663 Q4 |N6 |N4 | - | 5664 -----+---+---+---+ 5666 8.3.2. Session State Diagram for a Target 5668 Symbolic Names for States: 5670 Q1: FREE 5672 Q2: ACTIVE 5674 Q3: LOGGED_IN 5676 Q4: FAILED 5678 Q5: IN_CONTINUE 5680 State Q3 represents the Full Feature Phase operation of the 5681 session. 5683 The state diagram is as follows: 5685 ------- 5686 +------------------>/ Q1 \ 5687 / +-------------->\ /<-+ 5688 | | ---+--- | 5689 | | ^ | |N3 5690 N 6 | |N11 N9| V N1 | 5691 | | +------ | 5692 | | / Q2 \ | 5693 | | \ / | 5694 | --+---- +--+--- | 5695 | / Q5 \ | | 5696 | \ / N10 | | 5697 | +-+---+------------+ | N2 / 5698 | ^ | | | / 5699 | N7| |N8 | | / 5700 | | | | V / 5701 -+---+-V V------+- 5702 / Q4 \ N5 / Q3 \ 5703 \ /<-------------\ / 5704 ------- ------- 5706 The state transition table is as follows: 5708 +----+----+----+----+----+ 5709 |Q1 |Q2 |Q3 |Q4 |Q5 | 5710 -----+----+----+----+----+----+ 5711 Q1 | - |N1 | - | - | - | 5712 -----+----+----+----+----+----+ 5713 Q2 |N9 | - |N2 | - | - | 5714 -----+----+----+----+----+----+ 5715 Q3 |N3 | - | - |N5 | - | 5716 -----+----+----+----+----+----+ 5717 Q4 |N6 | - | - | - |N7 | 5718 -----+----+----+----+----+----+ 5719 Q5 |N11 | - |N10 |N8 | - | 5720 -----+----+----+----+----+----+ 5722 8.3.3. State Descriptions for Initiators and Targets 5724 -Q1: FREE 5725 -initiator: State on instantiation or after cleanup. 5727 -target: State on instantiation or after cleanup. 5728 -Q2: ACTIVE 5729 -initiator: Illegal. 5730 -target: The first iSCSI connection in the session 5731 transitioned to IN_LOGIN, waiting for it to complete the 5732 login process. 5733 -Q3: LOGGED_IN 5734 -initiator: Waiting for all session events. 5735 -target: Waiting for all session events. 5736 -Q4: FAILED 5737 -initiator: Waiting for session recovery or session 5738 continuation. 5739 -target: Waiting for session recovery or session 5740 continuation. 5741 -Q5: IN_CONTINUE 5742 -initiator: Illegal. 5743 -target: Waiting for session continuation attempt to reach 5744 a conclusion. 5746 8.3.4. State Transition Descriptions for Initiators and Targets 5748 -N1: 5749 -initiator: At least one transport connection reached the 5750 LOGGED_IN state. 5751 -target: The first iSCSI connection in the session had 5752 reached the IN_LOGIN state. 5753 -N2: 5754 -initiator: Illegal. 5755 -target: At least one iSCSI connection reached the 5756 LOGGED_IN state. 5757 -N3: 5758 -initiator: Graceful closing of the session via session 5759 closure (Section 6.3.6 - "Session Continuation and 5760 Failure"). 5761 -target: Graceful closing of the session via session 5762 closure (Section 6.3.6 - "Session Continuation and 5763 Failure") or a successful session reinstatement cleanly 5764 closed the session. 5765 -N4: 5766 -initiator: A session continuation attempt succeeded. 5768 -target: Illegal. 5769 -N5: 5770 -initiator: Session failure (Section 6.3.6 - "Session 5771 Continuation and Failure") occurred. 5772 -target: Session failure (Section 6.3.6- "Session 5773 Continuation and Failure") occurred. 5774 -N6: 5775 -initiator: Session state timeout occurred, or a session 5776 reinstatement cleared this session instance. This results 5777 in the freeing of all associated resources and the session 5778 state is discarded. 5779 -target: Session state timeout occurred, or a session 5780 reinstatement cleared this session instance. This results 5781 in the freeing of all associated resources and the session 5782 state is discarded. 5783 -N7: 5784 -initiator: Illegal. 5785 -target: A session continuation attempt is initiated. 5786 -N8: 5787 -initiator: Illegal. 5788 -target: The last session continuation attempt failed. 5789 -N9: 5790 -initiator: Illegal. 5791 -target: Login attempt on the leading connection failed. 5792 -N10: 5793 -initiator: Illegal. 5794 -target: A session continuation attempt succeeded. 5795 -N11: 5796 -initiator: Illegal. 5797 -target: A successful session reinstatement cleanly closed 5798 the session. 5800 9. Security Considerations 5802 Historically, native storage systems have not had to consider 5803 security because their environments offered minimal security 5804 risks. That is, these environments consisted of storage devices 5805 either directly attached to hosts or connected via a Storage Area 5806 Network (SAN) distinctly separate from the communications network. 5807 The use of storage protocols, such as SCSI, over IP-networks 5808 requires that security concerns be addressed. iSCSI 5809 implementations must provide means of protection against active 5810 attacks (e.g., pretending to be another identity, message 5811 insertion, deletion, modification, and replaying) and passive 5812 attacks (e.g.,eavesdropping, gaining advantage by analyzing the 5813 data sent over the line). 5815 Although technically possible, iSCSI SHOULD NOT be configured 5816 without security. iSCSI configured without security should be 5817 confined, in extreme cases, to closed environments without any 5818 security risk. [RFC3723] specifies the mechanisms that must be 5819 used in order to mitigate risks fully described in that document. 5821 The following Section describes the security mechanisms provided 5822 by an iSCSI implementation. 5824 9.1. iSCSI Security Mechanisms 5826 The entities involved in iSCSI security are the initiator, target, 5827 and the IP communication end points. iSCSI scenarios in which 5828 multiple initiators or targets share a single communication end 5829 point are expected. To accommodate such scenarios, iSCSI uses two 5830 separate security mechanisms: In-band authentication between the 5831 initiator and the target at the iSCSI connection level (carried 5832 out by exchange of iSCSI Login PDUs), and packet protection 5833 (integrity, authentication, and confidentiality) by IPsec at the 5834 IP level. The two security mechanisms complement each other. The 5835 in-band authentication provides end-to-end trust (at login time) 5836 between the iSCSI initiator and the target while IPsec provides a 5837 secure channel between the IP communication end points. 5839 Further details on typical iSCSI scenarios and the relation 5840 between the initiators, targets, and the communication end points 5841 can be found in [RFC3723]. 5843 9.2. In-band Initiator-Target Authentication 5845 During login, the target MAY authenticate the initiator and the 5846 initiator MAY authenticate the target. The authentication is 5847 performed on every new iSCSI connection by an exchange of iSCSI 5848 Login PDUs using a negotiated authentication method. 5850 The authentication method cannot assume an underlying IPsec 5851 protection, because IPsec is optional to use. An attacker should 5852 gain as little advantage as possible by inspecting the 5853 authentication phase PDUs. Therefore, a method using clear text 5854 (or equivalent) passwords MUST NOT be used; on the other hand, 5855 identity protection is not strictly required. 5857 The authentication mechanism protects against an unauthorized 5858 login to storage resources by using a false identity (spoofing). 5859 Once the authentication phase is completed, if the underlying 5860 IPsec is not used, all PDUs are sent and received in clear. The 5861 authentication mechanism alone (without underlying IPsec) should 5862 only be used when there is no risk of eavesdropping, message 5863 insertion, deletion, modification, and replaying. 5865 Section 11 - "iSCSI Security Text Keys and Authentication Methods" 5866 defines several authentication methods and the exact steps that 5867 must be followed in each of them, including the iSCSI-text-keys 5868 and their allowed values in each step. Whenever an iSCSI initiator 5869 gets a response whose keys, or their values, are not according to 5870 the step definition, it MUST abort the connection. Whenever an 5871 iSCSI target gets a response whose keys, or their values, are not 5872 according to the step definition, it MUST answer with a Login 5873 reject with the "Initiator Error" or "Missing Parameter" status. 5874 These statuses are not intended for cryptographically incorrect 5875 values such as the CHAP response, for which "Authentication 5876 Failure" status MUST be specified. The importance of this rule can 5877 be illustrated in CHAP with target authentication (see Section 5878 12.1.3- "Challenge Handshake Authentication Protocol (CHAP)") 5879 where the initiator would have been able to conduct a reflection 5880 attack by omitting his response key (CHAP_R) using the same CHAP 5881 challenge as the target and reflecting the target's response back 5882 to the target. In CHAP, this is prevented because the target must 5883 answer the missing CHAP_R key with a Login reject with the 5884 "Missing Parameter" status. 5886 For some of the authentication methods, a key specifies the 5887 identity of the iSCSI initiator or target for authentication 5888 purposes. The value associated with that key MAY be different from 5889 the iSCSI name and SHOULD be configurable. (CHAP_N, see Section 5890 12.1.3 - "Challenge Handshake Authentication Protocol (CHAP)" and 5891 SRP_U, see Section 12.1.2- "Secure Remote Password (SRP)"). 5893 9.2.1. CHAP Considerations 5895 Compliant iSCSI initiators and targets MUST implement the CHAP 5896 authentication method [RFC1994] (according to Section 12.1.3 - 5897 "Challenge Handshake Authentication Protocol (CHAP)" including the 5898 target authentication option). 5900 When CHAP is performed over a non-encrypted channel, it is 5901 vulnerable to an off-line dictionary attack. Implementations MUST 5902 support use of up to 128 bit random CHAP secrets, including the 5903 means to generate such secrets and to accept them from an external 5904 generation source. Implementations MUST NOT provide secret 5905 generation (or expansion) means other than random generation. 5907 An administrative entity of an environment in which CHAP is used 5908 with a secret that has less than 96 random bits MUST enforce IPsec 5909 encryption (according to the implementation requirements in 5910 Confidentiality) to protect the connection. Moreover, in this case 5911 IKE authentication with group pre-shared cryptographic keys SHOULD 5912 NOT be used unless it is not essential to protect group members 5913 against off-line dictionary attacks by other members. 5915 CHAP secrets MUST be an integral number of bytes (octets). A 5916 compliant implementation SHOULD NOT continue with the login step 5917 in which it should send a CHAP response (CHAP_R, Section 12.1.3- 5918 "Challenge Handshake Authentication Protocol (CHAP)") unless it 5919 can verify that the CHAP secret is at least 96 bits, or that IPsec 5920 encryption is being used to protect the connection. 5922 Any CHAP secret used for initiator authentication MUST NOT be 5923 configured for authentication of any target, and any CHAP secret 5924 used for target authentication MUST NOT be configured for 5925 authentication of any initiator. If the CHAP response received by 5926 one end of an iSCSI connection is the same as the CHAP response 5927 that the receiving endpoint would have generated for the same CHAP 5928 challenge, the response MUST be treated as an authentication 5929 failure and cause the connection to close (this ensures that the 5930 same CHAP secret is not used for authentication in both 5931 directions). Also, if an iSCSI implementation can function as 5932 both initiator and target, different CHAP secrets and identities 5933 MUST be configured for these two roles. The following is an 5934 example of the attacks prevented by the above requirements: 5936 Rogue wants to impersonate Storage to Alice, and knows that a 5937 single secret is used for both directions of Storage-Alice 5938 authentication. 5940 Rogue convinces Alice to open two connections to Rogue, and 5941 Rogue identifies itself as Storage on both connections. 5943 Rogue issues a CHAP challenge on connection 1, waits for Alice 5944 to respond, and then reflects Alice's challenge as the 5945 initial challenge to Alice on connection 2. 5947 If Alice doesn't check for the reflection across connections, 5948 Alice's response on connection 2 enables Rogue to 5949 impersonate Storage on connection 1, even though Rogue does 5950 not know the Alice-Storage CHAP secret. 5952 Originators MUST NOT reuse the CHAP challenge sent by the 5953 Responder for the other direction of a bidirectional 5954 authentication. Responders MUST check for this condition and close 5955 the iSCSI TCP connection if it occurs. 5957 The same CHAP secret SHOULD NOT be configured for authentication 5958 of multiple initiators or multiple targets, as this enables any of 5959 them to impersonate any other one of them, and compromising one of 5960 them enables the attacker to impersonate any of them. It is 5961 recommended that iSCSI implementations check for use of identical 5962 CHAP secrets by different peers when this check is feasible, and 5963 take appropriate measures to warn users and/or administrators when 5964 this is detected. 5966 When an iSCSI initiator or target authenticates itself to 5967 counterparts in multiple administrative domains, it SHOULD use a 5968 different CHAP secret for each administrative domain to avoid 5969 propagating security compromises across domains. 5971 Within a single administrative domain: 5972 - A single CHAP secret MAY be used for authentication of an 5973 initiator to multiple targets. 5975 - A single CHAP secret MAY be used for an authentication of a 5976 target to multiple initiators when the initiators use an 5977 external server (e.g., RADIUS) to verify the target's CHAP 5978 responses and do not know the target's CHAP secret. 5980 If an external response verification server (e.g., RADIUS) is not 5981 used, employing a single CHAP secret for authentication of a 5982 target to multiple initiators requires that all such initiators 5983 know that target secret. Any of these initiators can impersonate 5984 the target to any other such initiator, and compromise of such an 5985 initiator enables an attacker to impersonate the target to all 5986 such initiators. Targets SHOULD use separate CHAP secrets for 5987 authentication to each initiator when such risks are of concern; 5988 in this situation it may be useful to configure a separate logical 5989 iSCSI target with its own iSCSI Node Name for each initiator or 5990 group of initiators among which such separation is desired. 5992 9.2.2. SRP Considerations 5994 The strength of the SRP authentication method (specified in 5995 [RFC2945]) is dependent on the characteristics of the group being 5996 used (i.e., the prime modulus N and generator g). As described in 5997 [RFC2945], N is required to be a Sophie-German prime (of the form 5998 N = 2q + 1, where q is also prime) and the generator g is a 5999 primitive root of GF(n). In iSCSI authentication, the prime 6000 modulus N MUST be at least 768 bits. 6002 The list of allowed SRP groups is provided in [RFC3723]. 6004 9.3. IPsec 6006 iSCSI uses the IPsec mechanism for packet protection 6007 (cryptographic integrity, authentication, and confidentiality) at 6008 the IP level between the iSCSI communicating end points. The 6009 following sections describe the IPsec protocols that must be 6010 implemented for data integrity and authentication, 6011 confidentiality, and cryptographic key management. 6013 An iSCSI initiator or target may provide the required IPsec 6014 support fully integrated or in conjunction with an IPsec front-end 6015 device. In the latter case, the compliance requirements with 6016 regard to IPsec support apply to the "combined device". Only the 6017 "combined device" is to be considered an iSCSI device. 6019 Detailed considerations and recommendations for using IPsec for 6020 iSCSI are provided in [RFC3723]. 6022 This document updates RFC 3723 to add requirements for IPsec v3 6023 as specified in [RFC4301] and related RFCs. The IPsec v2 "MUST 6024 implement" requirements from [RFC3723] are left unchanged by this 6025 document; this document adds requirements that IPsec v3, as 6026 specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), 6027 SHOULD be implemented. The mandatory requirement for IPsec v2 6028 preserves interoperability with existing implementations, and the 6029 strong recommendation for IPsec v3 encourages implementers to move 6030 forward to that newer version of IPsec. 6032 9.3.1. Data Integrity and Authentication 6034 Data authentication and integrity is provided by a cryptographic 6035 keyed Message Authentication Code in every sent packet. This code 6036 protects against message insertion, deletion, and modification. 6037 Protection against message replay is realized by using a sequence 6038 counter. 6040 An iSCSI-compliant initiator or target MUST provide data integrity 6041 and authentication by implementing IPsec v2 [RFC2401] with ESPv2 6042 [RFC2406] in tunnel mode, SHOULD provide data integrity and 6043 authentication by implementing IPsec v3 [RFC4301] with ESPv3 6044 [RFC4303] in tunnel mode, and MAY provide data integrity and 6046 authentication by implementing either IPsec v2 or v3 with the 6047 appropriate version of ESP in transport mode. The IPsec 6048 implementation MUST fulfill the following iSCSI specific 6049 requirements: 6051 - HMAC-SHA1 MUST be implemented [RFC2404]. 6053 - AES CBC MAC with XCBC extensions SHOULD be implemented 6054 [RFC3566]. 6056 - Implementations that support IKEv2 [RFC5996] SHOULD also 6057 implement AES GMAC [RFC4543] 6059 The ESP anti-replay service MUST also be implemented. 6061 At the high speeds iSCSI is expected to operate, a single IPsec SA 6062 could rapidly cycle through the ESP 32-bit sequence number space. 6063 In view of this, an iSCSI implementation that is capable of 6064 operating at speeds of 1 Gbps and that implements both IKEv2 6065 [RFC5996] and ESPv3 [RFC4303] MUST also implement extended (64- 6066 bit) sequence numbers for ESPv3 and SHOULD use ESPv3 extended 6067 sequence numbers for all security associations that use ESPv3 to 6068 protect iSCSI connections. 6069 9.3.2. Confidentiality 6071 Confidentiality is provided by encrypting the data in every 6072 packet. When confidentiality is used it MUST be accompanied by 6073 data integrity and authentication to provide comprehensive 6074 protection against eavesdropping, message insertion, deletion, 6075 modification, and replaying. 6077 An iSCSI compliant initiator or target MUST provide 6078 confidentiality by implementing IPsec v2 [RFC2401] with ESPv2 6079 [RFC2406] in tunnel mode, SHOULD provide confidentiality by 6080 implementing IPsec v3 [RFC4301] with ESPv3 [RFC4303] in tunnel 6081 mode and MAY provide confidentiality by implementing either IPsec 6082 v2 or v3 with the appropriate version of ESP in transport mode, 6083 with the following iSCSI specific requirements that apply to IPsec 6084 v2 and IPsec v3: 6085 - 3DES in CBC mode MUST be implemented [RFC2451]. 6087 - AES in Counter mode SHOULD be implemented [RFC3686]. 6089 - Implementations that support IKEv2 [RFC5996] SHOULD also 6090 implement AES GCM [RFC4106] 6092 DES in CBC mode MUST NOT be used due to its inherent weakness. 6094 The NULL encryption algorithm MUST also be implemented. 6096 9.3.3. Policy, Security Associations, and Cryptographic Key 6097 Management 6099 A compliant iSCSI implementation MUST meet the cryptographic key 6100 management requirements of the IPsec protocol suite. 6101 Authentication, security association negotiation, and 6102 cryptographic key management MUST be provided by implementing IKE 6103 [RFC5996] using the IPsec DOI [RFC5996] with the following iSCSI 6104 specific requirements: 6106 - Peer authentication using a pre-shared cryptographic key 6107 MUST be supported. Certificate-based peer authentication 6108 using digital signatures MAY be supported. For IKEv1 6109 ([RFC2409]), peer authentication using the public key 6110 encryption methods outlined in IKE sections 5.2 and 5.3 of 6111 [RFC2409] SHOULD NOT be used. 6113 - When digital signatures are used to achieve authentication, 6114 an IKE negotiator SHOULD use IKE Certificate Request 6115 Payload(s) to specify the certificate authority. IKE 6116 negotiators SHOULD check the pertinent Certificate 6117 Revocation List (CRL) before accepting a PKI certificate for 6118 use in IKE authentication procedures. 6120 - Conformant iSCSI implementations of IKEv1 MUST support Main 6121 Mode and SHOULD support Aggressive Mode. Main Mode with pre- 6122 shared key authentication method SHOULD NOT be used when 6123 either the initiator or the target uses dynamically assigned 6125 addresses. While in many cases pre-shared keys offer good 6126 security, situations in which dynamically assigned addresses 6127 are used force the use of a group pre-shared key, which 6128 creates vulnerability to a man-in-the-middle attack. 6130 - In the IKEv1 Phase 2 Quick Mode, exchanges for creating the 6131 Phase 2 SA, the Identification Payload MUST be present. 6133 - The following identification type requirements apply to IKEv1. 6134 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports 6135 IPv6) and ID_FQDN Identification Types MUST be supported; 6136 ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address 6137 Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types 6138 SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT 6139 be used. 6141 - If IKEv2 is supported, the following identification requirements 6142 apply. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack 6143 supports IPv6) and ID_FQDN Identification Types MUST be 6144 supported; ID_RFC822_ADDR SHOULD be supported. The 6145 ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD 6146 NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. 6148 Manual cryptographic keying MUST NOT be used because it does not 6149 provide the necessary re-keying support. 6151 When DH groups are used, a DH group of at least 2048 bits SHOULD 6152 be offered as a part of all proposals to create IPsec Security 6153 Associations to protect iSCSI traffic. 6155 When IPsec is used, the receipt of an IKEv1 Phase 2 delete message 6156 or an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT 6157 be interpreted as a reason for tearing down the iSCSI TCP 6158 connection. If additional traffic is sent on it, a new IKE SA will 6159 be created to protect it. 6161 The method used by the initiator to determine whether the target 6162 should be connected using IPsec is regarded as an issue of IPsec 6163 policy administration, and thus not defined in the iSCSI standard. 6165 The method used by an initiator that supports both IPsec v2 and v3 6166 to determine which versions of IPsec are supported by the target 6167 is also regarded as an issue of IPsec policy administration, and 6168 thus not defined in the iSCSI standard. If both IPsec v2 and v3 6169 are supported by both the initiator and target, use of IPsec v3 is 6170 recommended. 6172 If an iSCSI target is discovered via a SendTargets request in a 6173 discovery session not using IPsec, the initiator should assume 6174 that it does not need IPsec to establish a session to that target. 6175 If an iSCSI target is discovered using a discovery session that 6176 does use IPsec, the initiator SHOULD use IPsec when establishing a 6177 session to that target. 6179 9.4. Security Considerations for the X#NodeArchitecture Key 6181 The security considerations in this Section are specific to the 6182 X#NodeArchitecture discussed in Section 13.26. 6184 This extension key transmits specific implementation details about 6185 the node that sends it; such details may be considered sensitive 6186 in some environments. For example, if a certain software or 6187 firmware version is known to contain security weaknesses, 6188 announcing the presence of that version via this key may not be 6189 desirable. The countermeasures for this security concern are: 6191 - sending less detailed information in the key values, 6192 - not sending the extension key, or 6193 - using IPsec ([RFC4303]) to provide confidentiality for 6194 the iSCSI connection on which the key is sent 6195 To support the first and second countermeasures, all 6196 implementations of this extension key MUST provide an 6197 administrative mechanism to disable sending the key. In addition, 6198 all implementations SHOULD provide an administrative mechanism to 6199 configure a verbosity level of the key value, thereby controlling 6200 the amount of information sent. 6202 For example, a lower verbosity might enable transmission of node 6203 architecture component names only, but no version numbers. The 6204 choice of which countermeasure is most appropriate depends on the 6205 environment. However, sending less detailed information in the key 6206 values may be an acceptable countermeasure in many environments, 6207 since it provides a compromise between sending too much 6208 information and the other more complete countermeasures of not 6209 sending the key at all or using IPsec. 6211 In addition to security considerations involving transmission of 6212 the key contents, any logging method(s) used for the key values 6213 MUST keep the information secure from intruders. For all 6214 implementations, the requirements to address this security concern 6215 are: 6217 - Display of the log MUST only be possible with administrative 6218 rights to the node. 6220 - Options to disable logging to disk and to keep logs for a 6221 fixed duration SHOULD be provided. 6223 Finally, it is important to note that different nodes may have 6224 different levels of risk, and these differences may affect the 6225 implementation. The components of risk include assets, threats, 6226 and vulnerabilities. Consider the following example iSCSI nodes, 6227 which demonstrate differences in assets and vulnerabilities of the 6228 nodes, and as a result, differences in implementation: 6230 One iSCSI target based on a special-purpose operating system: 6231 Since the iSCSI target controls access to the data storage 6232 containing company assets, the asset level is seen as very 6233 high. Also, because of the special-purpose operating 6234 system, in which vulnerabilities are less well-known, the 6235 vulnerability level is viewed as low. 6237 Multiple iSCSI initiators in a blade farm, each running a 6238 general purpose operating system: The asset level of each 6239 node is viewed as low, since blades are replaceable and low 6240 cost. However, the vulnerability level is viewed as high, 6242 since there may be many wellknown vulnerabilities to that 6243 general-purpose operating system. For this target, an 6244 appropriate implementation might be logging of received key 6245 values, but no transmission of the key. For this initiator, 6246 an appropriate implementation might be transmission of the 6247 key, but no logging of received key values. 6249 10. Notes to Implementers 6251 This Section notes some of the performance and reliability 6252 considerations of the iSCSI protocol. This protocol was designed 6253 to allow efficient silicon and software implementations. The iSCSI 6254 task tag mechanism was designed to enable Direct Data Placement 6255 (DDP - a DMA form) at the iSCSI level or lower. 6257 The guiding assumption made throughout the design of this protocol 6258 is that targets are resource constrained relative to initiators. 6260 Implementers are also advised to consider the implementation 6261 consequences of the iSCSI to SCSI mapping model as outlined in 6262 Section 4.4.3 - "Consequences of the Model". 6264 10.1. Multiple Network Adapters 6266 The iSCSI protocol allows multiple connections, not all of which 6267 need to go over the same network adapter. If multiple network 6268 connections are to be utilized with hardware support, the iSCSI 6269 protocol command-data-status allegiance to one TCP connection 6270 ensures that there is no need to replicate information across 6271 network adapters or otherwise require them to cooperate. 6273 However, some task management commands may require some loose form 6274 of cooperation or replication at least on the target. 6276 10.1.1. Conservative Reuse of ISIDs 6278 Historically, the SCSI model (and implementations and applications 6279 based on that model) has assumed that SCSI ports are static, 6280 physical entities. Recent extensions to the SCSI model have taken 6281 advantage of persistent worldwide unique names for these ports. In 6282 iSCSI however, the SCSI initiator ports are the endpoints of 6283 dynamically created sessions, so the presumptions of "static and 6284 physical" do not apply. In any case, the model clauses 6285 (particularly, Section 4.4.1- "SCSI Architecture Model") provide 6286 for persistent, reusable names for the iSCSI-type SCSI initiator 6287 ports even though there does not need to be any physical entity 6288 bound to these names. 6290 To both minimize the disruption of legacy applications and to 6291 better facilitate the SCSI features that rely on persistent names 6292 for SCSI ports, iSCSI implementations SHOULD attempt to provide a 6293 stable presentation of SCSI Initiator Ports (both to the upper OS- 6294 layers and to the targets to which they connect). This can be 6295 achieved in an initiator implementation by conservatively reusing 6296 ISIDs. In other words, the same ISID should be used in the Login 6297 process to multiple target portal groups (of the same iSCSI Target 6298 or different iSCSI Targets). The ISID RULE (Section 4.4.3- 6299 "Consequences of the Model") only prohibits reuse to the same 6300 target portal group. It does not "preclude" reuse to other target 6301 portal groups. 6302 The principle of conservative reuse "encourages" reuse to other 6303 target portal groups. When a SCSI target device sees the same 6304 (InitiatorName, ISID) pair in different sessions to different 6305 target portal groups, it can identify the underlying SCSI 6306 Initiator Port on each session as the same SCSI port. In effect, 6307 it can recognize multiple paths from the same source. 6309 10.1.2. iSCSI Name, ISID, and TPGT Use 6311 The designers of the iSCSI protocol are aware that legacy SCSI 6312 transports rely on initiator identity to assign access to storage 6313 resources. Although newer techniques are available and simplify 6314 access control, support for configuration and authentication 6315 schemes that are based on initiator identity is deemed important 6316 in order to support legacy systems and administration software. 6317 iSCSI thus supports the notion that it should be possible to 6318 assign access to storage resources based on "initiator device" 6319 identity. 6321 When there are multiple hardware or software components 6322 coordinated as a single iSCSI Node, there must be some (logical) 6323 entity that represents the iSCSI Node that makes the iSCSI Node 6324 Name available to all components involved in session creation and 6325 login. Similarly, this entity that represents the iSCSI Node must 6326 be able to coordinate session identifier resources (ISID for 6327 initiators) to enforce both the ISID and TSIH RULES (see Section 6328 4.4.3- "Consequences of the Model"). 6330 For targets, because of the closed environment, implementation of 6331 this entity should be straightforward. However, vendors of iSCSI 6332 hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide 6333 mechanisms for configuration of the iSCSI Node Name across the 6334 portal groups instantiated by multiple instances of these 6335 components within a target. 6337 However, complex targets making use of multiple Target Portal 6338 Group Tags may reconfigure them to achieve various quality goals. 6339 The initiators have two mechanisms at their disposal to discover 6340 and/or check reconfiguring targets - the discovery session type 6341 and a key returned by the target during login to confirm the TPGT. 6342 An initiator should attempt to "rediscover" the target 6343 configuration anytime a session is terminated unexpectedly. 6345 For initiators, in the long term, it is expected that operating 6346 system vendors will take on the role of this entity and provide 6347 standard APIs that can inform components of their iSCSI Node Name 6348 and can configure and/or coordinate ISID allocation, use, and 6349 reuse. 6351 Recognizing that such initiator APIs are not available today, 6352 other implementations of the role of this entity are possible. For 6353 example, a human may instantiate the (common) Node name as part of 6354 the installation process of each iSCSI component involved in 6355 session creation and login. This may be done either by pointing 6356 the component to a vendor-specific location for this datum or to a 6357 system-wide location. The structure of the ISID namespace (see 6358 Section 11.12.5 - "ISID" and [RFC3721]) facilitates implementation 6359 of the ISID coordination by allowing each component vendor to 6360 independently (of other vendor's components) coordinate 6361 allocation, use, and reuse of its own partition of the ISID 6362 namespace in a vendor-specific manner. Partitioning of the ISID 6363 namespace within initiator portal groups managed by that vendor 6364 allows each such initiator portal group to act independently of 6365 all other portal groups when selecting an ISID for a login; this 6366 facilitates enforcement of the ISID RULE (see Section 4.4.3- 6367 "Consequences of the Model") at the initiator. 6369 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use 6370 in initiators MUST implement a mechanism for configuring the iSCSI 6371 Node Name. Vendors, and administrators must ensure that iSCSI Node 6372 Names are unique worldwide. It is therefore important that when 6373 one chooses to reuse the iSCSI Node Name of a disabled unit, not 6374 to re-assign that name to the original unit unless its worldwide 6375 uniqueness can be ascertained again. 6377 In addition, a vendor of iSCSI hardware must implement a mechanism 6378 to configure and/or coordinate ISIDs for all sessions managed by 6379 multiple instances of that hardware within a given iSCSI Node. 6380 Such configuration might be either permanently pre-assigned at the 6381 factory (in a necessarily globally unique way), statically 6382 assigned (e.g., partitioned across all the NICs at initialization 6383 in a locally unique way), or dynamically assigned (e.g., on-line 6384 allocator, also in a locally unique way). In the latter two cases, 6385 the configuration may be via public APIs (perhaps driven by an 6386 independent vendor's software, such as the OS vendor) or via 6387 private APIs driven by the vendor's own software. 6389 The process of name assignment and coordination has to be as 6390 encompassing and automated as possible as years of legacy usage 6391 have shown it to be highly error-prone. It is to be mentioned 6392 that SCSI has today alternative schemes of access control that can 6393 be used by all transports and their security is not dependent on 6394 strict naming coordination. 6396 10.2. Autosense and Auto Contingent Allegiance (ACA) 6398 Autosense refers to the automatic return of sense data to the 6399 initiator in case a command did not complete successfully. iSCSI 6400 initiators and targets MUST support and use autosense. 6402 ACA helps preserve ordered command execution in the presence of 6403 errors. As there can be many commands in-flight between an 6404 initiator and a target, SCSI initiator functionality in some 6405 operating systems depends on ACA to enforce ordered command 6406 execution during error recovery, and hence iSCSI initiator 6407 implementations for those operating systems need to support ACA. 6408 In order to support error recovery for these operating systems and 6409 iSCSI initiators, iSCSI targets SHOULD support ACA. 6411 10.3. iSCSI Timeouts 6413 iSCSI recovery actions are often dependent on iSCSI time-outs 6414 being recognized and acted upon before SCSI time-outs. Determining 6415 the right time-outs to use for various iSCSI actions (command 6416 acknowledgements expected, status acknowledgements, etc.) is very 6417 much dependent on infrastructure (hardware, links, TCP/IP stack, 6418 iSCSI driver). As a guide, the implementer may use an average Nop- 6419 Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 6420 4) as a good estimate for the basic delay of the iSCSI stack for a 6421 given connection. The safety factor should account for the network 6422 load variability. For connection teardown the implementer may 6423 want to consider also TCP common practice for the given 6424 infrastructure. 6426 Text negotiations MAY also be subject to either time-limits or 6427 limits in the number of exchanges. Those SHOULD be generous enough 6428 to avoid affecting interoperability (e.g., allowing each key to be 6429 negotiated on a separate exchange). 6431 The relation between iSCSI timeouts and SCSI timeouts should also 6432 be considered. SCSI timeouts should be longer than iSCSI timeouts 6433 plus the time required for iSCSI recovery whenever iSCSI recovery 6434 is planned. Alternatively, an implementer may choose to interlock 6435 iSCSI timeouts and recovery with SCSI timeouts so that SCSI 6436 recovery will become active only where iSCSI is not planned to, or 6437 failed to, recover. 6439 The implementer may also want to consider the interaction between 6440 various iSCSI exception events - such as a digest failure - and 6441 subsequent timeouts. When iSCSI error recovery is active, a digest 6442 failure is likely to result in discovering a missing command or 6443 data PDU. In these cases, an implementer may want to lower the 6444 timeout values to enable faster initiation for recovery 6445 procedures. 6447 10.4. Command Retry and Cleaning Old Command Instances 6449 To avoid having old, retried command instances appear in a valid 6450 command window after a command sequence number wrap around, the 6451 protocol requires (see Section 4.2.2.1- "Command Numbering and 6452 Acknowledging") that on every connection on which a retry has been 6453 issued, a non-immediate command be issued and acknowledged within 6454 a 2**31-1 commands interval from the CmdSN of the retried command. 6455 This requirement can be fulfilled by an implementation in several 6456 ways. 6458 The simplest technique to use is to send a (non-retry) non- 6459 immediate SCSI command (or a NOP if no SCSI command is available 6460 for a while) after every command retry on the connection on which 6461 the retry was attempted. As errors are deemed rare events, this 6462 technique is probably the most effective, as it does not involve 6463 additional checks at the initiator when issuing commands. 6465 10.5. Synch and Steering Layer and Performance 6467 While a synch and steering layer is optional, an initiator/target 6468 that does not have it working against a target/initiator that 6469 demands synch and steering may experience performance degradation 6470 caused by packet reordering and loss. Providing a synch and 6471 steering mechanism is recommended for all high-speed 6472 implementations. 6474 10.6. Considerations for State-dependent Devices and Long-lasting 6475 SCSI Operations 6477 Sequential access devices operate on the principle that the 6478 position of the device is based on the last command processed. As 6479 such, command processing order and knowledge of whether or not the 6480 previous command was processed is of the utmost importance to 6481 maintain data integrity. For example, inadvertent retries of SCSI 6482 commands when it is not known if the previous SCSI command was 6483 processed is a potential data integrity risk. 6485 For a sequential access device, consider the scenario in which a 6486 SCSI SPACE command to backspace one filemark is issued and then 6487 re-issued due to no status received for the command. If the first 6488 SPACE command was actually processed, the re-issued SPACE command, 6489 if processed, will cause the position to change. Thus, a 6490 subsequent write operation will write data to the wrong position 6491 and any previous data at that position will be overwritten. 6493 For a medium changer device, consider the scenario in which an 6494 EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION 6495 ADDRESS are the same thus performing a swap) is issued and then 6496 re-issued due to no status received for the command. If the first 6497 EXCHANGE MEDIUM command was actually processed, the re-issued 6498 EXCHANGE MEDIUM command, if processed, will perform the swap 6499 again. The net effect is no swap was performed thus leaving a data 6500 integrity exposure. 6502 All commands that change the state of the device (as in SPACE 6503 commands for sequential access devices, and EXCHANGE MEDIUM for 6504 medium changer device), MUST be issued as non-immediate commands 6505 for deterministic and in order delivery to iSCSI targets. 6507 For many of those state changing commands, the execution model 6508 also assumes that the command is executed exactly once. Devices 6509 implementing READ POSITION and LOCATE provide a means for SCSI 6510 level command recovery and new tape-class devices 6511 should support those commands. In their absence a retry at SCSI 6512 level is difficult and error recovery at iSCSI level is advisable. 6514 Devices operating on long latency delivery subsystems and 6515 performing long lasting SCSI operations may need mechanisms that 6516 enable connection replacement while commands are running (e.g., 6517 during an extended copy operation). 6519 10.6.1. Determining the Proper ErrorRecoveryLevel 6521 The implementation and use of a specific ErrorRecoveryLevel should 6522 be determined based on the deployment scenarios of a given iSCSI 6523 implementation. Generally, the following factors must be 6524 considered before deciding on the proper level of recovery: 6526 Application resilience to I/O failures. 6527 Required level of availability in the face of transport 6528 connection failures. 6529 Probability of transport layer "checksum escape". This in turn 6530 decides the iSCSI digest failure frequency, and thus the 6531 criticality of iSCSI-level error recovery. The details of 6532 estimating this probability are outside the scope of this 6533 document. 6535 A consideration of the above factors for SCSI tape devices as an 6536 example suggests that implementations SHOULD use 6537 ErrorRecoveryLevel=1 when transport connection failure is not a 6538 concern and SCSI level recovery is unavailable, and 6539 ErrorRecoveryLevel=2 when the connection failure is also of high 6540 likelihood during a backup/retrieval. 6542 For extended copy operations, implementations SHOULD use 6543 ErrorRecoveryLevel=2 whenever there is a relatively high 6544 likelihood of connection failure. 6546 10.7. Multi-task Abort Implementation Considerations 6548 Multi-task abort operations are typically issued in emergencies - 6549 such as clearing a device lock-up, HA failover/failback etc. In 6550 these circumstances, it is desirable to rapidly go through the 6551 error handling process as opposed to the target waiting on 6552 multiple third-party initiators who may not even be functional 6553 anymore - especially if this emergency is triggered because of one 6554 such initiator failure. Therefore, both iSCSI target and 6555 initiator implementations SHOULD support FastAbort multi-task 6556 abort semantics (Section 4.2.3.4). 6558 Note that both in standard semantics (Section 4.2.3.3) and 6559 FastAbort semantics (Section 4.2.3.4), there may be outstanding 6560 data transfers even after the TMF completion is reported on the 6561 issuing session. In the case of iSCSI/iSER [iSER], these would be 6562 tagged data transfers for STags not owned by any active tasks. 6563 Whether or not real buffers support these data transfers is 6564 implementation-dependent. However, the data transfers logically 6565 MUST be silently discarded by the target iSCSI layer in all cases. 6566 A target MAY, on an implementation-defined internal timeout, also 6567 choose to drop the connections on which it did not receive the 6568 expected Data-Out sequences (Section 4.2.3.3) or NOP-Out 6569 acknowledgements (Section 4.2.3.4) so as to reclaim the associated 6570 buffer, STag, and TTT resources as appropriate. 6572 11. iSCSI PDU Formats 6574 All multi-byte integers that are specified in formats defined in 6575 this document are to be represented in network byte order (i.e., 6576 big endian). Any field that appears in this document assumes that 6577 the most significant byte is the lowest numbered byte and the most 6578 significant bit (within byte or field) is the lowest numbered bit 6579 unless specified otherwise. 6581 Any compliant sender MUST set all bits not defined and all 6582 reserved fields to zero unless specified otherwise. Any compliant 6583 receiver MUST ignore any bit not defined and all reserved fields 6584 unless specified otherwise. Receipt of reserved code values in 6585 defined fields MUST be reported as a protocol error. 6587 Reserved fields are marked by the word "reserved", some 6588 abbreviation of "reserved", or by "." for individual bits when no 6589 other form of marking is technically feasible. 6591 11.1. iSCSI PDU Length and Padding 6593 iSCSI PDUs are padded to the closest integer number of four byte 6594 words. The padding bytes SHOULD be sent as 0. 6596 11.2. PDU Template, Header, and Opcodes 6598 All iSCSI PDUs have one or more header segments and, optionally, a 6599 data segment. After the entire header segment group a header- 6600 digest MAY follow. The data segment MAY also be followed by a 6601 data-digest. 6603 The Basic Header Segment (BHS) is the first segment in all of the 6604 iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It 6605 MAY be followed by Additional Header Segments (AHS), a Header- 6606 Digest, a Data Segment, and/or a Data-Digest. 6608 The overall structure of an iSCSI PDU is as follows: 6610 Byte/ 0 | 1 | 2 | 3 | 6611 / | | | | 6612 |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| 6613 +---------------+---------------+---------------+--------------+ 6614 0/ Basic Header Segment (BHS) / 6615 +/ / 6616 +---------------+---------------+---------------+--------------+ 6617 48/ Additional Header Segment 1 (AHS) (optional) / 6618 +/ / 6619 +---------------+---------------+---------------+--------------+ 6620 / Additional Header Segment 2 (AHS) (optional) / 6621 +/ / 6622 +---------------+---------------+---------------+--------------+ 6623 ---- 6624 +---------------+---------------+---------------+--------------+ 6625 / Additional Header Segment n (AHS) (optional) / 6626 +/ / 6627 +---------------+---------------+---------------+--------------+ 6628 ---- 6629 +---------------+---------------+---------------+--------------+ 6630 k/ Header-Digest (optional) / 6631 +/ / 6632 +---------------+---------------+---------------+--------------+ 6633 l/ Data Segment(optional) / 6634 +/ / 6635 +---------------+---------------+---------------+--------------+ 6636 m/ Data-Digest (optional) / 6637 +/ / 6638 +---------------+---------------+---------------+--------------+ 6640 All PDU segments and digests are padded to the closest integer 6641 number of four byte words. For example, all PDU segments and 6642 digests start at a four byte word boundary and the padding ranges 6643 from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. 6645 iSCSI response PDUs do not have AH Segments. 6647 11.2.1. Basic Header Segment (BHS) 6649 The BHS is 48 bytes long. The Opcode and DataSegmentLength fields 6650 appear in all iSCSI PDUs. In addition, when used, the Initiator 6651 Task Tag and Logical Unit Number always appear in the same 6652 location in the header. 6654 The format of the BHS is: 6656 Byte/ 0 | 1 | 2 | 3 | 6657 / | | | | 6658 |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| 6659 +---------------+---------------+---------------+--------------+ 6660 0|.|I| Opcode |F| Opcode-specific fields | 6661 +---------------+---------------+---------------+--------------+ 6662 4|TotalAHSLength | DataSegmentLength | 6663 +---------------+---------------+---------------+--------------+ 6664 8| LUN or Opcode-specific fields | 6665 + + 6666 12| | 6667 +---------------+---------------+---------------+--------------+ 6668 16| Initiator Task Tag | 6669 +---------------+---------------+---------------+--------------+ 6670 20/ Opcode-specific fields / 6671 +/ / 6672 +---------------+---------------+---------------+--------------+ 6673 48 6675 11.2.1.1. I 6677 For request PDUs, the I bit set to 1 is an immediate delivery 6678 marker. 6680 11.2.1.2. Opcode 6682 The Opcode indicates the type of iSCSI PDU the header 6683 encapsulates. 6685 The Opcodes are divided into two categories: initiator opcodes and 6686 target opcodes. Initiator opcodes are in PDUs sent by the 6687 initiator (request PDUs). Target opcodes are in PDUs sent by the 6688 target (response PDUs). 6690 Initiators MUST NOT use target opcodes and targets MUST NOT use 6691 initiator opcodes. 6693 Initiator opcodes defined in this specification are: 6695 0x00 NOP-Out 6697 0x01 SCSI Command (encapsulates a SCSI Command Descriptor 6698 Block) 6700 0x02 SCSI Task Management function request 6702 0x03 Login Request 6704 0x04 Text Request 6706 0x05 SCSI Data-out (for WRITE operations) 6708 0x06 Logout Request 6710 0x10 SNACK Request 6712 0x1c-0x1e Vendor specific codes 6714 Target opcodes are: 6716 0x20 NOP-In 6718 0x21 SCSI Response - contains SCSI status and possibly sense 6719 information or other response information. 6721 0x22 SCSI Task Management function response 6723 0x23 Login Response 6725 0x24 Text Response 6727 0x25 SCSI Data-in - for READ operations. 6729 0x26 Logout Response 6730 0x31 Ready To Transfer (R2T) - sent by target when it is ready 6731 to receive data. 6733 0x32 Asynchronous Message - sent by target to indicate certain 6734 special conditions. 6736 0x3c-0x3e Vendor specific codes 6738 0x3f Reject 6740 All other opcodes are reserved. 6742 11.2.1.3. Final (F) bit 6744 When set to 1 it indicates the final (or only) PDU of a sequence. 6746 11.2.1.4. Opcode-specific Fields 6748 These fields have different meanings for different opcode types. 6750 11.2.1.5. TotalAHSLength 6752 Total length of all AHS header segments in units of four byte 6753 words including padding, if any. 6755 The TotalAHSLength is only used in PDUs that have an AHS and MUST 6756 be 0 in all other PDUs. 6758 11.2.1.6. DataSegmentLength 6760 This is the data segment payload length in bytes (excluding 6761 padding). The DataSegmentLength MUST be 0 whenever the PDU has no 6762 data segment. 6764 11.2.1.7. LUN 6766 Some opcodes operate on a specific Logical Unit. The Logical Unit 6767 Number (LUN) field identifies which Logical Unit. If the opcode 6768 does not relate to a Logical Unit, this field is either ignored or 6769 may be used in an opcode specific way. The LUN field is 64-bits 6770 and should be formatted in accordance with [SAM2]. For example, 6771 LUN[0] from [SAM2] is BHS byte 8 and so on up to LUN[7] from 6772 [SAM2], which is BHS byte 15. 6774 11.2.1.8. Initiator Task Tag 6776 The initiator assigns a Task Tag to each iSCSI task it issues. 6777 While a task exists, this tag MUST uniquely identify the task 6778 session-wide. SCSI may also use the initiator task tag as part of 6779 the SCSI task identifier when the timespan during which an iSCSI 6780 initiator task tag must be unique extends over the timespan during 6781 which a SCSI task tag must be unique. However, the iSCSI Initiator 6782 Task Tag must exist and be unique even for untagged SCSI commands. 6784 An ITT value of 0xffffffff is reserved and MUST NOT be assigned 6785 for a task by the initiator. The only instance in which it may be 6786 seen on the wire is in a target-initiated NOP-In PDU (Section 6787 11.19) and in the initiator response to that PDU, if necessary. 6789 11.2.2. Additional Header Segment (AHS) 6791 The general format of an AHS is: 6793 Byte/ 0 | 1 | 2 | 3 | 6794 / | | | | 6795 |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| 6796 +---------------+---------------+---------------+--------------+ 6797 0| AHSLength | AHSType | AHS-Specific | 6798 +---------------+---------------+---------------+--------------+ 6799 4/ AHS-Specific / 6800 +/ / 6801 +---------------+---------------+---------------+--------------+ 6802 x 6804 11.2.2.1. AHSType 6806 The AHSType field is coded as follows: 6808 bit 0-1 - Reserved 6810 bit 2-7 - AHS code 6812 0 - Reserved 6813 1 - Extended CDB 6815 2 - Expected Bidirectional Read Data Length 6817 3 - 63 Reserved 6819 11.2.2.2. AHSLength 6821 This field contains the effective length in bytes of the AHS 6822 excluding AHSType and AHSLength and padding, if any. The AHS is 6823 padded to the smallest integer number of 4 byte words (i.e., from 6824 0 up to 3 padding bytes). 6826 11.2.2.3. Extended CDB AHS 6828 The format of the Extended CDB AHS is: 6830 Byte/ 0 | 1 | 2 | 3 | 6831 / | | | | 6832 |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| 6833 +---------------+---------------+---------------+--------------+ 6834 0| AHSLength (CDBLength-15) | 0x01 | Reserved | 6835 +---------------+---------------+---------------+--------------+ 6836 4/ ExtendedCDB...+padding / 6837 +/ / 6838 +---------------+---------------+---------------+--------------+ 6839 x 6841 This type of AHS MUST NOT be used if the CDBLength is less than 6842 17. 6843 The length includes the reserved byte 3. 6845 11.2.2.4. Bidirectional Expected Read-Data Length AHS 6847 The format of the Bidirectional Read Expected Data Transfer Length 6848 AHS is: 6850 Byte/ 0 | 1 | 2 | 3 | 6851 / | | | | 6852 |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| 6853 +---------------+---------------+---------------+--------------+ 6854 0| AHSLength (0x0005) | 0x02 | Reserved | 6855 +---------------+---------------+---------------+--------------+ 6856 4| Expected Read-Data Length | 6857 +---------------+---------------+---------------+--------------+ 6858 8 6860 11.2.3. Header Digest and Data Digest 6862 Optional header and data digests protect the integrity of the 6863 header and data, respectively. The digests, if present, are 6864 located, respectively, after the header and PDU-specific data, and 6865 cover respectively the header and the PDU data, each including 6866 the padding bytes, if any. 6868 The existence and type of digests are negotiated during the Login 6869 Phase. 6871 The separation of the header and data digests is useful in iSCSI 6872 routing applications, in which only the header changes when a 6873 message is forwarded. In this case, only the header digest should 6874 be recalculated. 6876 Digests are not included in data or header length fields. 6878 A zero-length Data Segment also implies a zero-length data-digest. 6880 11.2.4. Data Segment 6882 The (optional) Data Segment contains PDU associated data. Its 6883 payload effective length is provided in the BHS field - 6884 DataSegmentLength. The Data Segment is also padded to an integer 6885 number of 4 byte words. 6887 11.3. SCSI Command 6889 The format of the SCSI Command PDU is: 6891 Byte/ 0 | 1 | 2 | 3 | 6892 / | | | | 6893 |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| 6894 +---------------+---------------+---------------+--------------+ 6895 0|.|I| 0x01 |F|R|W|. .|ATTR | Reserved | 6896 +---------------+---------------+---------------+--------------+ 6897 4|TotalAHSLength | DataSegmentLength | 6898 +---------------+---------------+---------------+--------------+ 6899 8| Logical Unit Number (LUN) | 6900 + + 6901 12| | 6902 +---------------+---------------+---------------+--------------+ 6903 16| Initiator Task Tag | 6904 +---------------+---------------+---------------+--------------+ 6905 20| Expected Data Transfer Length | 6906 +---------------+---------------+---------------+--------------+ 6907 24| CmdSN | 6908 +---------------+---------------+---------------+--------------+ 6909 28| ExpStatSN | 6910 +---------------+---------------+---------------+--------------+ 6911 32/ SCSI Command Descriptor Block (CDB) / 6912 +/ / 6913 +---------------+---------------+---------------+--------------+ 6914 48/ AHS (Optional) / 6915 +---------------+---------------+---------------+--------------+ 6916 x/ Header Digest (Optional) / 6917 +---------------+---------------+---------------+--------------+ 6918 y/ (DataSegment, Command Data) (Optional) / 6919 +/ / 6920 +---------------+---------------+---------------+--------------+ 6921 z/ Data Digest (Optional) / 6922 +---------------+---------------+---------------+--------------+ 6924 11.3.1. Flags and Task Attributes (byte 1) 6926 The flags for a SCSI Command are: 6928 bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs 6929 follow this PDU. When F=1 for a write and if Expected Data 6930 Transfer Length is larger than the DataSegmentLength, the 6931 target may solicit additional data through R2T. 6933 bit 1 (R) is set to 1 when the command is expected to input 6934 data. 6936 bit 2 (W) is set to 1 when the command is expected to output 6937 data. 6939 bit 3-4 Reserved. 6941 bit 5-7 contains Task Attributes. 6943 Task Attributes (ATTR) have one of the following integer values 6944 (see [SAM2] for details): 6946 0 - Untagged 6948 1 - Simple 6950 2 - Ordered 6952 3 - Head of Queue 6954 4 - ACA 6956 5-7 - Reserved 6958 At least one of the W and F bits MUST be set to 1. 6959 Either or both of R and W MAY be 1 when either the Expected Data 6960 Transfer Length and/or Bidirectional Read Expected Data Transfer 6961 Length are 0, but they MUST NOT both be 0 when the Expected Data 6962 Transfer Length and/or Bidirectional Read Expected Data Transfer 6963 Length are not 0 (i.e., when some data transfer is expected the 6964 transfer direction is indicated by the R and/or W bit). 6966 11.3.2. CmdSN - Command Sequence Number 6968 Enables ordered delivery across multiple connections in a single 6969 session. 6971 11.3.3. ExpStatSN 6973 Command responses up to ExpStatSN-1 (mod 2**32) have been received 6974 (acknowledges status) on the connection. 6976 11.3.4. Expected Data Transfer Length 6978 For unidirectional operations, the Expected Data Transfer Length 6979 field contains the number of bytes of data involved in this SCSI 6980 operation. For a unidirectional write operation (W flag set to 1 6981 and R flag set to 0), the initiator uses this field to specify the 6982 number of bytes of data it expects to transfer for this operation. 6983 For a unidirectional read operation (W flag set to 0 and R flag 6984 set to 1), the initiator uses this field to specify the number of 6985 bytes of data it expects the target to transfer to the initiator. 6986 It corresponds to the SAM2 byte count. 6988 For bidirectional operations (both R and W flags are set to 1), 6989 this field contains the number of data bytes involved in the write 6990 transfer. For bidirectional operations, an additional header 6991 segment MUST be present in the header sequence that indicates the 6992 Bidirectional Read Expected Data Transfer Length. The Expected 6993 Data Transfer Length field and the Bidirectional Read Expected 6994 Data Transfer Length field correspond to the SAM2 byte count. 6996 If the Expected Data Transfer Length for a write and the length of 6997 the immediate data part that follows the command (if any) are the 6998 same, then no more data PDUs are expected to follow. In this 6999 case, the F bit MUST be set to 1. 7001 If the Expected Data Transfer Length is higher than the 7002 FirstBurstLength (the negotiated maximum amount of unsolicited 7003 data the target will accept), the initiator MUST send the maximum 7004 amount of unsolicited data OR ONLY the immediate data, if any. 7006 Upon completion of a data transfer, the target informs the 7007 initiator (through residual counts) of how many bytes were 7008 actually processed (sent and/or received) by the target. 7010 11.3.5. CDB - SCSI Command Descriptor Block 7012 There are 16 bytes in the CDB field to accommodate the commonly 7013 used CDBs. Whenever the CDB is larger than 16 bytes, an Extended 7014 CDB AHS MUST be used to contain the CDB spillover. 7016 11.3.6. Data Segment - Command Data 7018 Some SCSI commands require additional parameter data to accompany 7019 the SCSI command. This data may be placed beyond the boundary of 7020 the iSCSI header in a data segment. Alternatively, user data 7021 (e.g., from a WRITE operation) can be placed in the data segment 7022 (both cases are referred to as immediate data). These data are 7023 governed by the rules for solicited vs. unsolicited data outlined 7024 in Section 4.2.5.2 - "Data Transfer Overview". 7026 11.4. SCSI Response 7028 The format of the SCSI Response PDU is: 7030 Byte/ 0 | 1 | 2 | 3 | 7031 / | | | | 7032 |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| 7033 +---------------+---------------+---------------+--------------+ 7034 0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status | 7035 +---------------+---------------+---------------+--------------+ 7036 4|TotalAHSLength | DataSegmentLength | 7037 +---------------+---------------+---------------+--------------+ 7038 8| Reserved | 7039 + + 7040 12| | 7041 +---------------+---------------+---------------+--------------+ 7042 16| Initiator Task Tag | 7043 +---------------+---------------+---------------+--------------+ 7044 20| SNACK Tag or Reserved | 7045 +---------------+---------------+---------------+--------------+ 7046 24| StatSN | 7047 +---------------+---------------+---------------+--------------+ 7048 28| ExpCmdSN | 7049 +---------------+---------------+---------------+--------------+ 7050 32| MaxCmdSN | 7051 +---------------+---------------+---------------+--------------+ 7052 36| ExpDataSN or Reserved | 7053 +---------------+---------------+---------------+--------------+ 7054 40| Bidirectional Read Residual Count or Reserved | 7055 +---------------+---------------+---------------+--------------+ 7056 44| Residual Count or Reserved | 7057 +---------------+---------------+---------------+--------------+ 7058 48| Header-Digest (Optional) | 7059 +---------------+---------------+---------------+--------------+ 7060 / Data Segment (Optional) / 7061 +/ / 7062 +---------------+---------------+---------------+--------------+ 7063 | Data-Digest (Optional) | 7064 +---------------+---------------+---------------+--------------+ 7066 11.4.1. Flags (byte 1) 7068 bit 1-2 Reserved. 7070 bit 3 - (o) set for Bidirectional Read Residual Overflow. In 7071 this case, the Bidirectional Read Residual Count indicates 7072 the number of bytes that were not transferred to the 7073 initiator because the initiator's Expected Bidirectional 7074 Read Data Transfer Length was not sufficient. 7076 bit 4 - (u) set for Bidirectional Read Residual Underflow. In 7077 this case, the Bidirectional Read Residual Count indicates 7078 the number of bytes that were not transferred to the 7079 initiator out of the number of bytes expected to be 7080 transferred. 7082 bit 5 - (O) set for Residual Overflow. In this case, the 7083 Residual Count indicates the number of bytes that were not 7084 transferred because the initiator's Expected Data Transfer 7085 Length was not sufficient. For a bidirectional operation, 7086 the Residual Count contains the residual for the write 7087 operation. 7089 bit 6 - (U) set for Residual Underflow. In this case, the 7090 Residual Count indicates the number of bytes that were not 7091 transferred out of the number of bytes that were expected to 7092 be transferred. For a bidirectional operation, the Residual 7093 Count contains the residual for the write operation. 7095 bit 7 - (0) Reserved. 7097 Bits O and U and bits o and u are mutually exclusive (i.e., having 7098 both o and u or O and U set to 1 is a protocol error). 7099 For a response other than "Command Completed at Target", bits 3-6 7100 MUST be 0. 7102 11.4.2. Status 7104 The Status field is used to report the SCSI status of the command 7105 (as specified in [SAM2]) and is only valid if the Response Code is 7106 Command Completed at target. 7108 Some of the status codes defined in [SAM2] are: 7110 0x00 GOOD 7111 0x02 CHECK CONDITION 7113 0x08 BUSY 7115 0x18 RESERVATION CONFLICT 7117 0x28 TASK SET FULL 7119 0x30 ACA ACTIVE 7121 0x40 TASK ABORTED 7123 See [SAM2] for the complete list and definitions. 7125 If a SCSI device error is detected while data from the initiator 7126 is still expected (the command PDU did not contain all the data 7127 and the target has not received a Data PDU with the final bit 7128 Set), the target MUST wait until it receives a Data PDU with the F 7129 bit set in the last expected sequence before sending the Response 7130 PDU. 7132 11.4.3. Response 7134 This field contains the iSCSI service response. 7136 iSCSI service response codes defined in this specification are: 7138 0x00 - Command Completed at Target 7140 0x01 - Target Failure 7142 0x80-0xff - Vendor specific 7144 All other response codes are reserved. 7146 The Response is used to report a Service Response. The mapping of 7147 the response code into a SCSI service response code value, if 7148 needed, is outside the scope of this document. However, in 7149 symbolic terms response value 0x00 maps to the SCSI service 7150 response (see [SAM2] and [SPC3]) of TASK COMPLETE or LINKED 7151 COMMAND COMPLETE. All other Response values map to the SCSI 7152 service response of SERVICE DELIVERY OR TARGET FAILURE. 7154 If a SCSI Response PDU does not arrive before the session is 7155 terminated, the SCSI service response is SERVICE DELIVERY OR 7156 TARGET FAILURE. 7158 A non-zero response field indicates a failure to execute the 7159 command in which case the Status and Flag fields are undefined and 7160 MUST be ignored on reception. 7162 11.4.4. SNACK Tag 7164 This field contains a copy of the SNACK Tag of the last SNACK Tag 7165 accepted by the target on the same connection and for the command 7166 for which the response is issued. Otherwise it is reserved and 7167 should be set to 0. 7169 After issuing a R-Data SNACK the initiator must discard any SCSI 7170 status unless contained in an SCSI Response PDU carrying the same 7171 SNACK Tag as the last issued R-Data SNACK for the SCSI command on 7172 the current connection. 7174 For a detailed discussion on R-Data SNACK see SNACK. 7176 11.4.5. Residual Count 7178 11.4.5.1. Field Semantics 7180 The Residual Count field MUST be valid in the case where either 7181 the U bit or the O bit is set. If neither bit is set, the Residual 7182 Count field MUST be ignored on reception and SHOULD be set to 0 7183 when sending. Targets may set the residual count and initiators 7184 may use it when the response code is "completed at target" (even 7185 if the status returned is not GOOD). If the O bit is set, the 7186 Residual Count indicates the number of bytes that were not 7187 transferred because the initiator's Expected Data Transfer Length 7188 was not sufficient. If the U bit is set, the Residual Count 7189 indicates the number of bytes that were not transferred out of the 7190 number of bytes expected to be transferred. 7192 11.4.5.2. Residuals Concepts Overview 7194 SCSI-Presented Data Transfer Length (SPDTL) is the term this 7195 document uses (see Section 2.1 for definition) to represent the 7196 aggregate data length that the target SCSI layer attempts to 7197 transfer using the local iSCSI layer for a task. Expected Data 7198 Transfer Length (EDTL) is the iSCSI term that represents the 7199 length of data that the iSCSI layer expects to transfer for a 7200 task. EDTL is specified in the SCSI Command PDU. 7202 When SPDTL = EDTL for a task, the target iSCSI layer completes the 7203 task with no residuals. Whenever SPDTL differs from EDTL for a 7204 task, that task is said to have a residual. 7206 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the 7207 SCSI Response PDU as specified in Section 11.4.5.1. The Residual 7208 Count MUST be set to the numerical value of (SPDTL - EDTL). 7210 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 7211 the SCSI Response PDU as specified in Section 11.4.5.1. The 7212 Residual Count MUST be set to the numerical value of (EDTL - 7213 SPDTL). 7215 Note that the Overflow and Underflow scenarios are independent of 7216 Data-In and Data-Out. Either scenario is logically possible in 7217 either direction of data transfer. 7219 11.4.5.3. SCSI REPORT LUNS and Residual Overflow 7221 This Section discusses the residual overflow issues citing the 7222 example of the SCSI REPORT LUNS command. Note however that there 7223 are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH 7224 fields following the same underlying rules. The semantics in the 7225 rest of the Section apply to all such SCSI commands. 7227 The specification of the SCSI REPORT LUNS command requires that 7228 the SCSI target limit the amount of data transferred to a maximum 7229 size (ALLOCATION LENGTH) provided by the initiator in the REPORT 7230 LUNS CDB. 7232 If the Expected Data Transfer Length (EDTL) in the iSCSI header of 7233 the SCSI Command PDU for a REPORT LUNS command is set to at least 7234 as large as that ALLOCATION LENGTH, the SCSI layer truncation 7235 prevents an iSCSI Residual Overflow from occurring. A SCSI 7236 initiator can detect that such truncation has occurred via other 7237 information at theS CSI layer. The rest of the Section elaborates 7238 this required behavior. 7240 The SCSI REPORT LUNS command requests a target SCSI layer to 7241 return a logical unit inventory (LUN list) to the initiator SCSI 7242 layer (see Section 6.21 of [SPC3]). The size of this LUN list may 7243 not be known to the initiator SCSI layer when it issues the REPORT 7244 LUNS command; to avoid transferring more LUN list data than the 7245 initiator is prepared for, the REPORT LUNS CDB contains an 7246 ALLOCATION LENGTH field to specify the maximum amount of data to 7247 be transferred to the initiator for this command. If the initiator 7248 SCSI layer has underestimated the number of logical units at the 7249 target, it is possible that the complete logical unit inventory 7250 does not fit in the specified ALLOCATION LENGTH. In this 7251 situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI 7252 layer "shall terminate transfers to the Data-In Buffer" when the 7253 number of bytes specified by the ALLOCATION LENGTH field have been 7254 transferred. 7256 Therefore, in response to a REPORT LUNS command, the SCSI layer at 7257 the target presents at most ALLOCATION LENGTH bytes of data 7258 (logical unit inventory) to iSCSI for transfer to the initiator. 7259 For a REPORT LUNS command, if the iSCSI EDTL is at least as large 7260 as the ALLOCATION LENGTH, the SCSI truncation ensures that the 7261 EDTL will accommodate all of the data to be transferred. If all of 7262 the logical unit inventory data presented to the iSCSI layer -- 7263 i.e., the data remaining after any SCSI truncation -- is 7264 transferred to the initiator by the iSCSI layer, an iSCSI Residual 7265 Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in 7266 the SCSI Response or final SCSI Data-Out PDU. Note that this 7267 behavior is implied by the combination of Section 11.4.5.1 along 7268 with the specification of the REPORT LUNS command in [SPC3]. 7269 However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in 7270 this scenario, note that the iSCSI Underflow MUST be signaled in 7271 the SCSI Response PDU. An iSCSI Underflow MUST also be signaled 7272 when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the 7273 logical unit inventory data presented to the iSCSI layer is 7274 smaller than the ALLOCATION LENGTH. 7276 The LUN LIST LENGTH field in the logical unit inventory (the first 7277 field in the inventory) is not affected by truncation of the 7278 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 7279 initiator to determine that the received inventory is incomplete 7280 by noticing that the LUN LIST LENGTH in the inventory is larger 7281 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A 7282 common initiator behavior in this situation is to re-issue the 7283 REPORT LUNS command with a larger ALLOCATION LENGTH. 7285 11.4.6. Bidirectional Read Residual Count 7287 The Bidirectional Read Residual Count field MUST be valid in the 7288 case where either the u bit or the o bit is set. If neither bit is 7289 set, the Bidirectional Read Residual Count field is reserved. 7290 Targets may set the Bidirectional Read Residual Count and 7291 initiators may use it when the response code is "completed at 7292 target". If the o bit is set, the Bidirectional Read Residual 7293 Count indicates the number of bytes that were not transferred to 7294 the initiator because the initiator's Expected Bidirectional Read 7295 Transfer Length was not sufficient. If the u bit is set, the 7296 Bidirectional Read Residual Count indicates the number of bytes 7297 that were not transferred to the initiator out of the number of 7298 bytes expected to be transferred. 7300 11.4.7. Data Segment - Sense and Response Data Segment 7302 iSCSI targets MUST support and enable autosense. If Status is 7303 CHECK CONDITION (0x02), then the Data Segment MUST contain sense 7304 data for the failed command. 7306 For some iSCSI responses, the response data segment MAY contain 7307 some response related information, (e.g., for a target failure, it 7308 may contain a vendor specific detailed description of the 7309 failure). 7311 If the DataSegmentLength is not 0, the format of the Data Segment 7312 is as follows: 7314 Byte/ 0 | 1 | 2 | 3 | 7315 / | | | | 7316 |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| 7317 +---------------+---------------+---------------+--------------+ 7318 0|SenseLength | Sense Data | 7319 +---------------+---------------+---------------+--------------+ 7320 x/ Sense Data / 7321 +---------------+---------------+---------------+--------------+ 7322 y/ Response Data / 7323 / / 7324 +---------------+---------------+---------------+--------------+ 7325 z| 7326 11.4.7.1. SenseLength 7328 Length of Sense Data. 7330 11.4.7.2. Sense Data 7332 The Sense Data contains detailed information about a check 7333 condition and [SPC3] specifies the format and content of the Sense 7334 Data. 7336 Certain iSCSI conditions result in the command being terminated at 7337 the target (response Command Completed at Target) with a SCSI 7338 Check Condition Status as outlined in the next table: 7340 +--------------------------+----------+--------------------------+ 7341 | iSCSI Condition |Sense | Additional Sense Code & | 7342 | |Key | Qualifier | 7343 +--------------------------+----------+--------------------------+ 7344 | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c | 7345 | data |Command-0B| Write Error | 7346 +--------------------------+----------+--------------------------+ 7347 | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d | 7348 | |Command-0B| Write Error | 7349 +--------------------------+----------+--------------------------+ 7350 | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 | 7351 | error |Command-0B| CRC Error Detected | 7352 +--------------------------+----------+--------------------------+ 7353 | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 | 7354 | |Command-0B| Read Error | 7355 +--------------------------+----------+--------------------------+ 7357 The target reports the "Incorrect amount of data" condition if 7358 during data output the total data length to output is greater than 7359 FirstBurstLength and the initiator sent unsolicited non-immediate 7360 data but the total amount of unsolicited data is different than 7361 FirstBurstLength. The target reports the same error when the 7362 amount of data sent as a reply to an R2T does not match the amount 7363 requested. 7365 11.4.8. ExpDataSN 7367 The number of Data-In (read) PDUs the target has sent for the 7368 command. 7370 This field MUST be 0 if the response code is not Command Completed 7371 at Target or the target sent no Data-In PDUs for the command. 7372 11.4.9. StatSN - Status Sequence Number 7374 StatSN is a Sequence Number that the target iSCSI layer generates 7375 per connection and that in turn, enables the initiator to 7376 acknowledge status reception. StatSN is incremented by 1 for every 7377 response/status sent on a connection except for responses sent as 7378 a result of a retry or SNACK. In the case of responses sent due to 7379 a retransmission request, the StatSN MUST be the same as the first 7380 time the PDU was sent unless the connection has since been 7381 restarted. 7383 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator 7385 ExpCmdSN is a Sequence Number that the target iSCSI returns to the 7386 initiator to acknowledge command reception. It is used to update a 7387 local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1 7388 indicates that the target cannot accept new commands. 7390 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 7392 MaxCmdSN is a Sequence Number that the target iSCSI returns to the 7393 initiator to indicate the maximum CmdSN the initiator can send. It 7394 is used to update a local variable with the same name. If MaxCmdSN 7395 is equal to ExpCmdSN-1, this indicates to the initiator that the 7396 target cannot receive any additional commands. When MaxCmdSN 7397 changes at the target while the target has no pending PDUs to 7398 convey this information to the initiator, it MUST generate a NOP- 7399 IN to carry the new MaxCmdSN. 7401 11.5. Task Management Function Request 7403 Byte/ 0 | 1 | 2 | 3 | 7404 / | | | | 7405 |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| 7406 +---------------+---------------+---------------+--------------+ 7407 0|.|I| 0x02 |1| Function | Reserved | 7408 +---------------+---------------+---------------+--------------+ 7409 4|TotalAHSLength | DataSegmentLength | 7410 +---------------+---------------+---------------+--------------+ 7411 8| Logical Unit Number (LUN) or Reserved | 7412 + + 7413 12| | 7414 +---------------+---------------+---------------+--------------+ 7415 16| Initiator Task Tag | 7416 +---------------+---------------+---------------+--------------+ 7417 20| Referenced Task Tag or 0xffffffff | 7418 +---------------+---------------+---------------+--------------+ 7419 24| CmdSN | 7420 +---------------+---------------+---------------+--------------+ 7421 28| ExpStatSN | 7422 +---------------+---------------+---------------+--------------+ 7423 32| RefCmdSN or Reserved | 7424 +---------------+---------------+---------------+--------------+ 7425 36| ExpDataSN or Reserved | 7426 +---------------+---------------+---------------+--------------+ 7427 40/ Reserved / 7428 +/ / 7429 +---------------+---------------+---------------+--------------+ 7430 48| Header-Digest (Optional) | 7431 +---------------+---------------+---------------+--------------+ 7433 11.5.1. Function 7435 The Task Management functions provide an initiator with a way to 7436 explicitly control the execution of one or more Tasks (SCSI and 7437 iSCSI tasks). The Task Management function codes are listed below. 7438 For a more detailed description of SCSI task management, see 7439 [SAM2]. 7441 1 - ABORT TASK - aborts the task identified by the 7442 Referenced Task Tag field. 7444 2 - ABORT TASK SET - aborts all Tasks issued via this 7445 session on the logical unit. 7447 3 - CLEAR ACA - clears the Auto Contingent Allegiance 7448 condition. 7450 4 - CLEAR TASK SET - aborts all Tasks in the appropriate 7451 task set as defined by the TST field in the Control mode 7452 page (see [SPC3]). 7454 5 - LOGICAL UNIT RESET 7456 6 - TARGET WARM RESET 7458 7 - TARGET COLD RESET 7460 8 - TASK REASSIGN - reassigns connection allegiance for the 7461 task identified by the Initiator Task Tag field to this 7462 connection, thus resuming the iSCSI exchanges for the task. 7464 All other possible values for Function field are reserved. 7466 For all these functions, the Task Management function response 7467 MUST be returned as detailed in Section 11.6. All these functions 7468 apply to the referenced tasks regardless of whether they are 7469 proper SCSI tasks or tagged iSCSI operations. Task management 7470 requests must act on all the commands from the same session having 7471 a CmdSN lower than the task management CmdSN. LOGICAL UNIT RESET, 7472 TARGET WARM RESET and TARGET COLD RESET may affect commands from 7473 other sessions or commands from the same session regardless of 7474 their CmdSN value. 7476 If the task management request is marked for immediate delivery, 7477 it must be considered immediately for execution, but the 7478 operations involved (all or part of them) may be postponed to 7479 allow the target to receive all relevant tasks. According to 7480 [SAM2], for all the tasks covered by the Task Management response 7481 (i.e., with CmdSN lower than the task management command CmdSN) 7482 but except the Task Management response to a TASK REASSIGN, 7483 additional responses MUST NOT be delivered to the SCSI layer after 7484 the Task Management response. The iSCSI initiator MAY deliver to 7485 the SCSI layer all responses received before the Task Management 7486 response (i.e., it is a matter of implementation if the SCSI 7487 responses, received before the Task Management response but after 7488 the task management request was issued, are delivered to the SCSI 7489 layer by the iSCSI layer in the initiator). The iSCSI target MUST 7490 ensure that no responses for the tasks covered by a task 7491 management function are delivered to the iSCSI initiator after the 7492 Task Management response except for a task covered by a TASK 7493 REASSIGN. 7495 For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST 7496 continue to respond to all valid target transfer tags (received 7497 via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to 7498 the affected task set, even after issuing the task management 7499 request. The issuing initiator SHOULD however terminate (i.e., by 7500 setting the F-bit to 1) these response sequences as quickly as 7501 possible. The target on its part MUST wait for responses on all 7502 affected target transfer tags before acting on either of these two 7503 task management requests. In case all or part of the response 7504 sequence is not received (due to digest errors) for a valid TTT, 7505 the target MAY treat it as a case of within-command error recovery 7506 class (see Section 7.1.4.1 - "Recovery Within-command") if it is 7507 supporting ErrorRecoveryLevel >= 1, or alternatively may drop the 7508 connection to complete the requested task set function. 7510 If an ABORT TASK is issued for a task created by an immediate 7511 command then RefCmdSN MUST be that of the Task Management request 7512 itself (i.e. CmdSN and RefCmdSN are equal); otherwise RefCmdSN 7513 MUST be set to the CmdSN of the task to be aborted (lower than 7514 CmdSN). 7516 If the connection is still active (it is not undergoing an 7517 implicit or explicit logout), ABORT TASK MUST be issued on the 7518 same connection to which the task to be aborted is allegiant at 7519 the time the Task Management Request is issued. If the connection 7520 is implicitly or explicitly logged out (i.e., no other request 7521 will be issued on the failing connection and no other response 7522 will be received on the failing connection), then an ABORT TASK 7523 function request may be issued on another connection. This Task 7524 Management request will then establish a new allegiance for the 7525 command to be aborted as well as abort it (i.e., the task to be 7526 aborted will not have to be retried or reassigned, and its status, 7527 if sent but not acknowledged, will be resent followed by the Task 7528 Management response). 7530 At the target an ABORT TASK function MUST NOT be executed on a 7531 Task Management request; such a request MUST result in Task 7532 Management response of "Function rejected". 7534 For the LOGICAL UNIT RESET function, the target MUST behave as 7535 dictated by the Logical Unit Reset function in [SAM2]. 7537 The implementation of the TARGET WARM RESET function and the 7538 TARGET COLD RESET function is OPTIONAL and when implemented, 7539 should act as described below. The TARGET WARM RESET is also 7540 subject to SCSI access controls on the requesting initiator as 7541 defined in [SPC3]. When authorization fails at the target, the 7542 appropriate response as described in Section 11.6.1 MUST be 7543 returned by the target. The TARGET COLD RESET function is not 7544 subject to SCSI access controls, but its execution privileges may 7545 be managed by iSCSI mechanisms such as login authentication. 7547 When executing the TARGET WARM RESET and TARGET COLD RESET 7548 functions, the target cancels all pending operations on all 7549 Logical Units known by the issuing initiator. Both functions are 7550 equivalent to the Target Reset function specified by [SAM2]. They 7551 can affect many other initiators logged in with the servicing SCSI 7552 target port. 7554 The target MUST treat the TARGET COLD RESET function additionally 7555 as a power on event, thus terminating all of its TCP connections 7556 to all initiators (all sessions are terminated). For this reason, 7557 the Service Response (defined by [SAM2]) for this SCSI task 7558 management function may not be reliably delivered to the issuing 7559 initiator port. 7561 For the TASK REASSIGN function, the target should reassign the 7562 connection allegiance to this new connection (and thus resume 7563 iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received 7564 by the target after the connection on which the command was 7565 previously executing has been successfully logged-out. The Task 7566 Management response MUST be issued before the reassignment becomes 7567 effective. 7569 For additional usage semantics see Section 7.2- "Retry and 7570 Reassign in Recovery". 7572 At the target a TASK REASSIGN function request MUST NOT be 7573 executed to reassign the connection allegiance of a Task 7574 Management function request, an active text negotiation task, or a 7575 Logout task; such a request MUST result in Task Management 7576 response of "Function rejected". 7578 TASK REASSIGN MUST be issued as an immediate command. 7580 11.5.2. TotalAHSLength and DataSegmentLength 7582 For this PDU, TotalAHSLength and DataSegmentLength MUST be 0. 7584 11.5.3. LUN 7586 This field is required for functions that address a specific LU 7587 (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL 7588 UNIT RESET) and is reserved in all others. 7590 11.5.4. Referenced Task Tag 7592 The Initiator Task Tag of the task to be aborted for the ABORT 7593 TASK function or reassigned for the TASK REASSIGN function. For 7594 all the other functions this field MUST be set to the reserved 7595 value 0xffffffff. 7597 11.5.5. RefCmdSN 7599 If an ABORT TASK is issued for a task created by an immediate 7600 command then RefCmdSN MUST be that of the Task Management request 7601 itself (i.e. CmdSN and RefCmdSN are equal). 7603 For an ABORT TASK of a task created by non-immediate command 7604 RefCmdSN MUST be set to the CmdSN of the task identified by the 7605 Referenced Task Tag field. Targets must use this field as 7606 described in Section 11.6.1 when the task identified by the 7607 Referenced Task Tag field is not with the target. 7609 Otherwise, this field is reserved. 7611 11.5.6. ExpDataSN 7613 For recovery purposes, the iSCSI target and initiator maintain a 7614 data acknowledgement reference number - the first input DataSN 7615 number unacknowledged by the initiator. When issuing a new 7616 command, this number is set to 0. If the function is TASK 7617 REASSIGN, which establishes a new connection allegiance for a 7618 previously issued Read or Bidirectional command, ExpDataSN will 7619 contain an updated data acknowledgement reference number or the 7620 value 0; the latter indicating that the data acknowledgement 7621 reference number is unchanged. The initiator MUST discard any data 7622 PDUs from the previous execution that it did not acknowledge and 7623 the target MUST transmit all Data-in PDUs (if any) starting with 7624 the data acknowledgement reference number. The number of 7625 retransmitted PDUs may or may not be the same as the original 7626 transmission depending on if there was a change in 7627 MaxRecvDataSegmentLength in the reassignment. The target MAY also 7628 send no more Data-In PDUs if all data has been acknowledged. 7630 The value of ExpDataSN MUST be 0 or higher than the DataSN of the 7631 last acknowledged Data-In PDU, but not larger than DataSN+1 of the 7632 last Data-IN PDU sent by the target. Any other value MUST be 7633 ignored by the target. 7635 For other functions this field is reserved. 7637 11.6. Task Management Function Response 7638 Byte/ 0 | 1 | 2 | 3 | 7639 / | | | | 7640 |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| 7641 +---------------+---------------+---------------+--------------+ 7642 0|.|.| 0x22 |1| Reserved | Response | Reserved | 7643 +---------------+---------------+---------------+--------------+ 7644 4|TotalAHSLength | DataSegmentLength | 7645 +--------------------------------------------------------------+ 7646 8/ Reserved / 7647 / / 7648 +---------------+---------------+---------------+--------------+ 7649 16| Initiator Task Tag | 7650 +---------------+---------------+---------------+--------------+ 7651 20| Reserved | 7652 +---------------+---------------+---------------+--------------+ 7653 24| StatSN | 7654 +---------------+---------------+---------------+--------------+ 7655 28| ExpCmdSN | 7656 +---------------+---------------+---------------+--------------+ 7657 32| MaxCmdSN | 7658 +---------------+---------------+---------------+--------------+ 7659 36/ Reserved / 7660 +/ / 7661 +---------------+---------------+---------------+--------------+ 7662 48| Header-Digest (Optional) | 7663 +---------------+---------------+---------------+--------------+ 7665 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR 7666 TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET 7667 and TASK REASSIGN, the target performs the requested Task 7668 Management function and sends a Task Management response back to 7669 the initiator. For TASK REASSIGN, the new connection allegiance 7670 MUST ONLY become effective at the target after the target issues 7671 the Task Management Response. 7673 11.6.1. Response 7675 The target provides a Response, which may take on the following 7676 values: 7678 0 - Function complete. 7679 1 - Task does not exist. 7681 2 - LUN does not exist. 7682 3 - Task still allegiant. 7683 4 - Task allegiance reassignment not supported. 7684 5 - Task management function not supported. 7685 6 - Function authorization failed. 7686 255 - Function rejected. 7688 All other values are reserved. 7690 For a discussion on usage of response codes 3 and 4, see Section 7691 7.2.2- "Allegiance Reassignment". 7693 For the TARGET COLD RESET and TARGET WARM RESET functions, the 7694 target cancels all pending operations across all Logical Units 7695 known to the issuing initiator. For the TARGET COLD RESET 7696 function, the target MUST then close all of its TCP connections to 7697 all initiators (terminates all sessions). 7699 The mapping of the response code into a SCSI service response code 7700 value, if needed, is outside the scope of this document. However, 7701 in symbolic terms, Response values 0 and 1 map to the SCSI service 7702 response of FUNCTION COMPLETE. Response value 2 maps to SCSI 7703 service response of INCORRECT LOGICAL UNIT NUMBER. All other 7704 Response values map to the SCSI service response of FUNCTION 7705 REJECTED. If a Task Management function response PDU does not 7706 arrive before the session is terminated, the SCSI service response 7707 is SERVICE DELIVERY OR TARGET FAILURE. 7709 The response to ABORT TASK SET and CLEAR TASK SET MUST only be 7710 issued by the target after all of the commands affected have been 7711 received by the target, the corresponding task management 7712 functions have been executed by the SCSI target, and the delivery 7713 of all responses delivered until the task management function 7714 completion have been confirmed (acknowledged through ExpStatSN) by 7715 the initiator on all connections of this session. For the exact 7716 timeline of events, refer to Section 4.2.3.3 and Section 4.2.3.4. 7718 For the ABORT TASK function, 7719 If the Referenced Task Tag identifies a valid task leading to 7720 a successful termination, then targets must return the 7721 "Function complete" response. 7722 If the Referenced Task Tag does not identify an existing task, 7723 but if the CmdSN indicated by the RefCmdSN field in the 7724 Task Management function request is within the valid CmdSN 7725 window and less than the CmdSN of the Task Management 7726 function request itself, then targets must consider the 7727 CmdSN received and return the "Function complete" response. 7728 If the Referenced Task Tag does not identify an existing task 7729 and if the CmdSN indicated by the RefCmdSN field in the 7730 Task Management function request is outside the valid CmdSN 7731 window, then targets must return the "Task does not exist" 7732 response. 7734 For response semantics on function types that can potentially 7735 impact multiple active tasks on the target, see Section 4.2.3. 7737 11.6.2. TotalAHSLength and DataSegmentLength 7739 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7741 11.7. SCSI Data-out & SCSI Data-in 7743 The SCSI Data-out PDU for WRITE operations has the following 7744 format: 7746 Byte/ 0 | 1 | 2 | 3 | 7747 / | | | | 7748 |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| 7749 +---------------+---------------+---------------+--------------+ 7750 0|.|.| 0x05 |F| Reserved | 7751 +---------------+---------------+---------------+--------------+ 7752 4|TotalAHSLength | DataSegmentLength | 7753 +---------------+---------------+---------------+--------------+ 7754 8| LUN or Reserved | 7755 + + 7756 12| | 7757 +---------------+---------------+---------------+--------------+ 7758 16| Initiator Task Tag | 7759 +---------------+---------------+---------------+--------------+ 7760 20| Target Transfer Tag or 0xffffffff | 7761 +---------------+---------------+---------------+--------------+ 7762 24| Reserved | 7763 +---------------+---------------+---------------+--------------+ 7764 28| ExpStatSN | 7765 +---------------+---------------+---------------+--------------+ 7766 32| Reserved | 7767 +---------------+---------------+---------------+--------------+ 7768 36| DataSN | 7769 +---------------+---------------+---------------+--------------+ 7770 40| Buffer Offset | 7771 +---------------+---------------+---------------+--------------+ 7772 44| Reserved | 7773 +---------------+---------------+---------------+--------------+ 7774 48| Header-Digest (Optional) | 7775 +---------------+---------------+---------------+--------------+ 7776 / DataSegment / 7777 +/ / 7778 +---------------+---------------+---------------+--------------+ 7779 | Data-Digest (Optional) | 7780 +---------------+---------------+---------------+--------------+ 7782 The SCSI Data-in PDU for READ operations has the following format: 7784 Byte/ 0 | 1 | 2 | 3 | 7785 / | | | | 7786 |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| 7787 +---------------+---------------+---------------+--------------+ 7788 0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd| 7789 +---------------+---------------+---------------+--------------+ 7790 4|TotalAHSLength | DataSegmentLength | 7791 +---------------+---------------+---------------+--------------+ 7792 8| LUN or Reserved | 7793 + + 7794 12| | 7795 +---------------+---------------+---------------+--------------+ 7796 16| Initiator Task Tag | 7797 +---------------+---------------+---------------+--------------+ 7798 20| Target Transfer Tag or 0xffffffff | 7799 +---------------+---------------+---------------+--------------+ 7800 24| StatSN or Reserved | 7801 +---------------+---------------+---------------+--------------+ 7802 28| ExpCmdSN | 7803 +---------------+---------------+---------------+--------------+ 7804 32| MaxCmdSN | 7805 +---------------+---------------+---------------+--------------+ 7806 36| DataSN | 7807 +---------------+---------------+---------------+--------------+ 7808 40| Buffer Offset | 7809 +---------------+---------------+---------------+--------------+ 7810 44| Residual Count | 7811 +---------------+---------------+---------------+--------------+ 7812 48| Header-Digest (Optional) | 7813 +---------------+---------------+---------------+--------------+ 7814 / DataSegment / 7815 +/ / 7816 +---------------+---------------+---------------+--------------+ 7817 | Data-Digest (Optional) | 7818 +---------------+---------------+---------------+--------------+ 7820 Status can accompany the last Data-in PDU if the command did not 7821 end with an exception (i.e., the status is "good status" - GOOD, 7822 CONDITION MET or INTERMEDIATE CONDITION MET). The presence of 7823 status (and of a residual count) is signaled though the S flag 7824 bit. Although targets MAY choose to send even non-exception 7825 status in separate responses, initiators MUST support non- 7826 exception status in Data-In PDUs. 7828 11.7.1. F (Final) Bit 7830 For outgoing data, this bit is 1 for the last PDU of unsolicited 7831 data or the last PDU of a sequence that answers an R2T. 7833 For incoming data, this bit is 1 for the last input (read) data 7834 PDU of a sequence. Input can be split into several sequences, 7835 each having its own F bit. Splitting the data stream into 7836 sequences does not affect DataSN counting on Data-In PDUs. It MAY 7837 be used as a "change direction" indication for Bidirectional 7838 operations that need such a change. 7840 DataSegmentLength MUST NOT exceed MaxRecvDataSegmentLength for the 7841 direction it is sent and the total of all the DataSegmentLength of 7842 all PDUs in a sequence MUST NOT exceed MaxBurstLength (or 7843 FirstBurstLength for unsolicited data). However the number of 7844 individual PDUs in a sequence (or in total) may be higher than the 7845 MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength 7846 ratio (as PDUs may be limited in length by the sender 7847 capabilities). Using DataSegmentLength of 0 may increase beyond 7848 what is reasonable for the number of PDUs and should therefore be 7849 avoided. 7851 For Bidirectional operations, the F bit is 1 for both the end of 7852 the input sequences and the end of the output sequences. 7854 11.7.2. A (Acknowledge) bit 7856 For sessions with ErrorRecoveryLevel 1 or higher, the target sets 7857 this bit to 1 to indicate that it requests a positive 7858 acknowledgement from the initiator for the data received. The 7859 target should use the A bit moderately; it MAY only set the A bit 7860 to 1 once every MaxBurstLength bytes, or on the last Data-In PDU 7861 that concludes the entire requested read data transfer for the 7862 task from the target's perspective, and it MUST NOT do so more 7863 frequently. The target MUST NOT set to 1 the A bit for sessions 7864 with ErrorRecoveryLevel=0. The initiator MUST ignore the A bit set 7865 to 1 for sessions with ErrorRecoveryLevel=0. 7867 On receiving a Data-In PDU with the A bit set to 1 on a session 7868 with ErrorRecoveryLevel greater than 0, if there are no holes in 7869 the read data until that Data-In PDU, the initiator MUST issue a 7870 SNACK of type DataACK except when it is able to acknowledge the 7871 status for the task immediately via ExpStatSN on other outbound 7872 PDUs if the status for the task is also received. In the latter 7873 case (acknowledgement through ExpStatSN), sending a SNACK of type 7874 DataACK in response to the A bit is OPTIONAL, but if it is done, 7875 it must not be sent after the status acknowledgement through 7876 ExpStatSN. If the initiator has detected holes in the read data 7877 prior to that Data-In PDU, it MUST postpone issuing the SNACK of 7878 type DataACK until the holes are filled. An initiator also MUST 7879 NOT acknowledge the status for the task before those holes are 7880 filled. A status acknowledgement for a task that generated the 7881 Data-In PDUs is considered by the target as an implicit 7882 acknowledgement of the Data-In PDUs if such an acknowledgement was 7883 requested by the target. 7885 11.7.3. Flags (byte 1) 7887 The last SCSI Data packet sent from a target to an initiator for a 7888 SCSI command that completed successfully (with a status of GOOD, 7889 CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may 7890 also optionally contain the Status for the data transfer. In this 7891 case, Sense Data cannot be sent together with the Command Status. 7892 If the command is completed with an error, then the response and 7893 sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be 7894 sent in a SCSI Data packet). For Bidirectional commands, the 7895 status MUST be sent in a SCSI Response PDU. 7897 bit 2-4 - Reserved. 7899 bit 5-6 - used the same as in a SCSI Response. These bits are 7900 only valid when S is set to 1. For details see SNACK . 7902 bit 7 S (status)- set to indicate that the Command Status 7903 field contains status. If this bit is set to 1, the F bit 7904 MUST also be set to 1. 7906 The fields StatSN, Status, and Residual Count only have meaningful 7907 content if the S bit is set to 1 and their values are defined in 7908 SNACK . 7910 11.7.4. Target Transfer Tag and LUN 7912 On outgoing data, the Target Transfer Tag is provided to the 7913 target if the transfer is honoring an R2T. In this case, the 7914 Target Transfer Tag field is a replica of the Target Transfer Tag 7915 provided with the R2T. 7917 On incoming data, the Target Transfer Tag and LUN MUST be provided 7918 by the target if the A bit is set to 1; otherwise they are 7919 reserved. The Target Transfer Tag and LUN are copied by the 7920 initiator into the SNACK of type DataACK that it issues as a 7921 result of receiving a SCSI Data-in PDU with the A bit set to 1. 7923 The Target Transfer Tag values are not specified by this protocol 7924 except that the value 0xffffffff is reserved and means that the 7925 Target Transfer Tag is not supplied. If the Target Transfer Tag 7926 is provided, then the LUN field MUST hold a valid value and be 7927 consistent with whatever was specified with the command; 7928 otherwise, the LUN field is reserved. 7930 11.7.5. DataSN 7932 For input (read) or bidirectional Data-In PDUs, the DataSN is the 7933 input PDU number within the data transfer for the command 7934 identified by the Initiator Task Tag. 7936 R2T and Data-In PDUs, in the context of bidirectional commands, 7937 share the numbering sequence (see Section 4.2.2.4- "Data 7938 Sequencing"). 7940 For output (write) data PDUs, the DataSN is the Data-Out PDU 7941 number within the current output sequence. The current output 7942 sequence is either identified by the Initiator Task Tag (for 7943 unsolicited data) or is a data sequence generated for one R2T (for 7944 data solicited through R2T). 7946 11.7.6. Buffer Offset 7948 The Buffer Offset field contains the offset of this PDU payload 7949 data within the complete data transfer. The sum of the buffer 7951 offset and length should not exceed the expected transfer length 7952 for the command. 7954 The order of data PDUs within a sequence is determined by 7955 DataPDUInOrder. When set to Yes, it means that PDUs have to be in 7956 increasing Buffer Offset order and overlays are forbidden. 7958 The ordering between sequences is determined by 7959 DataSequenceInOrder. When set to Yes, it means that sequences have 7960 to be in increasing Buffer Offset order and overlays are 7961 forbidden. 7963 11.7.7. DataSegmentLength 7965 This is the data payload length of a SCSI Data-In or SCSI Data-Out 7966 PDU. The sending of 0 length data segments should be avoided, but 7967 initiators and targets MUST be able to properly receive 0 length 7968 data segments. 7970 The Data Segments of Data-in and Data-out PDUs SHOULD be filled to 7971 the integer number of 4 byte words (real payload) unless the F bit 7972 is set to 1. 7974 11.8. Ready To Transfer (R2T) 7976 Byte/ 0 | 1 | 2 | 3 | 7977 / | | | | 7978 |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| 7979 +---------------+---------------+---------------+--------------+ 7980 0|.|.| 0x31 |1| Reserved | 7981 +---------------+---------------+---------------+--------------+ 7982 4|TotalAHSLength | DataSegmentLength | 7983 +---------------+---------------+---------------+--------------+ 7984 8| LUN | 7985 + + 7986 12| | 7987 +---------------+---------------+---------------+--------------+ 7988 16| Initiator Task Tag | 7989 +---------------+---------------+---------------+--------------+ 7990 20| Target Transfer Tag | 7991 +---------------+---------------+---------------+--------------+ 7992 24| StatSN | 7993 +---------------+---------------+---------------+--------------+ 7994 28| ExpCmdSN | 7995 +---------------+---------------+---------------+--------------+ 7996 32| MaxCmdSN | 7997 +---------------+---------------+---------------+--------------+ 7998 36| R2TSN | 7999 +---------------+---------------+---------------+--------------+ 8000 40| Buffer Offset | 8001 +---------------+---------------+---------------+--------------+ 8002 44| Desired Data Transfer Length | 8003 +--------------------------------------------------------------+ 8004 48| Header-Digest (Optional) | 8005 +---------------+---------------+---------------+--------------+ 8007 When an initiator has submitted a SCSI Command with data that 8008 passes from the initiator to the target (WRITE), the target may 8009 specify which blocks of data it is ready to receive. The target 8010 may request that the data blocks be delivered in whichever order 8011 is convenient for the target at that particular instant. This 8012 information is passed from the target to the initiator in the 8013 Ready To Transfer (R2T) PDU. 8015 In order to allow write operations without an explicit initial 8016 R2T, the initiator and target MUST have negotiated the key 8017 InitialR2T to No during Login. 8019 An R2T MAY be answered with one or more SCSI Data-out PDUs with a 8020 matching Target Transfer Tag. If an R2T is answered with a single 8021 Data-out PDU, the Buffer Offset in the Data PDU MUST be the same 8022 as the one specified by the R2T, and the data length of the Data 8023 PDU MUST be the same as the Desired Data Transfer Length specified 8024 in the R2T. If the R2T is answered with a sequence of Data PDUs, 8025 the Buffer Offset and Length MUST be within the range of those 8026 specified by R2T, and the last PDU MUST have the F bit set to 1. 8027 If the last PDU (marked with the F bit) is received before the 8028 Desired Data Transfer Length is transferred, a target MAY choose 8029 to Reject that PDU with "Protocol error" reason code. 8030 DataPDUInOrder governs the Data-Out PDU ordering. If 8031 DataPDUInOrder is set to Yes, the Buffer Offsets and Lengths for 8032 consecutive PDUs MUST form a continuous non-overlapping range and 8033 the PDUs MUST be sent in increasing offset order. 8035 The target may send several R2T PDUs. It, therefore, can have a 8036 number of pending data transfers. The number of outstanding R2T 8037 PDUs are limited by the value of the negotiated key 8038 MaxOutstandingR2T. Within a task, outstanding R2Ts MUST be 8039 fulfilled by the initiator in the order in which they were 8040 received. 8042 R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T 8043 (Recovery-R2T) is generated by a target upon detecting the loss of 8044 one or more Data-Out PDUs due to: 8046 - Digest error 8048 - Sequence error 8050 - Sequence reception timeout 8052 A Recovery-R2T carries the next unused R2TSN, but requests part of 8053 or the entire data burst that an earlier R2T (with a lower R2TSN) 8054 had already requested. 8056 DataSequenceInOrder governs the buffer offset ordering in 8057 consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive 8058 R2Ts MUST refer to continuous non-overlapping ranges except for 8059 Recovery-R2Ts. 8061 11.8.1. TotalAHSLength and DataSegmentLength 8063 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 8065 11.8.2. R2TSN 8067 R2TSN is the R2T PDU input PDU number within the command 8068 identified by the Initiator Task Tag. 8070 For bidirectional commands R2T and Data-In PDUs share the input 8071 PDU numbering sequence (see Section 4.2.2.4- "Data Sequencing"). 8073 11.8.3. StatSN 8075 The StatSN field will contain the next StatSN. The StatSN for this 8076 connection is not advanced after this PDU is sent. 8078 11.8.4. Desired Data Transfer Length and Buffer Offset 8080 The target specifies how many bytes it wants the initiator to send 8081 because of this R2T PDU. The target may request the data from the 8082 initiator in several chunks, not necessarily in the original order 8083 of the data. The target, therefore, also specifies a Buffer Offset 8084 that indicates the point at which the data transfer should begin, 8085 relative to the beginning of the total data transfer. The Desired 8086 Data Transfer Length MUST NOT be 0 and MUST NOT exceed 8087 MaxBurstLength. 8089 11.8.5. Target Transfer Tag 8091 The target assigns its own tag to each R2T request that it sends 8092 to the initiator. This tag can be used by the target to easily 8093 identify the data it receives. The Target Transfer Tag and LUN are 8094 copied in the outgoing data PDUs and are only used by the target. 8095 There is no protocol rule about the Target Transfer Tag except 8096 that the value 0xffffffff is reserved and MUST NOT be sent by a 8097 target in an R2T. 8099 11.9. Asynchronous Message 8101 An Asynchronous Message may be sent from the target to the 8102 initiator without correspondence to a particular command. The 8103 target specifies the reason for the event and sense data. 8105 Byte/ 0 | 1 | 2 | 3 | 8106 / | | | | 8107 |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| 8108 +---------------+---------------+---------------+--------------+ 8109 0|.|.| 0x32 |1| Reserved | 8110 +---------------+---------------+---------------+--------------+ 8111 4|TotalAHSLength | DataSegmentLength | 8112 +---------------+---------------+---------------+--------------+ 8113 8| LUN or Reserved | 8114 + + 8115 12| | 8116 +---------------+---------------+---------------+--------------+ 8117 16| 0xffffffff | 8118 +---------------+---------------+---------------+--------------+ 8119 20| Reserved | 8120 +---------------+---------------+---------------+--------------+ 8121 24| StatSN | 8122 +---------------+---------------+---------------+--------------+ 8123 28| ExpCmdSN | 8124 +---------------+---------------+---------------+--------------+ 8125 32| MaxCmdSN | 8126 +---------------+---------------+---------------+--------------+ 8127 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | 8128 +---------------+---------------+---------------+--------------+ 8129 40| Parameter2 or Reserved | Parameter3 or Reserved | 8130 +---------------+---------------+---------------+--------------+ 8131 44| Reserved | 8132 +---------------+---------------+---------------+--------------+ 8133 48| Header-Digest (Optional) | 8134 +---------------+---------------+---------------+--------------+ 8135 / DataSegment - Sense Data and iSCSI Event Data / 8136 +/ / 8137 +---------------+---------------+---------------+--------------+ 8138 | Data-Digest (Optional) | 8139 +---------------+---------------+---------------+--------------+ 8141 Some Asynchronous Messages are strictly related to iSCSI while 8142 others are related to SCSI [SAM2]. 8144 StatSN counts this PDU as an acknowledgeable event (StatSN is 8145 advanced), which allows for initiator and target state 8146 synchronization. 8148 11.9.1. AsyncEvent 8150 The codes used for iSCSI Asynchronous Messages (events) are: 8152 0 (SCSI_ASYNC) - a SCSI Asynchronous Event is reported in the 8153 sense data. Sense Data that accompanies the report, in the 8154 data segment, identifies the condition. The sending of a 8155 SCSI Event (Asynchronous Event Reporting in SCSI 8156 terminology) is dependent on the target support for SCSI 8157 asynchronous event reporting (see [SAM2]) as indicated in 8158 the standard INQUIRY data (see [SPC3]). Its use may be 8159 enabled by parameters in the SCSI Control mode page (see 8160 [SPC3]). 8162 1 (REQUEST_LOGOUT) - target requests Logout. This Async 8163 Message MUST be sent on the same connection as the one 8164 requesting to be logged out. The initiator MUST honor this 8165 request by issuing a Logout as early as possible, but no 8166 later than Parameter3 seconds. Initiator MUST send a 8167 Logout with a reason code of "Close the connection" OR 8168 "Close the session" to close all the connections. Once this 8169 message is received, the initiator SHOULD NOT issue new 8170 iSCSI commands on the connection to be logged out. The 8171 target MAY reject any new I/O requests that it receives 8172 after this Message with the reason code "Waiting for 8173 Logout". If the initiator does not Logout in Parameter3 8174 seconds, the target should send an Async PDU with iSCSI 8175 event code "Dropped the connection" if possible, or simply 8176 terminate the transport connection. Parameter1 and 8177 Parameter2 are reserved. 8179 2 (CONNECTION_DROP) - target indicates it will drop the 8180 connection. 8181 The Parameter1 field indicates the CID of the connection 8182 going to be dropped. 8184 The Parameter2 field (Time2Wait) indicates, in seconds, the 8185 minimum time to wait before attempting to reconnect or 8186 reassign. 8188 The Parameter3 field (Time2Retain) indicates the maximum 8189 time allowed to reassign commands after the initial wait (in 8190 Parameter2). 8192 If the initiator does not attempt to reconnect and/or 8193 reassign the outstanding commands within the time specified 8194 by Parameter3, or if Parameter3 is 0, the target will 8195 terminate all outstanding commands on this connection. In 8196 this case, no other responses should be expected from the 8197 target for the outstanding commands on this connection. 8199 A value of 0 for Parameter2 indicates that reconnect can be 8200 attempted immediately. 8202 3 (SESSION_DROP) - target indicates it will drop all the 8203 connections of this session. 8205 Parameter1 field is reserved. 8207 The Parameter2 field (Time2Wait) indicates, in seconds, the 8208 minimum time to wait before attempting to reconnect. 8209 The Parameter3 field (Time2Retain) indicates the maximum 8210 time allowed to reassign commands after the initial wait (in 8211 Parameter2). 8213 If the initiator does not attempt to reconnect and/or 8214 reassign the outstanding commands within the time specified 8215 by Parameter3, or if Parameter3 is 0, the session is 8216 terminated. In this case, the target will terminate all 8217 outstanding commands in this session; no other responses 8218 should be expected from the target for the outstanding 8219 commands in this session. A value of 0 for Parameter2 8220 indicates that reconnect can be attempted immediately. 8222 4 (RENEGOTIATE) - target requests parameter negotiation on 8223 this connection. The initiator MUST honor this request by 8224 issuing a Text Request (that can be empty) on the same 8225 connection as early as possible, but no later than 8226 Parameter3 seconds, unless a Text Request is already pending 8227 on the connection, or by issuing a Logout Request. If the 8228 initiator does not issue a Text Request the target may 8229 reissue the Asynchronous Message requesting parameter 8230 negotiation. 8232 5 (FAST_ABORT) - all active tasks for LU with a matching LUN 8233 field in the Async Message PDU are being terminated. The 8234 receiving initiator iSCSI layer MUST respond to this Message 8235 by taking the following steps in order. 8237 - Stop Data-Out transfers on that connection for all active 8238 TTTs for the affected LUN quoted in the Async Message 8239 PDU. 8240 - Acknowledge the StatSN of the Async Message PDU via a NOP- 8241 Out PDU with ITT=0xffffffff (i.e., non-ping flavor), 8242 while copying the LUN field from the Async Message to 8243 NOP-Out. 8245 This value of AsyncEvent however MUST NOT be used on an 8246 iSCSI session unless the new TaskReporting text key defined 8247 in Section 13.23 was negotiated to FastAbort on the session. 8249 255 - vendor-specific iSCSI Event. The AsyncVCode details the 8250 vendor code, and data MAY accompany the report. 8252 All other event codes are reserved. 8254 11.9.2. AsyncVCode 8256 AsyncVCode is a vendor specific detail code that is only valid if 8257 the AsyncEvent field indicates a vendor specific event. Otherwise, 8258 it is reserved. 8260 11.9.3. LUN 8262 The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this 8263 field is reserved. 8264 11.9.4. Sense Data and iSCSI Event Data 8266 For a SCSI event, this data accompanies the report in the data 8267 segment and identifies the condition. 8269 For an iSCSI event, additional vendor-unique data MAY accompany 8270 the Async event. Initiators MAY ignore the data when not 8271 understood while processing the rest of the PDU. 8273 If the DataSegmentLength is not 0, the format of the DataSegment 8274 is as follows: 8275 Byte/ 0 | 1 | 2 | 3 | 8276 / | | | | 8277 |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| 8278 +---------------+---------------+---------------+--------------+ 8279 0|SenseLength | Sense Data | 8280 +---------------+---------------+---------------+--------------+ 8281 x/ Sense Data / 8282 +---------------+---------------+---------------+--------------+ 8283 y/ iSCSI Event Data / 8284 / / 8285 +---------------+---------------+---------------+--------------+ 8286 z| 8288 11.9.4.1. SenseLength 8290 This is the length of Sense Data. When the Sense Data field is 8291 empty (e.g., the event is not a SCSI event) SenseLength is 0. 8293 11.10. Text Request 8295 The Text Request is provided to allow for the exchange of 8296 information and for future extensions. It permits the initiator to 8297 inform a target of its capabilities or to request some special 8298 operations. 8300 Byte/ 0 | 1 | 2 | 3 | 8301 / | | | | 8302 |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| 8303 +---------------+---------------+---------------+--------------+ 8304 0|.|I| 0x04 |F|C| Reserved | 8305 +---------------+---------------+---------------+--------------+ 8306 4|TotalAHSLength | DataSegmentLength | 8307 +---------------+---------------+---------------+--------------+ 8308 8| LUN or Reserved | 8309 + + 8310 12| | 8311 +---------------+---------------+---------------+--------------+ 8312 16| Initiator Task Tag | 8313 +---------------+---------------+---------------+--------------+ 8314 20| Target Transfer Tag or 0xffffffff | 8315 +---------------+---------------+---------------+--------------+ 8316 24| CmdSN | 8317 +---------------+---------------+---------------+--------------+ 8318 28| ExpStatSN | 8319 +---------------+---------------+---------------+--------------+ 8320 32/ Reserved / 8321 +/ / 8322 +---------------+---------------+---------------+--------------+ 8323 48| Header-Digest (Optional) | 8324 +---------------+---------------+---------------+--------------+ 8325 / DataSegment (Text) / 8326 +/ / 8327 +---------------+---------------+---------------+--------------+ 8328 | Data-Digest (Optional) | 8329 +---------------+---------------+---------------+--------------+ 8331 An initiator MUST NOT have more than one outstanding Text Request 8332 on a connection at any given time. 8334 On a connection failure, an initiator must either explicitly abort 8335 any active allegiant text negotiation task or must cause such a 8336 task to be implicitly terminated by the target. 8338 11.10.1. F (Final) Bit 8340 When set to 1, indicates that this is the last or only text 8341 request in a sequence of Text Requests; otherwise, it indicates 8342 that more Text Requests will follow. 8344 11.10.2. C (Continue) Bit 8346 When set to 1, indicates that the text (set of key=value pairs) 8347 in this Text Request is not complete (it will be continued on 8348 subsequent Text Requests); otherwise, it indicates that this Text 8349 Request ends a set of key=value pairs. A Text Request with the C 8350 bit set to 1 MUST have the F bit set to 0. 8352 11.10.3. Initiator Task Tag 8354 The initiator assigned identifier for this Text Request. If the 8355 command is sent as part of a sequence of text requests and 8356 responses, the Initiator Task Tag MUST be the same for all the 8357 requests within the sequence (similar to linked SCSI commands). 8358 The I bit for all requests in a sequence also MUST be the same. 8360 11.10.4. Target Transfer Tag 8362 When the Target Transfer Tag is set to the reserved value 8363 0xffffffff, it tells the target that this is a new request and the 8364 target resets any internal state associated with the Initiator 8365 Task Tag (resets the current negotiation state). 8367 The target sets the Target Transfer Tag in a text response to a 8368 value other than the reserved value 0xffffffff whenever it 8369 indicates that it has more data to send or more operations to 8370 perform that are associated with the specified Initiator Task Tag. 8371 It MUST do so whenever it sets the F bit to 0 in the response. By 8372 copying the Target Transfer Tag from the response to the next Text 8373 Request, the initiator tells the target to continue the operation 8374 for the specific Initiator Task Tag. The initiator MUST ignore the 8375 Target Transfer Tag in the Text Response when the F bit is set to 8376 1. 8378 This mechanism allows the initiator and target to transfer a large 8379 amount of textual data over a sequence of text-command/text- 8380 response exchanges, or to perform extended negotiation sequences. 8382 If the Target Transfer Tag is not 0xffffffff, the LUN field MUST 8383 be sent by the target in the Text Response. 8385 A target MAY reset its internal negotiation state if an exchange 8386 is stalled by the initiator for a long time or if it is running 8387 out of resources. 8389 Long text responses are handled as in the following example: 8391 I->T Text SendTargets=All (F=1,TTT=0xffffffff) 8393 T->I Text (F=0,TTT=0x12345678) 8395 I->T Text (F=1, TTT=0x12345678) 8397 T->I Text (F=0, TTT=0x12345678) 8399 I->T Text (F=1, TTT=0x12345678) 8401 ... 8403 T->I Text (F=1, TTT=0xffffffff) 8405 11.10.5. Text 8407 The data lengths of a text request MUST NOT exceed the iSCSI 8408 target MaxRecvDataSegmentLength (a per connection and per 8409 direction negotiated parameter). The text format is specified in 8410 Section 6.2- "Text Mode Negotiation". 8412 Chapter 11 and Chapter 12 list some basic Text key=value pairs, 8413 some of which can be used in Login Request/Response and some in 8414 Text Request/Response. 8416 A key=value pair can span Text request or response boundaries. A 8417 key=value pair can start in one PDU and continue on the next. In 8418 other words the end of a PDU does not necessarily signal the end 8419 of a key=value pair. 8421 The target responds by sending its response back to the initiator. 8422 The response text format is similar to the request text format. 8423 The text response MAY refer to key=value pairs presented in an 8424 earlier text request and the text in the request may refer to 8425 earlier responses. 8427 Chapter 5 details the rules for the Text Requests and Responses. 8429 Text operations are usually meant for parameter 8430 setting/negotiations, but can also be used to perform some long 8431 lasting operations. 8433 Text operations that take a long time should be placed in their 8434 own Text request. 8436 11.11. Text Response 8438 The Text Response PDU contains the target's responses to the 8439 initiator's Text request. The format of the Text field matches 8440 that of the Text request. 8442 Byte/ 0 | 1 | 2 | 3 | 8443 / | | | | 8444 |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| 8445 +---------------+---------------+---------------+--------------+ 8446 0|.|.| 0x24 |F|C| Reserved | 8447 +---------------+---------------+---------------+--------------+ 8448 4|TotalAHSLength | DataSegmentLength | 8449 +---------------+---------------+---------------+--------------+ 8450 8| LUN or Reserved | 8451 + + 8452 12| | 8453 +---------------+---------------+---------------+--------------+ 8454 16| Initiator Task Tag | 8455 +---------------+---------------+---------------+--------------+ 8456 20| Target Transfer Tag or 0xffffffff | 8457 +---------------+---------------+---------------+--------------+ 8458 24| StatSN | 8459 +---------------+---------------+---------------+--------------+ 8460 28| ExpCmdSN | 8461 +---------------+---------------+---------------+--------------+ 8462 32| MaxCmdSN | 8463 +---------------+---------------+---------------+--------------+ 8464 36/ Reserved / 8465 +/ / 8466 +---------------+---------------+---------------+--------------+ 8467 48| Header-Digest (Optional) | 8468 +---------------+---------------+---------------+--------------+ 8469 / DataSegment (Text) / 8470 +/ / 8471 +---------------+---------------+---------------+--------------+ 8472 | Data-Digest (Optional) | 8473 +---------------+---------------+---------------+--------------+ 8475 11.11.1. F (Final) Bit 8477 When set to 1, in response to a Text Request with the Final bit 8478 set to 1, the F bit indicates that the target has finished the 8479 whole operation. Otherwise, if set to 0 in response to a Text 8480 Request with the Final Bit set to 1, it indicates that the target 8481 has more work to do (invites a follow-on text request). A Text 8482 Response with the F bit set to 1 in response to a Text Request 8483 with the F bit set to 0 is a protocol error. 8485 A Text Response with the F bit set to 1 MUST NOT contain key=value 8486 pairs that may require additional answers from the initiator. 8488 A Text Response with the F bit set to 1 MUST have a Target 8489 Transfer Tag field set to the reserved value of 0xffffffff. 8491 A Text Response with the F bit set to 0 MUST have a Target 8492 Transfer Tag field set to a value other than the reserved 8493 0xffffffff. 8495 11.11.2. C (Continue) Bit 8497 When set to 1, indicates that the text (set of key=value pairs) in 8498 this Text Response is not complete (it will be continued on 8499 subsequent Text Responses); otherwise, it indicates that this Text 8500 Response ends a set of key=value pairs. A Text Response with the C 8501 bit set to 1 MUST have the F bit set to 0. 8503 11.11.3. Initiator Task Tag 8505 The Initiator Task Tag matches the tag used in the initial Text 8506 Request. 8508 11.11.4. Target Transfer Tag 8510 When a target has more work to do (e.g., cannot transfer all the 8511 remaining text data in a single Text Response or has to continue 8512 the negotiation) and has enough resources to proceed, it MUST set 8513 the Target Transfer Tag to a value other than the reserved value 8514 of 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to 8515 0xffffffff. 8517 When the Target Transfer Tag is not 0xffffffff, the LUN field may 8518 be significant. 8520 The initiator MUST copy the Target Transfer Tag and LUN in its 8521 next request to indicate that it wants the rest of the data. 8523 When the target receives a Text Request with the Target Transfer 8524 Tag set to the reserved value of 0xffffffff, it resets its 8525 internal information (resets state) associated with the given 8526 Initiator Task Tag (restarts the negotiation). 8528 When a target cannot finish the operation in a single Text 8529 Response, and does not have enough resources to continue, it 8530 rejects the Text Request with the appropriate Reject code. 8532 A target may reset its internal state associated with an Initiator 8533 Task Tag (the current negotiation state), state expressed through 8534 the Target Transfer Tag if the initiator fails to continue the 8535 exchange for some time. The target may reject subsequent Text 8536 Requests with the Target Transfer Tag set to the "stale" value. 8538 11.11.5. StatSN 8540 The target StatSN variable is advanced by each Text Response sent. 8542 11.11.6. Text Response Data 8544 The data lengths of a text response MUST NOT exceed the iSCSI 8545 initiator MaxRecvDataSegmentLength (a per connection and per 8546 direction negotiated parameter). 8548 The text in the Text Response Data is governed by the same rules 8549 as the text in the Text Request Data (see Section 11.11.2). 8551 Although the initiator is the requesting party and controls the 8552 request-response initiation and termination, the target can offer 8553 key=value pairs of its own as part of a sequence and not only in 8554 response to the initiator. 8556 11.12. Login Request 8558 After establishing a TCP connection between an initiator and a 8559 target, the initiator MUST start a Login Phase to gain further 8560 access to the target's resources. 8562 The Login Phase (see Section 6.3) consists of a sequence of Login 8563 requests and responses that carry the same Initiator Task Tag. 8565 Login requests are always considered as immediate. 8567 Byte/ 0 | 1 | 2 | 3 | 8568 / | | | | 8569 |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| 8570 +---------------+---------------+---------------+--------------+ 8571 0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min | 8572 +---------------+---------------+---------------+--------------+ 8573 4|TotalAHSLength | DataSegmentLength | 8574 +---------------+---------------+---------------+--------------+ 8575 8| ISID | 8576 + +---------------+--------------+ 8577 12| | TSIH | 8578 +---------------+---------------+---------------+--------------+ 8579 16| Initiator Task Tag | 8580 +---------------+---------------+---------------+--------------+ 8581 20| CID | Reserved | 8582 +---------------+---------------+---------------+--------------+ 8583 24| CmdSN | 8584 +---------------+---------------+---------------+--------------+ 8585 28| ExpStatSN or Reserved | 8586 +---------------+---------------+---------------+--------------+ 8587 32| Reserved | 8588 +---------------+---------------+---------------+--------------+ 8589 36| Reserved | 8590 +---------------+---------------+---------------+--------------+ 8591 40/ Reserved / 8592 +/ / 8593 +---------------+---------------+---------------+--------------+ 8594 48/ DataSegment - Login Parameters in Text request Format / 8595 +/ / 8596 +---------------+---------------+---------------+--------------+ 8598 11.12.1. T (Transit) Bit 8600 If set to 1, indicates that the initiator is ready to transit to 8601 the next stage. 8603 If the T bit is set to 1 and NSG is FullFeaturePhase, then this 8604 also indicates that the initiator is ready for the Final Login 8605 Response (see Section 6.3). 8607 11.12.2. C (Continue) Bit 8609 When set to 1, this bit indicates that the text (set of key=value 8610 pairs) in this Login Request is not complete (it will be continued 8611 on subsequent Login Requests); otherwise, it indicates that this 8612 Login Request ends a set of key=value pairs. A Login Request with 8613 the C bit set to 1 MUST have the T bit set to 0. 8615 11.12.3. CSG and NSG 8617 Through these fields, Current Stage (CSG) and Next Stage (NSG), 8618 the Login negotiation requests and responses are associated with a 8619 specific stage in the session (SecurityNegotiation, 8620 LoginOperationalNegotiation, FullFeaturePhase) and may indicate 8621 the next stage to which they want to move (see Chapter 5). The 8622 next stage value is only valid when the T bit is 1; otherwise, it 8623 is reserved. 8625 The stage codes are: 8627 - 0 - SecurityNegotiation 8629 - 1 - LoginOperationalNegotiation 8631 - 3 - FullFeaturePhase 8633 All other codes are reserved. 8635 11.12.4. Version 8637 The version number of the current draft is 0x00. As such, all 8638 devices MUST carry version 0x00 for both Version-min and Version- 8639 max. 8641 11.12.4.1. Version-max 8643 Maximum Version number supported. 8645 All Login requests within the Login Phase MUST carry the same 8646 Version-max. 8648 The target MUST use the value presented with the first login 8649 request. 8651 11.12.4.2. Version-min 8653 All Login requests within the Login Phase MUST carry the same 8654 Version-min. The target MUST use the value presented with the 8655 first login request. 8657 11.12.5. ISID 8659 This is an initiator-defined component of the session identifier 8660 and is structured as follows (see Section 10.1.1 for details): 8662 Byte/ 0 | 1 | 2 | 3 | 8663 / | | | | 8664 |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| 8665 +---------------+---------------+---------------+--------------+ 8666 8| T | A | B | C | 8667 +---------------+---------------+---------------+--------------+ 8668 12| D | 8669 +---------------+---------------+ 8671 The T field identifies the format and usage of A, B, C, and D as 8672 indicated below: 8674 T 8676 00b OUI-Format 8678 A&B are a 22 bit OUI 8680 (the I/G & U/L bits are omitted) 8682 C&D 24 bit qualifier 8684 01b EN - Format (IANA Enterprise Number) 8686 A - Reserved 8688 B&C EN (IANA Enterprise Number) 8690 D - Qualifier 8692 10b "Random" 8694 A - Reserved 8696 B&C Random 8698 D - Qualifier 8700 11b A,B,C&D Reserved 8702 For the T field values 00b and 01b, a combination of A and B (for 8703 00b) or B and C (for 01b) identifies the vendor or organization 8704 whose component (software or hardware) generates this ISID. A 8705 vendor or organization with one or more OUIs, or one or more 8706 Enterprise Numbers, MUST use at least one of these numbers and 8707 select the appropriate value for the T field when its components 8708 generate ISIDs. An OUI or EN MUST be set in the corresponding 8709 fields in network byte order (byte big-endian). 8711 If the T field is 10b, B and C are set to a random 24-bit unsigned 8712 integer value in network byte order (byte big-endian). See 8713 [RFC3721] for how this affects the principle of "conservative 8714 reuse". 8716 The Qualifier field is a 16 or 24-bit unsigned integer value that 8717 provides a range of possible values for the ISID within the 8718 selected namespace. It may be set to any value within the 8719 constraints specified in the iSCSI protocol (see Section 4.4.3 - 8720 "Consequences of the Model" and Section 10.1.1- "Conservative 8721 Reuse of ISIDs"). 8723 The T field value of 11b is reserved. 8725 If the ISID is derived from something assigned to a hardware 8726 adapter or interface by a vendor, as a preset default value, it 8727 MUST be configurable to a value assigned according to the SCSI 8728 port behavior desired by the system in which it is installed (see 8729 Section 10.1.1- "Conservative Reuse of ISIDs" and Section 10.1.2 - 8730 "iSCSI Name, ISID, and TPGT Use"). The resultant ISID MUST also be 8731 persistent over power cycles, reboot, card swap, etc. 8733 11.12.6. TSIH 8735 TSIH must be set in the first Login Request. The reserved value 0 8736 MUST be used on the first connection for a new session. Otherwise, 8737 the TSIH sent by the target at the conclusion of the successful 8738 login of the first connection for this session MUST be used. The 8739 TSIH identifies to the target the associated existing session for 8740 this new connection. 8742 All Login requests within a Login Phase MUST carry the same TSIH. 8744 The target MUST check the value presented with the first login 8745 request and act as specified in Section 5.3.1 - "Login Phase 8746 Start". 8748 11.12.7. Connection ID - CID 8750 A unique ID for this connection within the session. 8752 All Login requests within the Login Phase MUST carry the same CID. 8754 The target MUST use the value presented with the first login 8755 request. 8757 A Login request with a non-zero TSIH and a CID equal to that of an 8758 existing connection implies a logout of the connection followed by 8759 a Login (see Section 6.3.4). For the details of the implicit 8760 Logout Request, see Section 11.14. 8762 11.12.8. CmdSN 8764 CmdSN is either the initial command sequence number of a session 8765 (for the first Login request of a session - the "leading" login), 8766 or the command sequence number in the command stream if the login 8767 is for a new connection in an existing session. 8769 Examples: 8771 - Login on a leading connection - if the leading login carries 8772 the CmdSN 123, all other login requests in the same login 8773 phase carry the CmdSN 123 and the first non-immediate 8774 command in FullFeaturePhase also carries the CmdSN 123. 8776 - Login on other than a leading connection - if the current 8777 CmdSN at the time the first login on the connection is 8778 issued is 500, then that PDU carries CmdSN=500. Subsequent 8779 login requests that are needed to complete this login phase 8780 may carry a CmdSN higher than 500 if non-immediate requests 8781 that were issued on other connections in the same session 8782 advance CmdSN. 8784 If the login request is a leading login request, the target MUST 8785 use the value presented in CmdSN as the target value for ExpCmdSN. 8787 11.12.9. ExpStatSN 8789 For the first Login Request on a connection this is ExpStatSN for 8790 the old connection and this field is only valid if the Login 8791 request restarts a connection (see Section 6.3.4- "Connection 8792 Reinstatement"). 8794 For subsequent Login Requests it is used to acknowledge the Login 8795 Responses with their increasing StatSN values. 8797 11.12.10. Login Parameters 8799 The initiator MUST provide some basic parameters in order to 8800 enable the target to determine if the initiator may use the 8801 target's resources and the initial text parameters for the 8802 security exchange. 8804 All the rules specified in Section 11.10.5 for text requests also 8805 hold for login requests. Keys and their explanations are listed 8806 in Chapter 12 (security negotiation keys) and Section 13 8807 (operational parameter negotiation keys). All keys in Section 13, 8808 except for the X extension formats, MUST be supported by iSCSI 8809 initiators and targets. Keys in Section 12 only need to be 8811 supported when the function to which they refer is mandatory to 8812 implement. 8814 11.13. Login Response 8816 The Login Response indicates the progress and/or end of the Login 8817 Phase. 8819 Byte/ 0 | 1 | 2 | 3 | 8820 / | | | | 8821 |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| 8822 +---------------+---------------+---------------+--------------+ 8823 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max |Version-active| 8824 +---------------+---------------+---------------+--------------+ 8825 4|TotalAHSLength | DataSegmentLength | 8826 +---------------+---------------+---------------+--------------+ 8827 8| ISID | 8828 + +---------------+--------------+ 8829 12| | TSIH | 8830 +---------------+---------------+---------------+--------------+ 8831 16| Initiator Task Tag | 8832 +---------------+---------------+---------------+--------------+ 8833 20| Reserved | 8834 +---------------+---------------+---------------+--------------+ 8835 24| StatSN | 8836 +---------------+---------------+---------------+--------------+ 8837 28| ExpCmdSN | 8838 +---------------+---------------+---------------+--------------+ 8839 32| MaxCmdSN | 8840 +---------------+---------------+---------------+--------------+ 8841 36| Status-Class | Status-Detail | Reserved | 8842 +---------------+---------------+---------------+--------------+ 8843 40/ Reserved / 8844 +/ / 8845 +---------------+---------------+---------------+--------------+ 8846 48/ DataSegment - Login Parameters in Text request Format / 8847 +/ / 8848 +---------------+---------------+---------------+--------------+ 8850 11.13.1. Version-max 8852 This is the highest version number supported by the target. 8854 All Login responses within the Login Phase MUST carry the same 8855 Version-max. 8857 The initiator MUST use the value presented as a response to the 8858 first login request. 8860 11.13.2. Version-active 8862 Indicates the highest version supported by the target and 8863 initiator. If the target does not support a version within the 8864 range specified by the initiator, the target rejects the login and 8865 this field indicates the lowest version supported by the target. 8867 All Login responses within the Login Phase MUST carry the same 8868 Version-active. 8870 The initiator MUST use the value presented as a response to the 8871 first login request. 8873 11.13.3. TSIH 8875 The TSIH is the target assigned session identifying handle. Its 8876 internal format and content are not defined by this protocol 8877 except for the value 0 that is reserved. With the exception of the 8878 Login Final-Response in a new session, this field should be set to 8879 the TSIH provided by the initiator in the Login Request. For a 8880 new session, the target MUST generate a non-zero TSIH and ONLY 8881 return it in the Login Final-Response (see Section 6.3 - "Login 8882 Phase"). 8884 11.13.4. StatSN 8886 For the first Login Response (the response to the first Login 8887 Request), this is the starting status Sequence Number for the 8888 connection. The next response of any kind, including the next 8889 login response, if any, in the same Login Phase, will carry this 8890 number + 1. This field is only valid if the Status-Class is 0. 8892 11.13.5. Status-Class and Status-Detail 8894 The Status returned in a Login Response indicates the execution 8895 status of the Login Phase. The status includes: 8897 Status-Class 8899 Status-Detail 8901 0 Status-Class indicates success. 8903 A non-zero Status-Class indicates an exception. In this case, 8904 Status-Class is sufficient for a simple initiator to use when 8905 handling exceptions, without having to look at the Status-Detail. 8906 The Status-Detail allows finer-grained exception handling for more 8907 sophisticated initiators and for better information for logging. 8909 The status classes are as follows: 8911 0 - Success - indicates that the iSCSI target successfully 8912 received, understood, and accepted the request. The 8913 numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid 8914 if Status-Class is 0. 8916 1 - Redirection - indicates that the initiator must take 8917 further action to complete the request. This is usually due 8918 to the target moving to a different address. All of the 8919 redirection status class responses MUST return one or more 8920 text key parameters of the type "TargetAddress", which 8921 indicates the target's new address. A redirection response 8922 MAY be issued by a target prior or after completing a 8923 security negotiation if a security negotiation is required. 8924 A redirection SHOULD be accepted by an initiator even 8925 without having the target complete a security negotiation if 8926 any security negotiation is required, and MUST be accepted 8927 by the initiator after the completion of the security 8928 negotiation if any security negotiation is required. 8930 2 - Initiator Error (not a format error) - indicates that the 8931 initiator most likely caused the error. This MAY be due to a 8933 request for a resource for which the initiator does not have 8934 permission. The request should not be tried again. 8936 3 - Target Error - indicates that the target sees no errors in 8937 the initiator's login request, but is currently incapable of 8938 fulfilling the request. The initiator may re-try the same 8939 login request later. 8941 The table below shows all of the currently allocated status codes. 8942 The codes are in hexadecimal; the first byte is the status class 8943 and the second byte is the status detail. 8945 ----------------------------------------------------------------- 8946 Status | Code | Description 8947 |(hex) | 8948 ----------------------------------------------------------------- 8949 Success | 0000 | Login is proceeding OK (*1). 8950 ----------------------------------------------------------------- 8951 Target moved | 0101 | The requested iSCSI Target Name (ITN) 8952 temporarily | | has temporarily moved 8953 | | to the address provided. 8954 ----------------------------------------------------------------- 8955 Target moved | 0102 | The requested ITN has permanently moved 8956 permanently | | to the address provided. 8957 ----------------------------------------------------------------- 8958 Initiator | 0200 | Miscellaneous iSCSI initiator 8959 error | | errors. 8960 ---------------------------------------------------------------- 8961 Authentication| 0201 | The initiator could not be 8962 failure | | successfully authenticated or target 8963 | | authentication is not supported. 8964 ----------------------------------------------------------------- 8965 Authorization | 0202 | The initiator is not allowed access 8966 failure | | to the given target. 8967 ----------------------------------------------------------------- 8968 Not found | 0203 | The requested ITN does not 8969 | | exist at this address. 8970 ----------------------------------------------------------------- 8971 Target removed| 0204 | The requested ITN has been removed and 8972 | |no forwarding address is provided. 8973 ----------------------------------------------------------------- 8974 Unsupported | 0205 | The requested iSCSI version range is 8975 version | | not supported by the target. 8976 ----------------------------------------------------------------- 8977 Too many | 0206 | Too many connections on this SSID. 8978 connections | | 8979 ----------------------------------------------------------------- 8980 Missing | 0207 | Missing parameters (e.g., iSCSI 8981 parameter | | Initiator and/or Target Name). 8982 ----------------------------------------------------------------- 8983 Can't include | 0208 | Target does not support session 8984 in session | | spanning to this connection (address). 8985 ----------------------------------------------------------------- 8986 Session type | 0209 | Target does not support this type of 8987 not supported | | of session or not from this Initiator. 8988 ----------------------------------------------------------------- 8989 Session does | 020a | Attempt to add a connection 8990 not exist | | to a non-existent session. 8991 ----------------------------------------------------------------- 8992 Invalid during| 020b | Invalid Request type during Login. 8993 login | | 8994 ----------------------------------------------------------------- 8995 Target error | 0300 | Target hardware or software error. 8996 ----------------------------------------------------------------- 8997 Service | 0301 | The iSCSI service or target is not 8998 unavailable | | currently operational. 8999 ----------------------------------------------------------------- 9000 Out of | 0302 | The target has insufficient session, 9001 resources | | connection, or other resources. 9002 ----------------------------------------------------------------- 9004 (*1)If the response T bit is 1 in both the request and the 9005 matching response, and the NSG is FullFeaturePhase in both the 9006 request and the matching response, the Login Phase is finished and 9007 the initiator may proceed to issue SCSI commands. 9009 If the Status Class is not 0, the initiator and target MUST close 9010 the TCP connection. 9012 If the target wishes to reject the login request for more than one 9013 reason, it should return the primary reason for the rejection. 9015 11.13.6. T (Transit) bit 9017 The T bit is set to 1 as an indicator of the end of the stage. If 9018 the T bit is set to 1 and NSG is FullFeaturePhase, then this is 9019 also the Final Login Response (see Chapter 5). A T bit of 0 9020 indicates a "partial" response, which means "more negotiation 9021 needed". 9023 A login response with a T bit set to 1 MUST NOT contain key=value 9024 pairs that may require additional answers from the initiator 9025 within the same stage. 9027 If the status class is 0, the T bit MUST NOT be set to 1 if the T 9028 bit in the request was set to 0. 9030 11.13.7. C (Continue) Bit 9032 When set to 1, indicates that the text (set of key=value pairs) in 9033 this Login Response is not complete (it will be continued on 9034 subsequent Login Responses); otherwise, it indicates that this 9035 Login Response ends a set of key=value pairs. A Login Response 9036 with the C bit set to 1 MUST have the T bit set to 0. 9038 11.13.8. Login Parameters 9040 The target MUST provide some basic parameters in order to enable 9041 the initiator to determine if it is connected to the correct port 9042 and the initial text parameters for the security exchange. 9044 All the rules specified in Section 11.11.6 for text responses also 9045 hold for login responses. Keys and their explanations are listed 9046 in Chapter 11 (security negotiation keys) and Chapter 12 9047 (operational parameter negotiation keys). All keys in Section 13, 9048 except for the X extension formats, MUST be supported by iSCSI 9049 initiators and targets. Keys in Section 12, only need to be 9050 supported when the function to which they refer is mandatory to 9051 implement. 9053 11.14. Logout Request 9055 The Logout request is used to perform a controlled closing of a 9056 connection. 9058 An initiator MAY use a logout request to remove a connection from 9059 a session or to close an entire session. 9061 After sending the Logout request PDU, an initiator MUST NOT send 9062 any new iSCSI requests on the closing connection. If the Logout 9063 request is intended to close the session, new iSCSI requests MUST 9064 NOT be sent on any of the connections participating in the 9065 session. 9067 When receiving a Logout request with the reason code of "close the 9068 connection" or "close the session", the target MUST terminate all 9069 pending commands, whether acknowledged via ExpCmdSN or not, on 9070 that connection or session respectively. 9072 When receiving a Logout request with the reason code "remove 9073 connection for recovery", the target MUST discard all requests not 9074 yet acknowledged via ExpCmdSN that were issued on the specified 9075 connection, and suspend all data/status/R2T transfers on behalf of 9076 pending commands on the specified connection. 9078 The target then issues the Logout response and half-closes the TCP 9079 connection (sends FIN). After receiving the Logout response and 9080 attempting to receive the FIN (if still possible), the initiator 9081 MUST completely close the logging-out connection. For the 9082 terminated commands, no additional responses should be expected. 9084 A Logout for a CID may be performed on a different transport 9085 connection when the TCP connection for the CID has already been 9086 terminated. In such a case, only a logical "closing" of the iSCSI 9087 connection for the CID is implied with a Logout. 9089 All commands that were not terminated or not completed (with 9090 status) and acknowledged when the connection is closed completely 9091 can be reassigned to a new connection if the target supports 9092 connection recovery. 9094 If an initiator intends to start recovery for a failing 9095 connection, it MUST use the Logout request to "clean-up" the 9096 target end of a failing connection and enable recovery to start, 9097 or the Login request with a non-zero TSIH and the same CID on a 9098 new connection for the same effect. In sessions with a single 9099 connection, the connection can be closed and then a new connection 9100 reopened. A connection reinstatement login can be used for 9101 recovery (see Section 6.3.4- "Connection Reinstatement"). 9103 A successful completion of a logout request with the reason code 9104 of "close the connection" or "remove the connection for recovery" 9105 results at the target in the discarding of unacknowledged commands 9106 received on the connection being logged out. These are commands 9107 that have arrived on the connection being logged out, but have not 9108 been delivered to SCSI because one or more commands with a smaller 9109 CmdSN has not been received by iSCSI. See Section 4.2.2.1 - 9110 "Command Numbering and Acknowledging". The resulting holes in the 9111 command sequence numbers will have to be handled by appropriate 9112 recovery (see Chapter 6) unless the session is also closed. 9114 The entire logout discussion in this Section is also applicable 9115 for an implicit Logout realized by way of a connection 9116 reinstatement or session reinstatement. When a Login Request 9117 performs an implicit Logout, the implicit Logout is performed as 9118 if having the reason codes specified below: 9120 Reason code Type of implicit Logout 9122 ------------------------------------------- 9124 0 session reinstatement 9126 1 connection reinstatement when the operational 9127 ErrorRecoveryLevel < 2 9129 2 connection reinstatement when the operational 9130 ErrorRecoveryLevel = 2 9132 Byte/ 0 | 1 | 2 | 3 | 9133 / | | | | 9134 |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| 9135 +---------------+---------------+---------------+--------------+ 9136 0|.|I| 0x06 |1| Reason Code | Reserved | 9137 +---------------+---------------+---------------+--------------+ 9138 4|TotalAHSLength | DataSegmentLength | 9139 +--------------------------------------------------------------+ 9140 8/ Reserved / 9141 +/ / 9142 +---------------+---------------+---------------+--------------+ 9143 16| Initiator Task Tag | 9144 +---------------+---------------+---------------+--------------+ 9145 20| CID or Reserved | Reserved | 9146 +---------------+---------------+---------------+--------------+ 9147 24| CmdSN | 9148 +---------------+---------------+---------------+--------------+ 9149 28| ExpStatSN | 9150 +---------------+---------------+---------------+--------------+ 9151 32/ Reserved / 9152 +/ / 9153 +---------------+---------------+---------------+--------------+ 9154 48| Header-Digest (Optional) | 9155 +---------------+---------------+---------------+--------------+ 9157 11.14.1. Reason Code 9159 Reason Code indicates the reason for Logout as follows: 9161 0 - close the session. All commands associated with the 9162 session (if any) are terminated. 9164 1 - close the connection. All commands associated with 9165 connection (if any) are terminated. 9167 2 - remove the connection for recovery. Connection is closed 9168 and all commands associated with it, if any, are to be 9169 prepared for a new allegiance. 9171 All other values are reserved. 9173 11.14.2. TotalAHSLength and DataSegmentLength 9175 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9177 11.14.3. CID 9179 This is the connection ID of the connection to be closed 9180 (including closing the TCP stream). This field is only valid if 9181 the reason code is not "close the session". 9183 11.14.4. ExpStatSN 9185 This is the last ExpStatSN value for the connection to be closed. 9187 11.14.5. Implicit termination of tasks 9189 A target implicitly terminates the active tasks due to the iSCSI 9190 protocol in the following cases: 9192 When a connection is implicitly or explicitly logged out with 9193 the reason code of "Close the connection" and there are 9194 active tasks allegiant to that connection. 9196 When a connection fails and eventually the connection state 9197 times out (state transition M1 in Section 8.2.2- "State 9198 Transition Descriptions for Initiators and Targets") and 9199 there are active tasks allegiant to that connection. 9201 When a successful recovery Logout is performed while there are 9202 active tasks allegiant to that connection, and those tasks 9203 eventually time out after the Time2Wait and Time2Retain 9204 periods without allegiance reassignment. 9206 When a connection is implicitly or explicitly logged out with 9207 the reason code of "Close the session" and there are active 9208 tasks in that session. 9210 If the tasks terminated in any of the above cases are SCSI tasks, 9211 they must be internally terminated as if with CHECK CONDITION 9212 status. This status is only meaningful for appropriately handling 9213 the internal SCSI state and SCSI side effects with respect to 9214 ordering because this status is never communicated back as a 9215 terminating status to the initiator. However additional actions 9216 may have to be taken at SCSI level depending on the SCSI context 9217 as defined by the SCSI standards (e.g., queued commands and ACA, 9218 UA for the next command on the I_T nexus in cases a), b), and c), 9219 after the tasks are terminated, the target MUST report a Unit 9220 Attention condition on the next command processed on any 9221 connection for each affected I_T_L nexus with the status of CHECK 9222 CONDITION, and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS 9223 CLEARED BY ISCSI PROTOCOL EVENT" - etc. - see [SAM4] and [SPC3]). 9225 11.15. Logout Response 9227 The logout response is used by the target to indicate if the 9228 cleanup operation for the connection(s) has completed. 9230 After Logout, the TCP connection referred by the CID MUST be 9231 closed at both ends (or all connections must be closed if the 9232 logout reason was session close). 9234 Byte/ 0 | 1 | 2 | 3 | 9235 / | | | | 9236 |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| 9237 +---------------+---------------+---------------+--------------+ 9238 0|.|.| 0x26 |1| Reserved | Response | Reserved | 9239 +---------------+---------------+---------------+--------------+ 9240 4|TotalAHSLength | DataSegmentLength | 9241 +--------------------------------------------------------------+ 9242 8/ Reserved / 9243 +/ / 9244 +---------------+---------------+---------------+--------------+ 9245 16| Initiator Task Tag | 9246 +---------------+---------------+---------------+--------------+ 9247 20| Reserved | 9248 +---------------+---------------+---------------+--------------+ 9249 24| StatSN | 9250 +---------------+---------------+---------------+--------------+ 9251 28| ExpCmdSN | 9252 +---------------+---------------+---------------+--------------+ 9253 32| MaxCmdSN | 9254 +---------------+---------------+---------------+--------------+ 9255 36| Reserved | 9256 +--------------------------------------------------------------+ 9257 40| Time2Wait | Time2Retain | 9258 +---------------+---------------+---------------+--------------+ 9259 44| Reserved | 9260 +---------------+---------------+---------------+--------------+ 9261 48| Header-Digest (Optional) | 9262 +---------------+---------------+---------------+--------------+ 9264 11.15.1. Response 9266 Logout response: 9268 0 - connection or session closed successfully. 9270 1 - CID not found. 9272 2 - connection recovery is not supported. If Logout reason 9273 code was recovery and target does not support it as 9274 indicated by the ErrorRecoveryLevel. 9276 3 - cleanup failed for various reasons. 9278 11.15.2. TotalAHSLength and DataSegmentLength 9280 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9282 11.15.3. Time2Wait 9284 If the Logout response code is 0 and if the operational 9285 ErrorRecoveryLevel is 2, this is the minimum amount of time, in 9286 seconds, to wait before attempting task reassignment. If the 9287 Logout response code is 0 and if the operational 9288 ErrorRecoveryLevel is less than 2, this field is to be ignored. 9290 This field is invalid if the Logout response code is 1. 9292 If the Logout response code is 2 or 3, this field specifies the 9293 minimum time to wait before attempting a new implicit or explicit 9294 logout. 9296 If Time2Wait is 0, the reassignment or a new Logout may be 9297 attempted immediately. 9299 11.15.4. Time2Retain 9301 If the Logout response code is 0 and if the operational 9302 ErrorRecoveryLevel is 2, this is the maximum amount of time, in 9303 seconds, after the initial wait (Time2Wait), the target waits for 9304 the allegiance reassignment for any active task after which the 9305 task state is discarded. If the Logout response code is 0 and if 9306 the operational ErrorRecoveryLevel is less than 2, this field is 9307 to be ignored. 9309 This field is invalid if the Logout response code is 1. 9311 If the Logout response code is 2 or 3, this field specifies the 9312 maximum amount of time, in seconds, after the initial wait 9313 (Time2Wait), the target waits for a new implicit or explicit 9314 logout. 9316 If it is the last connection of a session, the whole session state 9317 is discarded after Time2Retain. 9319 If Time2Retain is 0, the target has already discarded the 9320 connection (and possibly the session) state along with the task 9321 states. No reassignment or Logout is required in this case. 9323 11.16. SNACK Request 9325 Byte/ 0 | 1 | 2 | 3 | 9326 / | | | 9327 | 9328 |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| 9329 +---------------+---------------+---------------+--------------+ 9330 0|.|.| 0x10 |1|.|.|.| Type | Reserved | 9331 +---------------+---------------+---------------+--------------+ 9332 4|TotalAHSLength | DataSegmentLength | 9333 +---------------+---------------+---------------+--------------+ 9334 8| LUN or Reserved | 9335 + + 9336 12| | 9337 +---------------+---------------+---------------+--------------+ 9338 16| Initiator Task Tag or 0xffffffff | 9339 +---------------+---------------+---------------+--------------+ 9340 20| Target Transfer Tag or SNACK Tag or 0xffffffff | 9341 +---------------+---------------+---------------+--------------+ 9342 24| Reserved | 9343 +---------------+---------------+---------------+--------------+ 9344 28| ExpStatSN | 9345 +---------------+---------------+---------------+--------------+ 9346 32/ Reserved / 9347 +/ / 9348 +---------------+---------------+---------------+--------------+ 9349 40| BegRun | 9350 +--------------------------------------------------------------+ 9351 44| RunLength | 9352 +--------------------------------------------------------------+ 9353 48| Header-Digest (Optional) | 9354 +---------------+---------------+---------------+--------------+ 9356 If the implementation supports ErrorRecoveryLevel greater than 9357 zero, it MUST support all SNACK types. 9359 The SNACK is used by the initiator to request the retransmission 9360 of numbered-responses, data, or R2T PDUs from the target. The 9361 SNACK request indicates the numbered-responses or data "runs" 9362 whose retransmission is requested by the target, where the run 9363 starts with the first StatSN, DataSN, or R2TSN whose 9364 retransmission is requested and indicates the number of Status, 9365 Data, or R2T PDUs requested including the first. 0 has special 9366 meaning when used as a starting number and length: 9368 - When used in RunLength, it means all PDUs starting with the 9369 initial. 9371 - When used in both BegRun and RunLength, it means all 9372 unacknowledged PDUs. 9374 The numbered-response(s) or R2T(s), requested by a SNACK, MUST be 9375 delivered as exact replicas of the ones that the target 9376 transmitted originally except for the fields ExpCmdSN, MaxCmdSN, 9377 and ExpDataSN, which MUST carry the current values. 9378 R2T(s)requested by SNACK MUST also carry the current value of 9379 StatSN. 9381 The numbered Data-In PDUs, requested by a Data SNACK MUST be 9382 delivered as exact replicas of the ones that the target 9383 transmitted originally except for the fields ExpCmdSN and 9384 MaxCmdSN, which MUST carry the current values and except for 9385 resegmentation (see Section 11.16.3). 9387 Any SNACK that requests a numbered-response, Data, or R2T that was 9388 not sent by the target or was already acknowledged by the 9389 initiator, MUST be rejected with a reason code of "Protocol 9390 error". 9392 11.16.1. Type 9394 This field encodes the SNACK function as follows: 9396 0-Data/R2T SNACK - requesting retransmission of one or more 9397 Data-In or R2T PDUs. 9399 1-Status SNACK - requesting retransmission of one or more 9400 numbered responses. 9402 2-DataACK - positively acknowledges Data-In PDUs. 9404 3-R-Data SNACK - requesting retransmission of Data-In PDUs 9405 with possible resegmentation and status tagging. 9407 All other values are reserved. 9409 Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST 9410 precede status acknowledgement for the given command. 9412 11.16.2. Data Acknowledgement 9414 If an initiator operates at ErrorRecoveryLevel 1 or higher, it 9415 MUST issue a SNACK of type DataACK after receiving a Data-In PDU 9416 with the A bit set to 1. However, if the initiator has detected 9417 holes in the input sequence, it MUST postpone issuing the SNACK of 9418 type DataACK until the holes are filled. An initiator MAY ignore 9419 the A bit if it deems that the bit is being set aggressively by 9420 the target (i.e., before the MaxBurstLength limit is 9421 reached). 9423 The DataACK is used to free resources at the target and not to 9424 request or imply data retransmission. 9426 An initiator MUST NOT request retransmission for any data it had 9427 already acknowledged. 9429 11.16.3. Resegmentation 9431 If the initiator MaxRecvDataSegmentLength changed between the 9432 original transmission and the time the initiator requests 9433 retransmission, the initiator MUST issue a R-Data SNACK (see 9434 Section 11.16.1). With R-Data SNACK, the initiator indicates that 9435 it discards all the unacknowledged data and expects the target to 9436 resend it. It also expects resegmentation. In this case, the 9437 retransmitted Data-In PDUs MAY be different from the ones 9438 originally sent in order to reflect changes in 9439 MaxRecvDataSegmentLength. Their DataSN starts with the BegRun of 9440 the last DataACK received by the target if any was received; 9441 otherwise it starts with 0 and is increased by 1 for each resent 9442 Data-In PDU. 9444 A target that has received a R-Data SNACK MUST return a SCSI 9445 Response that contains a copy of the SNACK Tag field from the R- 9446 Data SNACK in the SCSI Response SNACK Tag field as its last or 9447 only Response. For example, if it has already sent a response 9448 containing another value in the SNACK Tag field or had the status 9449 included in the last Data-In PDU, it must send a new SCSI Response 9450 PDU. If a target sends more than one SCSI Response PDU due to this 9451 rule, all SCSI responses must carry the same StatSN (see Section 9452 11.4.4). If an initiator attempts to recover a lost SCSI Response 9453 (with a Status-SNACK, see Section 11.16.1) when more than one 9454 response has been sent, the target will send the SCSI Response 9455 with the latest content known to the target, including the last 9456 SNACK Tag for the command. 9458 For considerations in allegiance reassignment of a task to a 9459 connection with a different MaxRecvDataSegmentLength, refer to 9460 Section 7.2.2. 9462 11.16.4. Initiator Task Tag 9464 For Status SNACK and DataACK, the Initiator Task Tag MUST be set 9465 to the reserved value 0xffffffff. In all other cases, the 9466 Initiator Task Tag field MUST be set to the Initiator Task Tag of 9467 the referenced command. 9469 11.16.5. Target Transfer Tag or SNACK Tag 9471 For an R-Data SNACK, this field MUST contain a value that is 9472 different from 0 or 0xffffffff and is unique for the task 9473 (identified by the Initiator Task Tag). This value MUST be copied 9474 by the iSCSI target in the last or only SCSI Response PDU it 9475 issues for the command. 9477 For DataACK, the Target Transfer Tag MUST contain a copy of the 9478 Target Transfer Tag and LUN provided with the SCSI Data-In PDU 9479 with the A bit set to 1. 9481 In all other cases, the Target Transfer Tag field MUST be set to 9482 the reserved value of 0xffffffff. 9484 11.16.6. BegRun 9486 The DataSN, R2TSN, or StatSN of the first PDU whose retransmission 9487 is requested (Data/R2T and Status SNACK), or the next expected 9488 DataSN (DataACK SNACK). 9490 BegRun 0 when used in conjunction with RunLength 0 means resend 9491 all unacknowledged Data-In, R2T or Response PDUs. 9493 BegRun MUST be 0 for a R-Data SNACK. 9495 11.16.7. RunLength 9497 The number of PDUs whose retransmission is requested. 9499 RunLength 0 signals that all Data-In, R2T, or Response PDUs 9500 carrying the numbers equal to or greater than BegRun have to be 9501 resent. 9503 The RunLength MUST also be 0 for a DataACK SNACK in addition to R- 9504 Data SNACK. 9506 11.17. Reject 9508 Byte/ 0 | 1 | 2 | 3 | 9509 / | | | | 9510 |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| 9511 +---------------+---------------+---------------+--------------+ 9512 0|.|.| 0x3f |1| Reserved | Reason | Reserved | 9513 +---------------+---------------+---------------+--------------+ 9514 4|TotalAHSLength | DataSegmentLength | 9515 +---------------+---------------+---------------+--------------+ 9516 8/ Reserved / 9517 +/ / 9518 +---------------+---------------+---------------+--------------+ 9519 16| 0xffffffff | 9520 +---------------+---------------+---------------+--------------+ 9521 20| Reserved | 9522 +---------------+---------------+---------------+--------------+ 9523 24| StatSN | 9524 +---------------+---------------+---------------+--------------+ 9525 28| ExpCmdSN | 9526 +---------------+---------------+---------------+--------------+ 9527 32| MaxCmdSN | 9528 +---------------+---------------+---------------+--------------+ 9529 36| DataSN/R2TSN or Reserved | 9530 +---------------+---------------+---------------+--------------+ 9531 40| Reserved | 9532 +---------------+---------------+---------------+--------------+ 9533 44| Reserved | 9534 +---------------+---------------+---------------+--------------+ 9535 48| Header-Digest (Optional) | 9536 +---------------+---------------+---------------+--------------+ 9537 xx/ Complete Header of Bad PDU / 9538 +/ / 9539 +---------------+---------------+---------------+--------------+ 9540 yy/Vendor specific data (if any) / 9541 / / 9542 +---------------+---------------+---------------+--------------+ 9543 zz| Data-Digest (Optional) | 9544 +---------------+---------------+---------------+--------------+ 9546 Reject is used to indicate an iSCSI error condition (protocol, 9547 unsupported option, etc.). 9549 11.17.1. Reason 9551 The reject Reason is coded as follows: 9553 +------+----------------------------------------+----------------+ 9554 | Code | Explanation |Can the original| 9555 | (hex)| |PDU be re-sent? | 9556 +------+----------------------------------------+----------------+ 9557 | 0x01 | Reserved | no | 9558 | | | | 9559 | 0x02 | Data (payload) Digest Error | yes (Note 1) | 9560 | | | | 9561 | 0x03 | SNACK Reject | yes | 9562 | | | | 9563 | 0x04 | Protocol Error (e.g., SNACK request for| no | 9564 | | a status that was already acknowledged)| | 9565 | | | | 9566 | 0x05 | Command not supported | no | 9567 | | | | 9568 | 0x06 | Immediate Command Reject - too many | yes | 9569 | | immediate commands | | 9570 | | | | 9571 | 0x07 | Task in progress | no | 9572 | | | | 9573 | 0x08 | Invalid Data ACK | no | 9574 | | | | 9575 | 0x09 | Invalid PDU field | no (Note 2) | 9576 | | | | 9577 | 0x0a | Long Operation Reject - Can't generate | yes | 9578 | | Target Transfer Tag - out of resources | | 9579 | | | | 9580 | 0x0c | Waiting for Logout | no | 9581 +------+----------------------------------------+----------------+ 9583 Note 1: For iSCSI, Data-Out PDU retransmission is only done if the 9584 target requests retransmission with a recovery R2T. However, if 9585 this is the data digest error on immediate data, the initiator may 9586 choose to retransmit the whole PDU including the immediate data. 9588 Note 2: A target should use this reason code for all invalid 9589 values of PDU fields that are meant to describe a task, a 9590 response, or a data transfer. Some examples are invalid TTT/ITT, 9591 buffer offset, LUN qualifying a TTT, and an invalid sequence 9592 number in a SNACK. 9594 Note 3: Reason code 0x0b ("Negotiation reset") defined in 9595 [RFC3720] is deprecated and MUST NOT be used by implementations. 9596 An implementation receiving reason code 0x0b MUST treat it as a 9597 negotiation failure that terminates the Login Phase and the TCP 9598 connection, as specified in Section 7.12. 9600 All other values for Reason are reserved. 9602 In all the cases in which a pre-instantiated SCSI task is 9603 terminated because of the reject, the target MUST issue a proper 9604 SCSI command response with CHECK CONDITION as described in Section 9605 11.4.3. In these cases in which a status for the SCSI task was 9606 already sent before the reject, no additional status is required. 9607 If the error is detected while data from the initiator is still 9608 expected (i.e., the command PDU did not contain all the data and 9609 the target has not received a Data-out PDU with the Final bit set 9610 to 1 for the unsolicited data, if any, and all outstanding R2Ts, 9611 if any), the target MUST wait until it receives the last expected 9612 Data-out PDUs with the F bit set to 1 before sending the Response 9613 PDU. 9615 For additional usage semantics of Reject PDU, see Section 7.3. 9617 11.17.2. DataSN/R2TSN 9619 This field is only valid if the rejected PDU is a Data/R2T SNACK 9620 and the Reject reason code is "Protocol error" (see Section 9621 11.16). The DataSN/R2TSN is the next Data/R2T sequence number 9622 that the target would send for the task, if any. 9624 11.17.3. StatSN, ExpCmdSN and MaxCmdSN 9626 These fields carry their usual values and are not related to the 9627 rejected command. StatSN is advanced after a Reject. 9629 11.17.4. Complete Header of Bad PDU 9631 The target returns the header (not including digest) of the PDU in 9632 error as the data of the response. 9634 11.18. NOP-Out 9636 Byte/ 0 | 1 | 2 | 3 | 9637 / | | | | 9638 |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| 9639 +---------------+---------------+---------------+--------------+ 9640 0|.|I| 0x00 |1| Reserved | 9641 +---------------+---------------+---------------+--------------+ 9642 4|TotalAHSLength | DataSegmentLength | 9643 +---------------+---------------+---------------+--------------+ 9644 8| LUN or Reserved | 9645 + + 9646 12| | 9647 +---------------+---------------+---------------+--------------+ 9648 16| Initiator Task Tag or 0xffffffff | 9649 +---------------+---------------+---------------+--------------+ 9650 20| Target Transfer Tag or 0xffffffff | 9651 +---------------+---------------+---------------+--------------+ 9652 24| CmdSN | 9653 +---------------+---------------+---------------+--------------+ 9654 28| ExpStatSN | 9655 +---------------+---------------+---------------+--------------+ 9656 32/ Reserved / 9657 +/ / 9658 +---------------+---------------+---------------+--------------+ 9659 48| Header-Digest (Optional) | 9660 +---------------+---------------+---------------+--------------+ 9661 / DataSegment - Ping Data (optional) / 9662 +/ / 9663 +---------------+---------------+---------------+--------------+ 9664 | Data-Digest (Optional) | 9665 +---------------+---------------+---------------+--------------+ 9667 A NOP-Out may be used by an initiator as a "ping request" to 9668 verify that a connection/session is still active and all its 9669 components are operational. The NOP-In response is the "ping 9670 echo". 9672 A NOP-Out is also sent by an initiator in response to a NOP-In. 9674 A NOP-Out may also be used to confirm a changed ExpStatSN if 9675 another PDU will not be available for a long time. 9677 Upon receipt of a NOP-In with the Target Transfer Tag set to a 9678 valid value (not the reserved 0xffffffff), the initiator MUST 9679 respond with a NOP-Out. In this case, the NOP-Out Target Transfer 9680 Tag MUST contain a copy of the NOP-In Target Transfer Tag. The 9681 initiator SHOULD NOT send a NOP-Out in response to any other 9682 received NOP-In in order to avoid lengthy sequences of NOP-In and 9683 NOP-Out PDUs sent in response to each other. 9685 11.18.1. Initiator Task Tag 9687 The NOP-Out MUST have the Initiator Task Tag set to a valid value 9688 only if a response in the form of NOP-In is requested (i.e., the 9689 NOP-Out is used as a ping request). Otherwise, the Initiator Task 9690 Tag MUST be set to 0xffffffff. 9692 When a target receives the NOP-Out with a valid Initiator Task 9693 Tag, it MUST respond with a Nop-In Response (see Section 6). 9695 If the Initiator Task Tag contains 0xffffffff, the I bit MUST be 9696 set to 1 and the CmdSN is not advanced after this PDU is sent. 9698 11.18.2. Target Transfer Tag 9700 A target assigned identifier for the operation. 9702 The NOP-Out MUST only have the Target Transfer Tag set if it is 9703 issued in response to a NOP-In with a valid Target Transfer Tag. 9704 In this case, it copies the Target Transfer Tag from the NOP-In 9705 PDU. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff. 9707 When the Target Transfer Tag is set to a value other than 9708 0xffffffff, the LUN field MUST also be copied from the NOP-In. 9710 11.18.3. Ping Data 9712 Ping data is reflected in the NOP-In Response. The length of the 9713 reflected data is limited to MaxRecvDataSegmentLength. The length 9714 of ping data is indicated by the DataSegmentLength. 0 is a valid 9715 value for the DataSegmentLength and indicates the absence of ping 9716 data. 9718 11.19. NOP-In 9720 Byte/ 0 | 1 | 2 | 3 | 9721 / | | | | 9722 |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| 9723 +---------------+---------------+---------------+--------------+ 9724 0|.|.| 0x20 |1| Reserved | 9725 +---------------+---------------+---------------+--------------+ 9726 4|TotalAHSLength | DataSegmentLength | 9727 +---------------+---------------+---------------+--------------+ 9728 8| LUN or Reserved | 9729 + + 9730 12| | 9731 +---------------+---------------+---------------+--------------+ 9732 16| Initiator Task Tag or 0xffffffff | 9733 +---------------+---------------+---------------+--------------+ 9734 20| Target Transfer Tag or 0xffffffff | 9735 +---------------+---------------+---------------+--------------+ 9736 24| StatSN | 9737 +---------------+---------------+---------------+--------------+ 9738 28| ExpCmdSN | 9739 +---------------+---------------+---------------+--------------+ 9740 32| MaxCmdSN | 9741 +---------------+---------------+---------------+--------------+ 9742 36/ Reserved / 9743 +/ / 9744 +---------------+---------------+---------------+--------------+ 9745 48| Header-Digest (Optional) | 9746 +---------------+---------------+---------------+--------------+ 9747 / DataSegment - Return Ping Data / 9748 +/ / 9749 +---------------+---------------+---------------+--------------+ 9750 | Data-Digest (Optional) | 9751 +---------------+---------------+---------------+--------------+ 9753 NOP-In is either sent by a target as a response to a NOP-Out, as a 9754 "ping" to an initiator, or as a means to carry a changed ExpCmdSN 9755 and/or MaxCmdSN if another PDU will not be available for a long 9756 time (as determined by the target). 9758 When a target receives the NOP-Out with a valid Initiator Task Tag 9759 (not the reserved value 0xffffffff), it MUST respond with a NOP-In 9760 with the same Initiator Task Tag that was provided in the NOP-Out 9761 request. It MUST also duplicate up to the first 9762 MaxRecvDataSegmentLength bytes of the initiator provided Ping 9763 Data. For such a response, the Target Transfer Tag MUST be 9764 0xffffffff. The target SHOULD NOT send a NOP-In in response to any 9765 other received NOP-Out in order to avoid lengthy sequences of NOP- 9766 In and NOP-Out PDUs sent in response to each other. 9768 Otherwise, when a target sends a NOP-In that is not a response to 9769 a Nop-Out received from the initiator, the Initiator Task Tag MUST 9770 be set to 0xffffffff and the Data Segment MUST NOT contain any 9771 data (DataSegmentLength MUST be 0). 9773 11.19.1. Target Transfer Tag 9775 If the target is responding to a NOP-Out, this is set to the 9776 reserved value 0xffffffff. 9778 If the target is sending a NOP-In as a Ping (intending to receive 9779 a corresponding NOP-Out), this field is set to a valid value (not 9780 the reserved 0xffffffff). 9782 If the target is initiating a NOP-In without wanting to receive a 9783 corresponding NOP-Out, this field MUST hold the reserved value of 9784 0xffffffff. 9786 11.19.2. StatSN 9788 The StatSN field will always contain the next StatSN. However, 9789 when the Initiator Task Tag is set to 0xffffffff StatSN for the 9790 connection is not advanced after this PDU is sent. 9792 11.19.3. LUN 9794 A LUN MUST be set to a correct value when the Target Transfer Tag 9795 is valid (not the reserved value 0xffffffff). 9797 12. iSCSI Security Text Keys and Authentication Methods 9799 Only the following keys are used during the SecurityNegotiation 9800 stage of the Login Phase: 9802 SessionType 9804 InitiatorName 9806 TargetName 9808 TargetAddress 9810 InitiatorAlias 9812 TargetAlias 9814 TargetPortalGroupTag 9816 AuthMethod and the keys used by the authentication methods 9817 specified under Section 12.1 along with all of their 9818 associated keys as well as Vendor Specific Authentication 9819 Methods. 9821 Other keys MUST NOT be used. 9823 SessionType, InitiatorName, TargetName, InitiatorAlias, 9824 TargetAlias, and TargetPortalGroupTag are described in Section 13 9825 as they can be used also in the OperationalNegotiation stage. 9827 All security keys have connection-wide applicability. 9829 12.1. AuthMethod 9831 Use: During Login - Security Negotiation 9832 Senders: Initiator and Target 9833 Scope: connection 9835 AuthMethod = 9837 The main item of security negotiation is the authentication method 9838 (AuthMethod). 9840 The authentication methods that can be used (appear in the list- 9841 of-values) are either those listed in the following table or are 9842 vendor-unique methods: 9844 +------------------------------------------------------------+ 9845 | Name | Description | 9846 +------------------------------------------------------------+ 9847 | KRB5 | Kerberos V5 - defined in [RFC4120] | 9848 +------------------------------------------------------------+ 9849 | SRP | Secure Remote Password | 9850 | | defined in [RFC2945] | 9851 +------------------------------------------------------------+ 9852 | CHAP | Challenge Handshake Authentication Protocol| 9853 | | defined in [RFC1994] | 9854 +------------------------------------------------------------+ 9855 | None | No authentication | 9856 +------------------------------------------------------------+ 9858 The AuthMethod selection is followed by an "authentication 9859 exchange" specific to the authentication method selected. 9861 The authentication method proposal may be made by either the 9862 initiator or the target. However the initiator MUST make the first 9863 step specific to the selected authentication method as soon as it 9864 is selected. It follows that if the target makes the 9865 authentication method proposal the initiator sends the first 9866 key(s) of the exchange together with its authentication method 9867 selection. 9869 The authentication exchange authenticates the initiator to the 9870 target, and optionally, the target to the initiator. 9871 Authentication is OPTIONAL to use but MUST be supported by the 9872 target and initiator. 9874 The initiator and target MUST implement CHAP. All other 9875 authentication methods are OPTIONAL. 9877 Private or public extension algorithms MAY also be negotiated for 9878 authentication methods. Whenever a private or public extension 9879 algorithm is part of the default offer (the offer made in absence 9880 of explicit administrative action) the implementer MUST ensure 9881 that CHAP is listed as an alternative in the default offer and 9882 "None" is not part of the default offer. 9884 Extension authentication methods MUST be named using one of the 9885 following two formats: 9887 i) Z-reversed.vendor.dns_name.do_something= 9888 ii) New public key with no name prefix constraints 9890 Authentication methods named using the Z- format are used as 9891 private extensions. New public keys must be registered with IANA 9892 using IETF Review process ([RFC5226]). New public extensions for 9893 authentication methods MUST NOT use the Z# name prefix. 9895 For all of the public or private extension authentication methods, 9896 the method specific keys MUST conform to the format specified in 9897 Section 6.1- "Text Format" for standard-label. 9899 To identify the vendor for private extension authentication 9900 methods, we suggest you use the reversed DNS-name as a prefix to 9901 the proper digest names. 9903 The part of digest-name following Z- MUST conform to the format 9904 for standard-label specified in Section 6.1 - "Text Format". 9906 Support for public or private extension authentication methods is 9907 OPTIONAL. 9909 The following subsections define the specific exchanges for each 9910 of the standardized authentication methods. As mentioned earlier 9911 the first step is always done by the initiator. 9913 12.1.1. Kerberos 9915 For KRB5 (Kerberos V5) [RFC4120] and [RFC1964], the initiator MUST 9916 use: 9918 KRB_AP_REQ= 9920 where KRB_AP_REQ is the client message as defined in [RFC4120]. 9922 The default principal name assumed by an iSCSI initiator or target 9923 (prior to any administrative configuration action) MUST be the 9924 iSCSI Initiator Name or iSCSI Target Name respectively, prefixed 9925 by the string "iscsi/". 9927 If the initiator authentication fails, the target MUST respond 9928 with a Login reject with "Authentication Failure" status. 9929 Otherwise, if the initiator has selected the mutual authentication 9930 option (by setting MUTUAL-REQUIRED in the ap-options field of the 9931 KRB_AP_REQ), the target MUST reply with: 9933 KRB_AP_REP= 9935 where KRB_AP_REP is the server's response message as defined in 9936 [RFC4120]. 9938 If mutual authentication was selected and target authentication 9939 fails, the initiator MUST close the connection. 9941 KRB_AP_REQ and KRB_AP_REP are binary-values and their binary 9942 length (not the length of the character string that represents 9943 them in encoded form) MUST NOT exceed 65536 bytes. 9945 12.1.2. Secure Remote Password (SRP) 9947 For SRP [RFC2945], the initiator MUST use: 9949 SRP_U= TargetAuth=Yes /* or TargetAuth=No */ 9951 The target MUST answer with a Login reject with the "Authorization 9952 Failure" status or reply with: 9954 SRP_GROUP= SRP_s= 9956 Where G1,G2... are proposed groups, in order of preference. 9958 The initiator MUST either close the connection or continue with: 9960 SRP_A= SRP_GROUP= 9961 Where G is one of G1,G2... that were proposed by the target. 9963 The target MUST answer with a Login reject with the 9964 "Authentication Failure" status or reply with: 9966 SRP_B= 9968 The initiator MUST close the connection or continue with: 9970 SRP_M= 9972 If the initiator authentication fails, the target MUST answer with 9973 a Login reject with "Authentication Failure" status. Otherwise, if 9974 the initiator sent TargetAuth=Yes in the first message (requiring 9975 target authentication), the target MUST reply with: 9977 SRP_HM= 9979 If the target authentication fails, the initiator MUST close the 9980 connection. 9982 Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] 9983 (using the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn 9984 stands for G1,G2...) are identifiers of SRP groups specified in 9985 [RFC3723]. G, Gn, and U are text strings, s,A,B,M, and H(A | M | 9986 K) are binary-values. The length of s,A,B,M and H(A | M | K) in 9987 binary form (not the length of the character string that 9988 represents them in encoded form) MUST NOT exceed 1024 bytes. 9990 For the SRP_GROUP, all the groups specified in [RFC3723] up to 9991 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be 9992 supported by initiators and targets. To guarantee 9993 interoperability, targets MUST always offer "SRP-1536" as one of 9994 the proposed groups. 9996 12.1.3. Challenge Handshake Authentication Protocol (CHAP) 9998 For CHAP [RFC1994], the initiator MUST use: 10000 CHAP_A= 10002 Where A1,A2... are proposed algorithms, in order of preference. 10004 The target MUST answer with a Login reject with the 10005 "Authentication Failure" status or reply with: 10007 CHAP_A= CHAP_I= CHAP_C= 10009 Where A is one of A1,A2... that were proposed by the initiator. 10011 The initiator MUST continue with: 10013 CHAP_N= CHAP_R= 10015 or, if it requires target authentication, with: 10017 CHAP_N= CHAP_R= CHAP_I= CHAP_C= 10019 If the initiator authentication fails, the target MUST answer with 10020 a Login reject with "Authentication Failure" status. Otherwise, if 10021 the initiator required target authentication, the target MUST 10022 either answer with a Login reject with "Authentication Failure" or 10023 reply with: 10025 CHAP_N= CHAP_R= 10027 If target authentication fails, the initiator MUST close the 10028 connection. 10030 Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, 10031 Algorithm, Identifier, Challenge, and Response as defined in 10032 [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C 10033 and R are binary-values and their binary length (not the length of 10034 the character string that represents them in encoded form) MUST 10035 NOT exceed 1024 bytes. 10037 For the Algorithm, as stated in [RFC1994], one value is required 10038 to be implemented: 10040 5 (CHAP with MD5) 10042 To guarantee interoperability, initiators MUST always offer it as 10043 one of the proposed algorithms. 10045 13. Login/Text Operational Text Keys 10047 Some session specific parameters MUST only be carried on the 10048 leading connection and cannot be changed after the leading 10049 connection login (e.g., MaxConnections, the maximum number of 10050 connections). This holds for a single connection session with 10051 regard to connection restart. The keys that fall into this 10052 category have the use: LO (Leading Only). 10054 Keys that can only be used during login have the use: IO 10055 (initialize only), while those that can be used in both the Login 10056 Phase and Full Feature Phase have the use: ALL. 10058 Keys that can only be used during Full Feature Phase use FFPO 10059 (Full Feature Phase only). 10061 Keys marked as Any-Stage may also appear in the 10062 SecurityNegotiation stage while all other keys described in this 10063 chapter are operational keys. 10065 Keys that do not require an answer are marked as Declarative. 10067 Key scope is indicated as session-wide (SW) or connection-only 10068 (CO). 10070 Result function, wherever mentioned, states the function that can 10071 be applied to check the validity of the responder selection. 10072 Minimum means that the selected value cannot exceed the offered 10073 value. Maximum means that the selected value cannot be lower than 10074 the offered value. AND means that the selected value must be a 10075 possible result of a Boolean "and" function with an arbitrary 10076 Boolean value (e.g., if the offered value is No the selected value 10077 must be No). OR means that the selected value must be a possible 10078 result of a Boolean "or" function with an arbitrary Boolean value 10079 (e.g., if the offered value is Yes the selected value must be 10080 Yes). 10082 13.1. HeaderDigest and DataDigest 10084 Use: IO 10085 Senders: Initiator and Target 10086 Scope: CO 10087 HeaderDigest = 10088 DataDigest = 10090 Default is None for both HeaderDigest and DataDigest. 10092 Digests enable the checking of end-to-end, non-cryptographic data 10093 integrity beyond the integrity checks provided by the link layers 10094 and the covering of the whole communication path including all 10095 elements that may change the network level PDUs such as routers, 10096 switches, and proxies. 10098 The following table lists cyclic integrity checksums that can be 10099 negotiated for the digests and that MUST be implemented by every 10100 iSCSI initiator and target. These digest options only have error 10101 detection significance. 10103 +---------------------------------------------+ 10104 | Name | Description | Generator | 10105 +---------------------------------------------+ 10106 | CRC32C | 32 bit CRC |0x11edc6f41| 10107 +---------------------------------------------+ 10108 | None | no digest | 10109 +---------------------------------------------+ 10111 The generator polynomial for this digest is given in hex-notation 10112 (e.g., 0x3b stands for 0011 1011 and the polynomial is 10113 x**5+X**4+x**3+x+1). 10115 When the Initiator and Target agree on a digest, this digest MUST 10116 be used for every PDU in Full Feature Phase. 10118 Padding bytes, when present in a segment covered by a CRC, SHOULD 10119 be set to 0 and are included in the CRC. 10121 The CRC MUST be calculated by a method that produces the same 10122 results as the following process: 10124 - The PDU bits are considered as the coefficients of a 10125 polynomial M(x) of degree n-1; bit 7 of the lowest numbered 10126 byte is considered the most significant bit (x^n-1), 10128 followed by bit 6 of the lowest numbered byte through bit 0 10129 of the highest numbered byte (x^0). 10131 - The most significant 32 bits are complemented. 10133 - The polynomial is multiplied by x^32 then divided by G(x). 10134 The generator polynomial produces a remainder R(x) of degree 10135 <= 31. 10137 - The coefficients of R(x) are considered a 32 bit sequence. 10139 - The bit sequence is complemented and the result is the CRC. 10141 - The CRC bits are mapped into the digest word. The x^31 10142 coefficient in bit 7 of the lowest numbered byte of the 10143 digest continuing through to the byte up to the x^24 10144 coefficient in bit 0 of the lowest numbered byte, continuing 10145 with the x^23 coefficient in bit 7 of next byte through x^0 10146 in bit 0 of the highest numbered byte. 10148 - Computing the CRC over any segment (data or header) extended 10149 to include the CRC built using the generator 0x11edc6f41 10150 will always get the value 0x1c2d19ed as its final remainder 10151 (R(x)). This value is given here in its polynomial form 10152 (i.e., not mapped as the digest word). 10154 For a discussion about selection criteria for the CRC, see 10155 [RFC3385]. For a detailed analysis of the iSCSI polynomial, see 10156 [Castagnoli93]. 10158 Private or public extension algorithms MAY also be negotiated for 10159 digests. Whenever a private or public digest extension algorithm 10160 is part of the default offer (the offer made in absence of 10161 explicit administrative action) the implementer MUST ensure that 10162 CRC32C is listed as an alternative in the default offer and "None" 10163 is not part of the default offer. 10165 Extension digest algorithms MUST be named using one of the 10166 following two formats: 10168 i) Y-reversed.vendor.dns_name.do_something= 10169 ii) New public key with no name prefix constraints 10171 Digests named using the Y- format are used for private purposes 10172 (unregistered). New public keys must be registered with IANA using 10173 IETF Review process ([RFC5226]). New public extensions for digests 10174 MUST NOT use the Y# name prefix. 10176 For private extension digests, to identify the vendor, we suggest 10177 you use the reversed DNS-name as a prefix to the proper digest 10178 names. 10180 The part of digest-name following Y- MUST conform to the format 10181 for standard-label specified in Section 6.1. 10183 Support for public or private extension digests is OPTIONAL. 10185 13.2. MaxConnections 10187 Use: LO 10188 Senders: Initiator and Target 10189 Scope: SW 10190 Irrelevant when: SessionType=Discovery 10192 MaxConnections= 10194 Default is 1. 10195 Result function is Minimum. 10197 Initiator and target negotiate the maximum number of connections 10198 requested/acceptable. 10200 13.3. SendTargets 10202 Use: FFPO 10203 Senders: Initiator 10204 Scope: SW 10206 For a complete description, see Appendix D. - "SendTargets 10207 Operation". 10209 13.4. TargetName 10211 Use: IO by initiator, FFPO by target - only as response to a 10212 SendTargets, Declarative, Any-Stage 10213 Senders: Initiator and Target 10214 Scope: SW 10216 TargetName= 10218 Examples: 10220 TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 10222 TargetName=eui.020000023B040506 10224 TargetName=naa.62004567BA64678D0123456789ABCDEF 10226 The initiator of the TCP connection MUST provide this key to the 10227 remote endpoint in the first login request if the initiator is not 10228 establishing a discovery session. The iSCSI Target Name specifies 10229 the worldwide unique name of the target. 10231 The TargetName key may also be returned by the "SendTargets" text 10232 request (which is its only use when issued by a target). 10234 TargetName MUST NOT be redeclared within the login phase. 10236 13.5. InitiatorName 10238 Use: IO, Declarative, Any-Stage 10239 Senders: Initiator 10240 Scope: SW 10242 InitiatorName= 10244 Examples: 10246 InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345 10248 InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90 10249 InitiatorName=naa.52004567BA64678D 10251 The initiator of the TCP connection MUST provide this key to the 10252 remote endpoint at the first Login of the Login Phase for every 10253 connection. The InitiatorName key enables the initiator to 10254 identify itself to the remote endpoint. 10256 InitiatorName MUST NOT be redeclared within the login phase. 10258 13.6. TargetAlias 10260 Use: ALL, Declarative, Any-Stage 10261 Senders: Target 10262 Scope: SW 10264 TargetAlias= 10266 Examples: 10268 TargetAlias=Bob-s Disk 10270 TargetAlias=Database Server 1 Log Disk 10272 TargetAlias=Web Server 3 Disk 20 10274 If a target has been configured with a human-readable name or 10275 description, this name SHOULD be communicated to the initiator 10276 during a Login Response PDU if SessionType=Normal (see 13.21). 10277 This string is not used as an identifier, nor is it meant to be 10278 used for authentication or authorization decisions. It can be 10279 displayed by the initiator's user interface in a list of targets 10280 to which it is connected. 10282 13.7. InitiatorAlias 10284 Use: ALL, Declarative, Any-Stage 10285 Senders: Initiator 10286 Scope: SW 10288 InitiatorAlias= 10289 Examples: 10291 InitiatorAlias=Web Server 4 10293 InitiatorAlias=spyalley.nsa.gov 10295 InitiatorAlias=Exchange Server 10297 If an initiator has been configured with a human-readable name or 10298 description, it SHOULD be communicated to the target during a 10299 Login Request PDU. If not, the host name can be used instead. This 10300 string is not used as an identifier, nor is meant to be used for 10301 authentication or authorization decisions. It can be displayed by 10302 the target's user interface in a list of initiators to which it is 10303 connected. 10305 13.8. TargetAddress 10307 Use: ALL, Declarative, Any-Stage 10308 Senders: Target 10309 Scope: SW 10311 TargetAddress=domainname[:port][,portal-group-tag] 10313 The domainname can be specified as either a DNS host name, a 10314 dotted-decimal IPv4 address, or a bracketed IPv6 address as 10315 specified in [RFC3986]. 10317 If the TCP port is not specified, it is assumed to be the IANA- 10318 assigned default port for iSCSI (see Section 14 -"IANA 10319 Considerations"). 10321 If the TargetAddress is returned as the result of a redirect 10322 status in a login response, the comma and portal group tag MUST be 10323 omitted. 10325 If the TargetAddress is returned within a SendTargets response, 10326 the portal group tag MUST be included. 10328 Examples: 10330 TargetAddress=10.0.0.1:5003,1 10332 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 10334 TargetAddress=[1080::8:800:200C:417A]:5003,1 10336 TargetAddress=computingcenter.example.com,23 10338 Use of the portal-group-tag is described in Appendix D. - 10339 "SendTargets Operation". The formats for the port and portal- 10340 group-tag are the same as the one specified in 10341 TargetPortalGroupTag. 10343 13.9. TargetPortalGroupTag 10345 Use: IO by target, Declarative, Any-Stage 10346 Senders: Target 10347 Scope: SW 10349 TargetPortalGroupTag=<16-bit-binary-value> 10351 Examples: 10352 TargetPortalGroupTag=1 10354 The target portal group tag is a 16-bit binary-value that uniquely 10355 identifies a portal group within an iSCSI target node. This key 10356 carries the value of the tag of the portal group that is servicing 10357 the Login request. The iSCSI target returns this key to the 10358 initiator in the Login Response PDU to the first Login Request PDU 10359 that has the C bit set to 0 when TargetName is given by the 10360 initiator. 10362 [SAM2] and [SAM3] specifications note in their informative text 10363 that TPGT value should be non-zero, note that it is incorrect. A 10364 zero value is allowed as a legal value for TPGT. This discrepancy 10365 currently stands corrected in [SAM4]. 10367 For the complete usage expectations of this key see Section 6.3. 10369 13.10. InitialR2T 10371 Use: LO 10372 Senders: Initiator and Target 10373 Scope: SW 10374 Irrelevant when: SessionType=Discovery 10376 InitialR2T= 10378 Examples: 10380 I->InitialR2T=No 10382 T->InitialR2T=No 10384 Default is Yes. 10385 Result function is OR. 10387 The InitialR2T key is used to turn off the default use of R2T for 10388 unidirectional and the output part of bidirectional commands, thus 10389 allowing an initiator to start sending data to a target as if it 10390 has received an initial R2T with Buffer Offset=Immediate Data 10391 Length and Desired Data Transfer Length=(min(FirstBurstLength, 10392 Expected Data Transfer Length) - Received Immediate Data Length). 10394 The default action is that R2T is required, unless both the 10395 initiator and the target send this key-pair attribute specifying 10396 InitialR2T=No. Only the first outgoing data burst (immediate data 10397 and/or separate PDUs) can be sent unsolicited (i.e., not requiring 10398 an explicit R2T). 10400 13.11. ImmediateData 10402 Use: LO 10403 Senders: Initiator and Target 10404 Scope: SW 10405 Irrelevant when: SessionType=Discovery 10407 ImmediateData= 10409 Default is Yes. 10411 Result function is AND. 10413 The initiator and target negotiate support for immediate data. To 10414 turn immediate data off, the initiator or target must state its 10415 desire to do so. ImmediateData can be turned on if both the 10416 initiator and target have ImmediateData=Yes. 10418 If ImmediateData is set to Yes and InitialR2T is set to Yes 10419 (default), then only immediate data are accepted in the first 10420 burst. 10422 If ImmediateData is set to No and InitialR2T is set to Yes, then 10423 the initiator MUST NOT send unsolicited data and the target MUST 10424 reject unsolicited data with the corresponding response code. 10426 If ImmediateData is set to No and InitialR2T is set to No, then 10427 the initiator MUST NOT send unsolicited immediate data, but MAY 10428 send one unsolicited burst of Data-OUT PDUs. 10430 If ImmediateData is set to Yes and InitialR2T is set to No, then 10431 the initiator MAY send unsolicited immediate data and/or one 10432 unsolicited burst of Data-OUT PDUs. 10434 The following table is a summary of unsolicited data options: 10436 +----------+-------------+------------------+--------------+ 10437 |InitialR2T|ImmediateData| Unsolicited |Immediate Data| 10438 | | | Data Out PDUs | | 10439 +----------+-------------+------------------+--------------+ 10440 | No | No | Yes | No | 10441 +----------+-------------+------------------+--------------+ 10442 | No | Yes | Yes | Yes | 10443 +----------+-------------+------------------+--------------+ 10444 | Yes | No | No | No | 10445 +----------+-------------+------------------+--------------+ 10446 | Yes | Yes | No | Yes | 10447 +----------+-------------+------------------+--------------+ 10449 13.12. MaxRecvDataSegmentLength 10451 Use: ALL, Declarative 10452 Senders: Initiator and Target 10453 Scope: CO 10455 MaxRecvDataSegmentLength= 10457 Default is 8192 bytes. 10459 The initiator or target declares the maximum data segment length 10460 in bytes it can receive in an iSCSI PDU. 10462 The transmitter (initiator or target) is required to send PDUs 10463 with a data segment that does not exceed MaxRecvDataSegmentLength 10464 of the receiver. 10466 A target receiver is additionally limited by MaxBurstLength for 10467 solicited data and FirstBurstLength for unsolicited data. An 10468 initiator MUST NOT send solicited PDUs exceeding MaxBurstLength 10469 nor unsolicited PDUs exceeding FirstBurstLength (or 10470 FirstBurstLength-Immediate Data Length if immediate data were 10471 sent). 10473 13.13. MaxBurstLength 10475 Use: LO 10476 Senders: Initiator and Target 10477 Scope: SW 10478 Irrelevant when: SessionType=Discovery 10480 MaxBurstLength= 10482 Default is 262144 (256 Kbytes). 10483 Result function is Minimum. 10485 The initiator and target negotiate maximum SCSI data payload in 10486 bytes in a Data-In or a solicited Data-Out iSCSI sequence. A 10487 sequence consists of one or more consecutive Data-In or Data-Out 10488 PDUs that end with a Data-In or Data-Out PDU with the F bit set to 10489 one. 10491 13.14. FirstBurstLength 10493 Use: LO 10494 Senders: Initiator and Target 10495 Scope: SW 10496 Irrelevant when: SessionType=Discovery 10497 Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) 10499 FirstBurstLength= 10501 Default is 65536 (64 Kbytes). 10502 Result function is Minimum. 10504 The initiator and target negotiate the maximum amount in bytes of 10505 unsolicited data an iSCSI initiator may send to the target during 10506 the execution of a single SCSI command. This covers the immediate 10507 data (if any) and the sequence of unsolicited Data-Out PDUs (if 10508 any) that follow the command. 10510 FirstBurstLength MUST NOT exceed MaxBurstLength. 10512 13.15. DefaultTime2Wait 10514 Use: LO 10515 Senders: Initiator and Target 10516 Scope: SW 10518 DefaultTime2Wait= 10520 Default is 2. 10521 Result function is Maximum. 10523 The initiator and target negotiate the minimum time, in seconds, 10524 to wait before attempting an explicit/implicit logout or an active 10525 task reassignment after an unexpected connection termination or a 10526 connection reset. 10528 A value of 0 indicates that logout or active task reassignment can 10529 be attempted immediately. 10531 13.16. DefaultTime2Retain 10533 Use: LO 10534 Senders: Initiator and Target 10535 Scope: SW 10536 DefaultTime2Retain= 10538 Default is 20. 10539 Result function is Minimum. 10541 The initiator and target negotiate the maximum time, in seconds 10542 after an initial wait (Time2Wait), before which an active task 10543 reassignment is still possible after an unexpected connection 10544 termination or a connection reset. 10546 This value is also the session state timeout if the connection in 10547 question is the last LOGGED_IN connection in the session. 10549 A value of 0 indicates that connection/task state is immediately 10550 discarded by the target. 10552 13.17. MaxOutstandingR2T 10554 Use: LO 10555 Senders: Initiator and Target 10556 Scope: SW 10558 MaxOutstandingR2T= 10559 Irrelevant when: SessionType=Discovery 10561 Default is 1. 10562 Result function is Minimum. 10564 Initiator and target negotiate the maximum number of outstanding 10565 R2Ts per task, excluding any implied initial R2T that might be 10566 part of that task. An R2T is considered outstanding until the last 10567 data PDU (with the F bit set to 1) is transferred, or a sequence 10568 reception timeout (Section 7.1.4.1) is encountered for that data 10569 sequence. 10571 13.18. DataPDUInOrder 10573 Use: LO 10574 Senders: Initiator and Target 10575 Scope: SW 10576 Irrelevant when: SessionType=Discovery 10577 DataPDUInOrder= 10579 Default is Yes. 10580 Result function is OR. 10582 No is used by iSCSI to indicate that the data PDUs within 10583 sequences can be in any order. Yes is used to indicate that data 10584 PDUs within sequences have to be at continuously increasing 10585 addresses and overlays are forbidden. 10587 13.19. DataSequenceInOrder 10589 Use: LO 10590 Senders: Initiator and Target 10591 Scope: SW 10592 Irrelevant when: SessionType=Discovery 10594 DataSequenceInOrder= 10596 Default is Yes. 10597 Result function is OR. 10599 A Data Sequence is a sequence of Data-In or Data-Out PDUs that end 10600 with a Data-In or Data-Out PDU with the F bit set to one. A Data- 10601 out sequence is sent either unsolicited or in response to an R2T. 10602 Sequences cover an offset-range. 10604 If DataSequenceInOrder is set to No, Data PDU sequences may be 10605 transferred in any order. 10607 If DataSequenceInOrder is set to Yes, Data Sequences MUST be 10608 transferred using continuously non-decreasing sequence offsets 10609 (R2T buffer offset for writes, or the smallest SCSI Data-In buffer 10610 offset within a read data sequence). 10612 If DataSequenceInOrder is set to Yes, a target may retry at most 10613 the last R2T, and an initiator may at most request retransmission 10614 for the last read data sequence. For this reason, if 10615 ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes 10616 then MaxOustandingR2T MUST be set to 1. 10618 13.20. ErrorRecoveryLevel 10620 Use: LO 10621 Senders: Initiator and Target 10622 Scope: SW 10624 ErrorRecoveryLevel= 10626 Default is 0. 10627 Result function is Minimum. 10629 The initiator and target negotiate the recovery level supported. 10631 Recovery levels represent a combination of recovery capabilities. 10632 Each recovery level includes all the capabilities of the lower 10633 recovery levels and adds some new ones to them. 10635 In the description of recovery mechanisms, certain recovery 10636 classes are specified. Section 7.1.5 describes the mapping between 10637 the classes and the levels. 10639 13.21. SessionType 10641 Use: LO, Declarative, Any-Stage 10642 Senders: Initiator 10643 Scope: SW 10645 SessionType= 10647 Default is Normal. 10649 The Initiator indicates the type of session it wants to create. 10650 The target can either accept it or reject it. 10652 A Discovery session indicates to the Target that the only purpose 10653 of this Session is discovery. The only requests a target accepts 10654 in this type of session are a text request with a SendTargets key 10655 and a logout request with reason "close the session". 10657 The Discovery session implies MaxConnections = 1 and overrides 10658 both the default and an explicit setting. As Section 7.4.1 10660 states, ErrorRecoveryLevel MUST be 0 (zero) for Discovery 10661 sessions. 10663 Depending on the type of the session, a target may decide on 10664 resources to allocate and the security to enforce, etc. for the 10665 session. If the SessionType key is thus going to be offered as 10666 "Discovery", it SHOULD be offered in the initial Login request by 10667 the initiator. 10669 13.22. The Private Extension Key Format 10671 Use: ALL 10672 Senders: Initiator and Target 10673 Scope: specific key dependent 10675 X-reversed.vendor.dns_name.do_something= 10677 Keys with this format are used for private extension purposes. 10678 These keys always start with X- if unregistered with IANA 10679 (private). New public keys (if registered with IANA via an IETF 10680 Review, [RFC5226]) no longer have an X# name prefix requirement, 10681 implementers may propose any intuitive unique name. 10683 For unregistered keys, to identify the vendor, we suggest you use 10684 the reversed DNS-name as a prefix to the key-proper. 10686 The part of key-name following X- MUST conform to the format for 10687 key-name specified in Section 6.1-"Text Format". 10689 Vendor specific keys MUST ONLY be used in normal sessions. 10691 Support for public or private extension keys is OPTIONAL. 10693 13.23. TaskReporting 10695 Use: LO 10696 Senders: Initiator and Target 10697 Scope: SW 10698 Irrelevant when: SessionType=Discovery 10699 TaskReporting= 10700 Default is RFC3720. 10701 Result function is AND. 10703 This key is used to negotiate the task completion reporting 10704 semantics from the SCSI target. The following table describes the 10705 semantics that an iSCSI target MUST support for respective 10706 negotiated key values. Whenever this key is negotiated, at least 10707 the RFC3720 and ResponseFence values MUST be offered as options by 10708 the negotiation originator. 10709 +--------------+------------------------------------------+ 10710 | Name | Description | 10711 +--------------+------------------------------------------+ 10712 | RFC3720 | RFC 3720-compliant semantics. Response | 10713 | | fencing is not guaranteed and fast | 10714 | | completion of multi-task aborting is not | 10715 | | supported | 10716 +--------------+------------------------------------------+ 10717 | ResponseFence| Response Fence (Section 4.2.2.3.3) | 10718 | | semantics MUST be supported in reporting | 10719 | | task completions | 10720 +--------------+------------------------------------------+ 10721 | FastAbort | Updated fast multi-task abort semantics | 10722 | | defined in Section 4.2.3.4 MUST be | 10723 | | supported. Support for Response Fence is | 10724 | | implied -- i.e., (Section 4.2.2.3.3) | 10725 | | semantics MUST be supported as well | 10726 +--------------+------------------------------------------+ 10727 When TaskReporting is not negotiated to FastAbort, the standard 10728 multi-task abort semantics in Section 4.2.3.3 MUST be used. 10730 13.24. iSCSIProtocolLevel Negotiation 10732 The iSCSIProtocolLevel associated with this document is "1". As a 10733 responder or an originator in a negotiation of this key, an iSCSI 10734 implementation compliant to this document alone, without any 10735 future protocol extensions, MUST use this value as defined by the 10736 [iSCSI-SAM] document. 10737 13.25. Obsoleted Keys 10739 This document obsoletes the following keys defined in [RFC3720]: 10740 IFMarker, OFMarker, OFMarkInt, IFMarkInt. However, iSCSI 10741 implementations compliant to this document may still receive these 10742 obsoleted keys - i.e. in a responder role - in a text negotiation. 10744 When IFMarker or OFMarker key is received, a compliant iSCSI 10745 implementation SHOULD respond with the constant "Reject" value. 10746 The implementation MAY alternatively respond with a "No" value. 10747 However, the implementation MUST NOT respond with a 10748 "NotUnderstood" value for either of these keys. 10750 When IFMarkInt or OFMarkInt key is received, a compliant iSCSI 10751 implementation MUST respond with the constant "Reject" value. 10752 The implementation MUST NOT respond with a "NotUnderstood" value 10753 for either of these keys. 10755 13.26. X#NodeArchitecture 10757 13.26.1. Definition 10759 Use: LO, Declarative 10760 Senders: Initiator and Target 10761 Scope: SW 10763 X#NodeArchitecture= 10765 Default is none. 10767 Examples: 10768 X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a 10769 X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 10770 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 10772 This document does not define the structure or content of the list 10773 of values. 10775 The initiator or target declares the details of its iSCSI node 10776 architecture to the remote endpoint. These details may include, 10777 but are not limited to, iSCSI vendor software, firmware, or 10778 hardware versions, the OS version, or hardware architecture. This 10779 key may be declared on a Discovery session or a Normal session. 10781 The length of the key value (total length of the list-of-values) 10782 MUST NOT be greater than 255 bytes. 10784 X#NodeArchitecture MUST NOT be redeclared during the login phase. 10786 13.26.2. Implementation Requirements 10788 Functional behavior of the iSCSI node (this includes the iSCSI 10789 protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT 10790 depend on the presence, absence, or content of the 10791 X#NodeArchitecture key. The key MUST NOT be used by iSCSI nodes 10792 for interoperability, or exclusion of other nodes. To ensure 10793 proper use, key values SHOULD be set by the node itself, and there 10794 SHOULD NOT be provisions for the key values to contain user- 10795 defined text. 10797 Nodes implementing this key MUST choose one of the following 10798 implementation options: 10800 only transmit the key, 10801 only log the key values received from other nodes, or 10802 both transmit and log the key values. 10803 Each node choosing to implement transmission of the key values 10804 MUST be prepared to handle the response of iSCSI Nodes that do not 10805 understand the key. 10807 Nodes that implement transmission and/or logging of the key values 10808 may also implement administrative mechanisms that disable and/or 10809 change the logging and key transmission detail (see Section 9.4 - 10810 "Security Considerations for the X#NodeArchitecture Key"). Thus, a 10811 valid behavior for this key may be that a node is completely 10812 silent (the node does not transmit any key value, and simply 10813 discards any key values it receives without issuing a 10814 NotUnderstood response). 10816 14. Rationale for revised IANA Considerations 10818 This document makes rather significant changes in this area, and 10819 this section outlines the reasons behind the changes. As 10820 previously specified in [RFC3720], iSCSI had used text string 10821 prefixes, such as X- and X#, to distinguish extended login/text 10822 keys, digest algorithms and authentication methods from their 10823 standardized counterparts. Based on experience with other 10824 protocols, [RFC6648] however strongly recommends against this 10825 practice, in large part because extensions that use such prefixes 10826 may become standard over time at which point it can be infeasible 10827 to change their text string names due to widespread usage under 10828 the existing text string name. 10830 iSCSI's experience with public extensions supports the 10831 recommendations in [RFC6648], as the only extension item ever 10832 registered with IANA, the X#NodeArchitecture key, was specified as 10833 a standard key in a standards-track RFC [RFC 4850], and hence did 10834 not require the X# prefix. In addition, that key is the only 10835 public iSCSI extension that has been registered with IANA since 10836 RFC 3720 was originally published, so there has been effectively 10837 no use of the X#, Y# and Z# public extension formats. 10839 Therefore, this document makes the following changes to the IANA 10840 registration procedures for iSCSI: 10842 (1) The separate registries for X#, Y# and Z# public 10843 extensions are removed. The single entry in the registry for 10844 X# login/text keys(X#NodeArchitecture) is transferred to the 10845 main login/text key registry. IANA has never created the 10846 latter two registries because there have been no 10847 registration requests for them. These public extension 10848 formats (X#, Y#, Z#) MUST NOT be used with the exception of 10849 the existing X#NodeArchitecture key. 10851 (2) The Registration Procedures for the main login/text key, 10852 digest algorithm and authentication method IANA registries 10853 are changed to IETF Review [RFC5226] for possible future 10854 extensions to iSCSI. This change includes a deliberate 10855 decision to remove the possibility of specifying an IANA- 10856 registered iSCSI extension in an RFC published via an RFC 10858 Editor independent submission, as the level of review in 10859 that process is insufficient for iSCSI extensions. 10861 (3) The restriction against registering items using the 10862 private extension formats (X-, Y-, Z-) in the main IANA 10863 registries is removed. Extensions using these formats MAY be 10864 registered under the new IETF Review registration 10865 procedures, but each format is restricted to the type of 10866 extension for which it is specified in this RFC and MUST NOT 10867 be used for other types. For example, the X- extension 10868 format for extension login/text keys MUST NOT be used for 10869 digest algorithms or authentication methods. 10871 15. IANA Considerations 10873 The well-known TCP port number for iSCSI connections assigned by 10874 IANA is 3260 and this is the default iSCSI port. Implementations 10875 needing a system TCP port number may use port 860, the port 10876 assigned by IANA as the iSCSI system port; however in order to use 10877 port 860, it MUST be explicitly specified - implementations MUST 10878 NOT default to use of port 860, as 3260 is the only allowed 10879 default. 10881 IANA is requested to update all references to RFC 3720, RFC 4850 10882 and RFC 5048 to instead reference this RFC in all of the iSCSI 10883 registries that are part of the "Internet Small Computer System 10884 Interface (iSCSI) Parameters" set of registries. This change 10885 reflects the fact that those three RFCs are obsoleted by this RFC. 10886 References to other RFCs that are not being obsoleted (e.g., RFC 10887 3723, RFC 5046) should not be changed. 10889 IANA is requested to perform the following actions on the iSCSI 10890 Login/Text Keys registry: 10891 - Change the registration procedure to IETF Review from 10892 Standard Required. 10894 - Change the RFC 5048 reference for the registry to reference 10895 this RFC. 10897 - Add the X#NodeArchitecture Key from the iSCSI extended key 10898 registry and change its reference to this RFC. 10900 - Change all references of RFC 3720 and RFC 5048 to reference 10901 this RFC. 10903 IANA is requested to change the Registration Procedures for the 10904 iSCSI authentication methods and iSCSI digests registries to IETF 10905 Review from RFC Required. 10907 IANA is requested to remove the iSCSI extended key registry, as 10908 its one entry is to be added to the iSCSI login/text keys 10909 registry. 10911 All the other IANA considerations stated in [RFC3720] and 10912 [RFC5048] remain unchanged. 10914 This document obsoletes the SPKM1 and SPKM2 key values for the 10915 AuthMethod text key. Consequently, the SPKM_ text key prefix MUST 10916 be treated as obsolete and be not reused. 10918 IANA is requested to add the following entry to the "iSCSI 10919 Protocol Level" registry created by Section 9 of [iSCSI-SAM]: 10921 Assigned value: 1 10922 RFC Reference: [RFCyyyy] 10924 RFC Editor: Please replace yyyy in the above reference with the 10925 RFC number assigned to this document and remove this note. 10927 Expert Review of this assignment has been performed by David Black 10928 in his role as the T10 Liaison to IETF. The value 1 is part of 10929 the initial contents of this registry; for that reason, IANA is 10930 instructed to assign the value 1 as indicated above and apply the 10931 sequential assignment policy for this registry (as specified in 10932 [iSCSI-SAM]) to future assignments, starting with the value 3. 10934 References 10936 Normative References 10938 [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", 10939 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 10941 [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling 10942 Interface (FC-FS). 10944 [iSCSI-SAM] Knight, F., Chadalapaka, M., "Internet Small 10945 Computer Systems Interface (iSCSI) SCSI Architecture 10946 Features Update", draft-ietf-storm-iscsi-sam-05.txt (work in 10947 progress), December 2011 10949 [OUI] "IEEE OUI and Company_Id Assignments", 10950 http://standards.ieee.org/regauth/oui 10952 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 10953 June 1996. 10955 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", 10956 August 1996. 10958 [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication 10959 Protocol (CHAP)", August 1996. 10961 [RFC2045] N. Borenstein, N. Freed, "MIME (Multipurpose 10962 Internet Mail Extensions) Part One: Mechanisms for 10963 Specifying and Describing the Format of Internet Message 10964 Bodies", November 1996. 10966 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 10967 Requirement Levels", BCP 14, March 1997. 10969 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 10970 within ESP and AH", November 1998. 10972 [RFC2451] R. Pereira, R. Adams "The ESP CBC-Mode Cipher 10973 Algorithms". 10975 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange 10976 System", September 2000. 10978 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 10979 Internationalized Strings ("stringprep")", RFC 3454, 10980 December 2002. 10982 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 10983 Algorithm and Its Use With IPsec", RFC 3566, September 2003. 10985 [RFC3629] Yergeau, F., "UTF-8, a Transformation Format of ISO 10986 10646", RFC 3629, November 2003 10988 [RFC3686] Housley, R., "Using Advanced Encryption Standard 10989 (AES) Counter Mode with IPsec Encapsulating Security Payload 10990 (ESP)", RFC 3686, January 2004. 10992 [RFC3722] Bakke, M., "String Profile for Internet Small 10993 Computer Systems Interface (iSCSI) Names", RFC 3722, March 10994 2004. 10996 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. 10997 Travostino, "Securing Block Storage Protocols over IP", RFC 10998 3723, March 2004. 11000 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter "Uniform 11001 Resource Identifier (URI): Generic Syntax", January 2005. 11003 [RFC4106] J. Viega, D. McGrew, "The Use of Galois/Counter Mode 11004 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 11005 4106, June 2005. 11007 [RFC4120] Neuman, C., Yu, T., Hartman, S., Raeburn, K, "The 11008 Kerberos Network Authentication Service (V5)", RFC 4120, 11009 July 2005. 11011 [RFC4171] J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. 11012 Souza, "Internet Storage Name Service (iSNS)", September 11013 2005. 11015 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 11016 Architecture", February 2006. 11018 [RFC4301] S. Kent, K.Seo, "Security Architecture for the 11019 Internet Protocol", December 2005. 11021 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 11022 RFC 4303, December 2005 11024 [RFC4543] D. McGrew, J. Viega, "The Use of Galois Message 11025 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 11026 May 2006 11028 [RFC5226] D. McGrew, J. Viega, "Guidelines for Writing an IANA 11029 Considerations Section in RFCs", RFC 5226, May 2008 11031 [RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet 11032 Key Exchange Protocol Version 2 (IKEv2) ", RFC 5996, 11033 September 2010. 11035 [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). 11037 [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). 11039 [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). 11041 [SBC2] NCITS.405-205, SCSI Block Commands - 2 (SBC-2). 11043 [SPC3] T10/1416-D, SCSI Primary Commands-3. 11045 [UML] ISO/IEC 19501, Unified Modeling Language 11046 Specification Version 1.4.2. 11048 [UNICODE] Unicode Standard Annex #15, "Unicode Normalization 11049 Forms", http://www.unicode.org/unicode/reports/tr15 11051 Informative References 11053 [RFC1737] K. Sollins, L. Masinter "Functional Requirements for 11054 Uniform Resource Names". 11056 [IB] InfiniBand{tm} Architecture Specification, Vol. 1, 11057 Rel.1.0.a, InfiniBand 11058 TradezAssociation(http://www.infinibandta.org). 11060 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman 11061 "Optimization of Cyclic Redundancy-Check Codes with 24 and 11062 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, 11063 No. 6, June 1993. 11065 [CRC] ISO 3309, High-Level Data Link Control (CRC 32). 11067 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 11068 Internet Protocol ", November 1998. 11070 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security 11071 Payload (ESP)", November 1998. 11073 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange 11074 (IKE)", November 1998. 11076 [RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. 11077 Cavanna, "Internet Protocol Small Computer System Interface 11079 (iSCSI) Cyclic Redundancy Check (CRC)/Checksum 11080 Considerations", RFC 3385, September 2002. 11082 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 11083 M., and E. Zeidner, "Internet Small Computer Systems 11084 Interface (iSCSI)", RFC 3720, April 2004. 11086 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. 11087 and M. Krueger, "Internet Small Computer Systems Interface 11088 (iSCSI) Naming and Discovery", RFC 3721, March 2004 11090 [RFC3783] M. Chadalapaka, R. Elliott, "Small Computer Systems 11091 Interface (SCSI) Command Ordering Considerations with 11092 iSCSI", RFC 3783, May 2004. 11094 [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, 11095 "Remote Direct Memory Access (RDMA) over IP Problem 11096 Statement", RFC 4297, October 2004 11098 [RFC4850] Wysochanski, D., "Declarative Public Extension Key 11099 for Internet Small Computer Systems Interface (iSCSI) Node 11100 Architecture", RFC 4850, April 2007. 11102 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., 11103 Shah, H., and P. Thaler, "Internet Small Computer System 11104 Interface (iSCSI) Extensions for Remote Direct Memory Access 11105 (RDMA)", RFC 5046, October 2007 11107 [RFC5048] Chadalapaka, M., "Internet Small Computer Systems 11108 Interface (iSCSI) Corrections and Clarifications", RFC 5048, 11109 October 2007. 11111 [RFC6648] P. Saint-Andre, D. Crocker, M. Nottingham, 11112 "Deprecating the X- Prefix and Similar Constructs in 11113 Application Protocols", RFC 6648, June 2012 11115 [SAS] INCITS 376-2003, Serial Attached SCSI (SAS). 11117 [SRP] INCITS 365-2002, SCSI RDMA Protocol (SRP). 11119 Appendix A. Examples 11121 Read Operation Example 11123 +------------------+-----------------------+---------------------+ 11124 |Initiator Function| PDU Type | Target Function | 11125 +------------------+-----------------------+---------------------+ 11126 | Command request |SCSI Command (READ)>>> | | 11127 | (read) | | | 11128 +------------------+-----------------------+---------------------+ 11129 | | |Prepare Data Transfer| 11130 +------------------+-----------------------+---------------------+ 11131 | Receive Data | <<< SCSI Data-in | Send Data | 11132 +------------------+-----------------------+---------------------+ 11133 | Receive Data | <<< SCSI Data-in | Send Data | 11134 +------------------+-----------------------+---------------------+ 11135 | Receive Data | <<< SCSI Data-in | Send Data | 11136 +------------------+-----------------------+---------------------+ 11137 | | <<< SCSI Response |Send Status and Sense| 11138 +------------------+-----------------------+---------------------+ 11139 | Command Complete | | | 11140 +------------------+-----------------------+---------------------+ 11142 Write Operation Example 11144 +------------------+-----------------------+---------------------+ 11145 |Initiator Function| PDU Type | Target Function | 11146 +------------------+-----------------------+---------------------+ 11147 | Command request |SCSI Command (WRITE)>>>| Receive command | 11148 | (write) | | and queue it | 11149 +------------------+-----------------------+---------------------+ 11150 | | | Process old commands| 11151 +------------------+-----------------------+---------------------+ 11152 | | | Ready to process | 11153 | | <<< R2T | WRITE command | 11154 +------------------+-----------------------+---------------------+ 11155 | Send Data | SCSI Data-out >>> | Receive Data | 11156 +------------------+-----------------------+---------------------+ 11157 | | <<< R2T | Ready for data | 11158 +------------------+-----------------------+---------------------+ 11159 | | <<< R2T | Ready for data | 11160 +------------------+-----------------------+---------------------+ 11161 | Send Data | SCSI Data-out >>> | Receive Data | 11162 +------------------+-----------------------+---------------------+ 11163 | Send Data | SCSI Data-out >>> | Receive Data | 11164 +------------------+-----------------------+---------------------+ 11165 | | <<< SCSI Response |Send Status and Sense| 11166 +------------------+-----------------------+---------------------+ 11167 | Command Complete | | | 11168 +------------------+-----------------------+---------------------+ 11170 R2TSN/DataSN Use Examples 11172 Output (write) data DataSN/R2TSN Example 11173 +------------------+-----------------------+---------------------+ 11174 |Initiator Function| PDU Type & Content | Target Function | 11175 +------------------+-----------------------+---------------------+ 11176 | Command request |SCSI Command (WRITE)>>>| Receive command | 11177 | (write) | | and queue it | 11178 +------------------+-----------------------+---------------------+ 11179 | | | Process old commands| 11180 +------------------+-----------------------+---------------------+ 11181 | | <<< R2T | Ready for data | 11182 | | R2TSN = 0 | | 11183 +------------------+-----------------------+---------------------+ 11184 | | <<< R2T | Ready for more data | 11185 | | R2TSN = 1 | | 11186 +------------------+-----------------------+---------------------+ 11187 | Send Data | SCSI Data-out >>> | Receive Data | 11188 | for R2TSN 0 | DataSN = 0, F=0 | | 11189 +------------------+-----------------------+---------------------+ 11190 | Send Data | SCSI Data-out >>> | Receive Data | 11191 | for R2TSN 0 | DataSN = 1, F=1 | | 11192 +------------------+-----------------------+---------------------+ 11193 | Send Data | SCSI Data >>> | Receive Data | 11194 | for R2TSN 1 | DataSN = 0, F=1 | | 11195 +------------------+-----------------------+---------------------+ 11196 | | <<< SCSI Response |Send Status and Sense| 11197 | | ExpDataSN = 0 | | 11198 +------------------+-----------------------+---------------------+ 11199 | Command Complete | | | 11200 +------------------+-----------------------+---------------------+ 11202 Input (read) data DataSN Example 11204 +------------------+-----------------------+---------------------+ 11205 |Initiator Function| PDU Type | Target Function | 11206 +------------------+-----------------------+---------------------+ 11207 | Command request |SCSI Command (READ)>>> | | 11208 | (read) | | | 11209 +------------------+-----------------------+---------------------+ 11210 | | |Prepare Data Transfer| 11211 +------------------+-----------------------+---------------------+ 11212 | Receive Data | <<< SCSI Data-in | Send Data | 11213 | | DataSN = 0, F=0 | | 11214 +------------------+-----------------------+---------------------+ 11215 | Receive Data | <<< SCSI Data-in | Send Data | 11216 | | DataSN = 1, F=0 | | 11217 +------------------+-----------------------+---------------------+ 11218 | Receive Data | <<< SCSI Data-in | Send Data | 11219 | | DataSN = 2, F=1 | | 11220 +------------------+-----------------------+---------------------+ 11221 | | <<< SCSI Response |Send Status and Sense| 11222 | | ExpDataSN = 3 | | 11223 +------------------+-----------------------+---------------------+ 11224 | Command Complete | | | 11225 +------------------+-----------------------+---------------------+ 11227 Bidirectional DataSN Example 11229 +------------------+-----------------------+---------------------+ 11230 |Initiator Function| PDU Type | Target Function | 11231 +------------------+-----------------------+---------------------+ 11232 | Command request |SCSI Command >>> | | 11233 | (Read-Write) | Read-Write | | 11234 +------------------+-----------------------+---------------------+ 11235 | | | Process old commands| 11236 +------------------+-----------------------+---------------------+ 11237 | | <<< R2T | Ready to process | 11238 | | R2TSN = 0 | WRITE command | 11239 +------------------+-----------------------+---------------------+ 11240 | * Receive Data | <<< SCSI Data-in | Send Data | 11241 | | DataSN = 0, F=0 | | 11242 +------------------+-----------------------+---------------------+ 11243 | * Receive Data | <<< SCSI Data-in | Send Data | 11244 | | DataSN = 1, F=1 | | 11245 +------------------+-----------------------+---------------------+ 11246 | * Send Data | SCSI Data-out >>> | Receive Data | 11247 | for R2TSN 0 | DataSN = 0, F=1 | | 11248 +------------------+-----------------------+---------------------+ 11249 | | <<< SCSI Response |Send Status and Sense| 11250 | | ExpDataSN = 2 | | 11251 +------------------+-----------------------+---------------------+ 11252 | Command Complete | | | 11253 +------------------+-----------------------+---------------------+ 11255 *) Send data and Receive Data may be transferred simultaneously as 11256 in an atomic Read-Old-Write-New or sequentially as in an atomic 11257 Read-Update-Write (in the latter case the R2T may follow the 11258 received data). 11260 Unsolicited and immediate output (write) data with DataSN Example 11261 +------------------+-----------------------+---------------------+ 11262 |Initiator Function| PDU Type & Content | Target Function | 11263 +------------------+-----------------------+---------------------+ 11264 | Command request |SCSI Command (WRITE)>>>| Receive command | 11265 | (write) |F=0 | and data | 11266 |+ immediate data | | and queue it | 11267 +------------------+-----------------------+---------------------+ 11268 | Send Unsolicited | SCSI Write Data >>> | Receive more Data | 11269 | Data | DataSN = 0, F=1 | | 11270 +------------------+-----------------------+---------------------+ 11271 | | | Process old commands| 11272 +------------------+-----------------------+---------------------+ 11273 | | <<< R2T | Ready for more data | 11274 | | R2TSN = 0 | | 11275 +------------------+-----------------------+---------------------+ 11276 | Send Data | SCSI Write Data >>> | Receive Data | 11277 | for R2TSN 0 | DataSN = 0, F=1 | | 11278 +------------------+-----------------------+---------------------+ 11279 | | <<< SCSI Response |Send Status and Sense| 11280 | | | | 11281 +------------------+-----------------------+---------------------+ 11282 | Command Complete | | | 11283 +------------------+-----------------------+---------------------+ 11285 CRC Examples 11287 N.B. all Values are Hexadecimal 11289 32 bytes of zeroes: 11291 Byte: 0 1 2 3 11293 0: 00 00 00 00 11294 ... 11295 28: 00 00 00 00 11297 CRC: aa 36 91 8a 11299 32 bytes of ones: 11301 Byte: 0 1 2 3 11302 0: ff ff ff ff 11303 ... 11304 28: ff ff ff ff 11306 CRC: 43 ab a8 62 11308 32 bytes of incrementing 00..1f: 11310 Byte: 0 1 2 3 11312 0: 00 01 02 03 11313 ... 11314 28: 1c 1d 1e 1f 11316 CRC: 4e 79 dd 46 11318 32 bytes of decrementing 1f..00: 11320 Byte: 0 1 2 3 11322 0: 1f 1e 1d 1c 11323 ... 11324 28: 03 02 01 00 11326 CRC: 5c db 3f 11 11328 An iSCSI - SCSI Read (10) Command PDU 11330 Byte: 0 1 2 3 11332 0: 01 c0 00 00 11333 4: 00 00 00 00 11334 8: 00 00 00 00 11335 12: 00 00 00 00 11336 16: 14 00 00 00 11337 20: 00 00 04 00 11338 24: 00 00 00 14 11339 28: 00 00 00 18 11340 32: 28 00 00 00 11341 36: 00 00 00 00 11342 40: 02 00 00 00 11343 44: 00 00 00 00 11345 CRC: 56 3a 96 d9 11347 Appendix B. Login Phase Examples 11349 In the first example, the initiator and target authenticate each 11350 other via Kerberos: 11352 I-> Login (CSG,NSG=0,1 T=1) 11353 InitiatorName=iqn.1999-07.com.os:hostid.77 11354 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11355 AuthMethod=KRB5,SRP,None 11357 T-> Login (CSG,NSG=0,0 T=0) 11358 AuthMethod=KRB5 11360 I-> Login (CSG,NSG=0,1 T=1) 11361 KRB_AP_REQ= 11363 (krb_ap_req contains the Kerberos V5 ticket and authenticator with 11364 MUTUAL-REQUIRED set in the ap-options field) 11366 If the authentication is successful, the target proceeds with: 11368 T-> Login (CSG,NSG=0,1 T=1) 11369 KRB_AP_REP= 11371 (krb_ap_rep is the Kerberos V5 mutual authentication reply) 11373 If the authentication is successful, the initiator may proceed 11374 with: 11376 I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192 11377 T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096 11378 MaxBurstLength=8192 11379 I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192 11380 ... more iSCSI Operational Parameters 11382 T-> Login (CSG,NSG=1,0 T=0) 11383 ... more iSCSI Operational Parameters 11385 And at the end: 11387 I-> Login (CSG,NSG=1,3 T=1) 11388 optional iSCSI parameters 11390 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11392 If the initiator's authentication by the target is not successful, 11393 the target responds with: 11395 T-> Login "login reject" 11397 instead of the Login KRB_AP_REP message, and terminates the 11398 connection. 11400 If the target's authentication by the initiator is not successful, 11401 the initiator terminates the connection (without responding to the 11402 Login KRB_AP_REP message). 11404 In the next example only the initiator is authenticated by the 11405 target via Kerberos: 11407 I-> Login (CSG,NSG=0,1 T=1) 11408 InitiatorName=iqn.1999-07.com.os:hostid.77 11409 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11410 AuthMethod=SRP,KRB5,None 11412 T-> Login-PR (CSG,NSG=0,0 T=0) 11413 AuthMethod=KRB5 11415 I-> Login (CSG,NSG=0,1 T=1) 11416 KRB_AP_REQ=krb_ap_req 11418 (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req) 11420 If the authentication is successful, the target proceeds with: 11422 T-> Login (CSG,NSG=0,1 T=1) 11424 I-> Login (CSG,NSG=1,0 T=0) 11425 ... iSCSI parameters 11427 T-> Login (CSG,NSG=1,0 T=0) 11428 ... iSCSI parameters 11430 . . . 11432 T-> Login (CSG,NSG=1,3 T=1)"login accept" 11434 In the next example, the initiator and target authenticate each 11435 other via SRP: 11437 I-> Login (CSG,NSG=0,1 T=1) 11438 InitiatorName=iqn.1999-07.com.os:hostid.77 11439 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11440 AuthMethod=KRB5,SRP,None 11442 T-> Login-PR (CSG,NSG=0,0 T=0) 11443 AuthMethod=SRP 11445 I-> Login (CSG,NSG=0,0 T=0) 11446 SRP_U= 11447 TargetAuth=Yes 11449 T-> Login (CSG,NSG=0,0 T=0) 11450 SRP_N= 11451 SRP_g= 11452 SRP_s= 11454 I-> Login (CSG,NSG=0,0 T=0) 11455 SRP_A= 11457 T-> Login (CSG,NSG=0,0 T=0) 11458 SRP_B= 11460 I-> Login (CSG,NSG=0,1 T=1) 11461 SRP_M= 11463 If the initiator authentication is successful, the target 11464 proceeds: 11466 T-> Login (CSG,NSG=0,1 T=1) 11467 SRP_HM= 11469 Where N, g, s, A, B, M, and H(A | M | K) are defined in 11470 [RFC2945]. 11472 If the target authentication is not successful, the initiator 11473 terminates the connection; otherwise, it proceeds. 11475 I-> Login (CSG,NSG=1,0 T=0) 11476 ... iSCSI parameters 11478 T-> Login (CSG,NSG=1,0 T=0) 11479 ... iSCSI parameters 11481 And at the end: 11483 I-> Login (CSG,NSG=1,3 T=1) 11484 optional iSCSI parameters 11486 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11488 If the initiator authentication is not successful, the target 11489 responds with: 11491 T-> Login "login reject" 11493 Instead of the T-> Login SRP_HM= message and 11494 terminates the connection. 11496 In the next example, only the initiator is authenticated by the 11497 target via SRP: 11499 I-> Login (CSG,NSG=0,1 T=1) 11500 InitiatorName=iqn.1999-07.com.os:hostid.77 11501 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11502 AuthMethod=KRB5,SRP,None 11504 T-> Login-PR (CSG,NSG=0,0 T=0) 11505 AuthMethod=SRP 11507 I-> Login (CSG,NSG=0,0 T=0) 11508 SRP_U= 11509 TargetAuth=No 11511 T-> Login (CSG,NSG=0,0 T=0) 11512 SRP_N= 11513 SRP_g= 11514 SRP_s= 11516 I-> Login (CSG,NSG=0,0 T=0) 11517 SRP_A= 11519 T-> Login (CSG,NSG=0,0 T=0) 11520 SRP_B= 11522 I-> Login (CSG,NSG=0,1 T=1) 11523 SRP_M= 11525 If the initiator authentication is successful, the target 11526 proceeds: 11528 T-> Login (CSG,NSG=0,1 T=1) 11530 I-> Login (CSG,NSG=1,0 T=0) 11532 ... iSCSI parameters 11534 T-> Login (CSG,NSG=1,0 T=0) 11536 ... iSCSI parameters 11538 And at the end: 11540 I-> Login (CSG,NSG=1,3 T=1) 11542 optional iSCSI parameters 11544 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11546 In the next example the initiator and target authenticate each 11547 other via CHAP: 11549 I-> Login (CSG,NSG=0,0 T=0) 11551 InitiatorName=iqn.1999-07.com.os:hostid.77 11553 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11555 AuthMethod=KRB5,CHAP,None 11557 T-> Login-PR (CSG,NSG=0,0 T=0) 11559 AuthMethod=CHAP 11561 I-> Login (CSG,NSG=0,0 T=0) 11563 CHAP_A= 11565 T-> Login (CSG,NSG=0,0 T=0) 11566 CHAP_A= 11567 CHAP_I= 11568 CHAP_C= 11570 I-> Login (CSG,NSG=0,1 T=1) 11572 CHAP_N= 11574 CHAP_R= 11576 CHAP_I= 11578 CHAP_C= 11580 If the initiator authentication is successful, the target 11581 proceeds: 11583 T-> Login (CSG,NSG=0,1 T=1) 11585 CHAP_N= 11587 CHAP_R= 11589 If the target authentication is not successful, the initiator 11590 aborts the connection; otherwise, it proceeds. 11592 I-> Login (CSG,NSG=1,0 T=0) 11594 ... iSCSI parameters 11596 T-> Login (CSG,NSG=1,0 T=0) 11598 ... iSCSI parameters 11600 And at the end: 11602 I-> Login (CSG,NSG=1,3 T=1) 11604 optional iSCSI parameters 11606 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11608 If the initiator authentication is not successful, the target 11609 responds with: 11611 T-> Login "login reject" 11613 Instead of the Login CHAP_R= "proceed and change 11614 stage" message and terminates the connection. 11616 In the next example, only the initiator is authenticated by the 11617 target via CHAP: 11619 I-> Login (CSG,NSG=0,1 T=0) 11621 InitiatorName=iqn.1999-07.com.os:hostid.77 11623 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11625 AuthMethod=KRB5,CHAP,None 11627 T-> Login-PR (CSG,NSG=0,0 T=0) 11629 AuthMethod=CHAP 11631 I-> Login (CSG,NSG=0,0 T=0) 11633 CHAP_A= 11635 T-> Login (CSG,NSG=0,0 T=0) 11636 CHAP_A= 11637 CHAP_I= 11638 CHAP_C= 11640 I-> Login (CSG,NSG=0,1 T=1) 11642 CHAP_N= 11644 CHAP_R= 11646 If the initiator authentication is successful, the target 11647 proceeds: 11649 T-> Login (CSG,NSG=0,1 T=1) 11651 I-> Login (CSG,NSG=1,0 T=0) 11653 ... iSCSI parameters 11655 T-> Login (CSG,NSG=1,0 T=0) 11657 ... iSCSI parameters 11659 And at the end: 11661 I-> Login (CSG,NSG=1,3 T=1) 11663 optional iSCSI parameters 11665 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11667 In the next example, the initiator does not offer any security 11668 parameters. It therefore may offer iSCSI parameters on the Login 11669 PDU with the T bit set to 1, and the target may respond with a 11670 final Login Response PDU immediately: 11672 I-> Login (CSG,NSG=1,3 T=1) 11674 InitiatorName=iqn.1999-07.com.os:hostid.77 11676 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11678 ... iSCSI parameters 11680 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11682 ... ISCSI parameters 11684 In the next example, the initiator does offer security 11685 parameters on the Login PDU, but the target does not choose 11686 any (i.e., chooses the "None" values): 11688 I-> Login (CSG,NSG=0,1 T=1) 11690 InitiatorName=iqn.1999-07.com.os:hostid.77 11692 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11694 AuthMethod=KRB5,SRP,None 11696 T-> Login-PR (CSG,NSG=0,1 T=1) 11698 AuthMethod=None 11700 I-> Login (CSG,NSG=1,0 T=0) 11702 ... iSCSI parameters 11704 T-> Login (CSG,NSG=1,0 T=0) 11706 ... iSCSI parameters 11708 And at the end: 11710 I-> Login (CSG,NSG=1,3 T=1) 11712 optional iSCSI parameters 11714 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11716 Appendix C. SendTargets Operation 11718 The text in this Appendix is a normative part of this document. 11720 To reduce the amount of configuration required on an initiator, 11721 iSCSI provides the SendTargets text request. The initiator uses 11722 the SendTargets request to get a list of targets to which it may 11723 have access, as well as the list of addresses (IP address and TCP 11724 port) on which these targets may be accessed. 11726 To make use of SendTargets, an initiator must first establish one 11727 of two types of sessions. If the initiator establishes 11728 the session using the key "SessionType=Discovery", the session is 11729 a discovery session, and a target name does not need to be 11730 specified. Otherwise, the session is a normal, operational 11731 session. The SendTargets command MUST only be sent during the 11732 Full Feature Phase of a normal or discovery session. 11734 A system that contains targets MUST support discovery sessions on 11735 each of its iSCSI IP address-port pairs, and MUST support the 11736 SendTargets command on the discovery session. In a discovery 11737 session, a target MUST return all path information (IP address- 11738 port pairs and portal group tags) for the targets on the target 11739 network entity which the requesting initiator is authorized to 11740 access. 11742 A target MUST support the SendTargets command on operational 11743 sessions; these will only return path information about the target 11744 to which the session is connected, and do not need to return 11745 information about other target names that may be defined in the 11746 responding system. 11748 An initiator MAY make use of the SendTargets as it sees fit. 11750 A SendTargets command consists of a single Text request PDU. 11751 This PDU contains exactly one text key and value. The text key 11752 MUST be SendTargets. The expected response depends upon the 11753 value, as well as whether the session is a discovery or 11754 operational session. 11756 The value must be one of: 11758 All 11760 The initiator is requesting that information on all relevant 11761 targets known to the implementation be returned. This value 11762 MUST be supported on a discovery session, and MUST NOT be 11763 supported on an operational session. 11765 11767 If an iSCSI target name is specified, the session should 11768 respond with addresses for only the named target, if 11769 possible. This value MUST be supported on discovery 11770 sessions. A discovery session MUST be capable of returning 11771 addresses for those targets that would have been returned 11772 had value=All been designated. 11774 11776 The session should only respond with addresses for the target 11777 to which the session is logged in. This MUST be supported 11778 on operational sessions, and MUST NOT return targets other 11779 than the one to which the session is logged in. 11781 The response to this command is a text response that contains a 11782 list of zero or more targets and, optionally, their addresses. 11783 Each target is returned as a target record. A target record 11784 begins with the TargetName text key, followed by a list of 11785 TargetAddress text keys, and bounded by the end of the text 11786 response or the next TargetName key, which begins a new record. 11787 No text keys other than TargetName and TargetAddress are permitted 11788 within a SendTargets response. 11790 For the format of the TargetName, see Section 13.4 - "TargetName". 11792 A discovery session MAY respond to a SendTargets request with its 11793 complete list of targets, or with a list of targets that is based 11794 on the name of the initiator logged in to the session. 11796 A SendTargets response MUST NOT contain target names if there are 11797 no targets for the requesting initiator to access. 11799 Each target record returned includes zero or more TargetAddress 11800 fields. 11802 Each target record starts with one text key of the form: 11804 TargetName= 11806 Followed by zero or more address keys of the form: 11808 TargetAddress=[:], 11811 The hostname-or-ipaddress contains a domain name, IPv4 address, or 11812 IPv6 address ([RFC4291]), as specified for the TargetAddress key. 11814 A hostname-or-ipaddress duplicated in TargetAddress responses for 11815 a given node (the port is absent or equal) would probably indicate 11816 that multiple address families are in use at once (IPv6 and IPv4). 11818 Each TargetAddress belongs to a portal group, identified by its 11819 numeric portal group tag (as in Section 13.9- 11820 "TargetPortalGroupTag"). The iSCSI target name, together with this 11821 tag, constitutes the SCSI port identifier; the tag only needs to 11822 be unique within a given target's name list of addresses. 11824 Multiple-connection sessions can span iSCSI addresses that belong 11825 to the same portal group. 11827 Multiple-connection sessions cannot span iSCSI addresses that 11828 belong to different portal groups. 11830 If a SendTargets response reports an iSCSI address for a target, 11831 it SHOULD also report all other addresses in its portal group in 11832 the same response. 11834 A SendTargets text response can be longer than a single Text 11835 Response PDU, and makes use of the long text responses as 11836 specified. 11838 After obtaining a list of targets from the discovery target 11839 session, 11840 an iSCSI initiator may initiate new sessions to log in to the 11841 discovered targets for full operation. The initiator MAY keep the 11842 discovery session open, and MAY send subsequent SendTargets 11843 commands to discover new targets. 11845 Examples: 11847 This example is the SendTargets response from a single target that 11848 has no other interface ports. 11850 Initiator sends text request that contains: 11852 SendTargets=All 11854 Target sends a text response that contains: 11856 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11858 All the target had to return in the simple case was the target 11859 name. It is assumed by the initiator that the IP address and TCP 11860 port for this target are the same as used on the current 11861 connection to the default iSCSI target. 11863 The next example has two internal iSCSI targets, each accessible 11864 via two different ports with different IP addresses. The 11865 following is the text response: 11867 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11869 TargetAddress=10.1.0.45:3000,1 11871 TargetAddress=10.1.1.45:3000,2 11873 TargetName=iqn.1993-11.com.example:diskarray.sn.1234567 11875 TargetAddress=10.1.0.45:3000,1 11877 TargetAddress=10.1.1.45:3000,2 11879 Both targets share both addresses; the multiple addresses are 11880 likely used to provide multi-path support. The initiator may 11881 connect to either target name on either address. Each of the 11882 addresses has its own portal group tag; they do not support 11883 spanning multiple-connection sessions with each other. Keep in 11884 mind that the portal group tags for the two named targets are 11885 independent of one another; portal group "1" on the first target 11886 is not necessarily the same as portal group "1" on the second 11887 target. 11889 In the above example, a DNS host name or an IPv6 address could 11890 have been returned instead of an IPv4 address. 11892 The next text response shows a target that supports spanning 11893 sessions across multiple addresses, and further illustrates the 11894 use of the portal group tags: 11896 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11898 TargetAddress=10.1.0.45:3000,1 11900 TargetAddress=10.1.1.46:3000,1 11902 TargetAddress=10.1.0.47:3000,2 11904 TargetAddress=10.1.1.48:3000,2 11906 TargetAddress=10.1.1.49:3000,3 11908 In this example, any of the target addresses can be used to reach 11909 the same target. A single-connection session can be established 11910 to any of these TCP addresses. A multiple-connection session 11911 could span addresses .45 and .46 or .47 and .48, but cannot span 11912 any other combination. A TargetAddress with its own tag (.49) 11913 cannot be combined with any other address within the same session. 11915 This SendTargets response does not indicate whether .49 supports 11916 multiple connections per session; it is communicated via the 11917 MaxConnections text key upon login to the target. 11919 Appendix D. Algorithmic Presentation of Error Recovery Classes 11920 This appendix illustrates the error recovery classes using a 11921 pseudo-programming-language. The procedure names are chosen to be 11922 obvious to most implementers. Each of the recovery classes 11923 described has initiator procedures as well as target procedures. 11924 These algorithms focus on outlining the mechanics of error 11925 recovery classes, and do not exhaustively describe all other 11926 aspects/cases. Examples of this approach are: 11928 - Handling for only certain Opcode types is shown. 11930 - Only certain reason codes (e.g., Recovery in Logout command) 11931 are outlined. 11933 - Resultant cases, such as recovery of Synchronization on a 11934 header digest error are considered out-of-scope in these 11935 algorithms. In this particular example, a header digest 11936 error may lead to connection recovery if some type of sync 11937 and steering layer is not implemented. 11939 These algorithms strive to convey the iSCSI error recovery 11940 concepts in the simplest terms, and are not designed to be 11941 optimal. 11943 D.1. General Data Structure and 11944 Procedure Description 11946 This Section defines the procedures and data structures that are 11947 commonly used by all the error recovery algorithms. The structures 11948 may not be the exhaustive representations of what is required for 11949 a typical implementation. 11951 Data structure definitions - 11952 struct TransferContext { 11953 int TargetTransferTag; 11954 int ExpectedDataSN; 11955 }; 11957 struct TCB { /* task control block */ 11958 Boolean SoFarInOrder; 11959 int ExpectedDataSN; /* used for both R2Ts, and Data */ 11960 int MissingDataSNList[MaxMissingDPDU]; 11961 Boolean FbitReceived; 11962 Boolean StatusXferd; 11963 Boolean CurrentlyAllegiant; 11964 int ActiveR2Ts; 11965 int Response; 11966 char *Reason; 11967 struct TransferContext 11968 TransferContextList[MaxOutStandingR2T]; 11969 int InitiatorTaskTag; 11970 int CmdSN; 11971 int SNACK_Tag; 11972 }; 11974 struct Connection { 11975 struct Session SessionReference; 11976 Boolean SoFarInOrder; 11977 int CID; 11978 int State; 11979 int CurrentTimeout; 11980 int ExpectedStatSN; 11981 int MissingStatSNList[MaxMissingSPDU]; 11982 Boolean PerformConnectionCleanup; 11983 }; 11985 struct Session { 11986 int NumConnections; 11987 int CmdSN; 11988 int Maxconnections; 11989 int ErrorRecoveryLevel; 11990 struct iSCSIEndpoint OtherEndInfo; 11991 struct Connection ConnectionList[MaxSupportedConns]; 11992 }; 11994 Procedure descriptions - 11995 Receive-a-In-PDU(transport connection, inbound PDU); 11996 check-basic-validity(inbound PDU); 11997 Start-Timer(timeout handler, argument, timeout value); 11998 Build-And-Send-Reject(transport connection, bad PDU, reason 11999 code); 12000 D.2. Within-command Error Recovery 12001 Algorithms 12003 D.2.1. Procedure Descriptions 12005 Recover-Data-if-Possible(last required DataSN, task control 12006 block); 12007 Build-And-Send-DSnack(task control block); 12008 Build-And-Send-RDSnack(task control block); 12009 Build-And-Send-Abort(task control block); 12010 SCSI-Task-Completion(task control block); 12011 Build-And-Send-A-Data-Burst(transport connection, data- 12012 descriptor, 12013 task control 12014 block); 12015 Build-And-Send-R2T(transport connection, data-descriptor, 12016 task control 12017 block); 12018 Build-And-Send-Status(transport connection, task control block); 12019 Transfer-Context-Timeout-Handler(transfer context); 12021 Notes: 12023 - One procedure used in this section: Handle-Status-SNACK- 12024 request is defined in Within-connection recovery algorithms. 12026 - The Response processing pseudo-code, shown in the target 12027 algorithms, applies to all solicited PDUs that carry StatSN 12028 - SCSI Response, Text Response etc. 12030 D.2.2. Initiator Algorithms 12032 Recover-Data-if-Possible(LastRequiredDataSN, TCB) 12033 { 12034 if (operational ErrorRecoveryLevel > 0) { 12035 if (# of missing PDUs is trackable) { 12036 Note the missing DataSNs in TCB. 12037 if (the task spanned a change in 12038 MaxRecvDataSegmentLength) { 12040 if (TCB.StatusXferd is TRUE) 12041 drop the status PDU; 12042 Build-And-Send-RDSnack(TCB); 12043 } else { 12044 Build-And-Send-DSnack(TCB); 12045 } 12046 } else { 12047 TCB.Reason = "Protocol service CRC error"; 12048 } 12049 } else { 12050 TCB.Reason = "Protocol service CRC error"; 12051 } 12052 if (TCB.Reason == "Protocol service CRC error") { 12053 Clear the missing PDU list in the TCB. 12054 if (TCB.StatusXferd is not TRUE) 12055 Build-And-Send-Abort(TCB); 12056 } 12057 } 12059 Receive-a-In-PDU(Connection, CurrentPDU) 12060 { 12061 check-basic-validity(CurrentPDU); 12062 if (Header-Digest-Bad) discard, return; 12063 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12064 if ((CurrentPDU.type == Data) 12065 or (CurrentPDU.type = R2T)) { 12066 if (Data-Digest-Bad for Data) { 12067 send-data-SNACK = TRUE; 12068 LastRequiredDataSN = CurrentPDU.DataSN; 12069 } else { 12070 if (TCB.SoFarInOrder = TRUE) { 12071 if (current DataSN is expected) { 12072 Increment TCB.ExpectedDataSN. 12073 } else { 12074 TCB.SoFarInOrder = FALSE; 12075 send-data-SNACK = TRUE; 12076 } 12077 } else { 12078 if (current DataSN was considered 12079 missing) { 12080 remove current DataSN from missing 12081 PDU list. 12082 } else if (current DataSN is higher than 12083 expected) { 12084 send-data-SNACK = TRUE; 12085 } else { 12086 discard, return; 12087 } 12088 Adjust TCB.ExpectedDataSN if 12089 appropriate. 12090 } 12091 LastRequiredDataSN = CurrentPDU.DataSN - 1; 12092 } 12093 if (send-data-SNACK is TRUE and 12094 task is not already considered failed) { 12095 Recover-Data-if-Possible(LastRequiredDataSN, TCB); 12096 } 12097 if (missing data PDU list is empty) { 12098 TCB.SoFarInOrder = TRUE; 12099 } 12100 if (CurrentPDU.type == R2T) { 12101 Increment ActiveR2Ts for this task. 12102 Create a data-descriptor for the data burst. 12103 Build-And-Send-A-Data-Burst(Connection, data- 12104 descriptor, 12105 TCB); 12106 } 12107 } else if (CurrentPDU.type == Response) { 12108 if (Data-Digest-Bad) { 12109 send-status-SNACK = TRUE; 12110 } else { 12111 TCB.StatusXferd = TRUE; 12112 Store the status information in TCB. 12113 if (ExpDataSN does not match) { 12114 TCB.SoFarInOrder = FALSE; 12115 Recover-Data-if-Possible(current DataSN, TCB); 12116 } 12117 if (missing data PDU list is empty) { 12118 TCB.SoFarInOrder = TRUE; 12119 } 12121 } 12122 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 12123 SHOWN */ 12124 } 12125 if ((TCB.SoFarInOrder == TRUE) and 12126 (TCB.StatusXferd == TRUE)) { 12127 SCSI-Task-Completion(TCB); 12128 } 12129 } 12131 D.2.3. Target Algorithms 12133 Receive-a-In-PDU(Connection, CurrentPDU) 12134 { 12135 check-basic-validity(CurrentPDU); 12136 if (Header-Digest-Bad) discard, return; 12137 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12138 if (CurrentPDU.type == Data) { 12139 Retrieve TContext from CurrentPDU.TargetTransferTag; 12140 if (Data-Digest-Bad) { 12141 Build-And-Send-Reject(Connection, CurrentPDU, 12142 Payload-Digest-Error); 12143 Note the missing data PDUs in MissingDataRange[]. 12144 send-recovery-R2T = TRUE; 12145 } else { 12146 if (current DataSN is not expected) { 12147 Note the missing data PDUs in MissingDataRange[]. 12148 send-recovery-R2T = TRUE; 12149 } 12150 if (CurrentPDU.Fbit == TRUE) { 12151 if (current PDU is solicited) { 12152 Decrement TCB.ActiveR2Ts. 12153 } 12154 if ((current PDU is unsolicited and 12155 data received is less than I/O length and 12156 data received is less than 12157 FirstBurstLength) 12158 or (current PDU is solicited and the length of 12159 this burst is less than expected)) { 12160 send-recovery-R2T = TRUE; 12161 Note the missing data in MissingDataRange[]. 12162 } 12163 } 12164 } 12165 Increment TContext.ExpectedDataSN. 12166 if (send-recovery-R2T is TRUE and 12167 task is not already considered failed) { 12168 if (operational ErrorRecoveryLevel > 0) { 12169 Increment TCB.ActiveR2Ts. 12170 Create a data-descriptor for the data burst 12171 from MissingDataRange. 12172 Build-And-Send-R2T(Connection, data-descriptor, 12173 TCB); 12174 } else { 12175 if (current PDU is the last unsolicited) 12176 TCB.Reason = "Not enough unsolicited data"; 12177 else 12178 TCB.Reason = "Protocol service CRC error"; 12179 } 12180 } 12181 if (TCB.ActiveR2Ts == 0) { 12182 Build-And-Send-Status(Connection, TCB); 12183 } 12184 } else if (CurrentPDU.type == SNACK) { 12185 snack-failure = FALSE; 12186 if (operational ErrorRecoveryLevel > 0) { 12187 if (CurrentPDU.type == Data/R2T) { 12188 if (the request is satisfiable) { 12189 if (request for Data) { 12190 Create a data-descriptor for the data burst 12191 from BegRun and RunLength. 12192 Build-And-Send-A-Data-Burst(Connection, 12193 data-descriptor, TCB); 12194 } else { /* R2T */ 12195 Create a data-descriptor for the data burst 12196 from BegRun and RunLength. 12197 Build-And-Send-R2T(Connection, data- 12198 descriptor, 12199 TCB); 12200 } 12201 } else { 12202 snack-failure = TRUE; 12203 } 12204 } else if (CurrentPDU.type == status) { 12205 Handle-Status-SNACK-request(Connection, 12206 CurrentPDU); 12207 } else if (CurrentPDU.type == DataACK) { 12208 Consider all data upto CurrentPDU.BegRun as 12209 acknowledged. 12210 Free up the retransmission resources for that data. 12211 } else if (CurrentPDU.type == R-Data SNACK) { 12212 Create a data descriptor for a data burst 12213 covering 12214 all unacknowledged data. 12215 Build-And-Send-A-Data-Burst(Connection, 12216 data-descriptor, TCB); 12217 TCB.SNACK_Tag = CurrentPDU.SNACK_Tag; 12218 if (there's no more data to send) { 12219 Build-And-Send-Status(Connection, TCB); 12220 } 12221 } 12222 } else { /* operational ErrorRecoveryLevel = 0 */ 12223 snack-failure = TRUE; 12224 } 12225 if (snack-failure == TRUE) { 12226 Build-And-Send-Reject(Connection, CurrentPDU, 12227 SNACK-Reject); 12228 if (TCB.StatusXferd != TRUE) { 12229 TCB.Reason = "SNACK Rejected"; 12230 Build-And-Send-Status(Connection, TCB); 12231 } 12232 } 12234 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 12235 SHOWN */ 12236 } 12237 } 12239 Transfer-Context-Timeout-Handler(TContext) 12240 { 12241 Retrieve TCB and Connection from TContext. 12242 Decrement TCB.ActiveR2Ts. 12244 if (operational ErrorRecoveryLevel > 0 and 12245 task is not already considered failed) { 12246 Note the missing data PDUs in MissingDataRange[]. 12247 Create a data-descriptor for the data burst 12248 from MissingDataRange[]. 12249 Build-And-Send-R2T(Connection, data-descriptor, TCB); 12250 } else { 12251 TCB.Reason = "Protocol service CRC error"; 12252 if (TCB.ActiveR2Ts = 0) { 12253 Build-And-Send-Status(Connection, TCB); 12254 } 12255 } 12256 } 12258 D.3. Within-connection Recovery 12259 Algorithms 12261 D.3.1. Procedure Descriptions 12263 Procedure descriptions: 12264 Recover-Status-if-Possible(transport connection, 12265 currently received PDU); 12266 Evaluate-a-StatSN(transport connection, currently received PDU); 12267 Retransmit-Command-if-Possible(transport connection, CmdSN); 12268 Build-And-Send-SSnack(transport connection); 12269 Build-And-Send-Command(transport connection, task control 12270 block); 12271 Command-Acknowledge-Timeout-Handler(task control block); 12272 Status-Expect-Timeout-Handler(transport connection); 12273 Build-And-Send-Nop-Out(transport connection); 12274 Handle-Status-SNACK-request(transport connection, status SNACK 12275 PDU); 12276 Retransmit-Status-Burst(status SNACK, task control block); 12277 Is-Acknowledged(beginning StatSN, run length); 12279 Implementation-specific tunables: 12280 InitiatorProactiveSNACKEnabled 12282 Notes: 12283 - The initiator algorithms only deal with unsolicited Nop-In 12284 PDUs for generating status SNACKs. A solicited Nop-In PDU 12285 has an assigned StatSN, which, when out of order, could 12286 trigger the out of order StatSN handling in Within-command 12287 algorithms, again leading to Recover-Status-if-Possible. 12289 - The pseudo-code shown may result in the retransmission of 12290 unacknowledged commands in more cases than necessary. This 12291 will not, however, affect the correctness of the operation 12292 because the target is required to discard the duplicate 12293 CmdSNs. 12295 - The procedure Build-And-Send-Async is defined in the 12296 Connection recovery algorithms. 12298 - The procedure Status-Expect-Timeout-Handler describes how 12299 initiators may proactively attempt to retrieve the Status if 12300 they so choose. This procedure is assumed to be triggered 12301 much before the standard ULP timeout. 12303 D.3.2. Initiator Algorithms 12305 Recover-Status-if-Possible(Connection, CurrentPDU) 12306 { 12307 if ((Connection.state == LOGGED_IN) and 12308 connection is not already considered 12309 failed) { 12310 if (operational ErrorRecoveryLevel > 0) { 12311 if (# of missing PDUs is trackable) { 12312 Note the missing StatSNs in Connection 12313 that were not already requested with SNACK; 12314 Build-And-Send-SSnack(Connection); 12315 } else { 12316 Connection.PerformConnectionCleanup = TRUE; 12317 } 12318 } else { 12319 Connection.PerformConnectionCleanup = TRUE; 12321 } 12322 if (Connection.PerformConnectionCleanup == TRUE) { 12323 Start-Timer(Connection-Cleanup-Handler, Connection, 12324 0); 12325 } 12326 } 12327 } 12329 Retransmit-Command-if-Possible(Connection, CmdSN) 12330 { 12331 if (operational ErrorRecoveryLevel > 0) { 12332 Retrieve the InitiatorTaskTag, and thus TCB for the 12333 CmdSN. 12334 Build-And-Send-Command(Connection, TCB); 12335 } 12336 } 12338 Evaluate-a-StatSN(Connection, CurrentPDU) 12339 { 12340 send-status-SNACK = FALSE; 12341 if (Connection.SoFarInOrder == TRUE) { 12342 if (current StatSN is the expected) { 12343 Increment Connection.ExpectedStatSN. 12344 } else { 12345 Connection.SoFarInOrder = FALSE; 12346 send-status-SNACK = TRUE; 12347 } 12348 } else { 12349 if (current StatSN was considered missing) { 12350 remove current StatSN from the missing list. 12351 } else { 12352 if (current StatSN is higher than expected){ 12353 send-status-SNACK = TRUE; 12354 } else { 12355 send-status-SNACK = FALSE; 12356 discard the PDU; 12357 } 12358 } 12359 Adjust Connection.ExpectedStatSN if appropriate. 12360 if (missing StatSN list is empty) { 12361 Connection.SoFarInOrder = TRUE; 12362 } 12363 } 12364 return send-status-SNACK; 12365 } 12367 Receive-a-In-PDU(Connection, CurrentPDU) 12368 { 12369 check-basic-validity(CurrentPDU); 12370 if (Header-Digest-Bad) discard, return; 12371 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12372 if (CurrentPDU.type == Nop-In) { 12373 if (the PDU is unsolicited) { 12374 if (current StatSN is not expected) { 12375 Recover-Status-if-Possible(Connection, 12376 CurrentPDU); 12377 } 12378 if (current ExpCmdSN is not Session.CmdSN) { 12379 Retransmit-Command-if-Possible(Connection, 12380 CurrentPDU.ExpCmdSN); 12381 } 12382 } 12383 } else if (CurrentPDU.type == Reject) { 12384 if (it is a data digest error on immediate data) { 12385 Retransmit-Command-if-Possible(Connection, 12387 CurrentPDU.BadPDUHeader.CmdSN); 12388 } 12389 } else if (CurrentPDU.type == Response) { 12390 send-status-SNACK = Evaluate-a-StatSN(Connection, 12391 CurrentPDU); 12392 if (send-status-SNACK == TRUE) 12393 Recover-Status-if-Possible(Connection, CurrentPDU); 12394 } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY, 12395 * NOT SHOWN */ 12396 } 12397 } 12399 Command-Acknowledge-Timeout-Handler(TCB) 12400 { 12401 Retrieve the Connection for TCB. 12402 Retransmit-Command-if-Possible(Connection, TCB.CmdSN); 12403 } 12405 Status-Expect-Timeout-Handler(Connection) 12406 { 12407 if (operational ErrorRecoveryLevel > 0) { 12408 Build-And-Send-Nop-Out(Connection); 12409 } else if (InitiatorProactiveSNACKEnabled){ 12410 if ((Connection.state == LOGGED_IN) and 12411 connection is not already considered 12412 failed) { 12413 Build-And-Send-SSnack(Connection); 12414 } 12415 } 12416 } 12418 E.3.3 Target Algorithms 12420 Handle-Status-SNACK-request(Connection, CurrentPDU) 12421 { 12422 if (operational ErrorRecoveryLevel > 0) { 12423 if (request for an acknowledged run) { 12424 Build-And-Send-Reject(Connection, CurrentPDU, 12425 Protocol-Error); 12426 } else if (request for an untransmitted run) { 12427 discard, return; 12428 } else { 12429 Retransmit-Status-Burst(CurrentPDU, TCB); 12430 } 12431 } else { 12432 Build-And-Send-Async(Connection, DroppedConnection, 12433 DefaultTime2Wait, 12434 DefaultTime2Retain); 12435 } 12436 } 12437 D.4. Connection Recovery Algorithms 12439 D.4.1. Procedure Descriptions 12441 Build-And-Send-Async(transport connection, reason code, 12442 minimum time, maximum time); 12443 Pick-A-Logged-In-Connection(session); 12444 Build-And-Send-Logout(transport connection, logout connection 12445 identifier, reason code); 12446 PerformImplicitLogout(transport connection, logout connection 12447 identifier, target information); 12448 PerformLogin(transport connection, target information); 12449 CreateNewTransportConnection(target information); 12450 Build-And-Send-Command(transport connection, task control 12451 block); 12452 Connection-Cleanup-Handler(transport connection); 12453 Connection-Resource-Timeout-Handler(transport connection); 12454 Quiesce-And-Prepare-for-New-Allegiance(session, task control 12455 block); 12456 Build-And-Send-Logout-Response(transport connection, 12457 CID of connection in recovery, reason 12458 code); 12459 Build-And-Send-TaskMgmt-Response(transport connection, 12460 task mgmt command PDU, response code); 12461 Establish-New-Allegiance(task control block, transport 12462 connection); 12463 Schedule-Command-To-Continue(task control block); 12465 Notes: 12466 - Transport exception conditions, such as unexpected 12467 connection termination, connection reset, and hung 12468 connection while the connection is in the full-feature 12469 phase, are all assumed to be asynchronously signaled to the 12470 iSCSI layer using the Transport_Exception_Handler procedure. 12472 D.4.2. Initiator Algorithms 12474 Receive-a-In-PDU(Connection, CurrentPDU) 12475 { 12476 check-basic-validity(CurrentPDU); 12477 if (Header-Digest-Bad) discard, return; 12478 Retrieve TCB from CurrentPDU.InitiatorTaskTag. 12479 if (CurrentPDU.type == Async) { 12480 if (CurrentPDU.AsyncEvent == ConnectionDropped) { 12481 Retrieve the AffectedConnection for 12482 CurrentPDU.Parameter1. 12483 AffectedConnection.CurrentTimeout = 12484 CurrentPDU.Parameter3; 12485 AffectedConnection.State = CLEANUP_WAIT; 12486 Start-Timer(Connection-Cleanup-Handler, 12487 AffectedConnection, 12488 CurrentPDU.Parameter2); 12489 } else if (CurrentPDU.AsyncEvent == LogoutRequest)) { 12490 AffectedConnection = Connection; 12491 AffectedConnection.State = LOGOUT_REQUESTED; 12492 AffectedConnection.PerformConnectionCleanup = TRUE; 12493 AffectedConnection.CurrentTimeout = 12494 CurrentPDU.Parameter3; 12495 Start-Timer(Connection-Cleanup-Handler, 12496 AffectedConnection, 0); 12497 } else if (CurrentPDU.AsyncEvent == SessionDropped)) { 12498 for (each Connection) { 12499 Connection.State = CLEANUP_WAIT; 12500 Connection.CurrentTimeout = CurrentPDU.Parameter3; 12501 Start-Timer(Connection-Cleanup-Handler, 12502 Connection, CurrentPDU.Parameter2); 12503 } 12504 Session.state = FAILED; 12505 } 12507 } else if (CurrentPDU.type == LogoutResponse) { 12508 Retrieve the CleanupConnection for CurrentPDU.CID. 12509 if (CurrentPDU.Response = failure) { 12510 CleanupConnection.State = CLEANUP_WAIT; 12511 } else { 12512 CleanupConnection.State = FREE; 12513 } 12514 } else if (CurrentPDU.type == LoginResponse) { 12515 if (this is a response to an implicit Logout) { 12516 Retrieve the CleanupConnection. 12517 if (successful) { 12518 CleanupConnection.State = FREE; 12519 Connection.State = LOGGED_IN; 12520 } else { 12521 CleanupConnection.State = CLEANUP_WAIT; 12522 DestroyTransportConnection(Connection); 12523 } 12524 } 12525 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12526 * NOT SHOWN */ 12527 } 12528 if (CleanupConnection.State == FREE) { 12529 for (each command that was active on CleanupConnection) { 12530 /* Establish new connection allegiance */ 12531 NewConnection = Pick-A-Logged-In- 12532 Connection(Session); 12533 Build-And-Send-Command(NewConnection, TCB); 12534 } 12535 } 12536 } 12538 Connection-Cleanup-Handler(Connection) 12539 { 12540 Retrieve Session from Connection. 12541 if (Connection can still exchange iSCSI PDUs) { 12542 NewConnection = Connection; 12543 } else { 12544 Start-Timer(Connection-Resource-Timeout-Handler, 12545 Connection, Connection.CurrentTimeout); 12546 if (there are other logged-in connections) { 12547 NewConnection = Pick-A-Logged-In- 12548 Connection(Session); 12549 } else { 12550 NewConnection = 12552 CreateTransportConnection(Session.OtherEndInfo); 12553 Initiate an implicit Logout on NewConnection for 12554 Connection.CID. 12555 return; 12557 } 12558 } 12559 Build-And-Send-Logout(NewConnection, Connection.CID, 12560 RecoveryRemove); 12561 } 12563 Transport_Exception_Handler(Connection) 12564 { 12565 Connection.PerformConnectionCleanup = TRUE; 12566 if (the event is an unexpected transport disconnect) { 12567 Connection.State = CLEANUP_WAIT; 12568 Connection.CurrentTimeout = DefaultTime2Retain; 12569 Start-Timer(Connection-Cleanup-Handler, Connection, 12570 DefaultTime2Wait); 12572 } else { 12573 Connection.State = FREE; 12574 } 12575 } 12577 D.4.3. Target Algorithms 12579 Receive-a-In-PDU(Connection, CurrentPDU) 12580 { 12581 check-basic-validity(CurrentPDU); 12582 if (Header-Digest-Bad) discard, return; 12583 else if (Data-Digest-Bad) { 12584 Build-And-Send-Reject(Connection, CurrentPDU, 12585 Payload-Digest-Error); 12586 discard, return; 12587 } 12588 Retrieve TCB and Session. 12589 if (CurrentPDU.type == Logout) { 12590 if (CurrentPDU.ReasonCode = RecoveryRemove) { 12591 Retrieve the CleanupConnection from CurrentPDU.CID). 12592 for (each command active on CleanupConnection) { 12593 Quiesce-And-Prepare-for-New-Allegiance(Session, 12594 TCB); 12595 TCB.CurrentlyAllegiant = FALSE; 12596 } 12597 Cleanup-Connection-State(CleanupConnection); 12598 if ((quiescing successful) and (cleanup successful)) 12599 { 12600 Build-And-Send-Logout-Response(Connection, 12601 CleanupConnection.CID, 12602 Success); 12603 } else { 12604 Build-And-Send-Logout-Response(Connection, 12605 CleanupConnection.CID, 12606 Failure); 12607 } 12608 } 12609 } else if ((CurrentPDU.type == Login) and 12610 operational ErrorRecoveryLevel == 2) { 12611 Retrieve the CleanupConnection from CurrentPDU.CID). 12612 for (each command active on CleanupConnection) { 12613 Quiesce-And-Prepare-for-New-Allegiance(Session, 12614 TCB); 12615 TCB.CurrentlyAllegiant = FALSE; 12616 } 12617 Cleanup-Connection-State(CleanupConnection); 12618 if ((quiescing successful) and (cleanup successful)) 12619 { 12620 Continue with the rest of the Login processing; 12621 } else { 12622 Build-And-Send-Login-Response(Connection, 12623 CleanupConnection.CID, Target 12624 Error); 12625 } 12626 } 12627 } else if (CurrentPDU.type == TaskManagement) { 12628 if (CurrentPDU.function == "TaskReassign") { 12629 if (Session.ErrorRecoveryLevel < 2) { 12630 Build-And-Send-TaskMgmt-Response(Connection, 12631 CurrentPDU, "Allegiance reassignment 12632 not supported"); 12633 } else if (task is not found) { 12634 Build-And-Send-TaskMgmt-Response(Connection, 12635 CurrentPDU, "Task not in task set"); 12636 } else if (task is currently allegiant) { 12637 Build-And-Send-TaskMgmt-Response(Connection, 12638 CurrentPDU, "Task still allegiant"); 12639 } else { 12640 Establish-New-Allegiance(TCB, Connection); 12641 TCB.CurrentlyAllegiant = TRUE; 12642 Schedule-Command-To-Continue(TCB); 12643 } 12644 } 12645 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12646 * NOT SHOWN */ 12647 } 12648 } 12650 Transport_Exception_Handler(Connection) 12651 { 12652 Connection.PerformConnectionCleanup = TRUE; 12653 if (the event is an unexpected transport disconnect) { 12654 Connection.State = CLEANUP_WAIT; 12655 Start-Timer(Connection-Resource-Timeout-Handler, 12656 Connection, 12658 (DefaultTime2Wait+DefaultTime2Retain)); 12659 if (this Session has full-feature phase connections 12660 left) { 12661 DifferentConnection = 12662 Pick-A-Logged-In-Connection(Session); 12663 Build-And-Send-Async(DifferentConnection, 12664 DroppedConnection, DefaultTime2Wait, 12665 DefaultTime2Retain); 12666 } 12667 } else { 12668 Connection.State = FREE; 12669 } 12670 } 12671 Appendix E. Clearing Effects of Various Events on Targets 12673 E.1. Clearing Effects on iSCSI Objects 12675 The following tables describe the target behavior on receiving the 12676 events specified in the rows of the table. The second table is 12678 an extension of the first table and defines clearing actions for 12679 more objects on the same events. The legend is: 12681 Y = Yes (cleared/discarded/reset on the event specified in 12682 the row). Unless otherwise noted, the clearing action is 12683 only applicable for the issuing initiator port. 12685 N = No (not affected on the event specified in the row, 12686 i.e., stays at previous value). 12688 NA = Not Applicable or Not Defined. 12690 +-----+-----+-----+-----+-----+ 12691 |IT(1)|IC(2)|CT(5)|ST(6)|PP(7)| 12692 +---------------------+-----+-----+-----+-----+-----+ 12693 |connection failure(8)|Y |Y |N |N |Y | 12694 +---------------------+-----+-----+-----+-----+-----+ 12695 |connection state |NA |NA |Y |N |NA | 12696 |timeout (9) | | | | | | 12697 +---------------------+-----+-----+-----+-----+-----+ 12698 |session timeout/ |Y |Y |Y |Y |Y(14)| 12699 |closure/reinstatement| | | | | | 12700 |(10) | | | | | | 12701 +---------------------+-----+-----+-----+-----+-----+ 12702 |session continuation |NA |NA |N(11)|N |NA | 12703 |(12) | | | | | | 12704 +---------------------+-----+-----+-----+-----+-----+ 12705 |successful connection|Y |Y |Y |N |Y(13)| 12706 |close logout | | | | | | 12707 +---------------------+-----+-----+-----+-----+-----+ 12708 |session failure (18) |Y |Y |N |N |Y | 12709 +---------------------+-----+-----+-----+-----+-----+ 12710 |successful recovery |Y |Y |N |N |Y(13)| 12711 |Logout | | | | | | 12712 +---------------------+-----+-----+-----+-----+-----+ 12713 |failed Logout |Y |Y |N |N |Y | 12714 +---------------------+-----+-----+-----+-----+-----+ 12715 |connection Login |NA |NA |NA |Y(15)|NA | 12716 |(leading) | | | | | | 12717 +---------------------+-----+-----+-----+-----+-----+ 12718 |connection Login |NA |NA |N(11)|N |Y | 12719 |(non-leading) | | | | | | 12720 +---------------------+-----+-----+-----+-----+-----+ 12721 |target cold reset(16)|Y(20)|Y |Y |Y |Y | 12722 +---------------------+-----+-----+-----+-----+-----+ 12723 |target warm reset(16)|Y(20)|Y |Y |Y |Y | 12724 +---------------------+-----+-----+-----+-----+-----+ 12725 |LU reset(19) |Y(20)|Y |Y |Y |Y | 12726 +---------------------+-----+-----+-----+-----+-----+ 12727 |powercycle(16) |Y |Y |Y |Y |Y | 12728 +---------------------+-----+-----+-----+-----+-----+ 12730 1. Incomplete TTTs - Target Transfer Tags on which the target is 12731 still expecting PDUs to be received. Examples include TTTs 12732 received via R2T, NOP-IN, etc. 12734 2. Immediate Commands - immediate commands, but waiting for 12735 execution on a target. For example, Abort Task Set. 12737 5. Connection Tasks - tasks that are active on the iSCSI connection 12738 in question. 12740 6. Session Tasks - tasks that are active on the entire iSCSI 12741 session. A union of "connection tasks" on all participating 12742 connections. 12744 7. Partial PDUs (if any) - PDUs that are partially sent and waiting 12745 for transport window credit to complete the transmission. 12747 8. Connection failure is a connection exception condition - one of 12748 the transport connections shutdown, transport connections 12749 reset, or transport connections timed out, which abruptly 12750 terminated the iSCSI full-feature phase connection. A 12751 connection failure always takes the connection state machine to 12752 the CLEANUP_WAIT state. 12754 9. Connection state timeout happens if a connection spends more 12755 time than agreed upon during Login negotiation in the 12756 CLEANUP_WAIT state, and this takes the connection to the FREE 12757 state (M1 transition in connection cleanup state diagram). 12759 10.These are defined in Section 6.3.5. 12761 11.This clearing effect is "Y" only if it is a connection 12762 reinstatement and the operational ErrorRecoveryLevel is less 12763 than 2. 12765 12.Session continuation is defined in Section 6.3.5. 12767 13.This clearing effect is only valid if the connection is being 12768 logged out on a different connection and when the connection 12769 being logged out on the target may have some partial PDUs 12770 pending to be sent. In all other cases, the effect is "NA". 12771 14.This clearing effect is only valid for a "close the session" 12772 logout in a multi-connection session. In all other cases, the 12773 effect is "NA". 12774 15.Only applicable if this leading connection login is a session 12775 reinstatement. If this is not the case, it is "NA". 12776 16.This operation affects all logged-in initiators. 12777 18.Session failure is defined in Section 6.3.5. 12778 19.This operation affects all logged-in initiators and the clearing 12779 effects are only applicable to the LU being reset. 12781 20.With Standard multi-task abort semantics (Section 4.2.3.3), a 12782 target warm reset or a target cold reset or an LU reset would 12783 clear the active TTTs upon completion. However, the FastAbort 12784 multi-task abort semantics defined by Section 4.2.3.4 do not 12785 guarantee that the active TTTs are cleared by the end of the 12786 reset operations. In fact, the FastAbort semantics are designed 12787 to allow clearing the TTTs in a "lazy" fashion after the TMF 12788 Response is delivered. Thus, when TaskReporting=FastAbort 12789 (Section 13.23) is operational on a session, the clearing 12790 effects of reset operations on "Incomplete TTTs" is "N". 12792 +-----+-----+-----+-----+-----+ 12793 |DC(1)|DD(2)|SS(3)|CS(4)|DS(5)| 12794 +---------------------+-----+-----+-----+-----+-----+ 12795 |connection failure |N |Y |N |N |N | 12796 +---------------------+-----+-----+-----+-----+-----+ 12797 |connection state |Y |NA |Y |N |NA | 12798 |timeout | | | | | | 12799 +---------------------+-----+-----+-----+-----+-----+ 12800 |session timeout/ |Y |Y |Y(7) |Y |NA | 12801 |closure/reinstatement| | | | | | 12802 +---------------------+-----+-----+-----+-----+-----+ 12803 |session continuation |N(11)|NA*12|NA |N |NA*13| 12804 +---------------------+-----+-----+-----+-----+-----+ 12805 |successful connection|Y |Y |Y |N |NA | 12806 |close Logout | | | | | | 12807 +---------------------+-----+-----+-----+-----+-----+ 12808 |session failure |N |Y |N |N |N | 12809 +---------------------+-----+-----+-----+-----+-----+ 12810 |successful recovery |Y |Y |Y |N |N | 12811 |Logout | | | | | | 12812 +---------------------+-----+-----+-----+-----+-----+ 12813 |failed Logout |N |Y(9) |N |N |N | 12814 +---------------------+-----+-----+-----+-----+-----+ 12815 |connection Login |NA |NA |N(8) |N(8) |NA | 12816 |(leading | | | | | | 12817 +---------------------+-----+-----+-----+-----+-----+ 12818 |connection Login |N(11)|NA*12|N(8) |N |NA*13| 12819 |(non-leading) | | | | | | 12820 +---------------------+-----+-----+-----+-----+-----+ 12821 |target cold reset |Y |Y |Y |Y(10)|NA | 12822 +---------------------+-----+-----+-----+-----+-----+ 12823 |target warm reset |Y |Y |N |N |NA | 12824 +---------------------+-----+-----+-----+-----+-----+ 12825 |LU reset |N |Y |N |N |N | 12826 +---------------------+-----+-----+-----+-----+-----+ 12827 |powercycle |Y |Y |Y |Y(10)|NA | 12828 +---------------------+-----+-----+-----+-----+-----+ 12830 1. Discontiguous Commands - commands allegiant to the connection 12831 in question and waiting to be reordered in the iSCSI layer. All 12832 "Y"s in this column assume that the task causing the event (if 12833 indeed the event is the result of a task) is issued as an 12834 immediate command, because the discontiguities can be ahead of the 12835 task. 12837 2. Discontiguous Data - data PDUs received for the task in 12838 question and waiting to be reordered due to prior discontiguities 12839 in DataSN. 12841 3. StatSN 12843 4. CmdSN 12845 5. DataSN 12847 7. It clears the StatSN on all the connections. 12849 8. This sequence number is instantiated on this event. 12851 9. A logout failure drives the connection state machine to the 12852 CLEANUP_WAIT state, similar to the connection failure event. 12853 Hence, it has a similar effect on this and several other protocol 12854 aspects. 12856 10. This is cleared by virtue of the fact that all sessions with 12857 all initiators are terminated. 12859 11. This clearing effect is "Y" if it is a connection 12860 reinstatement. 12862 12. This clearing effect is "Y" only if it is a connection 12863 reinstatement and the operational ErrorRecoveryLevel is 2. 12865 13. This clearing effect is "N" only if it is a connection 12866 reinstatement and the operational ErrorRecoveryLevel is 2. 12868 E.2. Clearing Effects on SCSI Objects 12870 The only iSCSI protocol action that can effect clearing actions on 12871 SCSI objects is the "I_T nexus loss" notification (Section 6.3.5.1 12872 Loss of Nexus notification). [SPC3] describes the clearing effects 12873 of this notification on a variety of SCSI attributes. In addition, 12874 SCSI standards documents (such as [SAM2] and [SBC2]) define 12875 additional clearing actions that may take place for several SCSI 12876 objects on SCSI events such as LU resets and power-on resets. 12878 Since iSCSI defines a target cold reset as a protocol-equivalent 12879 to a target power-cycle, the iSCSI target cold reset must also be 12880 considered as the power-on reset event in interpreting the actions 12881 defined in the SCSI standards. 12883 When the iSCSI session is reconstructed (between the same SCSI 12884 ports with the same nexus identifier) reestablishing the same I_T 12885 nexus, all SCSI objects that are defined to not clear on the "I_T 12886 nexus loss" notification event, such as persistent reservations, 12887 are automatically associated to this new session. 12889 Acknowledgments 12891 Several individuals on the original IPS Working Group made 12892 significant contributions to the original RFCs 3720, 3980, 4850 12893 and 5048. 12895 Specifically, the authors of the original RFCs - which this draft 12896 consolidates into a single document - were the following: 12898 RFC 3720: Julian Satran, Kalman Meth, Costa Sapuntzakis, 12899 Mallikarjun Chadalapaka, Efri Zeidner 12901 RFC 3980: Marjorie Krueger, Mallikarjun Chadalapaka, Rob Elliott 12903 RFC 4850: David Wysochanski 12905 RFC 5048: Mallikarjun Chadalapaka 12907 Many thanks to Fred Knight for contributing to the UML notations 12908 and drawings in this draft. 12910 We would in addition like to acknowledge the following individuals 12911 who contributed to this revised draft: David Harrington, Paul 12912 Koning, Mark Edwards, Rob Elliott, Martin Stiemerling. Finally, 12913 this draft also benefited from significant review contributions 12914 from the Storm Working Group. 12916 Authors' Addresses 12918 Mallikarjun Chadalapaka 12919 Microsoft 12920 One Microsoft Way 12921 Redmond WA 98052 USA 12922 E-mail: cbm@chadalapaka.com 12924 Julian Satran 12925 Infinidat Ltd. 12926 E-mail: julians@infinidat.com, julian@satran.net 12928 Kalman Meth 12929 IBM Haifa Research Lab 12930 Haifa University Campus - Mount Carmel 12931 Haifa 31905, Israel 12932 Phone +972.4.829.6341 12933 E-mail: meth@il.ibm.com 12935 David L. Black, 12936 EMC Corporation, 12937 176 South St., Hopkinton, MA 01748 12938 Phone +1 (508) 293-7953 12939 Email: david.black@emc.com 12941 Comments may be sent to Mallikarjun Chadalapaka 12943 Acknowledgement 12945 Funding for the RFC Editor function is currently provided by the 12946 Internet Society