idnits 2.17.1 draft-ietf-storm-iscsi-cons-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The abstract seems to indicate that this document obsoletes RFC3720, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC3980, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC5048, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC4850, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC3721, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3723, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC5048, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4850, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2859 -- Looks like a reference, but probably isn't: '0' on line 6736 -- Looks like a reference, but probably isn't: '7' on line 6736 == Missing Reference: 'MaxMissingDPDU' is mentioned on line 11831, but not defined == Missing Reference: 'MaxOutStandingR2T' is mentioned on line 11839, but not defined == Missing Reference: 'MaxMissingSPDU' is mentioned on line 11852, but not defined == Missing Reference: 'MaxSupportedConns' is mentioned on line 11862, but not defined -- 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 5996 (Obsoleted by RFC 7296) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM4' -- Possible downref: Non-RFC (?) normative reference: ref. 'SBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SPC3' -- Possible downref: Non-RFC (?) normative reference: ref. 'UML' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3720 (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 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: 2 errors (**), 0 flaws (~~), 7 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-05.txt 4 Intended status: Proposed Standard Julian Satran 5 Expires: July 2012 Infinidat Ltd. 6 Obsoletes: 3720, 3980, 4850, 5048 7 Updates: 3721, 3723 Kalman Meth 8 IBM 10 David Black 11 EMC 13 iSCSI Protocol (Consolidated) 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on July 7, 2012. 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. Definitions, Acronyms, and Document Summary..................... 15 75 2.1. Definitions ................................................. 15 76 2.2. Acronyms .................................................... 21 77 2.3. Summary of Changes .......................................... 23 78 2.4. Conventions ................................................. 24 79 2.4.1. Word Rule ............................................... 25 80 2.4.2. Half-Word Rule .......................................... 25 81 2.4.3. Byte Rule ............................................... 25 82 3. UML Conventions................................................. 27 83 3.1. UML Conventions Overview .................................. 27 84 3.2. Multiplicity Notion ....................................... 27 85 3.3. Class Diagram Conventions ................................. 28 86 3.4. Class Diagram Notation for Associations ................... 29 87 3.5. Class Diagram Notation for Aggregations ................... 30 88 3.6. Class Diagram Notation for Generalizations ................ 30 89 4. Overview........................................................ 32 90 4.1. SCSI Concepts ............................................... 32 91 4.2. iSCSI Concepts and Functional Overview ...................... 33 92 4.2.1. Layers and Sessions ..................................... 34 93 4.2.2. Ordering and iSCSI Numbering ............................ 34 94 4.2.2.1. Command Numbering and Acknowledging ................. 35 95 4.2.2.2. Response/Status Numbering and Acknowledging ......... 39 96 4.2.2.3. Response Ordering ................................... 40 97 4.2.2.3.1. Need for Response Ordering ...................... 40 98 4.2.2.3.2. Response Ordering Model Description ............. 40 99 4.2.2.3.3. iSCSI Semantics with the Interface Model ........ 41 100 4.2.2.3.4. Current List of Fenced Response Use Cases ....... 41 101 4.2.2.4. Data Sequencing ..................................... 43 102 4.2.3. iSCSI Task Management ................................... 43 103 4.2.3.1. Task Management Overview ............................ 43 104 4.2.3.2. Notion of Affected Tasks ............................ 44 105 4.2.3.3. Standard Multi-task Abort Semantics ................. 44 106 4.2.3.4. FastAbort Multi-task Abort Semantics ................46 107 4.2.3.5. Affected Tasks Shared across Standard and FastAbort 108 Sessions .....................................................48 109 4.2.3.6. Rationale behind the FastAbort Semantics ............49 110 4.2.4. iSCSI Login .............................................50 111 4.2.5. iSCSI Full Feature Phase ................................52 112 4.2.5.1. Command Connection Allegiance .......................52 113 4.2.5.2. Data Transfer Overview ..............................53 114 4.2.5.3. Tags and Integrity Checks ...........................55 115 4.2.5.4. Task Management .....................................55 116 4.2.6. iSCSI Connection Termination ............................56 117 4.2.7. iSCSI Names .............................................56 118 4.2.7.1. iSCSI Name Properties ...............................57 119 4.2.7.2. iSCSI Name Encoding .................................59 120 4.2.7.3. iSCSI Name Structure ................................60 121 4.2.7.4. Type "iqn." (iSCSI Qualified Name) ..................61 122 4.2.7.5. Type "eui." (IEEE EUI-64 format) ....................63 123 4.2.7.6. Type "naa." - Network Address Authority .............64 124 4.2.8. Persistent State ........................................65 125 4.2.9. Message Synchronization and Steering ....................65 126 4.2.9.1. Sync/Steering and iSCSI PDU Length ..................66 127 4.3. iSCSI Session Types .........................................67 128 4.4. SCSI to iSCSI Concepts Mapping Model ........................67 129 4.4.1. iSCSI Architecture Model ................................68 130 4.4.2. SCSI Architecture Model .................................71 131 4.4.3. Consequences of the Model ...............................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 Phase106 163 6.3.4. Connection Reinstatement ...............................107 164 6.3.5. Session Reinstatement, Closure, and Timeout ............107 165 6.3.5.1. Loss of Nexus Notification .........................108 166 6.3.6. Session Continuation and Failure .......................109 167 6.4. Operational Parameter Negotiation Outside the Login Phase ..109 168 7. iSCSI Error Handling and Recovery..............................111 169 7.1. Overview ...................................................111 170 7.1.1. Background .............................................111 171 7.1.2. Goals ..................................................111 172 7.1.3. Protocol Features and State Expectations ...............112 173 7.1.4. Recovery Classes .......................................113 174 7.1.4.1. Recovery Within-command ............................114 175 7.1.4.2. Recovery Within-connection .........................115 176 7.1.4.3. Connection Recovery ................................116 177 7.1.4.4. Session Recovery ...................................117 179 7.1.5. Error Recovery Hierarchy ...............................117 180 7.2. Retry and Reassign in Recovery .............................119 181 7.2.1. Usage of Retry .........................................120 182 7.2.2. Allegiance Reassignment ................................120 183 7.3. Usage Of Reject PDU in Recovery ............................122 184 7.4. Error Recovery Considerations for Discovery Sessions .......122 185 7.4.1. ErrorRecoveryLevel for Discovery Sessions ..............122 186 7.4.2. Reinstatement Semantics for Discovery Sessions .........123 187 7.4.2.1. Unnamed Discovery Sessions .........................124 188 7.4.2.2. Named Discovery Session ............................124 189 7.4.3. Target PDUs During Discovery ...........................124 190 7.5. Connection Timeout Management ..............................125 191 7.5.1. Timeouts on Transport Exception Events .................125 192 7.5.2. Timeouts on Planned Decommissioning ....................125 193 7.6. Implicit Termination of Tasks ..............................126 194 7.7. Format Errors ..............................................127 195 7.8. Digest Errors ..............................................127 196 7.9. Sequence Errors ............................................129 197 7.10. Message Error Checking ....................................130 198 7.11. SCSI Timeouts .............................................130 199 7.12. Negotiation Failures ......................................131 200 7.13. Protocol Errors ...........................................132 201 7.14. Connection Failures .......................................132 202 7.15. Session Errors ............................................133 203 8. State Transitions..............................................135 204 8.1. Standard Connection State Diagrams .........................135 205 8.1.1. State Descriptions for Initiators and Targets ..........135 206 8.1.2. State Transition Descriptions for Initiators and 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 or Public Extension Key Format ...............283 408 13.23. Task Reporting ...........................................283 409 13.24. iSCSIProtocolLevel Negotiation ...........................284 410 13.25. Obsoleted Keys ...........................................285 411 13.26. X#NodeArchitecture .......................................285 412 13.26.1. Definition ...........................................285 413 13.26.2. Implementation Requirements ..........................286 414 14. IANA Considerations........................................... 287 416 Appendix A. Examples ............................................. 292 417 Read Operation Example ..........................................292 418 Write Operation Example .........................................293 419 R2TSN/DataSN Use Examples .......................................293 420 CRC Examples ....................................................297 421 Appendix B. Login Phase Examples ................................. 299 423 Appendix C. SendTargets Operation ................................ 309 425 Appendix D. Algorithmic Presentation of Error Recovery Classes ... 314 426 D.2.1. Procedure Descriptions ................................. 317 427 Appendix E. Clearing Effects of Various Events on Targets ........ 333 428 1. Introduction 430 The Small Computer Systems Interface (SCSI) is a popular family of 431 protocols for communicating with I/O devices, especially storage 432 devices. SCSI is a client-server architecture. Clients of a SCSI 433 interface are called "initiators". Initiators issue SCSI 434 "commands" to request services from components, logical units of a 435 server known as a "target". A "SCSI transport" maps the client- 436 server SCSI protocol to a specific interconnect. An Initiator is 437 one endpoint of a SCSI transport and a target is the other 438 endpoint. 440 The SCSI protocol has been mapped over various transports, 441 including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre 442 Channel. These transports are I/O specific and have limited 443 distance capabilities. 445 The iSCSI protocol defined in this document describes a means of 446 transporting of the SCSI packets over TCP/IP, providing for an 447 interoperable solution which can take advantage of existing 448 Internet infrastructure, Internet management facilities and 449 address distance limitations. 451 2. Definitions, Acronyms, and Document Summary 453 2.1. Definitions 455 - Alias: An alias string can also be associated with an iSCSI 456 Node. The alias allows an organization to associate a user- 457 friendly string with the iSCSI Name. However, the alias string is 458 not a substitute for the iSCSI Name. 460 - CID (Connection ID): Connections within a session are identified 461 by a connection ID. It is a unique ID for this connection within 462 the session for the initiator. It is generated by the initiator 463 and presented to the target during login requests and during 464 logouts that close connections. 466 - Connection: A connection is a TCP connection. Communication 467 between the initiator and target occurs over one or more TCP 468 connections. The TCP connections carry control messages, SCSI 469 commands, parameters, and data within iSCSI Protocol Data Units 470 (iSCSI PDUs). 472 - I/O Buffer:A buffer that is used in a SCSI Read or Write 473 operation so SCSI data may be sent from or received into that 474 buffer. For a read or write data transfer to take place for a 475 task, an I/O Buffer is required on the initiator and at least one 476 is required on the 477 target. 479 - INCITS: INCITS stands for InterNational Committee of Information 480 Technology Standards. The INCITS has a broad standardization scope 481 within the field of Information and Communications Technologies 482 (ICT), encompassing storage, processing, transfer, display, 483 management, organization, and retrieval of information. INCITS 484 serves as ANSI's Technical Advisory Group for the ISO/IEC Joint 485 Technical Committee 1 (JTC 1). See http://www.incits.org. 487 - InfiniBand: An I/O architecture originally intended to replace 488 PCI and to address high performance server interconnectivity [IB]. 490 - iSCSI Device: A SCSI Device using an iSCSI service delivery 491 subsystem. Service Delivery Subsystem is defined by [SAM2] as a 492 transport mechanism for SCSI commands and responses. 494 - iSCSI Initiator Name: The iSCSI Initiator Name specifies the 495 worldwide unique name of the initiator. 497 - iSCSI Initiator Node: The "initiator" device. The word 498 "initiator" has been appropriately qualified as either a port or a 499 device in the rest of the document when the context is ambiguous. 500 All unqualified usages of "initiator" refer to an initiator port 501 (or device) depending on the context. 503 - iSCSI Layer: This layer builds/receives iSCSI PDUs and 504 relays/receives them to/from one or more TCP connections that form 505 an initiator-target "session". 507 - iSCSI Name: The name of an iSCSI initiator or iSCSI target. 509 - iSCSI Node: The iSCSI Node represents a single iSCSI initiator 510 or iSCSI target or a single instance of each. There are one or 511 more iSCSI Nodes within a Network Entity. The iSCSI Node is 512 accessible via one or more Network Portals. An iSCSI Node is 513 identified by its iSCSI Name. The separation of the iSCSI Name 514 from the addresses used by and for the iSCSI Node allows multiple 515 iSCSI nodes to use the same address, and the same iSCSI node to 516 use multiple addresses. 518 - iSCSI Target Name: The iSCSI Target Name specifies the worldwide 519 unique name of the target. 521 - iSCSI Target Node: The "target" device. The word "target" has 522 been appropriately qualified as either a port or a device in the 523 rest of the document when the context is ambiguous. All 524 unqualified usages of "target" refer to a target port (or device) 525 depending on the context. 527 - iSCSI Task: An iSCSI task is an iSCSI request for which a 528 response is expected. 530 - iSCSI Transfer Direction: The iSCSI transfer direction is 531 defined with regard to the initiator. Outbound or outgoing 532 transfers are transfers from the initiator to the target, while 533 inbound or incoming transfers are from the target to the 534 initiator. 536 - ISID: The initiator part of the Session Identifier. It is 537 explicitly specified by the initiator during Login. 539 - I_T nexus: According to [SAM2], the I_T nexus is a relationship 540 between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, 541 this relationship is a session, defined as a relationship between 542 an iSCSI Initiator's end of the session (SCSI Initiator Port) and 543 the iSCSI Target's Portal Group. The I_T nexus can be identified 544 by the conjunction of the SCSI port names; that is, the I_T nexus 545 identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI 546 Target Name + ',t,'+ Portal Group Tag). 548 - NAA: Network Address Authority, a naming format defined by the 549 INCITS T11 Fibre Channel protocols [FC-FS]. 551 - Network Entity: The Network Entity represents a device or 552 gateway that is accessible from the IP network. A Network Entity 553 must have one or more Network Portals, each of which can be used 554 to gain access to the IP network by some iSCSI Nodes contained in 555 that Network Entity. 557 - Network Portal: The Network Portal is a component of a Network 558 Entity that has a TCP/IP network address and that may be used by 559 an iSCSI Node within that Network Entity for the connection(s) 560 within one of its iSCSI sessions. A Network Portal in an initiator 561 is identified by its IP address. A Network Portal in a target is 562 identified by its IP address and its listening TCP port. 564 - Originator: In a negotiation or exchange, the party that 565 initiates the negotiation or exchange. 567 - PDU (Protocol Data Unit): The initiator and target divide their 568 communications into messages. The term "iSCSI protocol data unit" 569 (iSCSI PDU) is used for these messages. 571 - Portal Groups: iSCSI supports multiple connections within the 572 same session; some implementations will have the ability to 573 combine connections in a session across multiple Network Portals. 575 A Portal Group defines a set of Network Portals within an iSCSI 576 Network Entity that collectively supports the capability of 577 coordinating a session with connections spanning these portals. 578 Not all Network Portals within a Portal Group need participate in 579 every session connected through that Portal Group. One or more 580 Portal Groups may provide access to an iSCSI Node. Each Network 581 Portal, as utilized by a given iSCSI Node, belongs to exactly one 582 portal group within that node. 584 - Portal Group Tag: This 16-bit quantity identifies a Portal Group 585 within an iSCSI Node. All Network Portals with the same portal 586 group tag in the context of a given iSCSI Node are in the same 587 Portal Group. 589 - Recovery R2T: An R2T generated by a target upon detecting the 590 loss of one or more Data-Out PDUs through one of the following 591 means: a digest error, a sequence error, or a sequence reception 592 timeout. A recovery R2T carries the next unused R2TSN, but 593 requests all or part of the data burst that an earlier R2T (with a 594 lower R2TSN) had already requested. 596 - Responder: In a negotiation or exchange, the party that responds 597 to the originator of the negotiation or exchange. 599 - SAS: Serial Attached SCSI. The Serial Attached SCSI (SAS) 600 standard 601 contains both a physical layer compatible with Serial ATA, and 602 protocols for transporting SCSI commands to SAS devices and ATA 603 commands to SATA devices [SAS]. 605 - SCSI Device: This is the SAM2 term for an entity that contains 606 one or more SCSI ports that are connected to a service delivery 607 subsystem and supports a SCSI application protocol. For example, a 608 SCSI Initiator Device contains one or more SCSI Initiator Ports 609 and zero or more application clients. A Target Device contains one 610 or more SCSI Target Ports and one or more device servers and 611 associated logical units. For iSCSI, the SCSI Device is the 612 component within an iSCSI Node that provides the SCSI 613 functionality. As such, there can be, at most, one SCSI Device 614 within a given iSCSI Node. Access to the SCSI Device can only be 615 achieved in an iSCSI normal operational session. The SCSI Device 616 Name is defined to be the iSCSI Name of the node. 618 - SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor 619 Blocks) and relays/receives them with the remaining command 620 execute [SAM2] parameters to/from the iSCSI Layer. 622 - Session: The group of TCP connections that link an initiator 623 with a target form a session (loosely equivalent to a SCSI I-T 624 nexus). TCP connections can be added and removed from a session. 625 Across all connections within a session, an initiator sees one and 626 the same target. 628 - SCSI Initiator Port: This maps to the endpoint of an iSCSI 629 normal operational session. An iSCSI normal operational session is 630 negotiated through the login process between an iSCSI initiator 631 node and an iSCSI target node. At successful completion of this 632 process, a SCSI Initiator Port is created within the SCSI 633 Initiator Device. The SCSI Initiator Port Name and SCSI Initiator 634 Port Identifier are both defined to be the iSCSI Initiator Name 635 together with (a) a label that identifies it as an initiator port 636 name/identifier and (b) the ISID portion of the session 637 identifier. 639 - SCSI Port: This is the SAM2 term for an entity in a SCSI Device 640 that provides the SCSI functionality to interface with a service 641 delivery subsystem. For iSCSI, the definition of the SCSI 642 Initiator Port and the SCSI Target Port are different. 644 - SCSI Port Name: A name made up as UTF-8 characters and includes 645 the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag. 647 - SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 648 aggregate data length of the data that the SCSI layer logically 649 "presents" to the iSCSI layer for a Data-In or Data-Out transfer 650 in the context of a SCSI task. For a bidirectional task, there are 651 two SPDTL values -- one for Data-In and one for Data-Out. Note 652 that the notion of "presenting" includes immediate data per the 653 data transfer model in [SAM2], and excludes overlapping data 654 transfers, if any, requested by the SCSI layer. 656 - SCSI Target Port: This maps to an iSCSI Target Portal Group. 658 - SCSI Target Port Name and SCSI Target Port Identifier: These are 659 both defined to be the iSCSI Target Name together with (a) a label 660 that identifies it as a target port name/identifier and (b) the 661 portal group tag. 663 - SRP: SCSI RDMA Protocol. SRP defines a SCSI protocol mapping 664 onto the InfiniBand (tm) Architecture and/or functionally similar 665 Remote DMA-capable protocols [SRP]. 667 - SSID (Session ID): A session between an iSCSI initiator and an 668 iSCSI target is defined by a session ID that is a tuple composed 669 of an initiator part (ISID) and a target part (Target Portal Group 670 Tag). The ISID is explicitly specified by the initiator at session 671 establishment. The Target Portal Group Tag is implied by the 672 initiator through the selection of the TCP endpoint at connection 673 establishment. The TargetPortalGroupTag key must also be returned 674 by the target as a confimation during connection establishment. 676 - T10: A technical committee within INCITS that develops standards 677 and technical reports on I/O interfaces, particularly the series 678 of SCSI (Small Computer Systems Interface) standards. See 679 http://www.t10.org. 681 - T11: A technical committee within INCITS responsible for 682 standards development in the areas of Intelligent Peripheral 683 Interface (IPI), High-Performance Parallel Interface (HIPPI) and 684 Fibre Channel (FC). See http://www.t11.org. 686 - Target Portal Group Tag: A numerical identifier (16-bit) for an 687 iSCSI Target Portal Group. 689 - Third-party: A term used in this document to denote nexus 690 objects (I_T or I_T_L) and iSCSI sessions that reap the side 691 effects of actions that take place in the context of a separate 692 iSCSI session, while being third parties to the action that caused 693 the side effects. One example of a third-party session is an 694 iSCSI session hosting an I_T_L nexus to an LU that is reset with 695 an LU Reset TMF via a separate I_T nexus. 697 - TSIH (Target Session Identifying Handle): A target assigned tag 698 for a session with a specific named initiator. The target 699 generates it during session establishment. Other than defining it 700 as a 16 bit binary string, its internal format and content are not 701 defined by this protocol but for the all 0 value that is reserved 702 and used by the initiator to indicate a new session. It is given 703 to the target during additional connection establishment for the 704 same session. 706 2.2. Acronyms 708 Acronym Definition 709 -------------------------------------------------------------- 710 3DES Triple Data Encryption Standard 711 ACA Auto Contingent Allegiance 712 AEN Asynchronous Event Notification 713 AES Advanced Encryption Standard 714 AH Additional Header (not the IPsec AH!) 715 AHS Additional Header Segment 716 API Application Programming Interface 717 ASC Additional Sense Code 718 ASCII American Standard Code for Information Interchange 719 ASCQ Additional Sense Code Qualifier 720 BHS Basic Header Segment 721 CBC Cipher Block Chaining 722 CD Compact Disk 723 CDB Command Descriptor Block 724 CHAP Challenge Handshake Authentication Protocol 725 CID Connection ID 726 CO Connection Only 727 CRC Cyclic Redundancy Check 728 CRL Certificate Revocation List 729 CSG Current Stage 730 CSM Connection State Machine 731 DES Data Encryption Standard 732 DNS Domain Name Server 733 DOI Domain of Interpretation 734 DVD Digital Versatile Disk 735 EDTL Expected Data Transfer Length 736 ESP Encapsulating Security Payload 737 EUI Extended Unique Identifier 738 FFP Full Feature Phase 740 FFPO Full Feature Phase Only 741 Gbps Gigabits per Second 742 HBA Host Bus Adapter 743 HMAC Hashed Message Authentication Code 744 I_T Initiator_Target 745 I_T_L Initiator_Target_LUN 746 IANA Internet Assigned Numbers Authority 747 IB InfiniBand 748 ID Identifier 749 IDN Internationalized Domain Name 750 IEEE Institute of Electrical & Electronics Engineers 751 IETF Internet Engineering Task Force 752 IKE Internet Key Exchange 753 I/O Input-Output 754 IO Initialize Only 755 IP Internet Protocol 756 IPsec Internet Protocol Security 757 IPv4 Internet Protocol Version 4 758 IPv6 Internet Protocol Version 6 759 IQN iSCSI Qualified Name 760 iSCSI Internet SCSI 761 iSER iSCSI Extensions for RDMA 762 ISID Initiator Session ID 763 iSNS Internet Storage Name Service (see [RFC4171]) 764 ITN iSCSI Target Name 765 ITT Initiator Task Tag 766 KRB5 Kerberos V5 767 LFL Lower Functional Layer 768 LTDS Logical-Text-Data-Segment 769 LO Leading Only 770 LU Logical Unit 771 LUN Logical Unit Number 772 MAC Message Authentication Codes 773 NA Not Applicable 774 NAA Network Address Authority 775 NIC Network Interface Card 776 NOP No Operation 777 NSG Next Stage 778 OS Operating System 779 PDU Protocol Data Unit 780 PKI Public Key Infrastructure 781 R2T Ready To Transfer 782 R2TSN Ready To Transfer Sequence Number 783 RDMA Remote Direct Memory Access 784 RFC Request For Comments 785 SAM SCSI Architecture Model 786 SAM2 SCSI Architecture Model - 2 787 SAN Storage Area Network 788 SAS Serial Attached SCSI 789 SCSI Small Computer Systems Interface 790 SN Sequence Number 791 SNACK Selective Negative Acknowledgment - also 792 Sequence Number Acknowledgement for data 793 SPDTL SCSI-Presented Data Transfer Length 794 SPKM Simple Public-Key Mechanism 795 SRP Secure Remote Password, also SCSI RDMA Protocol 796 SSID Session ID 797 SW Session Wide 798 TCB Task Control Block 799 TCP Transmission Control Protocol 800 TMF Task Management Function 801 TPGT Target Portal Group Tag 802 TSIH Target Session Identifying Handle 803 TTT Target Transfer Tag 804 UA Unit Attention 805 UFL Upper Functional Layer 806 ULP Upper Level Protocol 807 URN Uniform Resource Names 808 UTF Universal Transformation Format 809 WG Working Group 811 2.3. Summary of Changes 813 1) Consolidated RFCs 3720, 3980, 4850 and 5048, and made the 814 necessary editorial changes 815 2) iSCSIProtocolLevel is specified as "1" in section 13.24, and 816 added a related normative reference to [iSCSI-SAM] draft 817 3) Markers and related keys were removed 818 4) SPKM authentication and related keys were removed 819 5) Added a new section 13.25 on responding to obsoleted keys 820 6) Have explicitly allowed initiator+target implementations 821 throughout the text 823 7) Clarified in section 4.2.7 that implementations SHOULD NOT 824 rely on SLP-based discovery 825 8) Added UML diagrams, and related conventions in section 3 826 9) FastAbort implementation is made a "SHOULD" requirement in 827 section 4.2.3.4 from the previous "MUST" requirement. 828 10) Clarified in section 6.2 that validity of NotUnderstood 829 response depends on iSCSIProtocolLevel 830 11) Required in section 4.2.7.1 that iSCSI Target Name must be 831 the same as iSCSI Initiator Name for SCSI (composite) devices 832 with both roles 833 12) Clarified in section 10.2 that ACA is a SHOULD requirement 834 only for iSCSI targets 835 13) Updated section 9.3 to require the following: MUST implement 836 IPsec, 2400-series RFCs (IPsec v2, IKEv1) and SHOULD implement 837 IPsec, 4300-series RFCs (IPsec v3, IKEv2). 839 2.4. Conventions 841 In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator 842 and target respectively. 844 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 845 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 846 in this document are to be interpreted as described in RFC 2119 847 [RFC2119]. 849 iSCSI messages - PDUs - are represented by diagrams as in the 850 following example: 852 Byte/ 0 | 1 | 2 | 3 853 | 854 / | | | 855 | 856 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 857 +---------------+---------------+---------------+---------------+ 858 0| Basic Header Segment (BHS) | 859 +---------------+---------------+---------------+---------------+ 860 ---------- 861 +| | 862 +---------------+---------------+---------------+---------------+ 863 The diagrams include byte and bit numbering. 865 The following representation and ordering rules are observed in 866 this document: 868 - Word Rule 870 - Half-word Rule 872 - Byte Rule 874 2.4.1. Word Rule 876 A word holds four consecutive bytes. Whenever a word has numeric 877 content, it is considered an unsigned number in base 2 positional 878 representation with the lowest numbered byte (e.g., byte 0) bit 0 879 representing 2**31 and bit 1 representing 2**30 through lowest 880 numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0. 882 Decimal and hexadecimal representation of word values map this 883 representation to decimal or hexadecimal positional notation. 885 2.4.2. Half-Word Rule 887 A half-word holds two consecutive bytes. Whenever a half-word has 888 numeric content it is considered an unsigned number in base 2 889 positional representation with the lowest numbered byte (e.g., 890 byte 0) bit 0 representing 2**15 and bit 1 representing 2**14 891 through lowest numbered byte + 1 (e.g., byte 1) bit 7 representing 892 2**0. 894 Decimal and hexadecimal representation of half-word values map 895 this representation to decimal or hexadecimal positional notation. 897 2.4.3. Byte Rule 899 For every PDU, bytes are sent and received in increasing numbered 900 order (network order). 902 Whenever a byte has numerical content it is considered an unsigned 903 number in base 2 positional representation with bit 0 representing 904 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0. 906 3. UML Conventions 908 3.1. UML Conventions Overview 910 The SCSI Architecture Model (SAM) uses class diagrams and object 911 diagrams with notation that is based on the Unified Modeling 912 Language [UML]. Therefore, this document also uses UML to model 913 the relationships for SCSI and iSCSI objects. 915 A treatise on the graphical notation used in UML is beyond the 916 scope of this document. However, given the use of ASCII drawing 917 for UML static class diagrams, a description of the notational 918 conventions used in this document is included in the remainder of 919 this section. 921 3.2. Multiplicity Notion 923 Not specified The number of instances of an attribute is not 924 specified. 926 1 One instance of the class or attribute exists. 928 0..* Zero or more instances of the class or attribute exist. 930 1..* One or more instances of the class or attribute exist. 932 0..1 Zero or one instance of the class or attribute exists. 934 n..m n to m instances of the class or attribute exist 935 (e.g., 2..8). 937 x, n..m Multiple disjoint instances of the class or 938 attribute exist (e.g., 2, 8..15). 940 3.3. Class Diagram Conventions 942 +--------------+ +--------------+ +--------------+ 943 | Class Name | | Class Name | | Class Name | 944 +--------------+ +--------------+ +--------------+ 945 | | | | 946 +--------------+ +--------------+ 947 | | 948 +--------------+ 949 The previous three diagrams are examples of a class with no 950 attributes and with no operations. 952 +-------------------+ +-------------------+ 953 | Class Name | | Class Name | 954 +-------------------+ +-------------------+ 955 | attribute 01[1] | | attribute 01[1] | 956 | attribute 02[1] | | attribute 02[1] | 957 +-------------------+ +-------------------+ 958 | | 959 +-------------------+ 960 The preceding two diagrams are examples of a class with attributes 961 and with no operations. 963 +------------------------+ 964 | Class Name | 965 +------------------------+ 966 | attribute 01[1..*] | 967 | attribute 02[1] | 968 +------------------------+ 969 | operation 01() | 970 | operation 02() | 971 +------------------------+ 972 The preceding diagram is an example of a class with attributes 973 that have a specified multiplicity and operations. 975 3.4. Class Diagram Notation for Associations 977 +-----------------+ 978 | Class A | 979 +-----------------+ association_name +-----------------+ 980 | attribute 01[1] |<------------------>| Class B | 981 | attribute 02[1] | 1..* 0..1 +-----------------+ 982 +-----------------+ | attribute 03[1] | 983 | operation 1() | +-----------------+ 984 +-----------------+ 985 The preceding diagram is an example where Class A knows about 986 Class B (i.e., read as "Class A association_name ClassB") and 987 Class B knows about Class A (i.e., read as "Class B 988 association_name Class A"). The use of association_name is 989 optional. The multiplicity notation (1..* and 0..1) indicates the 990 number of instances of the object. 992 +--------------------+ 993 | Class A | 994 +--------------------+ +--------------------+ 995 | attribute 01[1] |<-------------| Class B | 996 | attribute 02[1] | 1 0..1 +--------------------+ 997 +--------------------+ | attribute 03[1] | 998 | operation 1() | +--------------------+ 999 +--------------------+ 1000 The preceding diagram is an example where Class B knows about 1001 Class A (i.e., read as "Class B knows about Class A") but Class A 1002 does not know about Class B. 1004 +----------------------+ 1005 | Class A | 1006 +----------------------+ +--------------------+ 1007 | attribute 01[1] |----------->| Class B | 1008 | attribute 02[1] | 0..* 1 +--------------------+ 1009 +----------------------+ | attribute 03[1] | 1010 | operation 1() | +--------------------+ 1011 +----------------------+ 1012 The preceding diagram is an example where Class A knows about 1013 Class B (i.e., read as "Class A knows about Class B") but Class B 1014 does not know about Class A. 1016 3.5. Class Diagram Notation for Aggregations 1018 +---------------+ +--------------+ 1019 | Class whole |o------------| Class part | 1020 +---------------+ +--------------+ 1021 The preceding diagram is an example where Class whole is an 1022 aggregate that contains Class part and where Class part may 1023 continue to exist even if Class whole is removed (i.e., read as 1024 "the whole contains the part"). 1026 +---------------+ +--------------+ 1027 | Class whole |@------------| Class part | 1028 +---------------+ +--------------+ 1029 The preceding diagram is an example where Class whole is an 1030 aggregate that contains Class part where Class part shall only 1031 belong to one Class whole, and the Class part shall not continue 1032 to exist if the Class whole is removed (i.e., read as "the whole 1033 contains the part"). 1035 +-------------+ 1036 | | 1037 +-------------+ 1038 | | 1039 + =(a)= + 1040 | | 1041 The preceding diagram is an example where there is a constraint 1042 between the associations where the (a) footnote describes the 1043 constraint. 1045 3.6. Class Diagram Notation for Generalizations 1047 +---------------+ 1048 | Superclass | 1049 +-------^-------+ 1050 /_\ 1051 | 1052 +---------------+ 1053 | Subclass | 1054 +---------------+ 1055 The preceding diagram is an example where the subclass is a kind 1056 of superclass. A subclass shares all the attributes and 1057 operations of the superclass (i.e., the subclass inherits from the 1058 superclass). 1060 4. Overview 1062 4.1. SCSI Concepts 1064 The SCSI Architecture Model-2 [SAM2] describes in detail the 1065 architecture of the SCSI family of I/O protocols. This section 1066 provides a brief background of the SCSI architecture and is 1067 intended to familiarize readers with its terminology. 1069 At the highest level, SCSI is a family of interfaces for 1070 requesting services from I/O devices, including hard drives, tape 1071 drives, CD and DVD drives, printers, and scanners. In SCSI 1072 terminology, an individual I/O device is called a "logical unit" 1073 (LU). 1075 SCSI is a client-server architecture. Clients of a SCSI interface 1076 are called "initiators". Initiators issue SCSI "commands" to 1077 request services from components, logical units, of a server known 1078 as a "target". The "device server" on the logical unit accepts 1079 SCSI commands and processes them. 1081 A "SCSI transport" maps the client-server SCSI protocol to a 1082 specific interconnect. Initiator is one endpoint of a SCSI 1083 transport. The "target" is the other endpoint. A target can 1084 contain multiple Logical Units (LUs). Each Logical Unit has an 1085 address within a target called a Logical Unit Number (LUN). 1087 A SCSI task is a SCSI command or possibly a linked set of SCSI 1088 commands. Some LUs support multiple pending (queued) tasks, but 1089 the queue of tasks is managed by the logical unit. The target uses 1090 an initiator provided "task tag" to distinguish between tasks. 1091 Only one command in a task can be outstanding at any given time. 1093 Each SCSI command results in an optional data phase and a required 1094 response phase. In the data phase, information can travel from the 1095 initiator to target (e.g., WRITE), target to initiator (e.g., 1096 READ), or in both directions. In the response phase, the target 1097 returns the final status of the operation, including any errors. 1099 Command Descriptor Blocks (CDB) are the data structures used to 1100 contain the command parameters that an initiator sends to a 1102 target. The CDB content and structure is defined by [SAM2] and 1103 device-type specific SCSI standards. 1105 4.2. iSCSI Concepts and Functional Overview 1107 The iSCSI protocol is a mapping of the SCSI command, event and 1108 task management model (see [SAM2]) over the TCP protocol. SCSI 1109 commands are carried by iSCSI requests and SCSI responses and 1110 status are carried by iSCSI responses. iSCSI also uses the request 1111 response mechanism for iSCSI protocol mechanisms. 1113 For the remainder of this document, the terms "initiator" and 1114 "target" refer to "iSCSI initiator node" and "iSCSI target node", 1115 respectively (see iSCS) unless otherwise qualified. 1117 In keeping with similar protocols, the initiator and target divide 1118 their communications into messages. This document uses the term 1119 "iSCSI protocol data unit" (iSCSI PDU) for these messages. 1121 For performance reasons, iSCSI allows a "phase-collapse". A 1122 command and its associated data may be shipped together from 1123 initiator to target, and data and responses may be shipped 1124 together from targets. 1126 The iSCSI transfer direction is defined with respect to the 1127 initiator. Outbound or outgoing transfers are transfers from an 1128 initiator to a target, while inbound or incoming transfers are 1129 from a target to an initiator. 1131 An iSCSI task is an iSCSI request for which a response is 1132 expected. 1134 In this document "iSCSI request", "iSCSI command", request, or 1135 (unqualified) command have the same meaning. Also, unless 1136 otherwise specified, status, response, or numbered response have 1137 the same meaning. 1139 4.2.1. Layers and Sessions 1141 The following conceptual layering model is used to specify 1142 initiator and target actions and the way in which they relate to 1143 transmitted and received Protocol Data Units: 1145 the SCSI layer builds/receives SCSI CDBs (Command Descriptor 1146 Blocks) and passes/receives them with the remaining command 1147 execute parameters ([SAM2]) to/from 1148 the iSCSI layer that builds/receives iSCSI PDUs and 1149 relays/receives them to/from one or more TCP connections; 1150 the group of connections form an initiator-target 1151 "session". 1153 Communication between the initiator and target occurs over one or 1154 more TCP connections. The TCP connections carry control messages, 1155 SCSI commands, parameters, and data within iSCSI Protocol Data 1156 Units (iSCSI PDUs). The group of TCP connections that link an 1157 initiator with a target form a session (equivalent to a SCSI I_T 1158 nexus, see SCSI ). A session is defined by a session ID that is 1159 composed of an initiator part and a target part. TCP connections 1160 can be added and removed from a session. Each connection within a 1161 session is identified by a connection ID (CID). 1163 Across all connections within a session, an initiator sees one 1164 "target image". All target identifying elements, such as LUN, are 1165 the same. A target also sees one "initiator image" across all 1166 connections within a session. Initiator-identifying elements, such 1167 as the Initiator Task Tag, are global across the session 1168 regardless of the connection on which they are sent or received. 1170 iSCSI targets and initiators MUST support at least one TCP 1171 connection and MAY support several connections in a session. For 1172 error recovery purposes, targets and initiators that support a 1173 single active connection in a session SHOULD support two 1174 connections during recovery. 1176 4.2.2. Ordering and iSCSI Numbering 1178 iSCSI uses Command and Status numbering schemes and a Data 1179 sequencing scheme. 1181 Command numbering is session-wide and is used for ordered command 1182 delivery over multiple connections. It can also be used as a 1183 mechanism for command flow control over a session. 1185 Status numbering is per connection and is used to enable missing 1186 status detection and recovery in the presence of transient or 1187 permanent communication errors. 1189 Data sequencing is per command or part of a command (R2T-triggered 1190 sequence) and is used to detect missing data and/or R2T PDUs due 1191 to header digest errors. 1193 Typically, fields in the iSCSI PDUs communicate the Sequence 1194 Numbers between the initiator and target. During periods when 1195 traffic on a connection is unidirectional, iSCSI NOP-Out/In PDUs 1196 may be utilized to synchronize the command and status ordering 1197 counters of the target and initiator. 1199 The iSCSI session abstraction is equivalent to the SCSI I_T nexus, 1200 and the iSCSI session provides an ordered command delivery from 1201 the SCSI initiator to the SCSI target. For detailed design 1202 considerations that led to the iSCSI session model as it is 1203 defined here and how it relates the SCSI command ordering features 1204 defined in SCSI specifications to the iSCSI concepts see 1205 [RFC3783]. 1207 4.2.2.1. Command Numbering and Acknowledging 1209 iSCSI performs ordered command delivery within a session. All 1210 commands (initiator-to-target PDUs) in transit from the initiator 1211 to the target are numbered. 1213 iSCSI considers a task to be instantiated on the target in 1214 response to every request issued by the initiator. A set of task 1215 management operations including abort and reassign (see Section 1216 11.5"Task Management Function Request") may be performed on any 1217 iSCSI task. 1219 Some iSCSI tasks are SCSI tasks, and many SCSI activities are 1220 related to a SCSI task ([SAM2]). In all cases, the task is 1221 identified by the Initiator Task Tag for the life of the task. 1223 The command number is carried by the iSCSI PDU as CmdSN (Command- 1224 Sequence-Number). The numbering is session-wide. Outgoing iSCSI 1225 PDUs carry this number. The iSCSI initiator allocates CmdSNs with 1226 a 32-bit unsigned counter (modulo 2**32). Comparisons and 1227 arithmetic on CmdSN use Serial Number Arithmetic as defined in 1228 [RFC1982] where SERIAL_BITS = 32. 1230 Commands meant for immediate delivery are marked with an immediate 1231 delivery flag; they MUST also carry the current CmdSN. CmdSN does 1232 not advance after a command marked for immediate delivery is sent. 1234 Command numbering starts with the first login request on the first 1235 connection of a session (the leading login on the leading 1236 connection) and command numbers are incremented by 1 for every 1237 non-immediate command issued afterwards. 1239 If immediate delivery is used with task management commands, these 1240 commands may reach the target before the tasks on which they are 1241 supposed to act. However their CmdSN serves as a marker of their 1242 position in the stream of commands. The initiator and target must 1243 ensure that the task management commands act as specified by 1244 [SAM2]. For example, both commands and responses appear as if 1245 delivered in order. Whenever CmdSN for an outgoing PDU is not 1246 specified by an explicit rule, CmdSN will carry the current value 1247 of the local CmdSN variable (see later in this section). 1249 The means by which an implementation decides to mark a PDU for 1250 immediate delivery or by which iSCSI decides by itself to mark a 1251 PDU for immediate delivery are beyond the scope of this document. 1253 The number of commands used for immediate delivery is not limited 1254 and their delivery to execution is not acknowledged through the 1255 numbering scheme. Immediate commands MAY be rejected by the iSCSI 1256 target layer due to lack of resources. An iSCSI target MUST be 1257 able to handle at least one immediate task management command and 1258 one immediate non-task-management iSCSI command per connection at 1259 any time. 1261 In this document, delivery for execution means delivery to the 1262 SCSI execution engine or an iSCSI protocol specific execution 1263 engine (e.g., for text requests with public or private extension 1264 keys involving an execution component). With the exception of the 1265 commands marked for immediate delivery, the iSCSI target layer 1266 MUST deliver the commands for execution in the order specified by 1267 CmdSN. Commands marked for immediate delivery may be delivered by 1268 the iSCSI target layer for execution as soon as detected. iSCSI 1269 may avoid delivering some commands to the SCSI target layer if 1270 required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET 1271 Task Management request received before all the commands on which 1272 it was supposed to act). 1274 On any connection, the iSCSI initiator MUST send the commands in 1275 increasing order of CmdSN, except for commands that are 1276 retransmitted due to digest error recovery and connection 1277 recovery. 1279 For the numbering mechanism, the initiator and target maintain the 1280 following three variables for each session: 1282 - CmdSN - the current command Sequence Number, advanced by 1 1283 on each command shipped except for commands marked for 1284 immediate delivery. CmdSN always contains the number to be 1285 assigned to the next Command PDU. 1287 - ExpCmdSN - the next expected command by the target. The 1288 target acknowledges all commands up to, but not including, 1289 this number. The initiator treats all commands with CmdSN 1290 less than ExpCmdSN as acknowledged. The target iSCSI layer 1291 sets the ExpCmdSN to the largest non-immediate CmdSN that it 1292 can deliver for execution "plus 1" per [RFC1982]. There 1293 MUST NOT be any holes in the acknowledged CmdSN sequence. 1295 - MaxCmdSN - the maximum number to be shipped. The queuing 1296 capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN 1297 + 1. 1299 The initiator's ExpCmdSN and MaxCmdSN are derived from target-to- 1300 initiator PDU fields. Comparisons and arithmetic on ExpCmdSN and 1301 MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] 1302 where SERIAL_BITS = 32. 1304 The target MUST NOT transmit a MaxCmdSN that is less than 1305 ExpCmdSN-1. For non-immediate commands, the CmdSN field can take 1306 any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST 1307 silently ignore any non-immediate command outside of this range or 1308 non-immediate duplicates within the range. The CmdSN carried by 1309 immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. 1310 For example, if the initiator has previously sent a non-immediate 1311 command carrying the CmdSN equal to MaxCmdSN, the target window is 1312 closed. For group task management commands issued as immediate 1313 commands, CmdSN indicates the scope of the group action (e.g., on 1314 ABORT TASK SET indicates which commands are to be aborted). 1316 MaxCmdSN and ExpCmdSN fields are processed by the initiator as 1317 follows: 1319 -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in 1320 Serial Arithmetic Sense), they are both ignored. 1322 -If the PDU MaxCmdSN is greater than the local MaxCmdSN (in 1323 Serial Arithmetic Sense), it updates the local MaxCmdSN; 1324 otherwise, it is ignored. 1326 -If the PDU ExpCmdSN is greater than the local ExpCmdSN (in 1327 Serial Arithmetic Sense), it updates the local ExpCmdSN; 1328 otherwise, it is ignored. 1330 This sequence is required because updates may arrive out of order 1331 (e.g., the updates are sent on different TCP connections). 1333 iSCSI initiators and targets MUST support the command numbering 1334 scheme. 1336 A numbered iSCSI request will not change its allocated CmdSN, 1337 regardless of the number of times and circumstances in which it is 1338 reissued (see Section 7.2.1"Usage of Retry"). At the target, CmdSN 1339 is only relevant while the command has not created any state 1340 related to its execution (execution state); afterwards, CmdSN 1341 becomes irrelevant. Testing for the execution state (represented 1342 by identifying the Initiator Task Tag) MUST precede any other 1343 action at the target. If no execution state is found, it is 1344 followed by ordering and delivery. If an execution state is found, 1345 it is followed by delivery if it has not already been delivered. 1347 If an initiator issues a command retry for a command with CmdSN R 1348 on 1349 a connection when the session CmdSN value is Q, it MUST NOT 1350 advance the CmdSN past R + 2**31 -1 unless the connection is no 1351 longer operational (i.e., it has returned to the FREE state, see 1352 Section 8.1.3 "Standard Connection State Diagram for an 1353 Initiator"), the connection has been reinstated (see Section 6.3.4 1354 "Connection Reinstatement"), or a non-immediate command with CmdSN 1355 equal or greater than Q was issued subsequent to the command retry 1356 on the same connection and the reception of that command is 1357 acknowledged by the target (see Section 10.4"Command Retry and 1358 Cleaning Old Command Instances"). 1360 A target command response or Data-in PDU with status MUST NOT 1361 precede the command acknowledgement. However, the acknowledgement 1362 MAY be included in the response or the Data-in PDU. 1364 4.2.2.2. Response/Status Numbering and Acknowledging 1366 Responses in transit from the target to the initiator are 1367 numbered. The StatSN (Status Sequence Number) is used for this 1368 purpose. StatSN is a counter maintained per connection. ExpStatSN 1369 is used by the initiator to acknowledge status. The status 1370 sequence number space is 32-bit unsigned-integers and the 1371 arithmetic operations are the regular mod(2**32) arithmetic. 1373 Status numbering starts with the Login response to the first Login 1374 request of the connection. The Login response includes an initial 1375 value for status numbering (any initial value is valid). 1377 To enable command recovery, the target MAY maintain enough state 1378 information for data and status recovery after a connection 1379 failure. A target doing so can safely discard all of the state 1380 information maintained for recovery of a command after the 1381 delivery of the status for the command (numbered StatSN) is 1382 acknowledged through ExpStatSN. 1384 A large absolute difference between StatSN and ExpStatSN may 1385 indicate a failed connection. Initiators MUST undertake recovery 1386 actions if the difference is greater than an implementation 1387 defined constant that MUST NOT exceed 2**31-1. 1389 Initiators and Targets MUST support the response-numbering scheme. 1391 4.2.2.3. Response Ordering 1393 4.2.2.3.1. Need for Response Ordering 1395 Whenever an iSCSI session is composed of multiple connections, the 1396 Response PDUs (task responses or TMF responses) originating in 1397 the target SCSI layer are distributed onto the multiple 1398 connections by the target iSCSI layer according to iSCSI 1399 connection allegiance rules. This process generally may not 1400 preserve the ordering of the responses by the time they are 1401 delivered to the initiator SCSI layer. 1403 Since ordering is not expected across SCSI responses anyway, this 1404 approach works fine in the general case. However, to address the 1405 special cases where some ordering is desired by the SCSI layer, 1406 the following "Response Fence" semantics are defined with respect 1407 to handling SCSI response messages as they are handed off from the 1408 SCSI protocol layer to the iSCSI layer. 1410 4.2.2.3.2. Response Ordering Model Description 1412 The target SCSI protocol layer hands off the SCSI response 1413 messages to the target iSCSI layer by invoking the "Send Command 1414 Complete" protocol data service ([SAM2], clause 5.4.2) and "Task 1415 Management Function Executed" ([SAM2], clause 6.9) service. On 1416 receiving the SCSI response message, the iSCSI layer exhibits the 1417 Response Fence behavior for certain SCSI response messages 1418 (Section 4.2.2.3.4 describes the specific instances where the 1419 semantics must be realized). 1421 Whenever the Response Fence behavior is required for a SCSI 1422 response message, the target iSCSI layer MUST ensure that the 1423 following conditions are met in delivering the response message to 1424 the initiator iSCSI layer: 1426 Response with Response Fence MUST be delivered chronologically 1427 after all the "preceding" responses on the I_T_L nexus, if 1428 the preceding responses are delivered at all, to the 1429 initiator iSCSI layer. 1430 Response with Response Fence MUST be delivered chronologically 1431 prior to all the "following" responses on the I_T_L nexus. 1433 The "preceding" and "following" notions refer to the order of 1434 handoff of a response message from the target SCSI protocol layer 1435 to the target iSCSI layer. 1437 4.2.2.3.3. iSCSI Semantics with the Interface Model 1439 Whenever the TaskReporting key (Section 13.23"Task Reporting") is 1440 negotiated to ResponseFence or FastAbort for an iSCSI session and 1441 the Response Fence behavior is required for a SCSI response 1442 message, the target iSCSI layer MUST perform the actions described 1443 in this section for that session. 1445 If it is a single-connection session, no special processing is 1446 required. The standard SCSI Response PDU build and dispatch 1447 process happens. 1448 If it is a multi-connection session, the target iSCSI layer 1449 takes note of the last-sent and unacknowledged StatSN on 1450 each of the connections in the iSCSI session, and waits for 1451 an acknowledgement (NOP-In PDUs MAY be used to solicit 1452 acknowledgements as needed in order to accelerate this 1453 process) of each such StatSN to clear the fence. The SCSI 1454 response requiring Response Fence behavior MUST NOT be sent 1455 to the initiator before acknowledgements are received for 1456 each of the unacknowledged StatSNs. 1457 The target iSCSI layer must wait for an acknowledgement of the 1458 SCSI Response PDU that carried the SCSI response requiring 1459 the Response Fence behavior. The fence MUST be considered 1460 cleared only after receiving the acknowledgement. 1461 All further status processing for the LU is resumed only after 1462 clearing the fence. If any new responses for the I_T_L 1463 nexus are received from the SCSI layer before the fence is 1464 cleared, those Response PDUs MUST be held and queued at the 1465 iSCSI layer until the fence is cleared. 1467 4.2.2.3.4. Current List of Fenced Response Use Cases 1468 This section lists the fenced response use cases that iSCSI 1469 implementations MUST comply with. However, this is not an 1470 exhaustive enumeration. It is expected that as SCSI protocol 1471 specifications evolve, the specifications will specify when 1472 response fencing is required on a case-by-case basis. 1474 Whenever the TaskReporting key (Section 13.23) is negotiated to 1475 ResponseFence or FastAbort for an iSCSI session, the target iSCSI 1476 layer MUST assume that the Response Fence is required for the 1477 following SCSI completion messages: 1479 1. The first completion message carrying the UA after the 1480 multi-task abort on issuing and third-party sessions. See 1481 Section 4.2.3.2 for related TMF discussion. 1483 2. The TMF Response carrying the multi-task TMF Response on 1484 the issuing session. 1486 3. The completion message indicating ACA establishment on the 1487 issuing session. 1489 4. The first completion message carrying the ACA ACTIVE status 1490 after ACA establishment on issuing and third-party 1491 sessions. 1493 5. The TMF Response carrying the Clear ACA response on the 1494 issuing session. 1496 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 1497 command. 1499 Note: 1500 - Due to the absence of ACA-related fencing requirements in 1501 [RFC3720], initiator implementations SHOULD NOT use ACA on 1502 multi-connection iSCSI sessions with targets complying only 1503 with [RFC3720]. 1505 - Initiators that want to employ ACA on multi-connection iSCSI 1506 sessions SHOULD first assess response-fencing behavior via 1507 negotiating for ResponseFence or FastAbort values for the 1508 TaskReporting (Section 13.23) key. 1510 4.2.2.4. Data Sequencing 1512 Data and R2T PDUs transferred as part of some command execution 1513 MUST be sequenced. The DataSN field is used for data sequencing. 1514 For input (read) data PDUs, DataSN starts with 0 for the first 1515 data PDU of an input command and advances by 1 for each subsequent 1516 data PDU. For output data PDUs, DataSN starts with 0 for the first 1517 data PDU of a sequence (the initial unsolicited sequence or any 1518 data PDU sequence issued to satisfy an R2T) and advances by 1 for 1519 each subsequent data PDU. R2Ts are also sequenced per command. For 1520 example, the first R2T has an R2TSN of 0 and advances by 1 for 1521 each subsequent R2T. For bidirectional commands, the target uses 1522 the DataSN/R2TSN to sequence Data-In and R2T PDUs in one 1523 continuous sequence (undifferentiated). Unlike command and status, 1524 data PDUs and R2Ts are not acknowledged by a field in regular 1525 outgoing PDUs. Data-In PDUs can be acknowledged on demand by a 1526 special form of the SNACK PDU. Data and R2T PDUs are implicitly 1527 acknowledged by status for the command. The DataSN/R2TSN field 1528 enables the initiator to detect missing data or R2T PDUs. 1530 For any read or bidirectional command, a target MUST issue less 1531 than 2**32 combined R2T and Data-In PDUs. Any output data sequence 1532 MUST contain less than 2**32 Data-Out PDUs. 1534 4.2.3. iSCSI Task Management 1536 4.2.3.1. Task Management Overview 1538 iSCSI task management features allow an initiator to control the 1539 active iSCSI tasks on an operational iSCSI session that it has 1540 with an iSCSI target. Section 11.5 defines the task management 1541 function types that this specification defines - ABORT TASK, ABORT 1542 TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET 1543 WARM RESET, TARGET COLD RESET, and TASK REASSIGN. 1545 Out of these function types, ABORT TASK and TASK REASSIGN 1546 functions manage a single active task, whereas ABORT TASK SET, 1547 CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET and TARGET 1548 COLD RESET functions can each potentially affect multiple active 1549 tasks. 1551 4.2.3.2. Notion of Affected Tasks 1553 This section defines the notion of "affected tasks" in multi-task 1554 abort scenarios. Scope definitions in this section apply to both 1555 the Standard Multi-task Abort semantics (Section 4.2.3.3) and the 1556 FastAbort Multi-task Abort semantics behavior (Section 4.2.3.4). 1558 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 1559 identified by the LUN field in the ABORT TASK SET TMF Request PDU 1560 (Section 11.5). 1562 CLEAR TASK SET: All outstanding tasks in the task set for the LU 1563 identified by the LUN field in the CLEAR TASK SET TMF Request PDU. 1564 See [SPC3] for the definition of a "task set". 1566 LOGICAL UNIT RESET: All outstanding tasks from all initiators for 1567 the LU identified by the LUN field in the LOGICAL UNIT RESET 1568 Request PDU. 1570 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from 1571 all initiators across all LUs to which the TMF-issuing session has 1572 access on the SCSI target device hosting the iSCSI session. 1574 Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text 1575 is an iSCSI TMF Request PDU with the "Function" field set to 1576 "ABORT TASK SET" as defined in Section 11.5. Similar usage is 1577 employed for other scope descriptions. 1579 4.2.3.3. Standard Multi-task Abort Semantics 1581 All iSCSI implementations MUST support the protocol behavior 1582 defined in this section as the default behavior. The execution of 1583 ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM 1584 RESET, and TARGET COLD RESET TMF Requests consists of the 1585 following sequence of actions in the specified order on the 1586 specified party. 1588 The initiator iSCSI layer: 1589 a. MUST continue to respond to each TTT received for the 1590 affected tasks. 1591 b. SHOULD process any responses received for affected tasks in 1592 the normal fashion. This is acceptable because the 1593 responses are guaranteed to have been sent prior to the TMF 1594 response. 1595 c. SHOULD receive the TMF Response concluding all the tasks in 1596 the set of affected tasks unless the initiator has done 1597 something (e.g., LU reset, connection drop) that may 1598 prevent the TMF Response from being sent or received. The 1599 initiator MUST thus conclude all affected tasks as part of 1600 this step in either case, and MUST discard any TMF Response 1601 received after the affected tasks are concluded. 1603 The target iSCSI layer: 1604 a. MUST wait for responses on currently valid target-transfer 1605 tags of the affected tasks from the issuing initiator. MAY 1606 wait for responses on currently valid target-transfer tags 1607 of the affected tasks from third-party initiators. 1608 b. MUST wait (concurrent with the wait in Step a) for all 1609 commands of the affected tasks to be received based on the 1610 CmdSN ordering. SHOULD NOT wait for new commands on third- 1611 party affected sessions -- only the instantiated tasks have 1612 to be considered for the purpose of determining the 1613 affected tasks. In the case of target-scoped requests 1614 (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the 1615 commands that are not yet received on the issuing session 1616 in the command stream however can be considered to have 1617 been received with no command waiting period -- i.e., the 1618 entire CmdSN space up to the CmdSN of the task management 1619 function can be "plugged". 1620 c. MUST propagate the TMF request to and receive the response 1621 from the target SCSI layer. 1622 d. MUST provide the Response Fence behavior for the TMF 1623 Response on the issuing session as specified in Section 1624 4.2.2.3.2. 1625 e. MUST provide the Response Fence behavior on the first post- 1626 TMF Response on third-party sessions as specified in 1627 Section 4.2.2.3.3. If some tasks originate from non-iSCSI 1628 I_T_L nexuses, then the means by which the target ensures 1629 that all affected tasks have returned their status to the 1630 initiator are defined by the specific non-iSCSI transport 1631 protocol(s). 1633 Technically, the TMF servicing is complete in Step d. Data 1634 transfers corresponding to terminated tasks may however still be 1635 in progress on third-party iSCSI sessions even at the end of Step 1636 e. The TMF Response MUST NOT be sent by the target iSCSI layer 1637 before the end of Step d, and MAY be sent at the end of Step d 1638 despite these outstanding data transfers until after Step e. 1640 4.2.3.4. FastAbort Multi-task Abort Semantics 1642 Protocol behavior defined in this section SHOULD be implemented by 1643 all iSCSI implementations complying with this document. Protocol 1644 behavior defined in this section MUST be exhibited by iSCSI 1645 implementations on an iSCSI session when they negotiate the 1646 TaskReporting (Section 13.23) key to "FastAbort" on that session. 1647 The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT 1648 RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests 1649 consists of the following sequence of actions in the specified 1650 order on the specified party. 1652 The initiator iSCSI layer: 1653 a. MUST NOT send any more Data-Out PDUs for affected tasks on 1654 the issuing connection of the issuing iSCSI session once 1655 the TMF is sent to the target. 1656 b. SHOULD process any responses received for affected tasks in 1657 the normal fashion. This is acceptable because the 1658 responses are guaranteed to have been sent prior to the TMF 1659 response. 1660 c. MUST respond to each Async Message PDU with FAST_ABORT 1661 AsyncEvent as defined in Section 11.9. 1662 d. MUST treat the TMF response as terminating all affected 1663 tasks for which responses have not been received, and MUST 1664 discard any responses for affected tasks received after the 1665 TMF response is passed to the SCSI layer (although the 1666 semantics defined in this section ensure that such an out- 1667 of-order scenario will never happen with a compliant target 1668 implementation). 1670 The target iSCSI layer: 1671 a. MUST wait for all commands of the affected tasks to be 1672 received based on the CmdSN ordering on the issuing 1673 session. SHOULD NOT wait for new commands on third-party 1674 affected sessions - only the instantiated tasks have to be 1675 considered for the purpose of determining the affected 1676 tasks. In the case of target-scoped requests (i.e., TARGET 1677 WARM RESET and TARGET COLD RESET), all the commands that 1678 are not yet received on the issuing session in the command 1679 stream can be considered to have been received with no 1680 command waiting period -- i.e., the entire CmdSN space up 1681 to the CmdSN of the task management function can be 1682 "plugged". 1683 b. MUST propagate the TMF request to and receive the response 1684 from the target SCSI layer. 1685 c. MUST leave all active "affected TTTs" (i.e., active TTTs 1686 associated with affected tasks) valid. 1687 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 1688 (Section 11.9) on: 1689 i) each connection of each third-party session to 1690 which at least one affected task is allegiant if 1691 TaskReporting=FastAbort is operational on that third- 1692 party session, and, 1693 ii) each connection except the issuing connection of 1694 the issuing session that has at least one allegiant 1695 affected task. 1696 If there are multiple affected LUs (say, due to a target 1697 reset), then one Async Message PDU MUST be sent for each 1698 such LU on each connection that has at least one allegiant 1699 affected task. The LUN field in the Asynchronous Message PDU 1700 MUST be set to match the LUN for each such LU. 1701 e. MUST address the Response Fence flag on the TMF Response on 1702 the issuing session as defined in Section 4.2.2.3.3. 1703 f. MUST address the Response Fence flag on the first post-TMF 1704 Response on third-party sessions as defined in Section 1705 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L 1706 nexuses, then the means by which the target ensures that 1707 all affected tasks have returned their status to the 1708 initiator are defined by the specific non-iSCSI transport 1709 protocol(s). 1710 g. MUST free up the affected TTTs (and STags, if applicable) 1711 and the corresponding buffers, if any, once it receives 1712 each associated NOP-Out acknowledgement that the initiator 1713 generated in response to each Async Message. 1715 Technically, the TMF servicing is complete in Step e. Data 1716 transfers corresponding to terminated tasks may however still be 1717 in progress even at the end of Step f. A TMF Response MUST NOT be 1718 sent by the target iSCSI layer before the end of Step e, and MAY 1719 be sent at the end of Step e despite these outstanding Data 1720 transfers until Step g. Step g specifies an event to free up any 1721 such resources that may have been reserved to support outstanding 1722 data transfers. 1724 4.2.3.5. Affected Tasks Shared across Standard and FastAbort Sessions 1726 If an iSCSI target implementation is capable of supporting 1727 TaskReporting=FastAbort functionality (Section 13.23), it may end 1728 up in a situation where some sessions have TaskReporting=RFC3720 1729 operational (RFC 3720 sessions) while some other sessions have 1730 TaskReporting=FastAbort operational (FastAbort sessions) even 1731 while accessing a shared set of affected tasks (Section 4.2.3.2). 1732 If the issuing session is an RFC 3720 session, the iSCSI target 1733 implementation is FastAbort-capable, and the third-party affected 1734 session is a FastAbort session, the following behavior SHOULD be 1735 exhibited by the iSCSI target layer: 1736 a. Between Steps c and d of the target behavior in Section 1737 4.2.3.3, send an Asynchronous Message PDU with AsyncEvent=5 1738 (Section 11.9) on each connection of each third-party 1739 session to which at least one affected task is allegiant. 1740 If there are multiple affected LUs, then send one Async 1741 Message PDU for each such LU on each connection that has at 1742 least one allegiant affected task. When sent, the LUN field 1743 in the Asynchronous Message PDU MUST be set to match the 1744 LUN for each such LU. 1745 b. After Step e of the target behavior in Section 4.2.3.3, 1746 free up the affected TTTs (and STags, if applicable) and 1747 the corresponding buffers, if any, once each associated 1748 NOP-Out acknowledgement is received that the third-party 1749 initiator generated in response to each Async Message sent 1750 in Step a. 1752 If the issuing session is a FastAbort session, the iSCSI target 1753 implementation is FastAbort-capable, and the third-party affected 1754 session is an RFC 3720 session, the following behavior MUST be 1755 exhibited by the iSCSI target layer: Asynchronous Message PDUs 1756 MUST NOT be sent on the third-party session to prompt the 1757 FastAbort behavior. 1759 If the third-party affected session is a FastAbort session and the 1760 issuing session is a FastAbort session, the initiator in the 1761 third-party role MUST respond to each Async Message PDU with 1762 AsyncEvent=5 as defined in Section 11.9. Note that an initiator 1763 MAY thus receive these Async Messages on a third-party affected 1764 session even if the session is a single-connection session. 1766 4.2.3.6. Rationale behind the FastAbort Semantics 1768 There are fundamentally three basic objectives behind the 1769 semantics 1770 specified in Sections 4.2.3.3 and 4.2.3.4. 1771 1. Maintaining an ordered command flow I_T nexus abstraction 1772 to the target SCSI layer even with multi-connection 1773 sessions. 1774 - Target iSCSI processing of a TMF request must 1775 maintain the single flow illusion. Target behavior in 1776 Step b of Section 4.2.3.3 and Step aof Section 4.2.3.4 1777 correspond to this objective. 1778 2. Maintaining a single ordered response flow I_T nexus 1779 abstraction to the initiator SCSI layer even with multi- 1780 connection sessions when one response (i.e., TMF response) 1781 could imply the status of other unfinished tasks from the 1782 initiator's perspective. 1783 - The target must ensure that the initiator does not 1784 see "old" task responses (that were placed on the wire 1785 chronologically earlier than the TMF Response) after 1786 seeing the TMF response. The target behavior in Step d 1787 of Section 4.2.3.3 and Step e of Section 4.2.3.4 1788 correspond to this objective. 1789 - Whenever the result of a TMF action is visible across 1790 multiple I_T_L nexuses, [SAM2] requires the SCSI device 1791 server to trigger a UA on each of the other I_T_L 1792 nexuses. Once an initiator is notified of such an UA, 1793 the application client on the receiving initiator is 1794 required to clear its task state (clause 5.5 in [SAM2]) 1795 for the affected tasks. It would thus be inappropriate 1796 to deliver a SCSI Response for a task after the task 1797 state is cleared on the initiator, i.e., after the UA 1798 is notified. The UA notification contained in the first 1799 SCSI Response PDU on each affected Third-party I_T_L 1800 nexus after the TMF action thus MUST NOT pass the 1801 affected task responses on any of the iSCSI sessions 1802 accessing the LU. The target behavior in Step e of 1803 Section 4.2.3.3 and Step f of Section 4.2.3.4 1804 correspond to this objective. 1805 3. Draining all active TTTs corresponding to affected tasks in 1806 a deterministic fashion. 1807 - Data-Out PDUs with stale TTTs arriving after the 1808 tasks are terminated can create a buffer management 1809 problem even for traditional iSCSI implementations, and 1810 is fatal for the connection for iSCSI/iSER 1811 implementations. Either the termination of affected 1812 tasks should be postponed until the TTTs are retired 1813 (as in Step a of Section 4.2.3.3), or the TTTs and the 1814 buffers should stay allocated beyond task termination 1815 to be deterministically freed up later (as in Steps c 1816 and g of Section 4.2.3.4). 1818 The only other notable optimization is the plugging. If all tasks 1819 on an I_T nexus will be aborted anyway (as with a target reset), 1820 there is no need to wait to receive all commands to plug the CmdSN 1821 holes. The target iSCSI layer can simply plug all missing CmdSN 1822 slots and move on with TMF processing. The first objective 1823 (maintaining a single ordered command flow) is still met with this 1824 optimization because the target SCSI layer only sees ordered 1825 commands. 1827 4.2.4. iSCSI Login 1829 The purpose of the iSCSI login is to enable a TCP connection for 1830 iSCSI use, authentication of the parties, negotiation of the 1831 session's parameters and marking of the connection as belonging to 1832 an iSCSI session. 1834 A session is used to identify to a target all the connections with 1835 a given initiator that belong to the same I_T nexus. (For more 1837 details on how a session relates to an I_T nexus, see section 1838 4.4.2). 1840 The targets listen on a well-known TCP port or other TCP port for 1841 incoming connections. The initiator begins the login process by 1842 connecting to one of these TCP ports. 1844 As part of the login process, the initiator and target SHOULD 1845 authenticate each other and MAY set a security association 1846 protocol for the session. This can occur in many different ways 1847 and is subject to negotiation. 1849 To protect the TCP connection, an IPsec security association MAY 1850 be established before the Login request. For information on using 1851 IPsec security for iSCSI see Chapter 8 and [RFC3723]. 1853 The iSCSI Login Phase is carried through Login requests and 1854 responses. Once suitable authentication has occurred and 1855 operational parameters have been set, the session transitions to 1856 Full Feature Phase and the initiator may start to send SCSI 1857 commands. The security policy for whether, and by what means, a 1858 target chooses to authorize an initiator is beyond the scope of 1859 this document. For a more detailed description of the Login Phase, 1860 see Chapter 5. 1862 The login PDU includes the ISID part of the session ID (SSID). The 1863 target portal group that services the login is implied by the 1864 selection of the connection endpoint. For a new session, the TSIH 1865 is zero. As part of the response, the target generates a TSIH. 1867 During session establishment, the target identifies the SCSI 1868 initiator port (the "I" in the "I_T nexus") through the value pair 1869 (InitiatorName, ISID). We describe InitiatorName later in this 1870 section. Any persistent state (e.g., persistent reservations) on 1871 the target that is associated with a SCSI initiator port is 1872 identified based on this value pair. Any state associated with the 1873 SCSI target port (the "T" in the "I_T nexus") is identified 1874 externally by the TargetName and portal group tag (see Section 1875 4.4.1). ISID is subject to reuse restrictions because it is used 1876 to identify a persistent state (see Section 4.4.3). 1878 Before the Full Feature Phase is established, only Login Request 1879 and Login Response PDUs are allowed. Login requests and responses 1880 MUST be used exclusively during Login. On any connection, the 1881 login phase MUST immediately follow TCP connection establishment 1882 and a subsequent Login Phase MUST NOT occur before tearing down a 1883 connection. 1885 A target receiving any PDU except a Login request before the Login 1886 phase is started MUST immediately terminate the connection on 1887 which the PDU was received. Once the Login phase has started, if 1888 the target receives any PDU except a Login request, it MUST send a 1889 Login reject (with Status "invalid during login") and then 1890 disconnect. If the initiator receives any PDU except a Login 1891 response, it MUST immediately terminate the connection. 1893 4.2.5. iSCSI Full Feature Phase 1895 Once the initiator is authorized to do so, the iSCSI session is in 1896 the iSCSI Full Feature Phase. A session is in Full Feature Phase 1897 after successfully finishing the Login Phase on the first 1898 (leading) connection of a session. A connection is in Full Feature 1899 Phase if the session is in Full Feature Phase and the connection 1900 login has completed successfully. An iSCSI connection is not in 1901 Full Feature Phase 1903 when it does not have an established transport connection, 1904 OR 1905 when it has a valid transport connection, but a successful 1906 login was not performed or the connection is currently 1907 logged out. 1909 In a normal Full Feature Phase, the initiator may send SCSI 1910 commands and data to the various LUs on the target by 1911 encapsulating them in iSCSI PDUs that go over the established 1912 iSCSI session. 1914 4.2.5.1. Command Connection Allegiance 1916 For any iSCSI request issued over a TCP connection, the 1917 corresponding response and/or other related PDU(s) MUST be sent 1918 over the same connection. We call this "connection allegiance". If 1919 the original connection fails before the command is completed, the 1920 connection allegiance of the command may be explicitly reassigned 1921 to a different transport connection as described in detail in 1922 Section 7.2 "Retry and Reassign in Recovery". 1924 Thus, if an initiator issues a READ command, the target MUST send 1925 the requested data, if any, followed by the status to the 1926 initiator over the same TCP connection that was used to deliver 1927 the SCSI command. If an initiator issues a WRITE command, the 1928 initiator MUST send the data, if any, for that command over the 1929 same TCP connection that was used to deliver the SCSI command. The 1930 target MUST return Ready To Transfer (R2T), if any, and the status 1931 over the same TCP connection that was used to deliver the SCSI 1932 command. Retransmission requests (SNACK PDUs) and the data and 1933 status that they generate MUST also use the same connection. 1935 However, consecutive commands that are part of a SCSI linked 1936 command-chain task (see [SAM2]) MAY use different connections. 1937 Connection allegiance is strictly per-command and not per-task. 1938 During the iSCSI Full Feature Phase, the initiator and target MAY 1939 interleave unrelated SCSI commands, their SCSI Data, and responses 1940 over the session. 1942 4.2.5.2. Data Transfer Overview 1944 Outgoing SCSI data (initiator to target user data or command 1945 parameters) is sent as either solicited data or unsolicited data. 1946 Solicited data are sent in response to R2T PDUs. Unsolicited data 1947 can be sent as part of an iSCSI command PDU ("immediate data") or 1948 in separate iSCSI data PDUs. 1950 Immediate data are assumed to originate at offset 0 in the 1951 initiator SCSI write-buffer (outgoing data buffer). All other Data 1952 PDUs have the buffer offset set explicitly in the PDU header. 1954 An initiator may send unsolicited data up to FirstBurstLength as 1955 immediate (up to the negotiated maximum PDU length), in a separate 1956 PDU sequence or both. All subsequent data MUST be solicited. The 1957 maximum length of an individual data PDU or the immediate-part of 1958 the first unsolicited burst MAY be negotiated at login. 1960 The maximum amount of unsolicited data that can be sent with a 1961 command is negotiated at login through the FirstBurstLength key. A 1962 target MAY separately enable immediate data (through the 1963 ImmediateData key) without enabling the more general (separate 1964 data PDUs) form of unsolicited data (through the InitialR2T key). 1966 Unsolicited data on write are meant to reduce the effect of 1967 latency on throughput (no R2T is needed to start sending data). In 1968 addition, immediate data is meant to reduce the protocol overhead 1969 (both bandwidth and execution time). 1971 An iSCSI initiator MAY choose not to send unsolicited data, only 1972 immediate data or FirstBurstLength bytes of unsolicited data with 1973 a command. If any non-immediate unsolicited data is sent, the 1974 total unsolicited data MUST be either FirstBurstLength, or all of 1975 the data if the total amount is less than the FirstBurstLength. 1977 It is considered an error for an initiator to send unsolicited 1978 data PDUs to a target that operates in R2T mode (only solicited 1979 data are allowed). It is also an error for an initiator to send 1980 more unsolicited data, whether immediate or as separate PDUs, than 1981 FirstBurstLength. 1983 An initiator MUST honor an R2T data request for a valid 1984 outstanding command (i.e., carrying a valid Initiator Task Tag) 1985 and deliver all the requested data provided the command is 1986 supposed to deliver outgoing data and the R2T specifies data 1987 within the command bounds. The initiator action is unspecified for 1988 receiving an R2T request that specifies data, all or part, outside 1989 of the bounds of the command. 1991 A target SHOULD NOT silently discard data and then request 1992 retransmission through R2T. Initiators SHOULD NOT keep track of 1993 the data transferred to or from the target (scoreboarding). SCSI 1994 targets perform residual count calculation to check how much data 1995 was actually transferred to or from the device by a command. This 1996 may differ from the amount the initiator sent and/or received for 1997 reasons such as retransmissions and errors. Read or bidirectional 1998 commands implicitly solicit the transmission of the entire amount 1999 of data covered by the command. SCSI data packets are matched to 2000 their corresponding SCSI commands by using tags specified in the 2001 protocol. 2003 In addition, iSCSI initiators and targets MUST enforce some 2004 ordering rules. When unsolicited data is used, the order of the 2005 unsolicited data on each connection MUST match the order in which 2006 the commands on that connection are sent. Command and unsolicited 2007 data PDUs may be interleaved on a single connection as long as the 2008 ordering requirements of each are maintained (e.g., command N+1 2009 MAY be sent before the unsolicited Data-Out PDUs for command N, 2010 but the unsolicited Data-Out PDUs for command N MUST precede the 2011 unsolicited Data-Out PDUs of command N+1). A target that receives 2012 data out of order MAY terminate the session. 2014 4.2.5.3. Tags and Integrity Checks 2016 Initiator tags for pending commands are unique initiator-wide for 2017 a session. Target tags are not strictly specified by the protocol. 2018 It is assumed that target tags are used by the target to tag 2019 (alone or in combination with the LUN) the solicited data. Target 2020 tags are generated by the target and "echoed" by the initiator. 2021 These mechanisms are designed to accomplish efficient data 2022 delivery along with a large degree of control over the data flow. 2024 As the Initiator Task Tag is used to identify a task during its 2025 execution the iSCSI initiator and target MUST verify that all 2026 other fields used in task related PDUs have values that are 2027 consistent with the values used at the task instantiation based on 2028 Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the 2029 same as the one used in the SCSI command PDU used to instantiate 2030 the task). Using inconsistent field values is considered a 2031 protocol error. 2033 4.2.5.4. Task Management 2035 SCSI task management assumes that individual tasks and task groups 2036 can be aborted solely based on the task tags (for individual 2037 tasks) or the timing of the task management command (for task 2038 groups) and that the task management action is executed 2039 synchronously - i.e, no message involving an aborted task will be 2040 seen by the SCSI initiator after receiving the task management 2041 response. In iSCSI initiators and targets interact asynchronously 2042 over several connections. iSCSI specifies the protocol mechanism 2043 and implementation requirements needed to present a synchronous 2044 view while using an asynchronous infrastructure. 2046 4.2.6. iSCSI Connection Termination 2048 An iSCSI connection may be terminated by use of a transport 2049 connection shutdown or a transport reset. Transport reset is 2050 assumed to be an exceptional event. 2052 Graceful TCP connection shutdowns are done by sending TCP FINs. A 2053 graceful transport connection shutdown SHOULD only be initiated by 2054 either party when the connection is not in iSCSI Full Feature 2055 Phase. A target MAY terminate a Full Feature Phase connection on 2056 internal exception events, but it SHOULD announce the fact through 2057 an Asynchronous Message PDU. Connection termination with 2058 outstanding commands may require recovery actions. 2060 If a connection is terminated while in Full Feature Phase, 2061 connection cleanup (see section 7) is required prior to recovery. 2062 By doing connection cleanup before starting recovery, the 2063 initiator and target will avoid receiving stale PDUs after 2064 recovery. 2066 4.2.7. iSCSI Names 2068 Both targets and initiators require names for the purpose of 2069 identification. In addition, names enable iSCSI storage resources 2070 to be managed regardless of location (address). An iSCSI node name 2071 is also the SCSI device name contained in the iSCSI Node. The 2072 iSCSI name of a SCSI device is the principal object used in 2073 authentication of targets to initiators and initiators to targets. 2074 This name is also used to identify and manage iSCSI storage 2075 resources. 2077 iSCSI names must be unique within the operation domain of the end 2078 user. However, because the operation domain of an IP network is 2079 potentially worldwide, the iSCSI name formats are architected to 2080 be worldwide unique. To assist naming authorities in the 2081 construction of worldwide unique names, iSCSI provides three name 2082 formats for different types of naming authorities. 2084 iSCSI names are associated with iSCSI nodes, and not iSCSI network 2085 adapter cards, to ensure that the replacement of network adapter 2087 cards does not require reconfiguration of all SCSI and iSCSI 2088 resource allocation information. 2090 Some SCSI commands require that protocol-specific identifiers be 2091 communicated within SCSI CDBs. See SCSI for the definition of the 2092 SCSI port name/identifier for iSCSI ports. 2094 An initiator may discover the iSCSI Target Names to which it has 2095 access, along with their addresses, using the SendTargets text 2096 request, or other techniques discussed in [RFC3721]. 2098 iSCSI equipment that needs discovery functions beyond SendTargets 2099 SHOULD implement iSNS (see [RFC4171]) for extended discovery 2100 management capabilities and interoperability. Although [RFC3721] 2101 implies an SLP implementation requirement, SLP has not been widely 2102 implemented or deployed for use with iSCSI in practice. iSCSI 2103 implementations therefore SHOULD NOT rely on SLP-based discovery 2104 interoperability. 2106 4.2.7.1. iSCSI Name Properties 2108 Each iSCSI node, whether it is an initiator or target or both, 2109 MUST have an iSCSI name. Whenever an iSCSI Node contains an iSCSI 2110 Initiator Node and an iSCSI Target Node, the iSCSI Initiator Name 2111 MUST be the same as the iSCSI Target Name for the contained Nodes 2112 such that there is only one iSCSI Node Name for the iSCSI Node 2113 overall. Note the related requirements in section 9.2.1 on how to 2114 map CHAP names to iSCSI Names in such a scenario. 2116 Initiators and targets MUST support the receipt of iSCSI names of 2117 up to the maximum length of 223 bytes. 2119 The initiator MUST present both its iSCSI Initiator Name and the 2120 iSCSI Target Name to which it wishes to connect in the first login 2121 request of a new session or connection. The only exception is if a 2122 discovery session (see Section 4.3 iSCSI Session Types) is to be 2123 established. In this case, the iSCSI Initiator Name is still 2124 required, but the iSCSI Target Name MAY be omitted. 2126 iSCSI names have the following properties: 2128 iSCSI names are globally unique. No two initiators or targets 2129 can have the same name. 2130 iSCSI names are permanent. An iSCSI initiator node or target 2131 node has the same name for its lifetime. 2132 iSCSI names do not imply a location or address. An iSCSI 2133 initiator or target can move, or have multiple addresses. A 2134 change of address does not imply a change of name. 2135 iSCSI names do not rely on a central name broker; the naming 2136 authority is distributed. 2137 iSCSI names support integration with existing unique naming 2138 schemes. 2139 iSCSI names rely on existing naming authorities. iSCSI does 2140 not create any new naming authority. 2142 The encoding of an iSCSI name has the following properties: 2144 iSCSI names have the same encoding method regardless of the 2145 underlying protocols. 2146 iSCSI names are relatively simple to compare. The algorithm 2147 for comparing two iSCSI names for equivalence does not rely 2148 on an external server. 2149 iSCSI names are composed only of displayable characters. iSCSI 2150 names allow the use of international character sets but are 2151 not case sensitive. No whitespace characters are used in 2152 iSCSI names. 2153 iSCSI names may be transported using both binary and ASCII- 2154 based protocols. 2156 An iSCSI name really names a logical software entity, and is not 2157 tied to a port or other hardware that can be changed. For 2158 instance, an initiator name should name the iSCSI initiator node, 2159 not a particular NIC or HBA. When multiple NICs are used, they 2160 should generally all present the same iSCSI initiator name to the 2161 targets, because they are simply paths to the same SCSI layer. In 2162 most operating systems, the named entity is the operating system 2163 image. 2165 Similarly, a target name should not be tied to hardware interfaces 2166 that can be changed. A target name should identify the logical 2167 target and must be the same for the target regardless of the 2168 physical portion being addressed. This assists iSCSI initiators in 2169 determining that the two targets it has discovered are really two 2170 paths to the same target. 2172 The iSCSI name is designed to fulfill the functional requirements 2173 for Uniform Resource Names (URN) [RFC1737]. For example, it is 2174 required that the name have a global scope, be independent of 2175 address or location, and be persistent and globally unique. Names 2176 must be extensible and scalable with the use of naming 2177 authorities. The name encoding should be both human and machine 2178 readable. See [RFC1737] for further requirements. 2180 4.2.7.2. iSCSI Name Encoding 2182 An iSCSI name MUST be a UTF-8 (see [RFC3629]) encoding of a string 2183 of Unicode characters with the following properties: 2185 - It is in Normalization Form C (see "Unicode Normalization 2186 Forms" [UNICODE]). 2188 - It only contains characters allowed by the output of the 2189 iSCSI stringprep template (described in [RFC3722]). 2191 - The following characters are used for formatting iSCSI 2192 names: 2194 - dash ('-'=U+002d) 2195 - dot ('.'=U+002e) 2196 - colon (':'=U+003a) 2198 - The UTF-8 encoding of the name is not larger than 223 bytes. 2200 The stringprep process is described in [RFC3454]; iSCSI's use of 2201 the stringprep process is described in [RFC3722]. Stringprep is a 2202 method designed by the Internationalized Domain Name (IDN) working 2203 group to translate human-typed strings into a format that can be 2204 compared as opaque strings. Strings MUST NOT include punctuation, 2205 spacing, diacritical marks, or other characters that could get in 2206 the way of readability. The stringprep process also converts 2207 strings into equivalent strings of lower-case characters. 2209 The stringprep process does not need to be implemented if the 2210 names are only generated using numeric and lower-case (any 2211 character set) alphabetic characters. 2213 Once iSCSI names encoded in UTF-8 are "normalized" they may be 2214 safely compared byte-for-byte. 2216 4.2.7.3. iSCSI Name Structure 2218 An iSCSI name consists of two parts--a type designator followed by 2219 a unique name string. 2221 iSCSI uses three existing naming authorities in constructing 2222 globally unique iSCSI names. Type designator in an iSCSI name 2223 indicates the naming authority on which the name is based. The 2224 three iSCSI name formats are the following: 2226 iSCSI-Qualified Name: it is based on domain names to identify 2227 a naming authority, 2228 NAA format Name: it is based on a naming format defined by 2229 [FC-FS] for constructing globally unique identifiers, 2230 referred to as the Network Address Authority (NAA), and, 2231 EUI format Name: it is based on EUI names where the IEEE 2232 Registration Authority assists in the formation of 2233 worldwide unique names (EUI-64 format). 2235 The corresponding type designator strings currently defined are: 2237 iqn. - iSCSI Qualified name 2239 naa. - Remainder of the string is an INCITS T11-defined 2240 Network Address Authority identifier, in ASCII-encoded 2241 hexadecimal. 2243 eui. - Remainder of the string is an IEEE EUI-64 identifier, 2244 in ASCII-encoded hexadecimal. 2246 These three naming authority designators were considered 2247 sufficient at the time of writing this document. The creation of 2248 additional naming type designators for iSCSI may be considered by 2249 the IETF and detailed in separate RFCs. 2251 The following table summarizes the current SCSI transport 2252 protocols and their naming formats. 2254 SCSI Transport Protocol Naming Format 2255 +----------------------------+-------+-----+----+ 2256 | | EUI-64| NAA |IQN | 2257 |----------------------------|-------|-----|----| 2258 | iSCSI (Internet SCSI) | X | X | X | 2259 |----------------------------|-------|-----|----| 2260 | FCP (Fibre Channel) | | X | | 2261 |----------------------------|-------|-----|----| 2262 | SAS (Serial Attached SCSI) | | X | | 2263 |----------------------------|-------|-----|----| 2264 | SRP (for InfiniBand) | X | | | 2265 +----------------------------+-------+-----+----+ 2267 4.2.7.4. Type "iqn." (iSCSI Qualified Name) 2269 This iSCSI name type can be used by any organization that owns a 2270 domain name. This naming format is useful when an end user or 2271 service provider wishes to assign iSCSI names for targets and/or 2272 initiators. 2274 To generate names of this type, the person or organization 2275 generating the name must own a registered domain name. This domain 2276 name does not have to be active, and does not have to resolve to 2277 an address; it just needs to be reserved to prevent others from 2278 generating iSCSI names using the same domain name. 2280 Since a domain name can expire, be acquired by another entity, or 2281 may be used to generate iSCSI names by both owners, the domain 2282 name must be additionally qualified by a date during which the 2283 naming authority owned the domain name. A date code is provided as 2284 part of the "iqn." format for this reason. 2286 The iSCSI qualified name string consists of: 2288 - The string "iqn.", used to distinguish these names from 2289 "eui." formatted names. 2291 - A date code, in yyyy-mm format. This date MUST be a date 2292 during which the naming authority owned the domain name used 2293 in this format, and SHOULD be the first month in which the 2294 domain name was owned by this naming authority at 00:01 GMT 2295 of the first day of the month. This date code uses the 2296 Gregorian calendar. All four digits in the year must be 2297 present. Both digits of the month must be present, with 2298 January == "01" and December == "12". The dash must be 2299 included. 2301 - A dot "." 2303 - The reversed domain name of the naming authority (person or 2304 organization) creating this iSCSI name. 2306 - An optional, colon (:) prefixed, string within the character 2307 set and length boundaries that the owner of the domain name 2308 deems appropriate. This may contain product types, serial 2309 numbers, host identifiers, or software keys (e.g, it may 2310 include colons to separate organization boundaries). With 2311 the exception of the colon prefix, the owner of the domain 2312 name can assign everything after the reversed domain name as 2313 desired. It is the responsibility of the entity that is the 2314 naming authority to ensure that the iSCSI names it assigns 2315 are worldwide unique. For example, "Example Storage Arrays, 2316 Inc.", might own the domain name "example.com". 2318 The following are examples of iSCSI qualified names that might be 2319 generated by "EXAMPLE Storage Arrays, Inc." 2320 Naming String defined by 2321 Type Date Auth "example.com" naming authority 2322 +--++-----+ +---------+ +--------------------------------+ 2323 | || | | | | | 2325 iqn.2001-04.com.example:storage:diskarrays-sn-a8675309 2326 iqn.2001-04.com.example 2327 iqn.2001-04.com.example:storage.tape1.sys1.xyz 2328 iqn.2001-04.com.example:storage.disk2.sys1.xyz 2330 4.2.7.5. Type "eui." (IEEE EUI-64 format) 2332 The IEEE Registration Authority provides a service for assigning 2333 globally unique identifiers [EUI]. The EUI-64 format is used to 2334 build a global identifier in other network protocols. For example, 2335 Fibre Channel defines a method of encoding it into a 2336 WorldWideName. For more information on registering for EUI 2337 identifiers, see [OUI]. 2339 The format is "eui." followed by an EUI-64 identifier (16 ASCII- 2340 encoded hexadecimal digits). 2342 Example iSCSI name: 2344 Type EUI-64 identifier (ASCII-encoded hexadecimal) 2346 +--++--------------+ 2347 | || | 2349 eui.02004567A425678D 2351 The IEEE EUI-64 iSCSI name format might be used when a 2352 manufacturer is already registered with the IEEE Registration 2353 Authority and uses EUI-64 formatted worldwide unique names for its 2354 products. 2356 More examples of name construction are discussed in [RFC3721]. 2358 4.2.7.6. Type "naa." - Network Address Authority 2360 The INCITS T11 Framing and Signaling Specification [FC-FS] defines 2361 a format called the Network Address Authority (NAA) format for 2362 constructing worldwide unique identifiers that use various 2363 identifier registration authorities. This identifier format is 2364 used by the Fibre Channel and SAS SCSI transport protocols. As FC 2365 and SAS constitute a large fraction of networked SCSI ports, the 2366 NAA format is a widely used format for SCSI transports. The 2367 objective behind iSCSI supporting a direct representation of an 2368 NAA-format name is to facilitate construction of a target device 2369 name that translates easily across multiple namespaces for a SCSI 2370 storage device containing ports served by different transports. 2371 More specifically, this format allows implementations wherein one 2372 NAA identifier can be assigned as the basis for the SCSI device 2373 name for a SCSI target with both SAS ports and iSCSI ports. 2375 The iSCSI NAA naming format is "naa.", followed by an NAA 2376 identifier represented in ASCII-encoded hexadecimal digits. 2378 An example of an iSCSI name with a 64-bit NAA value follows: 2380 Type NAA identifier (ASCII-encoded hexadecimal) 2381 +--++--------------+ 2382 | || | 2383 naa.52004567BA64678D 2385 An example of an iSCSI name with a 128-bit NAA value follows: 2387 Type NAA identifier (ASCII-encoded hexadecimal) 2388 +--++------------------------------+ 2389 | || | 2390 naa.62004567BA64678D0123456789ABCDEF 2392 The iSCSI NAA naming format might be used in an implementation 2393 when the infrastructure for generating NAA worldwide unique names 2394 is already in place because the device contains both SAS and iSCSI 2395 SCSI ports. 2397 The NAA identifier formatted in an ASCII-hexadecimal 2398 representation has a maximum size of 32 characters (128 bit NAA 2399 format). As a result, there is no issue with this naming format 2400 exceeding the maximum size for iSCSI node names. 2402 4.2.8. Persistent State 2404 iSCSI does not require any persistent state maintenance across 2405 sessions. However, in some cases, SCSI requires persistent 2406 identification of the SCSI initiator port name (See Section 4.4.2 2407 and Section 4.4.3). 2409 iSCSI sessions do not persist through power cycles and boot 2410 operations. 2412 All iSCSI session and connection parameters are re-initialized on 2413 session and connection creation. 2415 Commands persist beyond connection termination if the session 2416 persists and command recovery within the session is supported. 2417 However, when a connection is dropped, command execution, as 2418 perceived by iSCSI (i.e., involving iSCSI protocol exchanges for 2419 the affected task), is suspended until a new allegiance is 2420 established by the 'task reassign' task management function. (See 2421 Section 11.5"Task Management Function Request".) 2423 4.2.9. Message Synchronization and Steering 2425 iSCSI presents a mapping of the SCSI protocol onto TCP. This 2426 encapsulation is accomplished by sending iSCSI PDUs of varying 2427 lengths. Unfortunately, TCP does not have a built-in mechanism for 2428 signaling message boundaries at the TCP layer. iSCSI overcomes 2429 this obstacle by placing the message length in the iSCSI message 2430 header. This serves to delineate the end of the current message as 2431 well as the beginning of the next message. 2433 In situations where IP packets are delivered in order from the 2434 network, iSCSI message framing is not an issue and messages are 2435 processed one after the other. In the presence of IP packet 2436 reordering (i.e., frames being dropped), legacy TCP 2437 implementations store the "out of order" TCP segments in temporary 2438 buffers until the missing TCP segments arrive, upon which the data 2439 must be copied to the application buffers. In iSCSI, it is 2440 desirable to steer the SCSI data within these out of order TCP 2441 segments into the pre-allocated SCSI buffers rather than store 2442 them in temporary buffers. This decreases the need for dedicated 2443 reassembly buffers as well as the latency and bandwidth related to 2444 extra copies. 2446 Relying solely on the "message length" information from the iSCSI 2447 message header may make it impossible to find iSCSI message 2448 boundaries in subsequent TCP segments due to the loss of a TCP 2449 segment that contains the iSCSI message length. The missing TCP 2450 segment(s) must be received before any of the following segments 2451 can be steered to the correct SCSI buffers (due to the inability 2452 to determine the iSCSI message boundaries). Since these segments 2453 cannot be steered to the correct location, they must be saved in 2454 temporary buffers that must then be copied to the SCSI buffers. 2456 Different schemes can be used to recover synchronization. The 2457 details of any such schemes are beyond this protocol 2458 specification, but it suffices to note that [RFC4297] provides an 2459 overview of the direct data placement problem on IP networks, and 2460 [RFC5046] specifies a protocol extension for iSCSI that 2461 facilitates this direct data placement objective. 2463 Under normal circumstances (no PDU loss or data reception out of 2464 order), iSCSI data steering can be accomplished by using the 2465 identifying tag and the data offset fields in the iSCSI header in 2466 addition to the TCP sequence number from the TCP header. The 2467 identifying tag helps associate the PDU with a SCSI buffer address 2468 while the data offset and TCP sequence number are used to 2469 determine the offset within the buffer. 2471 4.2.9.1. Sync/Steering and iSCSI PDU Length 2473 When a large iSCSI message is sent, the TCP segment(s) that 2474 contain the iSCSI header may be lost. The remaining TCP segment(s) 2475 up to the next iSCSI message must be buffered (in temporary 2476 buffers) because the iSCSI header that indicates to which SCSI 2477 buffers the data are to be steered was lost. To minimize the 2478 amount of buffering, it is recommended that the iSCSI PDU length 2479 be restricted to a small value (perhaps a few TCP segments in 2480 length). During login, each end of the iSCSI session specifies the 2481 maximum iSCSI PDU length it will accept. 2483 4.3. iSCSI Session Types 2485 iSCSI defines two types of sessions: 2487 Normal operational session - an unrestricted session. 2489 Discovery-session - a session only opened for target 2490 discovery. The target MUST ONLY accept text requests with 2491 the SendTargets key and a logout request with reason "close 2492 the session". All other requests MUST be rejected. 2494 The session type is defined during login with key=value parameter 2495 in the login command. 2497 4.4. SCSI to iSCSI Concepts Mapping Model 2499 The following diagram shows an example of how multiple iSCSI Nodes 2500 (targets in this case) can coexist within the same Network Entity 2501 and can share Network Portals (IP addresses and TCP ports). Other 2502 more complex configurations are also possible. For detailed 2503 descriptions of the components of these diagrams, see section 2504 4.4.1. 2506 +-----------------------------------+ 2507 | Network Entity (iSCSI Client) | 2508 | | 2509 | +-------------+ | 2510 | | iSCSI Node | | 2511 | | (Initiator) | | 2512 | +-------------+ | 2513 | | | | 2514 | +--------------+ +--------------+ | 2515 | |Network Portal| |Network Portal| | 2516 | | 192.0.2.4 | | 192.0.2.5 | | 2517 +-+--------------+-+--------------+-+ 2518 | | 2519 | IP Networks | 2520 | | 2521 +-+--------------+-+--------------+-+ 2522 | |Network Portal| |Network Portal| | 2523 | |198.51.100.21 | |198.51.100.3 | | 2524 | | TCP Port 3260| | TCP Port 3260| | 2525 | +--------------+ +--------------+ | 2526 | | | | 2527 | ----------------- | 2528 | | | | 2529 | +-------------+ +-------------+ | 2530 | | iSCSI Node | | iSCSI Node | | 2531 | | (Target) | | (Target) | | 2532 | +-------------+ +-------------+ | 2533 | | 2534 | Network Entity (iSCSI Server) | 2535 +-----------------------------------+ 2537 4.4.1. iSCSI Architecture Model 2539 This section describes the part of the iSCSI architecture model 2540 that has the most bearing on the relationship between iSCSI and 2541 the SCSI Architecture Model. 2543 Network Entity - represents a device or gateway that is 2544 accessible from the IP network. A Network Entity must have 2545 one or more Network Portals (see a following item), each of 2546 which can be used by some iSCSI Nodes (see the following 2547 item) contained in that Network Entity to gain access to 2548 the IP network. 2550 iSCSI Node - represents a single iSCSI initiator or iSCSI 2551 target or an instance of each. There are one or more iSCSI 2552 Nodes within a Network Entity. The iSCSI Node is accessible 2553 via one or more Network Portals (see item d). An iSCSI Node 2554 is identified by its iSCSI Name (see Section 4.2.7 and 2555 Section 13). The separation of the iSCSI Name from the 2556 addresses used by and for the iSCSI node allows multiple 2557 iSCSI nodes to use the same addresses, and the same iSCSI 2558 node to use multiple addresses. 2560 An alias string may also be associated with an iSCSI Node. The 2561 alias allows an organization to associate a user friendly 2562 string with the iSCSI Name. However, the alias string is 2563 not a substitute for the iSCSI Name. 2565 Network Portal - a component of a Network Entity that has a 2566 TCP/IP network address and that may be used by an iSCSI 2567 Node within that Network Entity for the connection(s) 2568 within one of its iSCSI sessions. In an initiator, it is 2569 identified by its IP address. In a target, it is identified 2570 by its IP address and its listening TCP port. 2572 Portal Groups - iSCSI supports multiple connections within the 2573 same session; some implementations will have the ability to 2574 combine connections in a session across multiple Network 2575 Portals. A Portal Group defines a set of Network Portals 2576 within an iSCSI Node that collectively supports the 2577 capability of coordinating a session with connections that 2578 span these portals. Not all Network Portals within a Portal 2579 Group need to participate in every session connected 2580 through that Portal Group. One or more Portal Groups may 2581 provide access to an iSCSI Node. Each Network Portal, as 2582 utilized by a given iSCSI Node, belongs to exactly one 2583 portal group within that node. Portal Groups are identified 2584 within an iSCSI Node by a portal group tag, a simple 2585 unsigned-integer between 0 and 65535 (see Section 13.3 2586 "SendTargets"). All Network Portals with the same portal 2587 group tag in the context of a given iSCSI Node are in the 2588 same Portal Group. 2590 Both iSCSI Initiators and iSCSI Targets have portal groups, 2591 though only the iSCSI Target Portal Groups are used 2592 directly in the iSCSI protocol (e.g., in SendTargets). For 2593 references to the Initiator Portal Groups, see Section 2594 10.1.1. 2596 Portals within a Portal Group should support similar session 2597 parameters, because they may participate in a common 2598 session. 2600 The following diagram shows an example of one such configuration 2601 on a target and how a session that shares Network Portals within a 2602 Portal Group may be established. 2604 ----------------------------IP Network--------------------- 2605 | | | 2606 +----|---------------|----+ +----|---------+ 2607 | +---------+ +---------+ | | +---------+ | 2608 | | Network | | Network | | | | Network | | 2609 | | Portal | | Portal | | | | Portal | | 2610 | +--|------+ +---------+ | | +---------+ | 2611 | | | | | | | 2612 | | Portal | | | | Portal | 2613 | | Group 1 | | | | Group 2 | 2614 +-------------------------+ +--------------+ 2615 | | | 2616 +-------- |----------------|------------------|---------------+ 2617 | | | | | 2618 | +----------------------------+ +-------------------------- +| 2619 | | iSCSI Session (Target side)| |iSCSI Session (Target side)|| 2620 | | | | || 2621 | | (TSIH = 56) | | (TSIH = 48) || 2622 | | | | || 2623 | +----------------------------+ +---------------------------+| 2624 | | 2625 | iSCSI Target Node | 2626 | | 2627 | (within Network Entity, not shown) | 2628 +-------------------------------------------------------------+ 2630 4.4.2. SCSI Architecture Model 2632 This section describes the relationship between the SCSI 2633 Architecture Model [SAM2] and constructs of the SCSI device, SCSI 2634 port and I_T nexus, and the iSCSI constructs described in Section 2635 4.4.1. 2637 This relationship implies implementation requirements in order to 2638 conform to the SAM2 model and other SCSI operational functions. 2639 These requirements are detailed in Section 4.4.3. 2641 The following list outlines mappings of SCSI architectural 2642 elements to iSCSI. 2644 SCSI Device - the SAM2 term for an entity that contains one or 2645 more SCSI ports that are connected to a service delivery 2646 subsystem and supports a SCSI application protocol. For 2647 example, a SCSI Initiator Device contains one or more SCSI 2648 Initiator Ports and zero or more application clients. A 2649 SCSI Target Device contains one or more SCSI Target Ports 2650 and one or more logical units. For iSCSI, the SCSI Device 2651 is the component within an iSCSI Node that provides the 2652 SCSI functionality. As such, there can be one SCSI Device, 2653 at most, within an iSCSI Node. Access to the SCSI Device 2654 can only be achieved in an iSCSI normal operational session 2655 (see Section 4.3). The SCSI Device Name is defined to be 2656 the iSCSI Name of the node and MUST be used in the iSCSI 2657 protocol. 2659 SCSI Port - the SAM2 term for an entity in a SCSI Device that 2660 provides the SCSI functionality to interface with a service 2661 delivery subsystem or transport. For iSCSI, the definition 2662 of SCSI Initiator Port and SCSI Target Port are different. 2664 SCSI Initiator Port: This maps to one endpoint of an iSCSI 2665 normal operational session (see Section 4.3). An iSCSI 2666 normal operational session is negotiated through the login 2667 process between an iSCSI initiator node and an iSCSI target 2668 node. At successful completion of this process, a SCSI 2669 Initiator Port is created within the SCSI Initiator Device. 2670 The SCSI Initiator Port Name and SCSI Initiator Port 2671 Identifier are both defined to be the iSCSI Initiator Name 2672 together with (a) a label that identifies it as an 2673 initiator port name/identifier and (b) the ISID portion of 2674 the session identifier. 2676 SCSI Target Port: This maps to an iSCSI Target Portal 2677 Group. The SCSI Target Port Name and the SCSI Target Port 2678 Identifier are both defined to be the iSCSI Target Name 2679 together with (a) a label that identifies it as a target 2680 port name/identifier and (b) the portal group tag. 2682 The SCSI Port Name MUST be used in iSCSI. When used in SCSI 2683 parameter data, the SCSI port name MUST be encoded as: 2684 - The iSCSI Name in UTF-8 format, followed by 2685 - a comma separator (1 byte), followed by 2686 - the ASCII character 'i' (for SCSI Initiator Port) or the 2687 ASCII character 't' (for SCSI Target Port) (1 byte), 2688 followed by 2689 - a comma separator (1 byte), followed by 2690 - a text encoding as a hex-constant (see Section 6.1 "Text 2691 Format") of the ISID (for SCSI initiator port) or the 2692 portal group tag (for SCSI target port) including the 2693 initial 0X or 0x and the terminating null (14 bytes). 2695 The ASCII character 'i' or 't' is the label that 2696 identifies this port as either a SCSI Initiator Port or a 2697 SCSI Target Port. 2699 I_T nexus - a relationship between a SCSI Initiator Port and a 2700 SCSI Target Port, according to [SAM2]. For iSCSI, this 2701 relationship is a session, defined as a relationship 2702 between an iSCSI Initiator's end of the session (SCSI 2703 Initiator Port) and the iSCSI Target's Portal Group. The 2704 I_T nexus can be identified by the conjunction of the SCSI 2705 port names or by the iSCSI session identifier SSID. iSCSI 2706 defines the I_T nexus identifier to be the tuple (iSCSI 2707 Initiator Name + ",i,0x" + ISID in text format, iSCSI 2708 Target Name + ",t,0x" + Portal Group Tag in text format) - 2709 an upper case hex prefix "0X" may alternatively be used in 2710 place of "0x". 2712 NOTE: The I_T nexus identifier is not equal to the session 2713 identifier (SSID). 2715 4.4.3. Consequences of the Model 2717 This section describes implementation and behavioral requirements 2718 that result from the mapping of SCSI constructs to the iSCSI 2719 constructs defined above. Between a given SCSI initiator port and 2720 a given SCSI target port, only one I_T nexus (session) can exist. 2721 No more than one nexus relationship (parallel nexus) is allowed by 2722 [SAM2]. Therefore, at any given time, only one session with the 2723 same session identifier (SSID) can exist between a given iSCSI 2724 initiator node and an iSCSI target node. 2726 These assumptions lead to the following conclusions and 2727 requirements: 2729 ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal 2730 Group (SCSI target port), there can only be one session with a 2731 given value for ISID that identifies the SCSI initiator port. See 2732 Section 11.12.5"ISID". 2734 The structure of the ISID that contains a naming authority 2735 component (see Section 11.12.5"ISID" and [RFC3721]) provides a 2736 mechanism to facilitate compliance with the ISID rule. (See 2737 Section 10.1.1 "Conservative Reuse of ISIDs".) 2739 The iSCSI Initiator Node should manage the assignment of ISIDs 2740 prior to session initiation. The "ISID RULE" does not preclude the 2741 use of the same ISID from the same iSCSI Initiator with different 2742 Target Portal Groups on the same iSCSI target or on other iSCSI 2743 targets (see Section 10.1.1 "Conservative Reuse of ISIDs"). 2744 Allowing this would be analogous to a single SCSI Initiator Port 2745 having relationships (nexus) with multiple SCSI target ports on 2746 the same SCSI target device or SCSI target ports on other SCSI 2747 target devices. It is also possible to have multiple sessions with 2748 different ISIDs to the same Target Portal Group. Each such session 2749 would be considered to be with a different initiator even when the 2750 sessions originate from the same initiator device. The same ISID 2751 may be used by a different iSCSI initiator because it is the iSCSI 2752 Name together with the ISID that identifies the SCSI Initiator 2753 Port. 2755 NOTE: A consequence of the ISID RULE and the specification for the 2756 I_T nexus identifier is that two nexus with the same identifier 2757 should never exist at the same time. 2759 TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH 2760 at session creation (when an initiator presents a 0 value at 2761 Login). After being selected, the same TSIH value MUST be used 2762 whenever initiator or target refers to the session and a TSIH is 2763 required. 2765 4.4.3.1. I_T Nexus State 2767 Certain nexus relationships contain an explicit state (e.g., 2768 initiator-specific mode pages) that may need to be preserved by 2769 the device server [SAM2] in a logical unit through changes or 2770 failures in the iSCSI layer (e.g., session failures). In order for 2771 that state to be restored, the iSCSI initiator should reestablish 2772 its session (re-login) to the same Target Portal Group using the 2773 previous ISID. That is, it should perform session recovery as 2774 described in Chapter 6. This is because the SCSI initiator port 2775 identifier and the SCSI target port identifier (or relative target 2776 port) form the datum that the SCSI logical unit device server uses 2777 to identify the I_T nexus. 2779 4.5. iSCSI UML Model 2781 This section presents the application of the UML modeling concepts 2782 discussed in Section 3 to the iSCSI and SCSI architecture model 2783 discussed in Section 4.4. 2785 +----------------+ 2786 | Network Entity | 2787 +----------------+ 2788 @ 1 @ 1 2789 | | 2790 +--------------------+ | 2791 | | 2792 | | 0..* 2793 | +------------------+ 2794 | | iSCSI Node | 2795 | +------------------+ 2796 | @ @ 2797 | | | 2798 | +-----------+ =(a)= +-----------+ 2799 | | | 2800 | | 0..1 | 0..1 2801 | +------------------------+ +----------------------+ 2802 | | iSCSI Target Node | | iSCSI Initiator Node | 2803 | +------------------------+ +----------------------+ 2804 | @ 1 @ 1 2805 | +--------------+ | 2806 | 1..* | | 1..* 2807 | +-----------------------------+ 2808 | | Portal Group | 2809 | +-----------------------------+ 2810 | O 1 2811 | | 2812 | | 1..* 2813 | 1..* +------------------------+ 2814 +-------------------| Network Portal | 2815 +------------------------+ 2817 (a) Each instance of an iSCSI Node class MUST contain one iSCSI 2818 Target Node instance or one iSCSI Initiator Node instance, or 2819 both. 2821 +----------------+ 2822 | Network Entity | 2823 +----------------+ 2824 @ 1 @ 1 2825 | | +-------------------+ 2826 +---------------------+ | | iSCSI Session | 2827 | | +-------------------+ 2828 | | 0..* | SSID[1] | 2829 | +--------------------+ | ISID[1] | 2830 | | iSCSI Node | +-------------------+ 2831 | +--------------------+ @ 1 2832 | | iSCSI Node Name[1] | | 2833 | | Alias [0..1] | | 0..* 2834 | +--------------------+ +------------------+ 2835 | | | | iSCSI Connection | 2836 | +--------------------+ +------------------+ 2837 | @ 1 @ 1 | CID[1] | 2838 | | | +------------------+ 2839 | +-------------+ ==(b)== +----------+ 0..* | 2840 | | 1 | 1 | 2841 | +------------------------+ +------------------------+ | 2842 | | iSCSI Target Node | | iSCSI Initiator Node | | 2843 | +------------------------+ +------------------------+ | 2844 | | iSCSI Target name [1] | |iSCSI Initiator Name [1]| | 2845 | +------------------------+ +------------------------+ | 2846 | @ 1 @ 1 | 2847 | | 1..* | 1..* | 2848 | +--------------------------+ +------------------------+ | 2849 | | Target Portal Group | | Initiator Portal Group | | 2850 | +--------------------------+ +------------------------+ | 2851 | |Target Portal Group Tag[1]| | Portal group tag[1] | | 2852 | +--------------------------+ +------------------------+ | 2853 | o 1 o 1 | 2854 | +------------+ +---------+ | 2855 | 1..* | | 1..* | 2856 | +-------------------------+ | 2857 | | Network Portal | | 2858 | +-------------------------+ | 2859 | 1..* | IP Address [1] | 1 | 2860 +----------------| TCP Port [0..1] |<----------------------+ 2861 +-------------------------+ 2863 (b) Each instance of an iSCSI Node class MUST contain one iSCSI 2864 Target Node instance or one iSCSI Initiator Node instance, or 2865 both. However, in all scenarios, note that an iSCSI Node MUST 2866 only have a single iSCSI Name. Note the related requirement in 2867 section 4.2.7.1. 2869 4.6. Request/Response Summary 2871 This section lists and briefly describes all the iSCSI PDU types 2872 (request and responses). 2874 All iSCSI PDUs are built as a set of one or more header segments 2875 (basic and auxiliary) and zero or one data segments. The header 2876 group and the data segment may each be followed by a CRC (digest) 2877 (see [CRC]). 2879 The basic header segment has a fixed length of 48 bytes. 2881 4.6.1. Request/Response Types Carrying SCSI Payload 2883 4.6.1.1. SCSI-Command 2885 This request carries the SCSI CDB and all the other SCSI execute 2886 command procedure call (see [SAM2]) IN arguments such as task 2887 attributes, Expected Data Transfer Length for one or both transfer 2888 directions (the latter for bidirectional commands), and Task Tag 2889 (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the 2890 initiator and target from the LUN field in the request and the I_T 2891 nexus is implicit in the session identification. 2893 In addition, the SCSI-command PDU carries information required for 2894 the proper operation of the iSCSI protocol - the command sequence 2895 number (CmdSN) and the expected status number (ExpStatSN) on the 2896 connection it is issued. 2898 All or part of the SCSI output (write) data associated with the 2899 SCSI command may be sent as part of the SCSI-Command PDU as a data 2900 segment. 2902 4.6.1.2. SCSI-Response 2904 The SCSI-Response carries all the SCSI execute-command procedure 2905 call (see [SAM2]) OUT arguments and the SCSI execute-command 2906 procedure call return value. 2908 The SCSI-Response contains the residual counts from the operation, 2909 if any, an indication of whether the counts represent an overflow 2910 or an underflow, and the SCSI status if the status is valid or a 2911 response code (a non-zero return value for the execute-command 2912 procedure call) if the status is not valid. 2914 For a valid status that indicates that the command has been 2915 processed, but resulted in an exception (e.g., a SCSI CHECK 2916 CONDITION), the PDU data segment contains the associated sense 2917 data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI. 2919 Some data segment content may also be associated (in the data 2920 segment) with a non-zero response code. 2922 In addition, the SCSI-Response PDU carries information required 2923 for the proper operation of the iSCSI protocol: 2925 - The number of Data-In PDUs that a target has sent (to enable 2926 the initiator to check that all have arrived). 2928 - StatSN - the Status Sequence Number on this connection. 2930 - ExpCmdSN - the next Expected Command Sequence Number at the 2931 target. 2933 - MaxCmdSN - the maximum CmdSN acceptable at the target from 2934 this initiator. 2936 4.6.1.3. Task Management Function Request 2938 The Task Management function request provides an initiator with a 2939 way to explicitly control the execution of one or more SCSI Tasks 2940 or iSCSI functions. The PDU carries a function identifier (which 2941 task management function to perform) and enough information to 2942 unequivocally identify the task or task-set on which to perform 2943 the action, even if the task(s) to act upon has not yet arrived or 2944 has been discarded due to an error. 2946 The referenced tag identifies an individual task if the function 2947 refers to an individual task. 2949 The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is 2950 identified by the LUN and the session identification (the session 2951 identifies an I_T nexus). 2953 For task sets, the CmdSN of the Task Management function request 2954 helps identify the tasks upon which to act, namely all tasks 2955 associated with a LUN and having a CmdSN preceding the Task 2956 Management function request CmdSN. 2958 For a Task Management function, the coordination between responses 2959 to the tasks affected and the Task Management function response is 2960 done by the target. 2962 4.6.1.4. Task Management Function Response 2964 The Task Management function response carries an indication of 2965 function completion for a Task Management function request 2966 including how it completed (response and qualifier) and additional 2967 information for failure responses. 2969 After the Task Management response indicates Task Management 2970 function completion, the initiator will not receive any additional 2971 responses from the affected tasks. 2973 4.6.1.5. SCSI Data-out and SCSI Data-in 2975 SCSI Data-out and SCSI Data-in are the main vehicles by which SCSI 2976 data payload is carried between initiator and target. Data payload 2977 is associated with a specific SCSI command through the Initiator 2978 Task Tag. For target convenience, outgoing solicited data also 2979 carries a Target Transfer Tag (copied from R2T) and the LUN. Each 2980 PDU contains the payload length and the data offset relative to 2981 the buffer address contained in the SCSI execute command procedure 2982 call. 2984 In each direction, the data transfer is split into "sequences". An 2985 end-of-sequence is indicated by the F bit. 2987 An outgoing sequence is either unsolicited (only the first 2988 sequence can be unsolicited) or consists of all the Data-Out PDUs 2989 sent in response to an R2T. 2991 Input sequences enable the switching of direction for 2992 bidirectional commands as required. 2994 For input, the target may request positive acknowledgement of 2995 input data. This is limited to sessions that support error 2996 recovery and is implemented through the A bit in the SCSI Data-in 2997 PDU header. 2999 Data-in and Data-out PDUs also carry the DataSN to enable the 3000 initiator and target to detect missing PDUs (discarded due to an 3001 error). 3003 In addition, StatSN is carried by the Data-In PDUs. 3005 To enable a SCSI command to be processed while involving a minimum 3006 number of messages, the last SCSI Data-in PDU passed for a command 3007 may also contain the status if the status indicates termination 3008 with no exceptions (no sense or response involved). 3010 4.6.1.6. Ready To Transfer (R2T) 3012 R2T is the mechanism by which the SCSI target "requests" the 3013 initiator for output data. R2T specifies to the initiator the 3014 offset of the requested data relative to the buffer address from 3015 the execute command procedure call and the length of the solicited 3016 data. 3018 To help the SCSI target associate the resulting Data-out with an 3019 R2T, the R2T carries a Target Transfer Tag that will be copied by 3020 the initiator in the solicited SCSI Data-out PDUs. There are no 3021 protocol specific requirements with regard to the value of these 3022 tags, but it is assumed that together with the LUN, they will 3023 enable the target to associate data with an R2T. 3025 R2T also carries information required for proper operation of the 3026 iSCSI protocol, such as: 3028 - R2TSN (to enable an initiator to detect a missing R2T) 3030 - StatSN 3032 - ExpCmdSN 3034 - MaxCmdSN 3036 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload 3038 4.6.2.1. Asynchronous Message 3040 Asynchronous Messages are used to carry SCSI asynchronous events 3041 (AEN) and iSCSI asynchronous messages. 3043 When carrying an AEN, the event details are reported as sense data 3044 in the data segment. 3046 4.6.3. Requests/Responses Carrying iSCSI Only Payload 3048 4.6.3.1. Text Request and Text Response 3050 Text requests and responses are designed as a parameter 3051 negotiation vehicle and as a vehicle for future extension. 3053 In the data segment Text Requests/Responses carry text information 3054 using a simple "key=value" syntax. 3056 Text Request/Responses may form extended sequences using the same 3057 Initiator Task Tag. The initiator uses the F (Final) flag bit in 3058 the text request header to indicate its readiness to terminate a 3059 sequence. The target uses the F (Final) flag bit in the text 3060 response header to indicate its consent to sequence termination. 3062 Text Request and Responses also use the Target Transfer Tag to 3063 indicate continuation of an operation or a new beginning. A target 3064 that wishes to continue an operation will set the Target Transfer 3065 Tag in a Text Response to a value different from the default 3066 0xffffffff. An initiator willing to continue will copy this value 3067 into the Target Transfer Tag of the next Text Request. If the 3068 initiator wants to restart the current target negotiation (start 3069 fresh) will set the Target Transfer Tag to 0xffffffff. 3071 Although a complete exchange is always started by the initiator, 3072 specific parameter negotiations may be initiated by the initiator 3073 or target. 3075 4.6.3.2. Login Request and Login Response 3077 Login Requests and Responses are used exclusively during the Login 3078 Phase of each connection to set up the session and connection 3079 parameters. (The Login Phase consists of a sequence of login 3080 requests and responses carrying the same Initiator Task Tag.) 3082 A connection is identified by an arbitrarily selected connection- 3083 ID (CID) that is unique within a session. 3085 Similar to the Text Requests and Responses, Login 3086 Requests/Responses carry key=value text information with a simple 3087 syntax in the data segment. 3089 The Login Phase proceeds through several stages (security 3090 negotiation, operational parameter negotiation) that are selected 3091 with two binary coded fields in the header -- the "current stage" 3092 (CSG) and the "next stage" (NSG) with the appearance of the latter 3093 being signaled by the "transit" flag (T). 3095 The first Login Phase of a session plays a special role, called 3096 the leading login, which determines some header fields (e.g., the 3097 version number, the maximum number of connections, and the session 3098 identification). 3100 The CmdSN initial value is also set by the leading login. 3102 StatSN for each connection is initiated by the connection login. 3104 A login request may indicate an implied logout (cleanup) of the 3105 connection to be logged in (a connection restart) by using the 3106 same Connection ID (CID) as an existing connection as well as the 3107 same session identifying elements of the session to which the old 3108 connection was associated. 3110 4.6.3.3. Logout Request and Response 3112 Logout Requests and Responses are used for the orderly closing of 3113 connections for recovery or maintenance. The logout request may be 3114 issued following a target prompt (through an asynchronous message) 3115 or at an initiators initiative. When issued on the connection to 3116 be logged out no other request may follow it. 3118 The Logout response indicates that the connection or session 3119 cleanup is completed and no other responses will arrive on the 3120 connection (if received on the logging out connection). In 3121 addition, the Logout Response indicates how long the target will 3122 continue to hold resources for recovery (e.g., command execution 3123 that continues on a new connection) in the text key Time2Retain 3124 and how long the initiator must wait before proceeding with 3125 recovery in the text key Time2Wait. 3127 4.6.3.4. SNACK Request 3129 With the SNACK Request, the initiator requests retransmission of 3130 numbered-responses or data from the target. A single SNACK request 3131 covers a contiguous set of missing items, called a run, of a given 3132 type of items. The type is indicated in a type field in the PDU 3133 header. The run is composed of an initial item (StatSN, DataSN, 3134 R2TSN) and the number of missed Status, Data, or R2T PDUs. For 3135 long data-in sequences, the target may request (at predefined 3136 minimum intervals) a positive acknowledgement for the data sent. A 3137 SNACK request with a type field that indicates ACK and the number 3138 of Data-In PDUs acknowledged conveys this positive 3139 acknowledgement. 3141 4.6.3.5. Reject 3143 Reject enables the target to report an iSCSI error condition 3144 (e.g., protocol, unsupported option) that uses a Reason field in 3145 the PDU header and includes the complete header of the bad PDU in 3146 the Reject PDU data segment. 3148 4.6.3.6. NOP-Out Request and NOP-In Response 3150 This request/response pair may be used by an initiator and target 3151 as a "ping" mechanism to verify that a connection/session is still 3152 active and all of its components are operational. Such a ping may 3153 be triggered by the initiator or target. The triggering party 3154 indicates that it wants a reply by setting a value different from 3155 the default 0xffffffff in the corresponding Initiator/Target 3156 Transfer Tag. 3158 NOP-In/NOP-Out may also be used "unidirectional" to convey to the 3159 initiator/target command, status or data counter values when there 3160 is no other "carrier" and there is a need to update the 3161 initiator/target. 3163 5. SCSI Mode Parameters for iSCSI 3165 There are no iSCSI specific mode pages. 3167 6. Login and Full Feature Phase Negotiation 3169 iSCSI parameters are negotiated at session or connection 3170 establishment by using Login Requests and Responses (see Section 3171 4.2.4 - "iSCSI Login") and during Full Feature Phase (Section 3172 4.2.5- "iSCSI Full Feature Phase") by using Text Requests and 3173 Responses. In both cases the mechanism used is an exchange of 3174 iSCSI-text-key=value pairs. For brevity, iSCSI-text-keys are 3175 called just keys in the rest of this document. 3177 Keys are either declarative or require negotiation and the key 3178 description indicates if the key is declarative or requires 3179 negotiation. 3181 For the declarative keys the declaring party sets a value for the 3182 key. The key specification indicates if the key can be declared by 3183 the initiator, target or both. 3185 For the keys that require negotiation, one of the parties (the 3186 proposing party) proposes a value or set of values by including 3187 the key=value in the data part of a Login or Text Request or 3188 Response. The other party (the accepting party) makes a selection 3189 based on the value or list of values proposed and includes the 3190 selected value in a key=value in the data part of the following 3191 Login or Text Response or Request. For most of the keys, both the 3192 initiator and target can be proposing parties. 3194 The login process proceeds in two stages - the security 3195 negotiation stage and the operational parameter negotiation stage. 3196 Both stages are optional but at least one of them has to be 3197 present to enable setting some mandatory parameters. 3199 If present, the security negotiation stage precedes the 3200 operational parameter negotiation stage. 3202 Progression from stage to stage is controlled by the T 3203 (Transition) bit in the Login Request/Response PDU header. Through 3204 the T bit set to 1, the initiator indicates that it would like to 3205 transition. The target agrees to the transition (and selects the 3206 next stage) when ready. A field in the Login PDU header indicates 3207 the current stage (CSG) and during transition, another field 3208 indicates the next stage (NSG) proposed (initiator) and selected 3209 (target). 3211 The Text negotiation process is used to negotiate or declare 3212 operational parameters. The negotiation process is controlled by 3213 the F (final) bit in the PDU header. During text negotiations, the 3214 F bit is used by the initiator to indicate that it is ready to 3215 finish the negotiation and by the Target to acquiesce the end of 3216 negotiation. 3218 Since some key=value pairs may not fit entirely in a single PDU, 3219 the C (continuation) bit is used (both in Login and Text) to 3220 indicate that "more follows". 3222 The text negotiation uses an additional mechanism by which a 3223 target may deliver larger amounts of data to an enquiring 3224 initiator. The target sets a Target Task Tag to be used as a 3225 bookmark which when returned by the initiator, means "go on". If 3226 reset to a "neutral value", it means "forget about the rest". 3228 This chapter details types of keys and values used, the syntax 3229 rules for parameter formation, and the negotiation schemes to be 3230 used with different types of parameters. 3232 6.1. Text Format 3234 The initiator and target send a set of key=value pairs encoded in 3235 UTF-8 Unicode. All the text keys and text values specified in this 3236 document are to be presented and interpreted in the case in which 3237 they appear in this document. They are case sensitive. 3239 The following character symbols are used in this document for text 3240 items (the hexadecimal values represent Unicode code points): 3242 (a-z, A-Z) - letters 3243 (0-9) - digits 3244 " " (0x20) - space 3245 "." (0x2e) - dot 3246 "-" (0x2d) - minus 3247 "+" (0x2b) - plus 3248 "@" (0x40) - commercial at 3249 "_" (0x5f) - underscore 3251 "=" (0x3d) - equal 3252 ":" (0x3a) - colon 3253 "/" (0x2f) - solidus or slash 3254 "[" (0x5b) - left bracket 3255 "]" (0x5d) - right bracket 3256 null (0x00) - null separator 3257 "," (0x2c) - comma 3258 "~" (0x7e) - tilde 3260 Key=value pairs may span PDU boundaries. An initiator or target 3261 that sends partial key=value text within a PDU indicates that more 3262 text follows by setting the C bit in the Text or Login Request or 3263 Text or Login Response to 1. Data segments in a series of PDUs 3264 that have the C bit set to 1 and end with a PDU that have the C 3265 bit set to 0, or include a single PDU that has the C bit set to 0 3266 have to be considered as forming a single logical-text-data- 3267 segment (LTDS). 3269 Every key=value pair, including the last or only pair in a LTDS, 3270 MUST be followed by one null (0x00) delimiter. 3272 A key-name is whatever precedes the first = in the key=value pair. 3273 The term key is used frequently in this document in place of key- 3274 name. 3276 A value is whatever follows the first = in the key=value pair up 3277 to the end of the key=value pair, but not including the null 3278 delimiter. 3280 The following definitions will be used in the rest of this 3281 document: 3283 standard-label: A string of one or more characters that 3284 consist of letters, digits, dot, minus, plus, commercial at, 3285 or underscore. A standard-label MUST begin with a capital 3286 letter and must not exceed 63 characters. 3288 key-name: A standard-label. 3290 text-value: A string of zero or more characters that consist 3291 of letters, digits, dot, minus, plus, commercial at, 3292 underscore, slash, left bracket, right bracket, or colon. 3294 iSCSI-name-value: A string of one or more characters that 3295 consist of minus, dot, colon, or any character allowed by 3296 the output of the iSCSI string-prep template as specified in 3297 [RFC3722] (see also Section 4.2.7.2- "iSCSI Name Encoding"). 3299 iSCSI-local-name-value: A UTF-8 string; no null characters are 3300 allowed in the string. This encoding is to be used for 3301 localized (internationalized) aliases. 3303 boolean-value: The string "Yes" or "No". 3305 hex-constant: A hexadecimal constant encoded as a string that 3306 starts with "0x" or "0X" followed by one or more digits or 3307 the letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex- 3308 constants are used to encode numerical values or binary 3309 strings. When used to encode numerical values, the excessive 3310 use of leading 0 digits is discouraged. The string following 3311 0X (or 0x) represents a base16 number that starts with the 3312 most significant base16 digit, followed by all other digits 3313 in decreasing order of significance and ending with the 3314 least-significant base16 digit. When used to encode binary 3315 strings, hexadecimal constants have an implicit byte-length 3316 that includes four bits for every hexadecimal digit of the 3317 constant, including leading zeroes. For example, a hex- 3318 constant of n hexadecimal digits has a byte-length of (the 3319 integer part of) (n+1)/2. 3321 decimal-constant: An unsigned decimal number with the digit 0 3322 or a string of one or more digits that start with a non-zero 3324 digit. Decimal-constants are used to encode numerical 3325 values or binary strings. Decimal constants can only be used 3326 to encode binary strings if the string length is explicitly 3327 specified. There is no implicit length for decimal strings. 3328 Decimal-constant MUST NOT be used for parameter values if 3329 the values can be equal or greater than 2**64 (numerical) or 3330 for binary strings that can be longer than 64 bits. 3332 base64-constant: base64 constant encoded as a string that 3333 starts with "0b" or "0B" followed by 1 or more digits or 3334 letters or plus or slash or equal. The encoding is done 3335 according to [RFC2045] and each character, except equal, 3336 represents a base64 digit or a 6-bit binary string. Base64- 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 (encoded as A) is discouraged. The 3340 string following 0B (or 0b) represents a base64 number that 3341 starts with the most significant base64 digit, followed by 3342 all other digits in decreasing order of significance and 3343 ending with the least-significant base64 digit; the least 3344 significant base64 digit may be optionally followed by pad 3345 digits (encoded as equal) that are not considered as part of 3346 the number. When used to encode binary strings, base64- 3347 constants have an implicit byte-length that includes six 3348 bits for every character of the constant, excluding trailing 3349 equals (i.e., a base64-constant of n base64 characters 3350 excluding the trailing equals has a byte-length of ((the 3351 integer part of) (n*3/4)). Correctly encoded base64 strings 3352 cannot have n values of 1, 5 ... k*4+1. 3354 numerical-value: An unsigned integer always less than 2**64 3355 encoded as a decimal-constant or a hex-constant. Unsigned 3356 integer arithmetic applies to numerical-values. 3358 large-numerical-value: An unsigned integer that can be larger 3359 than or equal to 2**64 encoded as a hex constant, or base64- 3360 constant. Unsigned integer arithmetic applies to large- 3361 numeric-values. 3363 numeric-range: Two numerical-values separated by a tilde where 3364 the value to the right of tilde must not be lower than the 3365 value to the left. 3367 regular-binary-value: A binary string not longer than 64 bits 3368 encoded as a decimal constant, hex constant, or base64- 3369 constant. The length of the string is either specified by 3370 the key definition or is the implicit byte-length of the 3371 encoded string. 3373 large-binary-value: A binary string longer than 64 bits 3374 encoded as a hex-constant or base64-constant. The length of 3375 the string is either specified by the key definition or is 3376 the implicit byte-length of the encoded string. 3378 binary-value: A regular-binary-value or a large-binary-value. 3379 Operations on binary values are key specific. 3381 simple-value: Text-value, iSCSI-name-value, boolean-value, 3382 numeric-value, a numeric-range, or a binary-value. 3384 list-of-values: A sequence of text-values separated by a 3385 comma. 3387 If not otherwise specified, the maximum length of a simple-value 3388 (not its encoded representation) is 255 bytes not including the 3389 delimiter (comma or zero byte). 3391 Any iSCSI target or initiator MUST support receiving at least 8192 3392 bytes of key=value data in a negotiation sequence. When proposing 3393 or accepting authentication methods that explicitly require 3394 support for very long authentication items, the initiator and 3395 target MUST support receiving of at least 64 kilobytes of 3396 key=value data. 3398 6.2. Text Mode Negotiation 3400 During login, and thereafter, some session or connection 3401 parameters are either declared or negotiated through an exchange 3402 of textual information. 3404 The initiator starts the negotiation and/or declaration through a 3405 Text or Login request and indicates when it is ready for 3406 completion (by setting the F bit to 1 and keeping it to 1 in a 3407 Text Request or the T bit in the Login Request). As negotiation 3408 text may span PDU boundaries, a Text or Login Request or Text or 3409 Login Response PDU that have the C bit set to 1 MUST NOT have the 3410 F/T bit set to 1. 3412 A target receiving a Text or Login Request with the C bit set to 1 3413 MUST answer with a Text or Login Response with no data segment 3414 (DataSegmentLength 0). An initiator receiving a Text or Login 3415 Response with the C bit set to 1 MUST answer with a Text or Login 3416 Request with no data segment (DataSegmentLength 0). 3418 A target or initiator SHOULD NOT use a Text or Login Response or 3419 Text or Login Request with no data segment (DataSegmentLength 0) 3420 unless explicitly required by a general or a key-specific 3421 negotiation rule. 3423 There MUST NOT be more than one outstanding Text Request, or Text 3424 Response PDU on an iSCSI connection. An outstanding PDU in this 3425 context is one that has not been acknowledged by the remote iSCSI 3426 side. 3428 The format of a declaration is: 3430 Declarer-> = 3432 The general format of text negotiation is: 3434 Proposer-> = 3436 Acceptor-> ={|NotUnderstood|Irrelevant|Reject} 3438 Thus a declaration is a one-way textual exchange (unless the key 3439 is not understood by the receiver) while a negotiation is a two- 3440 way exchange. 3442 The proposer or declarer can either be the initiator or the 3443 target, and the acceptor can either be the target or initiator, 3444 respectively. Targets are not limited to respond to key=value 3445 pairs as proposed by the initiator. The target may propose 3446 key=value pairs of its own. 3448 All negotiations are explicit (i.e., the result MUST only be based 3449 on newly exchanged or declared values). There are no implicit 3450 proposals. If a proposal is not made, then a reply cannot be 3451 expected. Conservative design also requires that default values 3452 should not be relied upon when use of some other value has serious 3453 consequences. 3455 The value proposed or declared can be a numerical-value, a 3456 numerical-range defined by lower and upper value with both 3457 integers separated by tilde, a binary value, a text-value, an 3458 iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes 3459 or No), or a list of comma separated text-values. A range, a 3460 large-numerical-value, an iSCSI-name-value and an iSCSI-local- 3461 name-value MAY ONLY be used if it is explicitly allowed. An 3462 accepted value can be a numerical-value, a large-numerical-value, 3463 a text-value, or a boolean-value. 3465 If a specific key is not relevant for the current negotiation, the 3466 acceptor may answer with the constant "Irrelevant" for all types 3467 of negotiation. However the negotiation is not considered as 3468 failed if the answer is "Irrelevant". The "Irrelevant" answer is 3469 meant for those cases in which several keys are presented by a 3470 proposing party but the selection made by the acceptor for one of 3471 the keys makes other keys irrelevant. The following example 3472 illustrates the use of "Irrelevant": 3474 I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192 3475 T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant 3477 I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb) 3478 T->I X#vkey1=None,X#vkey2=Irrelevant 3480 Any key not understood by the acceptor may be ignored by the 3481 acceptor without affecting the basic function. However, the answer 3482 for a key not understood MUST be key=NotUnderstood. Note that 3483 NotUnderstood is a valid answer for both declarative and 3484 negotiated keys. The general iSCSI philosophy is that 3485 comprehension precedes processing for any iSCSI key. A proposer 3486 of an iSCSI key, negotiated or declarative, in a text key exchange 3487 MUST thus be able to properly handle a NotUnderstood response. 3489 The proper way to handle a NotUnderstood response depends on where 3490 the key is specified and whether the key is declarative vs. 3491 negotiated. An iSCSI implementation MUST comprehend all text keys 3492 defined in iSCSI Protocol specifications from [RFC3720] through 3493 the RFC associated with the highest protocol version that the 3494 implementation has offered (or has negotiated, in the case of an 3495 acceptor) for the iSCSIProtocolLevel key in a negotiation. 3496 Returning a NotUnderstood response on any of these text keys 3497 therefore MUST be considered a protocol error and handled 3498 accordingly. For all other "later" keys, i.e. text keys defined 3499 in specifications associated with higher values of 3500 iSCSIProtocolLevel, a NotUnderstood answer concludes the 3501 negotiation for a negotiated key whereas for a declarative key, a 3502 NotUnderstood answer simply informs the declarer of a lack of 3503 comprehension by the receiver. 3505 In either case, a NotUnderstood answer always requires that the 3506 protocol behavior associated with that key not be used within the 3507 scope of the key (connection/session) by either side. 3509 The constants "None", "Reject", "Irrelevant", and "NotUnderstood" 3510 are reserved and MUST ONLY be used as described here. Violation of 3511 this rule is a protocol error (in particular the use of "Reject", 3512 "Irrelevant", and "NotUnderstood" as proposed values). 3514 Reject or Irrelevant are legitimate negotiation options where 3515 allowed but their excessive use is discouraged. A negotiation is 3516 considered complete when the acceptor has sent the key value pair 3517 even if the value is "Reject", "Irrelevant", or "NotUnderstood". 3518 Sending the key again would be a re-negotiation and is forbidden 3519 for many keys. 3521 If the acceptor sends "Reject" as an answer the negotiated key is 3522 left at its current value (or default if no value was set). If the 3523 current value is not acceptable to the proposer on the connection 3524 or to the session it is sent, the proposer MAY choose to terminate 3525 the connection or session. 3527 All keys in this document, except for the X extension formats, 3528 MUST be supported by iSCSI initiators and targets when used as 3529 specified here. If used as specified, these keys MUST NOT be 3530 answered with NotUnderstood. 3532 Implementers may introduce new keys by prefixing them with X- 3533 followed by their (reversed) domain name, or with new keys 3534 registered with IANA prefixing them with X#. For example, the 3535 entity owning the domain example.com can issue: 3537 X-com.example.bar.foo.do_something=3 3539 or a new registered key may be used as in: 3541 X#SuperCalyPhraGilistic=Yes 3543 Implementers MAY also introduce new values, but ONLY for new keys 3544 or authentication methods (see Section 12 - "iSCSI Security Text 3545 Keys and Authentication Methods"), or digests (see Section 13.1 - 3546 "HeaderDigest and DataDigest"). 3548 Whenever parameter action or acceptance are dependent on other 3549 parameters, the dependency rules and parameter sequence must be 3550 specified with the parameters. 3552 In the Login Phase (see Login Phase), every stage is a separate 3553 negotiation. In the FullFeaturePhase, a Text Request Response 3554 sequence is a negotiation. Negotiations MUST be handled as atomic 3555 operations. For example, all negotiated values go into effect 3556 after the negotiation concludes in agreement or are ignored if the 3557 negotiation fails. 3559 Some parameters may be subject to integrity rules (e.g., 3560 parameter-x must not exceed parameter-y or parameter-u not 1 3561 implies parameter-v be Yes). Whenever required, integrity rules 3562 are specified with the keys. Checking for compliance with the 3563 integrity rule must only be performed after all the parameters are 3564 available (the existent and the newly negotiated). An iSCSI target 3565 MUST perform integrity checking before the new parameters take 3566 effect. An initiator MAY perform integrity checking. 3568 An iSCSI initiator or target MAY terminate a negotiation that does 3569 not end within a reasonable time or number of exchanges. 3571 6.2.1. List negotiations 3573 In list negotiation, the originator sends a list of values (which 3574 may include "None") in its order of preference. 3576 The responding party MUST respond with the same key and the first 3577 value that it supports (and is allowed to use for the specific 3578 originator) selected from the originator list. 3580 The constant "None" MUST always be used to indicate a missing 3581 function. However, "None" is only a valid selection if it is 3582 explicitly proposed. 3584 If an acceptor does not understand any particular value in a list, 3585 it MUST ignore it. If an acceptor does not support, does not 3586 understand, or is not allowed to use any of the proposed options 3587 with a specific originator, it may use the constant "Reject" or 3588 terminate the negotiation. The selection of a value not proposed 3589 MUST be handled as a protocol error. 3591 6.2.2. Simple-value Negotiations 3593 For simple-value negotiations, the accepting party MUST answer 3594 with the same key. The value it selects becomes the negotiation 3595 result. 3597 Proposing a value not admissible (e.g., not within the specified 3598 bounds) MAY be answered with the constant "Reject" or the acceptor 3599 MAY select an admissible value. 3601 The selection, by the acceptor, of a value not admissible under 3602 the selection rules is considered a protocol error. The selection 3603 rules are key-specific. 3605 For a numerical range the value selected must be an integer within 3606 the proposed range or "Reject" (if the range is unacceptable). 3608 For Boolean negotiations (i.e., keys taking the values Yes or No), 3609 the accepting party MUST answer with the same key and the result 3610 of the negotiation when the received value does not determine that 3611 result by itself. The last value transmitted becomes the 3612 negotiation result. The rules for selecting the value to answer 3613 with are expressed as Boolean functions of the value received, and 3614 the value that the accepting party would have selected if given a 3615 choice. 3617 Specifically, the two cases in which answers are OPTIONAL are: 3619 - The Boolean function is "AND" and the value "No" is 3620 received. The outcome of the negotiation is "No". 3622 - The Boolean function is "OR" and the value "Yes" is 3623 received. The outcome of the negotiation is "Yes". 3625 Responses are REQUIRED in all other cases, and the value chosen 3626 and sent by the acceptor becomes the outcome of the negotiation. 3628 6.3. Login Phase 3630 The Login Phase establishes an iSCSI connection between an 3631 initiator and a target; it creates also a new session or 3632 associates the connection to an existing session. The Login Phase 3633 sets the iSCSI protocol parameters, security parameters, and 3634 authenticates the initiator and target to each other. 3636 The Login Phase is only implemented via Login request and 3637 responses. The whole Login Phase is considered as a single task 3638 and has a single Initiator Task Tag (similar to the linked SCSI 3639 commands). 3641 There MUST NOT be more than one outstanding Login Request, or 3642 Login Response on an iSCSI connection. An outstanding PDU in this 3643 context is one that has not been acknowledged by the remote iSCSI 3644 side. 3646 The default MaxRecvDataSegmentLength is used during Login. 3648 The Login Phase sequence of requests and responses proceeds as 3649 follows: 3651 - Login initial request 3653 - Login partial response (optional) 3655 - More Login requests and responses (optional) 3657 - Login Final-Response (mandatory) 3659 The initial login request of any connection MUST include the 3660 InitiatorName key=value pair. The initial login request of the 3661 first connection of a session MAY also include the SessionType 3662 key=value pair. For any connection within a session whose type is 3663 not "Discovery", the first login request MUST also include the 3664 TargetName key=value pair. 3666 The Login Final-response accepts or rejects the Login request. 3668 The Login Phase MAY include a SecurityNegotiation stage and a 3669 LoginOperationalNegotiation stage and MUST include at least one of 3670 them, but the included stage MAY be empty except for the mandatory 3671 names. 3673 The login requests and responses contain a field (CSG) that 3674 indicates the current negotiation stage (SecurityNegotiation or 3675 LoginOperationalNegotiation). If both stages are used, the 3676 SecurityNegotiation MUST precede the LoginOperationalNegotiation. 3678 Some operational parameters can be negotiated outside the login 3679 through Text requests and responses. 3681 Security MUST be completely negotiated within the Login Phase. The 3682 use of underlying IPsec security is specified in Chapter 8 and in 3683 [RFC3723]. iSCSI support for security within the protocol only 3684 consists of authentication in the Login Phase. 3686 In some environments, a target or an initiator is not interested 3687 in authenticating its counterpart. It is possible to bypass 3688 authentication through the Login request and response. 3690 The initiator and target MAY want to negotiate iSCSI 3691 authentication parameters. Once this negotiation is completed, the 3692 channel is considered secure. 3694 Most of the negotiation keys are only allowed in a specific stage. 3695 The SecurityNegotiation keys appear in Chapter 11 and the 3696 LoginOperationalNegotiation keys appear in Chapter 12. Only a 3697 limited set of keys (marked as Any-Stage in Chapter 12) may be 3698 used in any of the two stages. 3700 Any given Login request or response belongs to a specific stage; 3701 this determines the negotiation keys allowed with the request or 3702 response. It is considered to be a protocol error to send a key 3703 not allowed in the current stage. 3705 Stage transition is performed through a command exchange 3706 (request/response) that carries the T bit and the same CSG code. 3707 During this exchange, the next stage is selected by the target 3708 through the "next stage" code (NSG). The selected NSG MUST NOT 3709 exceed the value stated by the initiator. The initiator can 3710 request a transition whenever it is ready, but a target can only 3711 respond with a transition after one is proposed by the initiator. 3713 In a negotiation sequence, the T bit settings in one pair of login 3714 request-responses have no bearing on the T bit settings of the 3715 next pair. An initiator that has a T bit set to 1 in one pair and 3716 is answered with a T bit setting of 0 may issue the next request 3717 with T bit set to 0. 3719 When a transition is requested by the initiator and acknowledged 3720 by the target, both the initiator and target switch to the 3721 selected stage. 3723 Targets MUST NOT submit parameters that require an additional 3724 initiator login request in a login response with the T bit set to 3725 1. 3727 Stage transitions during login (including entering and exit) are 3728 only possible as outlined in the following table: 3730 +-----------------------------------------------------------+ 3731 |From To -> | Security | Operational | FullFeature | 3732 | | | | | | 3733 | V | | | | 3734 +-----------------------------------------------------------+ 3735 | (start) | yes | yes | no | 3736 +-----------------------------------------------------------+ 3737 | Security | no | yes | yes | 3738 +-----------------------------------------------------------+ 3739 | Operational | no | no | yes | 3740 +-----------------------------------------------------------+ 3742 The Login Final-Response that accepts a Login Request can only 3743 come as a response to a Login request with the T bit set to 1, 3744 and both the request and response MUST indicate FullFeaturePhase 3745 as the next phase via the NSG field. 3747 Neither the initiator nor the target should attempt to declare or 3748 negotiate a parameter more than once during login except for 3749 responses to specific keys that explicitly allow repeated key 3750 declarations (e.g., TargetAddress). An attempt to 3751 renegotiate/redeclare parameters not specifically allowed MUST be 3752 detected by the initiator and target. If such an attempt is 3753 detected by the target, the target MUST respond with Login reject 3754 (initiator error); if detected by the initiator, the initiator 3755 MUST drop the connection. 3757 6.3.1. Login Phase Start 3759 The Login Phase starts with a login request from the initiator to 3760 the target. The initial login request includes: 3762 -Protocol version supported by the initiator. 3764 -iSCSI Initiator Name and iSCSI Target Name 3766 -ISID, TSIH, and connection Ids 3768 -Negotiation stage that the initiator is ready to enter. 3770 A login may create a new session or it may add a connection to an 3771 existing session. Between a given iSCSI Initiator Node (selected 3772 only by an InitiatorName) and a given iSCSI target defined by an 3773 iSCSI TargetName and a Target Portal Group Tag, the login results 3774 are defined by the following table: 3776 +----------------------------------------------------------------+ 3777 |ISID | TSIH | CID | Target action | 3778 +----------------------------------------------------------------+ 3779 |new | non-zero | any | fail the login | 3780 | | | | ("session does not exist") | 3781 +----------------------------------------------------------------+ 3782 |new | zero | any | instantiate a new session | 3783 +----------------------------------------------------------------+ 3784 |existing| zero | any | do session reinstatement | 3785 | | | | (see Section 6.3.5) | 3786 +----------------------------------------------------------------+ 3787 |existing| non-zero | new | add a new connection to | 3788 | | existing | | the session | 3789 +----------------------------------------------------------------+ 3790 |existing| non-zero |existing| do connection reinstatement| 3791 | | existing | | (see Section 7.1.4.3) | 3792 +----------------------------------------------------------------+ 3793 |existing| non-zero | any | fail the login | 3794 | | new | | ("session does not exist") | 3795 +----------------------------------------------------------------+ 3797 Determination of "existing" or "new" are made by the target. 3799 Optionally, the login request may include: 3801 -Security parameters 3802 OR 3804 -iSCSI operational parameters 3805 AND/OR 3807 -The next negotiation stage that the initiator is ready to 3808 enter. 3810 The target can answer the login in the following ways: 3812 -Login Response with Login reject. This is an immediate 3813 rejection from the target that causes the connection to 3814 terminate and the session to terminate if this is the first 3815 (or only) connection of a new session. The T bit and the CSG 3816 and NSG fields are reserved. 3818 -Login Response with Login accept as a final response (T bit 3819 set to 1 and the NSG in both request and response are set to 3820 FullFeaturePhase). The response includes the protocol 3821 version supported by the target and the session ID, and may 3822 include iSCSI operational or security parameters (that 3823 depend on the current stage). 3825 -Login Response with Login Accept as a partial response (NSG 3826 not set to FullFeaturePhase in both request and response) 3828 that indicates the start of a negotiation sequence. The 3829 response includes the protocol version supported by the 3830 target and either security or iSCSI parameters (when no 3831 security mechanism is chosen) supported by the target. 3833 If the initiator decides to forego the SecurityNegotiation stage, 3834 it issues the Login with the CSG set to 3835 LoginOperationalNegotiation and the target may reply with a Login 3836 Response that indicates that it is unwilling to accept the 3837 connection (see Section 11.13 - "Login Response") without 3838 SecurityNegotiation and will terminate the connection with a 3839 response of Authentication failure (see Section 11.13.5 - "Status- 3840 Class and Status-Detail"). 3842 If the initiator is willing to negotiate iSCSI security, but is 3843 unwilling to make the initial parameter proposal and may accept a 3844 connection without iSCSI security, it issues the Login with the T 3845 bit set to 1, the CSG set to SecurityNegotiation, and NSG set to 3846 LoginOperationalNegotiation. If the target is also ready to skip 3847 security, the login response only contains the 3848 TargetPortalGroupTag key (see Section 13.9- 3849 "TargetPortalGroupTag"), the T bit set to 1, the CSG set to 3850 SecurityNegotiation, and NSG set to LoginOperationalNegotiation. 3852 An initiator that chooses to operate without iSCSI security and 3853 with all the operational parameters taking the default values 3854 issues the Login with the T bit set to 1, the CSG set to 3855 LoginOperationalNegotiation, and NSG set to FullFeaturePhase. If 3856 the target is also ready to forego security and can finish its 3857 LoginOperationalNegotiation, the Login response has T bit set to 3858 1, the CSG set to LoginOperationalNegotiation, and NSG set to 3859 FullFeaturePhase in the next stage. 3861 During the Login Phase the iSCSI target MUST return the 3862 TargetPortalGroupTag key with the first Login Response PDU with 3863 which it is allowed to do so (i.e., the first Login Response 3864 issued after the first Login Request with the C bit set to 0) for 3865 all session types. The TargetPortalGroupTag key value indicates 3866 the iSCSI portal group servicing the Login Request PDU. If the 3867 reconfiguration of iSCSI portal groups is a concern in a given 3868 environment, the iSCSI initiator should use this key to ascertain 3869 that it had indeed initiated the Login Phase with the intended 3870 target portal group. 3872 6.3.2. iSCSI Security Negotiation 3874 The security exchange sets the security mechanism and 3875 authenticates 3876 the initiator user and the target to each other. The exchange 3877 proceeds according to the authentication method chosen in the 3878 negotiation phase and is conducted using the login requests' and 3879 responses' key=value parameters. 3881 An initiator directed negotiation proceeds as follows: 3883 -The initiator sends a login request with an ordered list of 3884 the options it supports (authentication algorithm). The 3885 options are listed in the initiator's order of preference. 3886 The initiator MAY also send private or public extension 3887 options. 3889 -The target MUST reply with the first option in the list it 3890 supports and is allowed to use for the specific initiator 3891 unless it does not support any in which case it MUST answer 3892 with "Reject" (see Text Mode Negotiation). The parameters 3893 are encoded in UTF8 as key=value. For security parameters, 3894 see Chapter 11. 3896 -When the initiator considers that it is ready to conclude the 3897 SecurityNegotiation stage, it sets the T bit to 1 and the 3898 NSG to what it would like the next stage to be. The target 3899 will then set the T bit to 1 and set NSG to the next stage 3900 in the Login response when it finishes sending its security 3901 keys. The next stage selected will be the one the target 3902 selected. If the next stage is FullFeaturePhase, the target 3903 MUST respond with a Login Response with the TSIH value. 3905 If the security negotiation fails at the target, then the target 3906 MUST send the appropriate Login Response PDU. If the security 3907 negotiation fails at the initiator, the initiator SHOULD close the 3908 connection. 3910 It should be noted that the negotiation might also be directed by 3911 the target if the initiator does support security, but is not 3912 ready to direct the negotiation (propose options). 3914 6.3.3. Operational Parameter Negotiation During the Login Phase 3916 Operational parameter negotiation during the login MAY be done: 3918 - Starting with the first Login request if the initiator does 3919 not propose any security/ integrity option. 3921 - Starting immediately after the security negotiation if the 3922 initiator and target perform such a negotiation. 3924 Operational parameter negotiation MAY involve several Login 3925 request-response exchanges started and terminated by the 3926 initiator. The initiator MUST indicate its intent to terminate the 3927 negotiation by setting the T bit to 1; the target sets the T bit 3928 to 1 on the last response. 3930 If the target responds to a Login request that has the T bit set 3931 to 1 with a Login response that has the T bit set to 0, the 3932 initiator should keep sending the Login request (even empty) with 3933 the T bit set to 1, while it still wants to switch stage, until it 3934 receives the Login Response that has the T bit set to 1 or it 3935 receives a key that requires it to set the T bit to 0. 3937 Some session specific parameters can only be specified during the 3938 Login Phase of the first connection of a session (i.e., begun by a 3939 login request that contains a zero-valued TSIH) - the leading 3940 Login Phase (e.g., the maximum number of connections that can be 3941 used for this session). 3943 A session is operational once it has at least one connection in 3944 FullFeaturePhase. New or replacement connections can only be added 3945 to a session after the session is operational. 3947 For operational parameters, see Chapter 12. 3949 6.3.4. Connection Reinstatement 3951 Connection reinstatement is the process of an initiator logging in 3952 with a ISID-TSIH-CID combination that is possibly active from the 3953 target's perspective, which causes the implicit logging out of the 3954 connection corresponding to the CID and reinstating a new Full 3955 Feature Phase iSCSI connection in its place (with the same CID). 3956 Thus, the TSIH in the Login Request PDU MUST be non-zero and CID 3957 does not change during a connection reinstatement. The Login 3958 request performs the logout function of the old connection if an 3959 explicit logout was not performed earlier. In sessions with a 3960 single connection, this may imply the opening of a second 3961 connection with the sole purpose of cleaning up the first. Targets 3962 MUST support opening a second connection even when they do not 3963 support multiple connections in Full Feature Phase if 3964 ErrorRecoveryLevel is 2 and SHOULD support opening a second 3965 connection if ErrorRecoveryLevel is less than 2. 3967 If the operational ErrorRecoveryLevel is 2, connection 3968 reinstatement enables future task reassignment. If the operational 3969 ErrorRecoveryLevel is less than 2, connection reinstatement is the 3970 replacement of the old CID without enabling task reassignment. In 3971 this case, all the tasks that were active on the old CID must be 3972 immediately terminated without further notice to the initiator. 3974 The initiator connection state MUST be CLEANUP_WAIT (section 3975 8.1.3) when the initiator attempts a connection reinstatement. 3977 In practical terms, in addition to the implicit logout of the old 3978 connection, reinstatement is equivalent to a new connection login. 3980 6.3.5. Session Reinstatement, Closure, and Timeout 3982 Session reinstatement is the process of the initiator logging in 3983 with an ISID that is possibly active from the target's 3984 perspective. Thus implicitly logging out the session that 3985 corresponds to the ISID and reinstating a new iSCSI session in its 3986 place (with the same ISID). Therefore, the TSIH in the Login PDU 3987 MUST be zero to signal session reinstatement. Session 3988 reinstatement causes all the tasks that were active on the old 3989 session to be immediately terminated by the target without further 3990 notice to the initiator. 3992 The initiator session state MUST be FAILED (Section 8.3- "Session 3993 State Diagrams") when the initiator attempts a session 3994 reinstatement. 3996 Session closure is an event defined to be one of the following: 3998 - A successful "session close" logout. 4000 - A successful "connection close" logout for the last Full 4001 Feature Phase connection when no other connection in the 4002 session is waiting for cleanup (Section 8.2- "Connection 4003 Cleanup State Diagram for Initiators and Targets") and no 4004 tasks in the session are waiting for reassignment. 4006 Session timeout is an event defined to occur when the last 4007 connection state timeout expires and no tasks are waiting for 4008 reassignment. This takes the session to the FREE state (N6 4009 transition in the session state diagram). 4011 6.3.5.1. Loss of Nexus Notification 4013 The iSCSI layer provides the SCSI layer with the "I_T nexus loss" 4014 notification when any one of the following events happens: 4016 Successful completion of session reinstatement. 4017 Session closure event. 4018 Session timeout event. 4020 Certain SCSI object clearing actions may result due to the 4021 notification in the SCSI end nodes, as documented in Appendix F. - 4022 Clearing Effects of Various Events on Targets. 4024 6.3.6. Session Continuation and Failure 4026 Session continuation is the process by which the state of a 4027 preexisting session continues to be used by connection 4028 reinstatement (Section 6.3.4), or by adding a connection with a 4029 new CID. Either of these actions associates the new transport 4030 connection with the session state. 4032 Session failure is an event where the last Full Feature Phase 4033 connection reaches the CLEANUP_WAIT state (Section 8.2), or 4034 completes a successful recovery logout thus causing all active 4035 tasks (that are formerly allegiant to the connection) to start 4036 waiting for task reassignment. 4038 6.4. Operational Parameter Negotiation Outside the Login Phase 4040 Some operational parameters MAY be negotiated outside (after) the 4041 Login Phase. 4043 Parameter negotiation in Full Feature Phase is done through Text 4044 requests and responses. Operational parameter negotiation MAY 4045 involve several Text request-response exchanges, which the 4046 initiator always starts, terminates, and uses the same Initiator 4047 Task Tag. The initiator MUST indicate its intent to terminate the 4048 negotiation by setting the F bit to 1; the target sets the F bit 4049 to 1 on the last response. 4051 If the target responds to a Text request with the F bit set to 1 4052 with a Text response with the F bit set to 0, the initiator should 4053 keep sending the Text request (even empty) with the F bit set to 4054 1, while it still wants to finish the negotiation, until it 4055 receives the Text response with the F bit set to 1. Responding to 4056 a Text request with the F bit set to 1 with an empty (no key=value 4057 pairs) response with the F bit set to 0 is discouraged. 4059 Targets MUST NOT submit parameters that require an additional 4060 initiator Text request in a Text response with the F bit set to 1. 4062 In a negotiation sequence, the F bit settings in one pair of Text 4063 request-responses have no bearing on the F bit settings of the 4064 next pair. An initiator that has the F bit set to 1 in a request 4065 and is being answered with an F bit setting of 0 may issue the 4066 next request with the F bit set to 0. 4068 Whenever the target responds with the F bit set to 0, it MUST set 4069 the Target Transfer Tag to a value other than the default 4070 0xffffffff. 4072 An initiator MAY reset an operational parameter negotiation by 4073 issuing a Text request with the Target Transfer Tag set to the 4074 value 0xffffffff after receiving a response with the Target 4075 Transfer Tag set to a value other than 0xffffffff. A target may 4076 reset an operational parameter negotiation by answering a Text 4077 request with a Reject PDU. 4079 Neither the initiator nor the target should attempt to declare or 4080 negotiate a parameter more than once during any negotiation 4081 sequence, except for responses to specific keys that explicitly 4082 allow repeated key declarations (e.g., TargetAddress). If detected 4083 by the target, this MUST result in a Reject PDU with a reason of 4084 "protocol error". The initiator MUST reset the negotiation as 4085 outlined above. 4087 Parameters negotiated by a text exchange negotiation sequence only 4088 become effective after the negotiation sequence is completed. 4090 7. iSCSI Error Handling and Recovery 4092 7.1. Overview 4094 7.1.1. Background 4096 The following two considerations prompted the design of much of 4097 the error recovery functionality in iSCSI: 4099 An iSCSI PDU may fail the digest check and be dropped, despite 4100 being received by the TCP layer. The iSCSI layer must 4101 optionally be allowed to recover such dropped PDUs. 4103 A TCP connection may fail at any time during the data 4104 transfer. All the active tasks must optionally be allowed 4105 to be continued on a different TCP connection within the 4106 same session. 4108 Implementations have considerable flexibility in deciding what 4109 degree of error recovery to support, when to use it and by which 4110 mechanisms to achieve the required behavior. Only the externally 4111 visible actions of the error recovery mechanisms must be 4112 standardized to ensure interoperability. 4114 This chapter describes a general model for recovery in support of 4115 interoperability. See Appendix E. - "Algorithmic Presentation of 4116 Error Recovery Classes" for further detail on how the described 4117 model may be implemented. Compliant implementations do not have to 4118 match the implementation details of this model as presented, but 4119 the external behavior of such implementations must correspond to 4120 the externally observable characteristics of the presented model. 4122 7.1.2. Goals 4124 The major design goals of the iSCSI error recovery scheme are as 4125 follows: 4127 Allow iSCSI implementations to meet different requirements 4128 by defining a collection of error recovery mechanisms that 4129 implementations may choose from. 4130 Ensure interoperability between any two implementations 4131 supporting different sets of error recovery capabilities. 4133 Define the error recovery mechanisms to ensure command 4134 ordering even in the face of errors, for initiators that 4135 demand ordering. 4136 Do not make additions in the fast path, but allow moderate 4137 complexity in the error recovery path. 4138 Prevent both the initiator and target from attempting to 4139 recover the same set of PDUs at the same time. For example, 4140 there must be a clear "error recovery functionality 4141 distribution" between the initiator and target. 4143 7.1.3. Protocol Features and State Expectations 4145 The initiator mechanisms defined in connection with error recovery 4146 are: 4148 NOP-OUT to probe sequence numbers of the target (Section 4149 11.18) 4150 Command retry (Section 7.2.1) 4151 Recovery R2T support (Section 7.8) 4152 Requesting retransmission of status/data/R2T using the SNACK 4153 facility (section 11.16) 4154 Acknowledging the receipt of the data (section 11.16) 4155 Reassigning the connection allegiance of a task to a 4156 different TCP connection (Section 7.2.2) 4157 Terminating the entire iSCSI session to start afresh (Session 4158 Recovery) 4160 The target mechanisms defined in connection with error recovery 4161 are: 4163 NOP-IN to probe sequence numbers of the initiator (section 4164 11.19) 4165 Requesting retransmission of data using the recovery R2T 4166 feature (iSCSI Erro) 4167 SNACK support (section 11.16) 4168 Requesting that parts of read data be acknowledged (section 4169 11.7.2) 4170 Allegiance reassignment support (Section 7.2.2) 4171 Terminating the entire iSCSI session to force the initiator 4172 to start over (Session Recovery) 4174 For any outstanding SCSI command, it is assumed that iSCSI, in 4175 conjunction with SCSI at the initiator, is able to keep enough 4176 information to be able to rebuild the command PDU, and that 4177 outgoing data is available (in host memory) for retransmission 4178 while the command is outstanding. It is also assumed that at the 4179 target, incoming data (read data) MAY be kept for recovery or it 4180 can be reread from a device server. 4182 It is further assumed that a target will keep the "status & sense" 4183 for a command it has executed if it supports status 4184 retransmission. 4185 A target that agrees to support data retransmission is expected to 4186 be prepared to retransmit the outgoing data (i.e., Data-In) on 4187 request until either the status for the completed command is 4188 acknowledged, or the data in question has been separately 4189 acknowledged. 4191 7.1.4. Recovery Classes 4193 iSCSI enables the following classes of recovery (in the order of 4194 increasing scope of affected iSCSI tasks): 4196 - Within a command (i.e., without requiring command restart). 4198 - Within a connection (i.e., without requiring the connection 4199 to be rebuilt, but perhaps requiring command restart). 4201 - Connection recovery (i.e., perhaps requiring connections to 4202 be rebuilt and commands to be reissued). 4204 - Session recovery. 4206 The recovery scenarios detailed in the rest of this section are 4207 representative rather than exclusive. In every case, they detail 4208 the lowest class recovery that MAY be attempted. The implementer 4209 is left to decide under which circumstances to escalate to the 4210 next recovery class and/or what recovery classes to implement. 4211 Both the iSCSI target and initiator MAY escalate the error 4212 handling to an error recovery class, which impacts a larger number 4213 of iSCSI tasks in any of the cases identified in the following 4214 discussion. 4216 In all classes, the implementer has the choice of deferring errors 4217 to the SCSI initiator (with an appropriate response code), in 4218 which case the task, if any, has to be removed from the target and 4219 all the side-effects, such as ACA, must be considered. 4221 Use of within-connection and within-command recovery classes MUST 4222 NOT be attempted before the connection is in Full Feature Phase. 4224 In the detailed description of the recover classes the 4225 mandating terms (MUST, SHOULD, MAY, etc.) indicate normative 4226 actions to be executed if the recovery class is supported and 4227 used. 4229 7.1.4.1. Recovery Within-command 4231 At the target, the following cases lend themselves to within- 4232 command recovery: 4234 - Lost data PDU - realized through one of the following: 4236 Data digest error - dealt with as specified in Section 7.8, 4237 using the option of a recovery R2T. 4238 Sequence reception timeout (no data or partial-data-and-no-F- 4239 bit) - considered an implicit sequence error and dealt with 4240 as specified in Section 7.9, using the option of a recovery 4241 R2T. 4242 Header digest error, which manifests as a sequence reception 4243 timeout or a sequence error - dealt with as specified in 4244 Section 7.9, using the option of a recovery R2T. 4246 At the initiator, the following cases lend themselves to within- 4247 command recovery: 4249 Lost data PDU or lost R2T - realized through one of the 4250 following: 4252 Data digest error - dealt with as specified in Section 7.8, 4253 using the option of a SNACK. 4255 Sequence reception timeout (no status) or response reception 4256 timeout - dealt with as specified in Section 7.9, using the 4257 option of a SNACK. 4258 Header digest error, which manifests as a sequence reception 4259 timeout or a sequence error - dealt with as specified in 4260 Section 7.9, using the option of a SNACK. 4262 To avoid a race with the target, which may already have a recovery 4263 R2T or a termination response on its way, an initiator SHOULD NOT 4264 originate a SNACK for an R2T based on its internal timeouts (if 4265 any). Recovery in this case is better left to the target. 4267 The timeout values used by the initiator and target are outside 4268 the scope of this document. Sequence reception timeout is 4269 generally a large enough value to allow the data sequence transfer 4270 to be complete. 4272 7.1.4.2. Recovery Within-connection 4274 At the initiator, the following cases lend themselves to within- 4275 connection recovery: 4277 - Requests not acknowledged for a long time. Requests are 4278 acknowledged explicitly through ExpCmdSN or implicitly by 4279 receiving data and/or status. The initiator MAY retry non- 4280 acknowledged commands as specified in Retry an. 4282 - Lost iSCSI numbered Response. It is recognized by either 4283 identifying a data digest error on a Response PDU or a Data- 4284 In PDU carrying the status, or by receiving a Response PDU 4285 with a higher StatSN than expected. In the first case, 4286 digest error handling is done as specified in Section 7.8 4287 using the option of a SNACK. In the second case, sequence 4288 error handling is done as specified in Section 7.9, using 4289 the option of a SNACK. 4291 At the target, the following cases lend themselves to within- 4292 connection recovery: 4294 - Status/Response not acknowledged for a long time. The target 4295 MAY issue a NOP-IN (with a valid Target Transfer Tag or 4296 otherwise) that carries the next status sequence number it 4297 is going to use in the StatSN field. This helps the 4298 initiator detect any missing StatSN(s) and issue a SNACK for 4299 the status. 4301 The timeout values used by the initiator and the target are 4302 outside the scope of this document. 4304 7.1.4.3. Connection Recovery 4306 At an iSCSI initiator, the following cases lend themselves to 4307 connection recovery: 4309 - TCP connection failure: The initiator MUST close the 4310 connection. It then MUST either implicitly or explicitly 4311 logout the failed connection with the reason code "remove 4312 the connection for recovery" and reassign connection 4313 allegiance for all commands still in progress associated 4314 with the failed connection on one or more connections (some 4315 or all of which MAY be newly established connections) using 4316 the "Task reassign" task management function (see Section 4317 11.5.1- "Function"). For an initiator, a command is in 4318 progress as long as it has not received a response or a 4319 Data-In PDU including status. 4321 Note: The logout function is mandatory. However, a new 4322 connection establishment is only mandatory if the failed 4323 connection was the last or only connection in the session. 4325 - Receiving an Asynchronous Message that indicates one or all 4326 connections in a session has been dropped. The initiator 4327 MUST handle it as a TCP connection failure for the 4328 connection(s) referred to in the Message. 4330 At an iSCSI target, the following cases lend themselves to 4331 connection recovery: 4333 - TCP connection failure. The target MUST close the connection 4334 and, if more than one connection is available, the target 4335 SHOULD send an Asynchronous Message that indicates it has 4336 dropped the connection. Then, the target will wait for the 4337 initiator to continue recovery. 4339 7.1.4.4. Session Recovery 4341 Session recovery should be performed when all other recovery 4342 attempts have failed. Very simple initiators and targets MAY 4343 perform session recovery on all iSCSI errors and rely on recovery 4344 on the SCSI layer and above. 4346 Session recovery implies the closing of all TCP connections, 4347 internally aborting all executing and queued tasks for the given 4348 initiator at the target, terminating all outstanding SCSI commands 4349 with an appropriate SCSI service response at the initiator, and 4350 restarting a session on a new set of connection(s) (TCP connection 4351 establishment and login on all new connections). 4353 For possible clearing effects of session recovery on SCSI and 4354 iSCSI objects, refer to Appendix F. - "Clearing Effects of Various 4355 Events on Targets". 4357 7.1.5. Error Recovery Hierarchy 4359 The error recovery classes described so far are organized into a 4360 hierarchy for ease in understanding and to limit the 4361 implementation complexity. With few and well defined recovery 4362 levels interoperability is easier to achieve. The attributes of 4363 this hierarchy are as follows: 4365 Each level is a superset of the capabilities of the previous 4366 level. For example, Level 1 support implies supporting all 4367 capabilities of Level 0 and more. 4369 As a corollary, supporting a higher error recovery level means 4370 increased sophistication and possibly an increase in 4371 resource requirements. 4372 Supporting error recovery level "n" is advertised and 4373 negotiated by each iSCSI entity by exchanging the text key 4374 "ErrorRecoveryLevel=n". The lower of the two exchanged 4375 values is the operational ErrorRecoveryLevel for the 4376 session. 4378 The following diagram represents the error recovery hierarchy. 4380 + 4381 / \ 4382 / 2 \ <-- Connection recovery 4383 +-----+ 4384 / 1 \ <-- Digest failure recovery 4385 +---------+ 4386 / 0 \ <-- Session failure recovery 4387 +-------------+ 4389 The following table lists the error recovery capabilities expected 4390 from the implementations that support each error recovery level. 4392 +-------------------+--------------------------------------------+ 4393 |ErrorRecoveryLevel | Associated Error recovery capabilities | 4394 +-------------------+--------------------------------------------+ 4395 | 0 | Session recovery class | 4396 | | (Session Recovery) | 4397 +-------------------+--------------------------------------------+ 4398 | 1 | Digest failure recovery (See Note below.) | 4399 | | plus the capabilities of ER Level 0 | 4400 +-------------------+--------------------------------------------+ 4401 | 2 | Connection recovery class | 4402 | | (Connection Recovery) | 4403 | | plus the capabilities of ER Level 1 | 4404 +-------------------+--------------------------------------------+ 4406 Note: Digest failure recovery is comprised of two recovery 4407 classes: Within-Connection recovery class (Recovery Within- 4408 connection) and Within-Command recovery class (Recovery Within- 4409 command ). 4411 When a defined value of ErrorRecoveryLevel is proposed by an 4412 originator in a text negotiation, the originator MUST support the 4413 functionality defined for the proposed value and additionally, 4414 functionality corresponding to any defined value numerically less 4415 than the proposed. When a defined value of ErrorRecoveryLevel is 4416 returned by a responder in a text negotiation, the responder MUST 4417 support the functionality corresponding to the ErrorRecoveryLevel 4418 it is accepting. 4420 When either party attempts to use error recovery functionality 4421 beyond what is negotiated, the recovery attempts MAY fail unless 4422 an apriori agreement outside the scope of this document exists 4423 between the two parties to provide such support. 4425 Implementations MUST support error recovery level "0", while the 4426 rest are OPTIONAL to implement. In implementation terms, the 4427 above striation means that the following incremental 4428 sophistication with each level is required. 4430 +-------------------+--------------------------------------------- 4431 + 4432 |Level transition | Incremental requirement 4433 | 4434 +-------------------+--------------------------------------------- 4435 + 4436 | 0->1 | PDU retransmissions on the same connection 4437 | 4438 +-------------------+--------------------------------------------- 4439 + 4440 | 1->2 | Retransmission across connections and 4441 | 4442 | | allegiance reassignment 4443 | 4444 +-------------------+--------------------------------------------- 4445 + 4447 7.2. Retry and Reassign in Recovery 4449 This section summarizes two important and somewhat related iSCSI 4450 protocol features used in error recovery. 4452 7.2.1. Usage of Retry 4454 By resending the same iSCSI command PDU ("retry") in the absence 4455 of a command acknowledgement (by way of an ExpCmdSN update) or a 4456 response, an initiator attempts to "plug" (what it thinks are) the 4457 discontinuities in CmdSN ordering on the target end. Discarded 4458 command PDUs, due to digest errors, may have created these 4459 discontinuities. 4461 Retry MUST NOT be used for reasons other than plugging command 4462 sequence gaps, and in particular, cannot be used for requesting 4463 PDU retransmissions from a target. Any such PDU retransmission 4464 requests for a currently allegiant command in progress may be made 4465 using the SNACK mechanism described in section 11.16, although the 4466 usage of SNACK is OPTIONAL. 4468 If initiators, as part of plugging command sequence gaps as 4469 described above, inadvertently issue retries for allegiant 4470 commands already in progress (i.e., targets did not see the 4471 discontinuities in CmdSN ordering), the duplicate commands are 4472 silently ignored by targets as specified in section 4.2.2.1. 4474 When an iSCSI command is retried, the command PDU MUST carry the 4475 original Initiator Task Tag and the original operational 4476 attributes (e.g., flags, function names, LUN, CDB etc.) as well as 4477 the original CmdSN. The command being retried MUST be sent on the 4478 same connection as the original command unless the original 4479 connection was already successfully logged out. 4481 7.2.2. Allegiance Reassignment 4483 By issuing a "task reassign" task management request (Section 4484 11.5.1 - "Function"), the initiator signals its intent to continue 4485 an already active command (but with no current connection 4486 allegiance) as part of connection recovery. This means that a new 4487 connection allegiance is requested for the command, which seeks to 4488 associate it to the connection on which the task management 4489 request is being issued. Before the allegiance reassignment is 4490 attempted for a task, an implicit or explicit Logout with the 4491 reason code "remove the connection for recovery" (see section 4492 11.14.1) MUST be successfully completed for the previous 4493 connection to which the task was allegiant. 4495 In reassigning connection allegiance for a command, the targets 4496 SHOULD continue the command from its current state. For example, 4497 when reassigning read commands, the target SHOULD take advantage 4498 of the ExpDataSN field provided by the Task Management function 4499 request (which must be set to zero if there was no data transfer) 4500 and bring the read command to completion by sending the remaining 4501 data and sending (or resending) the status. ExpDataSN 4502 acknowledges all data sent up to, but not including, the Data-In 4503 PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However, 4504 targets may choose to send/receive all unacknowledged data or all 4505 of the data on a reassignment of connection allegiance if unable 4506 to recover or maintain accurate an state. Initiators MUST NOT 4507 subsequently request data retransmission through Data SNACK for 4508 PDUs numbered less than ExpDataSN (i.e., prior to the acknowledged 4509 sequence number). For all types of commands, a reassignment 4510 request implies that the task is still considered in progress by 4511 the initiator and the target must conclude the task appropriately 4512 if the target returns the "Function Complete" response to the 4513 reassignment request. This might possibly involve retransmission 4514 of data/R2T/status PDUs as necessary, but MUST involve the 4515 (re)transmission of the status PDU. 4517 It is OPTIONAL for targets to support the allegiance reassignment. 4518 This capability is negotiated via the ErrorRecoveryLevel text key 4519 during the login time. When a target does not support allegiance 4520 reassignment, it MUST respond with a Task Management response code 4521 of "Allegiance reassignment not supported". If allegiance 4522 reassignment is supported by the target, but the task is still 4523 allegiant to a different connection, or a successful recovery 4524 Logout of the previously allegiant connection was not performed, 4525 the target MUST respond with a Task Management response code of 4526 "Task still allegiant". 4528 If allegiance reassignment is supported by the target, the Task 4529 Management response to the reassignment request MUST be issued 4530 before the reassignment becomes effective. 4532 If a SCSI Command that involves data input is reassigned, any 4533 SNACK Tag it holds for a final response from the original 4534 connection is deleted and the default value of 0 MUST be used 4535 instead. 4537 7.3. Usage Of Reject PDU in Recovery 4539 Targets MUST NOT implicitly terminate an active task by sending a 4540 Reject PDU for any PDU exchanged during the life of the task. If 4541 the target decides to terminate the task, a Response PDU (SCSI, 4542 Text, Task, etc.) must be returned by the target to conclude the 4543 task. If the task had never been active before the Reject (i.e., 4544 the Reject is on the command PDU), targets should not send any 4545 further responses because the command itself is being discarded. 4547 The above rule means that the initiator can eventually expect a 4548 response on receiving Rejects, if the received Reject is for a PDU 4549 other than the command PDU itself. The non-command Rejects only 4550 have diagnostic value in logging the errors, and they can be used 4551 for retransmission decisions by the initiators. 4553 The CmdSN of the rejected command PDU (if it is a non-immediate 4554 command) MUST NOT be considered received by the target (i.e., a 4555 command sequence gap must be assumed for the CmdSN), even though 4556 the CmdSN of the rejected command PDU may be reliably ascertained. 4557 Upon receiving the Reject, the initiator MUST plug the CmdSN gap 4558 in order to continue to use the session. The gap may be plugged 4559 either by transmitting a command PDU with the same CmdSN, or by 4560 aborting the task (see SCS on how an abort may plug a CmdSN gap). 4562 When a data PDU is rejected and its DataSN can be ascertained, a 4563 target MUST advance ExpDataSN for the current data burst if a 4564 recovery R2T is being generated. The target MAY advance its 4565 ExpDataSN if it does not attempt to recover the lost data PDU. 4567 7.4. Error Recovery Considerations for Discovery Sessions 4569 7.4.1. ErrorRecoveryLevel for Discovery Sessions 4571 The negotiation of the key ErrorRecoveryLevel is not required for 4572 Discovery sessions -- i.e., for sessions that negotiated 4573 "SessionType=Discovery" -- because the default value of 0 is 4574 necessary and sufficient for Discovery sessions. It is however 4575 possible that some legacy iSCSI implementations might attempt to 4576 negotiate the ErrorRecoveryLevel key on Discovery sessions. When 4577 such a negotiation attempt is made by the remote side, a compliant 4578 iSCSI implementation MUST propose a value of 0 (zero) in response. 4579 The operational ErrorRecoveryLevel for Discovery sessions thus 4580 MUST 4581 be 0. This naturally follows from the functionality constraints 4582 that Section 4.3 imposes on Discovery sessions. 4584 7.4.2. Reinstatement Semantics for Discovery Sessions 4586 Discovery sessions are intended to be relatively short-lived. 4587 Initiators are not expected to establish multiple Discovery 4588 sessions to the same iSCSI Network Portal. An initiator may use 4589 the same iSCSI Initiator Name and ISID when establishing different 4590 unique sessions with different targets and/or different portal 4591 groups. This behavior is discussed in Section 10.1.1 and is, in 4592 fact, encouraged as conservative reuse of ISIDs. 4594 The ISID RULE in Section 4.4.3 states that there must not be more 4595 than one session with a matching 4-tuple: . While the spirit of the ISID 4597 RULE applies to Discovery sessions the same as it does for Normal 4598 sessions, note that some Discovery sessions differ from the Normal 4599 sessions in two important aspects: 4601 Because Appendix D allows a Discovery session to be established 4602 without specifying a TargetName key in the Login Request PDU 4603 (let us call such a session an "Unnamed" Discovery session), 4604 there is no Target Node context to enforce the ISID RULE. 4606 Portal Groups are defined only in the context of a Target Node. 4607 When the TargetName key is NULL-valued (i.e., not specified), 4608 the TargetPortalGroupTag thus cannot be ascertained to enforce 4609 the ISID RULE. 4611 The following two sections describe each of the two scenarios -- 4612 Named Discovery sessions and Unnamed Discovery sessions. 4614 7.4.2.1. Unnamed Discovery Sessions 4616 For Unnamed Discovery sessions, neither the TargetName nor the 4617 TargetPortalGroupTag is available to the targets in order to 4618 enforce the ISID RULE. So the following rule applies. 4620 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 4621 following 4-tuple for Unnamed Discovery sessions: . The following semantics are implied by 4623 this uniqueness requirement. 4625 Targets SHOULD allow concurrent establishment of one Discovery 4626 session with each of its Network Portals by the same initiator 4627 port with a given iSCSI Node Name and an ISID. Each of the 4628 concurrent Discovery sessions, if established by the same 4629 initiator port to other Network Portals, MUST be treated as 4630 independent sessions -- i.e., one session MUST NOT reinstate the 4631 other. 4633 A new Unnamed Discovery session that has a matching 4634 to an existing 4635 Discovery session MUST reinstate the existing Unnamed Discovery 4636 session. Note thus that only an Unnamed Discovery session may 4637 reinstate an Unnamed Discovery session. 4639 7.4.2.2. Named Discovery Session 4641 For a Named Discovery session, the TargetName key is specified by 4642 the initiator and thus the target can unambiguously ascertain the 4643 TargetPortalGroupTag as well. Since all the four elements of the 4644 4-tuple are known, the ISID RULE MUST be enforced by targets with 4645 no changes from Section 4.4.3 semantics. A new session with a 4646 matching 4647 thus will reinstate an existing session. Note in this case that 4648 any new iSCSI session (Discovery or Normal) with the matching 4- 4649 tuple may reinstate an existing Named Discovery iSCSI session. 4651 7.4.3. Target PDUs During Discovery 4653 Targets SHOULD NOT send any responses other than a Text Response 4654 and Logout Response on a Discovery session, once in Full Feature 4655 Phase. 4657 Implementation Note: A target may simply drop the connection in a 4658 Discovery session when it would have requested a Logout via an 4659 Async Message on Normal sessions. 4661 7.5. Connection Timeout Management 4663 iSCSI defines two session-global timeout values (in seconds) - 4664 Time2Wait and Time2Retain - that are applicable when an iSCSI Full 4665 Feature Phase connection is taken out of service either 4666 intentionally or by an exception. Time2Wait is the initial 4667 "respite time" before attempting an explicit/implicit Logout for 4668 the CID in question or task reassignment for the affected tasks 4669 (if any). Time2Retain is the maximum time after the initial 4670 respite interval that the task and/or connection state(s) is/are 4671 guaranteed to be maintained on the target to cater to a possible 4672 recovery attempt. Recovery attempts for the connection and/or 4673 task(s) SHOULD NOT be made before Time2Wait seconds, but MUST be 4674 completed within Time2Retain seconds after that initial Time2Wait 4675 waiting period. 4677 7.5.1. Timeouts on Transport Exception Events 4679 A transport connection shutdown or a transport reset without any 4680 preceding iSCSI protocol interactions informing the end-points of 4681 the fact causes a Full Feature Phase iSCSI connection to be 4682 abruptly terminated. The timeout values to be used in this case 4683 are the negotiated values of defaultTime2Wait (Section 13.15 - 4684 "DefaultTime2Wait") and DefaultTime2Retain (Section 13.16 - 4685 "DefaultTime2Retain") text keys for the session. 4687 7.5.2. Timeouts on Planned Decommissioning 4689 Any planned decommissioning of a Full Feature Phase iSCSI 4690 connection is preceded by either a Logout Response PDU, or an 4691 Async Message PDU. The Time2Wait and Time2Retain field values 4692 (section 11.15) in a Logout Response PDU, and the Parameter2 and 4693 Parameter3 fields of an Async Message (AsyncEvent types "drop the 4694 connection" or "drop all the connections"; section 11.9.1) specify 4695 the timeout values to be used in each of these cases. 4697 These timeout values are only applicable for the affected 4698 connection, and the tasks active on that connection. These 4699 timeout values have no bearing on initiator timers (if any) that 4700 are already running on connections or tasks associated with that 4701 session. 4703 7.6. Implicit Termination of Tasks 4705 A target implicitly terminates the active tasks due to iSCSI 4706 protocol dynamics in the following cases: 4708 When a connection is implicitly or explicitly logged out with 4709 the reason code of "Close the connection" and there are 4710 active tasks allegiant to that connection. 4712 When a connection fails and eventually the connection state 4713 times out (state transition M1 in Section 8.2.2- "State 4714 Transition Descriptions for Initiators and Targets") and 4715 there are active tasks allegiant to that connection. 4717 When a successful Logout with the reason code of "remove the 4718 connection for recovery" is performed while there are 4719 active tasks allegiant to that connection, and those tasks 4720 eventually time out after the Time2Wait and Time2Retain 4721 periods without allegiance reassignment. 4723 When a connection is implicitly or explicitly logged out with 4724 the reason code of "Close the session" and there are active 4725 tasks in that session. 4727 If the tasks terminated in the above cases a), b, c) and d)are 4728 SCSI tasks, they must be internally terminated as if with CHECK 4729 CONDITION status. This status is only meaningful for appropriately 4730 handling the internal SCSI state and SCSI side effects with 4731 respect to ordering because this status is never communicated back 4732 as a terminating status to the initiator. However additional 4733 actions may have to be taken at SCSI level depending on the SCSI 4734 context as defined by the SCSI standards (e.g., queued commands 4735 and ACA, UA for the next command on the I_T nexus in cases a), b), 4736 and c) etc. - see [SAM2] and [SPC3]). 4738 7.7. Format Errors 4740 The following two explicit violations of PDU layout rules are 4741 format errors: 4743 Illegal contents of any PDU header field except the Opcode 4744 (legal values are specified in Section 11 - "iSCSI PDU 4745 Formats"). 4746 Inconsistent field contents (consistent field contents are 4747 specified in Section 11 - "iSCSI PDU Formats"). 4749 Format errors indicate a major implementation flaw in one of the 4750 parties. 4752 When a target or an initiator receives an iSCSI PDU with a format 4753 error, it MUST immediately terminate all transport connections in 4754 the session either with a connection close or with a connection 4755 reset and escalate the format error to session recovery (see 4756 Section Session Recovery). 4758 All initiator-detected PDU construction errors MUST be considered 4759 as format errors. Some examples of such errors are: 4760 - NOP-In with a valid TTT but an invalid LUN 4762 - NOP-In with a valid ITT (i.e., a NOP-In response) and also a 4763 valid TTT 4765 - SCSI Response PDU with Status=CHECK CONDITION, but 4766 DataSegmentLength = 0 4768 7.8. Digest Errors 4770 The discussion of the legal choices in handling digest errors 4771 below excludes session recovery as an explicit option, but either 4772 party detecting a digest error may choose to escalate the error to 4773 session recovery. 4775 When a target or an initiator receives any iSCSI PDU, with a 4776 header digest error, it MUST either discard the header and all 4777 data up to the beginning of a later PDU or close the connection. 4778 Because the digest error indicates that the length field of the 4780 header may have been corrupted, the location of the beginning of a 4781 later PDU needs to be reliably ascertained by other means such as 4782 the operation of a sync and steering layer. 4784 When a target receives any iSCSI PDU with a payload digest error, 4785 it MUST answer with a Reject PDU with a reason code of Data- 4786 Digest-Error and discard the PDU. 4788 - If the discarded PDU is a solicited or unsolicited iSCSI 4789 data PDU (for immediate data in a command PDU, non-data PDU 4790 rule below applies), the target MUST do one of the 4791 following: 4793 i) Request retransmission with a recovery R2T. 4794 ii) Terminate the task with a response PDU with a CHECK 4795 CONDITION Status and an iSCSI Condition of "protocol 4796 service CRC error" (Section 11.4.7.2 - "Sense Data"). 4797 If the target chooses to implement this option, it MUST 4798 wait to receive all the data (signaled by a Data PDU 4799 with the final bit set for all outstanding R2Ts) before 4800 sending the response PDU. A task management command 4801 (such as an abort task) from the initiator during this 4802 wait may also conclude the task. 4803 - No further action is necessary for targets if the discarded 4804 PDU is a non-data PDU. In case of immediate data being 4805 present on a discarded command, the immediate data is 4806 implicitly recovered when the task is retried (see Section 4807 7.2.1) followed by the entire data transfer for the task. 4809 When an initiator receives any iSCSI PDU with a payload digest 4810 error, it MUST discard the PDU. 4812 - If the discarded PDU is an iSCSI data PDU, the initiator 4813 MUST do one of the following: 4815 Request the desired data PDU through SNACK. In response to 4816 the SNACK, the target MUST either resend the data 4817 PDU or reject the SNACK with a Reject PDU with a 4818 reason code of "SNACK reject" in which case: 4820 If the status has not already been sent for the command, 4821 the target MUST terminate the command with a 4822 CHECK CONDITION Status and an iSCSI Condition of 4823 "SNACK rejected" (Section 11.4.7.2 - "Sense 4824 Data"). 4825 If the status was already sent, no further action is 4826 necessary for the target. The initiator in this 4827 case MUST wait for the status to be received and 4828 then discard it, so as to internally signal the 4829 completion with CHECK CONDITION Status and an 4830 iSCSI Condition of "protocol service CRC error" 4831 (Section 11.4.7.2- "Sense Data"). 4832 Abort the task and terminate the command with an error. 4834 - If the discarded PDU is a response PDU or an unsolicited PDU 4835 (e.g. Async, Reject), the initiator MUST do one of the 4836 following: 4838 Request PDU retransmission with a status SNACK. 4839 Logout the connection for recovery and continue the tasks 4840 on a different connection instance as described 4841 in Retry an. 4842 Logout to close the connection (abort all the commands 4843 associated with the connection). 4845 Note that an unsolicited PDU carries the next StatSN value on 4846 an iSCSI connection, thereby advancing the StatSN. When an 4847 initiator discards one of these PDUs due to a payload digest 4848 error, the entire PDU including the header MUST be discarded. 4849 Consequently, the initiator MUST treat the exception like a 4850 loss of any other solicited response PDU. 4852 7.9. Sequence Errors 4854 When an initiator receives an iSCSI R2T/data PDU with an out of 4855 order R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that 4856 implies missing data PDU(s), it means that the initiator must have 4857 detected a header or payload digest error on one or more earlier 4858 R2T/data PDUs. The initiator MUST address these implied digest 4859 errors as described in Section 7.8. When a target receives a data 4860 PDU with an out of order DataSN, it means that the target must 4861 have hit a header or payload digest error on at least one of the 4862 earlier data PDUs. The target MUST address these implied digest 4863 errors as described in Section 7.8. 4865 When an initiator receives an iSCSI status PDU with an out of 4866 order StatSN that implies missing responses, it MUST address the 4867 one or more missing status PDUs as described in Section 7.8. As a 4868 side effect of receiving the missing responses, the initiator may 4869 discover missing data PDUs. If the initiator wants to recover the 4870 missing data for a command, it MUST NOT acknowledge the received 4871 responses that start from the StatSN of the relevant command, 4872 until it has completed receiving all the data PDUs of the command. 4874 When an initiator receives duplicate R2TSNs (due to proactive 4875 retransmission of R2Ts by the target) or duplicate DataSNs (due to 4876 proactive SNACKs by the initiator), it MUST discard the 4877 duplicates. 4879 7.10. Message Error Checking 4881 In the iSCSI implementations till date, there has been some 4882 uncertainty on the extent to which incoming messages have to be 4883 checked for protocol errors, beyond what is strictly required for 4884 processing the inbound message. This section addresses this 4885 question. 4887 Unless this document requires it, an iSCSI implementation is not 4888 required to do an exhaustive protocol conformance check on an 4889 incoming iSCSI PDU. The iSCSI implementation especially is not 4890 required to double-check the remote iSCSI implementation's 4891 conformance to protocol requirements. 4893 7.11. SCSI Timeouts 4895 An iSCSI initiator MAY attempt to plug a command sequence gap on 4896 the target end (in the absence of an acknowledgement of the 4897 command by way of ExpCmdSN) before the ULP timeout by retrying the 4898 unacknowledged command, as described in Section 7.2. 4900 On a ULP timeout for a command (that carried a CmdSN of n), if the 4901 iSCSI initiator intends to continue the session it MUST abort the 4902 command by either using an appropriate Task Management function 4904 request for the specific command, or a "close the connection" 4905 Logout. When using an ABORT TASK, if the ExpCmdSN is still less 4906 than (n+1), the target may see the abort request while missing the 4907 original command itself due to one of the following reasons: 4909 - Original command was dropped due to digest error. 4911 - Connection on which the original command was sent was 4912 successfully logged out. On logout, the unacknowledged 4913 commands issued on the connection being logged out are 4914 discarded. 4916 If the abort request is received and the original command is 4917 missing, targets MUST consider the original command with that 4918 RefCmdSN to be received and issue a Task Management response with 4919 the response code: "Function Complete". This response concludes 4920 the task on both ends. If the abort request is received and the 4921 target can determine (based on the Referenced Task Tag) that the 4922 command was received and executed and also that the response was 4923 sent prior to the abort, then the target MUST respond with the 4924 response code of "Task Does Not Exist". 4926 7.12. Negotiation Failures 4928 Text request and response sequences, when used to set/negotiate 4929 operational parameters, constitute the negotiation/parameter 4930 setting. A negotiation failure is considered to be one or more of 4931 the following: 4933 - None of the choices, or the stated value, is acceptable to 4934 one of the sides in the negotiation. 4936 - The text request timed out and possibly terminated. 4938 - The text request was answered with a Reject PDU. 4940 The following two rules should be used to address negotiation 4941 failures: 4943 - During Login, any failure in negotiation MUST be considered 4944 a login process failure and the Login Phase must be 4945 terminated, and with it, the connection. If the target 4946 detects the failure, it must terminate the login with the 4947 appropriate login response code. 4949 - A failure in negotiation, while in the Full Feature Phase, 4950 will terminate the entire negotiation sequence that may 4951 consist of a series of text requests that use the same 4952 Initiator Task Tag. The operational parameters of the 4953 session or the connection MUST continue to be the values 4954 agreed upon during an earlier successful negotiation (i.e., 4955 any partial results of this unsuccessful negotiation MUST 4956 NOT take effect and MUST be discarded). 4958 7.13. Protocol Errors 4960 Mapping framed messages over a "stream" connection, such as TCP, 4961 makes the proposed mechanisms vulnerable to simple software 4962 framing errors. On the other hand, the introduction of framing 4963 mechanisms to limit the effects of these errors may be onerous on 4964 performance for simple implementations. Command Sequence Numbers 4965 and the above mechanisms for connection drop and reestablishment 4966 help handle this type of mapping errors. 4968 All violations of iSCSI PDU exchange sequences specified in this 4969 draft are also protocol errors. This category of errors can only 4970 be 4971 addressed by fixing the implementations; iSCSI defines Reject and 4972 response codes to enable this. 4974 7.14. Connection Failures 4976 iSCSI can keep a session in operation if it is able to 4977 keep/establish at least one TCP connection between the initiator 4978 and the target in a timely fashion. Targets and/or initiators may 4979 recognize a failing connection by either transport level means 4980 (TCP), a gap in the command sequence number, a response stream 4981 that is not filled for a long time, or by a failing iSCSI NOP 4982 (acting as a ping). The latter MAY be used periodically to 4983 increase the speed and likelihood of detecting connection 4984 failures. Initiators and targets MAY also use the keep-alive 4985 option on the TCP connection to enable early link failure 4986 detection on otherwise idle links. 4988 On connection failure, the initiator and target MUST do one of the 4989 following: 4991 - Attempt connection recovery within the session (Connection 4992 Recovery). 4994 - Logout the connection with the reason code "closes the 4995 connection" (Section 10.14.5 - "Implicit termination of 4996 tasks"), re-issue missing commands, and implicitly terminate 4997 all active commands. This option requires support for the 4998 within-connection recovery class (Recovery Within- 4999 connection). 5001 - Perform session recovery (Session Recovery). 5003 Either side may choose to escalate to session recovery (via the 5004 initiator dropping all the connections, or via an Async Message 5005 that announces the similar intent from a target), and the other 5006 side MUST give it precedence. On a connection failure, a target 5007 MUST terminate and/or discard all of the active immediate commands 5008 regardless of which of the above options is used (i.e., immediate 5009 commands are not recoverable across connection failures). 5011 7.15. Session Errors 5013 If all of the connections of a session fail and cannot be 5014 reestablished in a short time, or if initiators detect protocol 5015 errors repeatedly, an initiator may choose to terminate a session 5016 and establish a new session. 5018 In this case, the initiator takes the following actions: 5020 - Resets or closes all the transport connections. 5022 - Terminates all outstanding requests with an appropriate 5023 response before initiating a new session. If the same I_T 5024 nexus is intended to be reestablished, the initiator MUST 5025 employ session reinstatement (see section 6.3.5). 5027 When the session timeout (the connection state timeout for the 5028 last failed connection) happens on the target, it takes the 5029 following actions: 5031 - Resets or closes the TCP connections (closes the session). 5033 - Terminates all active tasks that were allegiant to the 5034 connection(s) that constituted the session. 5036 A target MUST also be prepared to handle a session reinstatement 5037 request from the initiator that may be addressing session errors. 5039 8. State Transitions 5041 iSCSI connections and iSCSI sessions go through several well- 5042 defined states from the time they are created to the time they are 5043 cleared. 5045 The connection state transitions are described in two separate but 5046 dependent state diagrams for ease in understanding. The first 5047 diagram, "standard connection state diagram", describes the 5048 connection state transitions when the iSCSI connection is not 5049 waiting for, or undergoing, a cleanup by way of an explicit or 5050 implicit Logout. The second diagram, "connection cleanup state 5051 diagram", describes the connection state transitions while 5052 performing the iSCSI connection cleanup. 5054 The "session state diagram" describes the state transitions an 5055 iSCSI session would go through during its lifetime, and it depends 5056 on the states of possibly multiple iSCSI connections that 5057 participate in the session. 5059 States and transitions are described in text, tables and diagrams. 5060 The diagrams are used for illustration. The text and the tables 5061 are the governing specification. 5063 8.1. Standard Connection State Diagrams 5065 8.1.1. State Descriptions for Initiators and Targets 5067 State descriptions for the standard connection state diagram are 5068 as follows: 5069 -S1: FREE 5070 -initiator: State on instantiation, or after successful 5071 connection closure. 5072 -target: State on instantiation, or after successful 5073 connection closure. 5074 -S2: XPT_WAIT 5075 -initiator: Waiting for a response to its transport 5076 connection establishment request. 5077 -target: Illegal 5078 -S3: XPT_UP 5079 -initiator: Illegal 5080 -target: Waiting for the Login process to commence. 5082 -S4: IN_LOGIN 5083 -initiator: Waiting for the Login process to conclude, 5084 possibly involving several PDU exchanges. 5085 -target: Waiting for the Login process to conclude, 5086 possibly involving several PDU exchanges. 5087 -S5: LOGGED_IN 5088 -initiator: In Full Feature Phase, waiting for all 5089 internal, iSCSI, and transport events. 5090 -target: In Full Feature Phase, waiting for all internal, 5091 iSCSI, and transport events. 5092 -S6: IN_LOGOUT 5093 -initiator: Waiting for a Logout response. 5094 -target: Waiting for an internal event signaling completion 5095 of logout processing. 5096 -S7: LOGOUT_REQUESTED 5097 -initiator: Waiting for an internal event signaling 5098 readiness to proceed with Logout. 5099 -target: Waiting for the Logout process to start after 5100 having requested a Logout via an Async Message. 5101 -S8: CLEANUP_WAIT 5102 -initiator: Waiting for the context and/or resources to 5103 initiate the cleanup processing for this CSM. 5104 -target: Waiting for the cleanup process to start for this 5105 CSM. 5106 8.1.2. State Transition Descriptions for Initiators and Targets 5108 -T1: 5109 -initiator: Transport connect request was made (e.g., TCP 5110 SYN sent). 5111 -target: Illegal 5112 -T2: 5113 -initiator: Transport connection request timed out, a 5114 transport reset was received, or an internal event of 5115 receiving a Logout response (success) on another connection 5116 for a "close the session" Logout request was received. 5117 -target:Illegal 5118 -T3: 5119 -initiator: Illegal 5120 -target: Received a valid transport connection request that 5121 establishes the transport connection. 5122 -T4: 5124 -initiator: Transport connection established, thus 5125 prompting the initiator to start the iSCSI Login. 5126 -target: Initial iSCSI Login request was received. 5127 -T5: 5128 -initiator: The final iSCSI Login response with a Status- 5129 Class of zero was received. 5130 -target: The final iSCSI Login request to conclude the 5131 Login Phase was received, thus prompting the target to send 5132 the final iSCSI Login response with a Status-Class of zero. 5133 -T6: 5134 -initiator: Illegal 5135 -target: Timed out waiting for an iSCSI Login, transport 5136 disconnect indication was received, transport reset was 5137 received, or an internal event indicating a transport 5138 timeout was received. In all these cases, the connection is 5139 to be closed. 5140 -T7: 5141 -initiator - one of the following events caused the 5142 transition: 5143 - The final iSCSI Login response was received with a 5144 non-zero Status-Class. 5145 - Login timed out. 5146 - A transport disconnect indication was received. 5147 - A transport reset was received. 5148 - An internal event indicating a transport timeout was 5149 received. 5150 - An internal event of receiving a Logout response 5151 (success) on another connection for a "close the 5152 session" Logout request was received. 5154 In all these cases, the transport connection is closed. 5156 -target - one of the following events caused the 5157 transition: 5158 - The final iSCSI Login request to conclude the Login 5159 Phase was received, prompting the target to send the 5160 final iSCSI Login response with a non-zero Status- 5161 Class. 5162 - Login timed out. 5163 - Transport disconnect indication was received. 5165 - Transport reset was received. 5166 - An internal event indicating a transport timeout was 5167 received . 5168 - On another connection a "close the session" 5169 Logout request was received. 5171 In all these cases, the connection is to be closed. 5172 -T8: 5173 -initiator: An internal event of receiving a Logout 5174 response (success) on another connection for a "close the 5175 session" Logout request was received, thus closing this 5176 connection requiring no further cleanup. 5177 -target: An internal event of sending a Logout response 5178 (success) on another connection for a "close the session" 5179 Logout request was received, or an internal event of a 5180 successful connection/session reinstatement is received, 5181 thus prompting the target to close this connection cleanly. 5182 -T9, T10: 5183 -initiator: An internal event that indicates the readiness 5184 to start the Logout process was received, thus prompting an 5185 iSCSI Logout to be sent by the initiator. 5186 -target: An iSCSI Logout request was received. 5187 -T11, T12: 5188 -initiator: Async PDU with AsyncEvent "Request Logout" was 5189 received. 5190 -target: An internal event that requires the 5191 decommissioning of the connection is received, thus causing 5192 an Async PDU with an AsyncEvent "Request Logout" to be 5193 sent. 5194 -T13: 5195 -initiator: An iSCSI Logout response (success) was 5196 received, or an internal event of receiving a Logout 5197 response (success) on another connection for a "close the 5198 session" Logout request was received. 5199 -target: An internal event was received that indicates 5200 successful processing of the Logout, which prompts an iSCSI 5201 Logout response (success) to be sent; an internal event of 5202 sending a Logout response (success) on another connection 5203 for a "close the session" Logout request was received; or 5204 an internal event of a successful connection/session 5205 reinstatement is received. In all these cases, the 5206 transport connection is closed. 5208 -T14: 5209 -initiator: Async PDU with AsyncEvent "Request Logout" was 5210 received again. 5211 -target: Illegal 5212 -T15, T16: 5213 -initiator: One or more of the following events caused this 5214 transition: 5215 -Internal event that indicates a transport connection 5216 timeout was received thus prompting transport RESET or 5217 transport connection closure. 5218 -A transport RESET. 5219 -A transport disconnect indication. 5220 -Async PDU with AsyncEvent "Drop connection" (for this 5221 CID). 5222 -Async PDU with AsyncEvent "Drop all connections". 5223 -target: One or more of the following events caused this 5224 transition: 5225 -Internal event that indicates a transport connection 5226 timeout was received, thus prompting transport RESET or 5227 transport connection closure. 5228 -An internal event of a failed connection/session 5229 reinstatement is received. 5230 -A transport RESET. 5231 -A transport disconnect indication. 5232 -Internal emergency cleanup event was received which 5233 prompts an Async PDU with AsyncEvent "Drop connection" 5234 (for this CID), or event "Drop all connections". 5236 -T17: 5237 -initiator: One or more of the following events caused this 5238 transition: 5239 -Logout response, (failure i.e., a non-zero status) was 5240 received, or Logout timed out. 5241 -Any of the events specified for T15 and T16. 5242 -target: One or more of the following events caused this 5243 transition: 5245 -Internal event that indicates a failure of the Logout 5246 processing was received, which prompts a Logout 5247 response (failure, i.e., a non-zero status) to be sent. 5248 -Any of the events specified for T15 and T16. 5249 -T18: 5250 -initiator: An internal event of receiving a Logout 5251 response (success) on another connection for a "close the 5252 session" Logout request was received. 5254 -target: An internal event of sending a Logout response 5255 (success) on another connection for a "close the session" 5256 Logout request was received, or an internal event of a 5257 successful connection/session reinstatement is received. 5258 In both these cases, the connection is closed. 5260 The CLEANUP_WAIT state (S8) implies that there are possible iSCSI 5261 tasks that have not reached conclusion and are still considered 5262 busy. 5264 8.1.3. Standard Connection State Diagram for an Initiator 5266 Symbolic names for States: 5268 S1: FREE 5270 S2: XPT_WAIT 5272 S4: IN_LOGIN 5274 S5: LOGGED_IN 5276 S6: IN_LOGOUT 5278 S7: LOGOUT_REQUESTED 5280 S8: CLEANUP_WAIT 5282 States S5, S6, and S7 constitute the Full Feature Phase operation 5283 of the connection. 5285 The state diagram is as follows: 5287 -------<-------------+ 5288 +--------->/ S1 \<----+ | 5289 T13| +->\ /<-+ \ | 5290 | / ---+--- \ \ | 5291 | / | T2 \ | | 5292 | T8 | |T1 | | | 5293 | | | / |T7 | 5294 | | | / | | 5295 | | | / | | 5296 | | V / / | 5297 | | ------- / / | 5298 | | / S2 \ / | 5299 | | \ / / | 5300 | | ---+--- / | 5301 | | |T4 / | 5302 | | V / | T18 5303 | | ------- / | 5304 | | / S4 \ | 5305 | | \ / | 5306 | | ---+--- | T15 5307 | | |T5 +--------+---------+ 5308 | | | /T16+-----+------+ | 5309 | | | / -+-----+--+ | | 5310 | | | / / S7 \ |T12| | 5311 | | | / +->\ /<-+ V V 5312 | | | / / -+----- ------- 5313 | | | / /T11 |T10 / S8 \ 5314 | | V / / V +----+ \ / 5315 | | ---+-+- ----+-- | ------- 5316 | | / S5 \T9 / S6 \<+ ^ 5317 | +-----\ /--->\ / T14 | 5318 | ------- --+----+------+T17 5319 +---------------------------+ 5321 The following state transition table represents the above diagram. 5322 Each row represents the starting state for a given transition, 5323 which after taking a transition marked in a table cell would end 5324 in the state represented by the column of the cell. For example, 5325 from state S1, the connection takes the T1 transition to arrive at 5326 state S2. The fields marked "-" correspond to undefined 5327 transitions. 5329 +----+---+---+---+---+----+---+ 5330 |S1 |S2 |S4 |S5 |S6 |S7 |S8 | 5331 ---+----+---+---+---+---+----+---+ 5332 S1| - |T1 | - | - | - | - | - | 5333 ---+----+---+---+---+---+----+---+ 5334 S2|T2 |- |T4 | - | - | - | - | 5335 ---+----+---+---+---+---+----+---+ 5336 S4|T7 |- |- |T5 | - | - | - | 5337 ---+----+---+---+---+---+----+---+ 5338 S5|T8 |- |- | - |T9 |T11 |T15| 5339 ---+----+---+---+---+---+----+---+ 5340 S6|T13 |- |- | - |T14|- |T17| 5341 ---+----+---+---+---+---+----+---+ 5342 S7|T18 |- |- | - |T10|T12 |T16| 5343 ---+----+---+---+---+---+----+---+ 5344 S8| - |- |- | - | - | - | - | 5345 ---+----+---+---+---+---+----+---+ 5347 8.1.4. Standard Connection State Diagram for a Target 5349 Symbolic names for States: 5350 S1: FREE 5352 S3: XPT_UP 5354 S4: IN_LOGIN 5356 S5: LOGGED_IN 5358 S6: IN_LOGOUT 5360 S7: LOGOUT_REQUESTED 5362 S8: CLEANUP_WAIT 5364 States S5, S6, and S7 constitute the Full Feature Phase operation 5365 of the connection. 5367 The state diagram is as follows: 5369 -------<-------------+ 5370 +--------->/ S1 \<----+ | 5371 T13| +->\ /<-+ \ | 5372 | / ---+--- \ \ | 5373 | / | T6 \ | | 5374 | T8 | |T3 | | | 5375 | | | / |T7 | 5376 | | | / | | 5377 | | | / | | 5378 | | V / / | 5379 | | ------- / / | 5380 | | / S3 \ / | 5381 | | \ / / | T18 5382 | | ---+--- / | 5383 | | |T4 / | 5384 | | V / | 5385 | | ------- / | 5386 | | / S4 \ | 5387 | | \ / | 5388 | | ---+--- T15 | 5389 | | |T5 +--------+---------+ 5390 | | | /T16+-----+------+ | 5391 | | | / -+-----+---+ | | 5392 | | | / / S7 \ |T12| | 5393 | | | / +->\ /<-+ V V 5394 | | | / / -+----- ------- 5395 | | | / /T11 |T10 / S8 \ 5396 | | V / / V \ / 5397 | | ---+-+- ------- ------- 5398 | | / S5 \T9 / S6 \ ^ 5399 | +-----\ /--->\ / | 5400 | ------- --+----+--------+T17 5401 +---------------------------+ 5403 The following state transition table represents the above diagram, 5404 and follows the conventions described for the initiator diagram. 5406 +----+---+---+---+---+----+---+ 5407 |S1 |S3 |S4 |S5 |S6 |S7 |S8 | 5408 ---+----+---+---+---+---+----+---+ 5409 S1| - |T3 | - | - | - | - | - | 5410 ---+----+---+---+---+---+----+---+ 5411 S3|T6 |- |T4 | - | - | - | - | 5412 ---+----+---+---+---+---+----+---+ 5413 S4|T7 |- |- |T5 | - | - | - | 5414 ---+----+---+---+---+---+----+---+ 5415 S5|T8 |- |- | - |T9 |T11 |T15| 5416 ---+----+---+---+---+---+----+---+ 5417 S6|T13 |- |- | - |- |- |T17| 5418 ---+----+---+---+---+---+----+---+ 5419 S7|T18 |- |- | - |T10|T12 |T16| 5420 ---+----+---+---+---+---+----+---+ 5421 S8| - |- |- | - | - | - | - | 5422 ---+----+---+---+---+---+----+---+ 5424 8.2. Connection Cleanup State Diagram for Initiators and Targets 5426 Symbolic names for states: 5428 R1: CLEANUP_WAIT (same as S8) 5430 R2: IN_CLEANUP 5432 R3: FREE (same as S1) 5434 Whenever a connection state machine in cleanup (let's call it CSM- 5435 C) enters the CLEANUP_WAIT state (S8), it must go through the 5436 state transitions described in the connection cleanup state 5437 diagram either a) using a separate full-feature phase connection 5438 (let's call it CSM-E, for explicit) in the LOGGED_IN state in the 5439 same session, or b) using a new transport connection (let's call 5440 it CSM-I, for implicit) in the FREE state that is to be added to 5441 the same session. In the CSM-E case, an explicit logout for the 5442 CID that corresponds to CSM-C (either as a connection or session 5443 logout) needs to be performed to complete the cleanup. In the CSM- 5444 I case, an implicit logout for the CID that corresponds to CSM-C 5445 needs to be performed by way of connection reinstatement (section 5446 6.3.4) for that CID. In either case, the protocol exchanges on 5447 CSM-E or CSM-I determine the state transitions for CSM-C. 5448 Therefore, this cleanup state diagram is only applicable to the 5449 instance of the connection in cleanup (i.e., CSM-C). In the case 5450 of an implicit logout for example, CSM-C reaches FREE (R3) at the 5451 time CSM-I reaches LOGGED_IN. In the case of an explicit logout, 5452 CSM-C reaches FREE (R3) when CSM-E receives a successful logout 5453 response while continuing to be in the LOGGED_IN state. 5455 An initiator must initiate an explicit or implicit connection 5456 logout for a connection in the CLEANUP_WAIT state, if the 5457 initiator intends to continue using the associated iSCSI session. 5459 The following state diagram applies to both initiators and 5460 targets. 5462 ------- 5463 / R1 \ 5464 +--\ /<-+ 5465 / ---+--- \ 5466 / | \ M3 5467 M1 | |M2 | 5468 | | / 5469 | | / 5470 | | / 5471 | V / 5472 | ------- / 5473 | / R2 \ 5474 | \ / 5475 | ------- 5476 | | 5477 | |M4 5478 | | 5479 | | 5480 | | 5481 | V 5482 | ------- 5483 | / R3 \ 5484 +---->\ / 5485 ------- 5487 The following state transition table represents the above diagram, 5488 and follows the same conventions as in earlier sections. 5490 +----+----+----+ 5491 |R1 |R2 |R3 | 5492 -----+----+----+----+ 5493 R1 | - |M2 |M1 | 5494 -----+----+----+----+ 5495 R2 |M3 | - |M4 | 5496 -----+----+----+----+ 5497 R3 | - | - | - | 5498 -----+----+----+----+ 5500 8.2.1. State Descriptions for Initiators and Targets 5502 -R1: CLEANUP_WAIT (Same as S8) 5503 -initiator: Waiting for the internal event to initiate the 5504 cleanup processing for CSM-C. 5505 -target: Waiting for the cleanup process to start for CSM- 5506 C. 5507 -R2: IN_CLEANUP 5508 -initiator: Waiting for the connection cleanup process to 5509 conclude for CSM-C. 5510 -target: Waiting for the connection cleanup process to 5511 conclude for CSM-C. 5512 -R3: FREE (Same as S1) 5513 -initiator: End state for CSM-C. 5514 -target: End state for CSM-C. 5516 8.2.2. State Transition Descriptions for Initiators and Targets 5518 -M1: One or more of the following events was received: 5519 -initiator: 5520 -An internal event that indicates connection state 5521 timeout. 5522 -An internal event of receiving a successful Logout 5523 response on a different connection for a "close the 5524 session" Logout. 5525 -target: 5526 -An internal event that indicates connection state 5527 timeout. 5528 -An internal event of sending a Logout response 5529 (success) on a different connection for a "close the 5530 session" Logout request. 5532 -M2: An implicit/explicit logout process was initiated by the 5533 initiator. 5534 -In CSM-I usage: 5535 -initiator: An internal event requesting the connection 5536 (or session) reinstatement was received, thus prompting 5537 a connection (or session) reinstatement Login to be 5538 sent transitioning CSM-I to state IN_LOGIN. 5539 -target: A connection/session reinstatement Login was 5540 received while in state XPT_UP. 5541 -In CSM-E usage: 5543 -initiator: An internal event that indicates that an 5544 explicit logout was sent for this CID in state 5545 LOGGED_IN. 5546 -target: An explicit logout was received for this CID 5547 in state LOGGED_IN. 5548 -M3: Logout failure detected 5549 -In CSM-I usage: 5550 -initiator: CSM-I failed to reach LOGGED_IN and arrived 5551 into FREE instead. 5552 -target: CSM-I failed to reach LOGGED_IN and arrived 5553 into FREE instead. 5554 -In CSM-E usage: 5555 -initiator: CSM-E either moved out of LOGGED_IN, or 5556 Logout timed out and/or aborted, or Logout response 5557 (failure) was received. 5558 -target: CSM-E either moved out of LOGGED_IN, Logout 5559 timed out and/or aborted, or an internal event that 5560 indicates a failed Logout processing was received. A 5561 Logout response (failure) was sent in the last case. 5563 -M4: Successful implicit/explicit logout was performed. 5564 - In CSM-I usage: 5565 -initiator: CSM-I reached state LOGGED_IN, or an 5566 internal event of receiving a Logout response (success) 5567 on another connection for a "close the session" Logout 5568 request was received. 5569 -target: CSM-I reached state LOGGED_IN, or an internal 5570 event of sending a Logout response (success) on a 5571 different connection for a "close the session" Logout 5572 request was received. 5573 - In CSM-E usage: 5574 -initiator: CSM-E stayed in LOGGED_IN and received a 5575 Logout response (success), or an internal event of 5576 receiving a Logout response (success) on another 5577 connection for a "close the session" Logout request was 5578 received. 5579 -target: CSM-E stayed in LOGGED_IN and an internal 5580 event indicating a successful Logout processing was 5581 received, or an internal event of sending a Logout 5582 response (success) on a different connection for a 5583 "close the session" Logout request was received. 5585 8.3. Session State Diagrams 5587 8.3.1. Session State Diagram for an Initiator 5589 Symbolic Names for States: 5591 Q1: FREE 5593 Q3: LOGGED_IN 5595 Q4: FAILED 5597 State Q3 represents the Full Feature Phase operation of the 5598 session. 5600 The state diagram is as follows: 5602 ------- 5603 / Q1 \ 5604 +------>\ /<-+ 5605 / ---+--- | 5606 / | |N3 5607 N6 | |N1 | 5608 | | | 5609 | N4 | | 5610 | +----------+ | / 5611 | | | | / 5612 | | | | / 5613 | | V V / 5614 -+--+-- -----+- 5615 / Q4 \ N5 ---/ Q3 \ 5616 \ /<------\ / 5617 ------- ------- 5619 The state transition table is as follows: 5621 +---+---+---+ 5622 |Q1 |Q3 |Q4 | 5623 -----+---+---+---+ 5624 Q1 | - |N1 | - | 5625 -----+---+---+---+ 5626 Q3 |N3 | - |N5 | 5627 -----+---+---+---+ 5628 Q4 |N6 |N4 | - | 5629 -----+---+---+---+ 5631 8.3.2. Session State Diagram for a Target 5633 Symbolic Names for States: 5635 Q1: FREE 5637 Q2: ACTIVE 5639 Q3: LOGGED_IN 5641 Q4: FAILED 5643 Q5: IN_CONTINUE 5645 State Q3 represents the Full Feature Phase operation of the 5646 session. 5648 The state diagram is as follows: 5650 ------- 5651 +------------------>/ Q1 \ 5652 / +-------------->\ /<-+ 5653 | | ---+--- | 5654 | | ^ | |N3 5655 N 6 | |N11 N9| V N1 | 5656 | | +------ | 5657 | | / Q2 \ | 5658 | | \ / | 5659 | --+---- +--+--- | 5660 | / Q5 \ | | 5661 | \ / N10 | | 5662 | +-+---+------------+ | N2 / 5663 | ^ | | | / 5664 | N7| |N8 | | / 5665 | | | | V / 5666 -+---+-V V------+- 5667 / Q4 \ N5 / Q3 \ 5668 \ /<-------------\ / 5669 ------- ------- 5671 The state transition table is as follows: 5673 +----+----+----+----+----+ 5674 |Q1 |Q2 |Q3 |Q4 |Q5 | 5675 -----+----+----+----+----+----+ 5676 Q1 | - |N1 | - | - | - | 5677 -----+----+----+----+----+----+ 5678 Q2 |N9 | - |N2 | - | - | 5679 -----+----+----+----+----+----+ 5680 Q3 |N3 | - | - |N5 | - | 5681 -----+----+----+----+----+----+ 5682 Q4 |N6 | - | - | - |N7 | 5683 -----+----+----+----+----+----+ 5684 Q5 |N11 | - |N10 |N8 | - | 5685 -----+----+----+----+----+----+ 5687 8.3.3. State Descriptions for Initiators and Targets 5689 -Q1: FREE 5690 -initiator: State on instantiation or after cleanup. 5692 -target: State on instantiation or after cleanup. 5693 -Q2: ACTIVE 5694 -initiator: Illegal. 5695 -target: The first iSCSI connection in the session 5696 transitioned to IN_LOGIN, waiting for it to complete the 5697 login process. 5698 -Q3: LOGGED_IN 5699 -initiator: Waiting for all session events. 5700 -target: Waiting for all session events. 5701 -Q4: FAILED 5702 -initiator: Waiting for session recovery or session 5703 continuation. 5704 -target: Waiting for session recovery or session 5705 continuation. 5706 -Q5: IN_CONTINUE 5707 -initiator: Illegal. 5708 -target: Waiting for session continuation attempt to reach 5709 a conclusion. 5711 8.3.4. State Transition Descriptions for Initiators and Targets 5713 -N1: 5714 -initiator: At least one transport connection reached the 5715 LOGGED_IN state. 5716 -target: The first iSCSI connection in the session had 5717 reached the IN_LOGIN state. 5718 -N2: 5719 -initiator: Illegal. 5720 -target: At least one iSCSI connection reached the 5721 LOGGED_IN state. 5722 -N3: 5723 -initiator: Graceful closing of the session via session 5724 closure (Section 6.3.6 - "Session Continuation and 5725 Failure"). 5726 -target: Graceful closing of the session via session 5727 closure (Section 6.3.6 - "Session Continuation and 5728 Failure") or a successful session reinstatement cleanly 5729 closed the session. 5730 -N4: 5731 -initiator: A session continuation attempt succeeded. 5733 -target: Illegal. 5734 -N5: 5735 -initiator: Session failure (Section 6.3.6 - "Session 5736 Continuation and Failure") occurred. 5737 -target: Session failure (Section 6.3.6- "Session 5738 Continuation and Failure") occurred. 5739 -N6: 5740 -initiator: Session state timeout occurred, or a session 5741 reinstatement cleared this session instance. This results 5742 in the freeing of all associated resources and the session 5743 state is discarded. 5744 -target: Session state timeout occurred, or a session 5745 reinstatement cleared this session instance. This results 5746 in the freeing of all associated resources and the session 5747 state is discarded. 5748 -N7: 5749 -initiator: Illegal. 5750 -target: A session continuation attempt is initiated. 5751 -N8: 5752 -initiator: Illegal. 5753 -target: The last session continuation attempt failed. 5754 -N9: 5755 -initiator: Illegal. 5756 -target: Login attempt on the leading connection failed. 5757 -N10: 5758 -initiator: Illegal. 5759 -target: A session continuation attempt succeeded. 5760 -N11: 5761 -initiator: Illegal. 5762 -target: A successful session reinstatement cleanly closed 5763 the session. 5765 9. Security Considerations 5767 Historically, native storage systems have not had to consider 5768 security because their environments offered minimal security 5769 risks. That is, these environments consisted of storage devices 5770 either directly attached to hosts or connected via a Storage Area 5771 Network (SAN) distinctly separate from the communications network. 5772 The use of storage protocols, such as SCSI, over IP-networks 5773 requires that security concerns be addressed. iSCSI 5774 implementations MUST provide means of protection against active 5775 attacks (e.g., pretending to be another identity, message 5776 insertion, deletion, modification, and replaying) and passive 5777 attacks (e.g.,eavesdropping, gaining advantage by analyzing the 5778 data sent over the line). 5780 Although technically possible, iSCSI SHOULD NOT be configured 5781 without security. iSCSI configured without security should be 5782 confined, in extreme cases, to closed environments without any 5783 security risk. [RFC3723] specifies the mechanisms that must be 5784 used in order to mitigate risks fully described in that document. 5786 The following section describes the security mechanisms provided 5787 by an iSCSI implementation. 5789 9.1. iSCSI Security Mechanisms 5791 The entities involved in iSCSI security are the initiator, target, 5792 and the IP communication end points. iSCSI scenarios in which 5793 multiple initiators or targets share a single communication end 5794 point are expected. To accommodate such scenarios, iSCSI uses two 5795 separate security mechanisms: In-band authentication between the 5796 initiator and the target at the iSCSI connection level (carried 5797 out by exchange of iSCSI Login PDUs), and packet protection 5798 (integrity, authentication, and confidentiality) by IPsec at the 5799 IP level. The two security mechanisms complement each other. The 5800 in-band authentication provides end-to-end trust (at login time) 5801 between the iSCSI initiator and the target while IPsec provides a 5802 secure channel between the IP communication end points. 5804 Further details on typical iSCSI scenarios and the relation 5805 between the initiators, targets, and the communication end points 5806 can be found in [RFC3723]. 5808 9.2. In-band Initiator-Target Authentication 5810 During login, the target MAY authenticate the initiator and the 5811 initiator MAY authenticate the target. The authentication is 5812 performed on every new iSCSI connection by an exchange of iSCSI 5813 Login PDUs using a negotiated authentication method. 5815 The authentication method cannot assume an underlying IPsec 5816 protection, because IPsec is optional to use. An attacker should 5817 gain as little advantage as possible by inspecting the 5818 authentication phase PDUs. Therefore, a method using clear text 5819 (or equivalent) passwords is not acceptable; on the other hand, 5820 identity protection is not strictly required. 5822 The authentication mechanism protects against an unauthorized 5823 login to storage resources by using a false identity (spoofing). 5824 Once the authentication phase is completed, if the underlying 5825 IPsec is not used, all PDUs are sent and received in clear. The 5826 authentication mechanism alone (without underlying IPsec) should 5827 only be used when there is no risk of eavesdropping, message 5828 insertion, deletion, modification, and replaying. 5830 Section 11 - "iSCSI Security Text Keys and Authentication Methods" 5831 defines several authentication methods and the exact steps that 5832 must be followed in each of them, including the iSCSI-text-keys 5833 and their allowed values in each step. Whenever an iSCSI initiator 5834 gets a response whose keys, or their values, are not according to 5835 the step definition, it MUST abort the connection. Whenever an 5836 iSCSI target gets a response whose keys, or their values, are not 5837 according to the step definition, it MUST answer with a Login 5838 reject with the "Initiator Error" or "Missing Parameter" status. 5839 These statuses are not intended for cryptographically incorrect 5840 values such as the CHAP response, for which "Authentication 5841 Failure" status MUST be specified. The importance of this rule can 5842 be illustrated in CHAP with target authentication (see Section 5843 12.1.3- "Challenge Handshake Authentication Protocol (CHAP)") 5844 where the initiator would have been able to conduct a reflection 5845 attack by omitting his response key (CHAP_R) using the same CHAP 5846 challenge as the target and reflecting the target's response back 5847 to the target. In CHAP, this is prevented because the target must 5848 answer the missing CHAP_R key with a Login reject with the 5849 "Missing Parameter" status. 5851 For some of the authentication methods, a key specifies the 5852 identity of the iSCSI initiator or target for authentication 5853 purposes. The value associated with that key MAY be different from 5854 the iSCSI name and SHOULD be configurable. (CHAP_N, see Section 5855 12.1.3 - "Challenge Handshake Authentication Protocol (CHAP)" and 5856 SRP_U, see Section 12.1.2- "Secure Remote Password (SRP)"). 5858 9.2.1. CHAP Considerations 5860 Compliant iSCSI initiators and targets MUST implement the CHAP 5861 authentication method [RFC1994] (according to Section 12.1.3 - 5862 "Challenge Handshake Authentication Protocol (CHAP)" including the 5863 target authentication option). 5865 When CHAP is performed over a non-encrypted channel, it is 5866 vulnerable to an off-line dictionary attack. Implementations MUST 5867 support use of up to 128 bit random CHAP secrets, including the 5868 means to generate such secrets and to accept them from an external 5869 generation source. Implementations MUST NOT provide secret 5870 generation (or expansion) means other than random generation. 5872 An administrative entity of an environment in which CHAP is used 5873 with a secret that has less than 96 random bits MUST enforce IPsec 5874 encryption (according to the implementation requirements in 5875 Confidentiality) to protect the connection. Moreover, in this case 5876 IKE authentication with group pre-shared cryptographic keys SHOULD 5877 NOT be used unless it is not essential to protect group members 5878 against off-line dictionary attacks by other members. 5880 CHAP secrets MUST be an integral number of bytes (octets). A 5881 compliant implementation SHOULD NOT continue with the login step 5882 in which it should send a CHAP response (CHAP_R, Section 12.1.3- 5883 "Challenge Handshake Authentication Protocol (CHAP)") unless it 5884 can verify that the CHAP secret is at least 96 bits, or that IPsec 5885 encryption is being used to protect the connection. 5887 Any CHAP secret used for initiator authentication MUST NOT be 5888 configured for authentication of any target, and any CHAP secret 5889 used for target authentication MUST NOT be configured for 5890 authentication of any initiator. If the CHAP response received by 5891 one end of an iSCSI connection is the same as the CHAP response 5892 that the receiving endpoint would have generated for the same CHAP 5893 challenge, the response MUST be treated as an authentication 5894 failure and cause the connection to close (this ensures that the 5895 same CHAP secret is not used for authentication in both 5896 directions). Also, if an iSCSI implementation can function as 5897 both initiator and target, different CHAP secrets and identities 5898 MUST be configured for these two roles. The following is an 5899 example of the attacks prevented by the above requirements: 5901 Rogue wants to impersonate Storage to Alice, and knows that a 5902 single secret is used for both directions of Storage-Alice 5903 authentication. 5905 Rogue convinces Alice to open two connections to Rogue, and 5906 Rogue identifies itself as Storage on both connections. 5908 Rogue issues a CHAP challenge on connection 1, waits for Alice 5909 to respond, and then reflects Alice's challenge as the 5910 initial challenge to Alice on connection 2. 5912 If Alice doesn't check for the reflection across connections, 5913 Alice's response on connection 2 enables Rogue to 5914 impersonate Storage on connection 1, even though Rogue does 5915 not know the Alice-Storage CHAP secret. 5917 Originators MUST NOT reuse the CHAP challenge sent by the 5918 Responder for the other direction of a bidirectional 5919 authentication. Responders MUST check for this condition and close 5920 the iSCSI TCP connection if it occurs. 5922 The same CHAP secret SHOULD NOT be configured for authentication 5923 of multiple initiators or multiple targets, as this enables any of 5924 them to impersonate any other one of them, and compromising one of 5925 them enables the attacker to impersonate any of them. It is 5926 recommended that iSCSI implementations check for use of identical 5927 CHAP secrets by different peers when this check is feasible, and 5928 take appropriate measures to warn users and/or administrators when 5929 this is detected. 5931 When an iSCSI initiator or target authenticates itself to 5932 counterparts in multiple administrative domains, it SHOULD use a 5933 different CHAP secret for each administrative domain to avoid 5934 propagating security compromises across domains. 5936 Within a single administrative domain: 5937 - A single CHAP secret MAY be used for authentication of an 5938 initiator to multiple targets. 5940 - A single CHAP secret MAY be used for an authentication of a 5941 target to multiple initiators when the initiators use an 5942 external server (e.g., RADIUS) to verify the target's CHAP 5943 responses and do not know the target's CHAP secret. 5945 If an external response verification server (e.g., RADIUS) is not 5946 used, employing a single CHAP secret for authentication of a 5947 target to multiple initiators requires that all such initiators 5948 know that target secret. Any of these initiators can impersonate 5949 the target to any other such initiator, and compromise of such an 5950 initiator enables an attacker to impersonate the target to all 5951 such initiators. Targets SHOULD use separate CHAP secrets for 5952 authentication to each initiator when such risks are of concern; 5953 in this situation it may be useful to configure a separate logical 5954 iSCSI target with its own iSCSI Node Name for each initiator or 5955 group of initiators among which such separation is desired. 5957 9.2.2. SRP Considerations 5959 The strength of the SRP authentication method (specified in 5960 [RFC2945]) is dependent on the characteristics of the group being 5961 used (i.e., the prime modulus N and generator g). As described in 5962 [RFC2945], N is required to be a Sophie-German prime (of the form 5963 N = 2q + 1, where q is also prime) and the generator g is a 5964 primitive root of GF(n). In iSCSI authentication, the prime 5965 modulus N MUST be at least 768 bits. 5967 The list of allowed SRP groups is provided in [RFC3723]. 5969 9.3. IPsec 5971 iSCSI uses the IPsec mechanism for packet protection 5972 (cryptographic integrity, authentication, and confidentiality) at 5973 the IP level between the iSCSI communicating end points. The 5974 following sections describe the IPsec protocols that must be 5975 implemented for data integrity and authentication, 5976 confidentiality, and cryptographic key management. 5978 An iSCSI initiator or target may provide the required IPsec 5979 support fully integrated or in conjunction with an IPsec front-end 5980 device. In the latter case, the compliance requirements with 5981 regard to IPsec support apply to the "combined device". Only the 5982 "combined device" is to be considered an iSCSI device. 5984 Detailed considerations and recommendations for using IPsec for 5985 iSCSI are provided in [RFC3723]. 5987 This document updates RFC 3723 to add requirements for IPsec v3 5988 as specified in [RFC4301] and related RFCs. The IPsec v2 "MUST 5989 implement" requirements from [RFC3723] are left unchanged by this 5990 document; this document adds requirements that IPsec v3, as 5991 specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), 5992 SHOULD be implemented. The mandatory requirement for IPsec v2 5993 preserves interoperability with existing implementations, and the 5994 strong recommendation for IPsec v3 encourages implementers to move 5995 forward to that newer version of IPsec. 5997 9.3.1. Data Integrity and Authentication 5999 Data authentication and integrity is provided by a cryptographic 6000 keyed Message Authentication Code in every sent packet. This code 6001 protects against message insertion, deletion, and modification. 6002 Protection against message replay is realized by using a sequence 6003 counter. 6005 An iSCSI-compliant initiator or target MUST provide data integrity 6006 and authentication by implementing IPsec v2 [RFC2401] with ESPv2 6007 [RFC2406] in tunnel mode, SHOULD provide data integrity and 6008 authentication by implementing IPsec v3 [RFC4301] with ESPv3 6009 [RFC4303] in tunnel mode, and MAY provide data integrity and 6011 authentication by implementing either IPsec v2 or v3 with the 6012 appropriate version of ESP in transport mode. The IPsec 6013 implementation MUST fulfill the following iSCSI specific 6014 requirements: 6016 - HMAC-SHA1 MUST be implemented [RFC2404]. 6018 - AES CBC MAC with XCBC extensions SHOULD be implemented 6019 [RFC3566]. 6021 - Implementations that support IKEv2 [RFC5996] SHOULD also 6022 implement AES GMAC [RFC4543] 6024 The ESP anti-replay service MUST also be implemented. 6026 At the high speeds iSCSI is expected to operate, a single IPsec SA 6027 could rapidly cycle through the ESP 32-bit sequence number space. 6028 In view of this, an iSCSI implementation that is capable of 6029 operating at speeds of 1 Gbps and that implements both IKEv2 6030 [RFC5996] and ESPv3 [RFC4303] MUST also implement extended (64- 6031 bit) sequence numbers for ESPv3 and SHOULD use ESPv3 extended 6032 sequence numbers for all security associations that use ESPv3 to 6033 protect iSCSI connections. 6034 9.3.2. Confidentiality 6036 Confidentiality is provided by encrypting the data in every 6037 packet. When confidentiality is used it MUST be accompanied by 6038 data integrity and authentication to provide comprehensive 6039 protection against eavesdropping, message insertion, deletion, 6040 modification, and replaying. 6042 An iSCSI compliant initiator or target MUST provide 6043 confidentiality by implementing IPsec v2 [RFC2401] with ESPv2 6044 [RFC2406] in tunnel mode, SHOULD provide confidentiality by 6045 implementing IPsec v3 [RFC4301] with ESPv3 [RFC4303] in tunnel 6046 mode and MAY provide confidentiality by implementing either IPsec 6047 v2 or v3 with the appropriate version of ESP in transport mode, 6048 with the following iSCSI specific requirements that apply to IPsec 6049 v2 and IPsec v3: 6050 - 3DES in CBC mode MUST be implemented [RFC2451]. 6052 - AES in Counter mode SHOULD be implemented [RFC3686]. 6054 - Implementations that support IKEv2 [RFC5996] SHOULD also 6055 implement AES GCM [RFC4106] 6057 DES in CBC mode MUST NOT be used due to its inherent weakness. 6059 The NULL encryption algorithm MUST also be implemented. 6061 9.3.3. Policy, Security Associations, and Cryptographic Key 6062 Management 6064 A compliant iSCSI implementation MUST meet the cryptographic key 6065 management requirements of the IPsec protocol suite. 6066 Authentication, security association negotiation, and 6067 cryptographic key management MUST be provided by implementing IKE 6068 [RFC5996] using the IPsec DOI [RFC5996] with the following iSCSI 6069 specific requirements: 6071 - Peer authentication using a pre-shared cryptographic key 6072 MUST be supported. Certificate-based peer authentication 6073 using digital signatures MAY be supported. For IKEv1 6074 ([RFC2409]), peer authentication using the public key 6075 encryption methods outlined in IKE sections 5.2 and 5.3 of 6076 [RFC2409] SHOULD NOT be used. 6078 - When digital signatures are used to achieve authentication, 6079 an IKE negotiator SHOULD use IKE Certificate Request 6080 Payload(s) to specify the certificate authority. IKE 6081 negotiators SHOULD check the pertinent Certificate 6082 Revocation List (CRL) before accepting a PKI certificate for 6083 use in IKE authentication procedures. 6085 - Conformant iSCSI implementations of IKEv1 MUST support Main 6086 Mode and SHOULD support Aggressive Mode. Main Mode with pre- 6087 shared key authentication method SHOULD NOT be used when 6088 either the initiator or the target uses dynamically assigned 6090 addresses. While in many cases pre-shared keys offer good 6091 security, situations in which dynamically assigned addresses 6092 are used force the use of a group pre-shared key, which 6093 creates vulnerability to a man-in-the-middle attack. 6095 - In the IKEv1 Phase 2 Quick Mode, exchanges for creating the 6096 Phase 2 SA, the Identification Payload MUST be present. 6098 - The following identification type requirements apply to IKEv1. 6099 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports 6100 IPv6) and ID_FQDN Identification Types MUST be supported; 6101 ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address 6102 Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types 6103 SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT 6104 be used. 6106 - If IKEv2 is supported, the following identification requirements 6107 apply. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack 6108 supports IPv6) and ID_FQDN Identification Types MUST be 6109 supported; ID_RFC822_ADDR SHOULD be supported. The 6110 ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD 6111 NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. 6113 Manual cryptographic keying MUST NOT be used because it does not 6114 provide the necessary re-keying support. 6116 When DH groups are used, a DH group of at least 2048 bits SHOULD 6117 be offered as a part of all proposals to create IPsec Security 6118 Associations to protect iSCSI traffic. 6120 When IPsec is used, the receipt of an IKEv1 Phase 2 delete message 6121 or an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT 6122 be interpreted as a reason for tearing down the iSCSI TCP 6123 connection. If additional traffic is sent on it, a new IKE SA will 6124 be created to protect it. 6126 The method used by the initiator to determine whether the target 6127 should be connected using IPsec is regarded as an issue of IPsec 6128 policy administration, and thus not defined in the iSCSI standard. 6130 The method used by an initiator that supports both IPsec v2 and v3 6131 to determine which versions of IPsec are supported by the target 6132 is also regarded as an issue of IPsec policy administration, and 6133 thus not defined in the iSCSI standard. If both IPsec v2 and v3 6134 are supported by both the initiator and target, use of IPsec v3 is 6135 recommended. 6137 If an iSCSI target is discovered via a SendTargets request in a 6138 discovery session not using IPsec, the initiator should assume 6139 that it does not need IPsec to establish a session to that target. 6140 If an iSCSI target is discovered using a discovery session that 6141 does use IPsec, the initiator SHOULD use IPsec when establishing a 6142 session to that target. 6144 9.4. Security Considerations for the X#NodeArchitecture Key 6146 The security considerations in this section are specific to the 6147 X#NodeArchitecture discussed in Section 13.26 - 6148 "X#NodeArchitecture". 6150 This extension key transmits specific implementation details about 6151 the node that sends it; such details may be considered sensitive 6152 in some environments. For example, if a certain software or 6153 firmware version is known to contain security weaknesses, 6154 announcing the presence of that version via this key may not be 6155 desirable. The countermeasures for this security concern are: 6157 - sending less detailed information in the key values, 6158 - not sending the extension key, or 6159 - using IPsec ([RFC4303]) to provide confidentiality for 6160 the iSCSI connection on which the key is sent 6161 To support the first and second countermeasures, all 6162 implementations of this extension key MUST provide an 6163 administrative mechanism to disable sending the key. In addition, 6164 all implementations SHOULD provide an administrative mechanism to 6165 configure a verbosity level of the key value, thereby controlling 6166 the amount of information sent. 6168 For example, a lower verbosity might enable transmission of node 6169 architecture component names only, but no version numbers. The 6170 choice of which countermeasure is most appropriate depends on the 6171 environment. However, sending less detailed information in the key 6172 values may be an acceptable countermeasure in many environments, 6173 since it provides a compromise between sending too much 6174 information and the other more complete countermeasures of not 6175 sending the key at all or using IPsec. 6177 In addition to security considerations involving transmission of 6178 the key contents, any logging method(s) used for the key values 6179 MUST keep the information secure from intruders. For all 6180 implementations, the requirements to address this security concern 6181 are: 6183 - Display of the log MUST only be possible with administrative 6184 rights to the node. 6186 - Options to disable logging to disk and to keep logs for a 6187 fixed duration SHOULD be provided. 6189 Finally, it is important to note that different nodes may have 6190 different levels of risk, and these differences may affect the 6191 implementation. The components of risk include assets, threats, 6192 and vulnerabilities. Consider the following example iSCSI nodes, 6193 which demonstrate differences in assets and vulnerabilities of the 6194 nodes, and as a result, differences in implementation: 6196 One iSCSI target based on a special-purpose operating system: 6197 Since the iSCSI target controls access to the data storage 6198 containing company assets, the asset level is seen as very 6199 high. Also, because of the special-purpose operating 6200 system, in which vulnerabilities are less well-known, the 6201 vulnerability level is viewed as low. 6203 Multiple iSCSI initiators in a blade farm, each running a 6204 general purpose operating system: The asset level of each 6205 node is viewed as low, since blades are replaceable and low 6206 cost. However, the vulnerability level is viewed as high, 6207 since there may be many wellknown vulnerabilities to that 6208 general-purpose operating system. For this target, an 6209 appropriate implementation might be logging of received key 6210 values, but no transmission of the key. For this initiator, 6211 an appropriate implementation might be transmission of the 6212 key, but no logging of received key values. 6214 10. Notes to Implementers 6216 This section notes some of the performance and reliability 6217 considerations of the iSCSI protocol. This protocol was designed 6218 to allow efficient silicon and software implementations. The iSCSI 6219 task tag mechanism was designed to enable Direct Data Placement 6220 (DDP - a DMA form) at the iSCSI level or lower. 6222 The guiding assumption made throughout the design of this protocol 6223 is that targets are resource constrained relative to initiators. 6225 Implementers are also advised to consider the implementation 6226 consequences of the iSCSI to SCSI mapping model as outlined in 6227 Section 4.4.3 - "Consequences of the Model". 6229 10.1. Multiple Network Adapters 6231 The iSCSI protocol allows multiple connections, not all of which 6232 need to go over the same network adapter. If multiple network 6233 connections are to be utilized with hardware support, the iSCSI 6234 protocol command-data-status allegiance to one TCP connection 6235 ensures that there is no need to replicate information across 6236 network adapters or otherwise require them to cooperate. 6238 However, some task management commands may require some loose form 6239 of cooperation or replication at least on the target. 6241 10.1.1. Conservative Reuse of ISIDs 6243 Historically, the SCSI model (and implementations and applications 6244 based on that model) has assumed that SCSI ports are static, 6245 physical entities. Recent extensions to the SCSI model have taken 6246 advantage of persistent worldwide unique names for these ports. In 6247 iSCSI however, the SCSI initiator ports are the endpoints of 6248 dynamically created sessions, so the presumptions of "static and 6249 physical" do not apply. In any case, the model clauses 6250 (particularly, Section 4.4.1- "SCSI Architecture Model") provide 6251 for persistent, reusable names for the iSCSI-type SCSI initiator 6252 ports even though there does not need to be any physical entity 6253 bound to these names. 6255 To both minimize the disruption of legacy applications and to 6256 better facilitate the SCSI features that rely on persistent names 6257 for SCSI ports, iSCSI implementations SHOULD attempt to provide a 6258 stable presentation of SCSI Initiator Ports (both to the upper OS- 6259 layers and to the targets to which they connect). This can be 6260 achieved in an initiator implementation by conservatively reusing 6261 ISIDs. In other words, the same ISID should be used in the Login 6262 process to multiple target portal groups (of the same iSCSI Target 6263 or different iSCSI Targets). The ISID RULE (Section 4.4.3- 6264 "Consequences of the Model") only prohibits reuse to the same 6265 target portal group. It does not "preclude" reuse to other target 6266 portal groups. 6267 The principle of conservative reuse "encourages" reuse to other 6268 target portal groups. When a SCSI target device sees the same 6269 (InitiatorName, ISID) pair in different sessions to different 6270 target portal groups, it can identify the underlying SCSI 6271 Initiator Port on each session as the same SCSI port. In effect, 6272 it can recognize multiple paths from the same source. 6274 10.1.2. iSCSI Name, ISID, and TPGT Use 6276 The designers of the iSCSI protocol are aware that legacy SCSI 6277 transports rely on initiator identity to assign access to storage 6278 resources. Although newer techniques are available and simplify 6279 access control, support for configuration and authentication 6280 schemes that are based on initiator identity is deemed important 6281 in order to support legacy systems and administration software. 6282 iSCSI thus supports the notion that it should be possible to 6283 assign access to storage resources based on "initiator device" 6284 identity. 6286 When there are multiple hardware or software components 6287 coordinated as a single iSCSI Node, there must be some (logical) 6288 entity that represents the iSCSI Node that makes the iSCSI Node 6289 Name available to all components involved in session creation and 6290 login. Similarly, this entity that represents the iSCSI Node must 6291 be able to coordinate session identifier resources (ISID for 6292 initiators) to enforce both the ISID and TSIH RULES (see Section 6293 4.4.3- "Consequences of the Model"). 6295 For targets, because of the closed environment, implementation of 6296 this entity should be straightforward. However, vendors of iSCSI 6297 hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide 6298 mechanisms for configuration of the iSCSI Node Name across the 6299 portal groups instantiated by multiple instances of these 6300 components within a target. 6302 However, complex targets making use of multiple Target Portal 6303 Group Tags may reconfigure them to achieve various quality goals. 6304 The initiators have two mechanisms at their disposal to discover 6305 and/or check reconfiguring targets - the discovery session type 6306 and a key returned by the target during login to confirm the TPGT. 6307 An initiator should attempt to "rediscover" the target 6308 configuration anytime a session is terminated unexpectedly. 6310 For initiators, in the long term, it is expected that operating 6311 system vendors will take on the role of this entity and provide 6312 standard APIs that can inform components of their iSCSI Node Name 6313 and can configure and/or coordinate ISID allocation, use, and 6314 reuse. 6316 Recognizing that such initiator APIs are not available today, 6317 other implementations of the role of this entity are possible. For 6318 example, a human may instantiate the (common) Node name as part of 6319 the installation process of each iSCSI component involved in 6320 session creation and login. This may be done either by pointing 6321 the component to a vendor-specific location for this datum or to a 6322 system-wide location. The structure of the ISID namespace (see 6323 Section 11.12.5 - "ISID" and [RFC3721]) facilitates implementation 6324 of the ISID coordination by allowing each component vendor to 6325 independently (of other vendor's components) coordinate 6326 allocation, use, and reuse of its own partition of the ISID 6327 namespace in a vendor-specific manner. Partitioning of the ISID 6328 namespace within initiator portal groups managed by that vendor 6329 allows each such initiator portal group to act independently of 6330 all other portal groups when selecting an ISID for a login; this 6331 facilitates enforcement of the ISID RULE (see Section 4.4.3- 6332 "Consequences of the Model") at the initiator. 6334 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use 6335 in initiators MUST implement a mechanism for configuring the iSCSI 6336 Node Name. Vendors, and administrators must ensure that iSCSI Node 6337 Names are unique worldwide. It is therefore important that when 6338 one chooses to reuse the iSCSI Node Name of a disabled unit, not 6339 to re-assign that name to the original unit unless its worldwide 6340 uniqueness can be ascertained again. 6342 In addition, a vendor of iSCSI hardware must implement a mechanism 6343 to configure and/or coordinate ISIDs for all sessions managed by 6344 multiple instances of that hardware within a given iSCSI Node. 6345 Such configuration might be either permanently pre-assigned at the 6346 factory (in a necessarily globally unique way), statically 6347 assigned (e.g., partitioned across all the NICs at initialization 6348 in a locally unique way), or dynamically assigned (e.g., on-line 6349 allocator, also in a locally unique way). In the latter two cases, 6350 the configuration may be via public APIs (perhaps driven by an 6351 independent vendor's software, such as the OS vendor) or via 6352 private APIs driven by the vendor's own software. 6354 The process of name assignment and coordination has to be as 6355 encompassing and automated as possible as years of legacy usage 6356 have shown it to be highly error-prone. It is to be mentioned 6357 that SCSI has today alternative schemes of access control that can 6358 be used by all transports and their security is not dependent on 6359 strict naming coordination. 6361 10.2. Autosense and Auto Contingent Allegiance (ACA) 6363 Autosense refers to the automatic return of sense data to the 6364 initiator in case a command did not complete successfully. iSCSI 6365 initiators and targets MUST support and use autosense. 6367 ACA helps preserve ordered command execution in the presence of 6368 errors. As there can be many commands in-flight between an 6369 initiator and a target, SCSI initiator functionality in some 6370 operating systems depends on ACA to enforce ordered command 6371 execution during error recovery, and hence iSCSI initiator 6372 implementations for those operating systems need to support ACA. 6373 In order to support error recovery for these operating systems and 6374 iSCSI initiators, iSCSI targets SHOULD support ACA. 6376 10.3. iSCSI Timeouts 6378 iSCSI recovery actions are often dependent on iSCSI time-outs 6379 being recognized and acted upon before SCSI time-outs. Determining 6380 the right time-outs to use for various iSCSI actions (command 6381 acknowledgements expected, status acknowledgements, etc.) is very 6382 much dependent on infrastructure (hardware, links, TCP/IP stack, 6383 iSCSI driver). As a guide, the implementer may use an average Nop- 6384 Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 6385 4) as a good estimate for the basic delay of the iSCSI stack for a 6386 given connection. The safety factor should account for the network 6387 load variability. For connection teardown the implementer may 6388 want to consider also TCP common practice for the given 6389 infrastructure. 6391 Text negotiations MAY also be subject to either time-limits or 6392 limits in the number of exchanges. Those SHOULD be generous enough 6393 to avoid affecting interoperability (e.g., allowing each key to be 6394 negotiated on a separate exchange). 6396 The relation between iSCSI timeouts and SCSI timeouts should also 6397 be considered. SCSI timeouts should be longer than iSCSI timeouts 6398 plus the time required for iSCSI recovery whenever iSCSI recovery 6399 is planned. Alternatively, an implementer may choose to interlock 6400 iSCSI timeouts and recovery with SCSI timeouts so that SCSI 6401 recovery will become active only where iSCSI is not planned to, or 6402 failed to, recover. 6404 The implementer may also want to consider the interaction between 6405 various iSCSI exception events - such as a digest failure - and 6406 subsequent timeouts. When iSCSI error recovery is active, a digest 6407 failure is likely to result in discovering a missing command or 6408 data PDU. In these cases, an implementer may want to lower the 6409 timeout values to enable faster initiation for recovery 6410 procedures. 6412 10.4. Command Retry and Cleaning Old Command Instances 6414 To avoid having old, retried command instances appear in a valid 6415 command window after a command sequence number wrap around, the 6416 protocol requires (see Section 4.2.2.1- "Command Numbering and 6417 Acknowledging") that on every connection on which a retry has been 6418 issued, a non-immediate command be issued and acknowledged within 6419 a 2**31-1 commands interval from the CmdSN of the retried command. 6420 This requirement can be fulfilled by an implementation in several 6421 ways. 6423 The simplest technique to use is to send a (non-retry) non- 6424 immediate SCSI command (or a NOP if no SCSI command is available 6425 for a while) after every command retry on the connection on which 6426 the retry was attempted. As errors are deemed rare events, this 6427 technique is probably the most effective, as it does not involve 6428 additional checks at the initiator when issuing commands. 6430 10.5. Synch and Steering Layer and Performance 6432 While a synch and steering layer is optional, an initiator/target 6433 that does not have it working against a target/initiator that 6434 demands synch and steering may experience performance degradation 6435 caused by packet reordering and loss. Providing a synch and 6436 steering mechanism is recommended for all high-speed 6437 implementations. 6439 10.6. Considerations for State-dependent Devices and Long-lasting 6440 SCSI Operations 6442 Sequential access devices operate on the principle that the 6443 position of the device is based on the last command processed. As 6444 such, command processing order and knowledge of whether or not the 6445 previous command was processed is of the utmost importance to 6446 maintain data integrity. For example, inadvertent retries of SCSI 6447 commands when it is not known if the previous SCSI command was 6448 processed is a potential data integrity risk. 6450 For a sequential access device, consider the scenario in which a 6451 SCSI SPACE command to backspace one filemark is issued and then 6452 re-issued due to no status received for the command. If the first 6453 SPACE command was actually processed, the re-issued SPACE command, 6454 if processed, will cause the position to change. Thus, a 6455 subsequent write operation will write data to the wrong position 6456 and any previous data at that position will be overwritten. 6458 For a medium changer device, consider the scenario in which an 6459 EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION 6460 ADDRESS are the same thus performing a swap) is issued and then 6461 re-issued due to no status received for the command. If the first 6462 EXCHANGE MEDIUM command was actually processed, the re-issued 6463 EXCHANGE MEDIUM command, if processed, will perform the swap 6464 again. The net effect is no swap was performed thus leaving a data 6465 integrity exposure. 6467 All commands that change the state of the device (as in SPACE 6468 commands for sequential access devices, and EXCHANGE MEDIUM for 6469 medium changer device), MUST be issued as non-immediate commands 6470 for deterministic and in order delivery to iSCSI targets. 6472 For many of those state changing commands, the execution model 6473 also assumes that the command is executed exactly once. Devices 6474 implementing READ POSITION and LOCATE provide a means for SCSI 6475 level command recovery and new tape-class devices 6476 should support those commands. In their absence a retry at SCSI 6477 level is difficult and error recovery at iSCSI level is advisable. 6479 Devices operating on long latency delivery subsystems and 6480 performing long lasting SCSI operations may need mechanisms that 6481 enable connection replacement while commands are running (e.g., 6482 during an extended copy operation). 6484 10.6.1. Determining the Proper ErrorRecoveryLevel 6486 The implementation and use of a specific ErrorRecoveryLevel should 6487 be determined based on the deployment scenarios of a given iSCSI 6488 implementation. Generally, the following factors must be 6489 considered before deciding on the proper level of recovery: 6491 Application resilience to I/O failures. 6492 Required level of availability in the face of transport 6493 connection failures. 6494 Probability of transport layer "checksum escape". This in turn 6495 decides the iSCSI digest failure frequency, and thus the 6496 criticality of iSCSI-level error recovery. The details of 6497 estimating this probability are outside the scope of this 6498 document. 6500 A consideration of the above factors for SCSI tape devices as an 6501 example suggests that implementations SHOULD use 6502 ErrorRecoveryLevel=1 when transport connection failure is not a 6503 concern and SCSI level recovery is unavailable, and 6504 ErrorRecoveryLevel=2 when the connection failure is also of high 6505 likelihood during a backup/retrieval. 6507 For extended copy operations, implementations SHOULD use 6508 ErrorRecoveryLevel=2 whenever there is a relatively high 6509 likelihood of connection failure. 6511 10.7. Multi-task Abort Implementation Considerations 6513 Multi-task abort operations are typically issued in emergencies - 6514 such as clearing a device lock-up, HA failover/failback etc. In 6515 these circumstances, it is desirable to rapidly go through the 6516 error handling process as opposed to the target waiting on 6517 multiple third-party initiators who may not even be functional 6518 anymore - especially if this emergency is triggered because of one 6519 such initiator failure. Therefore, both iSCSI target and 6520 initiator implementations SHOULD support FastAbort multi-task 6521 abort semantics (Section 4.2.3.4). 6523 Note that both in standard semantics (Section 4.2.3.3) and 6524 FastAbort semantics (Section 4.2.3.4), there may be outstanding 6525 data transfers even after the TMF completion is reported on the 6526 issuing session. In the case of iSCSI/iSER [iSER], these would be 6527 tagged data transfers for STags not owned by any active tasks. 6528 Whether or not real buffers support these data transfers is 6529 implementation-dependent. However, the data transfers logically 6530 MUST be silently discarded by the target iSCSI layer in all cases. 6531 A target MAY, on an implementation-defined internal timeout, also 6532 choose to drop the connections on which it did not receive the 6533 expected Data-Out sequences (Section 4.2.3.3) or NOP-Out 6534 acknowledgements (Section 4.2.3.4) so as to reclaim the associated 6535 buffer, STag, and TTT resources as appropriate. 6537 11. iSCSI PDU Formats 6539 All multi-byte integers that are specified in formats defined in 6540 this document are to be represented in network byte order (i.e., 6541 big endian). Any field that appears in this document assumes that 6542 the most significant byte is the lowest numbered byte and the most 6543 significant bit (within byte or field) is the lowest numbered bit 6544 unless specified otherwise. 6546 Any compliant sender MUST set all bits not defined and all 6547 reserved fields to zero unless specified otherwise. Any compliant 6548 receiver MUST ignore any bit not defined and all reserved fields 6549 unless specified otherwise. Receipt of reserved code values in 6550 defined fields MUST be reported as a protocol error. 6552 Reserved fields are marked by the word "reserved", some 6553 abbreviation of "reserved", or by "." for individual bits when no 6554 other form of marking is technically feasible. 6556 11.1. iSCSI PDU Length and Padding 6558 iSCSI PDUs are padded to the closest integer number of four byte 6559 words. The padding bytes SHOULD be sent as 0. 6561 11.2. PDU Template, Header, and Opcodes 6563 All iSCSI PDUs have one or more header segments and, optionally, a 6564 data segment. After the entire header segment group a header- 6565 digest MAY follow. The data segment MAY also be followed by a 6566 data-digest. 6568 The Basic Header Segment (BHS) is the first segment in all of the 6569 iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It 6570 MAY be followed by Additional Header Segments (AHS), a Header- 6571 Digest, a Data Segment, and/or a Data-Digest. 6573 The overall structure of an iSCSI PDU is as follows: 6575 Byte/ 0 | 1 | 2 | 3 | 6576 / | | | | 6577 |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| 6578 +---------------+---------------+---------------+--------------+ 6579 0/ Basic Header Segment (BHS) / 6580 +/ / 6581 +---------------+---------------+---------------+--------------+ 6582 48/ Additional Header Segment 1 (AHS) (optional) / 6583 +/ / 6584 +---------------+---------------+---------------+--------------+ 6585 / Additional Header Segment 2 (AHS) (optional) / 6586 +/ / 6587 +---------------+---------------+---------------+--------------+ 6588 ---- 6589 +---------------+---------------+---------------+--------------+ 6590 / Additional Header Segment n (AHS) (optional) / 6591 +/ / 6592 +---------------+---------------+---------------+--------------+ 6593 ---- 6594 +---------------+---------------+---------------+--------------+ 6595 k/ Header-Digest (optional) / 6596 +/ / 6597 +---------------+---------------+---------------+--------------+ 6598 l/ Data Segment(optional) / 6599 +/ / 6600 +---------------+---------------+---------------+--------------+ 6601 m/ Data-Digest (optional) / 6602 +/ / 6603 +---------------+---------------+---------------+--------------+ 6605 All PDU segments and digests are padded to the closest integer 6606 number of four byte words. For example, all PDU segments and 6607 digests start at a four byte word boundary and the padding ranges 6608 from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. 6610 iSCSI response PDUs do not have AH Segments. 6612 11.2.1. Basic Header Segment (BHS) 6614 The BHS is 48 bytes long. The Opcode and DataSegmentLength fields 6615 appear in all iSCSI PDUs. In addition, when used, the Initiator 6616 Task Tag and Logical Unit Number always appear in the same 6617 location in the header. 6619 The format of the BHS is: 6621 Byte/ 0 | 1 | 2 | 3 | 6622 / | | | | 6623 |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| 6624 +---------------+---------------+---------------+--------------+ 6625 0|.|I| Opcode |F| Opcode-specific fields | 6626 +---------------+---------------+---------------+--------------+ 6627 4|TotalAHSLength | DataSegmentLength | 6628 +---------------+---------------+---------------+--------------+ 6629 8| LUN or Opcode-specific fields | 6630 + + 6631 12| | 6632 +---------------+---------------+---------------+--------------+ 6633 16| Initiator Task Tag | 6634 +---------------+---------------+---------------+--------------+ 6635 20/ Opcode-specific fields / 6636 +/ / 6637 +---------------+---------------+---------------+--------------+ 6638 48 6640 11.2.1.1. I 6642 For request PDUs, the I bit set to 1 is an immediate delivery 6643 marker. 6645 11.2.1.2. Opcode 6647 The Opcode indicates the type of iSCSI PDU the header 6648 encapsulates. 6650 The Opcodes are divided into two categories: initiator opcodes and 6651 target opcodes. Initiator opcodes are in PDUs sent by the 6652 initiator (request PDUs). Target opcodes are in PDUs sent by the 6653 target (response PDUs). 6655 Initiators MUST NOT use target opcodes and targets MUST NOT use 6656 initiator opcodes. 6658 Initiator opcodes defined in this specification are: 6660 0x00 NOP-Out 6662 0x01 SCSI Command (encapsulates a SCSI Command Descriptor 6663 Block) 6665 0x02 SCSI Task Management function request 6667 0x03 Login Request 6669 0x04 Text Request 6671 0x05 SCSI Data-out (for WRITE operations) 6673 0x06 Logout Request 6675 0x10 SNACK Request 6677 0x1c-0x1e Vendor specific codes 6679 Target opcodes are: 6681 0x20 NOP-In 6683 0x21 SCSI Response - contains SCSI status and possibly sense 6684 information or other response information. 6686 0x22 SCSI Task Management function response 6688 0x23 Login Response 6690 0x24 Text Response 6692 0x25 SCSI Data-in - for READ operations. 6694 0x26 Logout Response 6695 0x31 Ready To Transfer (R2T) - sent by target when it is ready 6696 to receive data. 6698 0x32 Asynchronous Message - sent by target to indicate certain 6699 special conditions. 6701 0x3c-0x3e Vendor specific codes 6703 0x3f Reject 6705 All other opcodes are reserved. 6707 11.2.1.3. Final (F) bit 6709 When set to 1 it indicates the final (or only) PDU of a sequence. 6711 11.2.1.4. Opcode-specific Fields 6713 These fields have different meanings for different opcode types. 6715 11.2.1.5. TotalAHSLength 6717 Total length of all AHS header segments in units of four byte 6718 words including padding, if any. 6720 The TotalAHSLength is only used in PDUs that have an AHS and MUST 6721 be 0 in all other PDUs. 6723 11.2.1.6. DataSegmentLength 6725 This is the data segment payload length in bytes (excluding 6726 padding). The DataSegmentLength MUST be 0 whenever the PDU has no 6727 data segment. 6729 11.2.1.7. LUN 6731 Some opcodes operate on a specific Logical Unit. The Logical Unit 6732 Number (LUN) field identifies which Logical Unit. If the opcode 6733 does not relate to a Logical Unit, this field is either ignored or 6734 may be used in an opcode specific way. The LUN field is 64-bits 6735 and should be formatted in accordance with [SAM2]. For example, 6736 LUN[0] from [SAM2] is BHS byte 8 and so on up to LUN[7] from 6737 [SAM2], which is BHS byte 15. 6739 11.2.1.8. Initiator Task Tag 6741 The initiator assigns a Task Tag to each iSCSI task it issues. 6742 While a task exists, this tag MUST uniquely identify the task 6743 session-wide. SCSI may also use the initiator task tag as part of 6744 the SCSI task identifier when the timespan during which an iSCSI 6745 initiator task tag must be unique extends over the timespan during 6746 which a SCSI task tag must be unique. However, the iSCSI Initiator 6747 Task Tag must exist and be unique even for untagged SCSI commands. 6749 An ITT value of 0xffffffff is reserved and MUST NOT be assigned 6750 for a task by the initiator. The only instance in which it may be 6751 seen on the wire is in a target-initiated NOP-In PDU (Section 6752 11.19) and in the initiator response to that PDU, if necessary. 6754 11.2.2. Additional Header Segment (AHS) 6756 The general format of an AHS is: 6758 Byte/ 0 | 1 | 2 | 3 | 6759 / | | | | 6760 |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| 6761 +---------------+---------------+---------------+--------------+ 6762 0| AHSLength | AHSType | AHS-Specific | 6763 +---------------+---------------+---------------+--------------+ 6764 4/ AHS-Specific / 6765 +/ / 6766 +---------------+---------------+---------------+--------------+ 6767 x 6769 11.2.2.1. AHSType 6771 The AHSType field is coded as follows: 6773 bit 0-1 - Reserved 6775 bit 2-7 - AHS code 6777 0 - Reserved 6778 1 - Extended CDB 6780 2 - Expected Bidirectional Read Data Length 6782 3 - 63 Reserved 6784 11.2.2.2. AHSLength 6786 This field contains the effective length in bytes of the AHS 6787 excluding AHSType and AHSLength and padding, if any. The AHS is 6788 padded to the smallest integer number of 4 byte words (i.e., from 6789 0 up to 3 padding bytes). 6791 11.2.2.3. Extended CDB AHS 6793 The format of the Extended CDB AHS is: 6795 Byte/ 0 | 1 | 2 | 3 | 6796 / | | | | 6797 |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| 6798 +---------------+---------------+---------------+--------------+ 6799 0| AHSLength (CDBLength-15) | 0x01 | Reserved | 6800 +---------------+---------------+---------------+--------------+ 6801 4/ ExtendedCDB...+padding / 6802 +/ / 6803 +---------------+---------------+---------------+--------------+ 6804 x 6806 This type of AHS MUST NOT be used if the CDBLength is less than 6807 17. 6808 The length includes the reserved byte 3. 6810 11.2.2.4. Bidirectional Expected Read-Data Length AHS 6812 The format of the Bidirectional Read Expected Data Transfer Length 6813 AHS is: 6815 Byte/ 0 | 1 | 2 | 3 | 6816 / | | | | 6817 |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| 6818 +---------------+---------------+---------------+--------------+ 6819 0| AHSLength (0x0005) | 0x02 | Reserved | 6820 +---------------+---------------+---------------+--------------+ 6821 4| Expected Read-Data Length | 6822 +---------------+---------------+---------------+--------------+ 6823 8 6825 11.2.3. Header Digest and Data Digest 6827 Optional header and data digests protect the integrity of the 6828 header and data, respectively. The digests, if present, are 6829 located, respectively, after the header and PDU-specific data, and 6830 cover respectively the header and the PDU data, each including 6831 the padding bytes, if any. 6833 The existence and type of digests are negotiated during the Login 6834 Phase. 6836 The separation of the header and data digests is useful in iSCSI 6837 routing applications, in which only the header changes when a 6838 message is forwarded. In this case, only the header digest should 6839 be recalculated. 6841 Digests are not included in data or header length fields. 6843 A zero-length Data Segment also implies a zero-length data-digest. 6845 11.2.4. Data Segment 6847 The (optional) Data Segment contains PDU associated data. Its 6848 payload effective length is provided in the BHS field - 6849 DataSegmentLength. The Data Segment is also padded to an integer 6850 number of 4 byte words. 6852 11.3. SCSI Command 6854 The format of the SCSI Command PDU is: 6856 Byte/ 0 | 1 | 2 | 3 | 6857 / | | | | 6858 |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| 6859 +---------------+---------------+---------------+--------------+ 6860 0|.|I| 0x01 |F|R|W|. .|ATTR | Reserved | 6861 +---------------+---------------+---------------+--------------+ 6862 4|TotalAHSLength | DataSegmentLength | 6863 +---------------+---------------+---------------+--------------+ 6864 8| Logical Unit Number (LUN) | 6865 + + 6866 12| | 6867 +---------------+---------------+---------------+--------------+ 6868 16| Initiator Task Tag | 6869 +---------------+---------------+---------------+--------------+ 6870 20| Expected Data Transfer Length | 6871 +---------------+---------------+---------------+--------------+ 6872 24| CmdSN | 6873 +---------------+---------------+---------------+--------------+ 6874 28| ExpStatSN | 6875 +---------------+---------------+---------------+--------------+ 6876 32/ SCSI Command Descriptor Block (CDB) / 6877 +/ / 6878 +---------------+---------------+---------------+--------------+ 6879 48/ AHS (Optional) / 6880 +---------------+---------------+---------------+--------------+ 6881 x/ Header Digest (Optional) / 6882 +---------------+---------------+---------------+--------------+ 6883 y/ (DataSegment, Command Data) (Optional) / 6884 +/ / 6885 +---------------+---------------+---------------+--------------+ 6886 z/ Data Digest (Optional) / 6887 +---------------+---------------+---------------+--------------+ 6889 11.3.1. Flags and Task Attributes (byte 1) 6891 The flags for a SCSI Command are: 6893 bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs 6894 follow this PDU. When F=1 for a write and if Expected Data 6895 Transfer Length is larger than the DataSegmentLength, the 6896 target may solicit additional data through R2T. 6898 bit 1 (R) is set to 1 when the command is expected to input 6899 data. 6901 bit 2 (W) is set to 1 when the command is expected to output 6902 data. 6904 bit 3-4 Reserved. 6906 bit 5-7 contains Task Attributes. 6908 Task Attributes (ATTR) have one of the following integer values 6909 (see [SAM2] for details): 6911 0 - Untagged 6913 1 - Simple 6915 2 - Ordered 6917 3 - Head of Queue 6919 4 - ACA 6921 5-7 - Reserved 6923 Setting both the W and the F bit to 0 is an error. 6924 Either or both of R and W MAY be 1 when either the Expected Data 6925 Transfer Length and/or Bidirectional Read Expected Data Transfer 6926 Length are 0, but they MUST NOT both be 0 when the Expected Data 6927 Transfer Length and/or Bidirectional Read Expected Data Transfer 6928 Length are not 0 (i.e., when some data transfer is expected the 6929 transfer direction is indicated by the R and/or W bit). 6931 11.3.2. CmdSN - Command Sequence Number 6933 Enables ordered delivery across multiple connections in a single 6934 session. 6936 11.3.3. ExpStatSN 6938 Command responses up to ExpStatSN-1 (mod 2**32) have been received 6939 (acknowledges status) on the connection. 6941 11.3.4. Expected Data Transfer Length 6943 For unidirectional operations, the Expected Data Transfer Length 6944 field contains the number of bytes of data involved in this SCSI 6945 operation. For a unidirectional write operation (W flag set to 1 6946 and R flag set to 0), the initiator uses this field to specify the 6947 number of bytes of data it expects to transfer for this operation. 6948 For a unidirectional read operation (W flag set to 0 and R flag 6949 set to 1), the initiator uses this field to specify the number of 6950 bytes of data it expects the target to transfer to the initiator. 6951 It corresponds to the SAM2 byte count. 6953 For bidirectional operations (both R and W flags are set to 1), 6954 this field contains the number of data bytes involved in the write 6955 transfer. For bidirectional operations, an additional header 6956 segment MUST be present in the header sequence that indicates the 6957 Bidirectional Read Expected Data Transfer Length. The Expected 6958 Data Transfer Length field and the Bidirectional Read Expected 6959 Data Transfer Length field correspond to the SAM2 byte count. 6961 If the Expected Data Transfer Length for a write and the length of 6962 the immediate data part that follows the command (if any) are the 6963 same, then no more data PDUs are expected to follow. In this 6964 case, the F bit MUST be set to 1. 6966 If the Expected Data Transfer Length is higher than the 6967 FirstBurstLength (the negotiated maximum amount of unsolicited 6968 data the target will accept), the initiator MUST send the maximum 6969 amount of unsolicited data OR ONLY the immediate data, if any. 6971 Upon completion of a data transfer, the target informs the 6972 initiator (through residual counts) of how many bytes were 6973 actually processed (sent and/or received) by the target. 6975 11.3.5. CDB - SCSI Command Descriptor Block 6977 There are 16 bytes in the CDB field to accommodate the commonly 6978 used CDBs. Whenever the CDB is larger than 16 bytes, an Extended 6979 CDB AHS MUST be used to contain the CDB spillover. 6981 11.3.6. Data Segment - Command Data 6983 Some SCSI commands require additional parameter data to accompany 6984 the SCSI command. This data may be placed beyond the boundary of 6985 the iSCSI header in a data segment. Alternatively, user data 6986 (e.g., from a WRITE operation) can be placed in the data segment 6987 (both cases are referred to as immediate data). These data are 6988 governed by the rules for solicited vs. unsolicited data outlined 6989 in Section 4.2.5.2 - "Data Transfer Overview". 6991 11.4. SCSI Response 6993 The format of the SCSI Response PDU is: 6995 Byte/ 0 | 1 | 2 | 3 | 6996 / | | | | 6997 |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| 6998 +---------------+---------------+---------------+--------------+ 6999 0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status | 7000 +---------------+---------------+---------------+--------------+ 7001 4|TotalAHSLength | DataSegmentLength | 7002 +---------------+---------------+---------------+--------------+ 7003 8| Reserved | 7004 + + 7005 12| | 7006 +---------------+---------------+---------------+--------------+ 7007 16| Initiator Task Tag | 7008 +---------------+---------------+---------------+--------------+ 7009 20| SNACK Tag or Reserved | 7010 +---------------+---------------+---------------+--------------+ 7011 24| StatSN | 7012 +---------------+---------------+---------------+--------------+ 7013 28| ExpCmdSN | 7014 +---------------+---------------+---------------+--------------+ 7015 32| MaxCmdSN | 7016 +---------------+---------------+---------------+--------------+ 7017 36| ExpDataSN or Reserved | 7018 +---------------+---------------+---------------+--------------+ 7019 40| Bidirectional Read Residual Count or Reserved | 7020 +---------------+---------------+---------------+--------------+ 7021 44| Residual Count or Reserved | 7022 +---------------+---------------+---------------+--------------+ 7023 48| Header-Digest (Optional) | 7024 +---------------+---------------+---------------+--------------+ 7025 / Data Segment (Optional) / 7026 +/ / 7027 +---------------+---------------+---------------+--------------+ 7028 | Data-Digest (Optional) | 7029 +---------------+---------------+---------------+--------------+ 7031 11.4.1. Flags (byte 1) 7033 bit 1-2 Reserved. 7035 bit 3 - (o) set for Bidirectional Read Residual Overflow. In 7036 this case, the Bidirectional Read Residual Count indicates 7037 the number of bytes that were not transferred to the 7038 initiator because the initiator's Expected Bidirectional 7039 Read Data Transfer Length was not sufficient. 7041 bit 4 - (u) set for Bidirectional Read Residual Underflow. In 7042 this case, the Bidirectional Read Residual Count indicates 7043 the number of bytes that were not transferred to the 7044 initiator out of the number of bytes expected to be 7045 transferred. 7047 bit 5 - (O) set for Residual Overflow. In this case, the 7048 Residual Count indicates the number of bytes that were not 7049 transferred because the initiator's Expected Data Transfer 7050 Length was not sufficient. For a bidirectional operation, 7051 the Residual Count contains the residual for the write 7052 operation. 7054 bit 6 - (U) set for Residual Underflow. In this case, the 7055 Residual Count indicates the number of bytes that were not 7056 transferred out of the number of bytes that were expected to 7057 be transferred. For a bidirectional operation, the Residual 7058 Count contains the residual for the write operation. 7060 bit 7 - (0) Reserved. 7062 Bits O and U and bits o and u are mutually exclusive (i.e., having 7063 both o and u or O and U set to 1 is a protocol error). 7064 For a response other than "Command Completed at Target", bits 3-6 7065 MUST be 0. 7067 11.4.2. Status 7069 The Status field is used to report the SCSI status of the command 7070 (as specified in [SAM2]) and is only valid if the Response Code is 7071 Command Completed at target. 7073 Some of the status codes defined in [SAM2] are: 7075 0x00 GOOD 7076 0x02 CHECK CONDITION 7078 0x08 BUSY 7080 0x18 RESERVATION CONFLICT 7082 0x28 TASK SET FULL 7084 0x30 ACA ACTIVE 7086 0x40 TASK ABORTED 7088 See [SAM2] for the complete list and definitions. 7090 If a SCSI device error is detected while data from the initiator 7091 is still expected (the command PDU did not contain all the data 7092 and the target has not received a Data PDU with the final bit 7093 Set), the target MUST wait until it receives a Data PDU with the F 7094 bit set in the last expected sequence before sending the Response 7095 PDU. 7097 11.4.3. Response 7099 This field contains the iSCSI service response. 7101 iSCSI service response codes defined in this specification are: 7103 0x00 - Command Completed at Target 7105 0x01 - Target Failure 7107 0x80-0xff - Vendor specific 7109 All other response codes are reserved. 7111 The Response is used to report a Service Response. The mapping of 7112 the response code into a SCSI service response code value, if 7113 needed, is outside the scope of this document. However, in 7114 symbolic terms response value 0x00 maps to the SCSI service 7115 response (see [SAM2] and [SPC3]) of TASK COMPLETE or LINKED 7116 COMMAND COMPLETE. All other Response values map to the SCSI 7117 service response of SERVICE DELIVERY OR TARGET FAILURE. 7119 If a SCSI Response PDU does not arrive before the session is 7120 terminated, the SCSI service response is SERVICE DELIVERY OR 7121 TARGET FAILURE. 7123 A non-zero response field indicates a failure to execute the 7124 command in which case the Status and Flag fields are undefined. 7126 11.4.4. SNACK Tag 7128 This field contains a copy of the SNACK Tag of the last SNACK Tag 7129 accepted by the target on the same connection and for the command 7130 for which the response is issued. Otherwise it is reserved and 7131 should be set to 0. 7133 After issuing a R-Data SNACK the initiator must discard any SCSI 7134 status unless contained in an SCSI Response PDU carrying the same 7135 SNACK Tag as the last issued R-Data SNACK for the SCSI command on 7136 the current connection. 7138 For a detailed discussion on R-Data SNACK see SNACK. 7140 11.4.5. Residual Count 7142 11.4.5.1. Field Semantics 7144 The Residual Count field MUST be valid in the case where either 7145 the U bit or the O bit is set. If neither bit is set, the Residual 7146 Count field is reserved. Targets may set the residual count and 7147 initiators may use it when the response code is "completed at 7148 target" (even if the status returned is not GOOD). If the O bit is 7149 set, the Residual Count indicates the number of bytes that were 7150 not transferred because the initiator's Expected Data Transfer 7151 Length was not sufficient. If the U bit is set, the Residual Count 7152 indicates the number of bytes that were not transferred out of the 7153 number of bytes expected to be transferred. 7155 11.4.5.2. Residuals Concepts Overview 7157 SCSI-Presented Data Transfer Length (SPDTL) is the term this 7158 document uses (see Section 2.1for definition) to represent the 7159 aggregate data length that the target SCSI layer attempts to 7160 transfer using the local iSCSI layer for a task. Expected Data 7161 Transfer Length (EDTL) is the iSCSI term that represents the 7162 length of data that the iSCSI layer expects to transfer for a 7163 task. EDTL is specified in the SCSI Command PDU. 7165 When SPDTL = EDTL for a task, the target iSCSI layer completes the 7166 task with no residuals. Whenever SPDTL differs from EDTL for a 7167 task, that task is said to have a residual. 7169 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the 7170 SCSI Response PDU as specified in Section 11.4.5.1. The Residual 7171 Count MUST be set to the numerical value of (SPDTL - EDTL). 7173 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 7174 the SCSI Response PDU as specified in Section 11.4.5.1. The 7175 Residual Count MUST be set to the numerical value of (EDTL - 7176 SPDTL). 7178 Note that the Overflow and Underflow scenarios are independent of 7179 Data-In and Data-Out. Either scenario is logically possible in 7180 either direction of data transfer. 7182 11.4.5.3. SCSI REPORT LUNS and Residual Overflow 7184 This section discusses the residual overflow issues citing the 7185 example of the SCSI REPORT LUNS command. Note however that there 7186 are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH 7187 fields following the same underlying rules. The semantics in the 7188 rest of the section apply to all such SCSI commands. 7190 The specification of the SCSI REPORT LUNS command requires that 7191 the SCSI target limit the amount of data transferred to a maximum 7192 size (ALLOCATION LENGTH) provided by the initiator in the REPORT 7193 LUNS CDB. 7195 If the Expected Data Transfer Length (EDTL) in the iSCSI header of 7196 the SCSI Command PDU for a REPORT LUNS command is set to at least 7197 as large as that ALLOCATION LENGTH, the SCSI layer truncation 7198 prevents an iSCSI Residual Overflow from occurring. A SCSI 7199 initiator can detect that such truncation has occurred via other 7200 information at theS CSI layer. The rest of the section elaborates 7201 this required behavior. 7203 The SCSI REPORT LUNS command requests a target SCSI layer to 7204 return a logical unit inventory (LUN list) to the initiator SCSI 7205 layer (see Section 6.21 of [SPC3]). The size of this LUN list may 7206 not be known to the initiator SCSI layer when it issues the REPORT 7207 LUNS command; to avoid transferring more LUN list data than the 7208 initiator is prepared for, the REPORT LUNS CDB contains an 7209 ALLOCATION LENGTH field to specify the maximum amount of data to 7210 be transferred to the initiator for this command. If the initiator 7211 SCSI layer has underestimated the number of logical units at the 7212 target, it is possible that the complete logical unit inventory 7213 does not fit in the specified ALLOCATION LENGTH. In this 7214 situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI 7215 layer "shall terminate transfers to the Data-In Buffer" when the 7216 number of bytes specified by the ALLOCATION LENGTH field have been 7217 transferred. 7219 Therefore, in response to a REPORT LUNS command, the SCSI layer at 7220 the target presents at most ALLOCATION LENGTH bytes of data 7221 (logical unit inventory) to iSCSI for transfer to the initiator. 7222 For a REPORT LUNS command, if the iSCSI EDTL is at least as large 7223 as the ALLOCATION LENGTH, the SCSI truncation ensures that the 7224 EDTL will accommodate all of the data to be transferred. If all of 7225 the logical unit inventory data presented to the iSCSI layer -- 7226 i.e., the data remaining after any SCSI truncation -- is 7227 transferred to the initiator by the iSCSI layer, an iSCSI Residual 7228 Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in 7229 the SCSI Response or final SCSI Data-Out PDU. Note that this 7230 behavior is implied by the combination of Section 11.4.5.1 along 7231 with the specification of the REPORT LUNS command in [SPC3]. 7232 However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in 7233 this scenario, note that the iSCSI Underflow MUST be signaled in 7234 the SCSI Response PDU. An iSCSI Underflow MUST also be signaled 7235 when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the 7236 logical unit inventory data presented to the iSCSI layer is 7237 smaller than the ALLOCATION LENGTH. 7239 The LUN LIST LENGTH field in the logical unit inventory (the first 7240 field in the inventory) is not affected by truncation of the 7241 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 7242 initiator to determine that the received inventory is incomplete 7243 by noticing that the LUN LIST LENGTH in the inventory is larger 7244 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A 7245 common initiator behavior in this situation is to re-issue the 7246 REPORT LUNS command with a larger ALLOCATION LENGTH. 7248 11.4.6. Bidirectional Read Residual Count 7250 The Bidirectional Read Residual Count field MUST be valid in the 7251 case where either the u bit or the o bit is set. If neither bit is 7252 set, the Bidirectional Read Residual Count field is reserved. 7253 Targets may set the Bidirectional Read Residual Count and 7254 initiators may use it when the response code is "completed at 7255 target". If the o bit is set, the Bidirectional Read Residual 7256 Count indicates the number of bytes that were not transferred to 7257 the initiator because the initiator's Expected Bidirectional Read 7258 Transfer Length was not sufficient. If the u bit is set, the 7259 Bidirectional Read Residual Count indicates the number of bytes 7260 that were not transferred to the initiator out of the number of 7261 bytes expected to be transferred. 7263 11.4.7. Data Segment - Sense and Response Data Segment 7265 iSCSI targets MUST support and enable autosense. If Status is 7266 CHECK CONDITION (0x02), then the Data Segment MUST contain sense 7267 data for the failed command. 7269 For some iSCSI responses, the response data segment MAY contain 7270 some response related information, (e.g., for a target failure, it 7271 may contain a vendor specific detailed description of the 7272 failure). 7274 If the DataSegmentLength is not 0, the format of the Data Segment 7275 is as follows: 7277 Byte/ 0 | 1 | 2 | 3 | 7278 / | | | | 7279 |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| 7280 +---------------+---------------+---------------+--------------+ 7281 0|SenseLength | Sense Data | 7282 +---------------+---------------+---------------+--------------+ 7283 x/ Sense Data / 7284 +---------------+---------------+---------------+--------------+ 7285 y/ Response Data / 7286 / / 7287 +---------------+---------------+---------------+--------------+ 7288 z| 7289 11.4.7.1. SenseLength 7291 Length of Sense Data. 7293 11.4.7.2. Sense Data 7295 The Sense Data contains detailed information about a check 7296 condition and [SPC3] specifies the format and content of the Sense 7297 Data. 7299 Certain iSCSI conditions result in the command being terminated at 7300 the target (response Command Completed at Target) with a SCSI 7301 Check Condition Status as outlined in the next table: 7303 +--------------------------+----------+--------------------------+ 7304 | iSCSI Condition |Sense | Additional Sense Code & | 7305 | |Key | Qualifier | 7306 +--------------------------+----------+--------------------------+ 7307 | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c | 7308 | data |Command-0B| Write Error | 7309 +--------------------------+----------+--------------------------+ 7310 | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d | 7311 | |Command-0B| Write Error | 7312 +--------------------------+----------+--------------------------+ 7313 | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 | 7314 | error |Command-0B| CRC Error Detected | 7315 +--------------------------+----------+--------------------------+ 7316 | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 | 7317 | |Command-0B| Read Error | 7318 +--------------------------+----------+--------------------------+ 7320 The target reports the "Incorrect amount of data" condition if 7321 during data output the total data length to output is greater than 7322 FirstBurstLength and the initiator sent unsolicited non-immediate 7323 data but the total amount of unsolicited data is different than 7324 FirstBurstLength. The target reports the same error when the 7325 amount of data sent as a reply to an R2T does not match the amount 7326 requested. 7328 11.4.8. ExpDataSN 7330 The number of Data-In (read) PDUs the target has sent for the 7331 command. 7333 This field MUST be 0 if the response code is not Command Completed 7334 at Target or the target sent no Data-In PDUs for the command. 7335 11.4.9. StatSN - Status Sequence Number 7337 StatSN is a Sequence Number that the target iSCSI layer generates 7338 per connection and that in turn, enables the initiator to 7339 acknowledge status reception. StatSN is incremented by 1 for every 7340 response/status sent on a connection except for responses sent as 7341 a result of a retry or SNACK. In the case of responses sent due to 7342 a retransmission request, the StatSN MUST be the same as the first 7343 time the PDU was sent unless the connection has since been 7344 restarted. 7346 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator 7348 ExpCmdSN is a Sequence Number that the target iSCSI returns to the 7349 initiator to acknowledge command reception. It is used to update a 7350 local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1 7351 indicates that the target cannot accept new commands. 7353 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 7355 MaxCmdSN is a Sequence Number that the target iSCSI returns to the 7356 initiator to indicate the maximum CmdSN the initiator can send. It 7357 is used to update a local variable with the same name. If MaxCmdSN 7358 is equal to ExpCmdSN-1, this indicates to the initiator that the 7359 target cannot receive any additional commands. When MaxCmdSN 7360 changes at the target while the target has no pending PDUs to 7361 convey this information to the initiator, it MUST generate a NOP- 7362 IN to carry the new MaxCmdSN. 7364 11.5. Task Management Function Request 7366 Byte/ 0 | 1 | 2 | 3 | 7367 / | | | | 7368 |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| 7369 +---------------+---------------+---------------+--------------+ 7370 0|.|I| 0x02 |1| Function | Reserved | 7371 +---------------+---------------+---------------+--------------+ 7372 4|TotalAHSLength | DataSegmentLength | 7373 +---------------+---------------+---------------+--------------+ 7374 8| Logical Unit Number (LUN) or Reserved | 7375 + + 7376 12| | 7377 +---------------+---------------+---------------+--------------+ 7378 16| Initiator Task Tag | 7379 +---------------+---------------+---------------+--------------+ 7380 20| Referenced Task Tag or 0xffffffff | 7381 +---------------+---------------+---------------+--------------+ 7382 24| CmdSN | 7383 +---------------+---------------+---------------+--------------+ 7384 28| ExpStatSN | 7385 +---------------+---------------+---------------+--------------+ 7386 32| RefCmdSN or Reserved | 7387 +---------------+---------------+---------------+--------------+ 7388 36| ExpDataSN or Reserved | 7389 +---------------+---------------+---------------+--------------+ 7390 40/ Reserved / 7391 +/ / 7392 +---------------+---------------+---------------+--------------+ 7393 48| Header-Digest (Optional) | 7394 +---------------+---------------+---------------+--------------+ 7396 11.5.1. Function 7398 The Task Management functions provide an initiator with a way to 7399 explicitly control the execution of one or more Tasks (SCSI and 7400 iSCSI tasks). The Task Management function codes are listed below. 7401 For a more detailed description of SCSI task management, see 7402 [SAM2]. 7404 1 - ABORT TASK - aborts the task identified by the 7405 Referenced Task Tag field. 7407 2 - ABORT TASK SET - aborts all Tasks issued via this 7408 session on the logical unit. 7410 3 - CLEAR ACA - clears the Auto Contingent Allegiance 7411 condition. 7413 4 - CLEAR TASK SET - aborts all Tasks in the appropriate 7414 task set as defined by the TST field in the Control mode 7415 page (see [SPC3]). 7417 5 - LOGICAL UNIT RESET 7419 6 - TARGET WARM RESET 7421 7 - TARGET COLD RESET 7423 8 - TASK REASSIGN - reassigns connection allegiance for the 7424 task identified by the Initiator Task Tag field to this 7425 connection, thus resuming the iSCSI exchanges for the task. 7427 For all these functions, the Task Management function response 7428 MUST be returned as detailed in Section 11.6. All these functions 7429 apply to the referenced tasks regardless of whether they are 7430 proper SCSI tasks or tagged iSCSI operations. Task management 7431 requests must act on all the commands from the same session having 7432 a CmdSN lower than the task management CmdSN. LOGICAL UNIT RESET, 7433 TARGET WARM RESET and TARGET COLD RESET may affect commands from 7434 other sessions or commands from the same session regardless of 7435 their CmdSN value. 7437 If the task management request is marked for immediate delivery, 7438 it must be considered immediately for execution, but the 7439 operations involved (all or part of them) may be postponed to 7440 allow the target to receive all relevant tasks. According to 7441 [SAM2], for all the tasks covered by the Task Management response 7442 (i.e., with CmdSN lower than the task management command CmdSN) 7443 but except the Task Management response to a TASK REASSIGN, 7444 additional responses MUST NOT be delivered to the SCSI layer after 7445 the Task Management response. The iSCSI initiator MAY deliver to 7446 the SCSI layer all responses received before the Task Management 7447 response (i.e., it is a matter of implementation if the SCSI 7448 responses, received before the Task Management response but after 7449 the task management request was issued, are delivered to the SCSI 7450 layer by the iSCSI layer in the initiator). The iSCSI target MUST 7451 ensure that no responses for the tasks covered by a task 7452 management function are delivered to the iSCSI initiator after the 7453 Task Management response except for a task covered by a TASK 7454 REASSIGN. 7456 For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST 7457 continue to respond to all valid target transfer tags (received 7458 via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to 7459 the affected task set, even after issuing the task management 7460 request. The issuing initiator SHOULD however terminate (i.e., by 7461 setting the F-bit to 1) these response sequences as quickly as 7462 possible. The target on its part MUST wait for responses on all 7463 affected target transfer tags before acting on either of these two 7464 task management requests. In case all or part of the response 7465 sequence is not received (due to digest errors) for a valid TTT, 7466 the target MAY treat it as a case of within-command error recovery 7467 class (see Section 7.1.4.1 - "Recovery Within-command") if it is 7468 supporting ErrorRecoveryLevel >= 1, or alternatively may drop the 7469 connection to complete the requested task set function. 7471 If an ABORT TASK is issued for a task created by an immediate 7472 command then RefCmdSN MUST be that of the Task Management request 7473 itself (i.e. CmdSN and RefCmdSN are equal); otherwise RefCmdSN 7474 MUST be set to the CmdSN of the task to be aborted (lower than 7475 CmdSN). 7477 If the connection is still active (it is not undergoing an 7478 implicit or explicit logout), ABORT TASK MUST be issued on the 7479 same connection to which the task to be aborted is allegiant at 7480 the time the Task Management Request is issued. If the connection 7481 is implicitly or explicitly logged out (i.e., no other request 7482 will be issued on the failing connection and no other response 7483 will be received on the failing connection), then an ABORT TASK 7484 function request may be issued on another connection. This Task 7485 Management request will then establish a new allegiance for the 7486 command to be aborted as well as abort it (i.e., the task to be 7487 aborted will not have to be retried or reassigned, and its status, 7488 if sent but not acknowledged, will be resent followed by the Task 7489 Management response). 7491 At the target an ABORT TASK function MUST NOT be executed on a 7492 Task Management request; such a request MUST result in Task 7493 Management response of "Function rejected". 7495 For the LOGICAL UNIT RESET function, the target MUST behave as 7496 dictated by the Logical Unit Reset function in [SAM2]. 7498 The implementation of the TARGET WARM RESET function and the 7499 TARGET COLD RESET function is OPTIONAL and when implemented, 7500 should act as described below. The TARGET WARM RESET is also 7501 subject to SCSI access controls on the requesting initiator as 7502 defined in [SPC3]. When authorization fails at the target, the 7503 appropriate response as described in Targe MUST be returned by the 7504 target. The TARGET COLD RESET function is not subject to SCSI 7505 access controls, but its execution privileges may be managed by 7506 iSCSI mechanisms such as login authentication. 7508 When executing the TARGET WARM RESET and TARGET COLD RESET 7509 functions, the target cancels all pending operations on all 7510 Logical Units known by the issuing initiator. Both functions are 7511 equivalent to the Target Reset function specified by [SAM2]. They 7512 can affect many other initiators logged in with the servicing SCSI 7513 target port. 7515 The target MUST treat the TARGET COLD RESET function additionally 7516 as a power on event, thus terminating all of its TCP connections 7517 to all initiators (all sessions are terminated). For this reason, 7518 the Service Response (defined by [SAM2]) for this SCSI task 7519 management function may not be reliably delivered to the issuing 7520 initiator port. 7522 For the TASK REASSIGN function, the target should reassign the 7523 connection allegiance to this new connection (and thus resume 7524 iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received 7525 by the target after the connection on which the command was 7526 previously executing has been successfully logged-out. The Task 7527 Management response MUST be issued before the reassignment becomes 7528 effective. 7530 For additional usage semantics see Section 7.2- "Retry and 7531 Reassign in Recovery". 7533 At the target a TASK REASSIGN function request MUST NOT be 7534 executed to reassign the connection allegiance of a Task 7535 Management function request, an active text negotiation task, or a 7536 Logout task; such a request MUST result in Task Management 7537 response of "Function rejected". 7539 TASK REASSIGN MUST be issued as an immediate command. 7541 11.5.2. TotalAHSLength and DataSegmentLength 7543 For this PDU, TotalAHSLength and DataSegmentLength MUST be 0. 7545 11.5.3. LUN 7547 This field is required for functions that address a specific LU 7548 (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL 7549 UNIT RESET) and is reserved in all others. 7551 11.5.4. Referenced Task Tag 7553 The Initiator Task Tag of the task to be aborted for the ABORT 7554 TASK function or reassigned for the TASK REASSIGN function. For 7555 all the other functions this field MUST be set to the reserved 7556 value 0xffffffff. 7558 11.5.5. RefCmdSN 7560 If an ABORT TASK is issued for a task created by an immediate 7561 command then RefCmdSN MUST be that of the Task Management request 7562 itself (i.e. CmdSN and RefCmdSN are equal). 7564 For an ABORT TASK of a task created by non-immediate command 7565 RefCmdSN MUST be set to the CmdSN of the task identified by the 7566 Referenced Task Tag field. Targets must use this field as 7567 described in Res when the task identified by the Referenced Task 7568 Tag field is not with the target. 7570 Otherwise, this field is reserved. 7572 11.5.6. ExpDataSN 7574 For recovery purposes, the iSCSI target and initiator maintain a 7575 data acknowledgement reference number - the first input DataSN 7576 number unacknowledged by the initiator. When issuing a new 7577 command, this number is set to 0. If the function is TASK 7578 REASSIGN, which establishes a new connection allegiance for a 7579 previously issued Read or Bidirectional command, ExpDataSN will 7580 contain an updated data acknowledgement reference number or the 7581 value 0; the latter indicating that the data acknowledgement 7582 reference number is unchanged. The initiator MUST discard any data 7583 PDUs from the previous execution that it did not acknowledge and 7584 the target MUST transmit all Data-in PDUs (if any) starting with 7585 the data acknowledgement reference number. The number of 7586 retransmitted PDUs may or may not be the same as the original 7587 transmission depending on if there was a change in 7588 MaxRecvDataSegmentLength in the reassignment. The target MAY also 7589 send no more Data-In PDUs if all data has been acknowledged. 7591 The value of ExpDataSN MUST be 0 or higher than the DataSN of the 7592 last acknowledged Data-In PDU, but not larger than DataSN+1 of the 7593 last Data-IN PDU sent by the target. Any other value MUST be 7594 ignored by the target. 7596 For other functions this field is reserved. 7598 11.6. Task Management Function Response 7599 Byte/ 0 | 1 | 2 | 3 | 7600 / | | | | 7601 |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| 7602 +---------------+---------------+---------------+--------------+ 7603 0|.|.| 0x22 |1| Reserved | Response | Reserved | 7604 +---------------+---------------+---------------+--------------+ 7605 4|TotalAHSLength | DataSegmentLength | 7606 +--------------------------------------------------------------+ 7607 8/ Reserved / 7608 / / 7609 +---------------+---------------+---------------+--------------+ 7610 16| Initiator Task Tag | 7611 +---------------+---------------+---------------+--------------+ 7612 20| Reserved | 7613 +---------------+---------------+---------------+--------------+ 7614 24| StatSN | 7615 +---------------+---------------+---------------+--------------+ 7616 28| ExpCmdSN | 7617 +---------------+---------------+---------------+--------------+ 7618 32| MaxCmdSN | 7619 +---------------+---------------+---------------+--------------+ 7620 36/ Reserved / 7621 +/ / 7622 +---------------+---------------+---------------+--------------+ 7623 48| Header-Digest (Optional) | 7624 +---------------+---------------+---------------+--------------+ 7626 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR 7627 TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET 7628 and TASK REASSIGN, the target performs the requested Task 7629 Management function and sends a Task Management response back to 7630 the initiator. For TASK REASSIGN, the new connection allegiance 7631 MUST ONLY become effective at the target after the target issues 7632 the Task Management Response. 7634 11.6.1. Response 7636 The target provides a Response, which may take on the following 7637 values: 7639 0 - Function complete. 7640 1 - Task does not exist. 7642 2 - LUN does not exist. 7643 3 - Task still allegiant. 7644 4 - Task allegiance reassignment not supported. 7645 5 - Task management function not supported. 7646 6 - Function authorization failed. 7647 255 - Function rejected. 7649 All other values are reserved. 7651 For a discussion on usage of response codes 3 and 4, see Section 7652 7.2.2- "Allegiance Reassignment". 7654 For the TARGET COLD RESET and TARGET WARM RESET functions, the 7655 target cancels all pending operations across all Logical Units 7656 known to the issuing initiator. For the TARGET COLD RESET 7657 function, the target MUST then close all of its TCP connections to 7658 all initiators (terminates all sessions). 7660 The mapping of the response code into a SCSI service response code 7661 value, if needed, is outside the scope of this document. However, 7662 in symbolic terms Response values 0 and 1 map to the SCSI service 7663 response of FUNCTION COMPLETE. All other Response values map to 7664 the SCSI service response of FUNCTION REJECTED. If a Task 7665 Management function response PDU does not arrive before the 7666 session is terminated, the SCSI service response is SERVICE 7667 DELIVERY OR TARGET FAILURE. 7669 The response to ABORT TASK SET and CLEAR TASK SET MUST only be 7670 issued by the target after all of the commands affected have been 7671 received by the target, the corresponding task management 7672 functions have been executed by the SCSI target, and the delivery 7673 of all responses delivered until the task management function 7674 completion have been confirmed (acknowledged through ExpStatSN) by 7675 the initiator on all connections of this session. For the exact 7676 timeline of events, refer to Section 4.2.3.3 and Section 4.2.3.4. 7678 For the ABORT TASK function, 7680 If the Referenced Task Tag identifies a valid task leading to 7681 a successful termination, then targets must return the 7682 "Function complete" response. 7684 If the Referenced Task Tag does not identify an existing task, 7685 but if the CmdSN indicated by the RefCmdSN field in the 7686 Task Management function request is within the valid CmdSN 7687 window and less than the CmdSN of the Task Management 7688 function request itself, then targets must consider the 7689 CmdSN received and return the "Function complete" response. 7690 If the Referenced Task Tag does not identify an existing task 7691 and if the CmdSN indicated by the RefCmdSN field in the 7692 Task Management function request is outside the valid CmdSN 7693 window, then targets must return the "Task does not exist" 7694 response. 7696 For response semantics on function types that can potentially 7697 impact multiple active tasks on the target, see Section 4.2.3. 7699 11.6.2. TotalAHSLength and DataSegmentLength 7701 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7703 11.7. SCSI Data-out & SCSI Data-in 7705 The SCSI Data-out PDU for WRITE operations has the following 7706 format: 7708 Byte/ 0 | 1 | 2 | 3 | 7709 / | | | | 7710 |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| 7711 +---------------+---------------+---------------+--------------+ 7712 0|.|.| 0x05 |F| Reserved | 7713 +---------------+---------------+---------------+--------------+ 7714 4|TotalAHSLength | DataSegmentLength | 7715 +---------------+---------------+---------------+--------------+ 7716 8| LUN or Reserved | 7717 + + 7718 12| | 7719 +---------------+---------------+---------------+--------------+ 7720 16| Initiator Task Tag | 7721 +---------------+---------------+---------------+--------------+ 7722 20| Target Transfer Tag or 0xffffffff | 7723 +---------------+---------------+---------------+--------------+ 7724 24| Reserved | 7725 +---------------+---------------+---------------+--------------+ 7726 28| ExpStatSN | 7727 +---------------+---------------+---------------+--------------+ 7728 32| Reserved | 7729 +---------------+---------------+---------------+--------------+ 7730 36| DataSN | 7731 +---------------+---------------+---------------+--------------+ 7732 40| Buffer Offset | 7733 +---------------+---------------+---------------+--------------+ 7734 44| Reserved | 7735 +---------------+---------------+---------------+--------------+ 7736 48| Header-Digest (Optional) | 7737 +---------------+---------------+---------------+--------------+ 7738 / DataSegment / 7739 +/ / 7740 +---------------+---------------+---------------+--------------+ 7741 | Data-Digest (Optional) | 7742 +---------------+---------------+---------------+--------------+ 7744 The SCSI Data-in PDU for READ operations has the following 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|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd| 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| StatSN or Reserved | 7763 +---------------+---------------+---------------+--------------+ 7764 28| ExpCmdSN | 7765 +---------------+---------------+---------------+--------------+ 7766 32| MaxCmdSN | 7767 +---------------+---------------+---------------+--------------+ 7768 36| DataSN | 7769 +---------------+---------------+---------------+--------------+ 7770 40| Buffer Offset | 7771 +---------------+---------------+---------------+--------------+ 7772 44| Residual Count | 7773 +---------------+---------------+---------------+--------------+ 7774 48| Header-Digest (Optional) | 7775 +---------------+---------------+---------------+--------------+ 7776 / DataSegment / 7777 +/ / 7778 +---------------+---------------+---------------+--------------+ 7779 | Data-Digest (Optional) | 7780 +---------------+---------------+---------------+--------------+ 7782 Status can accompany the last Data-in PDU if the command did not 7783 end with an exception (i.e., the status is "good status" - GOOD, 7784 CONDITION MET or INTERMEDIATE CONDITION MET). The presence of 7785 status (and of a residual count) is signaled though the S flag 7786 bit. Although targets MAY choose to send even non-exception 7787 status in separate responses, initiators MUST support non- 7788 exception status in Data-In PDUs. 7790 11.7.1. F (Final) Bit 7792 For outgoing data, this bit is 1 for the last PDU of unsolicited 7793 data or the last PDU of a sequence that answers an R2T. 7795 For incoming data, this bit is 1 for the last input (read) data 7796 PDU of a sequence. Input can be split into several sequences, 7797 each having its own F bit. Splitting the data stream into 7798 sequences does not affect DataSN counting on Data-In PDUs. It MAY 7799 be used as a "change direction" indication for Bidirectional 7800 operations that need such a change. 7802 DataSegmentLength MUST NOT exceed MaxRecvDataSegmentLength for the 7803 direction it is sent and the total of all the DataSegmentLength of 7804 all PDUs in a sequence MUST NOT exceed MaxBurstLength (or 7805 FirstBurstLength for unsolicited data). However the number of 7806 individual PDUs in a sequence (or in total) may be higher than the 7807 MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength 7808 ratio (as PDUs may be limited in length by the sender 7809 capabilities). Using DataSegmentLength of 0 may increase beyond 7810 what is reasonable for the number of PDUs and should therefore be 7811 avoided. 7813 For Bidirectional operations, the F bit is 1 for both the end of 7814 the input sequences and the end of the output sequences. 7816 11.7.2. A (Acknowledge) bit 7818 For sessions with ErrorRecoveryLevel 1 or higher, the target sets 7819 this bit to 1 to indicate that it requests a positive 7820 acknowledgement from the initiator for the data received. The 7821 target should use the A bit moderately; it MAY only set the A bit 7822 to 1 once every MaxBurstLength bytes, or on the last Data-In PDU 7823 that concludes the entire requested read data transfer for the 7824 task from the target's perspective, and it MUST NOT do so more 7825 frequently. The target MUST NOT set to 1 the A bit for sessions 7826 with ErrorRecoveryLevel=0. The initiator MUST ignore the A bit set 7827 to 1 for sessions with ErrorRecoveryLevel=0. 7829 On receiving a Data-In PDU with the A bit set to 1 on a session 7830 with ErrorRecoveryLevel greater than 0, if there are no holes in 7831 the read data until that Data-In PDU, the initiator MUST issue a 7832 SNACK of type DataACK except when it is able to acknowledge the 7833 status for the task immediately via ExpStatSN on other outbound 7834 PDUs if the status for the task is also received. In the latter 7835 case (acknowledgement through ExpStatSN), sending a SNACK of type 7836 DataACK in response to the A bit is OPTIONAL, but if it is done, 7837 it must not be sent after the status acknowledgement through 7838 ExpStatSN. If the initiator has detected holes in the read data 7839 prior to that Data-In PDU, it MUST postpone issuing the SNACK of 7840 type DataACK until the holes are filled. An initiator also MUST 7841 NOT acknowledge the status for the task before those holes are 7842 filled. A status acknowledgement for a task that generated the 7843 Data-In PDUs is considered by the target as an implicit 7844 acknowledgement of the Data-In PDUs if such an acknowledgement was 7845 requested by the target. 7847 11.7.3. Flags (byte 1) 7849 The last SCSI Data packet sent from a target to an initiator for a 7850 SCSI command that completed successfully (with a status of GOOD, 7851 CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may 7852 also optionally contain the Status for the data transfer. In this 7853 case, Sense Data cannot be sent together with the Command Status. 7854 If the command is completed with an error, then the response and 7855 sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be 7856 sent in a SCSI Data packet). For Bidirectional commands, the 7857 status MUST be sent in a SCSI Response PDU. 7859 bit 2-4 - Reserved. 7861 bit 5-6 - used the same as in a SCSI Response. These bits are 7862 only valid when S is set to 1. For details see SNACK . 7864 bit 7 S (status)- set to indicate that the Command Status 7865 field contains status. If this bit is set to 1, the F bit 7866 MUST also be set to 1. 7868 The fields StatSN, Status, and Residual Count only have meaningful 7869 content if the S bit is set to 1 and their values are defined in 7870 SNACK . 7872 11.7.4. Target Transfer Tag and LUN 7874 On outgoing data, the Target Transfer Tag is provided to the 7875 target if the transfer is honoring an R2T. In this case, the 7876 Target Transfer Tag field is a replica of the Target Transfer Tag 7877 provided with the R2T. 7879 On incoming data, the Target Transfer Tag and LUN MUST be provided 7880 by the target if the A bit is set to 1; otherwise they are 7881 reserved. The Target Transfer Tag and LUN are copied by the 7882 initiator into the SNACK of type DataACK that it issues as a 7883 result of receiving a SCSI Data-in PDU with the A bit set to 1. 7885 The Target Transfer Tag values are not specified by this protocol 7886 except that the value 0xffffffff is reserved and means that the 7887 Target Transfer Tag is not supplied. If the Target Transfer Tag 7888 is provided, then the LUN field MUST hold a valid value and be 7889 consistent with whatever was specified with the command; 7890 otherwise, the LUN field is reserved. 7892 11.7.5. DataSN 7894 For input (read) or bidirectional Data-In PDUs, the DataSN is the 7895 input PDU number within the data transfer for the command 7896 identified by the Initiator Task Tag. 7898 R2T and Data-In PDUs, in the context of bidirectional commands, 7899 share the numbering sequence (see Section 4.2.2.4- "Data 7900 Sequencing"). 7902 For output (write) data PDUs, the DataSN is the Data-Out PDU 7903 number within the current output sequence. The current output 7904 sequence is either identified by the Initiator Task Tag (for 7905 unsolicited data) or is a data sequence generated for one R2T (for 7906 data solicited through R2T). 7908 11.7.6. Buffer Offset 7910 The Buffer Offset field contains the offset of this PDU payload 7911 data within the complete data transfer. The sum of the buffer 7913 offset and length should not exceed the expected transfer length 7914 for the command. 7916 The order of data PDUs within a sequence is determined by 7917 DataPDUInOrder. When set to Yes, it means that PDUs have to be in 7918 increasing Buffer Offset order and overlays are forbidden. 7920 The ordering between sequences is determined by 7921 DataSequenceInOrder. When set to Yes, it means that sequences have 7922 to be in increasing Buffer Offset order and overlays are 7923 forbidden. 7925 11.7.7. DataSegmentLength 7927 This is the data payload length of a SCSI Data-In or SCSI Data-Out 7928 PDU. The sending of 0 length data segments should be avoided, but 7929 initiators and targets MUST be able to properly receive 0 length 7930 data segments. 7932 The Data Segments of Data-in and Data-out PDUs SHOULD be filled to 7933 the integer number of 4 byte words (real payload) unless the F bit 7934 is set to 1. 7936 11.8. Ready To Transfer (R2T) 7938 Byte/ 0 | 1 | 2 | 3 | 7939 / | | | | 7940 |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| 7941 +---------------+---------------+---------------+--------------+ 7942 0|.|.| 0x31 |1| Reserved | 7943 +---------------+---------------+---------------+--------------+ 7944 4|TotalAHSLength | DataSegmentLength | 7945 +---------------+---------------+---------------+--------------+ 7946 8| LUN | 7947 + + 7948 12| | 7949 +---------------+---------------+---------------+--------------+ 7950 16| Initiator Task Tag | 7951 +---------------+---------------+---------------+--------------+ 7952 20| Target Transfer Tag | 7953 +---------------+---------------+---------------+--------------+ 7954 24| StatSN | 7955 +---------------+---------------+---------------+--------------+ 7956 28| ExpCmdSN | 7957 +---------------+---------------+---------------+--------------+ 7958 32| MaxCmdSN | 7959 +---------------+---------------+---------------+--------------+ 7960 36| R2TSN | 7961 +---------------+---------------+---------------+--------------+ 7962 40| Buffer Offset | 7963 +---------------+---------------+---------------+--------------+ 7964 44| Desired Data Transfer Length | 7965 +--------------------------------------------------------------+ 7966 48| Header-Digest (Optional) | 7967 +---------------+---------------+---------------+--------------+ 7969 When an initiator has submitted a SCSI Command with data that 7970 passes from the initiator to the target (WRITE), the target may 7971 specify which blocks of data it is ready to receive. The target 7972 may request that the data blocks be delivered in whichever order 7973 is convenient for the target at that particular instant. This 7974 information is passed from the target to the initiator in the 7975 Ready To Transfer (R2T) PDU. 7977 In order to allow write operations without an explicit initial 7978 R2T, the initiator and target MUST have negotiated the key 7979 InitialR2T to No during Login. 7981 An R2T MAY be answered with one or more SCSI Data-out PDUs with a 7982 matching Target Transfer Tag. If an R2T is answered with a single 7983 Data-out PDU, the Buffer Offset in the Data PDU MUST be the same 7984 as the one specified by the R2T, and the data length of the Data 7985 PDU MUST be the same as the Desired Data Transfer Length specified 7986 in the R2T. If the R2T is answered with a sequence of Data PDUs, 7987 the Buffer Offset and Length MUST be within the range of those 7988 specified by R2T, and the last PDU MUST have the F bit set to 1. 7989 If the last PDU (marked with the F bit) is received before the 7990 Desired Data Transfer Length is transferred, a target MAY choose 7991 to Reject that PDU with "Protocol error" reason code. 7992 DataPDUInOrder governs the Data-Out PDU ordering. If 7993 DataPDUInOrder is set to Yes, the Buffer Offsets and Lengths for 7994 consecutive PDUs MUST form a continuous non-overlapping range and 7995 the PDUs MUST be sent in increasing offset order. 7997 The target may send several R2T PDUs. It, therefore, can have a 7998 number of pending data transfers. The number of outstanding R2T 7999 PDUs are limited by the value of the negotiated key 8000 MaxOutstandingR2T. Within a task, outstanding R2Ts MUST be 8001 fulfilled by the initiator in the order in which they were 8002 received. 8004 R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T 8005 (Recovery-R2T) is generated by a target upon detecting the loss of 8006 one or more Data-Out PDUs due to: 8008 - Digest error 8010 - Sequence error 8012 - Sequence reception timeout 8014 A Recovery-R2T carries the next unused R2TSN, but requests part of 8015 or the entire data burst that an earlier R2T (with a lower R2TSN) 8016 had already requested. 8018 DataSequenceInOrder governs the buffer offset ordering in 8019 consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive 8020 R2Ts MUST refer to continuous non-overlapping ranges except for 8021 Recovery-R2Ts. 8023 11.8.1. TotalAHSLength and DataSegmentLength 8025 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 8027 11.8.2. R2TSN 8029 R2TSN is the R2T PDU input PDU number within the command 8030 identified by the Initiator Task Tag. 8032 For bidirectional commands R2T and Data-In PDUs share the input 8033 PDU numbering sequence (see Section 4.2.2.4- "Data Sequencing"). 8035 11.8.3. StatSN 8037 The StatSN field will contain the next StatSN. The StatSN for this 8038 connection is not advanced after this PDU is sent. 8040 11.8.4. Desired Data Transfer Length and Buffer Offset 8042 The target specifies how many bytes it wants the initiator to send 8043 because of this R2T PDU. The target may request the data from the 8044 initiator in several chunks, not necessarily in the original order 8045 of the data. The target, therefore, also specifies a Buffer Offset 8046 that indicates the point at which the data transfer should begin, 8047 relative to the beginning of the total data transfer. The Desired 8048 Data Transfer Length MUST NOT be 0 and MUST NOT exceed 8049 MaxBurstLength. 8051 11.8.5. Target Transfer Tag 8053 The target assigns its own tag to each R2T request that it sends 8054 to the initiator. This tag can be used by the target to easily 8055 identify the data it receives. The Target Transfer Tag and LUN are 8056 copied in the outgoing data PDUs and are only used by the target. 8057 There is no protocol rule about the Target Transfer Tag except 8058 that the value 0xffffffff is reserved and MUST NOT be sent by a 8059 target in an R2T. 8061 11.9. Asynchronous Message 8063 An Asynchronous Message may be sent from the target to the 8064 initiator without correspondence to a particular command. The 8065 target specifies the reason for the event and sense data. 8067 Byte/ 0 | 1 | 2 | 3 | 8068 / | | | | 8069 |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| 8070 +---------------+---------------+---------------+--------------+ 8071 0|.|.| 0x32 |1| Reserved | 8072 +---------------+---------------+---------------+--------------+ 8073 4|TotalAHSLength | DataSegmentLength | 8074 +---------------+---------------+---------------+--------------+ 8075 8| LUN or Reserved | 8076 + + 8077 12| | 8078 +---------------+---------------+---------------+--------------+ 8079 16| 0xffffffff | 8080 +---------------+---------------+---------------+--------------+ 8081 20| Reserved | 8082 +---------------+---------------+---------------+--------------+ 8083 24| StatSN | 8084 +---------------+---------------+---------------+--------------+ 8085 28| ExpCmdSN | 8086 +---------------+---------------+---------------+--------------+ 8087 32| MaxCmdSN | 8088 +---------------+---------------+---------------+--------------+ 8089 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | 8090 +---------------+---------------+---------------+--------------+ 8091 40| Parameter2 or Reserved | Parameter3 or Reserved | 8092 +---------------+---------------+---------------+--------------+ 8093 44| Reserved | 8094 +---------------+---------------+---------------+--------------+ 8095 48| Header-Digest (Optional) | 8096 +---------------+---------------+---------------+--------------+ 8097 / DataSegment - Sense Data and iSCSI Event Data / 8098 +/ / 8099 +---------------+---------------+---------------+--------------+ 8100 | Data-Digest (Optional) | 8101 +---------------+---------------+---------------+--------------+ 8103 Some Asynchronous Messages are strictly related to iSCSI while 8104 others are related to SCSI [SAM2]. 8106 StatSN counts this PDU as an acknowledgeable event (StatSN is 8107 advanced), which allows for initiator and target state 8108 synchronization. 8110 11.9.1. AsyncEvent 8112 The codes used for iSCSI Asynchronous Messages (events) are: 8114 0 (SCSI_ASYNC) - a SCSI Asynchronous Event is reported in the 8115 sense data. Sense Data that accompanies the report, in the 8116 data segment, identifies the condition. The sending of a 8117 SCSI Event (Asynchronous Event Reporting in SCSI 8118 terminology) is dependent on the target support for SCSI 8119 asynchronous event reporting (see [SAM2]) as indicated in 8120 the standard INQUIRY data (see [SPC3]). Its use may be 8121 enabled by parameters in the SCSI Control mode page (see 8122 [SPC3]). 8124 1 (REQUEST_LOGOUT) - target requests Logout. This Async 8125 Message MUST be sent on the same connection as the one 8126 requesting to be logged out. The initiator MUST honor this 8127 request by issuing a Logout as early as possible, but no 8128 later than Parameter3 seconds. Initiator MUST send a 8129 Logout with a reason code of "Close the connection" OR 8130 "Close the session" to close all the connections. Once this 8131 message is received, the initiator SHOULD NOT issue new 8132 iSCSI commands on the connection to be logged out. The 8133 target MAY reject any new I/O requests that it receives 8134 after this Message with the reason code "Waiting for 8135 Logout". If the initiator does not Logout in Parameter3 8136 seconds, the target should send an Async PDU with iSCSI 8137 event code "Dropped the connection" if possible, or simply 8138 terminate the transport connection. Parameter1 and 8139 Parameter2 are reserved. 8141 2 (CONNECTION_DROP) - target indicates it will drop the 8142 connection. 8143 The Parameter1 field indicates the CID of the connection 8144 going to be dropped. 8146 The Parameter2 field (Time2Wait) indicates, in seconds, the 8147 minimum time to wait before attempting to reconnect or 8148 reassign. 8150 The Parameter3 field (Time2Retain) indicates the maximum 8151 time allowed to reassign commands after the initial wait (in 8152 Parameter2). 8154 If the initiator does not attempt to reconnect and/or 8155 reassign the outstanding commands within the time specified 8156 by Parameter3, or if Parameter3 is 0, the target will 8157 terminate all outstanding commands on this connection. In 8158 this case, no other responses should be expected from the 8159 target for the outstanding commands on this connection. 8161 A value of 0 for Parameter2 indicates that reconnect can be 8162 attempted immediately. 8164 3 (SESSION_DROP) - target indicates it will drop all the 8165 connections of this session. 8167 Parameter1 field is reserved. 8169 The Parameter2 field (Time2Wait) indicates, in seconds, the 8170 minimum time to wait before attempting to reconnect. 8171 The Parameter3 field (Time2Retain) indicates the maximum 8172 time allowed to reassign commands after the initial wait (in 8173 Parameter2). 8175 If the initiator does not attempt to reconnect and/or 8176 reassign the outstanding commands within the time specified 8177 by Parameter3, or if Parameter3 is 0, the session is 8178 terminated. In this case, the target will terminate all 8179 outstanding commands in this session; no other responses 8180 should be expected from the target for the outstanding 8181 commands in this session. A value of 0 for Parameter2 8182 indicates that reconnect can be attempted immediately. 8184 4 (RENEGOTIATE) - target requests parameter negotiation on 8185 this connection. The initiator MUST honor this request by 8186 issuing a Text Request (that can be empty) on the same 8187 connection as early as possible, but no later than 8188 Parameter3 seconds, unless a Text Request is already pending 8189 on the connection, or by issuing a Logout Request. If the 8190 initiator does not issue a Text Request the target may 8191 reissue the Asynchronous Message requesting parameter 8192 negotiation. 8194 5 (FAST_ABORT) - all active tasks for LU with a matching LUN 8195 field in the Async Message PDU are being terminated. The 8196 receiving initiator iSCSI layer MUST respond to this Message 8197 by taking the following steps in order. 8199 - Stop Data-Out transfers on that connection for all active 8200 TTTs for the affected LUN quoted in the Async Message 8201 PDU. 8202 - Acknowledge the StatSN of the Async Message PDU via a NOP- 8203 Out PDU with ITT=0xffffffff (i.e., non-ping flavor), 8204 while copying the LUN field from the Async Message to 8205 NOP-Out. 8207 This value of AsyncEvent however MUST NOT be used on an 8208 iSCSI session unless the new TaskReporting text key defined 8209 in Section 13.23 was negotiated to FastAbort on the session. 8211 255 - vendor-specific iSCSI Event. The AsyncVCode details the 8212 vendor code, and data MAY accompany the report. 8214 All other event codes are reserved. 8216 11.9.2. AsyncVCode 8218 AsyncVCode is a vendor specific detail code that is only valid if 8219 the AsyncEvent field indicates a vendor specific event. Otherwise, 8220 it is reserved. 8222 11.9.3. LUN 8224 The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this 8225 field is reserved. 8226 11.9.4. Sense Data and iSCSI Event Data 8228 For a SCSI event, this data accompanies the report in the data 8229 segment and identifies the condition. 8231 For an iSCSI event, additional vendor-unique data MAY accompany 8232 the Async event. Initiators MAY ignore the data when not 8233 understood while processing the rest of the PDU. 8235 If the DataSegmentLength is not 0, the format of the DataSegment 8236 is as follows: 8237 Byte/ 0 | 1 | 2 | 3 | 8238 / | | | | 8239 |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| 8240 +---------------+---------------+---------------+--------------+ 8241 0|SenseLength | Sense Data | 8242 +---------------+---------------+---------------+--------------+ 8243 x/ Sense Data / 8244 +---------------+---------------+---------------+--------------+ 8245 y/ iSCSI Event Data / 8246 / / 8247 +---------------+---------------+---------------+--------------+ 8248 z| 8250 11.9.4.1. SenseLength 8252 This is the length of Sense Data. When the Sense Data field is 8253 empty (e.g., the event is not a SCSI event) SenseLength is 0. 8255 11.10. Text Request 8257 The Text Request is provided to allow for the exchange of 8258 information and for future extensions. It permits the initiator to 8259 inform a target of its capabilities or to request some special 8260 operations. 8262 Byte/ 0 | 1 | 2 | 3 | 8263 / | | | | 8264 |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| 8265 +---------------+---------------+---------------+--------------+ 8266 0|.|I| 0x04 |F|C| Reserved | 8267 +---------------+---------------+---------------+--------------+ 8268 4|TotalAHSLength | DataSegmentLength | 8269 +---------------+---------------+---------------+--------------+ 8270 8| LUN or Reserved | 8271 + + 8272 12| | 8273 +---------------+---------------+---------------+--------------+ 8274 16| Initiator Task Tag | 8275 +---------------+---------------+---------------+--------------+ 8276 20| Target Transfer Tag or 0xffffffff | 8277 +---------------+---------------+---------------+--------------+ 8278 24| CmdSN | 8279 +---------------+---------------+---------------+--------------+ 8280 28| ExpStatSN | 8281 +---------------+---------------+---------------+--------------+ 8282 32/ Reserved / 8283 +/ / 8284 +---------------+---------------+---------------+--------------+ 8285 48| Header-Digest (Optional) | 8286 +---------------+---------------+---------------+--------------+ 8287 / DataSegment (Text) / 8288 +/ / 8289 +---------------+---------------+---------------+--------------+ 8290 | Data-Digest (Optional) | 8291 +---------------+---------------+---------------+--------------+ 8293 An initiator MUST NOT have more than one outstanding Text Request 8294 on a connection at any given time. 8296 On a connection failure, an initiator must either explicitly abort 8297 any active allegiant text negotiation task or must cause such a 8298 task to be implicitly terminated by the target. 8300 11.10.1. F (Final) Bit 8302 When set to 1, indicates that this is the last or only text 8303 request in a sequence of Text Requests; otherwise, it indicates 8304 that more Text Requests will follow. 8306 11.10.2. C (Continue) Bit 8308 When set to 1, indicates that the text (set of key=value pairs) 8309 in this Text Request is not complete (it will be continued on 8310 subsequent Text Requests); otherwise, it indicates that this Text 8311 Request ends a set of key=value pairs. A Text Request with the C 8312 bit set to 1 MUST have the F bit set to 0. 8314 11.10.3. Initiator Task Tag 8316 The initiator assigned identifier for this Text Request. If the 8317 command is sent as part of a sequence of text requests and 8318 responses, the Initiator Task Tag MUST be the same for all the 8319 requests within the sequence (similar to linked SCSI commands). 8320 The I bit for all requests in a sequence also MUST be the same. 8322 11.10.4. Target Transfer Tag 8324 When the Target Transfer Tag is set to the reserved value 8325 0xffffffff, it tells the target that this is a new request and the 8326 target resets any internal state associated with the Initiator 8327 Task Tag (resets the current negotiation state). 8329 The target sets the Target Transfer Tag in a text response to a 8330 value other than the reserved value 0xffffffff whenever it 8331 indicates that it has more data to send or more operations to 8332 perform that are associated with the specified Initiator Task Tag. 8333 It MUST do so whenever it sets the F bit to 0 in the response. By 8334 copying the Target Transfer Tag from the response to the next Text 8335 Request, the initiator tells the target to continue the operation 8336 for the specific Initiator Task Tag. The initiator MUST ignore the 8337 Target Transfer Tag in the Text Response when the F bit is set to 8338 1. 8340 This mechanism allows the initiator and target to transfer a large 8341 amount of textual data over a sequence of text-command/text- 8342 response exchanges, or to perform extended negotiation sequences. 8344 If the Target Transfer Tag is not 0xffffffff, the LUN field MUST 8345 be sent by the target in the Text Response. 8347 A target MAY reset its internal negotiation state if an exchange 8348 is stalled by the initiator for a long time or if it is running 8349 out of resources. 8351 Long text responses are handled as in the following example: 8353 I->T Text SendTargets=All (F=1,TTT=0xffffffff) 8355 T->I Text (F=0,TTT=0x12345678) 8357 I->T Text (F=1, TTT=0x12345678) 8359 T->I Text (F=0, TTT=0x12345678) 8361 I->T Text (F=1, TTT=0x12345678) 8363 ... 8365 T->I Text (F=1, TTT=0xffffffff) 8367 11.10.5. Text 8369 The data lengths of a text request MUST NOT exceed the iSCSI 8370 target MaxRecvDataSegmentLength (a per connection and per 8371 direction negotiated parameter). The text format is specified in 8372 Section 6.2- "Text Mode Negotiation". 8374 Chapter 11 and Chapter 12 list some basic Text key=value pairs, 8375 some of which can be used in Login Request/Response and some in 8376 Text Request/Response. 8378 A key=value pair can span Text request or response boundaries. A 8379 key=value pair can start in one PDU and continue on the next. In 8380 other words the end of a PDU does not necessarily signal the end 8381 of a key=value pair. 8383 The target responds by sending its response back to the initiator. 8384 The response text format is similar to the request text format. 8385 The text response MAY refer to key=value pairs presented in an 8386 earlier text request and the text in the request may refer to 8387 earlier responses. 8389 Chapter 5 details the rules for the Text Requests and Responses. 8391 Text operations are usually meant for parameter 8392 setting/negotiations, but can also be used to perform some long 8393 lasting operations. 8395 Text operations that take a long time should be placed in their 8396 own Text request. 8398 11.11. Text Response 8400 The Text Response PDU contains the target's responses to the 8401 initiator's Text request. The format of the Text field matches 8402 that of the Text request. 8404 Byte/ 0 | 1 | 2 | 3 | 8405 / | | | | 8406 |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| 8407 +---------------+---------------+---------------+--------------+ 8408 0|.|.| 0x24 |F|C| Reserved | 8409 +---------------+---------------+---------------+--------------+ 8410 4|TotalAHSLength | DataSegmentLength | 8411 +---------------+---------------+---------------+--------------+ 8412 8| LUN or Reserved | 8413 + + 8414 12| | 8415 +---------------+---------------+---------------+--------------+ 8416 16| Initiator Task Tag | 8417 +---------------+---------------+---------------+--------------+ 8418 20| Target Transfer Tag or 0xffffffff | 8419 +---------------+---------------+---------------+--------------+ 8420 24| StatSN | 8421 +---------------+---------------+---------------+--------------+ 8422 28| ExpCmdSN | 8423 +---------------+---------------+---------------+--------------+ 8424 32| MaxCmdSN | 8425 +---------------+---------------+---------------+--------------+ 8426 36/ Reserved / 8427 +/ / 8428 +---------------+---------------+---------------+--------------+ 8429 48| Header-Digest (Optional) | 8430 +---------------+---------------+---------------+--------------+ 8431 / DataSegment (Text) / 8432 +/ / 8433 +---------------+---------------+---------------+--------------+ 8434 | Data-Digest (Optional) | 8435 +---------------+---------------+---------------+--------------+ 8437 11.11.1. F (Final) Bit 8439 When set to 1, in response to a Text Request with the Final bit 8440 set to 1, the F bit indicates that the target has finished the 8441 whole operation. Otherwise, if set to 0 in response to a Text 8442 Request with the Final Bit set to 1, it indicates that the target 8443 has more work to do (invites a follow-on text request). A Text 8444 Response with the F bit set to 1 in response to a Text Request 8445 with the F bit set to 0 is a protocol error. 8447 A Text Response with the F bit set to 1 MUST NOT contain key=value 8448 pairs that may require additional answers from the initiator. 8450 A Text Response with the F bit set to 1 MUST have a Target 8451 Transfer Tag field set to the reserved value of 0xffffffff. 8453 A Text Response with the F bit set to 0 MUST have a Target 8454 Transfer Tag field set to a value other than the reserved 8455 0xffffffff. 8457 11.11.2. C (Continue) Bit 8459 When set to 1, indicates that the text (set of key=value pairs) in 8460 this Text Response is not complete (it will be continued on 8461 subsequent Text Responses); otherwise, it indicates that this Text 8462 Response ends a set of key=value pairs. A Text Response with the C 8463 bit set to 1 MUST have the F bit set to 0. 8465 11.11.3. Initiator Task Tag 8467 The Initiator Task Tag matches the tag used in the initial Text 8468 Request. 8470 11.11.4. Target Transfer Tag 8472 When a target has more work to do (e.g., cannot transfer all the 8473 remaining text data in a single Text Response or has to continue 8474 the negotiation) and has enough resources to proceed, it MUST set 8475 the Target Transfer Tag to a value other than the reserved value 8476 of 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to 8477 0xffffffff. 8479 When the Target Transfer Tag is not 0xffffffff, the LUN field may 8480 be significant. 8482 The initiator MUST copy the Target Transfer Tag and LUN in its 8483 next request to indicate that it wants the rest of the data. 8485 When the target receives a Text Request with the Target Transfer 8486 Tag set to the reserved value of 0xffffffff, it resets its 8487 internal information (resets state) associated with the given 8488 Initiator Task Tag (restarts the negotiation). 8490 When a target cannot finish the operation in a single Text 8491 Response, and does not have enough resources to continue, it 8492 rejects the Text Request with the appropriate Reject code. 8494 A target may reset its internal state associated with an Initiator 8495 Task Tag (the current negotiation state), state expressed through 8496 the Target Transfer Tag if the initiator fails to continue the 8497 exchange for some time. The target may reject subsequent Text 8498 Requests with the Target Transfer Tag set to the "stale" value. 8500 11.11.5. StatSN 8502 The target StatSN variable is advanced by each Text Response sent. 8504 11.11.6. Text Response Data 8506 The data lengths of a text response MUST NOT exceed the iSCSI 8507 initiator MaxRecvDataSegmentLength (a per connection and per 8508 direction negotiated parameter). 8510 The text in the Text Response Data is governed by the same rules 8511 as the text in the Text Request Data (see C (Con). 8513 Although the initiator is the requesting party and controls the 8514 request-response initiation and termination, the target can offer 8515 key=value pairs of its own as part of a sequence and not only in 8516 response to the initiator. 8518 11.12. Login Request 8520 After establishing a TCP connection between an initiator and a 8521 target, the initiator MUST start a Login Phase to gain further 8522 access to the target's resources. 8524 The Login Phase (see Chapter 5) consists of a sequence of Login 8525 requests and responses that carry the same Initiator Task Tag. 8527 Login requests are always considered as immediate. 8529 Byte/ 0 | 1 | 2 | 3 | 8530 / | | | | 8531 |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| 8532 +---------------+---------------+---------------+--------------+ 8533 0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min | 8534 +---------------+---------------+---------------+--------------+ 8535 4|TotalAHSLength | DataSegmentLength | 8536 +---------------+---------------+---------------+--------------+ 8537 8| ISID | 8538 + +---------------+--------------+ 8539 12| | TSIH | 8540 +---------------+---------------+---------------+--------------+ 8541 16| Initiator Task Tag | 8542 +---------------+---------------+---------------+--------------+ 8543 20| CID | Reserved | 8544 +---------------+---------------+---------------+--------------+ 8545 24| CmdSN | 8546 +---------------+---------------+---------------+--------------+ 8547 28| ExpStatSN or Reserved | 8548 +---------------+---------------+---------------+--------------+ 8549 32| Reserved | 8550 +---------------+---------------+---------------+--------------+ 8551 36| Reserved | 8552 +---------------+---------------+---------------+--------------+ 8553 40/ Reserved / 8554 +/ / 8555 +---------------+---------------+---------------+--------------+ 8556 48/ DataSegment - Login Parameters in Text request Format / 8557 +/ / 8558 +---------------+---------------+---------------+--------------+ 8560 11.12.1. T (Transit) Bit 8562 If set to 1, indicates that the initiator is ready to transit to 8563 the next stage. 8565 If the T bit is set to 1 and NSG is FullFeaturePhase, then this 8566 also indicates that the initiator is ready for the Final Login 8567 Response (see Chapter 5). 8569 11.12.2. C (Continue) Bit 8571 When set to 1, indicates that the text (set of key=value pairs) 8572 in this Login Request is not complete (it will be continued on 8573 subsequent Login Requests); otherwise, it indicates that this 8574 Login Request ends a set of key=value pairs. A Login Request with 8575 the C bit set to 1 MUST have the T bit set to 0. 8577 11.12.3. CSG and NSG 8579 Through these fields, Current Stage (CSG) and Next Stage (NSG), 8580 the Login negotiation requests and responses are associated with a 8581 specific stage in the session (SecurityNegotiation, 8582 LoginOperationalNegotiation, FullFeaturePhase) and may indicate 8583 the next stage to which they want to move (see Chapter 5). The 8584 next stage value is only valid when the T bit is 1; otherwise, it 8585 is reserved. 8587 The stage codes are: 8589 - 0 - SecurityNegotiation 8591 - 1 - LoginOperationalNegotiation 8593 - 3 - FullFeaturePhase 8595 All other codes are reserved. 8597 11.12.4. Version 8599 The version number of the current draft is 0x00. As such, all 8600 devices MUST carry version 0x00 for both Version-min and Version- 8601 max. 8603 11.12.4.1. Version-max 8605 Maximum Version number supported. 8607 All Login requests within the Login Phase MUST carry the same 8608 Version-max. 8610 The target MUST use the value presented with the first login 8611 request. 8613 11.12.4.2. Version-min 8615 All Login requests within the Login Phase MUST carry the same 8616 Version-min. The target MUST use the value presented with the 8617 first login request. 8619 11.12.5. ISID 8621 This is an initiator-defined component of the session identifier 8622 and is structured as follows (see Section 10.1.1 for details): 8624 Byte/ 0 | 1 | 2 | 3 | 8625 / | | | | 8626 |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| 8627 +---------------+---------------+---------------+--------------+ 8628 8| T | A | B | C | 8629 +---------------+---------------+---------------+--------------+ 8630 12| D | 8631 +---------------+---------------+ 8633 The T field identifies the format and usage of A, B, C, and D as 8634 indicated below: 8636 T 8638 00b OUI-Format 8640 A&B are a 22 bit OUI 8642 (the I/G & U/L bits are omitted) 8644 C&D 24 bit qualifier 8646 01b EN - Format (IANA Enterprise Number) 8648 A - Reserved 8650 B&C EN (IANA Enterprise Number) 8652 D - Qualifier 8654 10b "Random" 8656 A - Reserved 8658 B&C Random 8660 D - Qualifier 8662 11b A,B,C&D Reserved 8664 For the T field values 00b and 01b, a combination of A and B (for 8665 00b) or B and C (for 01b) identifies the vendor or organization 8666 whose component (software or hardware) generates this ISID. A 8667 vendor or organization with one or more OUIs, or one or more 8668 Enterprise Numbers, MUST use at least one of these numbers and 8669 select the appropriate value for the T field when its components 8670 generate ISIDs. An OUI or EN MUST be set in the corresponding 8671 fields in network byte order (byte big-endian). 8673 If the T field is 10b, B and C are set to a random 24-bit unsigned 8674 integer value in network byte order (byte big-endian). See 8675 [RFC3721] for how this affects the principle of "conservative 8676 reuse". 8678 The Qualifier field is a 16 or 24-bit unsigned integer value that 8679 provides a range of possible values for the ISID within the 8680 selected namespace. It may be set to any value within the 8681 constraints specified in the iSCSI protocol (see Section 4.4.3 - 8682 "Consequences of the Model" and Section 10.1.1- "Conservative 8683 Reuse of ISIDs"). 8685 The T field value of 11b is reserved. 8687 If the ISID is derived from something assigned to a hardware 8688 adapter or interface by a vendor, as a preset default value, it 8689 MUST be configurable to a value assigned according to the SCSI 8690 port behavior desired by the system in which it is installed (see 8691 Section 10.1.1- "Conservative Reuse of ISIDs" and Section 10.1.2 - 8692 "iSCSI Name, ISID, and TPGT Use"). The resultant ISID MUST also be 8693 persistent over power cycles, reboot, card swap, etc. 8695 11.12.6. TSIH 8697 TSIH must be set in the first Login Request. The reserved value 0 8698 MUST be used on the first connection for a new session. Otherwise, 8699 the TSIH sent by the target at the conclusion of the successful 8700 login of the first connection for this session MUST be used. The 8701 TSIH identifies to the target the associated existing session for 8702 this new connection. 8704 All Login requests within a Login Phase MUST carry the same TSIH. 8706 The target MUST check the value presented with the first login 8707 request and act as specified in Section 5.3.1 - "Login Phase 8708 Start". 8710 11.12.7. Connection ID - CID 8712 A unique ID for this connection within the session. 8714 All Login requests within the Login Phase MUST carry the same CID. 8716 The target MUST use the value presented with the first login 8717 request. 8719 A Login request with a non-zero TSIH and a CID equal to that of an 8720 existing connection implies a logout of the connection followed by 8721 a Login (see Section 6.3.4). For the details of the implicit 8722 Logout Request, see Section 11.14. 8724 11.12.8. CmdSN 8726 CmdSN is either the initial command sequence number of a session 8727 (for the first Login request of a session - the "leading" login), 8728 or the command sequence number in the command stream if the login 8729 is for a new connection in an existing session. 8731 Examples: 8733 - Login on a leading connection - if the leading login carries 8734 the CmdSN 123, all other login requests in the same login 8735 phase carry the CmdSN 123 and the first non-immediate 8736 command in FullFeaturePhase also carries the CmdSN 123. 8738 - Login on other than a leading connection - if the current 8739 CmdSN at the time the first login on the connection is 8740 issued is 500, then that PDU carries CmdSN=500. Subsequent 8741 login requests that are needed to complete this login phase 8742 may carry a CmdSN higher than 500 if non-immediate requests 8743 that were issued on other connections in the same session 8744 advance CmdSN. 8746 If the login request is a leading login request, the target MUST 8747 use the value presented in CmdSN as the target value for ExpCmdSN. 8749 11.12.9. ExpStatSN 8751 For the first Login Request on a connection this is ExpStatSN for 8752 the old connection and this field is only valid if the Login 8753 request restarts a connection (see Section 6.3.4- "Connection 8754 Reinstatement"). 8756 For subsequent Login Requests it is used to acknowledge the Login 8757 Responses with their increasing StatSN values. 8759 11.12.10. Login Parameters 8761 The initiator MUST provide some basic parameters in order to 8762 enable the target to determine if the initiator may use the 8763 target's resources and the initial text parameters for the 8764 security exchange. 8766 All the rules specified in Section 11.10.5 for text requests also 8767 hold for login requests. Keys and their explanations are listed 8768 in Chapter 12 (security negotiation keys) and Section 13 8769 (operational parameter negotiation keys). All keys in Section 13, 8770 except for the X extension formats, MUST be supported by iSCSI 8771 initiators and targets. Keys in Section 12 only need to be 8773 supported when the function to which they refer is mandatory to 8774 implement. 8776 11.13. Login Response 8778 The Login Response indicates the progress and/or end of the Login 8779 Phase. 8781 Byte/ 0 | 1 | 2 | 3 | 8782 / | | | | 8783 |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| 8784 +---------------+---------------+---------------+--------------+ 8785 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max |Version-active| 8786 +---------------+---------------+---------------+--------------+ 8787 4|TotalAHSLength | DataSegmentLength | 8788 +---------------+---------------+---------------+--------------+ 8789 8| ISID | 8790 + +---------------+--------------+ 8791 12| | TSIH | 8792 +---------------+---------------+---------------+--------------+ 8793 16| Initiator Task Tag | 8794 +---------------+---------------+---------------+--------------+ 8795 20| Reserved | 8796 +---------------+---------------+---------------+--------------+ 8797 24| StatSN | 8798 +---------------+---------------+---------------+--------------+ 8799 28| ExpCmdSN | 8800 +---------------+---------------+---------------+--------------+ 8801 32| MaxCmdSN | 8802 +---------------+---------------+---------------+--------------+ 8803 36| Status-Class | Status-Detail | Reserved | 8804 +---------------+---------------+---------------+--------------+ 8805 40/ Reserved / 8806 +/ / 8807 +---------------+---------------+---------------+--------------+ 8808 48/ DataSegment - Login Parameters in Text request Format / 8809 +/ / 8810 +---------------+---------------+---------------+--------------+ 8812 11.13.1. Version-max 8814 This is the highest version number supported by the target. 8816 All Login responses within the Login Phase MUST carry the same 8817 Version-max. 8819 The initiator MUST use the value presented as a response to the 8820 first login request. 8822 11.13.2. Version-active 8824 Indicates the highest version supported by the target and 8825 initiator. If the target does not support a version within the 8826 range specified by the initiator, the target rejects the login and 8827 this field indicates the lowest version supported by the target. 8829 All Login responses within the Login Phase MUST carry the same 8830 Version-active. 8832 The initiator MUST use the value presented as a response to the 8833 first login request. 8835 11.13.3. TSIH 8837 The TSIH is the target assigned session identifying handle. Its 8838 internal format and content are not defined by this protocol 8839 except for the value 0 that is reserved. With the exception of the 8840 Login Final-Response in a new session, this field should be set to 8841 the TSIH provided by the initiator in the Login Request. For a 8842 new session, the target MUST generate a non-zero TSIH and ONLY 8843 return it in the Login Final-Response (see Section 6.3 - "Login 8844 Phase"). 8846 11.13.4. StatSN 8848 For the first Login Response (the response to the first Login 8849 Request), this is the starting status Sequence Number for the 8850 connection. The next response of any kind, including the next 8851 login response, if any, in the same Login Phase, will carry this 8852 number + 1. This field is only valid if the Status-Class is 0. 8854 11.13.5. Status-Class and Status-Detail 8856 The Status returned in a Login Response indicates the execution 8857 status of the Login Phase. The status includes: 8859 Status-Class 8861 Status-Detail 8863 0 Status-Class indicates success. 8865 A non-zero Status-Class indicates an exception. In this case, 8866 Status-Class is sufficient for a simple initiator to use when 8867 handling exceptions, without having to look at the Status-Detail. 8868 The Status-Detail allows finer-grained exception handling for more 8869 sophisticated initiators and for better information for logging. 8871 The status classes are as follows: 8873 0 - Success - indicates that the iSCSI target successfully 8874 received, understood, and accepted the request. The 8875 numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid 8876 if Status-Class is 0. 8878 1 - Redirection - indicates that the initiator must take 8879 further action to complete the request. This is usually due 8880 to the target moving to a different address. All of the 8881 redirection status class responses MUST return one or more 8882 text key parameters of the type "TargetAddress", which 8883 indicates the target's new address. A redirection response 8884 MAY be issued by a target prior or after completing a 8885 security negotiation if a security negotiation is required. 8886 A redirection SHOULD be accepted by an initiator even 8887 without having the target complete a security negotiation if 8888 any security negotiation is required, and MUST be accepted 8889 by the initiator after the completion of the security 8890 negotiation if any security negotiation is required. 8892 2 - Initiator Error (not a format error) - indicates that the 8893 initiator most likely caused the error. This MAY be due to a 8895 request for a resource for which the initiator does not have 8896 permission. The request should not be tried again. 8898 3 - Target Error - indicates that the target sees no errors in 8899 the initiator's login request, but is currently incapable of 8900 fulfilling the request. The initiator may re-try the same 8901 login request later. 8903 The table below shows all of the currently allocated status codes. 8904 The codes are in hexadecimal; the first byte is the status class 8905 and the second byte is the status detail. 8907 ----------------------------------------------------------------- 8908 Status | Code | Description 8909 |(hex) | 8910 ----------------------------------------------------------------- 8911 Success | 0000 | Login is proceeding OK (*1). 8912 ----------------------------------------------------------------- 8913 Target moved | 0101 | The requested iSCSI Target Name (ITN) 8914 temporarily | | has temporarily moved 8915 | | to the address provided. 8916 ----------------------------------------------------------------- 8917 Target moved | 0102 | The requested ITN has permanently moved 8918 permanently | | to the address provided. 8919 ----------------------------------------------------------------- 8920 Initiator | 0200 | Miscellaneous iSCSI initiator 8921 error | | errors. 8922 ---------------------------------------------------------------- 8923 Authentication| 0201 | The initiator could not be 8924 failure | | successfully authenticated or target 8925 | | authentication is not supported. 8926 ----------------------------------------------------------------- 8927 Authorization | 0202 | The initiator is not allowed access 8928 failure | | to the given target. 8929 ----------------------------------------------------------------- 8930 Not found | 0203 | The requested ITN does not 8931 | | exist at this address. 8932 ----------------------------------------------------------------- 8933 Target removed| 0204 | The requested ITN has been removed and 8934 | |no forwarding address is provided. 8935 ----------------------------------------------------------------- 8936 Unsupported | 0205 | The requested iSCSI version range is 8937 version | | not supported by the target. 8938 ----------------------------------------------------------------- 8939 Too many | 0206 | Too many connections on this SSID. 8940 connections | | 8941 ----------------------------------------------------------------- 8942 Missing | 0207 | Missing parameters (e.g., iSCSI 8943 parameter | | Initiator and/or Target Name). 8944 ----------------------------------------------------------------- 8945 Can't include | 0208 | Target does not support session 8946 in session | | spanning to this connection (address). 8947 ----------------------------------------------------------------- 8948 Session type | 0209 | Target does not support this type of 8949 not supported | | of session or not from this Initiator. 8950 ----------------------------------------------------------------- 8951 Session does | 020a | Attempt to add a connection 8952 not exist | | to a non-existent session. 8953 ----------------------------------------------------------------- 8954 Invalid during| 020b | Invalid Request type during Login. 8955 login | | 8956 ----------------------------------------------------------------- 8957 Target error | 0300 | Target hardware or software error. 8958 ----------------------------------------------------------------- 8959 Service | 0301 | The iSCSI service or target is not 8960 unavailable | | currently operational. 8961 ----------------------------------------------------------------- 8962 Out of | 0302 | The target has insufficient session, 8963 resources | | connection, or other resources. 8964 ----------------------------------------------------------------- 8966 (*1)If the response T bit is 1 in both the request and the 8967 matching response, and the NSG is FullFeaturePhase in both the 8968 request and the matching response, the Login Phase is finished and 8969 the initiator may proceed to issue SCSI commands. 8971 If the Status Class is not 0, the initiator and target MUST close 8972 the TCP connection. 8974 If the target wishes to reject the login request for more than one 8975 reason, it should return the primary reason for the rejection. 8977 11.13.6. T (Transit) bit 8979 The T bit is set to 1 as an indicator of the end of the stage. If 8980 the T bit is set to 1 and NSG is FullFeaturePhase, then this is 8981 also the Final Login Response (see Chapter 5). A T bit of 0 8982 indicates a "partial" response, which means "more negotiation 8983 needed". 8985 A login response with a T bit set to 1 MUST NOT contain key=value 8986 pairs that may require additional answers from the initiator 8987 within the same stage. 8989 If the status class is 0, the T bit MUST NOT be set to 1 if the T 8990 bit in the request was set to 0. 8992 11.13.7. C (Continue) Bit 8994 When set to 1, indicates that the text (set of key=value pairs) in 8995 this Login Response is not complete (it will be continued on 8996 subsequent Login Responses); otherwise, it indicates that this 8997 Login Response ends a set of key=value pairs. A Login Response 8998 with the C bit set to 1 MUST have the T bit set to 0. 9000 11.13.8. Login Parameters 9002 The target MUST provide some basic parameters in order to enable 9003 the initiator to determine if it is connected to the correct port 9004 and the initial text parameters for the security exchange. 9006 All the rules specified in Section 11.11.6 for text responses also 9007 hold for login responses. Keys and their explanations are listed 9008 in Chapter 11 (security negotiation keys) and Chapter 12 9009 (operational parameter negotiation keys). All keys in Section 13, 9010 except for the X extension formats, MUST be supported by iSCSI 9011 initiators and targets. Keys in Section 12, only need to be 9012 supported when the function to which they refer is mandatory to 9013 implement. 9015 11.14. Logout Request 9017 The Logout request is used to perform a controlled closing of a 9018 connection. 9020 An initiator MAY use a logout request to remove a connection from 9021 a session or to close an entire session. 9023 After sending the Logout request PDU, an initiator MUST NOT send 9024 any new iSCSI requests on the closing connection. If the Logout 9025 request is intended to close the session, new iSCSI requests MUST 9026 NOT be sent on any of the connections participating in the 9027 session. 9029 When receiving a Logout request with the reason code of "close the 9030 connection" or "close the session", the target MUST terminate all 9031 pending commands, whether acknowledged via ExpCmdSN or not, on 9032 that connection or session respectively. 9034 When receiving a Logout request with the reason code "remove 9035 connection for recovery", the target MUST discard all requests not 9036 yet acknowledged via ExpCmdSN that were issued on the specified 9037 connection, and suspend all data/status/R2T transfers on behalf of 9038 pending commands on the specified connection. 9040 The target then issues the Logout response and half-closes the TCP 9041 connection (sends FIN). After receiving the Logout response and 9042 attempting to receive the FIN (if still possible), the initiator 9043 MUST completely close the logging-out connection. For the 9044 terminated commands, no additional responses should be expected. 9046 A Logout for a CID may be performed on a different transport 9047 connection when the TCP connection for the CID has already been 9048 terminated. In such a case, only a logical "closing" of the iSCSI 9049 connection for the CID is implied with a Logout. 9051 All commands that were not terminated or not completed (with 9052 status) and acknowledged when the connection is closed completely 9053 can be reassigned to a new connection if the target supports 9054 connection recovery. 9056 If an initiator intends to start recovery for a failing 9057 connection, it MUST use the Logout request to "clean-up" the 9058 target end of a failing connection and enable recovery to start, 9059 or the Login request with a non-zero TSIH and the same CID on a 9060 new connection for the same effect. In sessions with a single 9061 connection, the connection can be closed and then a new connection 9062 reopened. A connection reinstatement login can be used for 9063 recovery (see Section 6.3.4- "Connection Reinstatement"). 9065 A successful completion of a logout request with the reason code 9066 of "close the connection" or "remove the connection for recovery" 9067 results at the target in the discarding of unacknowledged commands 9068 received on the connection being logged out. These are commands 9069 that have arrived on the connection being logged out, but have not 9070 been delivered to SCSI because one or more commands with a smaller 9071 CmdSN has not been received by iSCSI. See Section 4.2.2.1 - 9072 "Command Numbering and Acknowledging". The resulting holes in the 9073 command sequence numbers will have to be handled by appropriate 9074 recovery (see Chapter 6) unless the session is also closed. 9076 The entire logout discussion in this section is also applicable 9077 for an implicit Logout realized by way of a connection 9078 reinstatement or session reinstatement. When a Login Request 9079 performs an implicit Logout, the implicit Logout is performed as 9080 if having the reason codes specified below: 9082 Reason code Type of implicit Logout 9084 ------------------------------------------- 9086 0 session reinstatement 9088 1 connection reinstatement when the operational 9089 ErrorRecoveryLevel < 2 9091 2 connection reinstatement when the operational 9092 ErrorRecoveryLevel = 2 9094 Byte/ 0 | 1 | 2 | 3 | 9095 / | | | | 9096 |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| 9097 +---------------+---------------+---------------+--------------+ 9098 0|.|I| 0x06 |1| Reason Code | Reserved | 9099 +---------------+---------------+---------------+--------------+ 9100 4|TotalAHSLength | DataSegmentLength | 9101 +--------------------------------------------------------------+ 9102 8/ Reserved / 9103 +/ / 9104 +---------------+---------------+---------------+--------------+ 9105 16| Initiator Task Tag | 9106 +---------------+---------------+---------------+--------------+ 9107 20| CID or Reserved | Reserved | 9108 +---------------+---------------+---------------+--------------+ 9109 24| CmdSN | 9110 +---------------+---------------+---------------+--------------+ 9111 28| ExpStatSN | 9112 +---------------+---------------+---------------+--------------+ 9113 32/ Reserved / 9114 +/ / 9115 +---------------+---------------+---------------+--------------+ 9116 48| Header-Digest (Optional) | 9117 +---------------+---------------+---------------+--------------+ 9119 11.14.1. Reason Code 9121 Reason Code indicates the reason for Logout as follows: 9123 0 - close the session. All commands associated with the 9124 session (if any) are terminated. 9126 1 - close the connection. All commands associated with 9127 connection (if any) are terminated. 9129 2 - remove the connection for recovery. Connection is closed 9130 and all commands associated with it, if any, are to be 9131 prepared for a new allegiance. 9133 All other values are reserved. 9135 11.14.2. TotalAHSLength and DataSegmentLength 9137 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9139 11.14.3. CID 9141 This is the connection ID of the connection to be closed 9142 (including closing the TCP stream). This field is only valid if 9143 the reason code is not "close the session". 9145 11.14.4. ExpStatSN 9147 This is the last ExpStatSN value for the connection to be closed. 9149 11.14.5. Implicit termination of tasks 9151 A target implicitly terminates the active tasks due to the iSCSI 9152 protocol in the following cases: 9154 When a connection is implicitly or explicitly logged out with 9155 the reason code of "Close the connection" and there are 9156 active tasks allegiant to that connection. 9158 When a connection fails and eventually the connection state 9159 times out (state transition M1 in Section 8.2.2- "State 9160 Transition Descriptions for Initiators and Targets") and 9161 there are active tasks allegiant to that connection. 9163 When a successful recovery Logout is performed while there are 9164 active tasks allegiant to that connection, and those tasks 9165 eventually time out after the Time2Wait and Time2Retain 9166 periods without allegiance reassignment. 9168 When a connection is implicitly or explicitly logged out with 9169 the reason code of "Close the session" and there are active 9170 tasks in that session. 9172 If the tasks terminated in any of the above cases are SCSI tasks, 9173 they must be internally terminated as if with CHECK CONDITION 9174 status. This status is only meaningful for appropriately handling 9175 the internal SCSI state and SCSI side effects with respect to 9176 ordering because this status is never communicated back as a 9177 terminating status to the initiator. However additional actions 9178 may have to be taken at SCSI level depending on the SCSI context 9179 as defined by the SCSI standards (e.g., queued commands and ACA, 9180 UA for the next command on the I_T nexus in cases a), b), and c), 9181 after the tasks are terminated, the target MUST report a Unit 9182 Attention condition on the next command processed on any 9183 connection for each affected I_T_L nexus with the status of CHECK 9184 CONDITION, and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS 9185 CLEARED BY ISCSI PROTOCOL EVENT" - etc. - see [SAM4] and [SPC3]). 9187 11.15. Logout Response 9189 The logout response is used by the target to indicate if the 9190 cleanup operation for the connection(s) has completed. 9192 After Logout, the TCP connection referred by the CID MUST be 9193 closed at both ends (or all connections must be closed if the 9194 logout reason was session close). 9196 Byte/ 0 | 1 | 2 | 3 | 9197 / | | | | 9198 |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| 9199 +---------------+---------------+---------------+--------------+ 9200 0|.|.| 0x26 |1| Reserved | Response | Reserved | 9201 +---------------+---------------+---------------+--------------+ 9202 4|TotalAHSLength | DataSegmentLength | 9203 +--------------------------------------------------------------+ 9204 8/ Reserved / 9205 +/ / 9206 +---------------+---------------+---------------+--------------+ 9207 16| Initiator Task Tag | 9208 +---------------+---------------+---------------+--------------+ 9209 20| Reserved | 9210 +---------------+---------------+---------------+--------------+ 9211 24| StatSN | 9212 +---------------+---------------+---------------+--------------+ 9213 28| ExpCmdSN | 9214 +---------------+---------------+---------------+--------------+ 9215 32| MaxCmdSN | 9216 +---------------+---------------+---------------+--------------+ 9217 36| Reserved | 9218 +--------------------------------------------------------------+ 9219 40| Time2Wait | Time2Retain | 9220 +---------------+---------------+---------------+--------------+ 9221 44| Reserved | 9222 +---------------+---------------+---------------+--------------+ 9223 48| Header-Digest (Optional) | 9224 +---------------+---------------+---------------+--------------+ 9226 11.15.1. Response 9228 Logout response: 9230 0 - connection or session closed successfully. 9232 1 - CID not found. 9234 2 - connection recovery is not supported. If Logout reason 9235 code was recovery and target does not support it as 9236 indicated by the ErrorRecoveryLevel. 9238 3 - cleanup failed for various reasons. 9240 11.15.2. TotalAHSLength and DataSegmentLength 9242 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9244 11.15.3. Time2Wait 9246 If the Logout response code is 0 and if the operational 9247 ErrorRecoveryLevel is 2, this is the minimum amount of time, in 9248 seconds, to wait before attempting task reassignment. If the 9249 Logout response code is 0 and if the operational 9250 ErrorRecoveryLevel is less than 2, this field is to be ignored. 9252 This field is invalid if the Logout response code is 1. 9254 If the Logout response code is 2 or 3, this field specifies the 9255 minimum time to wait before attempting a new implicit or explicit 9256 logout. 9258 If Time2Wait is 0, the reassignment or a new Logout may be 9259 attempted immediately. 9261 11.15.4. Time2Retain 9263 If the Logout response code is 0 and if the operational 9264 ErrorRecoveryLevel is 2, this is the maximum amount of time, in 9265 seconds, after the initial wait (Time2Wait), the target waits for 9266 the allegiance reassignment for any active task after which the 9267 task state is discarded. If the Logout response code is 0 and if 9268 the operational ErrorRecoveryLevel is less than 2, this field is 9269 to be ignored. 9271 This field is invalid if the Logout response code is 1. 9273 If the Logout response code is 2 or 3, this field specifies the 9274 maximum amount of time, in seconds, after the initial wait 9275 (Time2Wait), the target waits for a new implicit or explicit 9276 logout. 9278 If it is the last connection of a session, the whole session state 9279 is discarded after Time2Retain. 9281 If Time2Retain is 0, the target has already discarded the 9282 connection (and possibly the session) state along with the task 9283 states. No reassignment or Logout is required in this case. 9285 11.16. SNACK Request 9287 Byte/ 0 | 1 | 2 | 3 | 9288 / | | | 9289 | 9290 |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| 9291 +---------------+---------------+---------------+--------------+ 9292 0|.|.| 0x10 |1|.|.|.| Type | Reserved | 9293 +---------------+---------------+---------------+--------------+ 9294 4|TotalAHSLength | DataSegmentLength | 9295 +---------------+---------------+---------------+--------------+ 9296 8| LUN or Reserved | 9297 + + 9298 12| | 9299 +---------------+---------------+---------------+--------------+ 9300 16| Initiator Task Tag or 0xffffffff | 9301 +---------------+---------------+---------------+--------------+ 9302 20| Target Transfer Tag or SNACK Tag or 0xffffffff | 9303 +---------------+---------------+---------------+--------------+ 9304 24| Reserved | 9305 +---------------+---------------+---------------+--------------+ 9306 28| ExpStatSN | 9307 +---------------+---------------+---------------+--------------+ 9308 32/ Reserved / 9309 +/ / 9310 +---------------+---------------+---------------+--------------+ 9311 40| BegRun | 9312 +--------------------------------------------------------------+ 9313 44| RunLength | 9314 +--------------------------------------------------------------+ 9315 48| Header-Digest (Optional) | 9316 +---------------+---------------+---------------+--------------+ 9318 If the implementation supports ErrorRecoveryLevel greater than 9319 zero, it MUST support all SNACK types. 9321 The SNACK is used by the initiator to request the retransmission 9322 of numbered-responses, data, or R2T PDUs from the target. The 9323 SNACK request indicates the numbered-responses or data "runs" 9324 whose retransmission is requested by the target, where the run 9325 starts with the first StatSN, DataSN, or R2TSN whose 9326 retransmission is requested and indicates the number of Status, 9327 Data, or R2T PDUs requested including the first. 0 has special 9328 meaning when used as a starting number and length: 9330 - When used in RunLength, it means all PDUs starting with the 9331 initial. 9333 - When used in both BegRun and RunLength, it means all 9334 unacknowledged PDUs. 9336 The numbered-response(s) or R2T(s), requested by a SNACK, MUST be 9337 delivered as exact replicas of the ones that the target 9338 transmitted originally except for the fields ExpCmdSN, MaxCmdSN, 9339 and ExpDataSN, which MUST carry the current values. 9340 R2T(s)requested by SNACK MUST also carry the current value of 9341 StatSN. 9343 The numbered Data-In PDUs, requested by a Data SNACK MUST be 9344 delivered as exact replicas of the ones that the target 9345 transmitted originally except for the fields ExpCmdSN and 9346 MaxCmdSN, which MUST carry the current values and except for 9347 resegmentation (see Resegmentation). 9349 Any SNACK that requests a numbered-response, Data, or R2T that was 9350 not sent by the target or was already acknowledged by the 9351 initiator, MUST be rejected with a reason code of "Protocol 9352 error". 9354 11.16.1. Type 9356 This field encodes the SNACK function as follows: 9358 0-Data/R2T SNACK - requesting retransmission of one or more 9359 Data-In or R2T PDUs. 9361 1-Status SNACK - requesting retransmission of one or more 9362 numbered responses. 9364 2-DataACK - positively acknowledges Data-In PDUs. 9366 3-R-Data SNACK - requesting retransmission of Data-In PDUs 9367 with possible resegmentation and status tagging. 9369 All other values are reserved. 9371 Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST 9372 precede status acknowledgement for the given command. 9374 11.16.2. Data Acknowledgement 9376 If an initiator operates at ErrorRecoveryLevel 1 or higher, it 9377 MUST issue a SNACK of type DataACK after receiving a Data-In PDU 9378 with the A bit set to 1. However, if the initiator has detected 9379 holes in the input sequence, it MUST postpone issuing the SNACK of 9380 type DataACK until the holes are filled. An initiator MAY ignore 9381 the A bit if it deems that the bit is being set aggressively by 9382 the target (i.e., before the MaxBurstLength limit is 9383 reached). 9385 The DataACK is used to free resources at the target and not to 9386 request or imply data retransmission. 9388 An initiator MUST NOT request retransmission for any data it had 9389 already acknowledged. 9391 11.16.3. Resegmentation 9393 If the initiator MaxRecvDataSegmentLength changed between the 9394 original transmission and the time the initiator requests 9395 retransmission, the initiator MUST issue a R-Data SNACK (see 9396 Type). With R-Data SNACK, the initiator indicates that it discards 9397 all the unacknowledged data and expects the target to resend it. 9398 It also expects resegmentation. In this case, the retransmitted 9399 Data-In PDUs MAY be different from the ones originally sent in 9400 order to reflect changes in MaxRecvDataSegmentLength. Their DataSN 9401 starts with the BegRun of the last DataACK received by the target 9402 if any was received; otherwise it starts with 0 and is increased 9403 by 1 for each resent Data-In PDU. 9405 A target that has received a R-Data SNACK MUST return a SCSI 9406 Response that contains a copy of the SNACK Tag field from the R- 9407 Data SNACK in the SCSI Response SNACK Tag field as its last or 9408 only Response. For example, if it has already sent a response 9409 containing another value in the SNACK Tag field or had the status 9410 included in the last Data-In PDU, it must send a new SCSI Response 9411 PDU. If a target sends more than one SCSI Response PDU due to this 9412 rule, all SCSI responses must carry the same StatSN (see SNACK ). 9413 If an initiator attempts to recover a lost SCSI Response (with a 9414 Status-SNACK, see Type) when more than one response has been sent, 9415 the target will send the SCSI Response with the latest content 9416 known to the target, including the last SNACK Tag for the command. 9418 For considerations in allegiance reassignment of a task to a 9419 connection with a different MaxRecvDataSegmentLength, refer to 9420 Section 7.2.2 - "Allegiance Reassignment". 9422 11.16.4. Initiator Task Tag 9424 For Status SNACK and DataACK, the Initiator Task Tag MUST be set 9425 to the reserved value 0xffffffff. In all other cases, the 9426 Initiator Task Tag field MUST be set to the Initiator Task Tag of 9427 the referenced command. 9429 11.16.5. Target Transfer Tag or SNACK Tag 9431 For an R-Data SNACK, this field MUST contain a value that is 9432 different from 0 or 0xffffffff and is unique for the task 9433 (identified by the Initiator Task Tag). This value MUST be copied 9434 by the iSCSI target in the last or only SCSI Response PDU it 9435 issues for the command. 9437 For DataACK, the Target Transfer Tag MUST contain a copy of the 9438 Target Transfer Tag and LUN provided with the SCSI Data-In PDU 9439 with the A bit set to 1. 9441 In all other cases, the Target Transfer Tag field MUST be set to 9442 the reserved value of 0xffffffff. 9444 11.16.6. BegRun 9446 The DataSN, R2TSN, or StatSN of the first PDU whose retransmission 9447 is requested (Data/R2T and Status SNACK), or the next expected 9448 DataSN (DataACK SNACK). 9450 BegRun 0 when used in conjunction with RunLength 0 means resend 9451 all unacknowledged Data-In, R2T or Response PDUs. 9453 BegRun MUST be 0 for a R-Data SNACK. 9455 11.16.7. RunLength 9457 The number of PDUs whose retransmission is requested. 9459 RunLength 0 signals that all Data-In, R2T, or Response PDUs 9460 carrying the numbers equal to or greater than BegRun have to be 9461 resent. 9463 The RunLength MUST also be 0 for a DataACK SNACK in addition to R- 9464 Data SNACK. 9466 11.17. Reject 9468 Byte/ 0 | 1 | 2 | 3 | 9469 / | | | | 9470 |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| 9471 +---------------+---------------+---------------+--------------+ 9472 0|.|.| 0x3f |1| Reserved | Reason | Reserved | 9473 +---------------+---------------+---------------+--------------+ 9474 4|TotalAHSLength | DataSegmentLength | 9475 +---------------+---------------+---------------+--------------+ 9476 8/ Reserved / 9477 +/ / 9478 +---------------+---------------+---------------+--------------+ 9479 16| 0xffffffff | 9480 +---------------+---------------+---------------+--------------+ 9481 20| Reserved | 9482 +---------------+---------------+---------------+--------------+ 9483 24| StatSN | 9484 +---------------+---------------+---------------+--------------+ 9485 28| ExpCmdSN | 9486 +---------------+---------------+---------------+--------------+ 9487 32| MaxCmdSN | 9488 +---------------+---------------+---------------+--------------+ 9489 36| DataSN/R2TSN or Reserved | 9490 +---------------+---------------+---------------+--------------+ 9491 40| Reserved | 9492 +---------------+---------------+---------------+--------------+ 9493 44| Reserved | 9494 +---------------+---------------+---------------+--------------+ 9495 48| Header-Digest (Optional) | 9496 +---------------+---------------+---------------+--------------+ 9497 xx/ Complete Header of Bad PDU / 9498 +/ / 9499 +---------------+---------------+---------------+--------------+ 9500 yy/Vendor specific data (if any) / 9501 / / 9502 +---------------+---------------+---------------+--------------+ 9503 zz| Data-Digest (Optional) | 9504 +---------------+---------------+---------------+--------------+ 9506 Reject is used to indicate an iSCSI error condition (protocol, 9507 unsupported option, etc.). 9509 11.17.1. Reason 9511 The reject Reason is coded as follows: 9513 +------+----------------------------------------+----------------+ 9514 | Code | Explanation |Can the original| 9515 | (hex)| |PDU be re-sent? | 9516 +------+----------------------------------------+----------------+ 9517 | 0x01 | Reserved | no | 9518 | | | | 9519 | 0x02 | Data (payload) Digest Error | yes (Note 1) | 9520 | | | | 9521 | 0x03 | SNACK Reject | yes | 9522 | | | | 9523 | 0x04 | Protocol Error (e.g., SNACK request for| no | 9524 | | a status that was already acknowledged)| | 9525 | | | | 9526 | 0x05 | Command not supported | no | 9527 | | | | 9528 | 0x06 | Immediate Command Reject - too many | yes | 9529 | | immediate commands | | 9530 | | | | 9531 | 0x07 | Task in progress | no | 9532 | | | | 9533 | 0x08 | Invalid Data ACK | no | 9534 | | | | 9535 | 0x09 | Invalid PDU field | no (Note 2) | 9536 | | | | 9537 | 0x0a | Long Operation Reject - Can't generate | yes | 9538 | | Target Transfer Tag - out of resources | | 9539 | | | | 9540 | 0x0c | Waiting for Logout | no | 9541 +------+----------------------------------------+----------------+ 9543 Note 1: For iSCSI, Data-Out PDU retransmission is only done if the 9544 target requests retransmission with a recovery R2T. However, if 9545 this is the data digest error on immediate data, the initiator may 9546 choose to retransmit the whole PDU including the immediate data. 9548 Note 2: A target should use this reason code for all invalid 9549 values of PDU fields that are meant to describe a task, a 9550 response, or a data transfer. Some examples are invalid TTT/ITT, 9551 buffer offset, LUN qualifying a TTT, and an invalid sequence 9552 number in a SNACK. 9554 Note 3: Reason code 0x0b ("Negotiation reset") defined in 9555 [RFC3720] is deprecated and MUST NOT be used by implementations. 9556 An implementation receiving reason code 0x0b MUST treat it as a 9557 negotiation failure that terminates the Login Phase and the TCP 9558 connection, as specified in Section 7.12. 9560 All other values for Reason are reserved. 9562 In all the cases in which a pre-instantiated SCSI task is 9563 terminated because of the reject, the target MUST issue a proper 9564 SCSI command response with CHECK CONDITION as described in Section 9565 11.4.3. In these cases in which a status for the SCSI task was 9566 already sent before the reject, no additional status is required. 9567 If the error is detected while data from the initiator is still 9568 expected (i.e., the command PDU did not contain all the data and 9569 the target has not received a Data-out PDU with the Final bit set 9570 to 1 for the unsolicited data, if any, and all outstanding R2Ts, 9571 if any), the target MUST wait until it receives the last expected 9572 Data-out PDUs with the F bit set to 1 before sending the Response 9573 PDU. 9575 For additional usage semantics of Reject PDU, see Section 7.3 - 9576 "Usage Of Reject PDU in Recovery". 9578 11.17.2. DataSN/R2TSN 9580 This field is only valid if the rejected PDU is a Data/R2T SNACK 9581 and the Reject reason code is "Protocol error" (see SNACK). The 9582 DataSN/R2TSN is the next Data/R2T sequence number that the target 9583 would send for the task, if any. 9585 11.17.3. StatSN, ExpCmdSN and MaxCmdSN 9587 These fields carry their usual values and are not related to the 9588 rejected command. StatSN is advanced after a Reject. 9590 11.17.4. Complete Header of Bad PDU 9592 The target returns the header (not including digest) of the PDU in 9593 error as the data of the response. 9595 11.18. NOP-Out 9597 Byte/ 0 | 1 | 2 | 3 | 9598 / | | | | 9599 |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| 9600 +---------------+---------------+---------------+--------------+ 9601 0|.|I| 0x00 |1| Reserved | 9602 +---------------+---------------+---------------+--------------+ 9603 4|TotalAHSLength | DataSegmentLength | 9604 +---------------+---------------+---------------+--------------+ 9605 8| LUN or Reserved | 9606 + + 9607 12| | 9608 +---------------+---------------+---------------+--------------+ 9609 16| Initiator Task Tag or 0xffffffff | 9610 +---------------+---------------+---------------+--------------+ 9611 20| Target Transfer Tag or 0xffffffff | 9612 +---------------+---------------+---------------+--------------+ 9613 24| CmdSN | 9614 +---------------+---------------+---------------+--------------+ 9615 28| ExpStatSN | 9616 +---------------+---------------+---------------+--------------+ 9617 32/ Reserved / 9618 +/ / 9619 +---------------+---------------+---------------+--------------+ 9620 48| Header-Digest (Optional) | 9621 +---------------+---------------+---------------+--------------+ 9622 / DataSegment - Ping Data (optional) / 9623 +/ / 9624 +---------------+---------------+---------------+--------------+ 9625 | Data-Digest (Optional) | 9626 +---------------+---------------+---------------+--------------+ 9628 A NOP-Out may be used by an initiator as a "ping request" to 9629 verify that a connection/session is still active and all its 9631 components are operational. The NOP-In response is the "ping 9632 echo". 9634 A NOP-Out is also sent by an initiator in response to a NOP-In. 9636 A NOP-Out may also be used to confirm a changed ExpStatSN if 9637 another PDU will not be available for a long time. 9639 Upon receipt of a NOP-In with the Target Transfer Tag set to a 9640 valid value (not the reserved 0xffffffff), the initiator MUST 9641 respond with a NOP-Out. In this case, the NOP-Out Target Transfer 9642 Tag MUST contain a copy of the NOP-In Target Transfer Tag. 9644 11.18.1. Initiator Task Tag 9646 The NOP-Out MUST have the Initiator Task Tag set to a valid value 9647 only if a response in the form of NOP-In is requested (i.e., the 9648 NOP-Out is used as a ping request). Otherwise, the Initiator Task 9649 Tag MUST be set to 0xffffffff. 9651 When a target receives the NOP-Out with a valid Initiator Task 9652 Tag, it MUST respond with a Nop-In Response (see Login and Full 9653 Feature Phase Negotiation). 9655 If the Initiator Task Tag contains 0xffffffff, the I bit MUST be 9656 set to 1 and the CmdSN is not advanced after this PDU is sent. 9658 11.18.2. Target Transfer Tag 9660 A target assigned identifier for the operation. 9662 The NOP-Out MUST only have the Target Transfer Tag set if it is 9663 issued in response to a NOP-In with a valid Target Transfer Tag. 9664 In this case, it copies the Target Transfer Tag from the NOP-In 9665 PDU. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff. 9667 When the Target Transfer Tag is set to a value other than 9668 0xffffffff, the LUN field MUST also be copied from the NOP-In. 9670 11.18.3. Ping Data 9672 Ping data are reflected in the NOP-In Response. The length of the 9673 reflected data are limited to MaxRecvDataSegmentLength. The length 9674 of ping data are indicated by the DataSegmentLength. 0 is a valid 9675 value for the DataSegmentLength and indicates the absence of ping 9676 data. 9678 11.19. NOP-In 9680 Byte/ 0 | 1 | 2 | 3 | 9681 / | | | | 9682 |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| 9683 +---------------+---------------+---------------+--------------+ 9684 0|.|.| 0x20 |1| Reserved | 9685 +---------------+---------------+---------------+--------------+ 9686 4|TotalAHSLength | DataSegmentLength | 9687 +---------------+---------------+---------------+--------------+ 9688 8| LUN or Reserved | 9689 + + 9690 12| | 9691 +---------------+---------------+---------------+--------------+ 9692 16| Initiator Task Tag or 0xffffffff | 9693 +---------------+---------------+---------------+--------------+ 9694 20| Target Transfer Tag or 0xffffffff | 9695 +---------------+---------------+---------------+--------------+ 9696 24| StatSN | 9697 +---------------+---------------+---------------+--------------+ 9698 28| ExpCmdSN | 9699 +---------------+---------------+---------------+--------------+ 9700 32| MaxCmdSN | 9701 +---------------+---------------+---------------+--------------+ 9702 36/ Reserved / 9703 +/ / 9704 +---------------+---------------+---------------+--------------+ 9705 48| Header-Digest (Optional) | 9706 +---------------+---------------+---------------+--------------+ 9707 / DataSegment - Return Ping Data / 9708 +/ / 9709 +---------------+---------------+---------------+--------------+ 9710 | Data-Digest (Optional) | 9711 +---------------+---------------+---------------+--------------+ 9713 NOP-In is either sent by a target as a response to a NOP-Out, as a 9714 "ping" to an initiator, or as a means to carry a changed ExpCmdSN 9715 and/or MaxCmdSN if another PDU will not be available for a long 9716 time (as determined by the target). 9718 When a target receives the NOP-Out with a valid Initiator Task Tag 9719 (not the reserved value 0xffffffff), it MUST respond with a NOP-In 9720 with the same Initiator Task Tag that was provided in the NOP-Out 9721 request. It MUST also duplicate up to the first 9722 MaxRecvDataSegmentLength bytes of the initiator provided Ping 9723 Data. For such a response, the Target Transfer Tag MUST be 9724 0xffffffff. 9726 Otherwise, when a target sends a NOP-In that is not a response to 9727 a Nop-Out received from the initiator, the Initiator Task Tag MUST 9728 be set to 0xffffffff and the Data Segment MUST NOT contain any 9729 data (DataSegmentLength MUST be 0). 9731 11.19.1. Target Transfer Tag 9733 If the target is responding to a NOP-Out, this is set to the 9734 reserved value 0xffffffff. 9736 If the target is sending a NOP-In as a Ping (intending to receive 9737 a corresponding NOP-Out), this field is set to a valid value (not 9738 the reserved 0xffffffff). 9740 If the target is initiating a NOP-In without wanting to receive a 9741 corresponding NOP-Out, this field MUST hold the reserved value of 9742 0xffffffff. 9744 11.19.2. StatSN 9746 The StatSN field will always contain the next StatSN. However, 9747 when the Initiator Task Tag is set to 0xffffffff StatSN for the 9748 connection is not advanced after this PDU is sent. 9750 11.19.3. LUN 9752 A LUN MUST be set to a correct value when the Target Transfer Tag 9753 is valid (not the reserved value 0xffffffff). 9755 12. iSCSI Security Text Keys and Authentication Methods 9757 Only the following keys are used during the SecurityNegotiation 9758 stage of the Login Phase: 9760 SessionType 9762 InitiatorName 9764 TargetName 9766 TargetAddress 9768 InitiatorAlias 9770 TargetAlias 9772 TargetPortalGroupTag 9774 AuthMethod and the keys used by the authentication methods 9775 specified under Section 12.1 along with all of their 9776 associated keys as well as Vendor Specific Authentication 9777 Methods. 9779 Other keys MUST NOT be used. 9781 SessionType, InitiatorName, TargetName, InitiatorAlias, 9782 TargetAlias, and TargetPortalGroupTag are described in Section 13 9783 as they can be used also in the OperationalNegotiation stage. 9785 All security keys have connection-wide applicability. 9787 12.1. AuthMethod 9789 Use: During Login - Security Negotiation 9790 Senders: Initiator and Target 9791 Scope: connection 9793 AuthMethod = 9795 The main item of security negotiation is the authentication method 9796 (AuthMethod). 9798 The authentication methods that can be used (appear in the list- 9799 of-values) are either those listed in the following table or are 9800 vendor-unique methods: 9802 +------------------------------------------------------------+ 9803 | Name | Description | 9804 +------------------------------------------------------------+ 9805 | KRB5 | Kerberos V5 - defined in [RFC4120] | 9806 +------------------------------------------------------------+ 9807 | SRP | Secure Remote Password | 9808 | | defined in [RFC2945] | 9809 +------------------------------------------------------------+ 9810 | CHAP | Challenge Handshake Authentication Protocol| 9811 | | defined in [RFC1994] | 9812 +------------------------------------------------------------+ 9813 | None | No authentication | 9814 +------------------------------------------------------------+ 9816 The AuthMethod selection is followed by an "authentication 9817 exchange" specific to the authentication method selected. 9819 The authentication method proposal may be made by either the 9820 initiator or the target. However the initiator MUST make the first 9821 step specific to the selected authentication method as soon as it 9822 is selected. It follows that if the target makes the 9823 authentication method proposal the initiator sends the first 9824 key(s) of the exchange together with its authentication method 9825 selection. 9827 The authentication exchange authenticates the initiator to the 9828 target, and optionally, the target to the initiator. 9829 Authentication is OPTIONAL to use but MUST be supported by the 9830 target and initiator. 9832 The initiator and target MUST implement CHAP. All other 9833 authentication methods are OPTIONAL. 9835 Private or public extension algorithms MAY also be negotiated for 9836 authentication methods. Whenever a private or public extension 9837 algorithm is part of the default offer (the offer made in absence 9838 of explicit administrative action) the implementer MUST ensure 9839 that CHAP is listed as an alternative in the default offer and 9840 "None" is not part of the default offer. 9842 Extension authentication methods MUST be named using one of the 9843 following two formats: 9845 i) Z-reversed.vendor.dns_name.do_something= 9846 ii) Z<#>= 9848 Authentication methods named using the Z- format are used as 9849 private extensions. Authentication methods named using the Z# 9850 format are used as public extensions that must be registered with 9851 IANA and MUST be described by a standards track RFC, an 9852 experimental RFC, or an informational RFC. 9854 For all of the public or private extension authentication methods, 9855 the method specific keys MUST conform to the format specified in 9856 Section 6.1- "Text Format" for standard-label. 9858 To identify the vendor for private extension authentication 9859 methods, we suggest you use the reversed DNS-name as a prefix to 9860 the proper digest names. 9862 The part of digest-name following Z- and Z# MUST conform to the 9863 format for standard-label specified in Section 6.1 - "Text 9864 Format". 9866 Support for public or private extension authentication methods is 9867 OPTIONAL. 9869 The following subsections define the specific exchanges for each 9870 of the standardized authentication methods. As mentioned earlier 9871 the first step is always done by the initiator. 9873 12.1.1. Kerberos 9875 For KRB5 (Kerberos V5) [RFC4120] and [RFC1964], the initiator MUST 9876 use: 9878 KRB_AP_REQ= 9880 where KRB_AP_REQ is the client message as defined in [RFC4120]. 9882 The default principal name assumed by an iSCSI initiator or target 9883 (prior to any administrative configuration action) MUST be the 9884 iSCSI Initiator Name or iSCSI Target Name respectively, prefixed 9885 by the string "iscsi/". 9887 If the initiator authentication fails, the target MUST respond 9888 with a Login reject with "Authentication Failure" status. 9889 Otherwise, if the initiator has selected the mutual authentication 9890 option (by setting MUTUAL-REQUIRED in the ap-options field of the 9891 KRB_AP_REQ), the target MUST reply with: 9893 KRB_AP_REP= 9895 where KRB_AP_REP is the server's response message as defined in 9896 [RFC4120]. 9898 If mutual authentication was selected and target authentication 9899 fails, the initiator MUST close the connection. 9901 KRB_AP_REQ and KRB_AP_REP are binary-values and their binary 9902 length (not the length of the character string that represents 9903 them in encoded form) MUST NOT exceed 65536 bytes. 9905 12.1.2. Secure Remote Password (SRP) 9907 For SRP [RFC2945], the initiator MUST use: 9909 SRP_U= TargetAuth=Yes /* or TargetAuth=No */ 9911 The target MUST answer with a Login reject with the "Authorization 9912 Failure" status or reply with: 9914 SRP_GROUP= SRP_s= 9916 Where G1,G2... are proposed groups, in order of preference. 9918 The initiator MUST either close the connection or continue with: 9920 SRP_A= SRP_GROUP= 9922 Where G is one of G1,G2... that were proposed by the target. 9924 The target MUST answer with a Login reject with the 9925 "Authentication Failure" status or reply with: 9927 SRP_B= 9929 The initiator MUST close the connection or continue with: 9931 SRP_M= 9933 If the initiator authentication fails, the target MUST answer with 9934 a Login reject with "Authentication Failure" status. Otherwise, if 9935 the initiator sent TargetAuth=Yes in the first message (requiring 9936 target authentication), the target MUST reply with: 9938 SRP_HM= 9940 If the target authentication fails, the initiator MUST close the 9941 connection. 9943 Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] 9944 (using the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn 9945 stands for G1,G2...) are identifiers of SRP groups specified in 9946 [RFC3723]. G, Gn, and U are text strings, s,A,B,M, and H(A | M | 9947 K) are binary-values. The length of s,A,B,M and H(A | M | K) in 9948 binary form (not the length of the character string that 9949 represents them in encoded form) MUST NOT exceed 1024 bytes. 9951 For the SRP_GROUP, all the groups specified in [RFC3723] up to 9952 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be 9953 supported by initiators and targets. To guarantee 9954 interoperability, targets MUST always offer "SRP-1536" as one of 9955 the proposed groups. 9957 12.1.3. Challenge Handshake Authentication Protocol (CHAP) 9959 For CHAP [RFC1994], the initiator MUST use: 9961 CHAP_A= 9963 Where A1,A2... are proposed algorithms, in order of preference. 9965 The target MUST answer with a Login reject with the 9966 "Authentication Failure" status or reply with: 9968 CHAP_A= CHAP_I= CHAP_C= 9970 Where A is one of A1,A2... that were proposed by the initiator. 9972 The initiator MUST continue with: 9974 CHAP_N= CHAP_R= 9976 or, if it requires target authentication, with: 9978 CHAP_N= CHAP_R= CHAP_I= CHAP_C= 9980 If the initiator authentication fails, the target MUST answer with 9981 a Login reject with "Authentication Failure" status. Otherwise, if 9982 the initiator required target authentication, the target MUST 9983 either answer with a Login reject with "Authentication Failure" or 9984 reply with: 9986 CHAP_N= CHAP_R= 9988 If target authentication fails, the initiator MUST close the 9989 connection. 9991 Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, 9992 Algorithm, Identifier, Challenge, and Response as defined in 9993 [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C 9994 and R are binary-values and their binary length (not the length of 9995 the character string that represents them in encoded form) MUST 9996 NOT exceed 1024 bytes. 9998 For the Algorithm, as stated in [RFC1994], one value is required 9999 to be implemented: 10001 5 (CHAP with MD5) 10003 To guarantee interoperability, initiators MUST always offer it as 10004 one of the proposed algorithms. 10006 13. Login/Text Operational Text Keys 10008 Some session specific parameters MUST only be carried on the 10009 leading connection and cannot be changed after the leading 10010 connection login (e.g., MaxConnections, the maximum number of 10011 connections). This holds for a single connection session with 10012 regard to connection restart. The keys that fall into this 10013 category have the use: LO (Leading Only). 10015 Keys that can only be used during login have the use: IO 10016 (initialize only), while those that can be used in both the Login 10017 Phase and Full Feature Phase have the use: ALL. 10019 Keys that can only be used during Full Feature Phase use FFPO 10020 (Full Feature Phase only). 10022 Keys marked as Any-Stage may also appear in the 10023 SecurityNegotiation stage while all other keys described in this 10024 chapter are operational keys. 10026 Keys that do not require an answer are marked as Declarative. 10028 Key scope is indicated as session-wide (SW) or connection-only 10029 (CO). 10031 Result function, wherever mentioned, states the function that can 10032 be applied to check the validity of the responder selection. 10033 Minimum means that the selected value cannot exceed the offered 10034 value. Maximum means that the selected value cannot be lower than 10035 the offered value. AND means that the selected value must be a 10036 possible result of a Boolean "and" function with an arbitrary 10037 Boolean value (e.g., if the offered value is No the selected value 10038 must be No). OR means that the selected value must be a possible 10039 result of a Boolean "or" function with an arbitrary Boolean value 10040 (e.g., if the offered value is Yes the selected value must be 10041 Yes). 10043 13.1. HeaderDigest and DataDigest 10045 Use: IO 10046 Senders: Initiator and Target 10047 Scope: CO 10048 HeaderDigest = 10049 DataDigest = 10051 Default is None for both HeaderDigest and DataDigest. 10053 Digests enable the checking of end-to-end, non-cryptographic data 10054 integrity beyond the integrity checks provided by the link layers 10055 and the covering of the whole communication path including all 10056 elements that may change the network level PDUs such as routers, 10057 switches, and proxies. 10059 The following table lists cyclic integrity checksums that can be 10060 negotiated for the digests and that MUST be implemented by every 10061 iSCSI initiator and target. These digest options only have error 10062 detection significance. 10064 +---------------------------------------------+ 10065 | Name | Description | Generator | 10066 +---------------------------------------------+ 10067 | CRC32C | 32 bit CRC |0x11edc6f41| 10068 +---------------------------------------------+ 10069 | None | no digest | 10070 +---------------------------------------------+ 10072 The generator polynomial for this digest is given in hex-notation 10073 (e.g., 0x3b stands for 0011 1011 and the polynomial is 10074 x**5+X**4+x**3+x+1). 10076 When the Initiator and Target agree on a digest, this digest MUST 10077 be used for every PDU in Full Feature Phase. 10079 Padding bytes, when present in a segment covered by a CRC, SHOULD 10080 be set to 0 and are included in the CRC. 10082 The CRC MUST be calculated by a method that produces the same 10083 results as the following process: 10085 - The PDU bits are considered as the coefficients of a 10086 polynomial M(x) of degree n-1; bit 7 of the lowest numbered 10087 byte is considered the most significant bit (x^n-1), 10089 followed by bit 6 of the lowest numbered byte through bit 0 10090 of the highest numbered byte (x^0). 10092 - The most significant 32 bits are complemented. 10094 - The polynomial is multiplied by x^32 then divided by G(x). 10095 The generator polynomial produces a remainder R(x) of degree 10096 <= 31. 10098 - The coefficients of R(x) are considered a 32 bit sequence. 10100 - The bit sequence is complemented and the result is the CRC. 10102 - The CRC bits are mapped into the digest word. The x^31 10103 coefficient in bit 7 of the lowest numbered byte of the 10104 digest continuing through to the byte up to the x^24 10105 coefficient in bit 0 of the lowest numbered byte, continuing 10106 with the x^23 coefficient in bit 7 of next byte through x^0 10107 in bit 0 of the highest numbered byte. 10109 - Computing the CRC over any segment (data or header) extended 10110 to include the CRC built using the generator 0x11edc6f41 10111 will always get the value 0x1c2d19ed as its final remainder 10112 (R(x)). This value is given here in its polynomial form 10113 (i.e., not mapped as the digest word). 10115 For a discussion about selection criteria for the CRC, see 10116 [RFC3385]. For a detailed analysis of the iSCSI polynomial, see 10117 [Castagnoli93]. 10119 Private or public extension algorithms MAY also be negotiated for 10120 digests. Whenever a private or public digest extension algorithm 10121 is part of the default offer (the offer made in absence of 10122 explicit administrative action) the implementer MUST ensure that 10123 CRC32C is listed as an alternative in the default offer and "None" 10124 is not part of the default offer. 10126 Extension digest algorithms MUST be named using one of the 10127 following two formats: 10129 iii) Y-reversed.vendor.dns_name.do_something= 10130 iv) Y<#>= 10132 Digests named using the Y- format are used for private purposes 10133 (unregistered). Digests named using the Y# format (public 10134 extension) must be registered with IANA and MUST be described by a 10135 standards track RFC, an experimental RFC, or an informational RFC. 10137 For private extension digests, to identify the vendor, we suggest 10138 you use the reversed DNS-name as a prefix to the proper digest 10139 names. 10141 The part of digest-name following Y- and Y# MUST conform to the 10142 format for standard-label specified in Section 6.1. 10144 Support for public or private extension digests is OPTIONAL. 10146 13.2. MaxConnections 10148 Use: LO 10149 Senders: Initiator and Target 10150 Scope: SW 10151 Irrelevant when: SessionType=Discovery 10153 MaxConnections= 10155 Default is 1. 10156 Result function is Minimum. 10158 Initiator and target negotiate the maximum number of connections 10159 requested/acceptable. 10161 13.3. SendTargets 10163 Use: FFPO 10164 Senders: Initiator 10165 Scope: SW 10167 For a complete description, see Appendix D. - "SendTargets 10168 Operation". 10170 13.4. TargetName 10172 Use: IO by initiator, FFPO by target - only as response to a 10173 SendTargets, Declarative, Any-Stage 10174 Senders: Initiator and Target 10175 Scope: SW 10177 TargetName= 10179 Examples: 10181 TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 10183 TargetName=eui.020000023B040506 10185 TargetName=naa.62004567BA64678D0123456789ABCDEF 10187 The initiator of the TCP connection MUST provide this key to the 10188 remote endpoint in the first login request if the initiator is not 10189 establishing a discovery session. The iSCSI Target Name specifies 10190 the worldwide unique name of the target. 10192 The TargetName key may also be returned by the "SendTargets" text 10193 request (which is its only use when issued by a target). 10195 TargetName MUST NOT be redeclared within the login phase. 10197 13.5. InitiatorName 10199 Use: IO, Declarative, Any-Stage 10200 Senders: Initiator 10201 Scope: SW 10203 InitiatorName= 10205 Examples: 10207 InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345 10209 InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90 10210 InitiatorName=naa.52004567BA64678D 10212 The initiator of the TCP connection MUST provide this key to the 10213 remote endpoint at the first Login of the Login Phase for every 10214 connection. The InitiatorName key enables the initiator to 10215 identify itself to the remote endpoint. 10217 InitiatorName MUST NOT be redeclared within the login phase. 10219 13.6. TargetAlias 10221 Use: ALL, Declarative, Any-Stage 10222 Senders: Target 10223 Scope: SW 10225 TargetAlias= 10227 Examples: 10229 TargetAlias=Bob-s Disk 10231 TargetAlias=Database Server 1 Log Disk 10233 TargetAlias=Web Server 3 Disk 20 10235 If a target has been configured with a human-readable name or 10236 description, this name SHOULD be communicated to the initiator 10237 during a Login Response PDU if SessionType=Normal (see 13.21). 10238 This string is not used as an identifier, nor is it meant to be 10239 used for authentication or authorization decisions. It can be 10240 displayed by the initiator's user interface in a list of targets 10241 to which it is connected. 10243 13.7. InitiatorAlias 10245 Use: ALL, Declarative, Any-Stage 10246 Senders: Initiator 10247 Scope: SW 10249 InitiatorAlias= 10250 Examples: 10252 InitiatorAlias=Web Server 4 10254 InitiatorAlias=spyalley.nsa.gov 10256 InitiatorAlias=Exchange Server 10258 If an initiator has been configured with a human-readable name or 10259 description, it SHOULD be communicated to the target during a 10260 Login Request PDU. If not, the host name can be used instead. This 10261 string is not used as an identifier, nor is meant to be used for 10262 authentication or authorization decisions. It can be displayed by 10263 the target's user interface in a list of initiators to which it is 10264 connected. 10266 13.8. TargetAddress 10268 Use: ALL, Declarative, Any-Stage 10269 Senders: Target 10270 Scope: SW 10272 TargetAddress=domainname[:port][,portal-group-tag] 10274 The domainname can be specified as either a DNS host name, a 10275 dotted-decimal IPv4 address, or a bracketed IPv6 address as 10276 specified in [RFC3986]. 10278 If the TCP port is not specified, it is assumed to be the IANA- 10279 assigned default port for iSCSI (see Section 14 -"IANA 10280 Considerations"). 10282 If the TargetAddress is returned as the result of a redirect 10283 status in a login response, the comma and portal group tag MUST be 10284 omitted. 10286 If the TargetAddress is returned within a SendTargets response, 10287 the portal group tag MUST be included. 10289 Examples: 10291 TargetAddress=10.0.0.1:5003,1 10293 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 10295 TargetAddress=[1080::8:800:200C:417A]:5003,1 10297 TargetAddress=computingcenter.example.com,23 10299 Use of the portal-group-tag is described in Appendix D. - 10300 "SendTargets Operation". The formats for the port and portal- 10301 group-tag are the same as the one specified in 10302 TargetPortalGroupTag. 10304 13.9. TargetPortalGroupTag 10306 Use: IO by target, Declarative, Any-Stage 10307 Senders: Target 10308 Scope: SW 10310 TargetPortalGroupTag=<16-bit-binary-value> 10312 Examples: 10313 TargetPortalGroupTag=1 10315 The target portal group tag is a 16-bit binary-value that uniquely 10316 identifies a portal group within an iSCSI target node. This key 10317 carries the value of the tag of the portal group that is servicing 10318 the Login request. The iSCSI target returns this key to the 10319 initiator in the Login Response PDU to the first Login Request PDU 10320 that has the C bit set to 0 when TargetName is given by the 10321 initiator. 10323 [SAM2] and [SAM3] specifications note in their informative text 10324 that TPGT value should be non-zero, note that it is incorrect. A 10325 zero value is allowed as a legal value for TPGT. This discrepancy 10326 currently stands corrected in [SAM4]. 10328 For the complete usage expectations of this key see Section 6.3. 10330 13.10. InitialR2T 10332 Use: LO 10333 Senders: Initiator and Target 10334 Scope: SW 10335 Irrelevant when: SessionType=Discovery 10337 InitialR2T= 10339 Examples: 10341 I->InitialR2T=No 10343 T->InitialR2T=No 10345 Default is Yes. 10346 Result function is OR. 10348 The InitialR2T key is used to turn off the default use of R2T for 10349 unidirectional and the output part of bidirectional commands, thus 10350 allowing an initiator to start sending data to a target as if it 10351 has received an initial R2T with Buffer Offset=Immediate Data 10352 Length and Desired Data Transfer Length=(min(FirstBurstLength, 10353 Expected Data Transfer Length) - Received Immediate Data Length). 10355 The default action is that R2T is required, unless both the 10356 initiator and the target send this key-pair attribute specifying 10357 InitialR2T=No. Only the first outgoing data burst (immediate data 10358 and/or separate PDUs) can be sent unsolicited (i.e., not requiring 10359 an explicit R2T). 10361 13.11. ImmediateData 10363 Use: LO 10364 Senders: Initiator and Target 10365 Scope: SW 10366 Irrelevant when: SessionType=Discovery 10368 ImmediateData= 10370 Default is Yes. 10372 Result function is AND. 10374 The initiator and target negotiate support for immediate data. To 10375 turn immediate data off, the initiator or target must state its 10376 desire to do so. ImmediateData can be turned on if both the 10377 initiator and target have ImmediateData=Yes. 10379 If ImmediateData is set to Yes and InitialR2T is set to Yes 10380 (default), then only immediate data are accepted in the first 10381 burst. 10383 If ImmediateData is set to No and InitialR2T is set to Yes, then 10384 the initiator MUST NOT send unsolicited data and the target MUST 10385 reject unsolicited data with the corresponding response code. 10387 If ImmediateData is set to No and InitialR2T is set to No, then 10388 the initiator MUST NOT send unsolicited immediate data, but MAY 10389 send one unsolicited burst of Data-OUT PDUs. 10391 If ImmediateData is set to Yes and InitialR2T is set to No, then 10392 the initiator MAY send unsolicited immediate data and/or one 10393 unsolicited burst of Data-OUT PDUs. 10395 The following table is a summary of unsolicited data options: 10397 +----------+-------------+------------------+--------------+ 10398 |InitialR2T|ImmediateData| Unsolicited |Immediate Data| 10399 | | | Data Out PDUs | | 10400 +----------+-------------+------------------+--------------+ 10401 | No | No | Yes | No | 10402 +----------+-------------+------------------+--------------+ 10403 | No | Yes | Yes | Yes | 10404 +----------+-------------+------------------+--------------+ 10405 | Yes | No | No | No | 10406 +----------+-------------+------------------+--------------+ 10407 | Yes | Yes | No | Yes | 10408 +----------+-------------+------------------+--------------+ 10410 13.12. MaxRecvDataSegmentLength 10412 Use: ALL, Declarative 10413 Senders: Initiator and Target 10414 Scope: CO 10416 MaxRecvDataSegmentLength= 10418 Default is 8192 bytes. 10420 The initiator or target declares the maximum data segment length 10421 in bytes it can receive in an iSCSI PDU. 10423 The transmitter (initiator or target) is required to send PDUs 10424 with a data segment that does not exceed MaxRecvDataSegmentLength 10425 of the receiver. 10427 A target receiver is additionally limited by MaxBurstLength for 10428 solicited data and FirstBurstLength for unsolicited data. An 10429 initiator MUST NOT send solicited PDUs exceeding MaxBurstLength 10430 nor unsolicited PDUs exceeding FirstBurstLength (or 10431 FirstBurstLength-Immediate Data Length if immediate data were 10432 sent). 10434 13.13. MaxBurstLength 10436 Use: LO 10437 Senders: Initiator and Target 10438 Scope: SW 10439 Irrelevant when: SessionType=Discovery 10441 MaxBurstLength= 10443 Default is 262144 (256 Kbytes). 10444 Result function is Minimum. 10446 The initiator and target negotiate maximum SCSI data payload in 10447 bytes in a Data-In or a solicited Data-Out iSCSI sequence. A 10448 sequence consists of one or more consecutive Data-In or Data-Out 10449 PDUs that end with a Data-In or Data-Out PDU with the F bit set to 10450 one. 10452 13.14. FirstBurstLength 10454 Use: LO 10455 Senders: Initiator and Target 10456 Scope: SW 10457 Irrelevant when: SessionType=Discovery 10458 Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) 10460 FirstBurstLength= 10462 Default is 65536 (64 Kbytes). 10463 Result function is Minimum. 10465 The initiator and target negotiate the maximum amount in bytes of 10466 unsolicited data an iSCSI initiator may send to the target during 10467 the execution of a single SCSI command. This covers the immediate 10468 data (if any) and the sequence of unsolicited Data-Out PDUs (if 10469 any) that follow the command. 10471 FirstBurstLength MUST NOT exceed MaxBurstLength. 10473 13.15. DefaultTime2Wait 10475 Use: LO 10476 Senders: Initiator and Target 10477 Scope: SW 10479 DefaultTime2Wait= 10481 Default is 2. 10482 Result function is Maximum. 10484 The initiator and target negotiate the minimum time, in seconds, 10485 to wait before attempting an explicit/implicit logout or an active 10486 task reassignment after an unexpected connection termination or a 10487 connection reset. 10489 A value of 0 indicates that logout or active task reassignment can 10490 be attempted immediately. 10492 13.16. DefaultTime2Retain 10494 Use: LO 10495 Senders: Initiator and Target 10496 Scope: SW 10497 DefaultTime2Retain= 10499 Default is 20. 10500 Result function is Minimum. 10502 The initiator and target negotiate the maximum time, in seconds 10503 after an initial wait (Time2Wait), before which an active task 10504 reassignment is still possible after an unexpected connection 10505 termination or a connection reset. 10507 This value is also the session state timeout if the connection in 10508 question is the last LOGGED_IN connection in the session. 10510 A value of 0 indicates that connection/task state is immediately 10511 discarded by the target. 10513 13.17. MaxOutstandingR2T 10515 Use: LO 10516 Senders: Initiator and Target 10517 Scope: SW 10519 MaxOutstandingR2T= 10520 Irrelevant when: SessionType=Discovery 10522 Default is 1. 10523 Result function is Minimum. 10525 Initiator and target negotiate the maximum number of outstanding 10526 R2Ts per task, excluding any implied initial R2T that might be 10527 part of that task. An R2T is considered outstanding until the last 10528 data PDU (with the F bit set to 1) is transferred, or a sequence 10529 reception timeout (Section 7.1.4.1) is encountered for that data 10530 sequence. 10532 13.18. DataPDUInOrder 10534 Use: LO 10535 Senders: Initiator and Target 10536 Scope: SW 10537 Irrelevant when: SessionType=Discovery 10538 DataPDUInOrder= 10540 Default is Yes. 10541 Result function is OR. 10543 No is used by iSCSI to indicate that the data PDUs within 10544 sequences can be in any order. Yes is used to indicate that data 10545 PDUs within sequences have to be at continuously increasing 10546 addresses and overlays are forbidden. 10548 13.19. DataSequenceInOrder 10550 Use: LO 10551 Senders: Initiator and Target 10552 Scope: SW 10553 Irrelevant when: SessionType=Discovery 10555 DataSequenceInOrder= 10557 Default is Yes. 10558 Result function is OR. 10560 A Data Sequence is a sequence of Data-In or Data-Out PDUs that end 10561 with a Data-In or Data-Out PDU with the F bit set to one. A Data- 10562 out sequence is sent either unsolicited or in response to an R2T. 10563 Sequences cover an offset-range. 10565 If DataSequenceInOrder is set to No, Data PDU sequences may be 10566 transferred in any order. 10568 If DataSequenceInOrder is set to Yes, Data Sequences MUST be 10569 transferred using continuously non-decreasing sequence offsets 10570 (R2T buffer offset for writes, or the smallest SCSI Data-In buffer 10571 offset within a read data sequence). 10573 If DataSequenceInOrder is set to Yes, a target may retry at most 10574 the last R2T, and an initiator may at most request retransmission 10575 for the last read data sequence. For this reason, if 10576 ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes 10577 then MaxOustandingR2T MUST be set to 1. 10579 13.20. ErrorRecoveryLevel 10581 Use: LO 10582 Senders: Initiator and Target 10583 Scope: SW 10585 ErrorRecoveryLevel= 10587 Default is 0. 10588 Result function is Minimum. 10590 The initiator and target negotiate the recovery level supported. 10592 Recovery levels represent a combination of recovery capabilities. 10593 Each recovery level includes all the capabilities of the lower 10594 recovery levels and adds some new ones to them. 10596 In the description of recovery mechanisms, certain recovery 10597 classes are specified. Section 7.1.5 describes the mapping between 10598 the classes and the levels. 10600 13.21. SessionType 10602 Use: LO, Declarative, Any-Stage 10603 Senders: Initiator 10604 Scope: SW 10606 SessionType= 10608 Default is Normal. 10610 The Initiator indicates the type of session it wants to create. 10611 The target can either accept it or reject it. 10613 A Discovery session indicates to the Target that the only purpose 10614 of this Session is discovery. The only requests a target accepts 10615 in this type of session are a text request with a SendTargets key 10616 and a logout request with reason "close the session". 10618 The Discovery session implies MaxConnections = 1 and overrides 10619 both the default and an explicit setting. As section 7.4.1 10621 states, ErrorRecoveryLevel MUST be 0 (zero) for Discovery 10622 sessions. 10624 Depending on the type of the session, a target may decide on 10625 resources to allocate and the security to enforce, etc. for the 10626 session. If the SessionType key is thus going to be offered as 10627 "Discovery", it SHOULD be offered in the initial Login request by 10628 the initiator. 10630 13.22. The Private or Public Extension Key Format 10632 Use: ALL 10633 Senders: Initiator and Target 10634 Scope: specific key dependent 10636 X-reversed.vendor.dns_name.do_something= 10638 or 10640 X<#>= 10642 Keys with this format are used for public or private extension 10643 purposes. These keys always start with X- if unregistered with 10644 IANA (private) or X# if registered with IANA (public). 10646 For unregistered keys, to identify the vendor, we suggest you use 10647 the reversed DNS-name as a prefix to the key-proper. 10649 The part of key-name following X- and X# MUST conform to the 10650 format for key-name specified in Section 6.1-"Text Format". 10652 For IANA registered keys the string following X# must be 10653 registered with IANA and the use of the key MUST be described by a 10654 standards track RFC, an experimental RFC, or an informational RFC. 10656 Vendor specific keys MUST ONLY be used in normal sessions. 10658 Support for public or private extension keys is OPTIONAL. 10660 13.23. Task Reporting 10662 Use: LO 10663 Senders: Initiator and Target 10664 Scope: SW 10665 Irrelevant when: SessionType=Discovery 10666 TaskReporting= 10668 Default is RFC3720. 10669 Result function is AND. 10671 This key is used to negotiate the task completion reporting 10672 semantics from the SCSI target. The following table describes the 10673 semantics that an iSCSI target MUST support for respective 10674 negotiated key values. Whenever this key is negotiated, at least 10675 the RFC3720 and ResponseFence values MUST be offered as options by 10676 the negotiation originator. 10677 +--------------+------------------------------------------+ 10678 | Name | Description | 10679 +--------------+------------------------------------------+ 10680 | RFC3720 | RFC 3720-compliant semantics. Response | 10681 | | fencing is not guaranteed and fast | 10682 | | completion of multi-task aborting is not | 10683 | | supported | 10684 +--------------+------------------------------------------+ 10685 | ResponseFence| Response Fence (section 4.2.2.3.3) | 10686 | | semantics MUST be supported in reporting | 10687 | | task completions | 10688 +--------------+------------------------------------------+ 10689 | FastAbort | Updated fast multi-task abort semantics | 10690 | | defined in Section 4.2.3.4 MUST be | 10691 | | supported. Support for Response Fence is | 10692 | | implied -- i.e., (Section 4.2.2.3.3) | 10693 | | semantics MUST be supported as well | 10694 +--------------+------------------------------------------+ 10695 When TaskReporting is not negotiated to FastAbort, the standard 10696 multi-task abort semantics in Section 4.2.3.3 MUST be used. 10698 13.24. iSCSIProtocolLevel Negotiation 10700 The iSCSIProtocolLevel associated with this document is "1". As a 10701 responder or an originator in a negotiation of this key, an iSCSI 10702 implementation compliant to this document alone, without any 10703 future protocol extensions, MUST use this value as defined by the 10704 [iSCSI-SAM] document. 10706 13.25. Obsoleted Keys 10708 This document obsoletes the following keys defined in [RFC3720]: 10709 IFMarker, OFMarker, OFMarkInt, IFMarkInt. However, iSCSI 10710 implementations compliant to this document may still receive these 10711 obsoleted keys - i.e. in a responder role - in a text negotiation. 10713 When IFMarker or OFMarker key is received, a compliant iSCSI 10714 implementation SHOULD respond with the constant "Reject" value. 10715 The implementation MAY alternatively respond with a "No" value. 10716 However, the implementation MUST NOT respond with a 10717 "NotUnderstood" value for either of these keys. 10719 When IFMarkInt or OFMarkInt key is received, a compliant iSCSI 10720 implementation MUST respond with the constant "Reject" value. 10721 The implementation MUST NOT respond with a "NotUnderstood" value 10722 for either of these keys. 10724 13.26. X#NodeArchitecture 10726 13.26.1. Definition 10728 Use: LO, Declarative 10729 Senders: Initiator and Target 10730 Scope: SW 10732 X#NodeArchitecture= 10734 Default is none. 10736 Examples: 10737 X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a 10738 X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 10739 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 10741 This document does not define the structure or content of the list 10742 of values. 10744 The initiator or target declares the details of its iSCSI node 10745 architecture to the remote endpoint. These details may include, 10746 but are not limited to, iSCSI vendor software, firmware, or 10748 hardware versions, the OS version, or hardware architecture. This 10749 key may be declared on a Discovery session or a Normal session. 10751 The length of the key value (total length of the list-of-values) 10752 MUST NOT be greater than 255 bytes. 10754 X#NodeArchitecture MUST NOT be redeclared during the login phase. 10756 13.26.2. Implementation Requirements 10758 Functional behavior of the iSCSI node (this includes the iSCSI 10759 protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT 10760 depend on the presence, absence, or content of the 10761 X#NodeArchitecture key. The key MUST NOT be used by iSCSI nodes 10762 for interoperability, or exclusion of other nodes. To ensure 10763 proper use, key values SHOULD be set by the node itself, and there 10764 SHOULD NOT be provisions for the key values to contain user- 10765 defined text. 10767 Nodes implementing this key MUST choose one of the following 10768 implementation options: 10770 only transmit the key, 10771 only log the key values received from other nodes, or 10772 both transmit and log the key values. 10773 Each node choosing to implement transmission of the key values 10774 MUST be prepared to handle the response of iSCSI Nodes that do not 10775 understand the key. 10777 Nodes that implement transmission and/or logging of the key values 10778 may also implement administrative mechanisms that disable and/or 10779 change the logging and key transmission detail (see Section 9.4 - 10780 "Security Considerations for the X#NodeArchitecture Key"). Thus, a 10781 valid behavior for this key may be that a node is completely 10782 silent (the node does not transmit any key value, and simply 10783 discards any key values it receives without issuing a 10784 NotUnderstood response). 10786 14. IANA Considerations 10788 The well-known TCP port number for iSCSI connections assigned by 10789 IANA is 3260 and this is the default iSCSI port. Implementations 10790 needing a system TCP port number may use port 860, the port 10791 assigned by IANA as the iSCSI system port; however in order to use 10792 port 860, it MUST be explicitly specified - implementations MUST 10793 NOT default to use of port 860, as 3260 is the only allowed 10794 default. 10796 [RFC3720] instructs that three text key registries be set up, one 10797 for each of Extension keys, authentication methods, or digest keys 10798 - with the stipulation that the key prefix (X#, Y# or Z#) be not 10799 recorded. However, [RFC4850] indicates that the key prefix was 10800 recorded by IANA as part of the key name. Consequently, storm 10801 working group (which published this document) instructs IANA that: 10802 (i) It maintain a single text key registry for iSCSI keys, and, 10803 (ii) MUST always record the key prefix as part of the recorded 10804 string 10806 This is being done with the intent to not have to change what IANA 10807 already did while publishing [RFC4850]. 10809 All the other IANA considerations stated in [RFC3720] and 10810 [RFC5048] remain unchanged. 10812 This document obsoletes the SPKM1 and SPKM2 key values for the 10813 AuthMethod text key. Consequently, the SPKM_ text key prefix MUST 10814 be treated as obsolete and be not reused. 10816 References 10818 Normative References 10820 [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", 10821 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 10823 [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling 10824 Interface (FC-FS). 10826 [iSCSI-SAM] Knight, F., Chadalapaka, M., "Internet Small 10827 Computer Systems Interface (iSCSI) SCSI Architecture 10828 Features Update", draft-ietf-storm-iscsi-sam-05.txt (work in 10829 progress), December 2011 10831 [OUI] "IEEE OUI and Company_Id Assignments", 10832 http://standards.ieee.org/regauth/oui 10834 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 10835 June 1996. 10837 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", 10838 August 1996. 10840 [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication 10841 Protocol (CHAP)", August 1996. 10843 [RFC2045] N. Borenstein, N. Freed, "MIME (Multipurpose 10844 Internet Mail Extensions) Part One: Mechanisms for 10845 Specifying and Describing the Format of Internet Message 10846 Bodies", November 1996. 10848 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 10849 Requirement Levels", BCP 14, March 1997. 10851 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 10852 within ESP and AH", November 1998. 10854 [RFC2451] R. Pereira, R. Adams "The ESP CBC-Mode Cipher 10855 Algorithms". 10857 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange 10858 System", September 2000. 10860 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 10861 Internationalized Strings ("stringprep")", RFC 3454, 10862 December 2002. 10864 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 10865 Algorithm and Its Use With IPsec", RFC 3566, September 2003. 10867 [RFC3629] Yergeau, F., "UTF-8, a Transformation Format of ISO 10868 10646", RFC 3629, November 2003 10870 [RFC3686] Housley, R., "Using Advanced Encryption Standard 10871 (AES) Counter Mode with IPsec Encapsulating Security Payload 10872 (ESP)", RFC 3686, January 2004. 10874 [RFC3722] Bakke, M., "String Profile for Internet Small 10875 Computer Systems Interface (iSCSI) Names", RFC 3722, March 10876 2004. 10878 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. 10879 Travostino, "Securing Block Storage Protocols over IP", RFC 10880 3723, March 2004. 10882 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter "Uniform 10883 Resource Identifier (URI): Generic Syntax", January 2005. 10885 [RFC4106] J. Viega, D. McGrew, "The Use of Galois/Counter Mode 10886 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 10887 4106, June 2005. 10889 [RFC4120] Neuman, C., Yu, T., Hartman, S., Raeburn, K, "The 10890 Kerberos Network Authentication Service (V5)", RFC 4120, 10891 July 2005. 10893 [RFC4171] J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. 10894 Souza, "Internet Storage Name Service (iSNS)", September 10895 2005. 10897 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10898 Architecture", February 2006. 10900 [RFC4301] S. Kent, K.Seo, "Security Architecture for the 10901 Internet Protocol", December 2005. 10903 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 10904 RFC 4303, December 2005 10906 [RFC4543] D. McGrew, J. Viega, "The Use of Galois Message 10907 Authentication Code (GMAC) in IPsec ESP and AH", May 2006 10909 [RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet 10910 Key Exchange Protocol Version 2 (IKEv2) ", RFC 5996, 10911 September 2010. 10913 [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). 10915 [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). 10917 [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). 10919 [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC). 10921 [SPC3] T10/1416-D, SCSI Primary Commands-3. 10923 [UML] ISO/IEC 19501, Unified Modeling Language 10924 Specification Version 1.4.2. 10926 [UNICODE] Unicode Standard Annex #15, "Unicode Normalization 10927 Forms", http://www.unicode.org/unicode/reports/tr15 10929 Informative References 10931 [RFC1737] K. Sollins, L. Masinter "Functional Requirements for 10932 Uniform Resource Names". 10934 [IB] InfiniBand{tm} Architecture Specification, Vol. 1, 10935 Rel.1.0.a, InfiniBand 10936 TradezAssociation(http://www.infinibandta.org). 10938 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman 10939 "Optimization of Cyclic Redundancy-Check Codes with 24 and 10940 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, 10941 No. 6, June 1993. 10943 [CRC] ISO 3309, High-Level Data Link Control (CRC 32). 10945 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 10946 Internet Protocol ", November 1998. 10948 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security 10949 Payload (ESP)", November 1998. 10951 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange 10952 (IKE)", November 1998. 10954 [RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. 10955 Cavanna, "Internet Protocol Small Computer System Interface 10956 (iSCSI) Cyclic Redundancy Check (CRC)/Checksum 10957 Considerations", RFC 3385, September 2002. 10959 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 10960 M., and E. Zeidner, "Internet Small Computer Systems 10961 Interface (iSCSI)", RFC 3720, April 2004. 10963 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. 10964 and M. Krueger, "Internet Small Computer Systems Interface 10965 (iSCSI) Naming and Discovery", RFC 3721, March 2004 10967 [RFC3783] M. Chadalapaka, R. Elliott, "Small Computer Systems 10968 Interface (SCSI) Command Ordering Considerations with 10969 iSCSI", RFC 3783, May 2004. 10971 [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, 10972 "Remote Direct Memory Access (RDMA) over IP Problem 10973 Statement", RFC 4297, October 2004 10975 [RFC4850] Wysochanski, D., "Declarative Public Extension Key 10976 for Internet Small Computer Systems Interface (iSCSI) Node 10977 Architecture", RFC 4850, April 2007. 10979 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., 10980 Shah, H., and P. Thaler, "Internet Small Computer System 10981 Interface (iSCSI) Extensions for Remote Direct Memory Access 10982 (RDMA)", RFC 5046, October 2007 10984 [RFC5048] Chadalapaka, M., "Internet Small Computer Systems 10985 Interface (iSCSI) Corrections and Clarifications", RFC 5048, 10986 October 2007. 10988 [SAS] INCITS 376-2003, Serial Attached SCSI (SAS). 10990 [SRP] INCITS 365-2002, SCSI RDMA Protocol (SRP). 10992 Appendix A. Examples 10994 Read Operation Example 10996 +------------------+-----------------------+---------------------+ 10997 |Initiator Function| PDU Type | Target Function | 10998 +------------------+-----------------------+---------------------+ 10999 | Command request |SCSI Command (READ)>>> | | 11000 | (read) | | | 11001 +------------------+-----------------------+---------------------+ 11002 | | |Prepare Data Transfer| 11003 +------------------+-----------------------+---------------------+ 11004 | Receive Data | <<< SCSI Data-in | Send Data | 11005 +------------------+-----------------------+---------------------+ 11006 | Receive Data | <<< SCSI Data-in | Send Data | 11007 +------------------+-----------------------+---------------------+ 11008 | Receive Data | <<< SCSI Data-in | Send Data | 11009 +------------------+-----------------------+---------------------+ 11010 | | <<< SCSI Response |Send Status and Sense| 11011 +------------------+-----------------------+---------------------+ 11012 | Command Complete | | | 11013 +------------------+-----------------------+---------------------+ 11015 Write Operation Example 11017 +------------------+-----------------------+---------------------+ 11018 |Initiator Function| PDU Type | Target Function | 11019 +------------------+-----------------------+---------------------+ 11020 | Command request |SCSI Command (WRITE)>>>| Receive command | 11021 | (write) | | and queue it | 11022 +------------------+-----------------------+---------------------+ 11023 | | | Process old commands| 11024 +------------------+-----------------------+---------------------+ 11025 | | | Ready to process | 11026 | | <<< R2T | WRITE command | 11027 +------------------+-----------------------+---------------------+ 11028 | Send Data | SCSI Data-out >>> | Receive Data | 11029 +------------------+-----------------------+---------------------+ 11030 | | <<< R2T | Ready for data | 11031 +------------------+-----------------------+---------------------+ 11032 | | <<< R2T | Ready for data | 11033 +------------------+-----------------------+---------------------+ 11034 | Send Data | SCSI Data-out >>> | Receive Data | 11035 +------------------+-----------------------+---------------------+ 11036 | Send Data | SCSI Data-out >>> | Receive Data | 11037 +------------------+-----------------------+---------------------+ 11038 | | <<< SCSI Response |Send Status and Sense| 11039 +------------------+-----------------------+---------------------+ 11040 | Command Complete | | | 11041 +------------------+-----------------------+---------------------+ 11043 R2TSN/DataSN Use Examples 11045 Output (write) data DataSN/R2TSN Example 11046 +------------------+-----------------------+---------------------+ 11047 |Initiator Function| PDU Type & Content | Target Function | 11048 +------------------+-----------------------+---------------------+ 11049 | Command request |SCSI Command (WRITE)>>>| Receive command | 11050 | (write) | | and queue it | 11051 +------------------+-----------------------+---------------------+ 11052 | | | Process old commands| 11053 +------------------+-----------------------+---------------------+ 11054 | | <<< R2T | Ready for data | 11055 | | R2TSN = 0 | | 11056 +------------------+-----------------------+---------------------+ 11057 | | <<< R2T | Ready for more data | 11058 | | R2TSN = 1 | | 11059 +------------------+-----------------------+---------------------+ 11060 | Send Data | SCSI Data-out >>> | Receive Data | 11061 | for R2TSN 0 | DataSN = 0, F=0 | | 11062 +------------------+-----------------------+---------------------+ 11063 | Send Data | SCSI Data-out >>> | Receive Data | 11064 | for R2TSN 0 | DataSN = 1, F=1 | | 11065 +------------------+-----------------------+---------------------+ 11066 | Send Data | SCSI Data >>> | Receive Data | 11067 | for R2TSN 1 | DataSN = 0, F=1 | | 11068 +------------------+-----------------------+---------------------+ 11069 | | <<< SCSI Response |Send Status and Sense| 11070 | | ExpDataSN = 0 | | 11071 +------------------+-----------------------+---------------------+ 11072 | Command Complete | | | 11073 +------------------+-----------------------+---------------------+ 11075 Input (read) data DataSN Example 11077 +------------------+-----------------------+---------------------+ 11078 |Initiator Function| PDU Type | Target Function | 11079 +------------------+-----------------------+---------------------+ 11080 | Command request |SCSI Command (READ)>>> | | 11081 | (read) | | | 11082 +------------------+-----------------------+---------------------+ 11083 | | |Prepare Data Transfer| 11084 +------------------+-----------------------+---------------------+ 11085 | Receive Data | <<< SCSI Data-in | Send Data | 11086 | | DataSN = 0, F=0 | | 11087 +------------------+-----------------------+---------------------+ 11088 | Receive Data | <<< SCSI Data-in | Send Data | 11089 | | DataSN = 1, F=0 | | 11090 +------------------+-----------------------+---------------------+ 11091 | Receive Data | <<< SCSI Data-in | Send Data | 11092 | | DataSN = 2, F=1 | | 11093 +------------------+-----------------------+---------------------+ 11094 | | <<< SCSI Response |Send Status and Sense| 11095 | | ExpDataSN = 3 | | 11096 +------------------+-----------------------+---------------------+ 11097 | Command Complete | | | 11098 +------------------+-----------------------+---------------------+ 11100 Bidirectional DataSN Example 11102 +------------------+-----------------------+---------------------+ 11103 |Initiator Function| PDU Type | Target Function | 11104 +------------------+-----------------------+---------------------+ 11105 | Command request |SCSI Command >>> | | 11106 | (Read-Write) | Read-Write | | 11107 +------------------+-----------------------+---------------------+ 11108 | | | Process old commands| 11109 +------------------+-----------------------+---------------------+ 11110 | | <<< R2T | Ready to process | 11111 | | R2TSN = 0 | WRITE command | 11112 +------------------+-----------------------+---------------------+ 11113 | * Receive Data | <<< SCSI Data-in | Send Data | 11114 | | DataSN = 0, F=0 | | 11115 +------------------+-----------------------+---------------------+ 11116 | * Receive Data | <<< SCSI Data-in | Send Data | 11117 | | DataSN = 1, F=1 | | 11118 +------------------+-----------------------+---------------------+ 11119 | * Send Data | SCSI Data-out >>> | Receive Data | 11120 | for R2TSN 0 | DataSN = 0, F=1 | | 11121 +------------------+-----------------------+---------------------+ 11122 | | <<< SCSI Response |Send Status and Sense| 11123 | | ExpDataSN = 2 | | 11124 +------------------+-----------------------+---------------------+ 11125 | Command Complete | | | 11126 +------------------+-----------------------+---------------------+ 11128 *) Send data and Receive Data may be transferred simultaneously as 11129 in an atomic Read-Old-Write-New or sequentially as in an atomic 11130 Read-Update-Write (in the latter case the R2T may follow the 11131 received data). 11133 Unsolicited and immediate output (write) data with DataSN Example 11134 +------------------+-----------------------+---------------------+ 11135 |Initiator Function| PDU Type & Content | Target Function | 11136 +------------------+-----------------------+---------------------+ 11137 | Command request |SCSI Command (WRITE)>>>| Receive command | 11138 | (write) |F=0 | and data | 11139 |+ immediate data | | and queue it | 11140 +------------------+-----------------------+---------------------+ 11141 | Send Unsolicited | SCSI Write Data >>> | Receive more Data | 11142 | Data | DataSN = 0, F=1 | | 11143 +------------------+-----------------------+---------------------+ 11144 | | | Process old commands| 11145 +------------------+-----------------------+---------------------+ 11146 | | <<< R2T | Ready for more data | 11147 | | R2TSN = 0 | | 11148 +------------------+-----------------------+---------------------+ 11149 | Send Data | SCSI Write Data >>> | Receive Data | 11150 | for R2TSN 0 | DataSN = 0, F=1 | | 11151 +------------------+-----------------------+---------------------+ 11152 | | <<< SCSI Response |Send Status and Sense| 11153 | | | | 11154 +------------------+-----------------------+---------------------+ 11155 | Command Complete | | | 11156 +------------------+-----------------------+---------------------+ 11158 CRC Examples 11160 N.B. all Values are Hexadecimal 11162 32 bytes of zeroes: 11164 Byte: 0 1 2 3 11166 0: 00 00 00 00 11167 ... 11168 28: 00 00 00 00 11170 CRC: aa 36 91 8a 11172 32 bytes of ones: 11174 Byte: 0 1 2 3 11175 0: ff ff ff ff 11176 ... 11177 28: ff ff ff ff 11179 CRC: 43 ab a8 62 11181 32 bytes of incrementing 00..1f: 11183 Byte: 0 1 2 3 11185 0: 00 01 02 03 11186 ... 11187 28: 1c 1d 1e 1f 11189 CRC: 4e 79 dd 46 11191 32 bytes of decrementing 1f..00: 11193 Byte: 0 1 2 3 11195 0: 1f 1e 1d 1c 11196 ... 11197 28: 03 02 01 00 11199 CRC: 5c db 3f 11 11201 An iSCSI - SCSI Read (10) Command PDU 11203 Byte: 0 1 2 3 11205 0: 01 c0 00 00 11206 4: 00 00 00 00 11207 8: 00 00 00 00 11208 12: 00 00 00 00 11209 16: 14 00 00 00 11210 20: 00 00 04 00 11211 24: 00 00 00 14 11212 28: 00 00 00 18 11213 32: 28 00 00 00 11214 36: 00 00 00 00 11215 40: 02 00 00 00 11216 44: 00 00 00 00 11218 CRC: 56 3a 96 d9 11220 Appendix B. Login Phase Examples 11222 In the first example, the initiator and target authenticate each 11223 other via Kerberos: 11225 I-> Login (CSG,NSG=0,1 T=1) 11226 InitiatorName=iqn.1999-07.com.os:hostid.77 11227 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11228 AuthMethod=KRB5,SRP,None 11230 T-> Login (CSG,NSG=0,0 T=0) 11231 AuthMethod=KRB5 11233 I-> Login (CSG,NSG=0,1 T=1) 11234 KRB_AP_REQ= 11236 (krb_ap_req contains the Kerberos V5 ticket and authenticator with 11237 MUTUAL-REQUIRED set in the ap-options field) 11239 If the authentication is successful, the target proceeds with: 11241 T-> Login (CSG,NSG=0,1 T=1) 11242 KRB_AP_REP= 11244 (krb_ap_rep is the Kerberos V5 mutual authentication reply) 11246 If the authentication is successful, the initiator may proceed 11247 with: 11249 I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192 11250 T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096 11251 MaxBurstLength=8192 11252 I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192 11253 ... more iSCSI Operational Parameters 11255 T-> Login (CSG,NSG=1,0 T=0) 11256 ... more iSCSI Operational Parameters 11258 And at the end: 11260 I-> Login (CSG,NSG=1,3 T=1) 11261 optional iSCSI parameters 11263 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11265 If the initiator's authentication by the target is not successful, 11266 the target responds with: 11268 T-> Login "login reject" 11270 instead of the Login KRB_AP_REP message, and terminates the 11271 connection. 11273 If the target's authentication by the initiator is not successful, 11274 the initiator terminates the connection (without responding to the 11275 Login KRB_AP_REP message). 11277 In the next example only the initiator is authenticated by the 11278 target via Kerberos: 11280 I-> Login (CSG,NSG=0,1 T=1) 11281 InitiatorName=iqn.1999-07.com.os:hostid.77 11282 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11283 AuthMethod=SRP,KRB5,None 11285 T-> Login-PR (CSG,NSG=0,0 T=0) 11286 AuthMethod=KRB5 11288 I-> Login (CSG,NSG=0,1 T=1) 11289 KRB_AP_REQ=krb_ap_req 11291 (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req) 11293 If the authentication is successful, the target proceeds with: 11295 T-> Login (CSG,NSG=0,1 T=1) 11297 I-> Login (CSG,NSG=1,0 T=0) 11298 ... iSCSI parameters 11300 T-> Login (CSG,NSG=1,0 T=0) 11301 ... iSCSI parameters 11303 . . . 11305 T-> Login (CSG,NSG=1,3 T=1)"login accept" 11307 In the next example, the initiator and target authenticate each 11308 other via SRP: 11310 I-> Login (CSG,NSG=0,1 T=1) 11311 InitiatorName=iqn.1999-07.com.os:hostid.77 11312 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11313 AuthMethod=KRB5,SRP,None 11315 T-> Login-PR (CSG,NSG=0,0 T=0) 11316 AuthMethod=SRP 11318 I-> Login (CSG,NSG=0,0 T=0) 11319 SRP_U= 11320 TargetAuth=Yes 11322 T-> Login (CSG,NSG=0,0 T=0) 11323 SRP_N= 11324 SRP_g= 11325 SRP_s= 11327 I-> Login (CSG,NSG=0,0 T=0) 11328 SRP_A= 11330 T-> Login (CSG,NSG=0,0 T=0) 11331 SRP_B= 11333 I-> Login (CSG,NSG=0,1 T=1) 11334 SRP_M= 11336 If the initiator authentication is successful, the target 11337 proceeds: 11339 T-> Login (CSG,NSG=0,1 T=1) 11340 SRP_HM= 11342 Where N, g, s, A, B, M, and H(A | M | K) are defined in 11343 [RFC2945]. 11345 If the target authentication is not successful, the initiator 11346 terminates the connection; otherwise, it proceeds. 11348 I-> Login (CSG,NSG=1,0 T=0) 11349 ... iSCSI parameters 11351 T-> Login (CSG,NSG=1,0 T=0) 11352 ... iSCSI parameters 11354 And at the end: 11356 I-> Login (CSG,NSG=1,3 T=1) 11357 optional iSCSI parameters 11359 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11361 If the initiator authentication is not successful, the target 11362 responds with: 11364 T-> Login "login reject" 11366 Instead of the T-> Login SRP_HM= message and 11367 terminates the connection. 11369 In the next example, only the initiator is authenticated by the 11370 target via SRP: 11372 I-> Login (CSG,NSG=0,1 T=1) 11373 InitiatorName=iqn.1999-07.com.os:hostid.77 11374 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11375 AuthMethod=KRB5,SRP,None 11377 T-> Login-PR (CSG,NSG=0,0 T=0) 11378 AuthMethod=SRP 11380 I-> Login (CSG,NSG=0,0 T=0) 11381 SRP_U= 11382 TargetAuth=No 11384 T-> Login (CSG,NSG=0,0 T=0) 11385 SRP_N= 11386 SRP_g= 11387 SRP_s= 11389 I-> Login (CSG,NSG=0,0 T=0) 11390 SRP_A= 11392 T-> Login (CSG,NSG=0,0 T=0) 11393 SRP_B= 11395 I-> Login (CSG,NSG=0,1 T=1) 11396 SRP_M= 11398 If the initiator authentication is successful, the target 11399 proceeds: 11401 T-> Login (CSG,NSG=0,1 T=1) 11403 I-> Login (CSG,NSG=1,0 T=0) 11405 ... iSCSI parameters 11407 T-> Login (CSG,NSG=1,0 T=0) 11409 ... iSCSI parameters 11411 And at the end: 11413 I-> Login (CSG,NSG=1,3 T=1) 11415 optional iSCSI parameters 11417 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11419 In the next example the initiator and target authenticate each 11420 other via CHAP: 11422 I-> Login (CSG,NSG=0,0 T=0) 11424 InitiatorName=iqn.1999-07.com.os:hostid.77 11426 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11428 AuthMethod=KRB5,CHAP,None 11430 T-> Login-PR (CSG,NSG=0,0 T=0) 11432 AuthMethod=CHAP 11434 I-> Login (CSG,NSG=0,0 T=0) 11436 CHAP_A= 11438 T-> Login (CSG,NSG=0,0 T=0) 11439 CHAP_A= 11440 CHAP_I= 11441 CHAP_C= 11443 I-> Login (CSG,NSG=0,1 T=1) 11445 CHAP_N= 11447 CHAP_R= 11449 CHAP_I= 11451 CHAP_C= 11453 If the initiator authentication is successful, the target 11454 proceeds: 11456 T-> Login (CSG,NSG=0,1 T=1) 11458 CHAP_N= 11460 CHAP_R= 11462 If the target authentication is not successful, the initiator 11463 aborts the connection; otherwise, it proceeds. 11465 I-> Login (CSG,NSG=1,0 T=0) 11467 ... iSCSI parameters 11469 T-> Login (CSG,NSG=1,0 T=0) 11471 ... iSCSI parameters 11473 And at the end: 11475 I-> Login (CSG,NSG=1,3 T=1) 11477 optional iSCSI parameters 11479 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11481 If the initiator authentication is not successful, the target 11482 responds with: 11484 T-> Login "login reject" 11486 Instead of the Login CHAP_R= "proceed and change 11487 stage" message and terminates the connection. 11489 In the next example, only the initiator is authenticated by the 11490 target via CHAP: 11492 I-> Login (CSG,NSG=0,1 T=0) 11494 InitiatorName=iqn.1999-07.com.os:hostid.77 11496 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11498 AuthMethod=KRB5,CHAP,None 11500 T-> Login-PR (CSG,NSG=0,0 T=0) 11502 AuthMethod=CHAP 11504 I-> Login (CSG,NSG=0,0 T=0) 11506 CHAP_A= 11508 T-> Login (CSG,NSG=0,0 T=0) 11509 CHAP_A= 11510 CHAP_I= 11511 CHAP_C= 11513 I-> Login (CSG,NSG=0,1 T=1) 11515 CHAP_N= 11517 CHAP_R= 11519 If the initiator authentication is successful, the target 11520 proceeds: 11522 T-> Login (CSG,NSG=0,1 T=1) 11524 I-> Login (CSG,NSG=1,0 T=0) 11526 ... iSCSI parameters 11528 T-> Login (CSG,NSG=1,0 T=0) 11530 ... iSCSI parameters 11532 And at the end: 11534 I-> Login (CSG,NSG=1,3 T=1) 11536 optional iSCSI parameters 11538 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11540 In the next example, the initiator does not offer any security 11541 parameters. It therefore may offer iSCSI parameters on the Login 11542 PDU with the T bit set to 1, and the target may respond with a 11543 final Login Response PDU immediately: 11545 I-> Login (CSG,NSG=1,3 T=1) 11547 InitiatorName=iqn.1999-07.com.os:hostid.77 11549 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11551 ... iSCSI parameters 11553 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11555 ... ISCSI parameters 11557 In the next example, the initiator does offer security 11558 parameters on the Login PDU, but the target does not choose 11559 any (i.e., chooses the "None" values): 11561 I-> Login (CSG,NSG=0,1 T=1) 11563 InitiatorName=iqn.1999-07.com.os:hostid.77 11565 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11567 AuthMethod=KRB5,SRP,None 11569 T-> Login-PR (CSG,NSG=0,1 T=1) 11571 AuthMethod=None 11573 I-> Login (CSG,NSG=1,0 T=0) 11575 ... iSCSI parameters 11577 T-> Login (CSG,NSG=1,0 T=0) 11579 ... iSCSI parameters 11581 And at the end: 11583 I-> Login (CSG,NSG=1,3 T=1) 11585 optional iSCSI parameters 11587 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11589 Appendix C. SendTargets Operation 11591 To reduce the amount of configuration required on an initiator, 11592 iSCSI provides the SendTargets text request. The initiator uses 11593 the SendTargets request to get a list of targets to which it may 11594 have access, as well as the list of addresses (IP address and TCP 11595 port) on which these targets may be accessed. 11597 To make use of SendTargets, an initiator must first establish one 11598 of two types of sessions. If the initiator establishes 11599 the session using the key "SessionType=Discovery", the session is 11600 a discovery session, and a target name does not need to be 11601 specified. Otherwise, the session is a normal, operational 11602 session. The SendTargets command MUST only be sent during the 11603 Full Feature Phase of a normal or discovery session. 11605 A system that contains targets MUST support discovery sessions on 11606 each of its iSCSI IP address-port pairs, and MUST support the 11607 SendTargets command on the discovery session. In a discovery 11608 session, a target MUST return all path information (IP address- 11609 port pairs and portal group tags) for the targets on the target 11610 network entity which the requesting initiator is authorized to 11611 access. 11613 A target MUST support the SendTargets command on operational 11614 sessions; these will only return path information about the target 11615 to which the session is connected, and do not need to return 11616 information about other target names that may be defined in the 11617 responding system. 11619 An initiator MAY make use of the SendTargets as it sees fit. 11621 A SendTargets command consists of a single Text request PDU. 11622 This PDU contains exactly one text key and value. The text key 11623 MUST be SendTargets. The expected response depends upon the 11624 value, as well as whether the session is a discovery or 11625 operational session. 11627 The value must be one of: 11629 All 11631 The initiator is requesting that information on all relevant 11632 targets known to the implementation be returned. This value 11633 MUST be supported on a discovery session, and MUST NOT be 11634 supported on an operational session. 11636 11637 If an iSCSI target name is specified, the session should 11638 respond with addresses for only the named target, if 11639 possible. This value MUST be supported on discovery 11640 sessions. A discovery session MUST be capable of returning 11641 addresses for those targets that would have been returned 11642 had value=All been designated. 11644 11646 The session should only respond with addresses for the target 11647 to which the session is logged in. This MUST be supported 11648 on operational sessions, and MUST NOT return targets other 11649 than the one to which the session is logged in. 11651 The response to this command is a text response that contains a 11652 list of zero or more targets and, optionally, their addresses. 11653 Each target is returned as a target record. A target record 11654 begins with the TargetName text key, followed by a list of 11655 TargetAddress text keys, and bounded by the end of the text 11656 response or the next TargetName key, which begins a new record. 11657 No text keys other than TargetName and TargetAddress are permitted 11658 within a SendTargets response. 11660 For the format of the TargetName, see Section 13.4 - "TargetName". 11662 A discovery session MAY respond to a SendTargets request with its 11663 complete list of targets, or with a list of targets that is based 11664 on the name of the initiator logged in to the session. 11666 A SendTargets response MUST NOT contain target names if there are 11667 no targets for the requesting initiator to access. 11669 Each target record returned includes zero or more TargetAddress 11670 fields. 11672 Each target record starts with one text key of the form: 11674 TargetName= 11676 Followed by zero or more address keys of the form: 11678 TargetAddress=[:], 11681 The hostname-or-ipaddress contains a domain name, IPv4 address, or 11682 IPv6 address ([RFC4291]), as specified for the TargetAddress key. 11684 A hostname-or-ipaddress duplicated in TargetAddress responses for 11685 a given node (the port is absent or equal) would probably indicate 11686 that multiple address families are in use at once (IPv6 and IPv4). 11688 Each TargetAddress belongs to a portal group, identified by its 11689 numeric portal group tag (as in Section 13.9- 11690 "TargetPortalGroupTag"). The iSCSI target name, together with this 11691 tag, constitutes the SCSI port identifier; the tag only needs to 11692 be unique within a given target's name list of addresses. 11694 Multiple-connection sessions can span iSCSI addresses that belong 11695 to the same portal group. 11697 Multiple-connection sessions cannot span iSCSI addresses that 11698 belong to different portal groups. 11700 If a SendTargets response reports an iSCSI address for a target, 11701 it SHOULD also report all other addresses in its portal group in 11702 the same response. 11704 A SendTargets text response can be longer than a single Text 11705 Response PDU, and makes use of the long text responses as 11706 specified. 11708 After obtaining a list of targets from the discovery target 11709 session, 11710 an iSCSI initiator may initiate new sessions to log in to the 11711 discovered targets for full operation. The initiator MAY keep the 11712 discovery session open, and MAY send subsequent SendTargets 11713 commands to discover new targets. 11715 Examples: 11717 This example is the SendTargets response from a single target that 11718 has no other interface ports. 11720 Initiator sends text request that contains: 11722 SendTargets=All 11724 Target sends a text response that contains: 11726 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11728 All the target had to return in the simple case was the target 11729 name. It is assumed by the initiator that the IP address and TCP 11730 port for this target are the same as used on the current 11731 connection to the default iSCSI target. 11733 The next example has two internal iSCSI targets, each accessible 11734 via two different ports with different IP addresses. The 11735 following is the text response: 11737 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11739 TargetAddress=10.1.0.45:3000,1 11741 TargetAddress=10.1.1.45:3000,2 11743 TargetName=iqn.1993-11.com.example:diskarray.sn.1234567 11745 TargetAddress=10.1.0.45:3000,1 11747 TargetAddress=10.1.1.45:3000,2 11749 Both targets share both addresses; the multiple addresses are 11750 likely used to provide multi-path support. The initiator may 11751 connect to either target name on either address. Each of the 11752 addresses has its own portal group tag; they do not support 11753 spanning multiple-connection sessions with each other. Keep in 11754 mind that the portal group tags for the two named targets are 11755 independent of one another; portal group "1" on the first target 11756 is not necessarily the same as portal group "1" on the second 11757 target. 11759 In the above example, a DNS host name or an IPv6 address could 11760 have been returned instead of an IPv4 address. 11762 The next text response shows a target that supports spanning 11763 sessions across multiple addresses, and further illustrates the 11764 use of the portal group tags: 11766 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11768 TargetAddress=10.1.0.45:3000,1 11770 TargetAddress=10.1.1.46:3000,1 11772 TargetAddress=10.1.0.47:3000,2 11774 TargetAddress=10.1.1.48:3000,2 11776 TargetAddress=10.1.1.49:3000,3 11778 In this example, any of the target addresses can be used to reach 11779 the same target. A single-connection session can be established 11780 to any of these TCP addresses. A multiple-connection session 11781 could span addresses .45 and .46 or .47 and .48, but cannot span 11782 any other combination. A TargetAddress with its own tag (.49) 11783 cannot be combined with any other address within the same session. 11785 This SendTargets response does not indicate whether .49 supports 11786 multiple connections per session; it is communicated via the 11787 MaxConnections text key upon login to the target. 11789 Appendix D. Algorithmic Presentation of Error Recovery Classes 11791 This appendix illustrates the error recovery classes using a 11792 pseudo-programming-language. The procedure names are chosen to be 11793 obvious to most implementers. Each of the recovery classes 11794 described has initiator procedures as well as target procedures. 11795 These algorithms focus on outlining the mechanics of error 11796 recovery classes, and do not exhaustively describe all other 11797 aspects/cases. Examples of this approach are: 11799 - Handling for only certain Opcode types is shown. 11801 - Only certain reason codes (e.g., Recovery in Logout command) 11802 are outlined. 11804 - Resultant cases, such as recovery of Synchronization on a 11805 header digest error are considered out-of-scope in these 11806 algorithms. In this particular example, a header digest 11807 error may lead to connection recovery if some type of sync 11808 and steering layer is not implemented. 11810 These algorithms strive to convey the iSCSI error recovery 11811 concepts in the simplest terms, and are not designed to be 11812 optimal. 11814 D.1. General Data Structure and 11815 Procedure Description 11817 This section defines the procedures and data structures that are 11818 commonly used by all the error recovery algorithms. The structures 11819 may not be the exhaustive representations of what is required for 11820 a typical implementation. 11822 Data structure definitions - 11823 struct TransferContext { 11824 int TargetTransferTag; 11825 int ExpectedDataSN; 11826 }; 11828 struct TCB { /* task control block */ 11829 Boolean SoFarInOrder; 11830 int ExpectedDataSN; /* used for both R2Ts, and Data */ 11831 int MissingDataSNList[MaxMissingDPDU]; 11832 Boolean FbitReceived; 11833 Boolean StatusXferd; 11834 Boolean CurrentlyAllegiant; 11835 int ActiveR2Ts; 11836 int Response; 11837 char *Reason; 11838 struct TransferContext 11839 TransferContextList[MaxOutStandingR2T]; 11840 int InitiatorTaskTag; 11841 int CmdSN; 11842 int SNACK_Tag; 11843 }; 11845 struct Connection { 11846 struct Session SessionReference; 11847 Boolean SoFarInOrder; 11848 int CID; 11849 int State; 11850 int CurrentTimeout; 11851 int ExpectedStatSN; 11852 int MissingStatSNList[MaxMissingSPDU]; 11853 Boolean PerformConnectionCleanup; 11854 }; 11856 struct Session { 11857 int NumConnections; 11858 int CmdSN; 11859 int Maxconnections; 11860 int ErrorRecoveryLevel; 11861 struct iSCSIEndpoint OtherEndInfo; 11862 struct Connection ConnectionList[MaxSupportedConns]; 11863 }; 11865 Procedure descriptions - 11866 Receive-a-In-PDU(transport connection, inbound PDU); 11867 check-basic-validity(inbound PDU); 11868 Start-Timer(timeout handler, argument, timeout value); 11869 Build-And-Send-Reject(transport connection, bad PDU, reason 11870 code); 11871 D.2. Within-command Error Recovery 11872 Algorithms 11874 D.2.1. Procedure Descriptions 11876 Recover-Data-if-Possible(last required DataSN, task control 11877 block); 11878 Build-And-Send-DSnack(task control block); 11879 Build-And-Send-RDSnack(task control block); 11880 Build-And-Send-Abort(task control block); 11881 SCSI-Task-Completion(task control block); 11882 Build-And-Send-A-Data-Burst(transport connection, data- 11883 descriptor, 11884 task control 11885 block); 11886 Build-And-Send-R2T(transport connection, data-descriptor, 11887 task control 11888 block); 11889 Build-And-Send-Status(transport connection, task control block); 11890 Transfer-Context-Timeout-Handler(transfer context); 11892 Notes: 11894 - One procedure used in this section: Handle-Status-SNACK- 11895 request is defined in Within-connection recovery algorithms. 11897 - The Response processing pseudo-code, shown in the target 11898 algorithms, applies to all solicited PDUs that carry StatSN 11899 - SCSI Response, Text Response etc. 11901 D.2.2. Initiator Algorithms 11903 Recover-Data-if-Possible(LastRequiredDataSN, TCB) 11904 { 11905 if (operational ErrorRecoveryLevel > 0) { 11906 if (# of missing PDUs is trackable) { 11907 Note the missing DataSNs in TCB. 11908 if (the task spanned a change in 11909 MaxRecvDataSegmentLength) { 11911 if (TCB.StatusXferd is TRUE) 11912 drop the status PDU; 11913 Build-And-Send-RDSnack(TCB); 11914 } else { 11915 Build-And-Send-DSnack(TCB); 11916 } 11917 } else { 11918 TCB.Reason = "Protocol service CRC error"; 11919 } 11920 } else { 11921 TCB.Reason = "Protocol service CRC error"; 11922 } 11923 if (TCB.Reason == "Protocol service CRC error") { 11924 Clear the missing PDU list in the TCB. 11925 if (TCB.StatusXferd is not TRUE) 11926 Build-And-Send-Abort(TCB); 11927 } 11928 } 11930 Receive-a-In-PDU(Connection, CurrentPDU) 11931 { 11932 check-basic-validity(CurrentPDU); 11933 if (Header-Digest-Bad) discard, return; 11934 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11935 if ((CurrentPDU.type == Data) 11936 or (CurrentPDU.type = R2T)) { 11937 if (Data-Digest-Bad for Data) { 11938 send-data-SNACK = TRUE; 11939 LastRequiredDataSN = CurrentPDU.DataSN; 11940 } else { 11941 if (TCB.SoFarInOrder = TRUE) { 11942 if (current DataSN is expected) { 11943 Increment TCB.ExpectedDataSN. 11944 } else { 11945 TCB.SoFarInOrder = FALSE; 11946 send-data-SNACK = TRUE; 11947 } 11948 } else { 11949 if (current DataSN was considered 11950 missing) { 11951 remove current DataSN from missing 11952 PDU list. 11953 } else if (current DataSN is higher than 11954 expected) { 11955 send-data-SNACK = TRUE; 11956 } else { 11957 discard, return; 11958 } 11959 Adjust TCB.ExpectedDataSN if 11960 appropriate. 11961 } 11962 LastRequiredDataSN = CurrentPDU.DataSN - 1; 11963 } 11964 if (send-data-SNACK is TRUE and 11965 task is not already considered failed) { 11966 Recover-Data-if-Possible(LastRequiredDataSN, TCB); 11967 } 11968 if (missing data PDU list is empty) { 11969 TCB.SoFarInOrder = TRUE; 11970 } 11971 if (CurrentPDU.type == R2T) { 11972 Increment ActiveR2Ts for this task. 11973 Create a data-descriptor for the data burst. 11974 Build-And-Send-A-Data-Burst(Connection, data- 11975 descriptor, 11976 TCB); 11977 } 11978 } else if (CurrentPDU.type == Response) { 11979 if (Data-Digest-Bad) { 11980 send-status-SNACK = TRUE; 11981 } else { 11982 TCB.StatusXferd = TRUE; 11983 Store the status information in TCB. 11984 if (ExpDataSN does not match) { 11985 TCB.SoFarInOrder = FALSE; 11986 Recover-Data-if-Possible(current DataSN, TCB); 11987 } 11988 if (missing data PDU list is empty) { 11989 TCB.SoFarInOrder = TRUE; 11990 } 11992 } 11993 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 11994 SHOWN */ 11995 } 11996 if ((TCB.SoFarInOrder == TRUE) and 11997 (TCB.StatusXferd == TRUE)) { 11998 SCSI-Task-Completion(TCB); 11999 } 12000 } 12002 D.2.3. Target Algorithms 12004 Receive-a-In-PDU(Connection, CurrentPDU) 12005 { 12006 check-basic-validity(CurrentPDU); 12007 if (Header-Digest-Bad) discard, return; 12008 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12009 if (CurrentPDU.type == Data) { 12010 Retrieve TContext from CurrentPDU.TargetTransferTag; 12011 if (Data-Digest-Bad) { 12012 Build-And-Send-Reject(Connection, CurrentPDU, 12013 Payload-Digest-Error); 12014 Note the missing data PDUs in MissingDataRange[]. 12015 send-recovery-R2T = TRUE; 12016 } else { 12017 if (current DataSN is not expected) { 12018 Note the missing data PDUs in MissingDataRange[]. 12019 send-recovery-R2T = TRUE; 12020 } 12021 if (CurrentPDU.Fbit == TRUE) { 12022 if (current PDU is solicited) { 12023 Decrement TCB.ActiveR2Ts. 12024 } 12025 if ((current PDU is unsolicited and 12026 data received is less than I/O length and 12027 data received is less than 12028 FirstBurstLength) 12029 or (current PDU is solicited and the length of 12030 this burst is less than expected)) { 12031 send-recovery-R2T = TRUE; 12032 Note the missing data in MissingDataRange[]. 12033 } 12034 } 12035 } 12036 Increment TContext.ExpectedDataSN. 12037 if (send-recovery-R2T is TRUE and 12038 task is not already considered failed) { 12039 if (operational ErrorRecoveryLevel > 0) { 12040 Increment TCB.ActiveR2Ts. 12041 Create a data-descriptor for the data burst 12042 from MissingDataRange. 12043 Build-And-Send-R2T(Connection, data-descriptor, 12044 TCB); 12045 } else { 12046 if (current PDU is the last unsolicited) 12047 TCB.Reason = "Not enough unsolicited data"; 12048 else 12049 TCB.Reason = "Protocol service CRC error"; 12050 } 12051 } 12052 if (TCB.ActiveR2Ts == 0) { 12053 Build-And-Send-Status(Connection, TCB); 12054 } 12055 } else if (CurrentPDU.type == SNACK) { 12056 snack-failure = FALSE; 12057 if (operational ErrorRecoveryLevel > 0) { 12058 if (CurrentPDU.type == Data/R2T) { 12059 if (the request is satisfiable) { 12060 if (request for Data) { 12061 Create a data-descriptor for the data burst 12062 from BegRun and RunLength. 12063 Build-And-Send-A-Data-Burst(Connection, 12064 data-descriptor, TCB); 12065 } else { /* R2T */ 12066 Create a data-descriptor for the data burst 12067 from BegRun and RunLength. 12068 Build-And-Send-R2T(Connection, data- 12069 descriptor, 12070 TCB); 12071 } 12072 } else { 12073 snack-failure = TRUE; 12074 } 12075 } else if (CurrentPDU.type == status) { 12076 Handle-Status-SNACK-request(Connection, 12077 CurrentPDU); 12078 } else if (CurrentPDU.type == DataACK) { 12079 Consider all data upto CurrentPDU.BegRun as 12080 acknowledged. 12081 Free up the retransmission resources for that data. 12082 } else if (CurrentPDU.type == R-Data SNACK) { 12083 Create a data descriptor for a data burst 12084 covering 12085 all unacknowledged data. 12086 Build-And-Send-A-Data-Burst(Connection, 12087 data-descriptor, TCB); 12088 TCB.SNACK_Tag = CurrentPDU.SNACK_Tag; 12089 if (there's no more data to send) { 12090 Build-And-Send-Status(Connection, TCB); 12091 } 12092 } 12093 } else { /* operational ErrorRecoveryLevel = 0 */ 12094 snack-failure = TRUE; 12095 } 12096 if (snack-failure == TRUE) { 12097 Build-And-Send-Reject(Connection, CurrentPDU, 12098 SNACK-Reject); 12099 if (TCB.StatusXferd != TRUE) { 12100 TCB.Reason = "SNACK Rejected"; 12101 Build-And-Send-Status(Connection, TCB); 12102 } 12103 } 12105 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 12106 SHOWN */ 12107 } 12108 } 12110 Transfer-Context-Timeout-Handler(TContext) 12111 { 12112 Retrieve TCB and Connection from TContext. 12113 Decrement TCB.ActiveR2Ts. 12115 if (operational ErrorRecoveryLevel > 0 and 12116 task is not already considered failed) { 12117 Note the missing data PDUs in MissingDataRange[]. 12118 Create a data-descriptor for the data burst 12119 from MissingDataRange[]. 12120 Build-And-Send-R2T(Connection, data-descriptor, TCB); 12121 } else { 12122 TCB.Reason = "Protocol service CRC error"; 12123 if (TCB.ActiveR2Ts = 0) { 12124 Build-And-Send-Status(Connection, TCB); 12125 } 12126 } 12127 } 12129 D.3. Within-connection Recovery 12130 Algorithms 12132 D.3.1. Procedure Descriptions 12134 Procedure descriptions: 12135 Recover-Status-if-Possible(transport connection, 12136 currently received PDU); 12137 Evaluate-a-StatSN(transport connection, currently received PDU); 12138 Retransmit-Command-if-Possible(transport connection, CmdSN); 12139 Build-And-Send-SSnack(transport connection); 12140 Build-And-Send-Command(transport connection, task control 12141 block); 12142 Command-Acknowledge-Timeout-Handler(task control block); 12143 Status-Expect-Timeout-Handler(transport connection); 12144 Build-And-Send-Nop-Out(transport connection); 12145 Handle-Status-SNACK-request(transport connection, status SNACK 12146 PDU); 12147 Retransmit-Status-Burst(status SNACK, task control block); 12148 Is-Acknowledged(beginning StatSN, run length); 12150 Implementation-specific tunables: 12151 InitiatorProactiveSNACKEnabled 12153 Notes: 12154 - The initiator algorithms only deal with unsolicited Nop-In 12155 PDUs for generating status SNACKs. A solicited Nop-In PDU 12156 has an assigned StatSN, which, when out of order, could 12157 trigger the out of order StatSN handling in Within-command 12158 algorithms, again leading to Recover-Status-if-Possible. 12160 - The pseudo-code shown may result in the retransmission of 12161 unacknowledged commands in more cases than necessary. This 12162 will not, however, affect the correctness of the operation 12163 because the target is required to discard the duplicate 12164 CmdSNs. 12166 - The procedure Build-And-Send-Async is defined in the 12167 Connection recovery algorithms. 12169 - The procedure Status-Expect-Timeout-Handler describes how 12170 initiators may proactively attempt to retrieve the Status if 12171 they so choose. This procedure is assumed to be triggered 12172 much before the standard ULP timeout. 12174 D.3.2. Initiator Algorithms 12176 Recover-Status-if-Possible(Connection, CurrentPDU) 12177 { 12178 if ((Connection.state == LOGGED_IN) and 12179 connection is not already considered 12180 failed) { 12181 if (operational ErrorRecoveryLevel > 0) { 12182 if (# of missing PDUs is trackable) { 12183 Note the missing StatSNs in Connection 12184 that were not already requested with SNACK; 12185 Build-And-Send-SSnack(Connection); 12186 } else { 12187 Connection.PerformConnectionCleanup = TRUE; 12188 } 12189 } else { 12190 Connection.PerformConnectionCleanup = TRUE; 12192 } 12193 if (Connection.PerformConnectionCleanup == TRUE) { 12194 Start-Timer(Connection-Cleanup-Handler, Connection, 12195 0); 12196 } 12197 } 12198 } 12200 Retransmit-Command-if-Possible(Connection, CmdSN) 12201 { 12202 if (operational ErrorRecoveryLevel > 0) { 12203 Retrieve the InitiatorTaskTag, and thus TCB for the 12204 CmdSN. 12205 Build-And-Send-Command(Connection, TCB); 12206 } 12207 } 12209 Evaluate-a-StatSN(Connection, CurrentPDU) 12210 { 12211 send-status-SNACK = FALSE; 12212 if (Connection.SoFarInOrder == TRUE) { 12213 if (current StatSN is the expected) { 12214 Increment Connection.ExpectedStatSN. 12215 } else { 12216 Connection.SoFarInOrder = FALSE; 12217 send-status-SNACK = TRUE; 12218 } 12219 } else { 12220 if (current StatSN was considered missing) { 12221 remove current StatSN from the missing list. 12222 } else { 12223 if (current StatSN is higher than expected){ 12224 send-status-SNACK = TRUE; 12225 } else { 12226 send-status-SNACK = FALSE; 12227 discard the PDU; 12228 } 12229 } 12230 Adjust Connection.ExpectedStatSN if appropriate. 12231 if (missing StatSN list is empty) { 12232 Connection.SoFarInOrder = TRUE; 12233 } 12234 } 12235 return send-status-SNACK; 12236 } 12238 Receive-a-In-PDU(Connection, CurrentPDU) 12239 { 12240 check-basic-validity(CurrentPDU); 12241 if (Header-Digest-Bad) discard, return; 12242 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12243 if (CurrentPDU.type == Nop-In) { 12244 if (the PDU is unsolicited) { 12245 if (current StatSN is not expected) { 12246 Recover-Status-if-Possible(Connection, 12247 CurrentPDU); 12248 } 12249 if (current ExpCmdSN is not Session.CmdSN) { 12250 Retransmit-Command-if-Possible(Connection, 12251 CurrentPDU.ExpCmdSN); 12252 } 12253 } 12254 } else if (CurrentPDU.type == Reject) { 12255 if (it is a data digest error on immediate data) { 12256 Retransmit-Command-if-Possible(Connection, 12258 CurrentPDU.BadPDUHeader.CmdSN); 12259 } 12260 } else if (CurrentPDU.type == Response) { 12261 send-status-SNACK = Evaluate-a-StatSN(Connection, 12262 CurrentPDU); 12263 if (send-status-SNACK == TRUE) 12264 Recover-Status-if-Possible(Connection, CurrentPDU); 12265 } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY, 12266 * NOT SHOWN */ 12267 } 12268 } 12270 Command-Acknowledge-Timeout-Handler(TCB) 12271 { 12272 Retrieve the Connection for TCB. 12273 Retransmit-Command-if-Possible(Connection, TCB.CmdSN); 12274 } 12276 Status-Expect-Timeout-Handler(Connection) 12277 { 12278 if (operational ErrorRecoveryLevel > 0) { 12279 Build-And-Send-Nop-Out(Connection); 12280 } else if (InitiatorProactiveSNACKEnabled){ 12281 if ((Connection.state == LOGGED_IN) and 12282 connection is not already considered 12283 failed) { 12284 Build-And-Send-SSnack(Connection); 12285 } 12286 } 12287 } 12289 E.3.3 Target Algorithms 12291 Handle-Status-SNACK-request(Connection, CurrentPDU) 12292 { 12293 if (operational ErrorRecoveryLevel > 0) { 12294 if (request for an acknowledged run) { 12295 Build-And-Send-Reject(Connection, CurrentPDU, 12296 Protocol-Error); 12297 } else if (request for an untransmitted run) { 12298 discard, return; 12299 } else { 12300 Retransmit-Status-Burst(CurrentPDU, TCB); 12301 } 12302 } else { 12303 Build-And-Send-Async(Connection, DroppedConnection, 12304 DefaultTime2Wait, 12305 DefaultTime2Retain); 12306 } 12307 } 12308 D.4. Connection Recovery Algorithms 12310 D.4.1. Procedure Descriptions 12312 Build-And-Send-Async(transport connection, reason code, 12313 minimum time, maximum time); 12314 Pick-A-Logged-In-Connection(session); 12315 Build-And-Send-Logout(transport connection, logout connection 12316 identifier, reason code); 12317 PerformImplicitLogout(transport connection, logout connection 12318 identifier, target information); 12319 PerformLogin(transport connection, target information); 12320 CreateNewTransportConnection(target information); 12321 Build-And-Send-Command(transport connection, task control 12322 block); 12323 Connection-Cleanup-Handler(transport connection); 12324 Connection-Resource-Timeout-Handler(transport connection); 12325 Quiesce-And-Prepare-for-New-Allegiance(session, task control 12326 block); 12327 Build-And-Send-Logout-Response(transport connection, 12328 CID of connection in recovery, reason 12329 code); 12330 Build-And-Send-TaskMgmt-Response(transport connection, 12331 task mgmt command PDU, response code); 12332 Establish-New-Allegiance(task control block, transport 12333 connection); 12334 Schedule-Command-To-Continue(task control block); 12336 Notes: 12337 - Transport exception conditions, such as unexpected 12338 connection termination, connection reset, and hung 12339 connection while the connection is in the full-feature 12340 phase, are all assumed to be asynchronously signaled to the 12341 iSCSI layer using the Transport_Exception_Handler procedure. 12343 D.4.2. Initiator Algorithms 12345 Receive-a-In-PDU(Connection, CurrentPDU) 12346 { 12347 check-basic-validity(CurrentPDU); 12348 if (Header-Digest-Bad) discard, return; 12349 Retrieve TCB from CurrentPDU.InitiatorTaskTag. 12350 if (CurrentPDU.type == Async) { 12351 if (CurrentPDU.AsyncEvent == ConnectionDropped) { 12352 Retrieve the AffectedConnection for 12353 CurrentPDU.Parameter1. 12354 AffectedConnection.CurrentTimeout = 12355 CurrentPDU.Parameter3; 12356 AffectedConnection.State = CLEANUP_WAIT; 12357 Start-Timer(Connection-Cleanup-Handler, 12358 AffectedConnection, 12359 CurrentPDU.Parameter2); 12360 } else if (CurrentPDU.AsyncEvent == LogoutRequest)) { 12361 AffectedConnection = Connection; 12362 AffectedConnection.State = LOGOUT_REQUESTED; 12363 AffectedConnection.PerformConnectionCleanup = TRUE; 12364 AffectedConnection.CurrentTimeout = 12365 CurrentPDU.Parameter3; 12366 Start-Timer(Connection-Cleanup-Handler, 12367 AffectedConnection, 0); 12368 } else if (CurrentPDU.AsyncEvent == SessionDropped)) { 12369 for (each Connection) { 12370 Connection.State = CLEANUP_WAIT; 12371 Connection.CurrentTimeout = CurrentPDU.Parameter3; 12372 Start-Timer(Connection-Cleanup-Handler, 12373 Connection, CurrentPDU.Parameter2); 12374 } 12375 Session.state = FAILED; 12376 } 12378 } else if (CurrentPDU.type == LogoutResponse) { 12379 Retrieve the CleanupConnection for CurrentPDU.CID. 12380 if (CurrentPDU.Response = failure) { 12381 CleanupConnection.State = CLEANUP_WAIT; 12382 } else { 12383 CleanupConnection.State = FREE; 12384 } 12385 } else if (CurrentPDU.type == LoginResponse) { 12386 if (this is a response to an implicit Logout) { 12387 Retrieve the CleanupConnection. 12388 if (successful) { 12389 CleanupConnection.State = FREE; 12390 Connection.State = LOGGED_IN; 12391 } else { 12392 CleanupConnection.State = CLEANUP_WAIT; 12393 DestroyTransportConnection(Connection); 12394 } 12395 } 12396 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12397 * NOT SHOWN */ 12398 } 12399 if (CleanupConnection.State == FREE) { 12400 for (each command that was active on CleanupConnection) { 12401 /* Establish new connection allegiance */ 12402 NewConnection = Pick-A-Logged-In- 12403 Connection(Session); 12404 Build-And-Send-Command(NewConnection, TCB); 12405 } 12406 } 12407 } 12409 Connection-Cleanup-Handler(Connection) 12410 { 12411 Retrieve Session from Connection. 12412 if (Connection can still exchange iSCSI PDUs) { 12413 NewConnection = Connection; 12414 } else { 12415 Start-Timer(Connection-Resource-Timeout-Handler, 12416 Connection, Connection.CurrentTimeout); 12417 if (there are other logged-in connections) { 12418 NewConnection = Pick-A-Logged-In- 12419 Connection(Session); 12420 } else { 12421 NewConnection = 12423 CreateTransportConnection(Session.OtherEndInfo); 12424 Initiate an implicit Logout on NewConnection for 12425 Connection.CID. 12426 return; 12428 } 12429 } 12430 Build-And-Send-Logout(NewConnection, Connection.CID, 12431 RecoveryRemove); 12432 } 12434 Transport_Exception_Handler(Connection) 12435 { 12436 Connection.PerformConnectionCleanup = TRUE; 12437 if (the event is an unexpected transport disconnect) { 12438 Connection.State = CLEANUP_WAIT; 12439 Connection.CurrentTimeout = DefaultTime2Retain; 12440 Start-Timer(Connection-Cleanup-Handler, Connection, 12441 DefaultTime2Wait); 12443 } else { 12444 Connection.State = FREE; 12445 } 12446 } 12448 D.4.3. Target Algorithms 12450 Receive-a-In-PDU(Connection, CurrentPDU) 12451 { 12452 check-basic-validity(CurrentPDU); 12453 if (Header-Digest-Bad) discard, return; 12454 else if (Data-Digest-Bad) { 12455 Build-And-Send-Reject(Connection, CurrentPDU, 12456 Payload-Digest-Error); 12457 discard, return; 12458 } 12459 Retrieve TCB and Session. 12460 if (CurrentPDU.type == Logout) { 12461 if (CurrentPDU.ReasonCode = RecoveryRemove) { 12462 Retrieve the CleanupConnection from CurrentPDU.CID). 12463 for (each command active on CleanupConnection) { 12464 Quiesce-And-Prepare-for-New-Allegiance(Session, 12465 TCB); 12466 TCB.CurrentlyAllegiant = FALSE; 12467 } 12468 Cleanup-Connection-State(CleanupConnection); 12469 if ((quiescing successful) and (cleanup successful)) 12470 { 12471 Build-And-Send-Logout-Response(Connection, 12472 CleanupConnection.CID, 12473 Success); 12474 } else { 12475 Build-And-Send-Logout-Response(Connection, 12476 CleanupConnection.CID, 12477 Failure); 12478 } 12479 } 12480 } else if ((CurrentPDU.type == Login) and 12481 operational ErrorRecoveryLevel == 2) { 12482 Retrieve the CleanupConnection from CurrentPDU.CID). 12483 for (each command active on CleanupConnection) { 12484 Quiesce-And-Prepare-for-New-Allegiance(Session, 12485 TCB); 12486 TCB.CurrentlyAllegiant = FALSE; 12487 } 12488 Cleanup-Connection-State(CleanupConnection); 12489 if ((quiescing successful) and (cleanup successful)) 12490 { 12491 Continue with the rest of the Login processing; 12492 } else { 12493 Build-And-Send-Login-Response(Connection, 12494 CleanupConnection.CID, Target 12495 Error); 12496 } 12497 } 12498 } else if (CurrentPDU.type == TaskManagement) { 12499 if (CurrentPDU.function == "TaskReassign") { 12500 if (Session.ErrorRecoveryLevel < 2) { 12501 Build-And-Send-TaskMgmt-Response(Connection, 12502 CurrentPDU, "Allegiance reassignment 12503 not supported"); 12504 } else if (task is not found) { 12505 Build-And-Send-TaskMgmt-Response(Connection, 12506 CurrentPDU, "Task not in task set"); 12507 } else if (task is currently allegiant) { 12508 Build-And-Send-TaskMgmt-Response(Connection, 12509 CurrentPDU, "Task still allegiant"); 12510 } else { 12511 Establish-New-Allegiance(TCB, Connection); 12512 TCB.CurrentlyAllegiant = TRUE; 12513 Schedule-Command-To-Continue(TCB); 12514 } 12515 } 12516 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12517 * NOT SHOWN */ 12518 } 12519 } 12521 Transport_Exception_Handler(Connection) 12522 { 12523 Connection.PerformConnectionCleanup = TRUE; 12524 if (the event is an unexpected transport disconnect) { 12525 Connection.State = CLEANUP_WAIT; 12526 Start-Timer(Connection-Resource-Timeout-Handler, 12527 Connection, 12529 (DefaultTime2Wait+DefaultTime2Retain)); 12530 if (this Session has full-feature phase connections 12531 left) { 12532 DifferentConnection = 12533 Pick-A-Logged-In-Connection(Session); 12534 Build-And-Send-Async(DifferentConnection, 12535 DroppedConnection, DefaultTime2Wait, 12536 DefaultTime2Retain); 12537 } 12538 } else { 12539 Connection.State = FREE; 12540 } 12541 } 12542 Appendix E. Clearing Effects of Various Events on Targets 12544 E.1. Clearing Effects on iSCSI Objects 12546 The following tables describe the target behavior on receiving the 12547 events specified in the rows of the table. The second table is 12549 an extension of the first table and defines clearing actions for 12550 more objects on the same events. The legend is: 12552 Y = Yes (cleared/discarded/reset on the event specified in 12553 the row). Unless otherwise noted, the clearing action is 12554 only applicable for the issuing initiator port. 12556 N = No (not affected on the event specified in the row, 12557 i.e., stays at previous value). 12559 NA = Not Applicable or Not Defined. 12561 +-----+-----+-----+-----+-----+ 12562 |IT(1)|IC(2)|CT(5)|ST(6)|PP(7)| 12563 +---------------------+-----+-----+-----+-----+-----+ 12564 |connection failure(8)|Y |Y |N |N |Y | 12565 +---------------------+-----+-----+-----+-----+-----+ 12566 |connection state |NA |NA |Y |N |NA | 12567 |timeout (9) | | | | | | 12568 +---------------------+-----+-----+-----+-----+-----+ 12569 |session timeout/ |Y |Y |Y |Y |Y(14)| 12570 |closure/reinstatement| | | | | | 12571 |(10) | | | | | | 12572 +---------------------+-----+-----+-----+-----+-----+ 12573 |session continuation |NA |NA |N(11)|N |NA | 12574 |(12) | | | | | | 12575 +---------------------+-----+-----+-----+-----+-----+ 12576 |successful connection|Y |Y |Y |N |Y(13)| 12577 |close logout | | | | | | 12578 +---------------------+-----+-----+-----+-----+-----+ 12579 |session failure (18) |Y |Y |N |N |Y | 12580 +---------------------+-----+-----+-----+-----+-----+ 12581 |successful recovery |Y |Y |N |N |Y(13)| 12582 |Logout | | | | | | 12583 +---------------------+-----+-----+-----+-----+-----+ 12584 |failed Logout |Y |Y |N |N |Y | 12585 +---------------------+-----+-----+-----+-----+-----+ 12586 |connection Login |NA |NA |NA |Y(15)|NA | 12587 |(leading) | | | | | | 12588 +---------------------+-----+-----+-----+-----+-----+ 12589 |connection Login |NA |NA |N(11)|N |Y | 12590 |(non-leading) | | | | | | 12591 +---------------------+-----+-----+-----+-----+-----+ 12592 |target cold reset(16)|Y(20)|Y |Y |Y |Y | 12593 +---------------------+-----+-----+-----+-----+-----+ 12594 |target warm reset(16)|Y(20)|Y |Y |Y |Y | 12595 +---------------------+-----+-----+-----+-----+-----+ 12596 |LU reset(19) |Y(20)|Y |Y |Y |Y | 12597 +---------------------+-----+-----+-----+-----+-----+ 12598 |powercycle(16) |Y |Y |Y |Y |Y | 12599 +---------------------+-----+-----+-----+-----+-----+ 12601 1. Incomplete TTTs - Target Transfer Tags on which the target is 12602 still expecting PDUs to be received. Examples include TTTs 12603 received via R2T, NOP-IN, etc. 12605 2. Immediate Commands - immediate commands, but waiting for 12606 execution on a target. For example, Abort Task Set. 12608 5. Connection Tasks - tasks that are active on the iSCSI connection 12609 in question. 12611 6. Session Tasks - tasks that are active on the entire iSCSI 12612 session. A union of "connection tasks" on all participating 12613 connections. 12615 7. Partial PDUs (if any) - PDUs that are partially sent and waiting 12616 for transport window credit to complete the transmission. 12618 8. Connection failure is a connection exception condition - one of 12619 the transport connections shutdown, transport connections 12620 reset, or transport connections timed out, which abruptly 12621 terminated the iSCSI full-feature phase connection. A 12622 connection failure always takes the connection state machine to 12623 the CLEANUP_WAIT state. 12625 9. Connection state timeout happens if a connection spends more 12626 time than agreed upon during Login negotiation in the 12627 CLEANUP_WAIT state, and this takes the connection to the FREE 12628 state (M1 transition in connection cleanup state diagram). 12630 10.These are defined in Section 6.3.5. 12632 11.This clearing effect is "Y" only if it is a connection 12633 reinstatement and the operational ErrorRecoveryLevel is less 12634 than 2. 12636 12.Session continuation is defined in Section 6.3.5. 12638 13.This clearing effect is only valid if the connection is being 12639 logged out on a different connection and when the connection 12640 being logged out on the target may have some partial PDUs 12641 pending to be sent. In all other cases, the effect is "NA". 12642 14.This clearing effect is only valid for a "close the session" 12643 logout in a multi-connection session. In all other cases, the 12644 effect is "NA". 12645 15.Only applicable if this leading connection login is a session 12646 reinstatement. If this is not the case, it is "NA". 12647 16.This operation affects all logged-in initiators. 12648 18.Session failure is defined in Section 6.3.5. 12649 19.This operation affects all logged-in initiators and the clearing 12650 effects are only applicable to the LU being reset. 12652 20.With Standard multi-task abort semantics (Section 4.2.3.3), a 12653 target warm reset or a target cold reset or an LU reset would 12654 clear the active TTTs upon completion. However, the FastAbort 12655 multi-task abort semantics defined by Section 4.2.3.4 do not 12656 guarantee that the active TTTs are cleared by the end of the 12657 reset operations. In fact, the FastAbort semantics are designed 12658 to allow clearing the TTTs in a "lazy" fashion after the TMF 12659 Response is delivered. Thus, when TaskReporting=FastAbort 12660 (Section 13.23) is operational on a session, the clearing 12661 effects of reset operations on "Incomplete TTTs" is "N". 12663 +-----+-----+-----+-----+-----+ 12664 |DC(1)|DD(2)|SS(3)|CS(4)|DS(5)| 12665 +---------------------+-----+-----+-----+-----+-----+ 12666 |connection failure |N |Y |N |N |N | 12667 +---------------------+-----+-----+-----+-----+-----+ 12668 |connection state |Y |NA |Y |N |NA | 12669 |timeout | | | | | | 12670 +---------------------+-----+-----+-----+-----+-----+ 12671 |session timeout/ |Y |Y |Y(7) |Y |NA | 12672 |closure/reinstatement| | | | | | 12673 +---------------------+-----+-----+-----+-----+-----+ 12674 |session continuation |N(11)|NA*12|NA |N |NA*13| 12675 +---------------------+-----+-----+-----+-----+-----+ 12676 |successful connection|Y |Y |Y |N |NA | 12677 |close Logout | | | | | | 12678 +---------------------+-----+-----+-----+-----+-----+ 12679 |session failure |N |Y |N |N |N | 12680 +---------------------+-----+-----+-----+-----+-----+ 12681 |successful recovery |Y |Y |Y |N |N | 12682 |Logout | | | | | | 12683 +---------------------+-----+-----+-----+-----+-----+ 12684 |failed Logout |N |Y(9) |N |N |N | 12685 +---------------------+-----+-----+-----+-----+-----+ 12686 |connection Login |NA |NA |N(8) |N(8) |NA | 12687 |(leading | | | | | | 12688 +---------------------+-----+-----+-----+-----+-----+ 12689 |connection Login |N(11)|NA*12|N(8) |N |NA*13| 12690 |(non-leading) | | | | | | 12691 +---------------------+-----+-----+-----+-----+-----+ 12692 |target cold reset |Y |Y |Y |Y(10)|NA | 12693 +---------------------+-----+-----+-----+-----+-----+ 12694 |target warm reset |Y |Y |N |N |NA | 12695 +---------------------+-----+-----+-----+-----+-----+ 12696 |LU reset |N |Y |N |N |N | 12697 +---------------------+-----+-----+-----+-----+-----+ 12698 |powercycle |Y |Y |Y |Y(10)|NA | 12699 +---------------------+-----+-----+-----+-----+-----+ 12701 1. Discontiguous Commands - commands allegiant to the connection 12702 in question and waiting to be reordered in the iSCSI layer. All 12703 "Y"s in this column assume that the task causing the event (if 12704 indeed the event is the result of a task) is issued as an 12705 immediate command, because the discontiguities can be ahead of the 12706 task. 12708 2. Discontiguous Data - data PDUs received for the task in 12709 question and waiting to be reordered due to prior discontiguities 12710 in DataSN. 12712 3. StatSN 12714 4. CmdSN 12716 5. DataSN 12718 7. It clears the StatSN on all the connections. 12720 8. This sequence number is instantiated on this event. 12722 9. A logout failure drives the connection state machine to the 12723 CLEANUP_WAIT state, similar to the connection failure event. 12724 Hence, it has a similar effect on this and several other protocol 12725 aspects. 12727 10. This is cleared by virtue of the fact that all sessions with 12728 all initiators are terminated. 12730 11. This clearing effect is "Y" if it is a connection 12731 reinstatement. 12733 12. This clearing effect is "Y" only if it is a connection 12734 reinstatement and the operational ErrorRecoveryLevel is 2. 12736 13. This clearing effect is "N" only if it is a connection 12737 reinstatement and the operational ErrorRecoveryLevel is 2. 12739 E.2. Clearing Effects on SCSI Objects 12741 The only iSCSI protocol action that can effect clearing actions on 12742 SCSI objects is the "I_T nexus loss" notification (Section 6.3.5.1 12743 Loss of Nexus notification). [SPC3] describes the clearing effects 12744 of this notification on a variety of SCSI attributes. In addition, 12745 SCSI standards documents (such as [SAM2] and [SBC]) define 12746 additional clearing actions that may take place for several SCSI 12747 objects on SCSI events such as LU resets and power-on resets. 12749 Since iSCSI defines a target cold reset as a protocol-equivalent 12750 to a target power-cycle, the iSCSI target cold reset must also be 12751 considered as the power-on reset event in interpreting the actions 12752 defined in the SCSI standards. 12754 When the iSCSI session is reconstructed (between the same SCSI 12755 ports with the same nexus identifier) reestablishing the same I_T 12756 nexus, all SCSI objects that are defined to not clear on the "I_T 12757 nexus loss" notification event, such as persistent reservations, 12758 are automatically associated to this new session. 12760 Acknowledgments 12762 Several individuals on the original IPS Working Group made 12763 significant contributions to the original RFCs 3720, 3980, 4850 12764 and 5048. 12766 Specifically, the authors of the original RFCs - which this draft 12767 consolidates into a single document - were the following: 12769 RFC 3720: Julian Satran, Kalman Meth, Costa Sapuntzakis, 12770 Mallikarjun Chadalapaka, Efri Zeidner 12772 RFC 3980: Marjorie Krueger, Mallikarjun Chadalapaka, Rob Elliott 12774 RFC 4850: David Wysochanski 12776 RFC 5048: Mallikarjun Chadalapaka 12778 Many thanks to Fred Knight for contributing to the UML notations 12779 and drawings in this draft. 12781 We would in addition like to acknowledge the following individuals 12782 who contributed to this revised draft: David Harrington, Paul 12783 Koning, Mark Edwards. Finally, this draft also benefited from 12784 significant review contributions from the Storm Working Group. 12786 Authors' Addresses 12788 Mallikarjun Chadalapaka 12789 Microsoft 12790 One Microsoft Way 12791 Redmond WA 98052 USA 12792 E-mail: cbm@chadalapaka.com 12794 Julian Satran 12795 Infinidat Ltd. 12796 E-mail: julians@infinidat.com, julian@satran.net 12798 Kalman Meth 12799 IBM Haifa Research Lab 12800 Haifa University Campus - Mount Carmel 12801 Haifa 31905, Israel 12802 Phone +972.4.829.6341 12803 E-mail: meth@il.ibm.com 12805 David L. Black, 12806 EMC Corporation, 12807 176 South St., Hopkinton, MA 01748 12808 Phone +1 (508) 293-7953 12809 Email: david.black@emc.com 12811 Comments may be sent to Mallikarjun Chadalapaka 12813 Acknowledgement 12815 Funding for the RFC Editor function is currently provided by the 12816 Internet Society