idnits 2.17.1 draft-ietf-storm-iscsi-cons-02.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 updates RFC3721, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3980, 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 2837 -- Looks like a reference, but probably isn't: '7' on line 6658 -- Looks like a reference, but probably isn't: '0' on line 6658 == Missing Reference: 'MaxMissingDPDU' is mentioned on line 11775, but not defined == Missing Reference: 'MaxOutStandingR2T' is mentioned on line 11783, but not defined == Missing Reference: 'MaxMissingSPDU' is mentioned on line 11796, but not defined == Missing Reference: 'MaxSupportedConns' is mentioned on line 11806, but not defined == Unused Reference: 'RFC791' is defined on line 10755, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 10758, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 10761, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 10764, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 10776, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 10787, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 10806, but no explicit reference was found in the text == Unused Reference: 'RFC3980' is defined on line 10825, but no explicit reference was found in the text == Unused Reference: 'RFC5646' is defined on line 10850, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 10861, but no explicit reference was found in the text == Unused Reference: 'RFC4173' is defined on line 10889, but no explicit reference was found in the text == Unused Reference: 'CRC' is defined on line 10899, but no explicit reference was found in the text == Unused Reference: 'RFC3347' is defined on line 10901, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 10928, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OUI' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 3980 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 4850 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 5048 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- 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 5046 (Obsoleted by RFC 7145) Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 21 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-02.txt 4 Intended status: Proposed Standard Julian Satran 5 Expires: September 2011 6 Updates: 3720, 3721, 3980, 4850, 5048 Kalman Meth 7 IBM 9 iSCSI Protocol (Consolidated) 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 11, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This document describes a transport protocol for SCSI that works 52 on top of TCP. The iSCSI protocol aims to be fully compliant with 53 the standardized SCSI Architecture Model (SAM). RFC 3720 defined 54 the original iSCSI protocol. RFC 3721 discusses iSCSI Naming 55 examples and discovery techniques. Subsequently, RFC 3980 added 56 an additional naming format to iSCSI protocol. RFC 4850 followed 57 up by adding a new public extension key to iSCSI. RFC 5048 58 offered a number of clarifications and a few improvements and 59 corrections to the original iSCSI protocol. 61 This document consolidates RFCs 3720, 3980, 4850 and 5048 into a 62 single document and makes additional updates to the consolidated 63 specification. This document also updates RFC 3721. The text in 64 this document thus supersedes the text in RFCs 3720, 3721, 3980, 65 4850 and 5048 whenever there is such a question. 67 1. Introduction.................................................... 14 69 2. Definitions and Acronyms........................................ 15 70 2.1. Definitions ................................................. 15 71 2.2. Acronyms .................................................... 21 72 2.3. Conventions ................................................. 23 73 2.3.1. Word Rule ............................................... 24 74 2.3.2. Half-Word Rule .......................................... 25 75 2.3.3. Byte Rule ............................................... 25 76 3. UML Conventions................................................. 26 77 3.1. UML Conventions Overview ...................................26 78 3.2. Multiplicity Notion ........................................26 79 3.3. Class Diagram Conventions ..................................27 80 3.4. Class Diagram Notation for Associations ....................28 81 3.5. Class Diagram Notation for Aggregations ....................29 82 3.6. Class Diagram Notation for Generalizations .................29 83 4. Overview........................................................ 31 84 4.1. SCSI Concepts ............................................... 31 85 4.2. iSCSI Concepts and Functional Overview ...................... 32 86 4.2.1. Layers and Sessions ..................................... 33 87 4.2.2. Ordering and iSCSI Numbering ............................ 33 88 4.2.2.1. Command Numbering and Acknowledging ..................34 89 4.2.2.2. Response/Status Numbering and Acknowledging ..........38 90 4.2.2.3. Response Ordering ....................................39 91 4.2.2.3.1. Need for Response Ordering .......................39 92 4.2.2.3.2. Response Ordering Model Description ..............39 93 4.2.2.3.3. iSCSI Semantics with the Interface Model .........40 94 4.2.2.3.4. Current List of Fenced Response Use Cases ........40 95 4.2.2.4. Data Sequencing ......................................42 96 4.2.3. iSCSI Task Management ................................... 42 97 4.2.3.1. Task Management Overview .............................42 98 4.2.3.2. Notion of Affected Tasks .............................43 99 4.2.3.3. Standard Multi-task Abort Semantics ..................43 100 4.2.3.4. FastAbort Multi-task Abort Semantics ................45 101 4.2.3.5. Affected Tasks Shared across Standard and FastAbort 102 Sessions .....................................................47 103 4.2.3.6. Rationale behind the FastAbort Semantics ............48 104 4.2.4. iSCSI Login .............................................49 105 4.2.5. iSCSI Full Feature Phase ................................51 106 4.2.5.1. Command Connection Allegiance .......................51 107 4.2.5.2. Data Transfer Overview ..............................52 108 4.2.5.3. Tags and Integrity Checks ...........................54 109 4.2.5.4. Task Management .....................................54 110 4.2.6. iSCSI Connection Termination ............................55 111 4.2.7. iSCSI Names .............................................55 112 4.2.7.1. iSCSI Name Properties ...............................56 113 4.2.7.2. iSCSI Name Encoding .................................58 114 4.2.7.3. iSCSI Name Structure ................................59 115 4.2.7.4. Type "iqn." (iSCSI Qualified Name) ..................60 116 4.2.7.5. Type "eui." (IEEE EUI-64 format) ....................62 117 4.2.7.6. Type "naa." - Network Address Authority .............63 118 4.2.8. Persistent State ........................................64 119 4.2.9. Message Synchronization and Steering ....................64 120 4.2.9.1. Sync/Steering and iSCSI PDU Length ..................65 121 4.3. iSCSI Session Types .........................................66 122 4.4. SCSI to iSCSI Concepts Mapping Model ........................66 123 4.4.1. iSCSI Architecture Model ................................67 124 4.4.2. SCSI Architecture Model .................................70 125 4.4.3. Consequences of the Model ...............................72 126 4.4.3.1. I_T Nexus State .....................................74 127 4.5. iSCSI UML Model .............................................74 128 4.6. Request/Response Summary ....................................77 129 4.6.1. Request/Response Types Carrying SCSI Payload ............77 130 4.6.1.1. SCSI-Command ........................................77 131 4.6.1.2. SCSI-Response .......................................78 132 4.6.1.3. Task Management Function Request ....................78 133 4.6.1.4. Task Management Function Response ...................79 134 4.6.1.5. SCSI Data-out and SCSI Data-in ......................79 135 4.6.1.6. Ready To Transfer (R2T) .............................80 137 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload ......81 138 4.6.2.1. Asynchronous Message ................................81 139 4.6.3. Requests/Responses Carrying iSCSI Only Payload ..........81 140 4.6.3.1. Text Request and Text Response ......................81 141 4.6.3.2. Login Request and Login Response ....................82 142 4.6.3.3. Logout Request and Response .........................83 143 4.6.3.4. SNACK Request .......................................83 144 4.6.3.5. Reject ..............................................83 145 4.6.3.6. NOP-Out Request and NOP-In Response .................84 146 5. SCSI Mode Parameters for iSCSI................................. 85 148 6. Login and Full Feature Phase Negotiation....................... 86 149 6.1. Text Format ................................................ 87 150 6.2. Text Mode Negotiation ...................................... 92 151 6.2.1. List negotiations ...................................... 96 152 6.2.2. Simple-value Negotiations .............................. 97 153 6.3. Login Phase ................................................ 97 154 6.3.1. Login Phase Start ..................................... 101 155 6.3.2. iSCSI Security Negotiation ............................ 104 156 6.3.3. Operational Parameter Negotiation During the Login Phase105 157 6.3.4. Connection Reinstatement .............................. 106 158 6.3.5. Session Reinstatement, Closure, and Timeout ........... 106 159 6.3.5.1. Loss of Nexus Notification ........................ 107 160 6.3.6. Session Continuation and Failure ...................... 108 161 6.4. Operational Parameter Negotiation Outside the Login Phase . 108 162 7. iSCSI Error Handling and Recovery............................. 110 163 7.1. Overview ...................................................110 164 7.1.1. Background .............................................110 165 7.1.2. Goals ..................................................110 166 7.1.3. Protocol Features and State Expectations ...............111 167 7.1.4. Recovery Classes .......................................112 168 7.1.4.1. Recovery Within-command ............................113 169 7.1.4.2. Recovery Within-connection .........................114 170 7.1.4.3. Connection Recovery ................................115 171 7.1.4.4. Session Recovery ...................................116 173 7.1.5. Error Recovery Hierarchy ..............................116 174 7.2. Retry and Reassign in Recovery ............................118 175 7.2.1. Usage of Retry ........................................119 176 7.2.2. Allegiance Reassignment ...............................119 177 7.3. Usage Of Reject PDU in Recovery ...........................121 178 7.4. Error Recovery Considerations for Discovery Sessions ......121 179 7.4.1. ErrorRecoveryLevel for Discovery Sessions .............121 180 7.4.2. Reinstatement Semantics for Discovery Sessions ........122 181 7.4.2.1. Unnamed Discovery Sessions ........................123 182 7.4.2.2. Named Discovery Session ...........................123 183 7.4.3. Target PDUs During Discovery ..........................123 184 7.5. Connection Timeout Management .............................124 185 7.5.1. Timeouts on Transport Exception Events ................124 186 7.5.2. Timeouts on Planned Decommissioning ...................124 187 7.6. Implicit Termination of Tasks .............................125 188 7.7. Format Errors .............................................126 189 7.8. Digest Errors .............................................126 190 7.9. Sequence Errors ...........................................128 191 7.10. Message Error Checking ...................................129 192 7.11. SCSI Timeouts ............................................129 193 7.12. Negotiation Failures .....................................130 194 7.13. Protocol Errors ..........................................131 195 7.14. Connection Failures ......................................131 196 7.15. Session Errors ...........................................132 197 8. State Transitions............................................ 134 198 8.1. Standard Connection State Diagrams ........................134 199 8.1.1. State Descriptions for Initiators and Targets .........134 200 8.1.2. State Transition Descriptions for Initiators and Targets135 201 8.1.3. Standard Connection State Diagram for an Initiator ....139 202 8.1.4. Standard Connection State Diagram for a Target ........141 203 8.2. Connection Cleanup State Diagram for Initiators and Targets143 204 8.2.1. State Descriptions for Initiators and Targets .........145 205 8.2.2. State Transition Descriptions for Initiators and Targets146 206 8.3. Session State Diagrams ....................................148 207 8.3.1. Session State Diagram for an Initiator ................148 208 8.3.2. Session State Diagram for a Target ...................149 209 8.3.3. State Descriptions for Initiators and Targets ........150 210 8.3.4. State Transition Descriptions for Initiators and Targets 151 211 9. Security Considerations......................................153 212 9.1. iSCSI Security Mechanisms ................................153 213 9.2. In-band Initiator-Target Authentication ..................154 214 9.2.1. CHAP Considerations ..................................155 215 9.2.2. SRP Considerations ...................................157 216 9.3. IPsec ....................................................158 217 9.3.1. Data Integrity and Authentication ....................158 218 9.3.2. Confidentiality ......................................159 219 9.3.3. Policy, Security Associations, and Cryptographic Key 220 Management ..................................................159 221 9.4. Security Considerations for the X#NodeArchitecture Key ...161 222 10. Notes to Implementers.......................................164 223 10.1. Multiple Network Adapters ...............................164 224 10.1.1. Conservative Reuse of ISIDs .........................164 225 10.1.2. iSCSI Name, ISID, and TPGT Use ......................165 226 10.2. Autosense and Auto Contingent Allegiance (ACA) ..........167 227 10.3. iSCSI Timeouts ..........................................167 228 10.4. Command Retry and Cleaning Old Command Instances ........168 229 10.5. Synch and Steering Layer and Performance ................169 230 10.6. Considerations for State-dependent Devices and Long-lasting 231 SCSI Operations ...............................................169 232 10.6.1. Determining the Proper ErrorRecoveryLevel ...........170 233 10.7. Multi-task Abort Implementation Considerations ..........171 234 11. iSCSI PDU Formats...........................................172 235 11.1. iSCSI PDU Length and Padding ............................172 236 11.2. PDU Template, Header, and Opcodes .......................172 237 11.2.1. Basic Header Segment (BHS) ..........................173 238 11.2.1.1. I ...............................................174 239 11.2.1.2. Opcode ..........................................174 240 11.2.1.3. Final (F) bit ...................................176 241 11.2.1.4. Opcode-specific Fields ..........................176 242 11.2.1.5. TotalAHSLength ..................................176 243 11.2.1.6. DataSegmentLength ...............................176 244 11.2.1.7. LUN .............................................176 245 11.2.1.8. Initiator Task Tag ..............................177 246 11.2.2. Additional Header Segment (AHS) .....................177 247 11.2.2.1. AHSType .........................................177 248 11.2.2.2. AHSLength .......................................178 249 11.2.2.3. Extended CDB AHS ................................178 250 11.2.2.4. Bidirectional Expected Read-Data Length AHS .....178 251 11.2.3. Header Digest and Data Digest .......................179 252 11.2.4. Data Segment ........................................179 253 11.3. SCSI Command ............................................179 254 11.3.1. Flags and Task Attributes (byte 1) ..................180 255 11.3.2. CmdSN - Command Sequence Number .....................181 256 11.3.3. ExpStatSN ...........................................182 257 11.3.4. Expected Data Transfer Length .......................182 258 11.3.5. CDB - SCSI Command Descriptor Block .................183 259 11.3.6. Data Segment - Command Data .........................183 260 11.4. SCSI Response ...........................................183 261 11.4.1. Flags (byte 1) ......................................184 262 11.4.2. Status ..............................................185 263 11.4.3. Response ............................................186 264 11.4.4. SNACK Tag ...........................................187 265 11.4.5. Residual Count ......................................187 266 11.4.5.1. Field Semantics .................................187 267 11.4.5.2. Residuals Concepts Overview .....................188 268 11.4.5.3. SCSI REPORT LUNS and Residual Overflow ..........188 269 11.4.6. Bidirectional Read Residual Count ...................190 270 11.4.7. Data Segment - Sense and Response Data Segment ......190 271 11.4.7.1. SenseLength .....................................191 272 11.4.7.2. Sense Data ......................................191 273 11.4.8. ExpDataSN ...........................................192 274 11.4.9. StatSN - Status Sequence Number .....................192 275 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator .193 276 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator .......193 277 11.5. Task Management Function Request ........................194 278 11.5.1. Function ............................................194 279 11.5.2. TotalAHSLength and DataSegmentLength ................198 280 11.5.3. LUN .................................................198 281 11.5.4. Referenced Task Tag .................................198 282 11.5.5. RefCmdSN ............................................198 283 11.5.6. ExpDataSN ...........................................199 284 11.6. Task Management Function Response .......................199 285 11.6.1. Response ............................................200 286 11.6.2. TotalAHSLength and DataSegmentLength ................202 287 11.7. SCSI Data-out & SCSI Data-in ............................202 288 11.7.1. F (Final) Bit .......................................205 289 11.7.2. A (Acknowledge) bit .................................205 290 11.7.3. Flags (byte 1) ......................................206 291 11.7.4. Target Transfer Tag and LUN .........................207 292 11.7.5. DataSN ..............................................207 293 11.7.6. Buffer Offset .......................................207 294 11.7.7. DataSegmentLength ...................................208 295 11.8. Ready To Transfer (R2T) .................................209 296 11.8.1. TotalAHSLength and DataSegmentLength ................211 297 11.8.2. R2TSN ...............................................211 298 11.8.3. StatSN ..............................................211 299 11.8.4. Desired Data Transfer Length and Buffer Offset ......211 300 11.8.5. Target Transfer Tag .................................211 301 11.9. Asynchronous Message ....................................212 302 11.9.1. AsyncEvent ..........................................214 303 11.9.2. AsyncVCode ..........................................217 304 11.9.3. LUN .................................................217 305 11.9.4. Sense Data and iSCSI Event Data .....................217 306 11.9.4.1. SenseLength .....................................217 307 11.10. Text Request ...........................................218 308 11.10.1. F (Final) Bit ......................................219 309 11.10.2. C (Continue) Bit ...................................219 310 11.10.3. Initiator Task Tag .................................219 311 11.10.4. Target Transfer Tag ................................219 312 11.10.5. Text ...............................................220 313 11.11. Text Response ..........................................221 314 11.11.1. F (Final) Bit ......................................222 315 11.11.2. C (Continue) Bit ...................................223 316 11.11.3. Initiator Task Tag .................................223 317 11.11.4. Target Transfer Tag ................................223 318 11.11.5. StatSN .............................................224 319 11.11.6. Text Response Data .................................224 320 11.12. Login Request ..........................................224 321 11.12.1. T (Transit) Bit ....................................225 322 11.12.2. C (Continue) Bit ...................................226 323 11.12.3. CSG and NSG ........................................226 324 11.12.4. Version ............................................226 325 11.12.4.1. Version-max ....................................226 326 11.12.4.2. Version-min ....................................227 327 11.12.5. ISID ...............................................227 328 11.12.6. TSIH ...............................................229 329 11.12.7. Connection ID - CID ................................229 330 11.12.8. CmdSN ..............................................229 331 11.12.9. ExpStatSN ..........................................230 332 11.12.10. Login Parameters ..................................230 333 11.13. Login Response .........................................231 334 11.13.1. Version-max ........................................231 335 11.13.2. Version-active .....................................232 336 11.13.3. TSIH ...............................................232 337 11.13.4. StatSN .............................................232 338 11.13.5. Status-Class and Status-Detail .....................233 339 11.13.6. T (Transit) bit ....................................236 340 11.13.7. C (Continue) Bit ...................................237 341 11.13.8. Login Parameters ...................................237 342 11.14. Logout Request .........................................237 343 11.14.1. Reason Code ........................................240 344 11.14.2. TotalAHSLength and DataSegmentLength ...............241 345 11.14.3. CID ................................................241 346 11.14.4. ExpStatSN ..........................................241 347 11.14.5. Implicit termination of tasks ......................241 348 11.15. Logout Response ........................................242 349 11.15.1. Response ...........................................243 350 11.15.2. TotalAHSLength and DataSegmentLength ............... 244 351 11.15.3. Time2Wait .......................................... 244 352 11.15.4. Time2Retain ........................................ 244 353 11.16. SNACK Request .......................................... 246 354 11.16.1. Type ............................................... 247 355 11.16.2. Data Acknowledgement ............................... 248 356 11.16.3. Resegmentation ..................................... 248 357 11.16.4. Initiator Task Tag ................................. 249 358 11.16.5. Target Transfer Tag or SNACK Tag ................... 249 359 11.16.6. BegRun ............................................. 250 360 11.16.7. RunLength .......................................... 250 361 11.17. Reject ................................................. 251 362 11.17.1. Reason ............................................. 252 363 11.17.2. DataSN/R2TSN ....................................... 253 364 11.17.3. StatSN, ExpCmdSN and MaxCmdSN ...................... 253 365 11.17.4. Complete Header of Bad PDU ......................... 254 366 11.18. NOP-Out ................................................ 254 367 11.18.1. Initiator Task Tag ................................. 255 368 11.18.2. Target Transfer Tag ................................ 255 369 11.18.3. Ping Data .......................................... 256 370 11.19. NOP-In ................................................. 257 371 11.19.1. Target Transfer Tag ................................ 258 372 11.19.2. StatSN ............................................. 258 373 11.19.3. LUN ................................................ 258 374 12. iSCSI Security Text Keys and Authentication Methods..........259 375 12.1. AuthMethod .............................................. 259 376 12.1.1. Kerberos ............................................ 261 377 12.1.2. Secure Remote Password (SRP) ........................ 262 378 12.1.3. Challenge Handshake Authentication Protocol (CHAP) .. 263 379 13. Login/Text Operational Text Keys.............................266 380 13.1. HeaderDigest and DataDigest ........................... 266 381 13.2. MaxConnections ........................................ 269 382 13.3. SendTargets ........................................... 269 383 13.4. TargetName ............................................ 270 384 13.5. InitiatorName ......................................... 270 385 13.6. TargetAlias ..............................................271 386 13.7. InitiatorAlias ...........................................271 387 13.8. TargetAddress ............................................272 388 13.9. TargetPortalGroupTag .....................................273 389 13.10. InitialR2T ..............................................274 390 13.11. ImmediateData ...........................................274 391 13.12. MaxRecvDataSegmentLength ................................275 392 13.13. MaxBurstLength ..........................................276 393 13.14. FirstBurstLength ........................................276 394 13.15. DefaultTime2Wait ........................................277 395 13.16. DefaultTime2Retain ......................................277 396 13.17. MaxOutstandingR2T .......................................278 397 13.18. DataPDUInOrder ..........................................278 398 13.19. DataSequenceInOrder .....................................279 399 13.20. ErrorRecoveryLevel ......................................280 400 13.21. SessionType .............................................280 401 13.22. The Private or Public Extension Key Format ..............281 402 13.23. Task Reporting ..........................................281 403 13.24. iSCSIProtocolLevel Negotiation ..........................282 404 13.25. Obsoleted Keys ..........................................283 405 13.26. X#NodeArchitecture ......................................283 406 13.26.1. Definition ..........................................283 407 13.26.2. Implementation Requirements .........................284 408 14. IANA Considerations..........................................285 410 Appendix A. Examples ............................................291 411 Read Operation Example .........................................291 412 Write Operation Example ........................................292 413 R2TSN/DataSN Use Examples ......................................292 414 CRC Examples ...................................................296 415 Appendix B. Login Phase Examples ................................298 417 Appendix C. SendTargets Operation .............................. 308 419 Appendix D. Algorithmic Presentation of Error Recovery Classes . 313 420 D.2.1. Procedure Descriptions ............................... 316 421 Appendix E. Clearing Effects of Various Events on Targets ...... 332 422 1. Introduction 424 The Small Computer Systems Interface (SCSI) is a popular family of 425 protocols for communicating with I/O devices, especially storage 426 devices. SCSI is a client-server architecture. Clients of a SCSI 427 interface are called "initiators". Initiators issue SCSI 428 "commands" to request services from components, logical units of a 429 server known as a "target". A "SCSI transport" maps the client- 430 server SCSI protocol to a specific interconnect. An Initiator is 431 one endpoint of a SCSI transport and a target is the other 432 endpoint. 434 The SCSI protocol has been mapped over various transports, 435 including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre 436 Channel. These transports are I/O specific and have limited 437 distance capabilities. 439 The iSCSI protocol defined in this document describes a means of 440 transporting of the SCSI packets over TCP/IP, providing for an 441 interoperable solution which can take advantage of existing 442 Internet infrastructure, Internet management facilities and 443 address distance limitations. 445 2. Definitions and Acronyms 447 2.1. Definitions 449 - Alias: An alias string can also be associated with an iSCSI 450 Node. The alias allows an organization to associate a user- 451 friendly string with the iSCSI Name. However, the alias string is 452 not a substitute for the iSCSI Name. 454 - CID (Connection ID): Connections within a session are identified 455 by a connection ID. It is a unique ID for this connection within 456 the session for the initiator. It is generated by the initiator 457 and presented to the target during login requests and during 458 logouts that close connections. 460 - Connection: A connection is a TCP connection. Communication 461 between the initiator and target occurs over one or more TCP 462 connections. The TCP connections carry control messages, SCSI 463 commands, parameters, and data within iSCSI Protocol Data Units 464 (iSCSI PDUs). 466 - I/O Buffer:A buffer that is used in a SCSI Read or Write 467 operation so SCSI data may be sent from or received into that 468 buffer. For a read or write data transfer to take place for a 469 task, an I/O Buffer is required on the initiator and at least one 470 is required on the 471 target. 473 - INCITS: INCITS stands for InterNational Committee of Information 474 Technology Standards. The INCITS has a broad standardization scope 475 within the field of Information and Communications Technologies 476 (ICT), encompassing storage, processing, transfer, display, 477 management, organization, and retrieval of information. INCITS 478 serves as ANSI's Technical Advisory Group for the ISO/IEC Joint 479 Technical Committee 1 (JTC 1). See http://www.incits.org. 481 - InfiniBand: An I/O architecture originally intended to replace 482 PCI and to address high performance server interconnectivity [IB]. 484 - iSCSI Device: A SCSI Device using an iSCSI service delivery 485 subsystem. Service Delivery Subsystem is defined by [SAM2] as a 486 transport mechanism for SCSI commands and responses. 488 - iSCSI Initiator Name: The iSCSI Initiator Name specifies the 489 worldwide unique name of the initiator. 491 - iSCSI Initiator Node: The "initiator" device. The word 492 "initiator" has been appropriately qualified as either a port or a 493 device in the rest of the document when the context is ambiguous. 494 All unqualified usages of "initiator" refer to an initiator port 495 (or device) depending on the context. 497 - iSCSI Layer: This layer builds/receives iSCSI PDUs and 498 relays/receives them to/from one or more TCP connections that form 499 an initiator-target "session". 501 - iSCSI Name: The name of an iSCSI initiator or iSCSI target. 503 - iSCSI Node: The iSCSI Node represents a single iSCSI initiator 504 or iSCSI target or a single instance of each. There are one or 505 more iSCSI Nodes within a Network Entity. The iSCSI Node is 506 accessible via one or more Network Portals. An iSCSI Node is 507 identified by its iSCSI Name. The separation of the iSCSI Name 508 from the addresses used by and for the iSCSI Node allows multiple 509 iSCSI nodes to use the same address, and the same iSCSI node to 510 use multiple addresses. 512 - iSCSI Target Name: The iSCSI Target Name specifies the worldwide 513 unique name of the target. 515 - iSCSI Target Node: The "target" device. The word "target" has 516 been appropriately qualified as either a port or a device in the 517 rest of the document when the context is ambiguous. All 518 unqualified usages of "target" refer to a target port (or device) 519 depending on the context. 521 - iSCSI Task: An iSCSI task is an iSCSI request for which a 522 response is expected. 524 - iSCSI Transfer Direction: The iSCSI transfer direction is 525 defined with regard to the initiator. Outbound or outgoing 526 transfers are transfers from the initiator to the target, while 527 inbound or incoming transfers are from the target to the 528 initiator. 530 - ISID: The initiator part of the Session Identifier. It is 531 explicitly specified by the initiator during Login. 533 - I_T nexus: According to [SAM2], the I_T nexus is a relationship 534 between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, 535 this relationship is a session, defined as a relationship between 536 an iSCSI Initiator's end of the session (SCSI Initiator Port) and 537 the iSCSI Target's Portal Group. The I_T nexus can be identified 538 by the conjunction of the SCSI port names; that is, the I_T nexus 539 identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI 540 Target Name + ',t,'+ Portal Group Tag). 542 - NAA: Network Address Authority, a naming format defined by the 543 INCITS T11 Fibre Channel protocols [FC-FS]. 545 - Network Entity: The Network Entity represents a device or 546 gateway that is accessible from the IP network. A Network Entity 547 must have one or more Network Portals, each of which can be used 548 to gain access to the IP network by some iSCSI Nodes contained in 549 that Network Entity. 551 - Network Portal: The Network Portal is a component of a Network 552 Entity that has a TCP/IP network address and that may be used by 553 an iSCSI Node within that Network Entity for the connection(s) 554 within one of its iSCSI sessions. A Network Portal in an initiator 555 is identified by its IP address. A Network Portal in a target is 556 identified by its IP address and its listening TCP port. 558 - Originator: In a negotiation or exchange, the party that 559 initiates the negotiation or exchange. 561 - PDU (Protocol Data Unit): The initiator and target divide their 562 communications into messages. The term "iSCSI protocol data unit" 563 (iSCSI PDU) is used for these messages. 565 - Portal Groups: iSCSI supports multiple connections within the 566 same session; some implementations will have the ability to 567 combine connections in a session across multiple Network Portals. 569 A Portal Group defines a set of Network Portals within an iSCSI 570 Network Entity that collectively supports the capability of 571 coordinating a session with connections spanning these portals. 572 Not all Network Portals within a Portal Group need participate in 573 every session connected through that Portal Group. One or more 574 Portal Groups may provide access to an iSCSI Node. Each Network 575 Portal, as utilized by a given iSCSI Node, belongs to exactly one 576 portal group within that node. 578 - Portal Group Tag: This 16-bit quantity identifies a Portal Group 579 within an iSCSI Node. All Network Portals with the same portal 580 group tag in the context of a given iSCSI Node are in the same 581 Portal Group. 583 - Recovery R2T: An R2T generated by a target upon detecting the 584 loss of one or more Data-Out PDUs through one of the following 585 means: a digest error, a sequence error, or a sequence reception 586 timeout. A recovery R2T carries the next unused R2TSN, but 587 requests all or part of the data burst that an earlier R2T (with a 588 lower R2TSN) had already requested. 590 - Responder: In a negotiation or exchange, the party that responds 591 to the originator of the negotiation or exchange. 593 - SAS: Serial Attached SCSI. The Serial Attached SCSI (SAS) 594 standard 595 contains both a physical layer compatible with Serial ATA, and 596 protocols for transporting SCSI commands to SAS devices and ATA 597 commands to SATA devices [SAS]. 599 - SCSI Device: This is the SAM2 term for an entity that contains 600 one or more SCSI ports that are connected to a service delivery 601 subsystem and supports a SCSI application protocol. For example, a 602 SCSI Initiator Device contains one or more SCSI Initiator Ports 603 and zero or more application clients. A Target Device contains one 604 or more SCSI Target Ports and one or more device servers and 605 associated logical units. For iSCSI, the SCSI Device is the 606 component within an iSCSI Node that provides the SCSI 607 functionality. As such, there can be, at most, one SCSI Device 608 within a given iSCSI Node. Access to the SCSI Device can only be 609 achieved in an iSCSI normal operational session. The SCSI Device 610 Name is defined to be the iSCSI Name of the node. 612 - SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor 613 Blocks) and relays/receives them with the remaining command 614 execute [SAM2] parameters to/from the iSCSI Layer. 616 - Session: The group of TCP connections that link an initiator 617 with a target form a session (loosely equivalent to a SCSI I-T 618 nexus). TCP connections can be added and removed from a session. 619 Across all connections within a session, an initiator sees one and 620 the same target. 622 - SCSI Initiator Port: This maps to the endpoint of an iSCSI 623 normal operational session. An iSCSI normal operational session is 624 negotiated through the login process between an iSCSI initiator 625 node and an iSCSI target node. At successful completion of this 626 process, a SCSI Initiator Port is created within the SCSI 627 Initiator Device. The SCSI Initiator Port Name and SCSI Initiator 628 Port Identifier are both defined to be the iSCSI Initiator Name 629 together with (a) a label that identifies it as an initiator port 630 name/identifier and (b) the ISID portion of the session 631 identifier. 633 - SCSI Port: This is the SAM2 term for an entity in a SCSI Device 634 that provides the SCSI functionality to interface with a service 635 delivery subsystem. For iSCSI, the definition of the SCSI 636 Initiator Port and the SCSI Target Port are different. 638 - SCSI Port Name: A name made up as UTF-8 characters and includes 639 the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag. 641 - SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 642 aggregate data length of the data that the SCSI layer logically 643 "presents" to the iSCSI layer for a Data-In or Data-Out transfer 644 in the context of a SCSI task. For a bidirectional task, there are 645 two SPDTL values -- one for Data-In and one for Data-Out. Note 646 that the notion of "presenting" includes immediate data per the 647 data transfer model in [SAM2], and excludes overlapping data 648 transfers, if any, requested by the SCSI layer. 650 - SCSI Target Port: This maps to an iSCSI Target Portal Group. 652 - SCSI Target Port Name and SCSI Target Port Identifier: These are 653 both defined to be the iSCSI Target Name together with (a) a label 654 that identifies it as a target port name/identifier and (b) the 655 portal group tag. 657 - SRP: SCSI RDMA Protocol. SRP defines a SCSI protocol mapping 658 onto the InfiniBand (tm) Architecture and/or functionally similar 659 Remote DMA-capable protocols [SRP]. 661 - SSID (Session ID): A session between an iSCSI initiator and an 662 iSCSI target is defined by a session ID that is a tuple composed 663 of an initiator part (ISID) and a target part (Target Portal Group 664 Tag). The ISID is explicitly specified by the initiator at session 665 establishment. The Target Portal Group Tag is implied by the 666 initiator through the selection of the TCP endpoint at connection 667 establishment. The TargetPortalGroupTag key must also be returned 668 by the target as a confimation during connection establishment. 670 - T10: A technical committee within INCITS that develops standards 671 and technical reports on I/O interfaces, particularly the series 672 of SCSI (Small Computer Systems Interface) standards. See 673 http://www.t10.org. 675 - T11: A technical committee within INCITS responsible for 676 standards development in the areas of Intelligent Peripheral 677 Interface (IPI), High-Performance Parallel Interface (HIPPI) and 678 Fibre Channel (FC). See http://www.t11.org. 680 - Target Portal Group Tag: A numerical identifier (16-bit) for an 681 iSCSI Target Portal Group. 683 - Third-party: A term used in this document to denote nexus 684 objects (I_T or I_T_L) and iSCSI sessions that reap the side 685 effects of actions that take place in the context of a separate 686 iSCSI session, while being third parties to the action that caused 687 the side effects. One example of a third-party session is an 688 iSCSI session hosting an I_T_L nexus to an LU that is reset with 689 an LU Reset TMF via a separate I_T nexus. 691 - TSIH (Target Session Identifying Handle): A target assigned tag 692 for a session with a specific named initiator. The target 693 generates it during session establishment. Other than defining it 694 as a 16 bit binary string, its internal format and content are not 695 defined by this protocol but for the all 0 value that is reserved 696 and used by the initiator to indicate a new session. It is given 697 to the target during additional connection establishment for the 698 same session. 700 2.2. Acronyms 702 Acronym Definition 703 -------------------------------------------------------------- 704 3DES Triple Data Encryption Standard 705 ACA Auto Contingent Allegiance 706 AEN Asynchronous Event Notification 707 AES Advanced Encryption Standard 708 AH Additional Header (not the IPsec AH!) 709 AHS Additional Header Segment 710 API Application Programming Interface 711 ASC Additional Sense Code 712 ASCII American Standard Code for Information Interchange 713 ASCQ Additional Sense Code Qualifier 714 BHS Basic Header Segment 715 CBC Cipher Block Chaining 716 CD Compact Disk 717 CDB Command Descriptor Block 718 CHAP Challenge Handshake Authentication Protocol 719 CID Connection ID 720 CO Connection Only 721 CRC Cyclic Redundancy Check 722 CRL Certificate Revocation List 723 CSG Current Stage 724 CSM Connection State Machine 725 DES Data Encryption Standard 726 DNS Domain Name Server 727 DOI Domain of Interpretation 728 DVD Digital Versatile Disk 729 EDTL Expected Data Transfer Length 730 ESP Encapsulating Security Payload 731 EUI Extended Unique Identifier 732 FFP Full Feature Phase 734 FFPO Full Feature Phase Only 735 Gbps Gigabits per Second 736 HBA Host Bus Adapter 737 HMAC Hashed Message Authentication Code 738 I_T Initiator_Target 739 I_T_L Initiator_Target_LUN 740 IANA Internet Assigned Numbers Authority 741 IB InfiniBand 742 ID Identifier 743 IDN Internationalized Domain Name 744 IEEE Institute of Electrical & Electronics Engineers 745 IETF Internet Engineering Task Force 746 IKE Internet Key Exchange 747 I/O Input-Output 748 IO Initialize Only 749 IP Internet Protocol 750 IPsec Internet Protocol Security 751 IPv4 Internet Protocol Version 4 752 IPv6 Internet Protocol Version 6 753 IQN iSCSI Qualified Name 754 iSCSI Internet SCSI 755 iSER iSCSI Extensions for RDMA 756 ISID Initiator Session ID 757 iSNS Internet Storage Name Service (see [RFC4171]) 758 ITN iSCSI Target Name 759 ITT Initiator Task Tag 760 KRB5 Kerberos V5 761 LFL Lower Functional Layer 762 LTDS Logical-Text-Data-Segment 763 LO Leading Only 764 LU Logical Unit 765 LUN Logical Unit Number 766 MAC Message Authentication Codes 767 NA Not Applicable 768 NAA Network Address Authority 769 NIC Network Interface Card 770 NOP No Operation 771 NSG Next Stage 772 OS Operating System 773 PDU Protocol Data Unit 774 PKI Public Key Infrastructure 775 R2T Ready To Transfer 776 R2TSN Ready To Transfer Sequence Number 777 RDMA Remote Direct Memory Access 778 RFC Request For Comments 779 SAM SCSI Architecture Model 780 SAM2 SCSI Architecture Model - 2 781 SAN Storage Area Network 782 SAS Serial Attached SCSI 783 SCSI Small Computer Systems Interface 784 SN Sequence Number 785 SNACK Selective Negative Acknowledgment - also 786 Sequence Number Acknowledgement for data 787 SPDTL SCSI-Presented Data Transfer Length 788 SPKM Simple Public-Key Mechanism 789 SRP Secure Remote Password, also SCSI RDMA Protocol 790 SSID Session ID 791 SW Session Wide 792 TCB Task Control Block 793 TCP Transmission Control Protocol 794 TMF Task Management Function 795 TPGT Target Portal Group Tag 796 TSIH Target Session Identifying Handle 797 TTT Target Transfer Tag 798 UFL Upper Functional Layer 799 ULP Upper Level Protocol 800 URN Uniform Resource Names 801 UTF Universal Transformation Format 802 WG Working Group 804 2.3. Conventions 806 In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator 807 and target respectively. 809 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 810 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 811 in this document are to be interpreted as described in RFC 2119 812 [RFC2119]. 814 iSCSI messages - PDUs - are represented by diagrams as in the 815 following example: 817 Byte/ 0 | 1 | 2 | 3 818 | 819 / | | | 820 | 821 |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 822 7| 823 +---------------+---------------+---------------+--------------- 824 + 825 0| Basic Header Segment (BHS) 826 | 827 +---------------+---------------+---------------+--------------- 828 + 829 ---------- 830 +| 831 | 832 +---------------+---------------+---------------+--------------- 833 + 835 The diagrams include byte and bit numbering. 837 The following representation and ordering rules are observed in 838 this document: 840 - Word Rule 842 - Half-word Rule 844 - Byte Rule 846 2.3.1. Word Rule 848 A word holds four consecutive bytes. Whenever a word has numeric 849 content, it is considered an unsigned number in base 2 positional 850 representation with the lowest numbered byte (e.g., byte 0) bit 0 851 representing 2**31 and bit 1 representing 2**30 through lowest 852 numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0. 854 Decimal and hexadecimal representation of word values map this 855 representation to decimal or hexadecimal positional notation. 857 2.3.2. Half-Word Rule 859 A half-word holds two consecutive bytes. Whenever a half-word has 860 numeric content it is considered an unsigned number in base 2 861 positional representation with the lowest numbered byte (e.g., 862 byte 0) bit 0 representing 2**15 and bit 1 representing 2**14 863 through lowest numbered byte + 1 (e.g., byte 1) bit 7 representing 864 2**0. 866 Decimal and hexadecimal representation of half-word values map 867 this representation to decimal or hexadecimal positional notation. 869 2.3.3. Byte Rule 871 For every PDU, bytes are sent and received in increasing numbered 872 order (network order). 874 Whenever a byte has numerical content it is considered an unsigned 875 number in base 2 positional representation with bit 0 representing 876 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0. 878 3. UML Conventions 880 3.1. UML Conventions Overview 882 The SCSI Architecture Model (SAM) uses class diagrams and object 883 diagrams with notation that is based on the Unified Modeling 884 Language [UML]. Therefore, this document also uses UML to model 885 the relationships for SCSI and iSCSI objects. 887 A treatise on the graphical notation used in UML is beyond the 888 scope of this document. However, given the use of ASCII drawing 889 for UML static class diagrams, a description of the notational 890 conventions used in this document is included in the remainder of 891 this section. 893 3.2. Multiplicity Notion 895 Not specified The number of instances of an attribute is not 896 specified. 898 1 One instance of the class or attribute exists. 900 0..* Zero or more instances of the class or attribute exist. 902 1..* One or more instances of the class or attribute exist. 904 0..1 Zero or one instance of the class or attribute exists. 906 n..m n to m instances of the class or attribute exist 907 (e.g., 2..8). 909 x, n..m Multiple disjoint instances of the class or 910 attribute exist (e.g., 2, 8..15). 912 3.3. Class Diagram Conventions 914 +--------------+ +--------------+ +--------------+ 915 | Class Name | | Class Name | | Class Name | 916 +--------------+ +--------------+ +--------------+ 917 | | | | 918 +--------------+ +--------------+ 919 | | 920 +--------------+ 921 The previous three diagrams are examples of a class with no 922 attributes and with no operations. 924 +-------------------+ +-------------------+ 925 | Class Name | | Class Name | 926 +-------------------+ +-------------------+ 927 | attribute 01[1] | | attribute 01[1] | 928 | attribute 02[1] | | attribute 02[1] | 929 +-------------------+ +-------------------+ 930 | | 931 +-------------------+ 932 The preceding two diagrams are examples of a class with attributes 933 and with no operations. 935 +------------------------+ 936 | Class Name | 937 +------------------------+ 938 | attribute 01[1..*] | 939 | attribute 02[1] | 940 +------------------------+ 941 | operation 01() | 942 | operation 02() | 943 +------------------------+ 944 The preceding diagram is an example of a class with attributes 945 that have a specified multiplicity and operations. 947 3.4. Class Diagram Notation for Associations 949 +-----------------+ 950 | Class A | 951 +-----------------+ association_name +-----------------+ 952 | attribute 01[1] |<------------------>| Class B | 953 | attribute 02[1] | 1..* 0..1 +-----------------+ 954 +-----------------+ | attribute 03[1] | 955 | operation 1() | +-----------------+ 956 +-----------------+ 957 The preceding diagram is an example where Class A knows about 958 Class B (i.e., read as "Class A association_name ClassB") and 959 Class B knows about Class A (i.e., read as "Class B 960 association_name Class A"). The use of association_name is 961 optional. The multiplicity notation (1..* and 0..1) indicates the 962 number of instances of the object. 964 +--------------------+ 965 | Class A | 966 +--------------------+ +--------------------+ 967 | attribute 01[1] |<-------------| Class B | 968 | attribute 02[1] | 1 0..1 +--------------------+ 969 +--------------------+ | attribute 03[1] | 970 | operation 1() | +--------------------+ 971 +--------------------+ 972 The preceding diagram is an example where Class B knows about 973 Class A (i.e., read as "Class B knows about Class A") but Class A 974 does not know about Class B. 976 +----------------------+ 977 | Class A | 978 +----------------------+ +--------------------+ 979 | attribute 01[1] |----------->| Class B | 980 | attribute 02[1] | 0..* 1 +--------------------+ 981 +----------------------+ | attribute 03[1] | 982 | operation 1() | +--------------------+ 983 +----------------------+ 984 The preceding diagram is an example where Class A knows about 985 Class B (i.e., read as "Class A knows about Class B") but Class B 986 does not know about Class A. 988 3.5. Class Diagram Notation for Aggregations 990 +---------------+ +--------------+ 991 | Class whole |o------------| Class part | 992 +---------------+ +--------------+ 993 The preceding diagram is an example where Class whole is an 994 aggregate that contains Class part and where Class part may 995 continue to exist even if Class whole is removed (i.e., read as 996 "the whole contains the part"). 998 +---------------+ +--------------+ 999 | Class whole |@------------| Class part | 1000 +---------------+ +--------------+ 1001 The preceding diagram is an example where Class whole is an 1002 aggregate that contains Class part where Class part shall only 1003 belong to one Class whole, and the Class part shall not continue 1004 to exist if the Class whole is removed (i.e., read as "the whole 1005 contains the part"). 1007 +-------------+ 1008 | | 1009 +-------------+ 1010 | | 1011 + =(a)= + 1012 | | 1013 The preceding diagram is an example where there is a constraint 1014 between the associations where the (a) footnote describes the 1015 constraint. 1017 3.6. Class Diagram Notation for Generalizations 1019 +---------------+ 1020 | Superclass | 1021 +-------^-------+ 1022 /_\ 1023 | 1024 +---------------+ 1025 | Subclass | 1026 +---------------+ 1027 The preceding diagram is an example where the subclass is a kind 1028 of superclass. A subclass shares all the attributes and 1029 operations of the superclass (i.e., the subclass inherits from the 1030 superclass). 1032 4. Overview 1034 4.1. SCSI Concepts 1036 The SCSI Architecture Model-2 [SAM2] describes in detail the 1037 architecture of the SCSI family of I/O protocols. This section 1038 provides a brief background of the SCSI architecture and is 1039 intended to familiarize readers with its terminology. 1041 At the highest level, SCSI is a family of interfaces for 1042 requesting services from I/O devices, including hard drives, tape 1043 drives, CD and DVD drives, printers, and scanners. In SCSI 1044 terminology, an individual I/O device is called a "logical unit" 1045 (LU). 1047 SCSI is a client-server architecture. Clients of a SCSI interface 1048 are called "initiators". Initiators issue SCSI "commands" to 1049 request services from components, logical units, of a server known 1050 as a "target". The "device server" on the logical unit accepts 1051 SCSI commands and processes them. 1053 A "SCSI transport" maps the client-server SCSI protocol to a 1054 specific interconnect. Initiator is one endpoint of a SCSI 1055 transport. The "target" is the other endpoint. A target can 1056 contain multiple Logical Units (LUs). Each Logical Unit has an 1057 address within a target called a Logical Unit Number (LUN). 1059 A SCSI task is a SCSI command or possibly a linked set of SCSI 1060 commands. Some LUs support multiple pending (queued) tasks, but 1061 the queue of tasks is managed by the logical unit. The target uses 1062 an initiator provided "task tag" to distinguish between tasks. 1063 Only one command in a task can be outstanding at any given time. 1065 Each SCSI command results in an optional data phase and a required 1066 response phase. In the data phase, information can travel from the 1067 initiator to target (e.g., WRITE), target to initiator (e.g., 1068 READ), or in both directions. In the response phase, the target 1069 returns the final status of the operation, including any errors. 1071 Command Descriptor Blocks (CDB) are the data structures used to 1072 contain the command parameters that an initiator sends to a 1074 target. The CDB content and structure is defined by [SAM2] and 1075 device-type specific SCSI standards. 1077 4.2. iSCSI Concepts and Functional Overview 1079 The iSCSI protocol is a mapping of the SCSI command, event and 1080 task management model (see [SAM2]) over the TCP protocol. SCSI 1081 commands are carried by iSCSI requests and SCSI responses and 1082 status are carried by iSCSI responses. iSCSI also uses the request 1083 response mechanism for iSCSI protocol mechanisms. 1085 For the remainder of this document, the terms "initiator" and 1086 "target" refer to "iSCSI initiator node" and "iSCSI target node", 1087 respectively (see iSCS) unless otherwise qualified. 1089 In keeping with similar protocols, the initiator and target divide 1090 their communications into messages. This document uses the term 1091 "iSCSI protocol data unit" (iSCSI PDU) for these messages. 1093 For performance reasons, iSCSI allows a "phase-collapse". A 1094 command and its associated data may be shipped together from 1095 initiator to target, and data and responses may be shipped 1096 together from targets. 1098 The iSCSI transfer direction is defined with respect to the 1099 initiator. Outbound or outgoing transfers are transfers from an 1100 initiator to a target, while inbound or incoming transfers are 1101 from a target to an initiator. 1103 An iSCSI task is an iSCSI request for which a response is 1104 expected. 1106 In this document "iSCSI request", "iSCSI command", request, or 1107 (unqualified) command have the same meaning. Also, unless 1108 otherwise specified, status, response, or numbered response have 1109 the same meaning. 1111 4.2.1. Layers and Sessions 1113 The following conceptual layering model is used to specify 1114 initiator and target actions and the way in which they relate to 1115 transmitted and received Protocol Data Units: 1117 the SCSI layer builds/receives SCSI CDBs (Command Descriptor 1118 Blocks) and passes/receives them with the remaining command 1119 execute parameters ([SAM2]) to/from 1120 the iSCSI layer that builds/receives iSCSI PDUs and 1121 relays/receives them to/from one or more TCP connections; 1122 the group of connections form an initiator-target 1123 "session". 1125 Communication between the initiator and target occurs over one or 1126 more TCP connections. The TCP connections carry control messages, 1127 SCSI commands, parameters, and data within iSCSI Protocol Data 1128 Units (iSCSI PDUs). The group of TCP connections that link an 1129 initiator with a target form a session (equivalent to a SCSI I_T 1130 nexus, see SCSI ). A session is defined by a session ID that is 1131 composed of an initiator part and a target part. TCP connections 1132 can be added and removed from a session. Each connection within a 1133 session is identified by a connection ID (CID). 1135 Across all connections within a session, an initiator sees one 1136 "target image". All target identifying elements, such as LUN, are 1137 the same. A target also sees one "initiator image" across all 1138 connections within a session. Initiator-identifying elements, such 1139 as the Initiator Task Tag, are global across the session 1140 regardless of the connection on which they are sent or received. 1142 iSCSI targets and initiators MUST support at least one TCP 1143 connection and MAY support several connections in a session. For 1144 error recovery purposes, targets and initiators that support a 1145 single active connection in a session SHOULD support two 1146 connections during recovery. 1148 4.2.2. Ordering and iSCSI Numbering 1150 iSCSI uses Command and Status numbering schemes and a Data 1151 sequencing scheme. 1153 Command numbering is session-wide and is used for ordered command 1154 delivery over multiple connections. It can also be used as a 1155 mechanism for command flow control over a session. 1157 Status numbering is per connection and is used to enable missing 1158 status detection and recovery in the presence of transient or 1159 permanent communication errors. 1161 Data sequencing is per command or part of a command (R2T-triggered 1162 sequence) and is used to detect missing data and/or R2T PDUs due 1163 to header digest errors. 1165 Typically, fields in the iSCSI PDUs communicate the Sequence 1166 Numbers between the initiator and target. During periods when 1167 traffic on a connection is unidirectional, iSCSI NOP-Out/In PDUs 1168 may be utilized to synchronize the command and status ordering 1169 counters of the target and initiator. 1171 The iSCSI session abstraction is equivalent to the SCSI I_T nexus, 1172 and the iSCSI session provides an ordered command delivery from 1173 the SCSI initiator to the SCSI target. For detailed design 1174 considerations that led to the iSCSI session model as it is 1175 defined here and how it relates the SCSI command ordering features 1176 defined in SCSI specifications to the iSCSI concepts see 1177 [RFC3783]. 1179 4.2.2.1. Command Numbering and Acknowledging 1181 iSCSI performs ordered command delivery within a session. All 1182 commands (initiator-to-target PDUs) in transit from the initiator 1183 to the target are numbered. 1185 iSCSI considers a task to be instantiated on the target in 1186 response to every request issued by the initiator. A set of task 1187 management operations including abort and reassign (see Section 1188 10.5 "Task Management Function Request") may be performed on any 1189 iSCSI task. 1191 Some iSCSI tasks are SCSI tasks, and many SCSI activities are 1192 related to a SCSI task ([SAM2]). In all cases, the task is 1193 identified by the Initiator Task Tag for the life of the task. 1195 The command number is carried by the iSCSI PDU as CmdSN (Command- 1196 Sequence-Number). The numbering is session-wide. Outgoing iSCSI 1197 PDUs carry this number. The iSCSI initiator allocates CmdSNs with 1198 a 32-bit unsigned counter (modulo 2**32). Comparisons and 1199 arithmetic on CmdSN use Serial Number Arithmetic as defined in 1200 [RFC1982] where SERIAL_BITS = 32. 1202 Commands meant for immediate delivery are marked with an immediate 1203 delivery flag; they MUST also carry the current CmdSN. CmdSN does 1204 not advance after a command marked for immediate delivery is sent. 1206 Command numbering starts with the first login request on the first 1207 connection of a session (the leading login on the leading 1208 connection) and command numbers are incremented by 1 for every 1209 non-immediate command issued afterwards. 1211 If immediate delivery is used with task management commands, these 1212 commands may reach the target before the tasks on which they are 1213 supposed to act. However their CmdSN serves as a marker of their 1214 position in the stream of commands. The initiator and target must 1215 ensure that the task management commands act as specified by 1216 [SAM2]. For example, both commands and responses appear as if 1217 delivered in order. Whenever CmdSN for an outgoing PDU is not 1218 specified by an explicit rule, CmdSN will carry the current value 1219 of the local CmdSN variable (see later in this section). 1221 The means by which an implementation decides to mark a PDU for 1222 immediate delivery or by which iSCSI decides by itself to mark a 1223 PDU for immediate delivery are beyond the scope of this document. 1225 The number of commands used for immediate delivery is not limited 1226 and their delivery to execution is not acknowledged through the 1227 numbering scheme. Immediate commands MAY be rejected by the iSCSI 1228 target layer due to lack of resources. An iSCSI target MUST be 1229 able to handle at least one immediate task management command and 1230 one immediate non-task-management iSCSI command per connection at 1231 any time. 1233 In this document, delivery for execution means delivery to the 1234 SCSI execution engine or an iSCSI protocol specific execution 1235 engine (e.g., for text requests with public or private extension 1236 keys involving an execution component). With the exception of the 1237 commands marked for immediate delivery, the iSCSI target layer 1238 MUST deliver the commands for execution in the order specified by 1239 CmdSN. Commands marked for immediate delivery may be delivered by 1240 the iSCSI target layer for execution as soon as detected. iSCSI 1241 may avoid delivering some commands to the SCSI target layer if 1242 required by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET 1243 Task Management request received before all the commands on which 1244 it was supposed to act). 1246 On any connection, the iSCSI initiator MUST send the commands in 1247 increasing order of CmdSN, except for commands that are 1248 retransmitted due to digest error recovery and connection 1249 recovery. 1251 For the numbering mechanism, the initiator and target maintain the 1252 following three variables for each session: 1254 - CmdSN - the current command Sequence Number, advanced by 1 1255 on each command shipped except for commands marked for 1256 immediate delivery. CmdSN always contains the number to be 1257 assigned to the next Command PDU. 1259 - ExpCmdSN - the next expected command by the target. The 1260 target acknowledges all commands up to, but not including, 1261 this number. The initiator treats all commands with CmdSN 1262 less than ExpCmdSN as acknowledged. The target iSCSI layer 1263 sets the ExpCmdSN to the largest non-immediate CmdSN that it 1264 can deliver for execution "plus 1" per [RFC1982]. There 1265 MUST NOT be any holes in the acknowledged CmdSN sequence. 1267 - MaxCmdSN - the maximum number to be shipped. The queuing 1268 capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN 1269 + 1. 1271 The initiator's ExpCmdSN and MaxCmdSN are derived from target-to- 1272 initiator PDU fields. Comparisons and arithmetic on ExpCmdSN and 1273 MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] 1274 where SERIAL_BITS = 32. 1276 The target MUST NOT transmit a MaxCmdSN that is less than 1277 ExpCmdSN-1. For non-immediate commands, the CmdSN field can take 1278 any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST 1279 silently ignore any non-immediate command outside of this range or 1280 non-immediate duplicates within the range. The CmdSN carried by 1281 immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. 1282 For example, if the initiator has previously sent a non-immediate 1283 command carrying the CmdSN equal to MaxCmdSN, the target window is 1284 closed. For group task management commands issued as immediate 1285 commands, CmdSN indicates the scope of the group action (e.g., on 1286 ABORT TASK SET indicates which commands are to be aborted). 1288 MaxCmdSN and ExpCmdSN fields are processed by the initiator as 1289 follows: 1291 -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in 1292 Serial Arithmetic Sense), they are both ignored. 1294 -If the PDU MaxCmdSN is greater than the local MaxCmdSN (in 1295 Serial Arithmetic Sense), it updates the local MaxCmdSN; 1296 otherwise, it is ignored. 1298 -If the PDU ExpCmdSN is greater than the local ExpCmdSN (in 1299 Serial Arithmetic Sense), it updates the local ExpCmdSN; 1300 otherwise, it is ignored. 1302 This sequence is required because updates may arrive out of order 1303 (e.g., the updates are sent on different TCP connections). 1305 iSCSI initiators and targets MUST support the command numbering 1306 scheme. 1308 A numbered iSCSI request will not change its allocated CmdSN, 1309 regardless of the number of times and circumstances in which it is 1310 reissued (see Section 6.2.1 "Usage of Retry"). At the target, 1311 CmdSN is only relevant while the command has not created any state 1312 related to its execution (execution state); afterwards, CmdSN 1313 becomes irrelevant. Testing for the execution state (represented 1314 by identifying the Initiator Task Tag) MUST precede any other 1315 action at the target. If no execution state is found, it is 1316 followed by ordering and delivery. If an execution state is found, 1317 it is followed by delivery if it has not already been delivered. 1319 If an initiator issues a command retry for a command with CmdSN R 1320 on 1321 a connection when the session CmdSN value is Q, it MUST NOT 1322 advance the CmdSN past R + 2**31 -1 unless the connection is no 1323 longer operational (i.e., it has returned to the FREE state, see 1324 Section 7.1.3 "Standard Connection State Diagram for an 1325 Initiator"), the connection has been reinstated (see Section 5.3.4 1326 "Connection Reinstatement"), or a non-immediate command with CmdSN 1327 equal or greater than Q was issued subsequent to the command retry 1328 on the same connection and the reception of that command is 1329 acknowledged by the target (see Section 9.4 "Command Retry and 1330 Cleaning Old Command Instances"). 1332 A target command response or Data-in PDU with status MUST NOT 1333 precede the command acknowledgement. However, the acknowledgement 1334 MAY be included in the response or the Data-in PDU. 1336 4.2.2.2. Response/Status Numbering and Acknowledging 1338 Responses in transit from the target to the initiator are 1339 numbered. The StatSN (Status Sequence Number) is used for this 1340 purpose. StatSN is a counter maintained per connection. ExpStatSN 1341 is used by the initiator to acknowledge status. The status 1342 sequence number space is 32-bit unsigned-integers and the 1343 arithmetic operations are the regular mod(2**32) arithmetic. 1345 Status numbering starts with the Login response to the first Login 1346 request of the connection. The Login response includes an initial 1347 value for status numbering (any initial value is valid). 1349 To enable command recovery, the target MAY maintain enough state 1350 information for data and status recovery after a connection 1351 failure. A target doing so can safely discard all of the state 1352 information maintained for recovery of a command after the 1353 delivery of the status for the command (numbered StatSN) is 1354 acknowledged through ExpStatSN. 1356 A large absolute difference between StatSN and ExpStatSN may 1357 indicate a failed connection. Initiators MUST undertake recovery 1358 actions if the difference is greater than an implementation 1359 defined constant that MUST NOT exceed 2**31-1. 1361 Initiators and Targets MUST support the response-numbering scheme. 1363 4.2.2.3. Response Ordering 1365 4.2.2.3.1. Need for Response Ordering 1367 Whenever an iSCSI session is composed of multiple connections, the 1368 Response PDUs (task responses or TMF responses) originating in 1369 the target SCSI layer are distributed onto the multiple 1370 connections by the target iSCSI layer according to iSCSI 1371 connection allegiance rules. This process generally may not 1372 preserve the ordering of the responses by the time they are 1373 delivered to the initiator SCSI layer. 1375 Since ordering is not expected across SCSI responses anyway, this 1376 approach works fine in the general case. However, to address the 1377 special cases where some ordering is desired by the SCSI layer, 1378 the following "Response Fence" semantics are defined with respect 1379 to handling SCSI response messages as they are handed off from the 1380 SCSI protocol layer to the iSCSI layer. 1382 4.2.2.3.2. Response Ordering Model Description 1384 The target SCSI protocol layer hands off the SCSI response 1385 messages to the target iSCSI layer by invoking the "Send Command 1386 Complete" protocol data service ([SAM2], clause 5.4.2) and "Task 1387 Management Function Executed" ([SAM2], clause 6.9) service. On 1388 receiving the SCSI response message, the iSCSI layer exhibits the 1389 Response Fence behavior for certain SCSI response messages 1390 (Section 4.2.2.3.4 describes the specific instances where the 1391 semantics must be realized). 1393 Whenever the Response Fence behavior is required for a SCSI 1394 response message, the target iSCSI layer MUST ensure that the 1395 following conditions are met in delivering the response message to 1396 the initiator iSCSI layer: 1398 Response with Response Fence MUST be delivered chronologically 1399 after all the "preceding" responses on the I_T_L nexus, if 1400 the preceding responses are delivered at all, to the 1401 initiator iSCSI layer. 1402 Response with Response Fence MUST be delivered chronologically 1403 prior to all the "following" responses on the I_T_L nexus. 1405 The "preceding" and "following" notions refer to the order of 1406 handoff of a response message from the target SCSI protocol layer 1407 to the target iSCSI layer. 1409 4.2.2.3.3. iSCSI Semantics with the Interface Model 1411 Whenever the TaskReporting key (Section 12.23 "Task Reporting") is 1412 negotiated to ResponseFence or FastAbort for an iSCSI session and 1413 the Response Fence behavior is required for a SCSI response 1414 message, the target iSCSI layer MUST perform the actions described 1415 in this section for that session. 1417 If it is a single-connection session, no special processing is 1418 required. The standard SCSI Response PDU build and dispatch 1419 process happens. 1420 If it is a multi-connection session, the target iSCSI layer 1421 takes note of the last-sent and unacknowledged StatSN on 1422 each of the connections in the iSCSI session, and waits for 1423 an acknowledgement (NOP-In PDUs MAY be used to solicit 1424 acknowledgements as needed in order to accelerate this 1425 process) of each such StatSN to clear the fence. The SCSI 1426 response requiring Response Fence behavior MUST NOT be sent 1427 to the initiator before acknowledgements are received for 1428 each of the unacknowledged StatSNs. 1429 The target iSCSI layer must wait for an acknowledgement of the 1430 SCSI Response PDU that carried the SCSI response requiring 1431 the Response Fence behavior. The fence MUST be considered 1432 cleared only after receiving the acknowledgement. 1433 All further status processing for the LU is resumed only after 1434 clearing the fence. If any new responses for the I_T_L 1435 nexus are received from the SCSI layer before the fence is 1436 cleared, those Response PDUs MUST be held and queued at the 1437 iSCSI layer until the fence is cleared. 1439 4.2.2.3.4. Current List of Fenced Response Use Cases 1440 This section lists the fenced response use cases that iSCSI 1441 implementations MUST comply with. However, this is not an 1442 exhaustive enumeration. It is expected that as SCSI protocol 1443 specifications evolve, the specifications will specify when 1444 response fencing is required on a case-by-case basis. 1446 Whenever the TaskReporting key (Section 13.23) is negotiated to 1447 ResponseFence or FastAbort for an iSCSI session, the target iSCSI 1448 layer MUST assume that the Response Fence is required for the 1449 following SCSI completion messages: 1451 1. The first completion message carrying the UA after the 1452 multi-task abort on issuing and third-party sessions. See 1453 Section 4.2.3.2 for related TMF discussion. 1455 2. The TMF Response carrying the multi-task TMF Response on 1456 the issuing session. 1458 3. The completion message indicating ACA establishment on the 1459 issuing session. 1461 4. The first completion message carrying the ACA ACTIVE status 1462 after ACA establishment on issuing and third-party 1463 sessions. 1465 5. The TMF Response carrying the Clear ACA response on the 1466 issuing session. 1468 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 1469 command. 1471 Note: 1472 - Due to the absence of ACA-related fencing requirements in 1473 [RFC3720], initiator implementations SHOULD NOT use ACA on 1474 multi-connection iSCSI sessions with targets complying only 1475 with [RFC3720]. 1477 - Initiators that want to employ ACA on multi-connection iSCSI 1478 sessions SHOULD first assess response-fencing behavior via 1479 negotiating for ResponseFence or FastAbort values for the 1480 TaskReporting (Section 13.23) key. 1482 4.2.2.4. Data Sequencing 1484 Data and R2T PDUs transferred as part of some command execution 1485 MUST be sequenced. The DataSN field is used for data sequencing. 1486 For input (read) data PDUs, DataSN starts with 0 for the first 1487 data PDU of an input command and advances by 1 for each subsequent 1488 data PDU. For output data PDUs, DataSN starts with 0 for the first 1489 data PDU of a sequence (the initial unsolicited sequence or any 1490 data PDU sequence issued to satisfy an R2T) and advances by 1 for 1491 each subsequent data PDU. R2Ts are also sequenced per command. For 1492 example, the first R2T has an R2TSN of 0 and advances by 1 for 1493 each subsequent R2T. For bidirectional commands, the target uses 1494 the DataSN/R2TSN to sequence Data-In and R2T PDUs in one 1495 continuous sequence (undifferentiated). Unlike command and status, 1496 data PDUs and R2Ts are not acknowledged by a field in regular 1497 outgoing PDUs. Data-In PDUs can be acknowledged on demand by a 1498 special form of the SNACK PDU. Data and R2T PDUs are implicitly 1499 acknowledged by status for the command. The DataSN/R2TSN field 1500 enables the initiator to detect missing data or R2T PDUs. 1502 For any read or bidirectional command, a target MUST issue less 1503 than 2**32 combined R2T and Data-In PDUs. Any output data sequence 1504 MUST contain less than 2**32 Data-Out PDUs. 1506 4.2.3. iSCSI Task Management 1508 4.2.3.1. Task Management Overview 1510 iSCSI task management features allow an initiator to control the 1511 active iSCSI tasks on an operational iSCSI session that it has 1512 with an iSCSI target. Section 11.5 defines the task management 1513 function types that this specification defines - ABORT TASK, ABORT 1514 TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET 1515 WARM RESET, TARGET COLD RESET, and TASK REASSIGN. 1517 Out of these function types, ABORT TASK and TASK REASSIGN 1518 functions manage a single active task, whereas ABORT TASK SET, 1519 CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET and TARGET 1520 COLD RESET functions can each potentially affect multiple active 1521 tasks. 1523 4.2.3.2. Notion of Affected Tasks 1525 This section defines the notion of "affected tasks" in multi-task 1526 abort scenarios. Scope definitions in this section apply to both 1527 the Standard Multi-task Abort semantics (Section 4.2.3.3) and the 1528 FastAbort Multi-task Abort semantics behavior (Section 4.2.3.4). 1530 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 1531 identified by the LUN field in the ABORT TASK SET TMF Request PDU 1532 (Section 11.5). 1534 CLEAR TASK SET: All outstanding tasks in the task set for the LU 1535 identified by the LUN field in the CLEAR TASK SET TMF Request PDU. 1536 See [SPC3] for the definition of a "task set". 1538 LOGICAL UNIT RESET: All outstanding tasks from all initiators for 1539 the LU identified by the LUN field in the LOGICAL UNIT RESET 1540 Request PDU. 1542 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from 1543 all initiators across all LUs to which the TMF-issuing session has 1544 access on the SCSI target device hosting the iSCSI session. 1546 Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text 1547 is an iSCSI TMF Request PDU with the "Function" field set to 1548 "ABORT TASK SET" as defined in Section 11.5. Similar usage is 1549 employed for other scope descriptions. 1551 4.2.3.3. Standard Multi-task Abort Semantics 1553 All iSCSI implementations MUST support the protocol behavior 1554 defined in this section as the default behavior. The execution of 1555 ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM 1556 RESET, and TARGET COLD RESET TMF Requests consists of the 1557 following sequence of actions in the specified order on the 1558 specified party. 1560 The initiator iSCSI layer: 1561 a. MUST continue to respond to each TTT received for the 1562 affected tasks. 1563 b. SHOULD process any responses received for affected tasks in 1564 the normal fashion. This is acceptable because the 1565 responses are guaranteed to have been sent prior to the TMF 1566 response. 1567 c. SHOULD receive the TMF Response concluding all the tasks in 1568 the set of affected tasks unless the initiator has done 1569 something (e.g., LU reset, connection drop) that may 1570 prevent the TMF Response from being sent or received. The 1571 initiator MUST thus conclude all affected tasks as part of 1572 this step in either case, and MUST discard any TMF Response 1573 received after the affected tasks are concluded. 1575 The target iSCSI layer: 1576 a. MUST wait for responses on currently valid target-transfer 1577 tags of the affected tasks from the issuing initiator. MAY 1578 wait for responses on currently valid target-transfer tags 1579 of the affected tasks from third-party initiators. 1580 b. MUST wait (concurrent with the wait in Step a) for all 1581 commands of the affected tasks to be received based on the 1582 CmdSN ordering. SHOULD NOT wait for new commands on third- 1583 party affected sessions -- only the instantiated tasks have 1584 to be considered for the purpose of determining the 1585 affected tasks. In the case of target-scoped requests 1586 (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the 1587 commands that are not yet received on the issuing session 1588 in the command stream however can be considered to have 1589 been received with no command waiting period -- i.e., the 1590 entire CmdSN space up to the CmdSN of the task management 1591 function can be "plugged". 1592 c. MUST propagate the TMF request to and receive the response 1593 from the target SCSI layer. 1594 d. MUST provide the Response Fence behavior for the TMF 1595 Response on the issuing session as specified in Section 1596 4.2.2.3.2. 1597 e. MUST provide the Response Fence behavior on the first post- 1598 TMF Response on third-party sessions as specified in 1599 Section 4.2.2.3.3. If some tasks originate from non-iSCSI 1600 I_T_L nexuses, then the means by which the target ensures 1601 that all affected tasks have returned their status to the 1602 initiator are defined by the specific non-iSCSI transport 1603 protocol(s). 1605 Technically, the TMF servicing is complete in Step d. Data 1606 transfers corresponding to terminated tasks may however still be 1607 in progress on third-party iSCSI sessions even at the end of Step 1608 e. The TMF Response MUST NOT be sent by the target iSCSI layer 1609 before the end of Step d, and MAY be sent at the end of Step d 1610 despite these outstanding data transfers until after Step e. 1612 4.2.3.4. FastAbort Multi-task Abort Semantics 1614 Protocol behavior defined in this section MUST be implemented by 1615 all iSCSI implementations complying with this document. Protocol 1616 behavior defined in this section MUST be exhibited by iSCSI 1617 implementations on an iSCSI session when they negotiate the 1618 TaskReporting (Section 13.23) key to "FastAbort" on that session. 1619 The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT 1620 RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests 1621 consists of the following sequence of actions in the specified 1622 order on the specified party. 1624 The initiator iSCSI layer: 1625 a. MUST NOT send any more Data-Out PDUs for affected tasks on 1626 the issuing connection of the issuing iSCSI session once 1627 the TMF is sent to the target. 1628 b. SHOULD process any responses received for affected tasks in 1629 the normal fashion. This is acceptable because the 1630 responses are guaranteed to have been sent prior to the TMF 1631 response. 1632 c. MUST respond to each Async Message PDU with FAST_ABORT 1633 AsyncEvent as defined in Section 11.9. 1634 d. MUST treat the TMF response as terminating all affected 1635 tasks for which responses have not been received, and MUST 1636 discard any responses for affected tasks received after the 1637 TMF response is passed to the SCSI layer (although the 1638 semantics defined in this section ensure that such an out- 1639 of-order scenario will never happen with a compliant target 1640 implementation). 1642 The target iSCSI layer: 1643 a. MUST wait for all commands of the affected tasks to be 1644 received based on the CmdSN ordering on the issuing 1645 session. SHOULD NOT wait for new commands on third-party 1646 affected sessions - only the instantiated tasks have to be 1647 considered for the purpose of determining the affected 1648 tasks. In the case of target-scoped requests (i.e., TARGET 1649 WARM RESET and TARGET COLD RESET), all the commands that 1650 are not yet received on the issuing session in the command 1651 stream can be considered to have been received with no 1652 command waiting period -- i.e., the entire CmdSN space up 1653 to the CmdSN of the task management function can be 1654 "plugged". 1655 b. MUST propagate the TMF request to and receive the response 1656 from the target SCSI layer. 1657 c. MUST leave all active "affected TTTs" (i.e., active TTTs 1658 associated with affected tasks) valid. 1659 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 1660 (Section 11.9) on: 1661 i) each connection of each third-party session to 1662 which at least one affected task is allegiant if 1663 TaskReporting=FastAbort is operational on that third- 1664 party session, and, 1665 ii) each connection except the issuing connection of 1666 the issuing session that has at least one allegiant 1667 affected task. 1668 If there are multiple affected LUs (say, due to a target 1669 reset), then one Async Message PDU MUST be sent for each 1670 such LU on each connection that has at least one allegiant 1671 affected task. The LUN field in the Asynchronous Message PDU 1672 MUST be set to match the LUN for each such LU. 1673 e. MUST address the Response Fence flag on the TMF Response on 1674 the issuing session as defined in Section 4.2.2.3.3. 1675 f. MUST address the Response Fence flag on the first post-TMF 1676 Response on third-party sessions as defined in Section 1677 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L 1678 nexuses, then the means by which the target ensures that 1679 all affected tasks have returned their status to the 1680 initiator are defined by the specific non-iSCSI transport 1681 protocol(s). 1682 g. MUST free up the affected TTTs (and STags, if applicable) 1683 and the corresponding buffers, if any, once it receives 1684 each associated NOP-Out acknowledgement that the initiator 1685 generated in response to each Async Message. 1687 Technically, the TMF servicing is complete in Step e. Data 1688 transfers corresponding to terminated tasks may however still be 1689 in progress even at the end of Step f. A TMF Response MUST NOT be 1690 sent by the target iSCSI layer before the end of Step e, and MAY 1691 be sent at the end of Step e despite these outstanding Data 1692 transfers until Step g. Step g specifies an event to free up any 1693 such resources that may have been reserved to support outstanding 1694 data transfers. 1696 4.2.3.5. Affected Tasks Shared across Standard and FastAbort Sessions 1698 If an iSCSI target implementation is capable of supporting 1699 TaskReporting=FastAbort functionality (Section 13.23), it may end 1700 up in a situation where some sessions have TaskReporting=RFC3720 1701 operational (RFC 3720 sessions) while some other sessions have 1702 TaskReporting=FastAbort operational (FastAbort sessions) even 1703 while accessing a shared set of affected tasks (Section 4.2.3.2). 1704 If the issuing session is an RFC 3720 session, the iSCSI target 1705 implementation is FastAbort-capable, and the third-party affected 1706 session is a FastAbort session, the following behavior SHOULD be 1707 exhibited by the iSCSI target layer: 1708 a. Between Steps c and d of the target behavior in Section 1709 4.2.3.3, send an Asynchronous Message PDU with AsyncEvent=5 1710 (Section 11.9) on each connection of each third-party 1711 session to which at least one affected task is allegiant. 1712 If there are multiple affected LUs, then send one Async 1713 Message PDU for each such LU on each connection that has at 1714 least one allegiant affected task. When sent, the LUN field 1715 in the Asynchronous Message PDU MUST be set to match the 1716 LUN for each such LU. 1717 b. After Step e of the target behavior in Section 4.2.3.3, 1718 free up the affected TTTs (and STags, if applicable) and 1719 the corresponding buffers, if any, once each associated 1720 NOP-Out acknowledgement is received that the third-party 1721 initiator generated in response to each Async Message sent 1722 in Step a. 1724 If the issuing session is a FastAbort session, the iSCSI target 1725 implementation is FastAbort-capable, and the third-party affected 1726 session is an RFC 3720 session, the following behavior MUST be 1727 exhibited by the iSCSI target layer: Asynchronous Message PDUs 1728 MUST NOT be sent on the third-party session to prompt the 1729 FastAbort behavior. 1731 If the third-party affected session is a FastAbort session and the 1732 issuing session is a FastAbort session, the initiator in the 1733 third-party role MUST respond to each Async Message PDU with 1734 AsyncEvent=5 as defined in Section 11.9. Note that an initiator 1735 MAY thus receive these Async Messages on a third-party affected 1736 session even if the session is a single-connection session. 1738 4.2.3.6. Rationale behind the FastAbort Semantics 1740 There are fundamentally three basic objectives behind the 1741 semantics 1742 specified in Sections 4.2.3.3 and 4.2.3.4. 1743 1. Maintaining an ordered command flow I_T nexus abstraction 1744 to the target SCSI layer even with multi-connection 1745 sessions. 1746 - Target iSCSI processing of a TMF request must 1747 maintain the single flow illusion. Target behavior in 1748 Step b of Section 4.2.3.3 and Step a of Section 4.2.3.4 1749 correspond to this objective. 1750 2. Maintaining a single ordered response flow I_T nexus 1751 abstraction to the initiator SCSI layer even with multi- 1752 connection sessions when one response (i.e., TMF response) 1753 could imply the status of other unfinished tasks from the 1754 initiator's perspective. 1755 - The target must ensure that the initiator does not 1756 see "old" task responses (that were placed on the wire 1757 chronologically earlier than the TMF Response) after 1758 seeing the TMF response. The target behavior in Step d 1759 of Section 4.2.3.3 and Step e of Section 4.2.3.4 1760 correspond to this objective. 1761 - Whenever the result of a TMF action is visible across 1762 multiple I_T_L nexuses, [SAM2] requires the SCSI device 1763 server to trigger a UA on each of the other I_T_L 1764 nexuses. Once an initiator is notified of such an UA, 1765 the application client on the receiving initiator is 1766 required to clear its task state (clause 5.5 in [SAM2]) 1767 for the affected tasks. It would thus be inappropriate 1768 to deliver a SCSI Response for a task after the task 1769 state is cleared on the initiator, i.e., after the UA 1770 is notified. The UA notification contained in the first 1771 SCSI Response PDU on each affected Third-party I_T_L 1772 nexus after the TMF action thus MUST NOT pass the 1773 affected task responses on any of the iSCSI sessions 1774 accessing the LU. The target behavior in Step e of 1775 Section 4.2.3.3 and Step f of Section 4.2.3.4 1776 correspond to this objective. 1777 3. Draining all active TTTs corresponding to affected tasks in 1778 a deterministic fashion. 1779 - Data-Out PDUs with stale TTTs arriving after the 1780 tasks are terminated can create a buffer management 1781 problem even for traditional iSCSI implementations, and 1782 is fatal for the connection for iSCSI/iSER 1783 implementations. Either the termination of affected 1784 tasks should be postponed until the TTTs are retired 1785 (as in Step a of Section 4.2.3.3), or the TTTs and the 1786 buffers should stay allocated beyond task termination 1787 to be deterministically freed up later (as in Steps c 1788 and g of Section 4.2.3.4). 1790 The only other notable optimization is the plugging. If all tasks 1791 on an I_T nexus will be aborted anyway (as with a target reset), 1792 there is no need to wait to receive all commands to plug the CmdSN 1793 holes. The target iSCSI layer can simply plug all missing CmdSN 1794 slots and move on with TMF processing. The first objective 1795 (maintaining a single ordered command flow) is still met with this 1796 optimization because the target SCSI layer only sees ordered 1797 commands. 1799 4.2.4. iSCSI Login 1801 The purpose of the iSCSI login is to enable a TCP connection for 1802 iSCSI use, authentication of the parties, negotiation of the 1803 session's parameters and marking of the connection as belonging to 1804 an iSCSI session. 1806 A session is used to identify to a target all the connections with 1807 a given initiator that belong to the same I_T nexus. (For more 1809 details on how a session relates to an I_T nexus, see section 1810 4.4.2). 1812 The targets listen on a well-known TCP port or other TCP port for 1813 incoming connections. The initiator begins the login process by 1814 connecting to one of these TCP ports. 1816 As part of the login process, the initiator and target SHOULD 1817 authenticate each other and MAY set a security association 1818 protocol for the session. This can occur in many different ways 1819 and is subject to negotiation. 1821 To protect the TCP connection, an IPsec security association MAY 1822 be established before the Login request. For information on using 1823 IPsec security for iSCSI see Chapter 8 and [RFC3723]. 1825 The iSCSI Login Phase is carried through Login requests and 1826 responses. Once suitable authentication has occurred and 1827 operational parameters have been set, the session transitions to 1828 Full Feature Phase and the initiator may start to send SCSI 1829 commands. The security policy for whether, and by what means, a 1830 target chooses to authorize an initiator is beyond the scope of 1831 this document. For a more detailed description of the Login Phase, 1832 see Chapter 5. 1834 The login PDU includes the ISID part of the session ID (SSID). The 1835 target portal group that services the login is implied by the 1836 selection of the connection endpoint. For a new session, the TSIH 1837 is zero. As part of the response, the target generates a TSIH. 1839 During session establishment, the target identifies the SCSI 1840 initiator port (the "I" in the "I_T nexus") through the value pair 1841 (InitiatorName, ISID). We describe InitiatorName later in this 1842 section. Any persistent state (e.g., persistent reservations) on 1843 the target that is associated with a SCSI initiator port is 1844 identified based on this value pair. Any state associated with the 1845 SCSI target port (the "T" in the "I_T nexus") is identified 1846 externally by the TargetName and portal group tag (see Section 1847 4.4.1). ISID is subject to reuse restrictions because it is used 1848 to identify a persistent state (see Section 4.4.3). 1850 Before the Full Feature Phase is established, only Login Request 1851 and Login Response PDUs are allowed. Login requests and responses 1852 MUST be used exclusively during Login. On any connection, the 1853 login phase MUST immediately follow TCP connection establishment 1854 and a subsequent Login Phase MUST NOT occur before tearing down a 1855 connection. 1857 A target receiving any PDU except a Login request before the Login 1858 phase is started MUST immediately terminate the connection on 1859 which the PDU was received. Once the Login phase has started, if 1860 the target receives any PDU except a Login request, it MUST send a 1861 Login reject (with Status "invalid during login") and then 1862 disconnect. If the initiator receives any PDU except a Login 1863 response, it MUST immediately terminate the connection. 1865 4.2.5. iSCSI Full Feature Phase 1867 Once the initiator is authorized to do so, the iSCSI session is in 1868 the iSCSI Full Feature Phase. A session is in Full Feature Phase 1869 after successfully finishing the Login Phase on the first 1870 (leading) connection of a session. A connection is in Full Feature 1871 Phase if the session is in Full Feature Phase and the connection 1872 login has completed successfully. An iSCSI connection is not in 1873 Full Feature Phase 1875 when it does not have an established transport connection, 1876 OR 1877 when it has a valid transport connection, but a successful 1878 login was not performed or the connection is currently 1879 logged out. 1881 In a normal Full Feature Phase, the initiator may send SCSI 1882 commands and data to the various LUs on the target by 1883 encapsulating them in iSCSI PDUs that go over the established 1884 iSCSI session. 1886 4.2.5.1. Command Connection Allegiance 1888 For any iSCSI request issued over a TCP connection, the 1889 corresponding response and/or other related PDU(s) MUST be sent 1890 over the same connection. We call this "connection allegiance". If 1891 the original connection fails before the command is completed, the 1892 connection allegiance of the command may be explicitly reassigned 1893 to a different transport connection as described in detail in 1894 Section 6.2 "Retry and Reassign in Recovery". 1896 Thus, if an initiator issues a READ command, the target MUST send 1897 the requested data, if any, followed by the status to the 1898 initiator over the same TCP connection that was used to deliver 1899 the SCSI command. If an initiator issues a WRITE command, the 1900 initiator MUST send the data, if any, for that command over the 1901 same TCP connection that was used to deliver the SCSI command. The 1902 target MUST return Ready To Transfer (R2T), if any, and the status 1903 over the same TCP connection that was used to deliver the SCSI 1904 command. Retransmission requests (SNACK PDUs) and the data and 1905 status that they generate MUST also use the same connection. 1907 However, consecutive commands that are part of a SCSI linked 1908 command-chain task (see [SAM2]) MAY use different connections. 1909 Connection allegiance is strictly per-command and not per-task. 1910 During the iSCSI Full Feature Phase, the initiator and target MAY 1911 interleave unrelated SCSI commands, their SCSI Data, and responses 1912 over the session. 1914 4.2.5.2. Data Transfer Overview 1916 Outgoing SCSI data (initiator to target user data or command 1917 parameters) is sent as either solicited data or unsolicited data. 1918 Solicited data are sent in response to R2T PDUs. Unsolicited data 1919 can be sent as part of an iSCSI command PDU ("immediate data") or 1920 in separate iSCSI data PDUs. 1922 Immediate data are assumed to originate at offset 0 in the 1923 initiator SCSI write-buffer (outgoing data buffer). All other Data 1924 PDUs have the buffer offset set explicitly in the PDU header. 1926 An initiator may send unsolicited data up to FirstBurstLength as 1927 immediate (up to the negotiated maximum PDU length), in a separate 1928 PDU sequence or both. All subsequent data MUST be solicited. The 1929 maximum length of an individual data PDU or the immediate-part of 1930 the first unsolicited burst MAY be negotiated at login. 1932 The maximum amount of unsolicited data that can be sent with a 1933 command is negotiated at login through the FirstBurstLength key. A 1934 target MAY separately enable immediate data (through the 1935 ImmediateData key) without enabling the more general (separate 1936 data PDUs) form of unsolicited data (through the InitialR2T key). 1938 Unsolicited data on write are meant to reduce the effect of 1939 latency on throughput (no R2T is needed to start sending data). In 1940 addition, immediate data is meant to reduce the protocol overhead 1941 (both bandwidth and execution time). 1943 An iSCSI initiator MAY choose not to send unsolicited data, only 1944 immediate data or FirstBurstLength bytes of unsolicited data with 1945 a command. If any non-immediate unsolicited data is sent, the 1946 total unsolicited data MUST be either FirstBurstLength, or all of 1947 the data if the total amount is less than the FirstBurstLength. 1949 It is considered an error for an initiator to send unsolicited 1950 data PDUs to a target that operates in R2T mode (only solicited 1951 data are allowed). It is also an error for an initiator to send 1952 more unsolicited data, whether immediate or as separate PDUs, than 1953 FirstBurstLength. 1955 An initiator MUST honor an R2T data request for a valid 1956 outstanding command (i.e., carrying a valid Initiator Task Tag) 1957 and deliver all the requested data provided the command is 1958 supposed to deliver outgoing data and the R2T specifies data 1959 within the command bounds. The initiator action is unspecified for 1960 receiving an R2T request that specifies data, all or part, outside 1961 of the bounds of the command. 1963 A target SHOULD NOT silently discard data and then request 1964 retransmission through R2T. Initiators SHOULD NOT keep track of 1965 the data transferred to or from the target (scoreboarding). SCSI 1966 targets perform residual count calculation to check how much data 1967 was actually transferred to or from the device by a command. This 1968 may differ from the amount the initiator sent and/or received for 1969 reasons such as retransmissions and errors. Read or bidirectional 1970 commands implicitly solicit the transmission of the entire amount 1971 of data covered by the command. SCSI data packets are matched to 1972 their corresponding SCSI commands by using tags specified in the 1973 protocol. 1975 In addition, iSCSI initiators and targets MUST enforce some 1976 ordering rules. When unsolicited data is used, the order of the 1977 unsolicited data on each connection MUST match the order in which 1978 the commands on that connection are sent. Command and unsolicited 1979 data PDUs may be interleaved on a single connection as long as the 1980 ordering requirements of each are maintained (e.g., command N+1 1981 MAY be sent before the unsolicited Data-Out PDUs for command N, 1982 but the unsolicited Data-Out PDUs for command N MUST precede the 1983 unsolicited Data-Out PDUs of command N+1). A target that receives 1984 data out of order MAY terminate the session. 1986 4.2.5.3. Tags and Integrity Checks 1988 Initiator tags for pending commands are unique initiator-wide for 1989 a session. Target tags are not strictly specified by the protocol. 1990 It is assumed that target tags are used by the target to tag 1991 (alone or in combination with the LUN) the solicited data. Target 1992 tags are generated by the target and "echoed" by the initiator. 1993 These mechanisms are designed to accomplish efficient data 1994 delivery along with a large degree of control over the data flow. 1996 As the Initiator Task Tag is used to identify a task during its 1997 execution the iSCSI initiator and target MUST verify that all 1998 other fields used in task related PDUs have values that are 1999 consistent with the values used at the task instantiation based on 2000 Initiator Task Tag (e.g., the LUN used in an R2T PDU MUST be the 2001 same as the one used in the SCSI command PDU used to instantiate 2002 the task). Using inconsistent field values is considered a 2003 protocol error. 2005 4.2.5.4. Task Management 2007 SCSI task management assumes that individual tasks and task groups 2008 can be aborted solely based on the task tags (for individual 2009 tasks) or the timing of the task management command (for task 2010 groups) and that the task management action is executed 2011 synchronously - i.e, no message involving an aborted task will be 2012 seen by the SCSI initiator after receiving the task management 2013 response. In iSCSI initiators and targets interact asynchronously 2014 over several connections. iSCSI specifies the protocol mechanism 2015 and implementation requirements needed to present a synchronous 2016 view while using an asynchronous infrastructure. 2018 4.2.6. iSCSI Connection Termination 2020 An iSCSI connection may be terminated by use of a transport 2021 connection shutdown or a transport reset. Transport reset is 2022 assumed to be an exceptional event. 2024 Graceful TCP connection shutdowns are done by sending TCP FINs. A 2025 graceful transport connection shutdown SHOULD only be initiated by 2026 either party when the connection is not in iSCSI Full Feature 2027 Phase. A target MAY terminate a Full Feature Phase connection on 2028 internal exception events, but it SHOULD announce the fact through 2029 an Asynchronous Message PDU. Connection termination with 2030 outstanding commands may require recovery actions. 2032 If a connection is terminated while in Full Feature Phase, 2033 connection cleanup (see section 7) is required prior to recovery. 2034 By doing connection cleanup before starting recovery, the 2035 initiator and target will avoid receiving stale PDUs after 2036 recovery. 2038 4.2.7. iSCSI Names 2040 Both targets and initiators require names for the purpose of 2041 identification. In addition, names enable iSCSI storage resources 2042 to be managed regardless of location (address). An iSCSI node name 2043 is also the SCSI device name contained in the iSCSI Node. The 2044 iSCSI name of a SCSI device is the principal object used in 2045 authentication of targets to initiators and initiators to targets. 2046 This name is also used to identify and manage iSCSI storage 2047 resources. 2049 iSCSI names must be unique within the operation domain of the end 2050 user. However, because the operation domain of an IP network is 2051 potentially worldwide, the iSCSI name formats are architected to 2052 be worldwide unique. To assist naming authorities in the 2053 construction of worldwide unique names, iSCSI provides three name 2054 formats for different types of naming authorities. 2056 iSCSI names are associated with iSCSI nodes, and not iSCSI network 2057 adapter cards, to ensure that the replacement of network adapter 2059 cards does not require reconfiguration of all SCSI and iSCSI 2060 resource allocation information. 2062 Some SCSI commands require that protocol-specific identifiers be 2063 communicated within SCSI CDBs. See SCSI for the definition of the 2064 SCSI port name/identifier for iSCSI ports. 2066 An initiator may discover the iSCSI Target Names to which it has 2067 access, along with their addresses, using the SendTargets text 2068 request, or other techniques discussed in [RFC3721]. 2070 iSCSI equipment that needs discovery functions beyond SendTargets 2071 SHOULD implement iSNS (see [RFC4171]) for extended discovery 2072 management capabilities and interoperability. Although [RFC3721] 2073 implies an SLP implementation requirement, SLP has not been widely 2074 implemented or deployed for use with iSCSI in practice. iSCSI 2075 implementations therefore SHOULD NOT rely on SLP-based discovery 2076 interoperability. 2078 4.2.7.1. iSCSI Name Properties 2080 Each iSCSI node, whether it is an initiator or target or both, 2081 MUST have an iSCSI name. 2083 Initiators and targets MUST support the receipt of iSCSI names of 2084 up to the maximum length of 223 bytes. 2086 The initiator MUST present both its iSCSI Initiator Name and the 2087 iSCSI Target Name to which it wishes to connect in the first login 2088 request of a new session or connection. The only exception is if a 2089 discovery session (see Section 2.3 iSCSI Session Types) is to be 2090 established. In this case, the iSCSI Initiator Name is still 2091 required, but the iSCSI Target Name MAY be omitted. 2093 iSCSI names have the following properties: 2095 iSCSI names are globally unique. No two initiators or targets 2096 can have the same name. 2097 iSCSI names are permanent. An iSCSI initiator node or target 2098 node has the same name for its lifetime. 2100 iSCSI names do not imply a location or address. An iSCSI 2101 initiator or target can move, or have multiple addresses. A 2102 change of address does not imply a change of name. 2103 iSCSI names do not rely on a central name broker; the naming 2104 authority is distributed. 2105 iSCSI names support integration with existing unique naming 2106 schemes. 2107 iSCSI names rely on existing naming authorities. iSCSI does 2108 not create any new naming authority. 2110 The encoding of an iSCSI name has the following properties: 2112 iSCSI names have the same encoding method regardless of the 2113 underlying protocols. 2114 iSCSI names are relatively simple to compare. The algorithm 2115 for comparing two iSCSI names for equivalence does not rely 2116 on an external server. 2117 iSCSI names are composed only of displayable characters. iSCSI 2118 names allow the use of international character sets but are 2119 not case sensitive. No whitespace characters are used in 2120 iSCSI names. 2121 iSCSI names may be transported using both binary and ASCII- 2122 based protocols. 2124 An iSCSI name really names a logical software entity, and is not 2125 tied to a port or other hardware that can be changed. For 2126 instance, an initiator name should name the iSCSI initiator node, 2127 not a particular NIC or HBA. When multiple NICs are used, they 2128 should generally all present the same iSCSI initiator name to the 2129 targets, because they are simply paths to the same SCSI layer. In 2130 most operating systems, the named entity is the operating system 2131 image. 2133 Similarly, a target name should not be tied to hardware interfaces 2134 that can be changed. A target name should identify the logical 2135 target and must be the same for the target regardless of the 2136 physical portion being addressed. This assists iSCSI initiators in 2137 determining that the two targets it has discovered are really two 2138 paths to the same target. 2140 The iSCSI name is designed to fulfill the functional requirements 2141 for Uniform Resource Names (URN) [RFC1737]. For example, it is 2142 required that the name have a global scope, be independent of 2143 address or location, and be persistent and globally unique. Names 2144 must be extensible and scalable with the use of naming 2145 authorities. The name encoding should be both human and machine 2146 readable. See [RFC1737] for further requirements. 2148 4.2.7.2. iSCSI Name Encoding 2150 An iSCSI name MUST be a UTF-8 encoding of a string of Unicode 2151 characters with the following properties: 2153 - It is in Normalization Form C (see "Unicode Normalization 2154 Forms" [UNICODE]). 2156 - It only contains characters allowed by the output of the 2157 iSCSI stringprep template (described in [RFC3722]). 2159 - The following characters are used for formatting iSCSI 2160 names: 2162 - dash ('-'=U+002d) 2163 - dot ('.'=U+002e) 2164 - colon (':'=U+003a) 2166 - The UTF-8 encoding of the name is not larger than 223 bytes. 2168 The stringprep process is described in [RFC3454]; iSCSI's use of 2169 the stringprep process is described in [RFC3722]. Stringprep is a 2170 method designed by the Internationalized Domain Name (IDN) working 2171 group to translate human-typed strings into a format that can be 2172 compared as opaque strings. Strings MUST NOT include punctuation, 2173 spacing, diacritical marks, or other characters that could get in 2174 the way of readability. The stringprep process also converts 2175 strings into equivalent strings of lower-case characters. 2177 The stringprep process does not need to be implemented if the 2178 names are only generated using numeric and lower-case (any 2179 character set) alphabetic characters. 2181 Once iSCSI names encoded in UTF-8 are "normalized" they may be 2182 safely compared byte-for-byte. 2184 4.2.7.3. iSCSI Name Structure 2186 An iSCSI name consists of two parts--a type designator followed by 2187 a unique name string. 2189 iSCSI uses three existing naming authorities in constructing 2190 globally unique iSCSI names. Type designator in an iSCSI name 2191 indicates the naming authority on which the name is based. The 2192 three iSCSI name formats are the following: 2194 iSCSI-Qualified Name: it is based on domain names to identify 2195 a naming authority, 2196 NAA format Name: it is based on a naming format defined by 2197 [FC-FS] for constructing globally unique identifiers, 2198 referred to as the Network Address Authority (NAA), and, 2199 EUI format Name: it is based on EUI names where the IEEE 2200 Registration Authority assists in the formation of 2201 worldwide unique names (EUI-64 format). 2203 The corresponding type designator strings currently defined are: 2205 iqn. - iSCSI Qualified name 2207 naa. - Remainder of the string is an INCITS T11-defined 2208 Network Address Authority identifier, in ASCII-encoded 2209 hexadecimal. 2211 eui. - Remainder of the string is an IEEE EUI-64 identifier, 2212 in ASCII-encoded hexadecimal. 2214 These three naming authority designators were considered 2215 sufficient at the time of writing this document. The creation of 2216 additional naming type designators for iSCSI may be considered by 2217 the IETF and detailed in separate RFCs. 2219 The following table summarizes the current SCSI transport 2220 protocols and their naming formats. 2222 SCSI Transport Protocol Naming Format 2223 +----------------------------+-------+-----+----+ 2224 | | EUI-64| NAA |IQN | 2225 |----------------------------|-------|-----|----| 2226 | iSCSI (Internet SCSI) | X | X | X | 2227 |----------------------------|-------|-----|----| 2228 | FCP (Fibre Channel) | | X | | 2229 |----------------------------|-------|-----|----| 2230 | SAS (Serial Attached SCSI) | | X | | 2231 |----------------------------|-------|-----|----| 2232 | SRP (for InfiniBand) | X | | | 2233 +----------------------------+-------+-----+----+ 2235 4.2.7.4. Type "iqn." (iSCSI Qualified Name) 2237 This iSCSI name type can be used by any organization that owns a 2238 domain name. This naming format is useful when an end user or 2239 service provider wishes to assign iSCSI names for targets and/or 2240 initiators. 2242 To generate names of this type, the person or organization 2243 generating the name must own a registered domain name. This domain 2244 name does not have to be active, and does not have to resolve to 2245 an address; it just needs to be reserved to prevent others from 2246 generating iSCSI names using the same domain name. 2248 Since a domain name can expire, be acquired by another entity, or 2249 may be used to generate iSCSI names by both owners, the domain 2250 name must be additionally qualified by a date during which the 2251 naming authority owned the domain name. A date code is provided as 2252 part of the "iqn." format for this reason. 2254 The iSCSI qualified name string consists of: 2256 - The string "iqn.", used to distinguish these names from 2257 "eui." formatted names. 2259 - A date code, in yyyy-mm format. This date MUST be a date 2260 during which the naming authority owned the domain name used 2261 in this format, and SHOULD be the first month in which the 2262 domain name was owned by this naming authority at 00:01 GMT 2263 of the first day of the month. This date code uses the 2264 Gregorian calendar. All four digits in the year must be 2265 present. Both digits of the month must be present, with 2266 January == "01" and December == "12". The dash must be 2267 included. 2269 - A dot "." 2271 - The reversed domain name of the naming authority (person or 2272 organization) creating this iSCSI name. 2274 - An optional, colon (:) prefixed, string within the character 2275 set and length boundaries that the owner of the domain name 2276 deems appropriate. This may contain product types, serial 2277 numbers, host identifiers, or software keys (e.g, it may 2278 include colons to separate organization boundaries). With 2279 the exception of the colon prefix, the owner of the domain 2280 name can assign everything after the reversed domain name as 2281 desired. It is the responsibility of the entity that is the 2282 naming authority to ensure that the iSCSI names it assigns 2283 are worldwide unique. For example, "Example Storage Arrays, 2284 Inc.", might own the domain name "example.com". 2286 The following are examples of iSCSI qualified names that might be 2287 generated by "EXAMPLE Storage Arrays, Inc." 2288 Naming String defined by 2289 Type Date Auth "example.com" naming authority 2290 +--++-----+ +---------+ +--------------------------------+ 2291 | || | | | | | 2293 iqn.2001-04.com.example:storage:diskarrays-sn-a8675309 2294 iqn.2001-04.com.example 2295 iqn.2001-04.com.example:storage.tape1.sys1.xyz 2296 iqn.2001-04.com.example:storage.disk2.sys1.xyz 2298 4.2.7.5. Type "eui." (IEEE EUI-64 format) 2300 The IEEE Registration Authority provides a service for assigning 2301 globally unique identifiers [EUI]. The EUI-64 format is used to 2302 build a global identifier in other network protocols. For example, 2303 Fibre Channel defines a method of encoding it into a 2304 WorldWideName. For more information on registering for EUI 2305 identifiers, see [OUI]. 2307 The format is "eui." followed by an EUI-64 identifier (16 ASCII- 2308 encoded hexadecimal digits). 2310 Example iSCSI name: 2312 Type EUI-64 identifier (ASCII-encoded hexadecimal) 2314 +--++--------------+ 2316 | || | 2318 eui.02004567A425678D 2320 The IEEE EUI-64 iSCSI name format might be used when a 2321 manufacturer is already registered with the IEEE Registration 2322 Authority and uses EUI-64 formatted worldwide unique names for its 2323 products. 2325 More examples of name construction are discussed in [RFC3721]. 2327 4.2.7.6. Type "naa." - Network Address Authority 2329 The INCITS T11 Framing and Signaling Specification [FC-FS] defines 2330 a format called the Network Address Authority (NAA) format for 2331 constructing worldwide unique identifiers that use various 2332 identifier registration authorities. This identifier format is 2333 used by the Fibre Channel and SAS SCSI transport protocols. As FC 2334 and SAS constitute a large fraction of networked SCSI ports, the 2335 NAA format is a widely used format for SCSI transports. The 2336 objective behind iSCSI supporting a direct representation of an 2337 NAA-format name is to facilitate construction of a target device 2338 name that translates easily across multiple namespaces for a SCSI 2339 storage device containing ports served by different transports. 2340 More specifically, this format allows implementations wherein one 2341 NAA identifier can be assigned as the basis for the SCSI device 2342 name for a SCSI target with both SAS ports and iSCSI ports. 2344 The iSCSI NAA naming format is "naa.", followed by an NAA 2345 identifier represented in ASCII-encoded hexadecimal digits. 2347 An example of an iSCSI name with a 64-bit NAA value follows: 2349 Type NAA identifier (ASCII-encoded hexadecimal) 2350 +--++--------------+ 2351 | || | 2352 naa.52004567BA64678D 2354 An example of an iSCSI name with a 128-bit NAA value follows: 2356 Type NAA identifier (ASCII-encoded hexadecimal) 2357 +--++------------------------------+ 2358 | || | 2359 naa.62004567BA64678D0123456789ABCDEF 2361 The iSCSI NAA naming format might be used in an implementation 2362 when the infrastructure for generating NAA worldwide unique names 2363 is already in place because the device contains both SAS and iSCSI 2364 SCSI ports. 2366 The NAA identifier formatted in an ASCII-hexadecimal 2367 representation has a maximum size of 32 characters (128 bit NAA 2368 format). As a result, there is no issue with this naming format 2369 exceeding the maximum size for iSCSI node names. 2371 4.2.8. Persistent State 2373 iSCSI does not require any persistent state maintenance across 2374 sessions. However, in some cases, SCSI requires persistent 2375 identification of the SCSI initiator port name (See Section 4.4.2 2376 and Section 4.4.3). 2378 iSCSI sessions do not persist through power cycles and boot 2379 operations. 2381 All iSCSI session and connection parameters are re-initialized on 2382 session and connection creation. 2384 Commands persist beyond connection termination if the session 2385 persists and command recovery within the session is supported. 2386 However, when a connection is dropped, command execution, as 2387 perceived by iSCSI (i.e., involving iSCSI protocol exchanges for 2388 the affected task), is suspended until a new allegiance is 2389 established by the 'task reassign' task management function. (See 2390 Section 10.5 "Task Management Function Request".) 2392 4.2.9. Message Synchronization and Steering 2394 iSCSI presents a mapping of the SCSI protocol onto TCP. This 2395 encapsulation is accomplished by sending iSCSI PDUs of varying 2396 lengths. Unfortunately, TCP does not have a built-in mechanism for 2397 signaling message boundaries at the TCP layer. iSCSI overcomes 2398 this obstacle by placing the message length in the iSCSI message 2399 header. This serves to delineate the end of the current message as 2400 well as the beginning of the next message. 2402 In situations where IP packets are delivered in order from the 2403 network, iSCSI message framing is not an issue and messages are 2404 processed one after the other. In the presence of IP packet 2405 reordering (i.e., frames being dropped), legacy TCP 2406 implementations store the "out of order" TCP segments in temporary 2407 buffers until the missing TCP segments arrive, upon which the data 2408 must be copied to the application buffers. In iSCSI, it is 2409 desirable to steer the SCSI data within these out of order TCP 2410 segments into the pre-allocated SCSI buffers rather than store 2411 them in temporary buffers. This decreases the need for dedicated 2412 reassembly buffers as well as the latency and bandwidth related to 2413 extra copies. 2415 Relying solely on the "message length" information from the iSCSI 2416 message header may make it impossible to find iSCSI message 2417 boundaries in subsequent TCP segments due to the loss of a TCP 2418 segment that contains the iSCSI message length. The missing TCP 2419 segment(s) must be received before any of the following segments 2420 can be steered to the correct SCSI buffers (due to the inability 2421 to determine the iSCSI message boundaries). Since these segments 2422 cannot be steered to the correct location, they must be saved in 2423 temporary buffers that must then be copied to the SCSI buffers. 2425 Different schemes can be used to recover synchronization. The 2426 details of any such schemes are beyond this protocol 2427 specification, but it suffices to note that [RFC4297] provides an 2428 overview of the direct data placement problem on IP networks, and 2429 [RFC5046] specifies a protocol extension for iSCSI that 2430 facilitates this direct data placement objective. 2432 Under normal circumstances (no PDU loss or data reception out of 2433 order), iSCSI data steering can be accomplished by using the 2434 identifying tag and the data offset fields in the iSCSI header in 2435 addition to the TCP sequence number from the TCP header. The 2436 identifying tag helps associate the PDU with a SCSI buffer address 2437 while the data offset and TCP sequence number are used to 2438 determine the offset within the buffer. 2440 4.2.9.1. Sync/Steering and iSCSI PDU Length 2442 When a large iSCSI message is sent, the TCP segment(s) that 2443 contain the iSCSI header may be lost. The remaining TCP segment(s) 2444 up to the next iSCSI message must be buffered (in temporary 2445 buffers) because the iSCSI header that indicates to which SCSI 2446 buffers the data are to be steered was lost. To minimize the 2447 amount of buffering, it is recommended that the iSCSI PDU length 2448 be restricted to a small value (perhaps a few TCP segments in 2449 length). During login, each end of the iSCSI session specifies the 2450 maximum iSCSI PDU length it will accept. 2452 4.3. iSCSI Session Types 2454 iSCSI defines two types of sessions: 2456 Normal operational session - an unrestricted session. 2458 Discovery-session - a session only opened for target 2459 discovery. The target MUST ONLY accept text requests with 2460 the SendTargets key and a logout request with reason "close 2461 the session". All other requests MUST be rejected. 2463 The session type is defined during login with key=value parameter 2464 in the login command. 2466 4.4. SCSI to iSCSI Concepts Mapping Model 2468 The following diagram shows an example of how multiple iSCSI Nodes 2469 (targets in this case) can coexist within the same Network Entity 2470 and can share Network Portals (IP addresses and TCP ports). Other 2471 more complex configurations are also possible. For detailed 2472 descriptions of the components of these diagrams, see section 2473 4.4.1. 2475 +-----------------------------------+ 2476 | Network Entity (iSCSI Client) | 2477 | | 2478 | +-------------+ | 2479 | | iSCSI Node | | 2480 | | (Initiator) | | 2481 | +-------------+ | 2482 | | | | 2483 | +--------------+ +--------------+ | 2484 | |Network Portal| |Network Portal| | 2485 | | 192.0.2.4 | | 192.0.2.5 | | 2486 +-+--------------+-+--------------+-+ 2487 | | 2488 | IP Networks | 2489 | | 2490 +-+--------------+-+--------------+-+ 2491 | |Network Portal| |Network Portal| | 2492 | |198.51.100.21 | |198.51.100.3 | | 2493 | | TCP Port 3260| | TCP Port 3260| | 2494 | +--------------+ +--------------+ | 2495 | | | | 2496 | ----------------- | 2497 | | | | 2498 | +-------------+ +--------------+ | 2499 | | iSCSI Node | | iSCSI Node | | 2500 | | (Target) | | (Target) | | 2501 | +-------------+ +--------------+ | 2502 | | 2503 | Network Entity (iSCSI Server) | 2504 +-----------------------------------+ 2506 4.4.1. iSCSI Architecture Model 2508 This section describes the part of the iSCSI architecture model 2509 that has the most bearing on the relationship between iSCSI and 2510 the SCSI Architecture Model. 2512 Network Entity - represents a device or gateway that is 2513 accessible from the IP network. A Network Entity must have 2514 one or more Network Portals (see a following item), each of 2515 which can be used by some iSCSI Nodes (see the following 2517 item) contained in that Network Entity to gain access to 2518 the IP network. 2520 iSCSI Node - represents a single iSCSI initiator or iSCSI 2521 target or an instance of each. There are one or more iSCSI 2522 Nodes within a Network Entity. The iSCSI Node is accessible 2523 via one or more Network Portals (see item d). An iSCSI Node 2524 is identified by its iSCSI Name (see Section 4.2.7 and 2525 Section 13). The separation of the iSCSI Name from the 2526 addresses used by and for the iSCSI node allows multiple 2527 iSCSI nodes to use the same addresses, and the same iSCSI 2528 node to use multiple addresses. 2530 An alias string may also be associated with an iSCSI Node. The 2531 alias allows an organization to associate a user friendly 2532 string with the iSCSI Name. However, the alias string is 2533 not a substitute for the iSCSI Name. 2535 Network Portal - a component of a Network Entity that has a 2536 TCP/IP network address and that may be used by an iSCSI 2537 Node within that Network Entity for the connection(s) 2538 within one of its iSCSI sessions. In an initiator, it is 2539 identified by its IP address. In a target, it is identified 2540 by its IP address and its listening TCP port. 2542 Portal Groups - iSCSI supports multiple connections within the 2543 same session; some implementations will have the ability to 2544 combine connections in a session across multiple Network 2545 Portals. A Portal Group defines a set of Network Portals 2546 within an iSCSI Node that collectively supports the 2547 capability of coordinating a session with connections that 2548 span these portals. Not all Network Portals within a Portal 2549 Group need to participate in every session connected 2550 through that Portal Group. One or more Portal Groups may 2551 provide access to an iSCSI Node. Each Network Portal, as 2552 utilized by a given iSCSI Node, belongs to exactly one 2553 portal group within that node. Portal Groups are identified 2554 within an iSCSI Node by a portal group tag, a simple 2555 unsigned-integer between 0 and 65535 (see Section 12.3 2556 "SendTargets"). All Network Portals with the same portal 2558 group tag in the context of a given iSCSI Node are in the 2559 same Portal Group. 2561 Both iSCSI Initiators and iSCSI Targets have portal groups, 2562 though only the iSCSI Target Portal Groups are used 2563 directly in the iSCSI protocol (e.g., in SendTargets). For 2564 references to the Initiator Portal Groups, see Section 2565 10.1.1. 2567 Portals within a Portal Group should support similar session 2568 parameters, because they may participate in a common 2569 session. 2571 The following diagram shows an example of one such configuration 2572 on a target and how a session that shares Network Portals within a 2573 Portal Group may be established. 2575 ----------------------------IP Network--------------------- 2576 | | | 2577 +----|---------------|-----+ +----|---------+ 2578 | +---------+ +---------+ | | +---------+ | 2579 | | Network | | Network | | | | Network | | 2580 | | Portal | | Portal | | | | Portal | | 2581 | +--|------+ +---------+ | | +---------+ | 2582 | | | | | | | 2583 | | Portal | | | | Portal | 2584 | | Group 1 | | | | Group 2 | 2585 +--------------------------+ +--------------+ 2586 | | | 2587 +--------|---------------|--------------------|------------------- 2588 + 2589 | | | | 2590 | 2591 | +----------------------------+ +----------------------------- 2592 +| 2593 | | iSCSI Session (Target side)| | iSCSI Session (Target side) 2594 || 2595 | | | | 2596 || 2597 | | (TSIH = 56) | | (TSIH = 48) 2598 || 2599 | +----------------------------+ +----------------------------- 2600 +| 2601 | 2602 | 2603 | iSCSI Target Node 2604 | 2605 | (within Network Entity, not shown) 2606 | 2607 +----------------------------------------------------------------- 2608 + 2610 4.4.2. SCSI Architecture Model 2612 This section describes the relationship between the SCSI 2613 Architecture Model [SAM2] and constructs of the SCSI device, SCSI 2614 port and I_T nexus, and the iSCSI constructs described in Section 2615 4.4.1. 2617 This relationship implies implementation requirements in order to 2618 conform to the SAM2 model and other SCSI operational functions. 2619 These requirements are detailed in Section 4.4.3. 2621 The following list outlines mappings of SCSI architectural 2622 elements to iSCSI. 2624 SCSI Device - the SAM2 term for an entity that contains one or 2625 more SCSI ports that are connected to a service delivery 2626 subsystem and supports a SCSI application protocol. For 2627 example, a SCSI Initiator Device contains one or more SCSI 2628 Initiator Ports and zero or more application clients. A 2629 SCSI Target Device contains one or more SCSI Target Ports 2630 and one or more logical units. For iSCSI, the SCSI Device 2631 is the component within an iSCSI Node that provides the 2632 SCSI functionality. As such, there can be one SCSI Device, 2633 at most, within an iSCSI Node. Access to the SCSI Device 2634 can only be achieved in an iSCSI normal operational session 2635 (see Section 4.3). The SCSI Device Name is defined to be 2636 the iSCSI Name of the node and MUST be used in the iSCSI 2637 protocol. 2639 SCSI Port - the SAM2 term for an entity in a SCSI Device that 2640 provides the SCSI functionality to interface with a service 2641 delivery subsystem or transport. For iSCSI, the definition 2642 of SCSI Initiator Port and SCSI Target Port are different. 2644 SCSI Initiator Port: This maps to one endpoint of an iSCSI 2645 normal operational session (see Section 4.3). An iSCSI 2646 normal operational session is negotiated through the login 2647 process between an iSCSI initiator node and an iSCSI target 2648 node. At successful completion of this process, a SCSI 2649 Initiator Port is created within the SCSI Initiator Device. 2650 The SCSI Initiator Port Name and SCSI Initiator Port 2651 Identifier are both defined to be the iSCSI Initiator Name 2652 together with (a) a label that identifies it as an 2653 initiator port name/identifier and (b) the ISID portion of 2654 the session identifier. 2656 SCSI Target Port: This maps to an iSCSI Target Portal 2657 Group. The SCSI Target Port Name and the SCSI Target Port 2658 Identifier are both defined to be the iSCSI Target Name 2659 together with (a) a label that identifies it as a target 2660 port name/identifier and (b) the portal group tag. 2662 The SCSI Port Name MUST be used in iSCSI. When used in SCSI 2663 parameter data, the SCSI port name MUST be encoded as: 2664 - The iSCSI Name in UTF-8 format, followed by 2665 - a comma separator (1 byte), followed by 2666 - the ASCII character 'i' (for SCSI Initiator Port) or the 2667 ASCII character 't' (for SCSI Target Port) (1 byte), 2668 followed by 2669 - a comma separator (1 byte), followed by 2670 - a text encoding as a hex-constant (see Section 5.1 "Text 2671 Format") of the ISID (for SCSI initiator port) or the 2672 portal group tag (for SCSI target port) including the 2673 initial 0X or 0x and the terminating null (14 bytes). 2675 The ASCII character 'i' or 't' is the label that 2676 identifies this port as either a SCSI Initiator Port or a 2677 SCSI Target Port. 2679 I_T nexus - a relationship between a SCSI Initiator Port and a 2680 SCSI Target Port, according to [SAM2]. For iSCSI, this 2681 relationship is a session, defined as a relationship 2682 between an iSCSI Initiator's end of the session (SCSI 2683 Initiator Port) and the iSCSI Target's Portal Group. The 2684 I_T nexus can be identified by the conjunction of the SCSI 2685 port names or by the iSCSI session identifier SSID. iSCSI 2686 defines the I_T nexus identifier to be the tuple (iSCSI 2687 Initiator Name + 'i' + ISID, iSCSI Target Name + 't' + 2688 Portal Group Tag). 2690 NOTE: The I_T nexus identifier is not equal to the session 2691 identifier (SSID). 2693 4.4.3. Consequences of the Model 2695 This section describes implementation and behavioral requirements 2696 that result from the mapping of SCSI constructs to the iSCSI 2697 constructs defined above. Between a given SCSI initiator port and 2698 a given SCSI target port, only one I_T nexus (session) can exist. 2699 No more than one nexus relationship (parallel nexus) is allowed by 2700 [SAM2]. Therefore, at any given time, only one session with the 2701 same session identifier (SSID) can exist between a given iSCSI 2702 initiator node and an iSCSI target node. 2704 These assumptions lead to the following conclusions and 2705 requirements: 2707 ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal 2708 Group (SCSI target port), there can only be one session with a 2709 given value for ISID that identifies the SCSI initiator port. See 2710 Section 10.12.5 "ISID". 2712 The structure of the ISID that contains a naming authority 2713 component (see Section 10.12.5 "ISID" and [RFC3721]) provides a 2714 mechanism to facilitate compliance with the ISID rule. (See 2715 Section 9.1.1 "Conservative Reuse of ISIDs".) 2717 The iSCSI Initiator Node should manage the assignment of ISIDs 2718 prior to session initiation. The "ISID RULE" does not preclude the 2719 use of the same ISID from the same iSCSI Initiator with different 2720 Target Portal Groups on the same iSCSI target or on other iSCSI 2721 targets (see Section 9.1.1 "Conservative Reuse of ISIDs"). 2722 Allowing this would be analogous to a single SCSI Initiator Port 2723 having relationships (nexus) with multiple SCSI target ports on 2724 the same SCSI target device or SCSI target ports on other SCSI 2725 target devices. It is also possible to have multiple sessions with 2726 different ISIDs to the same Target Portal Group. Each such session 2727 would be considered to be with a different initiator even when the 2728 sessions originate from the same initiator device. The same ISID 2729 may be used by a different iSCSI initiator because it is the iSCSI 2730 Name together with the ISID that identifies the SCSI Initiator 2731 Port. 2733 NOTE: A consequence of the ISID RULE and the specification for the 2734 I_T nexus identifier is that two nexus with the same identifier 2735 should never exist at the same time. 2737 TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH 2738 at session creation (when an initiator presents a 0 value at 2739 Login). After being selected, the same TSIH value MUST be used 2740 whenever initiator or target refers to the session and a TSIH is 2741 required. 2743 4.4.3.1. I_T Nexus State 2745 Certain nexus relationships contain an explicit state (e.g., 2746 initiator-specific mode pages) that may need to be preserved by 2747 the device server [SAM2] in a logical unit through changes or 2748 failures in the iSCSI layer (e.g., session failures). In order for 2749 that state to be restored, the iSCSI initiator should reestablish 2750 its session (re-login) to the same Target Portal Group using the 2751 previous ISID. That is, it should perform session recovery as 2752 described in Chapter 6. This is because the SCSI initiator port 2753 identifier and the SCSI target port identifier (or relative target 2754 port) form the datum that the SCSI logical unit device server uses 2755 to identify the I_T nexus. 2757 4.5. iSCSI UML Model 2759 This section presents the application of the UML modeling concepts 2760 discussed in Section 3 to the iSCSI and SCSI architecture model 2761 discussed in Section 4.4. 2763 +----------------+ 2764 | Network Entity | 2765 +----------------+ 2766 @ 1 @ 1 2767 | | 2768 +--------------------+ | 2769 | | 2770 | | 0..* 2771 | +------------------+ 2772 | | iSCSI Node | 2773 | +------------------+ 2774 | @ @ 2775 | | | 2776 | +-----------+ =(a)= +-----------+ 2777 | | | 2778 | | 0..1 | 0..1 2779 | +------------------------+ +----------------------+ 2780 | | iSCSI Target Node | | iSCSI Initiator Node | 2781 | +------------------------+ +----------------------+ 2782 | @ 1 @ 1 2783 | +--------------+ | 2784 | 1..* | | 1..* 2785 | +-----------------------------+ 2786 | | Portal Group | 2787 | +-----------------------------+ 2788 | O 1 2789 | | 2790 | | 1..* 2791 | 1..* +------------------------+ 2792 +-------------------| Network Portal | 2793 +------------------------+ 2795 (a) Each instance of an iSCSI Node class MUST contain one iSCSI 2796 Target Node instance or one iSCSI Initiator Node instance, or 2797 both. 2799 +----------------+ 2800 | Network Entity | 2801 +----------------+ 2802 @ 1 @ 1 2803 | | +-------------------+ 2804 +---------------------+ | | iSCSI Session | 2805 | | +-------------------+ 2806 | | 0..* | SSID[1] | 2807 | +--------------------+ | ISID[1] | 2808 | | iSCSI Node | +-------------------+ 2809 | +--------------------+ @ 1 2810 | | iSCSI Node Name[1] | | 2811 | | Alias [0..1] | | 0..* 2812 | +--------------------+ +------------------+ 2813 | | | | iSCSI Connection | 2814 | +--------------------+ +------------------+ 2815 | @ 1 @ 1 | CID[1] | 2816 | | | +------------------+ 2817 | +-------------+ ==(b)== +----------+ 0..* | 2818 | | 1 | 1 | 2819 | +------------------------+ +------------------------+ | 2820 | | iSCSI Target Node | | iSCSI Initiator Node | | 2821 | +------------------------+ +------------------------+ | 2822 | | iSCSI Target name [1] | |iSCSI Initiator Name [1]| | 2823 | +------------------------+ +------------------------+ | 2824 | @ 1 @ 1 | 2825 | | 1..* | 1..* | 2826 | +--------------------------+ +------------------------+ | 2827 | | Target Portal Group | | Initiator Portal Group | | 2828 | +--------------------------+ +------------------------+ | 2829 | |Target Portal Group Tag[1]| | Portal group tag[1] | | 2830 | +--------------------------+ +------------------------+ | 2831 | o 1 o 1 | 2832 | +------------+ +---------+ | 2833 | 1..* | | 1..* | 2834 | +-------------------------+ | 2835 | | Network Portal | | 2836 | +-------------------------+ | 2837 | 1..* | IP Address [1] | 1 | 2838 +----------------| TCP Port [0..1] |<----------------------+ 2839 +-------------------------+ 2841 (b) Each instance of an iSCSI Node class MUST contain one iSCSI 2842 Target Node instance or one iSCSI Initiator Node instance, or 2843 both. 2845 4.6. Request/Response Summary 2847 This section lists and briefly describes all the iSCSI PDU types 2848 (request and responses). 2850 All iSCSI PDUs are built as a set of one or more header segments 2851 (basic and auxiliary) and zero or one data segments. The header 2852 group and the data segment may each be followed by a CRC (digest). 2854 The basic header segment has a fixed length of 48 bytes. 2856 4.6.1. Request/Response Types Carrying SCSI Payload 2858 4.6.1.1. SCSI-Command 2860 This request carries the SCSI CDB and all the other SCSI execute 2861 command procedure call (see [SAM2]) IN arguments such as task 2862 attributes, Expected Data Transfer Length for one or both transfer 2863 directions (the latter for bidirectional commands), and Task Tag 2864 (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the 2865 initiator and target from the LUN field in the request and the I_T 2866 nexus is implicit in the session identification. 2868 In addition, the SCSI-command PDU carries information required for 2869 the proper operation of the iSCSI protocol - the command sequence 2870 number (CmdSN) and the expected status number (ExpStatSN) on the 2871 connection it is issued. 2873 All or part of the SCSI output (write) data associated with the 2874 SCSI command may be sent as part of the SCSI-Command PDU as a data 2875 segment. 2877 4.6.1.2. SCSI-Response 2879 The SCSI-Response carries all the SCSI execute-command procedure 2880 call (see [SAM2]) OUT arguments and the SCSI execute-command 2881 procedure call return value. 2883 The SCSI-Response contains the residual counts from the operation, 2884 if any, an indication of whether the counts represent an overflow 2885 or an underflow, and the SCSI status if the status is valid or a 2886 response code (a non-zero return value for the execute-command 2887 procedure call) if the status is not valid. 2889 For a valid status that indicates that the command has been 2890 processed, but resulted in an exception (e.g., a SCSI CHECK 2891 CONDITION), the PDU data segment contains the associated sense 2892 data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI. 2894 Some data segment content may also be associated (in the data 2895 segment) with a non-zero response code. 2897 In addition, the SCSI-Response PDU carries information required 2898 for the proper operation of the iSCSI protocol: 2900 - The number of Data-In PDUs that a target has sent (to enable 2901 the initiator to check that all have arrived). 2903 - StatSN - the Status Sequence Number on this connection. 2905 - ExpCmdSN - the next Expected Command Sequence Number at the 2906 target. 2908 - MaxCmdSN - the maximum CmdSN acceptable at the target from 2909 this initiator. 2911 4.6.1.3. Task Management Function Request 2913 The Task Management function request provides an initiator with a 2914 way to explicitly control the execution of one or more SCSI Tasks 2915 or iSCSI functions. The PDU carries a function identifier (which 2916 task management function to perform) and enough information to 2917 unequivocally identify the task or task-set on which to perform 2918 the action, even if the task(s) to act upon has not yet arrived or 2919 has been discarded due to an error. 2921 The referenced tag identifies an individual task if the function 2922 refers to an individual task. 2924 The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is 2925 identified by the LUN and the session identification (the session 2926 identifies an I_T nexus). 2928 For task sets, the CmdSN of the Task Management function request 2929 helps identify the tasks upon which to act, namely all tasks 2930 associated with a LUN and having a CmdSN preceding the Task 2931 Management function request CmdSN. 2933 For a Task Management function, the coordination between responses 2934 to the tasks affected and the Task Management function response is 2935 done by the target. 2937 4.6.1.4. Task Management Function Response 2939 The Task Management function response carries an indication of 2940 function completion for a Task Management function request 2941 including how it completed (response and qualifier) and additional 2942 information for failure responses. 2944 After the Task Management response indicates Task Management 2945 function completion, the initiator will not receive any additional 2946 responses from the affected tasks. 2948 4.6.1.5. SCSI Data-out and SCSI Data-in 2950 SCSI Data-out and SCSI Data-in are the main vehicles by which SCSI 2951 data payload is carried between initiator and target. Data payload 2952 is associated with a specific SCSI command through the Initiator 2953 Task Tag. For target convenience, outgoing solicited data also 2954 carries a Target Transfer Tag (copied from R2T) and the LUN. Each 2955 PDU contains the payload length and the data offset relative to 2956 the buffer address contained in the SCSI execute command procedure 2957 call. 2959 In each direction, the data transfer is split into "sequences". An 2960 end-of-sequence is indicated by the F bit. 2962 An outgoing sequence is either unsolicited (only the first 2963 sequence can be unsolicited) or consists of all the Data-Out PDUs 2964 sent in response to an R2T. 2966 Input sequences enable the switching of direction for 2967 bidirectional commands as required. 2969 For input, the target may request positive acknowledgement of 2970 input data. This is limited to sessions that support error 2971 recovery and is implemented through the A bit in the SCSI Data-in 2972 PDU header. 2974 Data-in and Data-out PDUs also carry the DataSN to enable the 2975 initiator and target to detect missing PDUs (discarded due to an 2976 error). 2978 In addition, StatSN is carried by the Data-In PDUs. 2980 To enable a SCSI command to be processed while involving a minimum 2981 number of messages, the last SCSI Data-in PDU passed for a command 2982 may also contain the status if the status indicates termination 2983 with no exceptions (no sense or response involved). 2985 4.6.1.6. Ready To Transfer (R2T) 2987 R2T is the mechanism by which the SCSI target "requests" the 2988 initiator for output data. R2T specifies to the initiator the 2989 offset of the requested data relative to the buffer address from 2990 the execute command procedure call and the length of the solicited 2991 data. 2993 To help the SCSI target associate the resulting Data-out with an 2994 R2T, the R2T carries a Target Transfer Tag that will be copied by 2995 the initiator in the solicited SCSI Data-out PDUs. There are no 2996 protocol specific requirements with regard to the value of these 2997 tags, but it is assumed that together with the LUN, they will 2998 enable the target to associate data with an R2T. 3000 R2T also carries information required for proper operation of the 3001 iSCSI protocol, such as: 3003 - R2TSN (to enable an initiator to detect a missing R2T) 3005 - StatSN 3007 - ExpCmdSN 3009 - MaxCmdSN 3011 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload 3013 4.6.2.1. Asynchronous Message 3015 Asynchronous Messages are used to carry SCSI asynchronous events 3016 (AEN) and iSCSI asynchronous messages. 3018 When carrying an AEN, the event details are reported as sense data 3019 in the data segment. 3021 4.6.3. Requests/Responses Carrying iSCSI Only Payload 3023 4.6.3.1. Text Request and Text Response 3025 Text requests and responses are designed as a parameter 3026 negotiation vehicle and as a vehicle for future extension. 3028 In the data segment Text Requests/Responses carry text information 3029 using a simple "key=value" syntax. 3031 Text Request/Responses may form extended sequences using the same 3032 Initiator Task Tag. The initiator uses the F (Final) flag bit in 3033 the text request header to indicate its readiness to terminate a 3034 sequence. The target uses the F (Final) flag bit in the text 3035 response header to indicate its consent to sequence termination. 3037 Text Request and Responses also use the Target Transfer Tag to 3038 indicate continuation of an operation or a new beginning. A target 3039 that wishes to continue an operation will set the Target Transfer 3040 Tag in a Text Response to a value different from the default 3041 0xffffffff. An initiator willing to continue will copy this value 3042 into the Target Transfer Tag of the next Text Request. If the 3043 initiator wants to restart the current target negotiation (start 3044 fresh) will set the Target Transfer Tag to 0xffffffff. 3046 Although a complete exchange is always started by the initiator, 3047 specific parameter negotiations may be initiated by the initiator 3048 or target. 3050 4.6.3.2. Login Request and Login Response 3052 Login Requests and Responses are used exclusively during the Login 3053 Phase of each connection to set up the session and connection 3054 parameters. (The Login Phase consists of a sequence of login 3055 requests and responses carrying the same Initiator Task Tag.) 3057 A connection is identified by an arbitrarily selected connection- 3058 ID (CID) that is unique within a session. 3060 Similar to the Text Requests and Responses, Login 3061 Requests/Responses carry key=value text information with a simple 3062 syntax in the data segment. 3064 The Login Phase proceeds through several stages (security 3065 negotiation, operational parameter negotiation) that are selected 3066 with two binary coded fields in the header -- the "current stage" 3067 (CSG) and the "next stage" (NSG) with the appearance of the latter 3068 being signaled by the "transit" flag (T). 3070 The first Login Phase of a session plays a special role, called 3071 the leading login, which determines some header fields (e.g., the 3072 version number, the maximum number of connections, and the session 3073 identification). 3075 The CmdSN initial value is also set by the leading login. 3077 StatSN for each connection is initiated by the connection login. 3079 A login request may indicate an implied logout (cleanup) of the 3080 connection to be logged in (a connection restart) by using the 3081 same Connection ID (CID) as an existing connection as well as the 3082 same session identifying elements of the session to which the old 3083 connection was associated. 3085 4.6.3.3. Logout Request and Response 3087 Logout Requests and Responses are used for the orderly closing of 3088 connections for recovery or maintenance. The logout request may be 3089 issued following a target prompt (through an asynchronous message) 3090 or at an initiators initiative. When issued on the connection to 3091 be logged out no other request may follow it. 3093 The Logout response indicates that the connection or session 3094 cleanup is completed and no other responses will arrive on the 3095 connection (if received on the logging out connection). In 3096 addition, the Logout Response indicates how long the target will 3097 continue to hold resources for recovery (e.g., command execution 3098 that continues on a new connection) in the text key Time2Retain 3099 and how long the initiator must wait before proceeding with 3100 recovery in the text key Time2Wait. 3102 4.6.3.4. SNACK Request 3104 With the SNACK Request, the initiator requests retransmission of 3105 numbered-responses or data from the target. A single SNACK request 3106 covers a contiguous set of missing items, called a run, of a given 3107 type of items. The type is indicated in a type field in the PDU 3108 header. The run is composed of an initial item (StatSN, DataSN, 3109 R2TSN) and the number of missed Status, Data, or R2T PDUs. For 3110 long data-in sequences, the target may request (at predefined 3111 minimum intervals) a positive acknowledgement for the data sent. A 3112 SNACK request with a type field that indicates ACK and the number 3113 of Data-In PDUs acknowledged conveys this positive 3114 acknowledgement. 3116 4.6.3.5. Reject 3118 Reject enables the target to report an iSCSI error condition 3119 (e.g., protocol, unsupported option) that uses a Reason field in 3120 the PDU header and includes the complete header of the bad PDU in 3121 the Reject PDU data segment. 3123 4.6.3.6. NOP-Out Request and NOP-In Response 3125 This request/response pair may be used by an initiator and target 3126 as a "ping" mechanism to verify that a connection/session is still 3127 active and all of its components are operational. Such a ping may 3128 be triggered by the initiator or target. The triggering party 3129 indicates that it wants a reply by setting a value different from 3130 the default 0xffffffff in the corresponding Initiator/Target 3131 Transfer Tag. 3133 NOP-In/NOP-Out may also be used "unidirectional" to convey to the 3134 initiator/target command, status or data counter values when there 3135 is no other "carrier" and there is a need to update the 3136 initiator/target. 3138 5. SCSI Mode Parameters for iSCSI 3140 There are no iSCSI specific mode pages. 3142 6. Login and Full Feature Phase Negotiation 3144 iSCSI parameters are negotiated at session or connection 3145 establishment by using Login Requests and Responses (see Section 3146 3.2.3 - "iSCSI Login") and during Full Feature Phase (Section 3147 3.2.4 - "iSCSI Full Feature Phase") by using Text Requests and 3148 Responses. In both cases the mechanism used is an exchange of 3149 iSCSI-text-key=value pairs. For brevity, iSCSI-text-keys are 3150 called just keys in the rest of this document. 3152 Keys are either declarative or require negotiation and the key 3153 description indicates if the key is declarative or requires 3154 negotiation. 3156 For the declarative keys the declaring party sets a value for the 3157 key. The key specification indicates if the key can be declared by 3158 the initiator, target or both. 3160 For the keys that require negotiation, one of the parties (the 3161 proposing party) proposes a value or set of values by including 3162 the key=value in the data part of a Login or Text Request or 3163 Response. The other party (the accepting party) makes a selection 3164 based on the value or list of values proposed and includes the 3165 selected value in a key=value in the data part of the following 3166 Login or Text Response or Request. For most of the keys, both the 3167 initiator and target can be proposing parties. 3169 The login process proceeds in two stages - the security 3170 negotiation stage and the operational parameter negotiation stage. 3171 Both stages are optional but at least one of them has to be 3172 present to enable setting some mandatory parameters. 3174 If present, the security negotiation stage precedes the 3175 operational parameter negotiation stage. 3177 Progression from stage to stage is controlled by the T 3178 (Transition) bit in the Login Request/Response PDU header. Through 3179 the T bit set to 1, the initiator indicates that it would like to 3180 transition. The target agrees to the transition (and selects the 3181 next stage) when ready. A field in the Login PDU header indicates 3182 the current stage (CSG) and during transition, another field 3183 indicates the next stage (NSG) proposed (initiator) and selected 3184 (target). 3186 The Text negotiation process is used to negotiate or declare 3187 operational parameters. The negotiation process is controlled by 3188 the F (final) bit in the PDU header. During text negotiations, the 3189 F bit is used by the initiator to indicate that it is ready to 3190 finish the negotiation and by the Target to acquiesce the end of 3191 negotiation. 3193 Since some key=value pairs may not fit entirely in a single PDU, 3194 the C (continuation) bit is used (both in Login and Text) to 3195 indicate that "more follows". 3197 The text negotiation uses an additional mechanism by which a 3198 target may deliver larger amounts of data to an enquiring 3199 initiator. The target sets a Target Task Tag to be used as a 3200 bookmark which when returned by the initiator, means "go on". If 3201 reset to a "neutral value", it means "forget about the rest". 3203 This chapter details types of keys and values used, the syntax 3204 rules for parameter formation, and the negotiation schemes to be 3205 used with different types of parameters. 3207 6.1. Text Format 3209 The initiator and target send a set of key=value pairs encoded in 3210 UTF-8 Unicode. All the text keys and text values specified in this 3211 document are to be presented and interpreted in the case in which 3212 they appear in this document. They are case sensitive. 3214 The following character symbols are used in this document for text 3215 items (the hexadecimal values represent Unicode code points): 3217 (a-z, A-Z) - letters 3218 (0-9) - digits 3219 " " (0x20) - space 3220 "." (0x2e) - dot 3221 "-" (0x2d) - minus 3222 "+" (0x2b) - plus 3223 "@" (0x40) - commercial at 3224 "_" (0x5f) - underscore 3226 "=" (0x3d) - equal 3227 ":" (0x3a) - colon 3228 "/" (0x2f) - solidus or slash 3229 "[" (0x5b) - left bracket 3230 "]" (0x5d) - right bracket 3231 null (0x00) - null separator 3232 "," (0x2c) - comma 3233 "~" (0x7e) - tilde 3235 Key=value pairs may span PDU boundaries. An initiator or target 3236 that sends partial key=value text within a PDU indicates that more 3237 text follows by setting the C bit in the Text or Login Request or 3238 Text or Login Response to 1. Data segments in a series of PDUs 3239 that have the C bit set to 1 and end with a PDU that have the C 3240 bit set to 0, or include a single PDU that has the C bit set to 0 3241 have to be considered as forming a single logical-text-data- 3242 segment (LTDS). 3244 Every key=value pair, including the last or only pair in a LTDS, 3245 MUST be followed by one null (0x00) delimiter. 3247 A key-name is whatever precedes the first = in the key=value pair. 3248 The term key is used frequently in this document in place of key- 3249 name. 3251 A value is whatever follows the first = in the key=value pair up 3252 to the end of the key=value pair, but not including the null 3253 delimiter. 3255 The following definitions will be used in the rest of this 3256 document: 3258 standard-label: A string of one or more characters that 3259 consist of letters, digits, dot, minus, plus, commercial at, 3260 or underscore. A standard-label MUST begin with a capital 3261 letter and must not exceed 63 characters. 3263 key-name: A standard-label. 3265 text-value: A string of zero or more characters that consist 3266 of letters, digits, dot, minus, plus, commercial at, 3267 underscore, slash, left bracket, right bracket, or colon. 3269 iSCSI-name-value: A string of one or more characters that 3270 consist of minus, dot, colon, or any character allowed by 3271 the output of the iSCSI string-prep template as specified in 3272 [RFC3722] (see also Section 3.2.6.2 - "iSCSI Name 3273 Encoding"). 3275 iSCSI-local-name-value: A UTF-8 string; no null characters are 3276 allowed in the string. This encoding is to be used for 3277 localized (internationalized) aliases. 3279 boolean-value: The string "Yes" or "No". 3281 hex-constant: A hexadecimal constant encoded as a string that 3282 starts with "0x" or "0X" followed by one or more digits or 3283 the letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex- 3284 constants are used to encode numerical values or binary 3285 strings. When used to encode numerical values, the excessive 3286 use of leading 0 digits is discouraged. The string following 3287 0X (or 0x) represents a base16 number that starts with the 3288 most significant base16 digit, followed by all other digits 3289 in decreasing order of significance and ending with the 3290 least-significant base16 digit. When used to encode binary 3291 strings, hexadecimal constants have an implicit byte-length 3292 that includes four bits for every hexadecimal digit of the 3293 constant, including leading zeroes. For example, a hex- 3294 constant of n hexadecimal digits has a byte-length of (the 3295 integer part of) (n+1)/2. 3297 decimal-constant: An unsigned decimal number with the digit 0 3298 or a string of one or more digits that start with a non-zero 3299 digit. Decimal-constants are used to encode numerical 3300 values or binary strings. Decimal constants can only be used 3301 to encode binary strings if the string length is explicitly 3302 specified. There is no implicit length for decimal strings. 3303 Decimal-constant MUST NOT be used for parameter values if 3304 the values can be equal or greater than 2**64 (numerical) or 3305 for binary strings that can be longer than 64 bits. 3307 base64-constant: base64 constant encoded as a string that 3308 starts with "0b" or "0B" followed by 1 or more digits or 3309 letters or plus or slash or equal. The encoding is done 3310 according to [RFC2045] and each character, except equal, 3311 represents a base64 digit or a 6-bit binary string. Base64- 3312 constants are used to encode numerical-values or binary 3313 strings. When used to encode numerical values, the excessive 3314 use of leading 0 digits (encoded as A) is discouraged. The 3315 string following 0B (or 0b) represents a base64 number that 3316 starts with the most significant base64 digit, followed by 3317 all other digits in decreasing order of significance and 3318 ending with the least-significant base64 digit; the least 3319 significant base64 digit may be optionally followed by pad 3320 digits (encoded as equal) that are not considered as part of 3321 the number. When used to encode binary strings, base64- 3322 constants have an implicit byte-length that includes six 3323 bits for every character of the constant, excluding trailing 3324 equals (i.e., a base64-constant of n base64 characters 3325 excluding the trailing equals has a byte-length of ((the 3326 integer part of) (n*3/4)). Correctly encoded base64 strings 3327 cannot have n values of 1, 5 ... k*4+1. 3329 numerical-value: An unsigned integer always less than 2**64 3330 encoded as a decimal-constant or a hex-constant. Unsigned 3331 integer arithmetic applies to numerical-values. 3333 large-numerical-value: An unsigned integer that can be larger 3334 than or equal to 2**64 encoded as a hex constant, or base64- 3335 constant. Unsigned integer arithmetic applies to large- 3336 numeric-values. 3338 numeric-range: Two numerical-values separated by a tilde where 3339 the value to the right of tilde must not be lower than the 3340 value to the left. 3342 regular-binary-value: A binary string not longer than 64 bits 3343 encoded as a decimal constant, hex constant, or base64- 3344 constant. The length of the string is either specified by 3345 the key definition or is the implicit byte-length of the 3346 encoded string. 3348 large-binary-value: A binary string longer than 64 bits 3349 encoded as a hex-constant or base64-constant. The length of 3350 the string is either specified by the key definition or is 3351 the implicit byte-length of the encoded string. 3353 binary-value: A regular-binary-value or a large-binary-value. 3354 Operations on binary values are key specific. 3356 simple-value: Text-value, iSCSI-name-value, boolean-value, 3357 numeric-value, a numeric-range, or a binary-value. 3359 list-of-values: A sequence of text-values separated by a 3360 comma. 3362 If not otherwise specified, the maximum length of a simple-value 3363 (not its encoded representation) is 255 bytes not including the 3364 delimiter (comma or zero byte). 3366 Any iSCSI target or initiator MUST support receiving at least 8192 3367 bytes of key=value data in a negotiation sequence. When proposing 3368 or accepting authentication methods that explicitly require 3369 support for very long authentication items, the initiator and 3370 target MUST support receiving of at least 64 kilobytes of 3371 key=value data. 3373 6.2. Text Mode Negotiation 3375 During login, and thereafter, some session or connection 3376 parameters are either declared or negotiated through an exchange 3377 of textual information. 3379 The initiator starts the negotiation and/or declaration through a 3380 Text or Login request and indicates when it is ready for 3381 completion (by setting the F bit to 1 and keeping it to 1 in a 3382 Text Request or the T bit in the Login Request). As negotiation 3383 text may span PDU boundaries, a Text or Login Request or Text or 3384 Login Response PDU that have the C bit set to 1 MUST NOT have the 3385 F/T bit set to 1. 3387 A target receiving a Text or Login Request with the C bit set to 1 3388 MUST answer with a Text or Login Response with no data segment 3389 (DataSegmentLength 0). An initiator receiving a Text or Login 3390 Response with the C bit set to 1 MUST answer with a Text or Login 3391 Request with no data segment (DataSegmentLength 0). 3393 A target or initiator SHOULD NOT use a Text or Login Response or 3394 Text or Login Request with no data segment (DataSegmentLength 0) 3395 unless explicitly required by a general or a key-specific 3396 negotiation rule. 3398 There MUST NOT be more than one outstanding Text Request, or Text 3399 Response PDU on an iSCSI connection. An outstanding PDU in this 3400 context is one that has not been acknowledged by the remote iSCSI 3401 side. 3403 The format of a declaration is: 3405 Declarer-> = 3407 The general format of text negotiation is: 3409 Proposer-> = 3411 Acceptor-> ={|NotUnderstood|Irrelevant|Reject} 3413 Thus a declaration is a one-way textual exchange (unless the key 3414 is not understood by the receiver) while a negotiation is a two- 3415 way exchange. 3417 The proposer or declarer can either be the initiator or the 3418 target, and the acceptor can either be the target or initiator, 3419 respectively. Targets are not limited to respond to key=value 3420 pairs as proposed by the initiator. The target may propose 3421 key=value pairs of its own. 3423 All negotiations are explicit (i.e., the result MUST only be based 3424 on newly exchanged or declared values). There are no implicit 3425 proposals. If a proposal is not made, then a reply cannot be 3426 expected. Conservative design also requires that default values 3427 should not be relied upon when use of some other value has serious 3428 consequences. 3430 The value proposed or declared can be a numerical-value, a 3431 numerical-range defined by lower and upper value with both 3432 integers separated by tilde, a binary value, a text-value, an 3433 iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes 3434 or No), or a list of comma separated text-values. A range, a 3435 large-numerical-value, an iSCSI-name-value and an iSCSI-local- 3436 name-value MAY ONLY be used if it is explicitly allowed. An 3437 accepted value can be a numerical-value, a large-numerical-value, 3438 a text-value, or a boolean-value. 3440 If a specific key is not relevant for the current negotiation, the 3441 acceptor may answer with the constant "Irrelevant" for all types 3442 of negotiation. However the negotiation is not considered as 3443 failed if the answer is "Irrelevant". The "Irrelevant" answer is 3444 meant for those cases in which several keys are presented by a 3445 proposing party but the selection made by the acceptor for one of 3446 the keys makes other keys irrelevant. The following example 3447 illustrates the use of "Irrelevant": 3449 I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192 3450 T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant 3452 I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb) 3453 T->I X#vkey1=None,X#vkey2=Irrelevant 3455 Any key not understood by the acceptor may be ignored by the 3456 acceptor without affecting the basic function. However, the answer 3457 for a key not understood MUST be key=NotUnderstood. Note that 3458 NotUnderstood is a valid answer for both declarative and 3459 negotiated keys. The general iSCSI philosophy is that 3460 comprehension precedes processing for any iSCSI key. A proposer 3461 of an iSCSI key, negotiated or declarative, in a text key exchange 3462 MUST thus be able to properly handle a NotUnderstood response. 3464 The proper way to handle a NotUnderstood response depends on where 3465 the key is specified and whether the key is declarative vs. 3466 negotiated. All keys defined in [RFC3720] MUST be supported by all 3467 compliant implementations; a NotUnderstood answer on any of the 3468 [RFC3720] keys therefore MUST be considered a protocol error and 3469 handled accordingly. For all other later keys, a NotUnderstood 3470 answer concludes the negotiation for a negotiated key whereas for 3471 a declarative key, a NotUnderstood answer simply informs the 3472 declarer of a lack of comprehension by the receiver. 3474 In either case, a NotUnderstood answer always requires that the 3475 protocol behavior associated with that key not be used within the 3476 scope of the key (connection/session) by either side. 3478 The constants "None", "Reject", "Irrelevant", and "NotUnderstood" 3479 are reserved and MUST ONLY be used as described here. Violation of 3480 this rule is a protocol error (in particular the use of "Reject", 3481 "Irrelevant", and "NotUnderstood" as proposed values). 3483 Reject or Irrelevant are legitimate negotiation options where 3484 allowed but their excessive use is discouraged. A negotiation is 3485 considered complete when the acceptor has sent the key value pair 3486 even if the value is "Reject", "Irrelevant", or "NotUnderstood". 3487 Sending the key again would be a re-negotiation and is forbidden 3488 for many keys. 3490 If the acceptor sends "Reject" as an answer the negotiated key is 3491 left at its current value (or default if no value was set). If the 3492 current value is not acceptable to the proposer on the connection 3493 or to the session it is sent, the proposer MAY choose to terminate 3494 the connection or session. 3496 All keys in this document, except for the X extension formats, 3497 MUST be supported by iSCSI initiators and targets when used as 3498 specified here. If used as specified, these keys MUST NOT be 3499 answered with NotUnderstood. 3501 Implementers may introduce new keys by prefixing them with X- 3502 followed by their (reversed) domain name, or with new keys 3503 registered with IANA prefixing them with X#. For example, the 3504 entity owning the domain example.com can issue: 3506 X-com.example.bar.foo.do_something=3 3508 or a new registered key may be used as in: 3510 X#SuperCalyPhraGilistic=Yes 3512 Implementers MAY also introduce new values, but ONLY for new keys 3513 or authentication methods (see Section 11 - "iSCSI Security Text 3514 Keys and Authentication Methods"), or digests (see Section 12.1 - 3515 "HeaderDigest and DataDigest"). 3517 Whenever parameter action or acceptance are dependent on other 3518 parameters, the dependency rules and parameter sequence must be 3519 specified with the parameters. 3521 In the Login Phase (see Login Phase), every stage is a separate 3522 negotiation. In the FullFeaturePhase, a Text Request Response 3523 sequence is a negotiation. Negotiations MUST be handled as atomic 3524 operations. For example, all negotiated values go into effect 3525 after the negotiation concludes in agreement or are ignored if the 3526 negotiation fails. 3528 Some parameters may be subject to integrity rules (e.g., 3529 parameter-x must not exceed parameter-y or parameter-u not 1 3530 implies parameter-v be Yes). Whenever required, integrity rules 3531 are specified with the keys. Checking for compliance with the 3532 integrity rule must only be performed after all the parameters are 3533 available (the existent and the newly negotiated). An iSCSI target 3534 MUST perform integrity checking before the new parameters take 3535 effect. An initiator MAY perform integrity checking. 3537 An iSCSI initiator or target MAY terminate a negotiation that does 3538 not end within a reasonable time or number of exchanges. 3540 6.2.1. List negotiations 3542 In list negotiation, the originator sends a list of values (which 3543 may include "None") in its order of preference. 3545 The responding party MUST respond with the same key and the first 3546 value that it supports (and is allowed to use for the specific 3547 originator) selected from the originator list. 3549 The constant "None" MUST always be used to indicate a missing 3550 function. However, "None" is only a valid selection if it is 3551 explicitly proposed. 3553 If an acceptor does not understand any particular value in a list, 3554 it MUST ignore it. If an acceptor does not support, does not 3555 understand, or is not allowed to use any of the proposed options 3556 with a specific originator, it may use the constant "Reject" or 3557 terminate the negotiation. The selection of a value not proposed 3558 MUST be handled as a protocol error. 3560 6.2.2. Simple-value Negotiations 3562 For simple-value negotiations, the accepting party MUST answer 3563 with the same key. The value it selects becomes the negotiation 3564 result. 3566 Proposing a value not admissible (e.g., not within the specified 3567 bounds) MAY be answered with the constant "Reject" or the acceptor 3568 MAY select an admissible value. 3570 The selection, by the acceptor, of a value not admissible under 3571 the selection rules is considered a protocol error. The selection 3572 rules are key-specific. 3574 For a numerical range the value selected must be an integer within 3575 the proposed range or "Reject" (if the range is unacceptable). 3577 For Boolean negotiations (i.e., keys taking the values Yes or No), 3578 the accepting party MUST answer with the same key and the result 3579 of the negotiation when the received value does not determine that 3580 result by itself. The last value transmitted becomes the 3581 negotiation result. The rules for selecting the value to answer 3582 with are expressed as Boolean functions of the value received, and 3583 the value that the accepting party would have selected if given a 3584 choice. 3586 Specifically, the two cases in which answers are OPTIONAL are: 3588 - The Boolean function is "AND" and the value "No" is 3589 received. The outcome of the negotiation is "No". 3591 - The Boolean function is "OR" and the value "Yes" is 3592 received. The outcome of the negotiation is "Yes". 3594 Responses are REQUIRED in all other cases, and the value chosen 3595 and sent by the acceptor becomes the outcome of the negotiation. 3597 6.3. Login Phase 3599 The Login Phase establishes an iSCSI connection between an 3600 initiator and a target; it creates also a new session or 3602 associates the connection to an existing session. The Login Phase 3603 sets the iSCSI protocol parameters, security parameters, and 3604 authenticates the initiator and target to each other. 3606 The Login Phase is only implemented via Login request and 3607 responses. The whole Login Phase is considered as a single task 3608 and has a single Initiator Task Tag (similar to the linked SCSI 3609 commands). 3611 There MUST NOT be more than one outstanding Login Request, or 3612 Login Response on an iSCSI connection. An outstanding PDU in this 3613 context is one that has not been acknowledged by the remote iSCSI 3614 side. 3616 The default MaxRecvDataSegmentLength is used during Login. 3618 The Login Phase sequence of requests and responses proceeds as 3619 follows: 3621 - Login initial request 3623 - Login partial response (optional) 3625 - More Login requests and responses (optional) 3627 - Login Final-Response (mandatory) 3629 The initial login request of any connection MUST include the 3630 InitiatorName key=value pair. The initial login request of the 3631 first connection of a session MAY also include the SessionType 3632 key=value pair. For any connection within a session whose type is 3633 not "Discovery", the first login request MUST also include the 3634 TargetName key=value pair. 3636 The Login Final-response accepts or rejects the Login request. 3638 The Login Phase MAY include a SecurityNegotiation stage and a 3639 LoginOperationalNegotiation stage and MUST include at least one of 3640 them, but the included stage MAY be empty except for the mandatory 3641 names. 3643 The login requests and responses contain a field (CSG) that 3644 indicates the current negotiation stage (SecurityNegotiation or 3645 LoginOperationalNegotiation). If both stages are used, the 3646 SecurityNegotiation MUST precede the LoginOperationalNegotiation. 3648 Some operational parameters can be negotiated outside the login 3649 through Text requests and responses. 3651 Security MUST be completely negotiated within the Login Phase. The 3652 use of underlying IPsec security is specified in Chapter 8 and in 3653 [RFC3723]. iSCSI support for security within the protocol only 3654 consists of authentication in the Login Phase. 3656 In some environments, a target or an initiator is not interested 3657 in authenticating its counterpart. It is possible to bypass 3658 authentication through the Login request and response. 3660 The initiator and target MAY want to negotiate iSCSI 3661 authentication parameters. Once this negotiation is completed, the 3662 channel is considered secure. 3664 Most of the negotiation keys are only allowed in a specific stage. 3665 The SecurityNegotiation keys appear in Chapter 11 and the 3666 LoginOperationalNegotiation keys appear in Chapter 12. Only a 3667 limited set of keys (marked as Any-Stage in Chapter 12) may be 3668 used in any of the two stages. 3670 Any given Login request or response belongs to a specific stage; 3671 this determines the negotiation keys allowed with the request or 3672 response. It is considered to be a protocol error to send a key 3673 not allowed in the current stage. 3675 Stage transition is performed through a command exchange 3676 (request/response) that carries the T bit and the same CSG code. 3677 During this exchange, the next stage is selected by the target 3678 through the "next stage" code (NSG). The selected NSG MUST NOT 3679 exceed the value stated by the initiator. The initiator can 3680 request a transition whenever it is ready, but a target can only 3681 respond with a transition after one is proposed by the initiator. 3683 In a negotiation sequence, the T bit settings in one pair of login 3684 request-responses have no bearing on the T bit settings of the 3685 next pair. An initiator that has a T bit set to 1 in one pair and 3686 is answered with a T bit setting of 0 may issue the next request 3687 with T bit set to 0. 3689 When a transition is requested by the initiator and acknowledged 3690 by the target, both the initiator and target switch to the 3691 selected stage. 3693 Targets MUST NOT submit parameters that require an additional 3694 initiator login request in a login response with the T bit set to 3695 1. 3697 Stage transitions during login (including entering and exit) are 3698 only possible as outlined in the following table: 3700 +-----------------------------------------------------------+ 3701 |From To -> | Security | Operational | FullFeature | 3702 | | | | | | 3703 | V | | | | 3704 +-----------------------------------------------------------+ 3705 | (start) | yes | yes | no | 3706 +-----------------------------------------------------------+ 3707 | Security | no | yes | yes | 3708 +-----------------------------------------------------------+ 3709 | Operational | no | no | yes | 3710 +-----------------------------------------------------------+ 3712 The Login Final-Response that accepts a Login Request can only 3713 come as a response to a Login request with the T bit set to 1, 3714 and both the request and response MUST indicate FullFeaturePhase 3715 as the next phase via the NSG field. 3717 Neither the initiator nor the target should attempt to declare or 3718 negotiate a parameter more than once during login except for 3719 responses to specific keys that explicitly allow repeated key 3720 declarations (e.g., TargetAddress). An attempt to 3721 renegotiate/redeclare parameters not specifically allowed MUST be 3722 detected by the initiator and target. If such an attempt is 3723 detected by the target, the target MUST respond with Login reject 3724 (initiator error); if detected by the initiator, the initiator 3725 MUST drop the connection. 3727 6.3.1. Login Phase Start 3729 The Login Phase starts with a login request from the initiator to 3730 the target. The initial login request includes: 3732 -Protocol version supported by the initiator. 3734 -iSCSI Initiator Name and iSCSI Target Name 3736 -ISID, TSIH, and connection Ids 3738 -Negotiation stage that the initiator is ready to enter. 3740 A login may create a new session or it may add a connection to an 3741 existing session. Between a given iSCSI Initiator Node (selected 3742 only by an InitiatorName) and a given iSCSI target defined by an 3743 iSCSI TargetName and a Target Portal Group Tag, the login results 3744 are defined by the following table: 3746 +----------------------------------------------------------------+ 3747 |ISID | TSIH | CID | Target action | 3748 +----------------------------------------------------------------+ 3749 |new | non-zero | any | fail the login | 3750 | | | | ("session does not exist") | 3751 +----------------------------------------------------------------+ 3752 |new | zero | any | instantiate a new session | 3753 +----------------------------------------------------------------+ 3754 |existing| zero | any | do session reinstatement | 3755 | | | | (see Section 6.3.5) | 3756 +----------------------------------------------------------------+ 3757 |existing| non-zero | new | add a new connection to | 3758 | | existing | | the session | 3759 +----------------------------------------------------------------+ 3760 |existing| non-zero |existing| do connection reinstatement| 3761 | | existing | | (see Section 7.1.4.3) | 3762 +----------------------------------------------------------------+ 3763 |existing| non-zero | any | fail the login | 3764 | | new | | ("session does not exist") | 3765 +----------------------------------------------------------------+ 3767 Determination of "existing" or "new" are made by the target. 3769 Optionally, the login request may include: 3771 -Security parameters 3772 OR 3774 -iSCSI operational parameters 3775 AND/OR 3777 -The next negotiation stage that the initiator is ready to 3778 enter. 3780 The target can answer the login in the following ways: 3782 -Login Response with Login reject. This is an immediate 3783 rejection from the target that causes the connection to 3784 terminate and the session to terminate if this is the first 3785 (or only) connection of a new session. The T bit and the CSG 3786 and NSG fields are reserved. 3788 -Login Response with Login accept as a final response (T bit 3789 set to 1 and the NSG in both request and response are set to 3790 FullFeaturePhase). The response includes the protocol 3791 version supported by the target and the session ID, and may 3792 include iSCSI operational or security parameters (that 3793 depend on the current stage). 3795 -Login Response with Login Accept as a partial response (NSG 3796 not set to FullFeaturePhase in both request and response) 3798 that indicates the start of a negotiation sequence. The 3799 response includes the protocol version supported by the 3800 target and either security or iSCSI parameters (when no 3801 security mechanism is chosen) supported by the target. 3803 If the initiator decides to forego the SecurityNegotiation stage, 3804 it issues the Login with the CSG set to 3805 LoginOperationalNegotiation and the target may reply with a Login 3806 Response that indicates that it is unwilling to accept the 3807 connection (see Section 10.13 - "Login Response") without 3808 SecurityNegotiation and will terminate the connection with a 3809 response of Authentication failure (see Section 10.13.5 - "Status- 3810 Class and Status-Detail"). 3812 If the initiator is willing to negotiate iSCSI security, but is 3813 unwilling to make the initial parameter proposal and may accept a 3814 connection without iSCSI security, it issues the Login with the T 3815 bit set to 1, the CSG set to SecurityNegotiation, and NSG set to 3816 LoginOperationalNegotiation. If the target is also ready to skip 3817 security, the login response only contains the 3818 TargetPortalGroupTag key (see Section 12.9 - 3819 "TargetPortalGroupTag"), the T bit set to 1, the CSG set to 3820 SecurityNegotiation, and NSG set to LoginOperationalNegotiation. 3822 An initiator that chooses to operate without iSCSI security and 3823 with all the operational parameters taking the default values 3824 issues the Login with the T bit set to 1, the CSG set to 3825 LoginOperationalNegotiation, and NSG set to FullFeaturePhase. If 3826 the target is also ready to forego security and can finish its 3827 LoginOperationalNegotiation, the Login response has T bit set to 3828 1, the CSG set to LoginOperationalNegotiation, and NSG set to 3829 FullFeaturePhase in the next stage. 3831 During the Login Phase the iSCSI target MUST return the 3832 TargetPortalGroupTag key with the first Login Response PDU with 3833 which it is allowed to do so (i.e., the first Login Response 3834 issued after the first Login Request with the C bit set to 0) for 3835 all session types. The TargetPortalGroupTag key value indicates 3836 the iSCSI portal group servicing the Login Request PDU. If the 3837 reconfiguration of iSCSI portal groups is a concern in a given 3838 environment, the iSCSI initiator should use this key to ascertain 3839 that it had indeed initiated the Login Phase with the intended 3840 target portal group. 3842 6.3.2. iSCSI Security Negotiation 3844 The security exchange sets the security mechanism and 3845 authenticates 3846 the initiator user and the target to each other. The exchange 3847 proceeds according to the authentication method chosen in the 3848 negotiation phase and is conducted using the login requests' and 3849 responses' key=value parameters. 3851 An initiator directed negotiation proceeds as follows: 3853 -The initiator sends a login request with an ordered list of 3854 the options it supports (authentication algorithm). The 3855 options are listed in the initiator's order of preference. 3856 The initiator MAY also send private or public extension 3857 options. 3859 -The target MUST reply with the first option in the list it 3860 supports and is allowed to use for the specific initiator 3861 unless it does not support any in which case it MUST answer 3862 with "Reject" (see Text Mode Negotiation). The parameters 3863 are encoded in UTF8 as key=value. For security parameters, 3864 see Chapter 11. 3866 -When the initiator considers that it is ready to conclude the 3867 SecurityNegotiation stage, it sets the T bit to 1 and the 3868 NSG to what it would like the next stage to be. The target 3869 will then set the T bit to 1 and set NSG to the next stage 3870 in the Login response when it finishes sending its security 3871 keys. The next stage selected will be the one the target 3872 selected. If the next stage is FullFeaturePhase, the target 3873 MUST respond with a Login Response with the TSIH value. 3875 If the security negotiation fails at the target, then the target 3876 MUST send the appropriate Login Response PDU. If the security 3877 negotiation fails at the initiator, the initiator SHOULD close the 3878 connection. 3880 It should be noted that the negotiation might also be directed by 3881 the target if the initiator does support security, but is not 3882 ready to direct the negotiation (propose options). 3884 6.3.3. Operational Parameter Negotiation During the Login Phase 3886 Operational parameter negotiation during the login MAY be done: 3888 - Starting with the first Login request if the initiator does 3889 not propose any security/ integrity option. 3891 - Starting immediately after the security negotiation if the 3892 initiator and target perform such a negotiation. 3894 Operational parameter negotiation MAY involve several Login 3895 request-response exchanges started and terminated by the 3896 initiator. The initiator MUST indicate its intent to terminate the 3897 negotiation by setting the T bit to 1; the target sets the T bit 3898 to 1 on the last response. 3900 If the target responds to a Login request that has the T bit set 3901 to 1 with a Login response that has the T bit set to 0, the 3902 initiator should keep sending the Login request (even empty) with 3903 the T bit set to 1, while it still wants to switch stage, until it 3904 receives the Login Response that has the T bit set to 1 or it 3905 receives a key that requires it to set the T bit to 0. 3907 Some session specific parameters can only be specified during the 3908 Login Phase of the first connection of a session (i.e., begun by a 3909 login request that contains a zero-valued TSIH) - the leading 3910 Login Phase (e.g., the maximum number of connections that can be 3911 used for this session). 3913 A session is operational once it has at least one connection in 3914 FullFeaturePhase. New or replacement connections can only be added 3915 to a session after the session is operational. 3917 For operational parameters, see Chapter 12. 3919 6.3.4. Connection Reinstatement 3921 Connection reinstatement is the process of an initiator logging in 3922 with a ISID-TSIH-CID combination that is possibly active from the 3923 target's perspective, which causes the implicit logging out of the 3924 connection corresponding to the CID and reinstating a new Full 3925 Feature Phase iSCSI connection in its place (with the same CID). 3926 Thus, the TSIH in the Login Request PDU MUST be non-zero and CID 3927 does not change during a connection reinstatement. The Login 3928 request performs the logout function of the old connection if an 3929 explicit logout was not performed earlier. In sessions with a 3930 single connection, this may imply the opening of a second 3931 connection with the sole purpose of cleaning up the first. Targets 3932 MUST support opening a second connection even when they do not 3933 support multiple connections in Full Feature Phase if 3934 ErrorRecoveryLevel is 2 and SHOULD support opening a second 3935 connection if ErrorRecoveryLevel is less than 2. 3937 If the operational ErrorRecoveryLevel is 2, connection 3938 reinstatement enables future task reassignment. If the operational 3939 ErrorRecoveryLevel is less than 2, connection reinstatement is the 3940 replacement of the old CID without enabling task reassignment. In 3941 this case, all the tasks that were active on the old CID must be 3942 immediately terminated without further notice to the initiator. 3944 The initiator connection state MUST be CLEANUP_WAIT (section 3945 7.1.3) when the initiator attempts a connection reinstatement. 3947 In practical terms, in addition to the implicit logout of the old 3948 connection, reinstatement is equivalent to a new connection login. 3950 6.3.5. Session Reinstatement, Closure, and Timeout 3952 Session reinstatement is the process of the initiator logging in 3953 with an ISID that is possibly active from the target's 3954 perspective. Thus implicitly logging out the session that 3955 corresponds to the ISID and reinstating a new iSCSI session in its 3956 place (with the same ISID). Therefore, the TSIH in the Login PDU 3957 MUST be zero to signal session reinstatement. Session 3958 reinstatement causes all the tasks that were active on the old 3959 session to be immediately terminated by the target without further 3960 notice to the initiator. 3962 The initiator session state MUST be FAILED (Section 7.3 - "Session 3963 State Diagrams") when the initiator attempts a session 3964 reinstatement. 3966 Session closure is an event defined to be one of the following: 3968 - A successful "session close" logout. 3970 - A successful "connection close" logout for the last Full 3971 Feature Phase connection when no other connection in the 3972 session is waiting for cleanup (Section 7.2 - "Connection 3973 Cleanup State Diagram for Initiators and Targets") and no 3974 tasks in the session are waiting for reassignment. 3976 Session timeout is an event defined to occur when the last 3977 connection state timeout expires and no tasks are waiting for 3978 reassignment. This takes the session to the FREE state (N6 3979 transition in the session state diagram). 3981 6.3.5.1. Loss of Nexus Notification 3983 The iSCSI layer provides the SCSI layer with the "I_T nexus loss" 3984 notification when any one of the following events happens: 3986 Successful completion of session reinstatement. 3987 Session closure event. 3988 Session timeout event. 3990 Certain SCSI object clearing actions may result due to the 3991 notification in the SCSI end nodes, as documented in Appendix F. - 3992 Clearing Effects of Various Events on Targets. 3994 6.3.6. Session Continuation and Failure 3996 Session continuation is the process by which the state of a 3997 preexisting session continues to be used by connection 3998 reinstatement (Section 6.3.4), or by adding a connection with a 3999 new CID. Either of these actions associates the new transport 4000 connection with the session state. 4002 Session failure is an event where the last Full Feature Phase 4003 connection reaches the CLEANUP_WAIT state (Section 8.2), or 4004 completes a successful recovery logout thus causing all active 4005 tasks (that are formerly allegiant to the connection) to start 4006 waiting for task reassignment. 4008 6.4. Operational Parameter Negotiation Outside the Login Phase 4010 Some operational parameters MAY be negotiated outside (after) the 4011 Login Phase. 4013 Parameter negotiation in Full Feature Phase is done through Text 4014 requests and responses. Operational parameter negotiation MAY 4015 involve several Text request-response exchanges, which the 4016 initiator always starts, terminates, and uses the same Initiator 4017 Task Tag. The initiator MUST indicate its intent to terminate the 4018 negotiation by setting the F bit to 1; the target sets the F bit 4019 to 1 on the last response. 4021 If the target responds to a Text request with the F bit set to 1 4022 with a Text response with the F bit set to 0 , the initiator 4023 should keep sending the Text request (even empty) with the F bit 4024 set to 1, while it still wants to finish the negotiation, until it 4025 receives the Text response with the F bit set to 1. Responding to 4026 a Text request with the F bit set to 1 with an empty (no key=value 4027 pairs) response with the F bit set to 0 is discouraged. 4029 Targets MUST NOT submit parameters that require an additional 4030 initiator Text request in a Text response with the F bit set to 1. 4032 In a negotiation sequence, the F bit settings in one pair of Text 4033 request-responses have no bearing on the F bit settings of the 4034 next pair. An initiator that has the F bit set to 1 in a request 4035 and is being answered with an F bit setting of 0 may issue the 4036 next request with the F bit set to 0. 4038 Whenever the target responds with the F bit set to 0, it MUST set 4039 the Target Transfer Tag to a value other than the default 4040 0xffffffff. 4042 An initiator MAY reset an operational parameter negotiation by 4043 issuing a Text request with the Target Transfer Tag set to the 4044 value 0xffffffff after receiving a response with the Target 4045 Transfer Tag set to a value other than 0xffffffff. A target may 4046 reset an operational parameter negotiation by answering a Text 4047 request with a Reject PDU. 4049 Neither the initiator nor the target should attempt to declare or 4050 negotiate a parameter more than once during any negotiation 4051 sequence, except for responses to specific keys that explicitly 4052 allow repeated key declarations (e.g., TargetAddress). If detected 4053 by the target, this MUST result in a Reject PDU with a reason of 4054 "protocol error". The initiator MUST reset the negotiation as 4055 outlined above. 4057 Parameters negotiated by a text exchange negotiation sequence only 4058 become effective after the negotiation sequence is completed. 4060 7. iSCSI Error Handling and Recovery 4062 7.1. Overview 4064 7.1.1. Background 4066 The following two considerations prompted the design of much of 4067 the error recovery functionality in iSCSI: 4069 An iSCSI PDU may fail the digest check and be dropped, despite 4070 being received by the TCP layer. The iSCSI layer must 4071 optionally be allowed to recover such dropped PDUs. 4073 A TCP connection may fail at any time during the data 4074 transfer. All the active tasks must optionally be allowed 4075 to be continued on a different TCP connection within the 4076 same session. 4078 Implementations have considerable flexibility in deciding what 4079 degree of error recovery to support, when to use it and by which 4080 mechanisms to achieve the required behavior. Only the externally 4081 visible actions of the error recovery mechanisms must be 4082 standardized to ensure interoperability. 4084 This chapter describes a general model for recovery in support of 4085 interoperability. See Appendix E. - "Algorithmic Presentation of 4086 Error Recovery Classes" for further detail on how the described 4087 model may be implemented. Compliant implementations do not have to 4088 match the implementation details of this model as presented, but 4089 the external behavior of such implementations must correspond to 4090 the externally observable characteristics of the presented model. 4092 7.1.2. Goals 4094 The major design goals of the iSCSI error recovery scheme are as 4095 follows: 4097 Allow iSCSI implementations to meet different requirements 4098 by defining a collection of error recovery mechanisms that 4099 implementations may choose from. 4100 Ensure interoperability between any two implementations 4101 supporting different sets of error recovery capabilities. 4103 Define the error recovery mechanisms to ensure command 4104 ordering even in the face of errors, for initiators that 4105 demand ordering. 4106 Do not make additions in the fast path, but allow moderate 4107 complexity in the error recovery path. 4108 Prevent both the initiator and target from attempting to 4109 recover the same set of PDUs at the same time. For example, 4110 there must be a clear "error recovery functionality 4111 distribution" between the initiator and target. 4113 7.1.3. Protocol Features and State Expectations 4115 The initiator mechanisms defined in connection with error recovery 4116 are: 4118 NOP-OUT to probe sequence numbers of the target (Section 4119 10.18) 4120 Command retry (Section 7.2.1) 4121 Recovery R2T support (Section 7.8) 4122 Requesting retransmission of status/data/R2T using the SNACK 4123 facility (section 10.16) 4124 Acknowledging the receipt of the data (section 10.16) 4125 Reassigning the connection allegiance of a task to a 4126 different TCP connection (Section 7.2.2) 4127 Terminating the entire iSCSI session to start afresh (Session 4128 Recovery) 4130 The target mechanisms defined in connection with error recovery 4131 are: 4133 NOP-IN to probe sequence numbers of the initiator (section 4134 10.19) 4135 Requesting retransmission of data using the recovery R2T 4136 feature (iSCSI Erro) 4137 SNACK support (section 10.16) 4138 Requesting that parts of read data be acknowledged (section 4139 10.7.2) 4140 Allegiance reassignment support (Section 7.2.2) 4141 Terminating the entire iSCSI session to force the initiator 4142 to start over (Session Recovery) 4144 For any outstanding SCSI command, it is assumed that iSCSI, in 4145 conjunction with SCSI at the initiator, is able to keep enough 4146 information to be able to rebuild the command PDU, and that 4147 outgoing data is available (in host memory) for retransmission 4148 while the command is outstanding. It is also assumed that at the 4149 target, incoming data (read data) MAY be kept for recovery or it 4150 can be reread from a device server. 4152 It is further assumed that a target will keep the "status & sense" 4153 for a command it has executed if it supports status 4154 retransmission. 4155 A target that agrees to support data retransmission is expected to 4156 be prepared to retransmit the outgoing data (i.e., Data-In) on 4157 request until either the status for the completed command is 4158 acknowledged, or the data in question has been separately 4159 acknowledged. 4161 7.1.4. Recovery Classes 4163 iSCSI enables the following classes of recovery (in the order of 4164 increasing scope of affected iSCSI tasks): 4166 - Within a command (i.e., without requiring command restart). 4168 - Within a connection (i.e., without requiring the connection 4169 to be rebuilt, but perhaps requiring command restart). 4171 - Connection recovery (i.e., perhaps requiring connections to 4172 be rebuilt and commands to be reissued). 4174 - Session recovery. 4176 The recovery scenarios detailed in the rest of this section are 4177 representative rather than exclusive. In every case, they detail 4178 the lowest class recovery that MAY be attempted. The implementer 4179 is left to decide under which circumstances to escalate to the 4180 next recovery class and/or what recovery classes to implement. 4181 Both the iSCSI target and initiator MAY escalate the error 4182 handling to an error recovery class, which impacts a larger number 4183 of iSCSI tasks in any of the cases identified in the following 4184 discussion. 4186 In all classes, the implementer has the choice of deferring errors 4187 to the SCSI initiator (with an appropriate response code), in 4188 which case the task, if any, has to be removed from the target and 4189 all the side-effects, such as ACA, must be considered. 4191 Use of within-connection and within-command recovery classes MUST 4192 NOT be attempted before the connection is in Full Feature Phase. 4194 In the detailed description of the recover classes the 4195 mandating terms (MUST, SHOULD, MAY, etc.) indicate normative 4196 actions to be executed if the recovery class is supported and 4197 used. 4199 7.1.4.1. Recovery Within-command 4201 At the target, the following cases lend themselves to within- 4202 command recovery: 4204 - Lost data PDU - realized through one of the following: 4206 Data digest error - dealt with as specified in Section 7.8, 4207 using the option of a recovery R2T. 4208 Sequence reception timeout (no data or partial-data-and-no-F- 4209 bit) - considered an implicit sequence error and dealt with 4210 as specified in Section 7.9, using the option of a recovery 4211 R2T. 4212 Header digest error, which manifests as a sequence reception 4213 timeout or a sequence error - dealt with as specified in 4214 Section 7.9, using the option of a recovery R2T. 4216 At the initiator, the following cases lend themselves to within- 4217 command recovery: 4219 Lost data PDU or lost R2T - realized through one of the 4220 following: 4222 Data digest error - dealt with as specified in Section 7.8, 4223 using the option of a SNACK. 4225 Sequence reception timeout (no status) or response reception 4226 timeout - dealt with as specified in Section 7.9, using the 4227 option of a SNACK. 4228 Header digest error, which manifests as a sequence reception 4229 timeout or a sequence error - dealt with as specified in 4230 Section 7.9, using the option of a SNACK. 4232 To avoid a race with the target, which may already have a recovery 4233 R2T or a termination response on its way, an initiator SHOULD NOT 4234 originate a SNACK for an R2T based on its internal timeouts (if 4235 any). Recovery in this case is better left to the target. 4237 The timeout values used by the initiator and target are outside 4238 the scope of this document. Sequence reception timeout is 4239 generally a large enough value to allow the data sequence transfer 4240 to be complete. 4242 7.1.4.2. Recovery Within-connection 4244 At the initiator, the following cases lend themselves to within- 4245 connection recovery: 4247 - Requests not acknowledged for a long time. Requests are 4248 acknowledged explicitly through ExpCmdSN or implicitly by 4249 receiving data and/or status. The initiator MAY retry non- 4250 acknowledged commands as specified in Retry an. 4252 - Lost iSCSI numbered Response. It is recognized by either 4253 identifying a data digest error on a Response PDU or a Data- 4254 In PDU carrying the status, or by receiving a Response PDU 4255 with a higher StatSN than expected. In the first case, 4256 digest error handling is done as specified in Section 7.8 4257 using the option of a SNACK. In the second case, sequence 4258 error handling is done as specified in Section 7.9, using 4259 the option of a SNACK. 4261 At the target, the following cases lend themselves to within- 4262 connection recovery: 4264 - Status/Response not acknowledged for a long time. The target 4265 MAY issue a NOP-IN (with a valid Target Transfer Tag or 4266 otherwise) that carries the next status sequence number it 4267 is going to use in the StatSN field. This helps the 4268 initiator detect any missing StatSN(s) and issue a SNACK for 4269 the status. 4271 The timeout values used by the initiator and the target are 4272 outside the scope of this document. 4274 7.1.4.3. Connection Recovery 4276 At an iSCSI initiator, the following cases lend themselves to 4277 connection recovery: 4279 - TCP connection failure: The initiator MUST close the 4280 connection. It then MUST either implicitly or explicitly 4281 logout the failed connection with the reason code "remove 4282 the connection for recovery" and reassign connection 4283 allegiance for all commands still in progress associated 4284 with the failed connection on one or more connections (some 4285 or all of which MAY be newly established connections) using 4286 the "Task reassign" task management function (see Section 4287 10.5.1 - "Function"). For an initiator, a command is in 4288 progress as long as it has not received a response or a 4289 Data-In PDU including status. 4291 Note: The logout function is mandatory. However, a new 4292 connection establishment is only mandatory if the failed 4293 connection was the last or only connection in the session. 4295 - Receiving an Asynchronous Message that indicates one or all 4296 connections in a session has been dropped. The initiator 4297 MUST handle it as a TCP connection failure for the 4298 connection(s) referred to in the Message. 4300 At an iSCSI target, the following cases lend themselves to 4301 connection recovery: 4303 - TCP connection failure. The target MUST close the connection 4304 and, if more than one connection is available, the target 4305 SHOULD send an Asynchronous Message that indicates it has 4306 dropped the connection. Then, the target will wait for the 4307 initiator to continue recovery. 4309 7.1.4.4. Session Recovery 4311 Session recovery should be performed when all other recovery 4312 attempts have failed. Very simple initiators and targets MAY 4313 perform session recovery on all iSCSI errors and rely on recovery 4314 on the SCSI layer and above. 4316 Session recovery implies the closing of all TCP connections, 4317 internally aborting all executing and queued tasks for the given 4318 initiator at the target, terminating all outstanding SCSI commands 4319 with an appropriate SCSI service response at the initiator, and 4320 restarting a session on a new set of connection(s) (TCP connection 4321 establishment and login on all new connections). 4323 For possible clearing effects of session recovery on SCSI and 4324 iSCSI objects, refer to Appendix F. - "Clearing Effects of Various 4325 Events on Targets". 4327 7.1.5. Error Recovery Hierarchy 4329 The error recovery classes described so far are organized into a 4330 hierarchy for ease in understanding and to limit the 4331 implementation complexity. With few and well defined recovery 4332 levels interoperability is easier to achieve. The attributes of 4333 this hierarchy are as follows: 4335 Each level is a superset of the capabilities of the previous 4336 level. For example, Level 1 support implies supporting all 4337 capabilities of Level 0 and more. 4339 As a corollary, supporting a higher error recovery level means 4340 increased sophistication and possibly an increase in 4341 resource requirements. 4342 Supporting error recovery level "n" is advertised and 4343 negotiated by each iSCSI entity by exchanging the text key 4344 "ErrorRecoveryLevel=n". The lower of the two exchanged 4345 values is the operational ErrorRecoveryLevel for the 4346 session. 4348 The following diagram represents the error recovery hierarchy. 4350 + 4351 / \ 4352 / 2 \ <-- Connection recovery 4353 +-----+ 4354 / 1 \ <-- Digest failure recovery 4355 +---------+ 4356 / 0 \ <-- Session failure recovery 4357 +-------------+ 4359 The following table lists the error recovery capabilities expected 4360 from the implementations that support each error recovery level. 4362 +-------------------+--------------------------------------------+ 4363 |ErrorRecoveryLevel | Associated Error recovery capabilities | 4364 +-------------------+--------------------------------------------+ 4365 | 0 | Session recovery class | 4366 | | (Session Recovery) | 4367 +-------------------+--------------------------------------------+ 4368 | 1 | Digest failure recovery (See Note below.) | 4369 | | plus the capabilities of ER Level 0 | 4370 +-------------------+--------------------------------------------+ 4371 | 2 | Connection recovery class | 4372 | | (Connection Recovery) | 4373 | | plus the capabilities of ER Level 1 | 4374 +-------------------+--------------------------------------------+ 4376 Note: Digest failure recovery is comprised of two recovery 4377 classes: Within-Connection recovery class (Recovery Within- 4378 connection) and Within-Command recovery class (Recovery Within- 4379 command ). 4381 When a defined value of ErrorRecoveryLevel is proposed by an 4382 originator in a text negotiation, the originator MUST support the 4383 functionality defined for the proposed value and additionally, 4384 functionality corresponding to any defined value numerically less 4385 than the proposed. When a defined value of ErrorRecoveryLevel is 4386 returned by a responder in a text negotiation, the responder MUST 4387 support the functionality corresponding to the ErrorRecoveryLevel 4388 it is accepting. 4390 When either party attempts to use error recovery functionality 4391 beyond what is negotiated, the recovery attempts MAY fail unless 4392 an apriori agreement outside the scope of this document exists 4393 between the two parties to provide such support. 4395 Implementations MUST support error recovery level "0", while the 4396 rest are OPTIONAL to implement. In implementation terms, the 4397 above striation means that the following incremental 4398 sophistication with each level is required. 4400 +-------------------+--------------------------------------------- 4401 + 4402 |Level transition | Incremental requirement 4403 | 4404 +-------------------+--------------------------------------------- 4405 + 4406 | 0->1 | PDU retransmissions on the same connection 4407 | 4408 +-------------------+--------------------------------------------- 4409 + 4410 | 1->2 | Retransmission across connections and 4411 | 4412 | | allegiance reassignment 4413 | 4414 +-------------------+--------------------------------------------- 4415 + 4417 7.2. Retry and Reassign in Recovery 4419 This section summarizes two important and somewhat related iSCSI 4420 protocol features used in error recovery. 4422 7.2.1. Usage of Retry 4424 By resending the same iSCSI command PDU ("retry") in the absence 4425 of a command acknowledgement (by way of an ExpCmdSN update) or a 4426 response, an initiator attempts to "plug" (what it thinks are) the 4427 discontinuities in CmdSN ordering on the target end. Discarded 4428 command PDUs, due to digest errors, may have created these 4429 discontinuities. 4431 Retry MUST NOT be used for reasons other than plugging command 4432 sequence gaps, and in particular, cannot be used for requesting 4433 PDU retransmissions from a target. Any such PDU retransmission 4434 requests for a currently allegiant command in progress may be made 4435 using the SNACK mechanism described in section 10.16, although the 4436 usage of SNACK is OPTIONAL. 4438 If initiators, as part of plugging command sequence gaps as 4439 described above, inadvertently issue retries for allegiant 4440 commands already in progress (i.e., targets did not see the 4441 discontinuities in CmdSN ordering), the duplicate commands are 4442 silently ignored by targets as specified in section 3.2.2.1. 4444 When an iSCSI command is retried, the command PDU MUST carry the 4445 original Initiator Task Tag and the original operational 4446 attributes (e.g., flags, function names, LUN, CDB etc.) as well as 4447 the original CmdSN. The command being retried MUST be sent on the 4448 same connection as the original command unless the original 4449 connection was already successfully logged out. 4451 7.2.2. Allegiance Reassignment 4453 By issuing a "task reassign" task management request (Section 4454 10.5.1 - "Function"), the initiator signals its intent to continue 4455 an already active command (but with no current connection 4456 allegiance) as part of connection recovery. This means that a new 4457 connection allegiance is requested for the command, which seeks to 4458 associate it to the connection on which the task management 4459 request is being issued. Before the allegiance reassignment is 4460 attempted for a task, an implicit or explicit Logout with the 4461 reason code "remove the connection for recovery" ( see section 4462 10.14) MUST be successfully completed for the previous connection 4463 to which the task was allegiant. 4465 In reassigning connection allegiance for a command, the targets 4466 SHOULD continue the command from its current state. For example, 4467 when reassigning read commands, the target SHOULD take advantage 4468 of the ExpDataSN field provided by the Task Management function 4469 request (which must be set to zero if there was no data transfer) 4470 and bring the read command to completion by sending the remaining 4471 data and sending (or resending) the status. ExpDataSN 4472 acknowledges all data sent up to, but not including, the Data-In 4473 PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However, 4474 targets may choose to send/receive all unacknowledged data or all 4475 of the data on a reassignment of connection allegiance if unable 4476 to recover or maintain accurate an state. Initiators MUST NOT 4477 subsequently request data retransmission through Data SNACK for 4478 PDUs numbered less than ExpDataSN (i.e., prior to the acknowledged 4479 sequence number). For all types of commands, a reassignment 4480 request implies that the task is still considered in progress by 4481 the initiator and the target must conclude the task appropriately 4482 if the target returns the "Function Complete" response to the 4483 reassignment request. This might possibly involve retransmission 4484 of data/R2T/status PDUs as necessary, but MUST involve the 4485 (re)transmission of the status PDU. 4487 It is OPTIONAL for targets to support the allegiance reassignment. 4488 This capability is negotiated via the ErrorRecoveryLevel text key 4489 during the login time. When a target does not support allegiance 4490 reassignment, it MUST respond with a Task Management response code 4491 of "Allegiance reassignment not supported". If allegiance 4492 reassignment is supported by the target, but the task is still 4493 allegiant to a different connection, or a successful recovery 4494 Logout of the previously allegiant connection was not performed, 4495 the target MUST respond with a Task Management response code of 4496 "Task still allegiant". 4498 If allegiance reassignment is supported by the target, the Task 4499 Management response to the reassignment request MUST be issued 4500 before the reassignment becomes effective. 4502 If a SCSI Command that involves data input is reassigned, any 4503 SNACK Tag it holds for a final response from the original 4504 connection is deleted and the default value of 0 MUST be used 4505 instead. 4507 7.3. Usage Of Reject PDU in Recovery 4509 Targets MUST NOT implicitly terminate an active task by sending a 4510 Reject PDU for any PDU exchanged during the life of the task. If 4511 the target decides to terminate the task, a Response PDU (SCSI, 4512 Text, Task, etc.) must be returned by the target to conclude the 4513 task. If the task had never been active before the Reject (i.e., 4514 the Reject is on the command PDU), targets should not send any 4515 further responses because the command itself is being discarded. 4517 The above rule means that the initiator can eventually expect a 4518 response on receiving Rejects, if the received Reject is for a PDU 4519 other than the command PDU itself. The non-command Rejects only 4520 have diagnostic value in logging the errors, and they can be used 4521 for retransmission decisions by the initiators. 4523 The CmdSN of the rejected command PDU (if it is a non-immediate 4524 command) MUST NOT be considered received by the target (i.e., a 4525 command sequence gap must be assumed for the CmdSN), even though 4526 the CmdSN of the rejected command PDU may be reliably ascertained. 4527 Upon receiving the Reject, the initiator MUST plug the CmdSN gap 4528 in order to continue to use the session. The gap may be plugged 4529 either by transmitting a command PDU with the same CmdSN, or by 4530 aborting the task (see SCS on how an abort may plug a CmdSN gap). 4532 When a data PDU is rejected and its DataSN can be ascertained, a 4533 target MUST advance ExpDataSN for the current data burst if a 4534 recovery R2T is being generated. The target MAY advance its 4535 ExpDataSN if it does not attempt to recover the lost data PDU. 4537 7.4. Error Recovery Considerations for Discovery Sessions 4539 7.4.1. ErrorRecoveryLevel for Discovery Sessions 4541 The negotiation of the key ErrorRecoveryLevel is not required for 4542 Discovery sessions -- i.e., for sessions that negotiated 4543 "SessionType=Discovery" -- because the default value of 0 is 4544 necessary and sufficient for Discovery sessions. It is however 4545 possible that some legacy iSCSI implementations might attempt to 4546 negotiate the ErrorRecoveryLevel key on Discovery sessions. When 4547 such a negotiation attempt is made by the remote side, a compliant 4548 iSCSI implementation MUST propose a value of 0 (zero) in response. 4549 The operational ErrorRecoveryLevel for Discovery sessions thus 4550 MUST 4551 be 0. This naturally follows from the functionality constraints 4552 that Section 4.3 imposes on Discovery sessions. 4554 7.4.2. Reinstatement Semantics for Discovery Sessions 4556 Discovery sessions are intended to be relatively short-lived. 4557 Initiators are not expected to establish multiple Discovery 4558 sessions to the same iSCSI Network Portal. An initiator may use 4559 the same iSCSI Initiator Name and ISID when establishing different 4560 unique sessions with different targets and/or different portal 4561 groups. This behavior is discussed in Section 10.1.1 and is, in 4562 fact, encouraged as conservative reuse of ISIDs. 4564 The ISID RULE in Section 4.4.3 states that there must not be more 4565 than one session with a matching 4-tuple: . While the spirit of the ISID 4567 RULE applies to Discovery sessions the same as it does for Normal 4568 sessions, note that some Discovery sessions differ from the Normal 4569 sessions in two important aspects: 4571 Because Appendix D allows a Discovery session to be 4572 established without specifying a TargetName key in the Login 4573 Request PDU (let us call such a session an "Unnamed" 4574 Discovery session), there is no Target Node context to 4575 enforce the ISID RULE. 4577 Portal Groups are defined only in the context of a Target 4578 Node. When the TargetName key is NULL-valued (i.e., not 4579 specified), the TargetPortalGroupTag thus cannot be 4580 ascertained to enforce the ISID RULE. 4582 The following two sections describe each of the two scenarios -- 4583 Named Discovery sessions and Unnamed Discovery sessions. 4585 7.4.2.1. Unnamed Discovery Sessions 4587 For Unnamed Discovery sessions, neither the TargetName nor the 4588 TargetPortalGroupTag is available to the targets in order to 4589 enforce the ISID RULE. So the following rule applies. 4591 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 4592 following 4-tuple for Unnamed Discovery sessions: . The following semantics are implied by 4594 this uniqueness requirement. 4596 Targets SHOULD allow concurrent establishment of one Discovery 4597 session with each of its Network Portals by the same initiator 4598 port with a given iSCSI Node Name and an ISID. Each of the 4599 concurrent Discovery sessions, if established by the same 4600 initiator port to other Network Portals, MUST be treated as 4601 independent sessions -- i.e., one session MUST NOT reinstate the 4602 other. 4604 A new Unnamed Discovery session that has a matching 4605 to an existing 4606 Discovery session MUST reinstate the existing Unnamed Discovery 4607 session. Note thus that only an Unnamed Discovery session may 4608 reinstate an Unnamed Discovery session. 4610 7.4.2.2. Named Discovery Session 4612 For a Named Discovery session, the TargetName key is specified by 4613 the initiator and thus the target can unambiguously ascertain the 4614 TargetPortalGroupTag as well. Since all the four elements of the 4615 4-tuple are known, the ISID RULE MUST be enforced by targets with 4616 no changes from Section 4.4.3 semantics. A new session with a 4617 matching 4618 thus will reinstate an existing session. Note in this case that 4619 any new iSCSI session (Discovery or Normal) with the matching 4- 4620 tuple may reinstate an existing Named Discovery iSCSI session. 4622 7.4.3. Target PDUs During Discovery 4624 Targets SHOULD NOT send any responses other than a Text Response 4625 and Logout Response on a Discovery session, once in Full Feature 4626 Phase. 4628 Implementation Note: A target may simply drop the connection in a 4629 Discovery session when it would have requested a Logout via an 4630 Async Message on Normal sessions. 4632 7.5. Connection Timeout Management 4634 iSCSI defines two session-global timeout values (in seconds) - 4635 Time2Wait and Time2Retain - that are applicable when an iSCSI Full 4636 Feature Phase connection is taken out of service either 4637 intentionally or by an exception. Time2Wait is the initial 4638 "respite time" before attempting an explicit/implicit Logout for 4639 the CID in question or task reassignment for the affected tasks 4640 (if any). Time2Retain is the maximum time after the initial 4641 respite interval that the task and/or connection state(s) is/are 4642 guaranteed to be maintained on the target to cater to a possible 4643 recovery attempt. Recovery attempts for the connection and/or 4644 task(s) SHOULD NOT be made before Time2Wait seconds, but MUST be 4645 completed within Time2Retain seconds after that initial Time2Wait 4646 waiting period. 4648 7.5.1. Timeouts on Transport Exception Events 4650 A transport connection shutdown or a transport reset without any 4651 preceding iSCSI protocol interactions informing the end-points of 4652 the fact causes a Full Feature Phase iSCSI connection to be 4653 abruptly terminated. The timeout values to be used in this case 4654 are the negotiated values of defaultTime2Wait (Section 12.15 - 4655 "DefaultTime2Wait") and DefaultTime2Retain (Section 12.16 - 4656 "DefaultTime2Retain") text keys for the session. 4658 7.5.2. Timeouts on Planned Decommissioning 4660 Any planned decommissioning of a Full Feature Phase iSCSI 4661 connection is preceded by either a Logout Response PDU, or an 4662 Async Message PDU. The Time2Wait and Time2Retain field values 4663 (section 10.15) in a Logout Response PDU, and the Parameter2 and 4664 Parameter3 fields of an Async Message (AsyncEvent types "drop the 4665 connection" or "drop all the connections"; section 10.9.1) specify 4666 the timeout values to be used in each of these cases. 4668 These timeout values are only applicable for the affected 4669 connection, and the tasks active on that connection. These 4670 timeout values have no bearing on initiator timers (if any) that 4671 are already running on connections or tasks associated with that 4672 session. 4674 7.6. Implicit Termination of Tasks 4676 A target implicitly terminates the active tasks due to iSCSI 4677 protocol dynamics in the following cases: 4679 When a connection is implicitly or explicitly logged out with 4680 the reason code of "Close the connection" and there are 4681 active tasks allegiant to that connection. 4683 When a connection fails and eventually the connection state 4684 times out (state transition M1 in Section 7.2.2 - "State 4685 Transition Descriptions for Initiators and Targets") and 4686 there are active tasks allegiant to that connection. 4688 When a successful Logout with the reason code of "remove the 4689 connection for recovery" is performed while there are 4690 active tasks allegiant to that connection, and those tasks 4691 eventually time out after the Time2Wait and Time2Retain 4692 periods without allegiance reassignment. 4694 When a connection is implicitly or explicitly logged out with 4695 the reason code of "Close the session" and there are active 4696 tasks in that session. 4698 If the tasks terminated in the above cases a), b, c) and d)are 4699 SCSI tasks, they must be internally terminated as if with CHECK 4700 CONDITION status. This status is only meaningful for appropriately 4701 handling the internal SCSI state and SCSI side effects with 4702 respect to ordering because this status is never communicated back 4703 as a terminating status to the initiator. However additional 4704 actions may have to be taken at SCSI level depending on the SCSI 4705 context as defined by the SCSI standards (e.g., queued commands 4706 and ACA, UA for the next command on the I_T nexus in cases a), b), 4707 and c) etc. - see [SAM2] and [SPC3]). 4709 7.7. Format Errors 4711 The following two explicit violations of PDU layout rules are 4712 format errors: 4714 Illegal contents of any PDU header field except the Opcode 4715 (legal values are specified in Section 10 - "iSCSI PDU 4716 Formats"). 4717 Inconsistent field contents (consistent field contents are 4718 specified in Section 10 - "iSCSI PDU Formats"). 4720 Format errors indicate a major implementation flaw in one of the 4721 parties. 4723 When a target or an initiator receives an iSCSI PDU with a format 4724 error, it MUST immediately terminate all transport connections in 4725 the session either with a connection close or with a connection 4726 reset and escalate the format error to session recovery (see 4727 Section Session Recovery). 4729 All initiator-detected PDU construction errors MUST be considered 4730 as format errors. Some examples of such errors are: 4731 - NOP-In with a valid TTT but an invalid LUN 4733 - NOP-In with a valid ITT (i.e., a NOP-In response) and also a 4734 valid TTT 4736 - SCSI Response PDU with Status=CHECK CONDITION, but 4737 DataSegmentLength = 0 4739 7.8. Digest Errors 4741 The discussion of the legal choices in handling digest errors 4742 below excludes session recovery as an explicit option, but either 4743 party detecting a digest error may choose to escalate the error to 4744 session recovery. 4746 When a target or an initiator receives any iSCSI PDU, with a 4747 header digest error, it MUST either discard the header and all 4748 data up to the beginning of a later PDU or close the connection. 4749 Because the digest error indicates that the length field of the 4751 header may have been corrupted, the location of the beginning of a 4752 later PDU needs to be reliably ascertained by other means such as 4753 the operation of a sync and steering layer. 4755 When a target receives any iSCSI PDU with a payload digest error, 4756 it MUST answer with a Reject PDU with a reason code of Data- 4757 Digest-Error and discard the PDU. 4759 - If the discarded PDU is a solicited or unsolicited iSCSI 4760 data PDU (for immediate data in a command PDU, non-data PDU 4761 rule below applies), the target MUST do one of the 4762 following: 4764 i) Request retransmission with a recovery R2T. 4765 ii) Terminate the task with a response PDU with a CHECK 4766 CONDITION Status and an iSCSI Condition of "protocol 4767 service CRC error" (Section 10.4.7.2 - "Sense Data"). 4768 If the target chooses to implement this option, it MUST 4769 wait to receive all the data (signaled by a Data PDU 4770 with the final bit set for all outstanding R2Ts) before 4771 sending the response PDU. A task management command 4772 (such as an abort task) from the initiator during this 4773 wait may also conclude the task. 4774 - No further action is necessary for targets if the discarded 4775 PDU is a non-data PDU. In case of immediate data being 4776 present on a discarded command, the immediate data is 4777 implicitly recovered when the task is retried (see Section 4778 7.2.1) followed by the entire data transfer for the task. 4780 When an initiator receives any iSCSI PDU with a payload digest 4781 error, it MUST discard the PDU. 4783 - If the discarded PDU is an iSCSI data PDU, the initiator 4784 MUST do one of the following: 4786 Request the desired data PDU through SNACK. In response to 4787 the SNACK, the target MUST either resend the data 4788 PDU or reject the SNACK with a Reject PDU with a 4789 reason code of "SNACK reject" in which case: 4791 If the status has not already been sent for the command, 4792 the target MUST terminate the command with a 4793 CHECK CONDITION Status and an iSCSI Condition of 4794 "SNACK rejected" (Section 10.4.7.2 - "Sense 4795 Data"). 4796 If the status was already sent, no further action is 4797 necessary for the target. The initiator in this 4798 case MUST wait for the status to be received and 4799 then discard it, so as to internally signal the 4800 completion with CHECK CONDITION Status and an 4801 iSCSI Condition of "protocol service CRC error" 4802 (Section 10.4.7.2 - "Sense Data"). 4803 Abort the task and terminate the command with an error. 4805 - If the discarded PDU is a response PDU or an unsolicited PDU 4806 (e.g. Async, Reject), the initiator MUST do one of the 4807 following: 4809 Request PDU retransmission with a status SNACK. 4810 Logout the connection for recovery and continue the tasks 4811 on a different connection instance as described 4812 in Retry an. 4813 Logout to close the connection (abort all the commands 4814 associated with the connection). 4816 Note that an unsolicited PDU carries the next StatSN value on 4817 an iSCSI connection, thereby advancing the StatSN. When an 4818 initiator discards one of these PDUs due to a payload digest 4819 error, the entire PDU including the header MUST be discarded. 4820 Consequently, the initiator MUST treat the exception like a 4821 loss of any other solicited response PDU. 4823 7.9. Sequence Errors 4825 When an initiator receives an iSCSI R2T/data PDU with an out of 4826 order R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that 4827 implies missing data PDU(s), it means that the initiator must have 4828 detected a header or payload digest error on one or more earlier 4829 R2T/data PDUs. The initiator MUST address these implied digest 4830 errors as described in Section 7.8. When a target receives a data 4831 PDU with an out of order DataSN, it means that the target must 4832 have hit a header or payload digest error on at least one of the 4833 earlier data PDUs. The target MUST address these implied digest 4834 errors as described in Section 7.8. 4836 When an initiator receives an iSCSI status PDU with an out of 4837 order StatSN that implies missing responses, it MUST address the 4838 one or more missing status PDUs as described in Section 7.8. As a 4839 side effect of receiving the missing responses, the initiator may 4840 discover missing data PDUs. If the initiator wants to recover the 4841 missing data for a command, it MUST NOT acknowledge the received 4842 responses that start from the StatSN of the relevant command, 4843 until it has completed receiving all the data PDUs of the command. 4845 When an initiator receives duplicate R2TSNs (due to proactive 4846 retransmission of R2Ts by the target) or duplicate DataSNs (due to 4847 proactive SNACKs by the initiator), it MUST discard the 4848 duplicates. 4850 7.10. Message Error Checking 4852 In the iSCSI implementations till date, there has been some 4853 uncertainty on the extent to which incoming messages have to be 4854 checked for protocol errors, beyond what is strictly required for 4855 processing the inbound message. This section addresses this 4856 question. 4858 Unless this document requires it, an iSCSI implementation is not 4859 required to do an exhaustive protocol conformance check on an 4860 incoming iSCSI PDU. The iSCSI implementation especially is not 4861 required to double-check the remote iSCSI implementation's 4862 conformance to protocol requirements. 4864 7.11. SCSI Timeouts 4866 An iSCSI initiator MAY attempt to plug a command sequence gap on 4867 the target end (in the absence of an acknowledgement of the 4868 command by way of ExpCmdSN) before the ULP timeout by retrying the 4869 unacknowledged command, as described in Section 7.2. 4871 On a ULP timeout for a command (that carried a CmdSN of n), if the 4872 iSCSI initiator intends to continue the session it MUST abort the 4873 command by either using an appropriate Task Management function 4875 request for the specific command, or a "close the connection" 4876 Logout. When using an ABORT TASK, if the ExpCmdSN is still less 4877 than (n+1), the target may see the abort request while missing the 4878 original command itself due to one of the following reasons: 4880 - Original command was dropped due to digest error. 4882 - Connection on which the original command was sent was 4883 successfully logged out. On logout, the unacknowledged 4884 commands issued on the connection being logged out are 4885 discarded. 4887 If the abort request is received and the original command is 4888 missing, targets MUST consider the original command with that 4889 RefCmdSN to be received and issue a Task Management response with 4890 the response code: "Function Complete". This response concludes 4891 the task on both ends. If the abort request is received and the 4892 target can determine (based on the Referenced Task Tag) that the 4893 command was received and executed and also that the response was 4894 sent prior to the abort, then the target MUST respond with the 4895 response code of "Task Does Not Exist". 4897 7.12. Negotiation Failures 4899 Text request and response sequences, when used to set/negotiate 4900 operational parameters, constitute the negotiation/parameter 4901 setting. A negotiation failure is considered to be one or more of 4902 the following: 4904 - None of the choices, or the stated value, is acceptable to 4905 one of the sides in the negotiation. 4907 - The text request timed out and possibly terminated. 4909 - The text request was answered with a Reject PDU. 4911 The following two rules should be used to address negotiation 4912 failures: 4914 - During Login, any failure in negotiation MUST be considered 4915 a login process failure and the Login Phase must be 4916 terminated, and with it, the connection. If the target 4917 detects the failure, it must terminate the login with the 4918 appropriate login response code. 4920 - A failure in negotiation, while in the Full Feature Phase, 4921 will terminate the entire negotiation sequence that may 4922 consist of a series of text requests that use the same 4923 Initiator Task Tag. The operational parameters of the 4924 session or the connection MUST continue to be the values 4925 agreed upon during an earlier successful negotiation (i.e., 4926 any partial results of this unsuccessful negotiation MUST 4927 NOT take effect and MUST be discarded). 4929 7.13. Protocol Errors 4931 Mapping framed messages over a "stream" connection, such as TCP, 4932 makes the proposed mechanisms vulnerable to simple software 4933 framing errors. On the other hand, the introduction of framing 4934 mechanisms to limit the effects of these errors may be onerous on 4935 performance for simple implementations. Command Sequence Numbers 4936 and the above mechanisms for connection drop and reestablishment 4937 help handle this type of mapping errors. 4939 All violations of iSCSI PDU exchange sequences specified in this 4940 draft are also protocol errors. This category of errors can only 4941 be 4942 addressed by fixing the implementations; iSCSI defines Reject and 4943 response codes to enable this. 4945 7.14. Connection Failures 4947 iSCSI can keep a session in operation if it is able to 4948 keep/establish at least one TCP connection between the initiator 4949 and the target in a timely fashion. Targets and/or initiators may 4950 recognize a failing connection by either transport level means 4951 (TCP), a gap in the command sequence number, a response stream 4952 that is not filled for a long time, or by a failing iSCSI NOP 4953 (acting as a ping). The latter MAY be used periodically to 4954 increase the speed and likelihood of detecting connection 4955 failures. Initiators and targets MAY also use the keep-alive 4956 option on the TCP connection to enable early link failure 4957 detection on otherwise idle links. 4959 On connection failure, the initiator and target MUST do one of the 4960 following: 4962 - Attempt connection recovery within the session (Connection 4963 Recovery). 4965 - Logout the connection with the reason code "closes the 4966 connection" (Section 10.14.5 - "Implicit termination of 4967 tasks"), re-issue missing commands, and implicitly terminate 4968 all active commands. This option requires support for the 4969 within-connection recovery class (Recovery Within- 4970 connection). 4972 - Perform session recovery (Session Recovery). 4974 Either side may choose to escalate to session recovery (via the 4975 initiator dropping all the connections, or via an Async Message 4976 that announces the similar intent from a target), and the other 4977 side MUST give it precedence. On a connection failure, a target 4978 MUST terminate and/or discard all of the active immediate commands 4979 regardless of which of the above options is used (i.e., immediate 4980 commands are not recoverable across connection failures). 4982 7.15. Session Errors 4984 If all of the connections of a session fail and cannot be 4985 reestablished in a short time, or if initiators detect protocol 4986 errors repeatedly, an initiator may choose to terminate a session 4987 and establish a new session. 4989 In this case, the initiator takes the following actions: 4991 - Resets or closes all the transport connections. 4993 - Terminates all outstanding requests with an appropriate 4994 response before initiating a new session. If the same I_T 4995 nexus is intended to be reestablished, the initiator MUST 4996 employ session reinstatement (see section 5.3.5). 4998 When the session timeout (the connection state timeout for the 4999 last failed connection) happens on the target, it takes the 5000 following actions: 5002 - Resets or closes the TCP connections (closes the session). 5004 - Terminates all active tasks that were allegiant to the 5005 connection(s) that constituted the session. 5007 A target MUST also be prepared to handle a session reinstatement 5008 request from the initiator, that may be addressing session errors. 5010 8. State Transitions 5012 iSCSI connections and iSCSI sessions go through several well- 5013 defined states from the time they are created to the time they are 5014 cleared. 5016 The connection state transitions are described in two separate but 5017 dependent state diagrams for ease in understanding. The first 5018 diagram, "standard connection state diagram", describes the 5019 connection state transitions when the iSCSI connection is not 5020 waiting for, or undergoing, a cleanup by way of an explicit or 5021 implicit Logout. The second diagram, "connection cleanup state 5022 diagram", describes the connection state transitions while 5023 performing the iSCSI connection cleanup. 5025 The "session state diagram" describes the state transitions an 5026 iSCSI session would go through during its lifetime, and it depends 5027 on the states of possibly multiple iSCSI connections that 5028 participate in the session. 5030 States and transitions are described in text, tables and diagrams. 5031 The diagrams are used for illustration. The text and the tables 5032 are the governing specification. 5034 8.1. Standard Connection State Diagrams 5036 8.1.1. State Descriptions for Initiators and Targets 5038 State descriptions for the standard connection state diagram are 5039 as follows: 5040 -S1: FREE 5041 -initiator: State on instantiation, or after successful 5042 connection closure. 5043 -target: State on instantiation, or after successful 5044 connection closure. 5045 -S2: XPT_WAIT 5046 -initiator: Waiting for a response to its transport 5047 connection establishment request. 5048 -target: Illegal 5049 -S3: XPT_UP 5050 -initiator: Illegal 5051 -target: Waiting for the Login process to commence. 5053 -S4: IN_LOGIN 5054 -initiator: Waiting for the Login process to conclude, 5055 possibly involving several PDU exchanges. 5056 -target: Waiting for the Login process to conclude, 5057 possibly involving several PDU exchanges. 5058 -S5: LOGGED_IN 5059 -initiator: In Full Feature Phase, waiting for all 5060 internal, iSCSI, and transport events. 5061 -target: In Full Feature Phase, waiting for all internal, 5062 iSCSI, and transport events. 5063 -S6: IN_LOGOUT 5064 -initiator: Waiting for a Logout response. 5065 -target: Waiting for an internal event signaling completion 5066 of logout processing. 5067 -S7: LOGOUT_REQUESTED 5068 -initiator: Waiting for an internal event signaling 5069 readiness to proceed with Logout. 5070 -target: Waiting for the Logout process to start after 5071 having requested a Logout via an Async Message. 5072 -S8: CLEANUP_WAIT 5073 -initiator: Waiting for the context and/or resources to 5074 initiate the cleanup processing for this CSM. 5075 -target: Waiting for the cleanup process to start for this 5076 CSM. 5077 8.1.2. State Transition Descriptions for Initiators and Targets 5079 -T1: 5080 -initiator: Transport connect request was made (e.g., TCP 5081 SYN sent). 5082 -target: Illegal 5083 -T2: 5084 -initiator: Transport connection request timed out, a 5085 transport reset was received, or an internal event of 5086 receiving a Logout response (success) on another connection 5087 for a "close the session" Logout request was received. 5088 -target:Illegal 5089 -T3: 5090 -initiator: Illegal 5091 -target: Received a valid transport connection request that 5092 establishes the transport connection. 5093 -T4: 5095 -initiator: Transport connection established, thus 5096 prompting the initiator to start the iSCSI Login. 5097 -target: Initial iSCSI Login request was received. 5098 -T5: 5099 -initiator: The final iSCSI Login response with a Status- 5100 Class of zero was received. 5101 -target: The final iSCSI Login request to conclude the 5102 Login Phase was received, thus prompting the target to send 5103 the final iSCSI Login response with a Status-Class of zero. 5104 -T6: 5105 -initiator: Illegal 5106 -target: Timed out waiting for an iSCSI Login, transport 5107 disconnect indication was received, transport reset was 5108 received, or an internal event indicating a transport 5109 timeout was received. In all these cases, the connection is 5110 to be closed. 5111 -T7: 5112 -initiator - one of the following events caused the 5113 transition: 5114 - The final iSCSI Login response was received with a 5115 non-zero Status-Class. 5116 - Login timed out. 5117 - A transport disconnect indication was received. 5118 - A transport reset was received. 5119 - An internal event indicating a transport timeout was 5120 received. 5121 - An internal event of receiving a Logout response 5122 (success) on another connection for a "close the 5123 session" Logout request was received. 5125 In all these cases, the transport connection is closed. 5127 -target - one of the following events caused the 5128 transition: 5129 - The final iSCSI Login request to conclude the Login 5130 Phase was received, prompting the target to send the 5131 final iSCSI Login response with a non-zero Status- 5132 Class. 5133 - Login timed out. 5134 - Transport disconnect indication was received. 5136 - Transport reset was received. 5137 - An internal event indicating a transport timeout was 5138 received . 5139 - On another connection a "close the session" 5140 Logout request was received. 5142 In all these cases, the connection is to be closed. 5143 -T8: 5144 -initiator: An internal event of receiving a Logout 5145 response (success) on another connection for a "close the 5146 session" Logout request was received, thus closing this 5147 connection requiring no further cleanup. 5148 -target: An internal event of sending a Logout response 5149 (success) on another connection for a "close the session" 5150 Logout request was received, or an internal event of a 5151 successful connection/session reinstatement is received, 5152 thus prompting the target to close this connection cleanly. 5153 -T9, T10: 5154 -initiator: An internal event that indicates the readiness 5155 to start the Logout process was received, thus prompting an 5156 iSCSI Logout to be sent by the initiator. 5157 -target: An iSCSI Logout request was received. 5158 -T11, T12: 5159 -initiator: Async PDU with AsyncEvent "Request Logout" was 5160 received. 5161 -target: An internal event that requires the 5162 decommissioning of the connection is received, thus causing 5163 an Async PDU with an AsyncEvent "Request Logout" to be 5164 sent. 5165 -T13: 5166 -initiator: An iSCSI Logout response (success) was 5167 received, or an internal event of receiving a Logout 5168 response (success) on another connection for a "close the 5169 session" Logout request was received. 5170 -target: An internal event was received that indicates 5171 successful processing of the Logout, which prompts an iSCSI 5172 Logout response (success) to be sent; an internal event of 5173 sending a Logout response (success) on another connection 5174 for a "close the session" Logout request was received; or 5175 an internal event of a successful connection/session 5176 reinstatement is received. In all these cases, the 5177 transport connection is closed. 5179 -T14: 5180 -initiator: Async PDU with AsyncEvent "Request Logout" was 5181 received again. 5182 -target: Illegal 5183 -T15, T16: 5184 -initiator: One or more of the following events caused this 5185 transition: 5186 -Internal event that indicates a transport connection 5187 timeout was received thus prompting transport RESET or 5188 transport connection closure. 5189 -A transport RESET. 5190 -A transport disconnect indication. 5191 -Async PDU with AsyncEvent "Drop connection" (for this 5192 CID). 5193 -Async PDU with AsyncEvent "Drop all connections". 5194 -target: One or more of the following events caused this 5195 transition: 5196 -Internal event that indicates a transport connection 5197 timeout was received, thus prompting transport RESET or 5198 transport connection closure. 5199 -An internal event of a failed connection/session 5200 reinstatement is received. 5201 -A transport RESET. 5202 -A transport disconnect indication. 5203 -Internal emergency cleanup event was received which 5204 prompts an Async PDU with AsyncEvent "Drop connection" 5205 (for this CID), or event "Drop all connections". 5207 -T17: 5208 -initiator: One or more of the following events caused this 5209 transition: 5210 -Logout response, (failure i.e., a non-zero status) was 5211 received, or Logout timed out. 5212 -Any of the events specified for T15 and T16. 5213 -target: One or more of the following events caused this 5214 transition: 5216 -Internal event that indicates a failure of the Logout 5217 processing was received, which prompts a Logout 5218 response (failure, i.e., a non-zero status) to be sent. 5219 -Any of the events specified for T15 and T16. 5220 -T18: 5221 -initiator: An internal event of receiving a Logout 5222 response (success) on another connection for a "close the 5223 session" Logout request was received. 5225 -target: An internal event of sending a Logout response 5226 (success) on another connection for a "close the session" 5227 Logout request was received, or an internal event of a 5228 successful connection/session reinstatement is received. 5229 In both these cases, the connection is closed. 5231 The CLEANUP_WAIT state (S8) implies that there are possible iSCSI 5232 tasks that have not reached conclusion and are still considered 5233 busy. 5235 8.1.3. Standard Connection State Diagram for an Initiator 5237 Symbolic names for States: 5239 S1: FREE 5241 S2: XPT_WAIT 5243 S4: IN_LOGIN 5245 S5: LOGGED_IN 5247 S6: IN_LOGOUT 5249 S7: LOGOUT_REQUESTED 5251 S8: CLEANUP_WAIT 5253 States S5, S6, and S7 constitute the Full Feature Phase operation 5254 of the connection. 5256 The state diagram is as follows: 5258 -------<-------------+ 5259 +--------->/ S1 \<----+ | 5260 T13| +->\ /<-+ \ | 5261 | / ---+--- \ \ | 5262 | / | T2 \ | | 5263 | T8 | |T1 | | | 5264 | | | / |T7 | 5265 | | | / | | 5266 | | | / | | 5267 | | V / / | 5268 | | ------- / / | 5269 | | / S2 \ / | 5270 | | \ / / | 5271 | | ---+--- / | 5272 | | |T4 / | 5273 | | V / | T18 5274 | | ------- / | 5275 | | / S4 \ | 5276 | | \ / | 5277 | | ---+--- | T15 5278 | | |T5 +--------+---------+ 5279 | | | /T16+-----+------+ | 5280 | | | / -+-----+--+ | | 5281 | | | / / S7 \ |T12| | 5282 | | | / +->\ /<-+ V V 5283 | | | / / -+----- ------- 5284 | | | / /T11 |T10 / S8 \ 5285 | | V / / V +----+ \ / 5286 | | ---+-+- ----+-- | ------- 5287 | | / S5 \T9 / S6 \<+ ^ 5288 | +-----\ /--->\ / T14 | 5289 | ------- --+----+------+T17 5290 +---------------------------+ 5292 The following state transition table represents the above diagram. 5293 Each row represents the starting state for a given transition, 5294 which after taking a transition marked in a table cell would end 5295 in the state represented by the column of the cell. For example, 5296 from state S1, the connection takes the T1 transition to arrive at 5297 state S2. The fields marked "-" correspond to undefined 5298 transitions. 5300 +----+---+---+---+---+----+---+ 5301 |S1 |S2 |S4 |S5 |S6 |S7 |S8 | 5302 ---+----+---+---+---+---+----+---+ 5303 S1| - |T1 | - | - | - | - | - | 5304 ---+----+---+---+---+---+----+---+ 5305 S2|T2 |- |T4 | - | - | - | - | 5306 ---+----+---+---+---+---+----+---+ 5307 S4|T7 |- |- |T5 | - | - | - | 5308 ---+----+---+---+---+---+----+---+ 5309 S5|T8 |- |- | - |T9 |T11 |T15| 5310 ---+----+---+---+---+---+----+---+ 5311 S6|T13 |- |- | - |T14|- |T17| 5312 ---+----+---+---+---+---+----+---+ 5313 S7|T18 |- |- | - |T10|T12 |T16| 5314 ---+----+---+---+---+---+----+---+ 5315 S8| - |- |- | - | - | - | - | 5316 ---+----+---+---+---+---+----+---+ 5318 8.1.4. Standard Connection State Diagram for a Target 5320 Symbolic names for States: 5321 S1: FREE 5323 S3: XPT_UP 5325 S4: IN_LOGIN 5327 S5: LOGGED_IN 5329 S6: IN_LOGOUT 5331 S7: LOGOUT_REQUESTED 5333 S8: CLEANUP_WAIT 5335 States S5, S6, and S7 constitute the Full Feature Phase operation 5336 of the connection. 5338 The state diagram is as follows: 5340 -------<-------------+ 5341 +--------->/ S1 \<----+ | 5342 T13| +->\ /<-+ \ | 5343 | / ---+--- \ \ | 5344 | / | T6 \ | | 5345 | T8 | |T3 | | | 5346 | | | / |T7 | 5347 | | | / | | 5348 | | | / | | 5349 | | V / / | 5350 | | ------- / / | 5351 | | / S3 \ / | 5352 | | \ / / | T18 5353 | | ---+--- / | 5354 | | |T4 / | 5355 | | V / | 5356 | | ------- / | 5357 | | / S4 \ | 5358 | | \ / | 5359 | | ---+--- T15 | 5360 | | |T5 +--------+---------+ 5361 | | | /T16+-----+------+ | 5362 | | | / -+-----+---+ | | 5363 | | | / / S7 \ |T12| | 5364 | | | / +->\ /<-+ V V 5365 | | | / / -+----- ------- 5366 | | | / /T11 |T10 / S8 \ 5367 | | V / / V \ / 5368 | | ---+-+- ------- ------- 5369 | | / S5 \T9 / S6 \ ^ 5370 | +-----\ /--->\ / | 5371 | ------- --+----+--------+T17 5372 +---------------------------+ 5374 The following state transition table represents the above diagram, 5375 and follows the conventions described for the initiator diagram. 5377 +----+---+---+---+---+----+---+ 5378 |S1 |S3 |S4 |S5 |S6 |S7 |S8 | 5379 ---+----+---+---+---+---+----+---+ 5380 S1| - |T3 | - | - | - | - | - | 5381 ---+----+---+---+---+---+----+---+ 5382 S3|T6 |- |T4 | - | - | - | - | 5383 ---+----+---+---+---+---+----+---+ 5384 S4|T7 |- |- |T5 | - | - | - | 5385 ---+----+---+---+---+---+----+---+ 5386 S5|T8 |- |- | - |T9 |T11 |T15| 5387 ---+----+---+---+---+---+----+---+ 5388 S6|T13 |- |- | - |- |- |T17| 5389 ---+----+---+---+---+---+----+---+ 5390 S7|T18 |- |- | - |T10|T12 |T16| 5391 ---+----+---+---+---+---+----+---+ 5392 S8| - |- |- | - | - | - | - | 5393 ---+----+---+---+---+---+----+---+ 5395 8.2. Connection Cleanup State Diagram for Initiators and Targets 5397 Symbolic names for states: 5399 R1: CLEANUP_WAIT (same as S8) 5401 R2: IN_CLEANUP 5403 R3: FREE (same as S1) 5405 Whenever a connection state machine in cleanup (let's call it CSM- 5406 C) enters the CLEANUP_WAIT state (S8), it must go through the 5407 state transitions described in the connection cleanup state 5408 diagram either a) using a separate full-feature phase connection 5409 (let's call it CSM-E, for explicit) in the LOGGED_IN state in the 5410 same session, or b) using a new transport connection (let's call 5411 it CSM-I, for implicit) in the FREE state that is to be added to 5412 the same session. In the CSM-E case, an explicit logout for the 5413 CID that corresponds to CSM-C (either as a connection or session 5414 logout) needs to be performed to complete the cleanup. In the CSM- 5415 I case, an implicit logout for the CID that corresponds to CSM-C 5416 needs to be performed by way of connection reinstatement (section 5417 5.3.4) for that CID. In either case, the protocol exchanges on 5418 CSM-E or CSM-I determine the state transitions for CSM-C. 5419 Therefore, this cleanup state diagram is only applicable to the 5420 instance of the connection in cleanup (i.e., CSM-C). In the case 5421 of an implicit logout for example, CSM-C reaches FREE (R3) at the 5422 time CSM-I reaches LOGGED_IN. In the case of an explicit logout, 5423 CSM-C reaches FREE (R3) when CSM-E receives a successful logout 5424 response while continuing to be in the LOGGED_IN state. 5426 An initiator must initiate an explicit or implicit connection 5427 logout for a connection in the CLEANUP_WAIT state, if the 5428 initiator intends to continue using the associated iSCSI session. 5430 The following state diagram applies to both initiators and 5431 targets. 5433 ------- 5434 / R1 \ 5435 +--\ /<-+ 5436 / ---+--- \ 5437 / | \ M3 5438 M1 | |M2 | 5439 | | / 5440 | | / 5441 | | / 5442 | V / 5443 | ------- / 5444 | / R2 \ 5445 | \ / 5446 | ------- 5447 | | 5448 | |M4 5449 | | 5450 | | 5451 | | 5452 | V 5453 | ------- 5454 | / R3 \ 5455 +---->\ / 5456 ------- 5458 The following state transition table represents the above diagram, 5459 and follows the same conventions as in earlier sections. 5461 +----+----+----+ 5462 |R1 |R2 |R3 | 5463 -----+----+----+----+ 5464 R1 | - |M2 |M1 | 5465 -----+----+----+----+ 5466 R2 |M3 | - |M4 | 5467 -----+----+----+----+ 5468 R3 | - | - | - | 5469 -----+----+----+----+ 5471 8.2.1. State Descriptions for Initiators and Targets 5473 -R1: CLEANUP_WAIT (Same as S8) 5474 -initiator: Waiting for the internal event to initiate the 5475 cleanup processing for CSM-C. 5476 -target: Waiting for the cleanup process to start for CSM- 5477 C. 5478 -R2: IN_CLEANUP 5479 -initiator: Waiting for the connection cleanup process to 5480 conclude for CSM-C. 5481 -target: Waiting for the connection cleanup process to 5482 conclude for CSM-C. 5483 -R3: FREE (Same as S1) 5484 -initiator: End state for CSM-C. 5485 -target: End state for CSM-C. 5487 8.2.2. State Transition Descriptions for Initiators and Targets 5489 -M1: One or more of the following events was received: 5490 -initiator: 5491 -An internal event that indicates connection state 5492 timeout. 5493 -An internal event of receiving a successful Logout 5494 response on a different connection for a "close the 5495 session" Logout. 5496 -target: 5497 -An internal event that indicates connection state 5498 timeout. 5499 -An internal event of sending a Logout response 5500 (success) on a different connection for a "close the 5501 session" Logout request. 5503 -M2: An implicit/explicit logout process was initiated by the 5504 initiator. 5505 -In CSM-I usage: 5506 -initiator: An internal event requesting the connection 5507 (or session) reinstatement was received, thus prompting 5508 a connection (or session) reinstatement Login to be 5509 sent transitioning CSM-I to state IN_LOGIN. 5510 -target: A connection/session reinstatement Login was 5511 received while in state XPT_UP. 5512 -In CSM-E usage: 5514 -initiator: An internal event that indicates that an 5515 explicit logout was sent for this CID in state 5516 LOGGED_IN. 5517 -target: An explicit logout was received for this CID 5518 in state LOGGED_IN. 5519 -M3: Logout failure detected 5520 -In CSM-I usage: 5521 -initiator: CSM-I failed to reach LOGGED_IN and arrived 5522 into FREE instead. 5523 -target: CSM-I failed to reach LOGGED_IN and arrived 5524 into FREE instead. 5525 -In CSM-E usage: 5526 -initiator: CSM-E either moved out of LOGGED_IN, or 5527 Logout timed out and/or aborted, or Logout response 5528 (failure) was received. 5529 -target: CSM-E either moved out of LOGGED_IN, Logout 5530 timed out and/or aborted, or an internal event that 5531 indicates a failed Logout processing was received. A 5532 Logout response (failure) was sent in the last case. 5534 -M4: Successful implicit/explicit logout was performed. 5535 - In CSM-I usage: 5536 -initiator: CSM-I reached state LOGGED_IN, or an 5537 internal event of receiving a Logout response (success) 5538 on another connection for a "close the session" Logout 5539 request was received. 5540 -target: CSM-I reached state LOGGED_IN, or an internal 5541 event of sending a Logout response (success) on a 5542 different connection for a "close the session" Logout 5543 request was received. 5544 - In CSM-E usage: 5545 -initiator: CSM-E stayed in LOGGED_IN and received a 5546 Logout response (success), or an internal event of 5547 receiving a Logout response (success) on another 5548 connection for a "close the session" Logout request was 5549 received. 5550 -target: CSM-E stayed in LOGGED_IN and an internal 5551 event indicating a successful Logout processing was 5552 received, or an internal event of sending a Logout 5553 response (success) on a different connection for a 5554 "close the session" Logout request was received. 5556 8.3. Session State Diagrams 5558 8.3.1. Session State Diagram for an Initiator 5560 Symbolic Names for States: 5562 Q1: FREE 5564 Q3: LOGGED_IN 5566 Q4: FAILED 5568 State Q3 represents the Full Feature Phase operation of the 5569 session. 5571 The state diagram is as follows: 5573 ------- 5574 / Q1 \ 5575 +------>\ /<-+ 5576 / ---+--- | 5577 / | |N3 5578 N6 | |N1 | 5579 | | | 5580 | N4 | | 5581 | +--------+ | / 5582 | | | | / 5583 | | | | / 5584 | | V V / 5585 -+--+-- -----+- 5586 / Q4 \ N5 / Q3 \ 5587 \ /<---\ / 5588 ------- ------- 5590 The state transition table is as follows: 5592 +----+----+----+ 5593 |Q1 |Q3 |Q4 | 5594 -----+----+----+----+ 5595 Q1 | - |N1 | - | 5596 -----+----+----+----+ 5597 Q3 |N3 | - |N5 | 5598 -----+----+----+----+ 5599 Q4 |N6 |N4 | - | 5600 -----+----+----+----+ 5602 8.3.2. Session State Diagram for a Target 5604 Symbolic Names for States: 5606 Q1: FREE 5608 Q2: ACTIVE 5610 Q3: LOGGED_IN 5612 Q4: FAILED 5614 Q5: IN_CONTINUE 5616 State Q3 represents the Full Feature Phase operation of the 5617 session. 5619 The state diagram is as follows: 5621 ------- 5622 +------------------>/ Q1 \ 5623 / +-------------->\ /<-+ 5624 | | ---+--- | 5625 | | ^ | |N3 5626 N6 | |N11 N9| V N1 | 5627 | | +------ | 5628 | | / Q2 \ | 5629 | | \ / | 5630 | --+---- +--+--- | 5631 | / Q5 \ | | 5632 | \ / N10 | | 5633 | +-+---+------------+ |N2 / 5634 | ^ | | | / 5635 |N7| |N8 | | / 5636 | | | | V / 5637 -+--+-V V----+- 5638 / Q4 \ N5 / Q3 \ 5639 \ /<-------------\ / 5640 ------- ------- 5642 The state transition table is as follows: 5644 +----+----+----+----+----+ 5645 |Q1 |Q2 |Q3 |Q4 |Q5 | 5646 -----+----+----+----+----+----+ 5647 Q1 | - |N1 | - | - | - | 5648 -----+----+----+----+----+----+ 5649 Q2 |N9 | - |N2 | - | - | 5650 -----+----+----+----+----+----+ 5651 Q3 |N3 | - | - |N5 | - | 5652 -----+----+----+----+----+----+ 5653 Q4 |N6 | - | - | - |N7 | 5654 -----+----+----+----+----+----+ 5655 Q5 |N11 | - |N10 |N8 | - | 5656 -----+----+----+----+----+----+ 5658 8.3.3. State Descriptions for Initiators and Targets 5660 -Q1: FREE 5661 -initiator: State on instantiation or after cleanup. 5663 -target: State on instantiation or after cleanup. 5664 -Q2: ACTIVE 5665 -initiator: Illegal. 5666 -target: The first iSCSI connection in the session 5667 transitioned to IN_LOGIN, waiting for it to complete the 5668 login process. 5669 -Q3: LOGGED_IN 5670 -initiator: Waiting for all session events. 5671 -target: Waiting for all session events. 5672 -Q4: FAILED 5673 -initiator: Waiting for session recovery or session 5674 continuation. 5675 -target: Waiting for session recovery or session 5676 continuation. 5677 -Q5: IN_CONTINUE 5678 -initiator: Illegal. 5679 -target: Waiting for session continuation attempt to reach 5680 a conclusion. 5682 8.3.4. State Transition Descriptions for Initiators and Targets 5684 -N1: 5685 -initiator: At least one transport connection reached the 5686 LOGGED_IN state. 5687 -target: The first iSCSI connection in the session had 5688 reached the IN_LOGIN state. 5689 -N2: 5690 -initiator: Illegal. 5691 -target: At least one iSCSI connection reached the 5692 LOGGED_IN state. 5693 -N3: 5694 -initiator: Graceful closing of the session via session 5695 closure (Section 5.3.6 - "Session Continuation and 5696 Failure"). 5697 -target: Graceful closing of the session via session 5698 closure (Section 5.3.6 - "Session Continuation and 5699 Failure") or a successful session reinstatement cleanly 5700 closed the session. 5701 -N4: 5702 -initiator: A session continuation attempt succeeded. 5704 -target: Illegal. 5705 -N5: 5706 -initiator: Session failure (Section 5.3.6 - "Session 5707 Continuation and Failure") occurred. 5708 -target: Session failure (Section 5.3.6 - "Session 5709 Continuation and Failure") occurred. 5710 -N6: 5711 -initiator: Session state timeout occurred, or a session 5712 reinstatement cleared this session instance. This results 5713 in the freeing of all associated resources and the session 5714 state is discarded. 5715 -target: Session state timeout occurred, or a session 5716 reinstatement cleared this session instance. This results 5717 in the freeing of all associated resources and the session 5718 state is discarded. 5719 -N7: 5720 -initiator: Illegal. 5721 -target: A session continuation attempt is initiated. 5722 -N8: 5723 -initiator: Illegal. 5724 -target: The last session continuation attempt failed. 5725 -N9: 5726 -initiator: Illegal. 5727 -target: Login attempt on the leading connection failed. 5728 -N10: 5729 -initiator: Illegal. 5730 -target: A session continuation attempt succeeded. 5731 -N11: 5732 -initiator: Illegal. 5733 -target: A successful session reinstatement cleanly closed 5734 the session. 5736 9. Security Considerations 5738 Historically, native storage systems have not had to consider 5739 security because their environments offered minimal security 5740 risks. That is, these environments consisted of storage devices 5741 either directly attached to hosts or connected via a Storage Area 5742 Network (SAN) distinctly separate from the communications network. 5743 The use of storage protocols, such as SCSI, over IP-networks 5744 requires that security concerns be addressed. iSCSI 5745 implementations MUST provide means of protection against active 5746 attacks (e.g., pretending to be another identity, message 5747 insertion, deletion, modification, and replaying) and passive 5748 attacks (e.g.,eavesdropping, gaining advantage by analyzing the 5749 data sent over the line). 5751 Although technically possible, iSCSI SHOULD NOT be configured 5752 without security. iSCSI configured without security should be 5753 confined, in extreme cases, to closed environments without any 5754 security risk. [RFC3723] specifies the mechanisms that must be 5755 used in order to mitigate risks fully described in that document. 5757 The following section describes the security mechanisms provided 5758 by an iSCSI implementation. 5760 9.1. iSCSI Security Mechanisms 5762 The entities involved in iSCSI security are the initiator, target, 5763 and the IP communication end points. iSCSI scenarios in which 5764 multiple initiators or targets share a single communication end 5765 point are expected. To accommodate such scenarios, iSCSI uses two 5766 separate security mechanisms: In-band authentication between the 5767 initiator and the target at the iSCSI connection level (carried 5768 out by exchange of iSCSI Login PDUs), and packet protection 5769 (integrity, authentication, and confidentiality) by IPsec at the 5770 IP level. The two security mechanisms complement each other. The 5771 in-band authentication provides end-to-end trust (at login time) 5772 between the iSCSI initiator and the target while IPsec provides a 5773 secure channel between the IP communication end points. 5775 Further details on typical iSCSI scenarios and the relation 5776 between the initiators, targets, and the communication end points 5777 can be found in [RFC3723]. 5779 9.2. In-band Initiator-Target Authentication 5781 During login, the target MUST authenticate the initiator and the 5782 initiator MAY authenticate the target. The authentication is 5783 performed on every new iSCSI connection by an exchange of iSCSI 5784 Login PDUs using a negotiated authentication method. 5786 The authentication method cannot assume an underlying IPsec 5787 protection, because IPsec is optional to use. An attacker should 5788 gain as little advantage as possible by inspecting the 5789 authentication phase PDUs. Therefore, a method using clear text 5790 (or equivalent) passwords is not acceptable; on the other hand, 5791 identity protection is not strictly required. 5793 The authentication mechanism protects against an unauthorized 5794 login to storage resources by using a false identity (spoofing). 5795 Once the authentication phase is completed, if the underlying 5796 IPsec is not used, all PDUs are sent and received in clear. The 5797 authentication mechanism alone (without underlying IPsec) should 5798 only be used when there is no risk of eavesdropping, message 5799 insertion, deletion, modification, and replaying. 5801 Section 11 - "iSCSI Security Text Keys and Authentication Methods" 5802 defines several authentication methods and the exact steps that 5803 must be followed in each of them, including the iSCSI-text-keys 5804 and their allowed values in each step. Whenever an iSCSI initiator 5805 gets a response whose keys, or their values, are not according to 5806 the step definition, it MUST abort the connection. Whenever an 5807 iSCSI target gets a response whose keys, or their values, are not 5808 according to the step definition, it MUST answer with a Login 5809 reject with the "Initiator Error" or "Missing Parameter" status. 5810 These statuses are not intended for cryptographically incorrect 5811 values such as the CHAP response, for which "Authentication 5812 Failure" status MUST be specified. The importance of this rule can 5813 be illustrated in CHAP with target authentication (see Section 5814 11.1.4 - "Challenge Handshake Authentication Protocol (CHAP)") 5815 where the initiator would have been able to conduct a reflection 5816 attack by omitting his response key (CHAP_R) using the same CHAP 5817 challenge as the target and reflecting the target's response back 5818 to the target. In CHAP, this is prevented because the target must 5819 answer the missing CHAP_R key with a Login reject with the 5820 "Missing Parameter" status. 5822 For some of the authentication methods, a key specifies the 5823 identity of the iSCSI initiator or target for authentication 5824 purposes. The value associated with that key MAY be different from 5825 the iSCSI name and SHOULD be configurable. (CHAP_N, see Section 5826 11.1.4 - "Challenge Handshake Authentication Protocol (CHAP)" and 5827 SRP_U, see Section 11.1.3 - "Secure Remote Password (SRP)"). 5829 9.2.1. CHAP Considerations 5831 Compliant iSCSI initiators and targets MUST implement the CHAP 5832 authentication method [RFC1994] (according to Section 11.1.4 - 5833 "Challenge Handshake Authentication Protocol (CHAP)" including the 5834 target authentication option). 5836 When CHAP is performed over a non-encrypted channel, it is 5837 vulnerable to an off-line dictionary attack. Implementations MUST 5838 support use of up to 128 bit random CHAP secrets, including the 5839 means to generate such secrets and to accept them from an external 5840 generation source. Implementations MUST NOT provide secret 5841 generation (or expansion) means other than random generation. 5843 An administrative entity of an environment in which CHAP is used 5844 with a secret that has less than 96 random bits MUST enforce IPsec 5845 encryption (according to the implementation requirements in 5846 Confidentiality) to protect the connection. Moreover, in this case 5847 IKE authentication with group pre-shared cryptographic keys SHOULD 5848 NOT be used unless it is not essential to protect group members 5849 against off-line dictionary attacks by other members. 5851 CHAP secrets MUST be an integral number of bytes (octets). A 5852 compliant implementation SHOULD NOT continue with the login step 5853 in which it should send a CHAP response (CHAP_R, Section 11.1.4 - 5854 "Challenge Handshake Authentication Protocol (CHAP)") unless it 5855 can verify that the CHAP secret is at least 96 bits, or that IPsec 5856 encryption is being used to protect the connection. 5858 Any CHAP secret used for initiator authentication MUST NOT be 5859 configured for authentication of any target, and any CHAP secret 5860 used for target authentication MUST NOT be configured for 5861 authentication of any initiator. If the CHAP response received by 5862 one end of an iSCSI connection is the same as the CHAP response 5863 that the receiving endpoint would have generated for the same CHAP 5864 challenge, the response MUST be treated as an authentication 5865 failure and cause the connection to close (this ensures that the 5866 same CHAP secret is not used for authentication in both 5867 directions). Also, if 5868 an iSCSI implementation can function as both initiator and target, 5869 different CHAP secrets and identities MUST be configured for these 5870 two roles. The following is an example of the attacks prevented by 5871 the above requirements: 5873 Rogue wants to impersonate Storage to Alice, and knows that a 5874 single secret is used for both directions of Storage-Alice 5875 authentication. 5877 Rogue convinces Alice to open two connections to Rogue, and 5878 Rogue identifies itself as Storage on both connections. 5880 Rogue issues a CHAP challenge on connection 1, waits for Alice 5881 to respond, and then reflects Alice's challenge as the 5882 initial challenge to Alice on connection 2. 5884 If Alice doesn't check for the reflection across connections, 5885 Alice's response on connection 2 enables Rogue to 5886 impersonate Storage on connection 1, even though Rogue does 5887 not know the Alice-Storage CHAP secret. 5889 Originators MUST NOT reuse the CHAP challenge sent by the 5890 Responder for the other direction of a bidirectional 5891 authentication. Responders MUST check for this condition and close 5892 the iSCSI TCP connection if it occurs. 5894 The same CHAP secret SHOULD NOT be configured for authentication 5895 of multiple initiators or multiple targets, as this enables any of 5896 them to impersonate any other one of them, and compromising one of 5897 them enables the attacker to impersonate any of them. It is 5898 recommended that iSCSI implementations check for use of identical 5899 CHAP secrets by different peers when this check is feasible, and 5900 take appropriate measures to warn users and/or administrators when 5901 this is detected. 5903 When an iSCSI initiator or target authenticates itself to 5904 counterparts in multiple administrative domains, it SHOULD use a 5905 different CHAP secret for each administrative domain to avoid 5906 propagating security compromises across domains. 5908 Within a single administrative domain: 5909 - A single CHAP secret MAY be used for authentication of an 5910 initiator to multiple targets. 5912 - A single CHAP secret MAY be used for an authentication of a 5913 target to multiple initiators when the initiators use an 5914 external server (e.g., RADIUS) to verify the target's CHAP 5915 responses and do not know the target's CHAP secret. 5917 If an external response verification server (e.g., RADIUS) is not 5918 used, employing a single CHAP secret for authentication of a 5919 target to multiple initiators requires that all such initiators 5920 know that target secret. Any of these initiators can impersonate 5921 the target to any other such initiator, and compromise of such an 5922 initiator enables an attacker to impersonate the target to all 5923 such initiators. Targets SHOULD use separate CHAP secrets for 5924 authentication to each initiator when such risks are of concern; 5925 in this situation it may be useful to configure a separate logical 5926 iSCSI target with its own iSCSI Node Name for each initiator or 5927 group of initiators among which such separation is desired. 5929 9.2.2. SRP Considerations 5931 The strength of the SRP authentication method (specified in 5932 [RFC2945]) is dependent on the characteristics of the group being 5933 used (i.e., the prime modulus N and generator g). As described in 5934 [RFC2945], N is required to be a Sophie-German prime (of the form 5935 N = 2q + 1, where q is also prime) and the generator g is a 5936 primitive root of GF(n). In iSCSI authentication, the prime 5937 modulus N MUST be at least 768 bits. 5939 The list of allowed SRP groups is provided in [RFC3723]. 5941 9.3. IPsec 5943 iSCSI uses the IPsec mechanism for packet protection 5944 (cryptographic integrity, authentication, and confidentiality) at 5945 the IP level between the iSCSI communicating end points. The 5946 following sections describe the IPsec protocols that must be 5947 implemented for data integrity and authentication, 5948 confidentiality, and cryptographic key management. 5950 An iSCSI initiator or target may provide the required IPsec 5951 support fully integrated or in conjunction with an IPsec front-end 5952 device. In the latter case, the compliance requirements with 5953 regard to IPsec support apply to the "combined device". Only the 5954 "combined device" is to be considered an iSCSI device. 5956 Detailed considerations and recommendations for using IPsec for 5957 iSCSI are provided in [RFC3723]. 5959 9.3.1. Data Integrity and Authentication 5961 Data authentication and integrity is provided by a cryptographic 5962 keyed Message Authentication Code in every sent packet. This code 5963 protects against message insertion, deletion, and modification. 5964 Protection against message replay is realized by using a sequence 5965 counter. 5967 An iSCSI compliant initiator or target MUST provide data integrity 5968 and authentication by implementing IPsec [RFC4301] with ESP 5969 [RFC4303] in tunnel mode and MAY provide data integrity and 5970 authentication by implementing IPsec with ESP in transport mode. 5971 The IPsec implementation MUST fulfill the following iSCSI specific 5972 requirements: 5974 - HMAC-SHA1 MUST be implemented [RFC2404]. 5976 - AES CBC MAC with XCBC extensions SHOULD be implemented 5977 [RFC3566]. 5979 The ESP anti-replay service MUST also be implemented. 5981 At the high speeds iSCSI is expected to operate, a single IPsec SA 5982 could rapidly cycle through the 32-bit IPsec sequence number 5983 space. 5984 In view of this, an iSCSI implementation that operates at speeds 5985 of 1 Gbps or greater MUST implement the IPsec sequence number 5986 extension [RFC4303] and SHOULD use it on iSCSI connections. 5988 9.3.2. Confidentiality 5990 Confidentiality is provided by encrypting the data in every 5991 packet. When confidentiality is used it MUST be accompanied by 5992 data integrity and authentication to provide comprehensive 5993 protection against eavesdropping, message insertion, deletion, 5994 modification, and replaying. 5996 An iSCSI compliant initiator or target MUST provide 5997 confidentiality by implementing IPsec [RFC4301] with ESP [RFC4303] 5998 in tunnel mode and MAY provide confidentiality by implementing 5999 IPsec with ESP in transport mode, with the following iSCSI 6000 specific requirements: 6002 - 3DES in CBC mode MUST be implemented [RFC2451]. 6004 - AES in Counter mode SHOULD be implemented [RFC3686]. 6006 DES in CBC mode SHOULD NOT be used due to its inherent weakness. 6007 The NULL encryption algorithm MUST also be implemented. 6009 9.3.3. Policy, Security Associations, and Cryptographic Key 6010 Management 6012 A compliant iSCSI implementation MUST meet the cryptographic key 6013 management requirements of the IPsec protocol suite. 6014 Authentication, security association negotiation, and 6015 cryptographic key management MUST be provided by implementing IKE 6016 [RFC5996] using the IPsec DOI [RFC5996] with the following iSCSI 6017 specific requirements: 6019 - Peer authentication using a pre-shared cryptographic key 6020 MUST be supported. Certificate-based peer authentication 6021 using digital signatures MAY be supported. Peer 6023 authentication using the public key encryption methods 6024 outlined in IKE sections 5.2 and 5.3[7] SHOULD NOT be used. 6026 - When digital signatures are used to achieve authentication, 6027 an IKE negotiator SHOULD use IKE Certificate Request 6028 Payload(s) to specify the certificate authority. IKE 6029 negotiators SHOULD check the pertinent Certificate 6030 Revocation List (CRL) before accepting a PKI certificate for 6031 use in IKE authentication procedures. 6033 - Conformant iSCSI implementations MUST support IKE Main Mode 6034 and SHOULD support Aggressive Mode. IKE main mode with pre- 6035 shared key authentication method SHOULD NOT be used when 6036 either the initiator or the target uses dynamically assigned 6037 IP addresses. While in many cases pre-shared keys offer good 6038 security, situations in which dynamically assigned addresses 6039 are used force the use of a group pre-shared key, which 6040 creates vulnerability to a man-in-the-middle attack. 6042 - In the IKE Phase 2 Quick Mode, exchanges for creating the 6043 Phase 2 SA, the Identity Payload, fields MUST be present. 6044 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports 6045 IPv6) and ID_FQDN Identity payloads MUST be supported; 6046 ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address 6047 Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN formats SHOULD NOT 6048 be used. The ID_KEY_ID Identity Payload MUST NOT be used. 6050 Manual cryptographic keying MUST NOT be used because it does not 6051 provide the necessary re-keying support. 6053 When IPsec is used, the receipt of an IKE Phase 2 delete message 6054 SHOULD NOT be interpreted as a reason for tearing down the iSCSI 6055 TCP connection. If additional traffic is sent on it, a new IKE 6056 Phase 2 SA will be created to protect it. 6058 The method used by the initiator to determine whether the target 6059 should be connected using IPsec is regarded as an issue of IPsec 6060 policy administration, and thus not defined in the iSCSI standard. 6062 If an iSCSI target is discovered via a SendTargets request in a 6063 discovery session not using IPsec, the initiator should assume 6064 that it does not need IPsec to establish a session to that target. 6065 If an iSCSI target is discovered using a discovery session that 6066 does use IPsec, the initiator SHOULD use IPsec when establishing a 6067 session to that target. 6069 9.4. Security Considerations for the X#NodeArchitecture Key 6071 The security considerations in this section are specific to the 6072 X#NodeArchitecture discussed in Section 12.24 - 6073 "X#NodeArchitecture". 6075 This extension key transmits specific implementation details about 6076 the node that sends it; such details may be considered sensitive 6077 in some environments. For example, if a certain software or 6078 firmware version is known to contain security weaknesses, 6079 announcing the presence of that version via this key may not be 6080 desirable. The countermeasures for this security concern are: 6082 - sending less detailed information in the key values, 6083 - not sending the extension key, or 6084 - using IPsec ([RFC4303]) to provide confidentiality for 6085 the iSCSI connection on which the key is sent 6086 To support the first and second countermeasures, all 6087 implementations of this extension key MUST provide an 6088 administrative mechanism to disable sending the key. In addition, 6089 all implementations SHOULD provide an administrative mechanism to 6090 configure a verbosity level of the key value, thereby controlling 6091 the amount of information sent. 6093 For example, a lower verbosity might enable transmission of node 6094 architecture component names only, but no version numbers. The 6095 choice of which countermeasure is most appropriate depends on the 6096 environment. However, sending less detailed information in the key 6097 values may be an acceptable countermeasure in many environments, 6098 since it provides a compromise between sending too much 6099 information and the other more complete countermeasures of not 6100 sending the key at all or using IPsec. 6102 In addition to security considerations involving transmission of 6103 the key contents, any logging method(s) used for the key values 6104 MUST keep the information secure from intruders. For all 6105 implementations, the requirements to address this security concern 6106 are: 6108 - Display of the log MUST only be possible with administrative 6109 rights to the node. 6111 - Options to disable logging to disk and to keep logs for a 6112 fixed duration SHOULD be provided. 6114 Finally, it is important to note that different nodes may have 6115 different levels of risk, and these differences may affect the 6116 implementation. The components of risk include assets, threats, 6117 and vulnerabilities. Consider the following example iSCSI nodes, 6118 which demonstrate differences in assets and vulnerabilities of the 6119 nodes, and as a result, differences in implementation: 6121 One iSCSI target based on a special-purpose operating system: 6122 Since the iSCSI target controls access to the data storage 6123 containing company assets, the asset level is seen as very 6124 high. Also, because of the special-purpose operating 6125 system, in which vulnerabilities are less well-known, the 6126 vulnerability level is viewed as low. 6128 Multiple iSCSI initiators in a blade farm, each running a 6129 general purpose operating system: The asset level of each 6130 node is viewed as low, since blades are replaceable and low 6131 cost. However, the vulnerability level is viewed as high, 6132 since there may be many wellknown vulnerabilities to that 6133 general-purpose operating system. For this target, an 6134 appropriate implementation might be logging of received key 6135 values, but no transmission of the key. For this initiator, 6137 an appropriate implementation might be transmission of the 6138 key, but no logging of received key values. 6140 10. Notes to Implementers 6142 This section notes some of the performance and reliability 6143 considerations of the iSCSI protocol. This protocol was designed 6144 to allow efficient silicon and software implementations. The iSCSI 6145 task tag mechanism was designed to enable Direct Data Placement 6146 (DDP - a DMA form) at the iSCSI level or lower. 6148 The guiding assumption made throughout the design of this protocol 6149 is that targets are resource constrained relative to initiators. 6151 Implementers are also advised to consider the implementation 6152 consequences of the iSCSI to SCSI mapping model as outlined in 6153 Section 3.4.3 - "Consequences of the Model". 6155 10.1. Multiple Network Adapters 6157 The iSCSI protocol allows multiple connections, not all of which 6158 need to go over the same network adapter. If multiple network 6159 connections are to be utilized with hardware support, the iSCSI 6160 protocol command-data-status allegiance to one TCP connection 6161 ensures that there is no need to replicate information across 6162 network adapters or otherwise require them to cooperate. 6164 However, some task management commands may require some loose form 6165 of cooperation or replication at least on the target. 6167 10.1.1. Conservative Reuse of ISIDs 6169 Historically, the SCSI model (and implementations and applications 6170 based on that model) has assumed that SCSI ports are static, 6171 physical entities. Recent extensions to the SCSI model have taken 6172 advantage of persistent worldwide unique names for these ports. In 6173 iSCSI however, the SCSI initiator ports are the endpoints of 6174 dynamically created sessions, so the presumptions of "static and 6175 physical" do not apply. In any case, the model clauses 6176 (particularly, Section 3.4.2 - "SCSI Architecture Model") provide 6177 for persistent, reusable names for the iSCSI-type SCSI initiator 6178 ports even though there does not need to be any physical entity 6179 bound to these names. 6181 To both minimize the disruption of legacy applications and to 6182 better facilitate the SCSI features that rely on persistent names 6183 for SCSI ports, iSCSI implementations SHOULD attempt to provide a 6184 stable presentation of SCSI Initiator Ports (both to the upper OS- 6185 layers and to the targets to which they connect). This can be 6186 achieved in an initiator implementation by conservatively reusing 6187 ISIDs. In other words, the same ISID should be used in the Login 6188 process to multiple target portal groups (of the same iSCSI Target 6189 or different iSCSI Targets). The ISID RULE (Section 3.4.3 - 6190 "Consequences of the Model") only prohibits reuse to the same 6191 target portal group. It does not "preclude" reuse to other target 6192 portal groups. 6193 The principle of conservative reuse "encourages" reuse to other 6194 target portal groups. When a SCSI target device sees the same 6195 (InitiatorName, ISID) pair in different sessions to different 6196 target portal groups, it can identify the underlying SCSI 6197 Initiator Port on each session as the same SCSI port. In effect, 6198 it can recognize multiple paths from the same source. 6200 10.1.2. iSCSI Name, ISID, and TPGT Use 6202 The designers of the iSCSI protocol are aware that legacy SCSI 6203 transports rely on initiator identity to assign access to storage 6204 resources. Although newer techniques are available and simplify 6205 access control, support for configuration and authentication 6206 schemes that are based on initiator identity is deemed important 6207 in order to support legacy systems and administration software. 6208 iSCSI thus supports the notion that it should be possible to 6209 assign access to storage resources based on "initiator device" 6210 identity. 6212 When there are multiple hardware or software components 6213 coordinated as a single iSCSI Node, there must be some (logical) 6214 entity that represents the iSCSI Node that makes the iSCSI Node 6215 Name available to all components involved in session creation and 6216 login. Similarly, this entity that represents the iSCSI Node must 6217 be able to coordinate session identifier resources (ISID for 6218 initiators) to enforce both the ISID and TSIH RULES (see Section 6219 3.4.3 - "Consequences of the Model"). 6221 For targets, because of the closed environment, implementation of 6222 this entity should be straightforward. However, vendors of iSCSI 6223 hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide 6224 mechanisms for configuration of the iSCSI Node Name across the 6225 portal groups instantiated by multiple instances of these 6226 components within a target. 6228 However, complex targets making use of multiple Target Portal 6229 Group Tags may reconfigure them to achieve various quality goals. 6230 The initiators have two mechanisms at their disposal to discover 6231 and/or check reconfiguring targets - the discovery session type 6232 and a key returned by the target during login to confirm the TPGT. 6233 An initiator should attempt to "rediscover" the target 6234 configuration anytime a session is terminated unexpectedly. 6236 For initiators, in the long term, it is expected that operating 6237 system vendors will take on the role of this entity and provide 6238 standard APIs that can inform components of their iSCSI Node Name 6239 and can configure and/or coordinate ISID allocation, use, and 6240 reuse. 6242 Recognizing that such initiator APIs are not available today, 6243 other implementations of the role of this entity are possible. For 6244 example, a human may instantiate the (common) Node name as part of 6245 the installation process of each iSCSI component involved in 6246 session creation and login. This may be done either by pointing 6247 the component to a vendor-specific location for this datum or to a 6248 system-wide location. The structure of the ISID namespace (see 6249 Section 10.12.5 - "ISID" and [RFC3721]) facilitates implementation 6250 of the ISID coordination by allowing each component vendor to 6251 independently (of other vendor's components) coordinate 6252 allocation, use, and reuse of its own partition of the ISID 6253 namespace in a vendor-specific manner. Partitioning of the ISID 6254 namespace within initiator portal groups managed by that vendor 6255 allows each such initiator portal group to act independently of 6256 all other portal groups when selecting an ISID for a login; this 6257 facilitates enforcement of the ISID RULE (see Section 3.4.3 - 6258 "Consequences of the Model") at the initiator. 6260 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use 6261 in initiators MUST implement a mechanism for configuring the iSCSI 6262 Node Name. Vendors, and administrators must ensure that iSCSI Node 6263 Names are unique worldwide. It is therefore important that when 6264 one chooses to reuse the iSCSI Node Name of a disabled unit, not 6265 to re-assign that name to the original unit unless its worldwide 6266 uniqueness can be ascertained again. 6268 In addition, a vendor of iSCSI hardware must implement a mechanism 6269 to configure and/or coordinate ISIDs for all sessions managed by 6270 multiple instances of that hardware within a given iSCSI Node. 6271 Such configuration might be either permanently pre-assigned at the 6272 factory (in a necessarily globally unique way), statically 6273 assigned (e.g., partitioned across all the NICs at initialization 6274 in a locally unique way), or dynamically assigned (e.g., on-line 6275 allocator, also in a locally unique way). In the latter two cases, 6276 the configuration may be via public APIs (perhaps driven by an 6277 independent vendor's software, such as the OS vendor) or via 6278 private APIs driven by the vendor's own software. 6280 The process of name assignment and coordination has to be as 6281 encompassing and automated as possible as years of legacy usage 6282 have shown it to be highly error-prone. It is to be mentioned 6283 that SCSI has today alternative schemes of access control that can 6284 be used by all transports and their security is not dependent on 6285 strict naming coordination. 6287 10.2. Autosense and Auto Contingent Allegiance (ACA) 6289 Autosense refers to the automatic return of sense data to the 6290 initiator in case a command did not complete successfully. iSCSI 6291 initiators and targets MUST support and use autosense. 6293 ACA helps preserve ordered command execution in the presence of 6294 errors. As iSCSI can have many commands in-flight between 6295 initiator and target, iSCSI initiators and targets SHOULD support 6296 ACA. 6298 10.3. iSCSI Timeouts 6300 iSCSI recovery actions are often dependent on iSCSI time-outs 6301 being recognized and acted upon before SCSI time-outs. Determining 6302 the right time-outs to use for various iSCSI actions (command 6303 acknowledgements expected, status acknowledgements, etc.) is very 6304 much dependent on infrastructure (hardware, links, TCP/IP stack, 6305 iSCSI driver). As a guide, the implementer may use an average Nop- 6306 Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 6307 4) as a good estimate for the basic delay of the iSCSI stack for a 6308 given connection. The safety factor should account for the network 6309 load variability. For connection teardown the implementer may 6310 want to consider also TCP common practice for the given 6311 infrastructure. 6313 Text negotiations MAY also be subject to either time-limits or 6314 limits in the number of exchanges. Those SHOULD be generous enough 6315 to avoid affecting interoperability (e.g., allowing each key to be 6316 negotiated on a separate exchange). 6318 The relation between iSCSI timeouts and SCSI timeouts should also 6319 be considered. SCSI timeouts should be longer than iSCSI timeouts 6320 plus the time required for iSCSI recovery whenever iSCSI recovery 6321 is planned. Alternatively, an implementer may choose to interlock 6322 iSCSI timeouts and recovery with SCSI timeouts so that SCSI 6323 recovery will become active only where iSCSI is not planned to, or 6324 failed to, recover. 6326 The implementer may also want to consider the interaction between 6327 various iSCSI exception events - such as a digest failure - and 6328 subsequent timeouts. When iSCSI error recovery is active, a digest 6329 failure is likely to result in discovering a missing command or 6330 data PDU. In these cases, an implementer may want to lower the 6331 timeout values to enable faster initiation for recovery 6332 procedures. 6334 10.4. Command Retry and Cleaning Old Command Instances 6336 To avoid having old, retried command instances appear in a valid 6337 command window after a command sequence number wrap around, the 6338 protocol requires (see Section 3.2.2.1 - "Command Numbering and 6339 Acknowledging") that on every connection on which a retry has been 6340 issued, a non-immediate command be issued and acknowledged within 6341 a 2**31-1 commands interval from the CmdSN of the retried command. 6342 This requirement can be fulfilled by an implementation in several 6343 ways. 6345 The simplest technique to use is to send a (non-retry) non- 6346 immediate SCSI command (or a NOP if no SCSI command is available 6347 for a while) after every command retry on the connection on which 6348 the retry was attempted. As errors are deemed rare events, this 6349 technique is probably the most effective, as it does not involve 6350 additional checks at the initiator when issuing commands. 6352 10.5. Synch and Steering Layer and Performance 6354 While a synch and steering layer is optional, an initiator/target 6355 that does not have it working against a target/initiator that 6356 demands synch and steering may experience performance degradation 6357 caused by packet reordering and loss. Providing a synch and 6358 steering mechanism is recommended for all high-speed 6359 implementations. 6361 10.6. Considerations for State-dependent Devices and Long-lasting 6362 SCSI Operations 6364 Sequential access devices operate on the principle that the 6365 position of the device is based on the last command processed. As 6366 such, command processing order and knowledge of whether or not the 6367 previous command was processed is of the utmost importance to 6368 maintain data integrity. For example, inadvertent retries of SCSI 6369 commands when it is not known if the previous SCSI command was 6370 processed is a potential data integrity risk. 6372 For a sequential access device, consider the scenario in which a 6373 SCSI SPACE command to backspace one filemark is issued and then 6374 re-issued due to no status received for the command. If the first 6375 SPACE command was actually processed, the re-issued SPACE command, 6376 if processed, will cause the position to change. Thus, a 6377 subsequent write operation will write data to the wrong position 6378 and any previous data at that position will be overwritten. 6380 For a medium changer device, consider the scenario in which an 6381 EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION 6382 ADDRESS are the same thus performing a swap) is issued and then 6383 re-issued due to no status received for the command. If the first 6384 EXCHANGE MEDIUM command was actually processed, the re-issued 6385 EXCHANGE MEDIUM command, if processed, will perform the swap 6386 again. The net effect is no swap was performed thus leaving a data 6387 integrity exposure. 6389 All commands that change the state of the device (as in SPACE 6390 commands for sequential access devices, and EXCHANGE MEDIUM for 6391 medium changer device), MUST be issued as non-immediate commands 6392 for deterministic and in order delivery to iSCSI targets. 6394 For many of those state changing commands, the execution model 6395 also assumes that the command is executed exactly once. Devices 6396 implementing READ POSITION and LOCATE provide a means for SCSI 6397 level command recovery and new tape-class devices 6398 should support those commands. In their absence a retry at SCSI 6399 level is difficult and error recovery at iSCSI level is advisable. 6401 Devices operating on long latency delivery subsystems and 6402 performing long lasting SCSI operations may need mechanisms that 6403 enable connection replacement while commands are running (e.g., 6404 during an extended copy operation). 6406 10.6.1. Determining the Proper ErrorRecoveryLevel 6408 The implementation and use of a specific ErrorRecoveryLevel should 6409 be determined based on the deployment scenarios of a given iSCSI 6410 implementation. Generally, the following factors must be 6411 considered before deciding on the proper level of recovery: 6413 Application resilience to I/O failures. 6414 Required level of availability in the face of transport 6415 connection failures. 6416 Probability of transport layer "checksum escape". This in turn 6417 decides the iSCSI digest failure frequency, and thus the 6418 criticality of iSCSI-level error recovery. The details of 6419 estimating this probability are outside the scope of this 6420 document. 6422 A consideration of the above factors for SCSI tape devices as an 6423 example suggests that implementations SHOULD use 6424 ErrorRecoveryLevel=1 when transport connection failure is not a 6425 concern and SCSI level recovery is unavailable, and 6426 ErrorRecoveryLevel=2 when the connection failure is also of high 6427 likelihood during a backup/retrieval. 6429 For extended copy operations, implementations SHOULD use 6430 ErrorRecoveryLevel=2 whenever there is a relatively high 6431 likelihood of connection failure. 6433 10.7. Multi-task Abort Implementation Considerations 6435 Multi-task abort operations are typically issued in emergencies - 6436 such as clearing a device lock-up, HA failover/failback etc. In 6437 these circumstances, it is desirable to rapidly go through the 6438 error handling process as opposed to the target waiting on 6439 multiple third-party initiators who may not even be functional 6440 anymore - especially if this emergency is triggered because of one 6441 such initiator failure. Therefore, both iSCSI target and 6442 initiator implementations SHOULD support FastAbort multi-task 6443 abort semantics (Section 4.2.3.4). 6445 Note that both in standard semantics (Section 4.2.3.3) and 6446 FastAbort semantics (Section 4.2.3.4), there may be outstanding 6447 data transfers even after the TMF completion is reported on the 6448 issuing session. In the case of iSCSI/iSER [iSER], these would be 6449 tagged data transfers for STags not owned by any active tasks. 6450 Whether or not real buffers support these data transfers is 6451 implementation-dependent. However, the data transfers logically 6452 MUST be silently discarded by the target iSCSI layer in all cases. 6453 A target MAY, on an implementation-defined internal timeout, also 6454 choose to drop the connections on which it did not receive the 6455 expected Data-Out sequences (Section 4.2.3.3) or NOP-Out 6456 acknowledgements (Section 4.2.3.4) so as to reclaim the associated 6457 buffer, STag, and TTT resources as appropriate. 6459 11. iSCSI PDU Formats 6461 All multi-byte integers that are specified in formats defined in 6462 this document are to be represented in network byte order (i.e., 6463 big endian). Any field that appears in this document assumes that 6464 the most significant byte is the lowest numbered byte and the most 6465 significant bit (within byte or field) is the lowest numbered bit 6466 unless specified otherwise. 6468 Any compliant sender MUST set all bits not defined and all 6469 reserved fields to zero unless specified otherwise. Any compliant 6470 receiver MUST ignore any bit not defined and all reserved fields 6471 unless specified otherwise. Receipt of reserved code values in 6472 defined fields MUST be reported as a protocol error. 6474 Reserved fields are marked by the word "reserved", some 6475 abbreviation of "reserved", or by "." for individual bits when no 6476 other form of marking is technically feasible. 6478 11.1. iSCSI PDU Length and Padding 6480 iSCSI PDUs are padded to the closest integer number of four byte 6481 words. The padding bytes SHOULD be sent as 0. 6483 11.2. PDU Template, Header, and Opcodes 6485 All iSCSI PDUs have one or more header segments and, optionally, a 6486 data segment. After the entire header segment group a header- 6487 digest MAY follow. The data segment MAY also be followed by a 6488 data-digest. 6490 The Basic Header Segment (BHS) is the first segment in all of the 6491 iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It 6492 MAY be followed by Additional Header Segments (AHS), a Header- 6493 Digest, a Data Segment, and/or a Data-Digest. 6495 The overall structure of an iSCSI PDU is as follows: 6497 Byte/ 0 | 1 | 2 | 3 | 6498 / | | | | 6499 |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| 6500 +---------------+---------------+---------------+--------------+ 6501 0/ Basic Header Segment (BHS) / 6502 +/ / 6503 +---------------+---------------+---------------+--------------+ 6504 48/ Additional Header Segment 1 (AHS) (optional) / 6505 +/ / 6506 +---------------+---------------+---------------+--------------+ 6507 / Additional Header Segment 2 (AHS) (optional) / 6508 +/ / 6509 +---------------+---------------+---------------+--------------+ 6510 ---- 6511 +---------------+---------------+---------------+--------------+ 6512 / Additional Header Segment n (AHS) (optional) / 6513 +/ / 6514 +---------------+---------------+---------------+--------------+ 6515 ---- 6516 +---------------+---------------+---------------+--------------+ 6517 k/ Header-Digest (optional) / 6518 +/ / 6519 +---------------+---------------+---------------+--------------+ 6520 l/ Data Segment(optional) / 6521 +/ / 6522 +---------------+---------------+---------------+--------------+ 6523 m/ Data-Digest (optional) / 6524 +/ / 6525 +---------------+---------------+---------------+--------------+ 6527 All PDU segments and digests are padded to the closest integer 6528 number of four byte words. For example, all PDU segments and 6529 digests start at a four byte word boundary and the padding ranges 6530 from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. 6532 iSCSI response PDUs do not have AH Segments. 6534 11.2.1. Basic Header Segment (BHS) 6536 The BHS is 48 bytes long. The Opcode and DataSegmentLength fields 6537 appear in all iSCSI PDUs. In addition, when used, the Initiator 6538 Task Tag and Logical Unit Number always appear in the same 6539 location in the header. 6541 The format of the BHS is: 6543 Byte/ 0 | 1 | 2 | 3 | 6544 / | | | | 6545 |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| 6546 +---------------+---------------+---------------+--------------+ 6547 0|.|I| Opcode |F| Opcode-specific fields | 6548 +---------------+---------------+---------------+--------------+ 6549 4|TotalAHSLength | DataSegmentLength | 6550 +---------------+---------------+---------------+--------------+ 6551 8| LUN or Opcode-specific fields | 6552 + + 6553 12| | 6554 +---------------+---------------+---------------+--------------+ 6555 16| Initiator Task Tag | 6556 +---------------+---------------+---------------+--------------+ 6557 20/ Opcode-specific fields / 6558 +/ / 6559 +---------------+---------------+---------------+--------------+ 6560 48 6562 11.2.1.1. I 6564 For request PDUs, the I bit set to 1 is an immediate delivery 6565 marker. 6567 11.2.1.2. Opcode 6569 The Opcode indicates the type of iSCSI PDU the header 6570 encapsulates. 6572 The Opcodes are divided into two categories: initiator opcodes and 6573 target opcodes. Initiator opcodes are in PDUs sent by the 6574 initiator (request PDUs). Target opcodes are in PDUs sent by the 6575 target (response PDUs). 6577 Initiators MUST NOT use target opcodes and targets MUST NOT use 6578 initiator opcodes. 6580 Initiator opcodes defined in this specification are: 6582 0x00 NOP-Out 6584 0x01 SCSI Command (encapsulates a SCSI Command Descriptor 6585 Block) 6587 0x02 SCSI Task Management function request 6589 0x03 Login Request 6591 0x04 Text Request 6593 0x05 SCSI Data-out (for WRITE operations) 6595 0x06 Logout Request 6597 0x10 SNACK Request 6599 0x1c-0x1e Vendor specific codes 6601 Target opcodes are: 6603 0x20 NOP-In 6605 0x21 SCSI Response - contains SCSI status and possibly sense 6606 information or other response information. 6608 0x22 SCSI Task Management function response 6610 0x23 Login Response 6612 0x24 Text Response 6614 0x25 SCSI Data-in - for READ operations. 6616 0x26 Logout Response 6617 0x31 Ready To Transfer (R2T) - sent by target when it is ready 6618 to receive data. 6620 0x32 Asynchronous Message - sent by target to indicate certain 6621 special conditions. 6623 0x3c-0x3e Vendor specific codes 6625 0x3f Reject 6627 All other opcodes are reserved. 6629 11.2.1.3. Final (F) bit 6631 When set to 1 it indicates the final (or only) PDU of a sequence. 6633 11.2.1.4. Opcode-specific Fields 6635 These fields have different meanings for different opcode types. 6637 11.2.1.5. TotalAHSLength 6639 Total length of all AHS header segments in units of four byte 6640 words including padding, if any. 6642 The TotalAHSLength is only used in PDUs that have an AHS and MUST 6643 be 0 in all other PDUs. 6645 11.2.1.6. DataSegmentLength 6647 This is the data segment payload length in bytes (excluding 6648 padding). The DataSegmentLength MUST be 0 whenever the PDU has no 6649 data segment. 6651 11.2.1.7. LUN 6653 Some opcodes operate on a specific Logical Unit. The Logical Unit 6654 Number (LUN) field identifies which Logical Unit. If the opcode 6655 does not relate to a Logical Unit, this field is either ignored or 6656 may be used in an opcode specific way. The LUN field is 64-bits 6657 and should be formatted in accordance with [SAM2]. For example, 6658 LUN[0] from [SAM2] is BHS byte 8 and so on up to LUN[7] from 6659 [SAM2], which is BHS byte 15. 6661 11.2.1.8. Initiator Task Tag 6663 The initiator assigns a Task Tag to each iSCSI task it issues. 6664 While a task exists, this tag MUST uniquely identify the task 6665 session-wide. SCSI may also use the initiator task tag as part of 6666 the SCSI task identifier when the timespan during which an iSCSI 6667 initiator task tag must be unique extends over the timespan during 6668 which a SCSI task tag must be unique. However, the iSCSI Initiator 6669 Task Tag must exist and be unique even for untagged SCSI commands. 6671 An ITT value of 0xffffffff is reserved and MUST NOT be assigned 6672 for a task by the initiator. The only instance in which it may be 6673 seen on the wire is in a target-initiated NOP-In PDU (Section 6674 11.19) and in the initiator response to that PDU, if necessary. 6676 11.2.2. Additional Header Segment (AHS) 6678 The general format of an AHS is: 6680 Byte/ 0 | 1 | 2 | 3 | 6681 / | | | | 6682 |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| 6683 +---------------+---------------+---------------+--------------+ 6684 0| AHSLength | AHSType | AHS-Specific | 6685 +---------------+---------------+---------------+--------------+ 6686 4/ AHS-Specific / 6687 +/ / 6688 +---------------+---------------+---------------+--------------+ 6689 x 6691 11.2.2.1. AHSType 6693 The AHSType field is coded as follows: 6695 bit 0-1 - Reserved 6697 bit 2-7 - AHS code 6699 0 - Reserved 6700 1 - Extended CDB 6702 2 - Expected Bidirectional Read Data Length 6704 3 - 63 Reserved 6706 11.2.2.2. AHSLength 6708 This field contains the effective length in bytes of the AHS 6709 excluding AHSType and AHSLength and padding, if any. The AHS is 6710 padded to the smallest integer number of 4 byte words (i.e., from 6711 0 up to 3 padding bytes). 6713 11.2.2.3. Extended CDB AHS 6715 The format of the Extended CDB AHS is: 6717 Byte/ 0 | 1 | 2 | 3 | 6718 / | | | | 6719 |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| 6720 +---------------+---------------+---------------+--------------+ 6721 0| AHSLength (CDBLength-15) | 0x01 | Reserved | 6722 +---------------+---------------+---------------+--------------+ 6723 4/ ExtendedCDB...+padding / 6724 +/ / 6725 +---------------+---------------+---------------+--------------+ 6726 x 6728 This type of AHS MUST NOT be used if the CDBLength is less than 6729 17. 6730 The length includes the reserved byte 3. 6732 11.2.2.4. Bidirectional Expected Read-Data Length AHS 6734 The format of the Bidirectional Read Expected Data Transfer Length 6735 AHS is: 6737 Byte/ 0 | 1 | 2 | 3 | 6738 / | | | | 6739 |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| 6740 +---------------+---------------+---------------+--------------+ 6741 0| AHSLength (0x0005) | 0x02 | Reserved | 6742 +---------------+---------------+---------------+--------------+ 6743 4| Expected Read-Data Length | 6744 +---------------+---------------+---------------+--------------+ 6745 8 6747 11.2.3. Header Digest and Data Digest 6749 Optional header and data digests protect the integrity of the 6750 header and data, respectively. The digests, if present, are 6751 located, respectively, after the header and PDU-specific data, and 6752 cover respectively the header and the PDU data, each including 6753 the padding bytes, if any. 6755 The existence and type of digests are negotiated during the Login 6756 Phase. 6758 The separation of the header and data digests is useful in iSCSI 6759 routing applications, in which only the header changes when a 6760 message is forwarded. In this case, only the header digest should 6761 be recalculated. 6763 Digests are not included in data or header length fields. 6765 A zero-length Data Segment also implies a zero-length data-digest. 6767 11.2.4. Data Segment 6769 The (optional) Data Segment contains PDU associated data. Its 6770 payload effective length is provided in the BHS field - 6771 DataSegmentLength. The Data Segment is also padded to an integer 6772 number of 4 byte words. 6774 11.3. SCSI Command 6776 The format of the SCSI Command PDU is: 6778 Byte/ 0 | 1 | 2 | 3 | 6779 / | | | | 6780 |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| 6781 +---------------+---------------+---------------+--------------+ 6782 0|.|I| 0x01 |F|R|W|. .|ATTR | Reserved | 6783 +---------------+---------------+---------------+--------------+ 6784 4|TotalAHSLength | DataSegmentLength | 6785 +---------------+---------------+---------------+--------------+ 6786 8| Logical Unit Number (LUN) | 6787 + + 6788 12| | 6789 +---------------+---------------+---------------+--------------+ 6790 16| Initiator Task Tag | 6791 +---------------+---------------+---------------+--------------+ 6792 20| Expected Data Transfer Length | 6793 +---------------+---------------+---------------+--------------+ 6794 24| CmdSN | 6795 +---------------+---------------+---------------+--------------+ 6796 28| ExpStatSN | 6797 +---------------+---------------+---------------+--------------+ 6798 32/ SCSI Command Descriptor Block (CDB) / 6799 +/ / 6800 +---------------+---------------+---------------+--------------+ 6801 48/ AHS (Optional) / 6802 +---------------+---------------+---------------+--------------+ 6803 x/ Header Digest (Optional) / 6804 +---------------+---------------+---------------+--------------+ 6805 y/ (DataSegment, Command Data) (Optional) / 6806 +/ / 6807 +---------------+---------------+---------------+--------------+ 6808 z/ Data Digest (Optional) / 6809 +---------------+---------------+---------------+--------------+ 6811 11.3.1. Flags and Task Attributes (byte 1) 6813 The flags for a SCSI Command are: 6815 bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs 6816 follow this PDU. When F=1 for a write and if Expected Data 6817 Transfer Length is larger than the DataSegmentLength, the 6818 target may solicit additional data through R2T. 6820 bit 1 (R) is set to 1 when the command is expected to input 6821 data. 6823 bit 2 (W) is set to 1 when the command is expected to output 6824 data. 6826 bit 3-4 Reserved. 6828 bit 5-7 contains Task Attributes. 6830 Task Attributes (ATTR) have one of the following integer values 6831 (see [SAM2] for details): 6833 0 - Untagged 6835 1 - Simple 6837 2 - Ordered 6839 3 - Head of Queue 6841 4 - ACA 6843 5-7 - Reserved 6845 Setting both the W and the F bit to 0 is an error. 6846 Either or both of R and W MAY be 1 when either the Expected Data 6847 Transfer Length and/or Bidirectional Read Expected Data Transfer 6848 Length are 0, but they MUST NOT both be 0 when the Expected Data 6849 Transfer Length and/or Bidirectional Read Expected Data Transfer 6850 Length are not 0 (i.e., when some data transfer is expected the 6851 transfer direction is indicated by the R and/or W bit). 6853 11.3.2. CmdSN - Command Sequence Number 6855 Enables ordered delivery across multiple connections in a single 6856 session. 6858 11.3.3. ExpStatSN 6860 Command responses up to ExpStatSN-1 (mod 2**32) have been received 6861 (acknowledges status) on the connection. 6863 11.3.4. Expected Data Transfer Length 6865 For unidirectional operations, the Expected Data Transfer Length 6866 field contains the number of bytes of data involved in this SCSI 6867 operation. For a unidirectional write operation (W flag set to 1 6868 and R flag set to 0), the initiator uses this field to specify the 6869 number of bytes of data it expects to transfer for this operation. 6870 For a unidirectional read operation (W flag set to 0 and R flag 6871 set to 1), the initiator uses this field to specify the number of 6872 bytes of data it expects the target to transfer to the initiator. 6873 It corresponds to the SAM2 byte count. 6875 For bidirectional operations (both R and W flags are set to 1), 6876 this field contains the number of data bytes involved in the write 6877 transfer. For bidirectional operations, an additional header 6878 segment MUST be present in the header sequence that indicates the 6879 Bidirectional Read Expected Data Transfer Length. The Expected 6880 Data Transfer Length field and the Bidirectional Read Expected 6881 Data Transfer Length field correspond to the SAM2 byte count. 6883 If the Expected Data Transfer Length for a write and the length of 6884 the immediate data part that follows the command (if any) are the 6885 same, then no more data PDUs are expected to follow. In this 6886 case, the F bit MUST be set to 1. 6888 If the Expected Data Transfer Length is higher than the 6889 FirstBurstLength (the negotiated maximum amount of unsolicited 6890 data the target will accept), the initiator MUST send the maximum 6891 amount of unsolicited data OR ONLY the immediate data, if any. 6893 Upon completion of a data transfer, the target informs the 6894 initiator (through residual counts) of how many bytes were 6895 actually processed (sent and/or received) by the target. 6897 11.3.5. CDB - SCSI Command Descriptor Block 6899 There are 16 bytes in the CDB field to accommodate the commonly 6900 used CDBs. Whenever the CDB is larger than 16 bytes, an Extended 6901 CDB AHS MUST be used to contain the CDB spillover. 6903 11.3.6. Data Segment - Command Data 6905 Some SCSI commands require additional parameter data to accompany 6906 the SCSI command. This data may be placed beyond the boundary of 6907 the iSCSI header in a data segment. Alternatively, user data 6908 (e.g., from a WRITE operation) can be placed in the data segment 6909 (both cases are referred to as immediate data). These data are 6910 governed by the rules for solicited vs. unsolicited data outlined 6911 in Section 3.2.4.2 - "Data Transfer Overview". 6913 11.4. SCSI Response 6915 The format of the SCSI Response PDU is: 6917 Byte/ 0 | 1 | 2 | 3 | 6918 / | | | | 6919 |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| 6920 +---------------+---------------+---------------+--------------+ 6921 0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status | 6922 +---------------+---------------+---------------+--------------+ 6923 4|TotalAHSLength | DataSegmentLength | 6924 +---------------+---------------+---------------+--------------+ 6925 8| Reserved | 6926 + + 6927 12| | 6928 +---------------+---------------+---------------+--------------+ 6929 16| Initiator Task Tag | 6930 +---------------+---------------+---------------+--------------+ 6931 20| SNACK Tag or Reserved | 6932 +---------------+---------------+---------------+--------------+ 6933 24| StatSN | 6934 +---------------+---------------+---------------+--------------+ 6935 28| ExpCmdSN | 6936 +---------------+---------------+---------------+--------------+ 6937 32| MaxCmdSN | 6938 +---------------+---------------+---------------+--------------+ 6939 36| ExpDataSN or Reserved | 6940 +---------------+---------------+---------------+--------------+ 6941 40| Bidirectional Read Residual Count or Reserved | 6942 +---------------+---------------+---------------+--------------+ 6943 44| Residual Count or Reserved | 6944 +---------------+---------------+---------------+--------------+ 6945 48| Header-Digest (Optional) | 6946 +---------------+---------------+---------------+--------------+ 6947 / Data Segment (Optional) / 6948 +/ / 6949 +---------------+---------------+---------------+--------------+ 6950 | Data-Digest (Optional) | 6951 +---------------+---------------+---------------+--------------+ 6953 11.4.1. Flags (byte 1) 6955 bit 1-2 Reserved. 6957 bit 3 - (o) set for Bidirectional Read Residual Overflow. In 6958 this case, the Bidirectional Read Residual Count indicates 6959 the number of bytes that were not transferred to the 6960 initiator because the initiator's Expected Bidirectional 6961 Read Data Transfer Length was not sufficient. 6963 bit 4 - (u) set for Bidirectional Read Residual Underflow. In 6964 this case, the Bidirectional Read Residual Count indicates 6965 the number of bytes that were not transferred to the 6966 initiator out of the number of bytes expected to be 6967 transferred. 6969 bit 5 - (O) set for Residual Overflow. In this case, the 6970 Residual Count indicates the number of bytes that were not 6971 transferred because the initiator's Expected Data Transfer 6972 Length was not sufficient. For a bidirectional operation, 6973 the Residual Count contains the residual for the write 6974 operation. 6976 bit 6 - (U) set for Residual Underflow. In this case, the 6977 Residual Count indicates the number of bytes that were not 6978 transferred out of the number of bytes that were expected to 6979 be transferred. For a bidirectional operation, the Residual 6980 Count contains the residual for the write operation. 6982 bit 7 - (0) Reserved. 6984 Bits O and U and bits o and u are mutually exclusive (i.e., having 6985 both o and u or O and U set to 1 is a protocol error). 6986 For a response other than "Command Completed at Target", bits 3-6 6987 MUST be 0. 6989 11.4.2. Status 6991 The Status field is used to report the SCSI status of the command 6992 (as specified in [SAM2]) and is only valid if the Response Code is 6993 Command Completed at target. 6995 Some of the status codes defined in [SAM2] are: 6997 0x00 GOOD 6998 0x02 CHECK CONDITION 7000 0x08 BUSY 7002 0x18 RESERVATION CONFLICT 7004 0x28 TASK SET FULL 7006 0x30 ACA ACTIVE 7008 0x40 TASK ABORTED 7010 See [SAM2] for the complete list and definitions. 7012 If a SCSI device error is detected while data from the initiator 7013 is still expected (the command PDU did not contain all the data 7014 and the target has not received a Data PDU with the final bit 7015 Set), the target MUST wait until it receives a Data PDU with the F 7016 bit set in the last expected sequence before sending the Response 7017 PDU. 7019 11.4.3. Response 7021 This field contains the iSCSI service response. 7023 iSCSI service response codes defined in this specification are: 7025 0x00 - Command Completed at Target 7027 0x01 - Target Failure 7029 0x80-0xff - Vendor specific 7031 All other response codes are reserved. 7033 The Response is used to report a Service Response. The mapping of 7034 the response code into a SCSI service response code value, if 7035 needed, is outside the scope of this document. However, in 7036 symbolic terms response value 0x00 maps to the SCSI service 7037 response (see [SAM2] and [SPC3]) of TASK COMPLETE or LINKED 7038 COMMAND COMPLETE. All other Response values map to the SCSI 7039 service response of SERVICE DELIVERY OR TARGET FAILURE. 7041 If a SCSI Response PDU does not arrive before the session is 7042 terminated, the SCSI service response is SERVICE DELIVERY OR 7043 TARGET FAILURE. 7045 A non-zero response field indicates a failure to execute the 7046 command in which case the Status and Flag fields are undefined. 7048 11.4.4. SNACK Tag 7050 This field contains a copy of the SNACK Tag of the last SNACK Tag 7051 accepted by the target on the same connection and for the command 7052 for which the response is issued. Otherwise it is reserved and 7053 should be set to 0. 7055 After issuing a R-Data SNACK the initiator must discard any SCSI 7056 status unless contained in an SCSI Response PDU carrying the same 7057 SNACK Tag as the last issued R-Data SNACK for the SCSI command on 7058 the current connection. 7060 For a detailed discussion on R-Data SNACK see SNACK. 7062 11.4.5. Residual Count 7064 11.4.5.1. Field Semantics 7066 The Residual Count field MUST be valid in the case where either 7067 the U bit or the O bit is set. If neither bit is set, the Residual 7068 Count field is reserved. Targets may set the residual count and 7069 initiators may use it when the response code is "completed at 7070 target" (even if the status returned is not GOOD). If the O bit is 7071 set, the Residual Count indicates the number of bytes that were 7072 not transferred because the initiator's Expected Data Transfer 7073 Length was not sufficient. If the U bit is set, the Residual Count 7074 indicates the number of bytes that were not transferred out of the 7075 number of bytes expected to be transferred. 7077 11.4.5.2. Residuals Concepts Overview 7079 SCSI-Presented Data Transfer Length (SPDTL) is the term this 7080 document uses (see Section 1.1 for definition) to represent the 7081 aggregate data length that the target SCSI layer attempts to 7082 transfer using the local iSCSI layer for a task. Expected Data 7083 Transfer Length (EDTL) is the iSCSI term that represents the 7084 length of data that the iSCSI layer expects to transfer for a 7085 task. EDTL is specified in the SCSI Command PDU. 7087 When SPDTL = EDTL for a task, the target iSCSI layer completes the 7088 task with no residuals. Whenever SPDTL differs from EDTL for a 7089 task, that task is said to have a residual. 7091 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the 7092 SCSI Response PDU as specified in Section 11.4.5.1. The Residual 7093 Count MUST be set to the numerical value of (SPDTL - EDTL). 7095 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in 7096 the SCSI Response PDU as specified in Section 11.4.5.1. The 7097 Residual Count MUST be set to the numerical value of (EDTL - 7098 SPDTL). 7100 Note that the Overflow and Underflow scenarios are independent of 7101 Data-In and Data-Out. Either scenario is logically possible in 7102 either direction of data transfer. 7104 11.4.5.3. SCSI REPORT LUNS and Residual Overflow 7106 This section discusses the residual overflow issues citing the 7107 example of the SCSI REPORT LUNS command. Note however that there 7108 are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH 7109 fields following the same underlying rules. The semantics in the 7110 rest of the section apply to all such SCSI commands. 7112 The specification of the SCSI REPORT LUNS command requires that 7113 the SCSI target limit the amount of data transferred to a maximum 7114 size (ALLOCATION LENGTH) provided by the initiator in the REPORT 7115 LUNS CDB. 7117 If the Expected Data Transfer Length (EDTL) in the iSCSI header of 7118 the SCSI Command PDU for a REPORT LUNS command is set to at least 7119 as large as that ALLOCATION LENGTH, the SCSI layer truncation 7120 prevents an iSCSI Residual Overflow from occurring. A SCSI 7121 initiator can detect that such truncation has occurred via other 7122 information at theS CSI layer. The rest of the section elaborates 7123 this required behavior. 7125 The SCSI REPORT LUNS command requests a target SCSI layer to 7126 return a logical unit inventory (LUN list) to the initiator SCSI 7127 layer (see Section 6.21 of [SPC3]). The size of this LUN list may 7128 not be known to the initiator SCSI layer when it issues the REPORT 7129 LUNS command; to avoid transferring more LUN list data than the 7130 initiator is prepared for, the REPORT LUNS CDB contains an 7131 ALLOCATION LENGTH field to specify the maximum amount of data to 7132 be transferred to the initiator for this command. If the initiator 7133 SCSI layer has underestimated the number of logical units at the 7134 target, it is possible that the complete logical unit inventory 7135 does not fit in the specified ALLOCATION LENGTH. In this 7136 situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI 7137 layer "shall terminate transfers to the Data-In Buffer" when the 7138 number of bytes specified by the ALLOCATION LENGTH field have been 7139 transferred. 7141 Therefore, in response to a REPORT LUNS command, the SCSI layer at 7142 the target presents at most ALLOCATION LENGTH bytes of data 7143 (logical unit inventory) to iSCSI for transfer to the initiator. 7144 For a REPORT LUNS command, if the iSCSI EDTL is at least as large 7145 as the ALLOCATION LENGTH, the SCSI truncation ensures that the 7146 EDTL will accommodate all of the data to be transferred. If all of 7147 the logical unit inventory data presented to the iSCSI layer -- 7148 i.e., the data remaining after any SCSI truncation -- is 7149 transferred to the initiator by the iSCSI layer, an iSCSI Residual 7150 Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in 7151 the SCSI Response or final SCSI Data-Out PDU. Note that this 7152 behavior is implied by the combination of Section 11.4.5.1 along 7153 with the specification of the REPORT LUNS command in [SPC3]. 7154 However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in 7155 this scenario, note that the iSCSI Underflow MUST be signaled in 7156 the SCSI Response PDU. An iSCSI Underflow MUST also be signaled 7157 when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the 7158 logical unit inventory data presented to the iSCSI layer is 7159 smaller than the ALLOCATION LENGTH. 7161 The LUN LIST LENGTH field in the logical unit inventory (the first 7162 field in the inventory) is not affected by truncation of the 7163 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 7164 initiator to determine that the received inventory is incomplete 7165 by noticing that the LUN LIST LENGTH in the inventory is larger 7166 than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A 7167 common initiator behavior in this situation is to re-issue the 7168 REPORT LUNS command with a larger ALLOCATION LENGTH. 7170 11.4.6. Bidirectional Read Residual Count 7172 The Bidirectional Read Residual Count field MUST be valid in the 7173 case where either the u bit or the o bit is set. If neither bit is 7174 set, the Bidirectional Read Residual Count field is reserved. 7175 Targets may set the Bidirectional Read Residual Count and 7176 initiators may use it when the response code is "completed at 7177 target". If the o bit is set, the Bidirectional Read Residual 7178 Count indicates the number of bytes that were not transferred to 7179 the initiator because the initiator's Expected Bidirectional Read 7180 Transfer Length was not sufficient. If the u bit is set, the 7181 Bidirectional Read Residual Count indicates the number of bytes 7182 that were not transferred to the initiator out of the number of 7183 bytes expected to be transferred. 7185 11.4.7. Data Segment - Sense and Response Data Segment 7187 iSCSI targets MUST support and enable autosense. If Status is 7188 CHECK CONDITION (0x02), then the Data Segment MUST contain sense 7189 data for the failed command. 7191 For some iSCSI responses, the response data segment MAY contain 7192 some response related information, (e.g., for a target failure, it 7193 may contain a vendor specific detailed description of the 7194 failure). 7196 If the DataSegmentLength is not 0, the format of the Data Segment 7197 is as follows: 7199 Byte/ 0 | 1 | 2 | 3 | 7200 / | | | | 7201 |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| 7202 +---------------+---------------+---------------+--------------+ 7203 0|SenseLength | Sense Data | 7204 +---------------+---------------+---------------+--------------+ 7205 x/ Sense Data / 7206 +---------------+---------------+---------------+--------------+ 7207 y/ Response Data / 7208 / / 7209 +---------------+---------------+---------------+--------------+ 7210 z| 7211 11.4.7.1. SenseLength 7213 Length of Sense Data. 7215 11.4.7.2. Sense Data 7217 The Sense Data contains detailed information about a check 7218 condition and [SPC3] specifies the format and content of the Sense 7219 Data. 7221 Certain iSCSI conditions result in the command being terminated at 7222 the target (response Command Completed at Target) with a SCSI 7223 Check Condition Status as outlined in the next table: 7225 +--------------------------+----------+--------------------------+ 7226 | iSCSI Condition |Sense | Additional Sense Code & | 7227 | |Key | Qualifier | 7228 +--------------------------+----------+--------------------------+ 7229 | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c | 7230 | data |Command-0B| Write Error | 7231 +--------------------------+----------+--------------------------+ 7232 | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d | 7233 | |Command-0B| Write Error | 7234 +--------------------------+----------+--------------------------+ 7235 | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 | 7236 | error |Command-0B| CRC Error Detected | 7237 +--------------------------+----------+--------------------------+ 7238 | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 | 7239 | |Command-0B| Read Error | 7240 +--------------------------+----------+--------------------------+ 7242 The target reports the "Incorrect amount of data" condition if 7243 during data output the total data length to output is greater than 7244 FirstBurstLength and the initiator sent unsolicited non-immediate 7245 data but the total amount of unsolicited data is different than 7246 FirstBurstLength. The target reports the same error when the 7247 amount of data sent as a reply to an R2T does not match the amount 7248 requested. 7250 11.4.8. ExpDataSN 7252 The number of Data-In (read) PDUs the target has sent for the 7253 command. 7255 This field MUST be 0 if the response code is not Command Completed 7256 at Target or the target sent no Data-In PDUs for the command. 7257 11.4.9. StatSN - Status Sequence Number 7259 StatSN is a Sequence Number that the target iSCSI layer generates 7260 per connection and that in turn, enables the initiator to 7261 acknowledge status reception. StatSN is incremented by 1 for every 7262 response/status sent on a connection except for responses sent as 7263 a result of a retry or SNACK. In the case of responses sent due to 7264 a retransmission request, the StatSN MUST be the same as the first 7265 time the PDU was sent unless the connection has since been 7266 restarted. 7268 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator 7270 ExpCmdSN is a Sequence Number that the target iSCSI returns to the 7271 initiator to acknowledge command reception. It is used to update a 7272 local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1 7273 indicates that the target cannot accept new commands. 7275 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 7277 MaxCmdSN is a Sequence Number that the target iSCSI returns to the 7278 initiator to indicate the maximum CmdSN the initiator can send. It 7279 is used to update a local variable with the same name. If MaxCmdSN 7280 is equal to ExpCmdSN-1, this indicates to the initiator that the 7281 target cannot receive any additional commands. When MaxCmdSN 7282 changes at the target while the target has no pending PDUs to 7283 convey this information to the initiator, it MUST generate a NOP- 7284 IN to carry the new MaxCmdSN. 7286 11.5. Task Management Function Request 7288 Byte/ 0 | 1 | 2 | 3 | 7289 / | | | | 7290 |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| 7291 +---------------+---------------+---------------+--------------+ 7292 0|.|I| 0x02 |1| Function | Reserved | 7293 +---------------+---------------+---------------+--------------+ 7294 4|TotalAHSLength | DataSegmentLength | 7295 +---------------+---------------+---------------+--------------+ 7296 8| Logical Unit Number (LUN) or Reserved | 7297 + + 7298 12| | 7299 +---------------+---------------+---------------+--------------+ 7300 16| Initiator Task Tag | 7301 +---------------+---------------+---------------+--------------+ 7302 20| Referenced Task Tag or 0xffffffff | 7303 +---------------+---------------+---------------+--------------+ 7304 24| CmdSN | 7305 +---------------+---------------+---------------+--------------+ 7306 28| ExpStatSN | 7307 +---------------+---------------+---------------+--------------+ 7308 32| RefCmdSN or Reserved | 7309 +---------------+---------------+---------------+--------------+ 7310 36| ExpDataSN or Reserved | 7311 +---------------+---------------+---------------+--------------+ 7312 40/ Reserved / 7313 +/ / 7314 +---------------+---------------+---------------+--------------+ 7315 48| Header-Digest (Optional) | 7316 +---------------+---------------+---------------+--------------+ 7318 11.5.1. Function 7320 The Task Management functions provide an initiator with a way to 7321 explicitly control the execution of one or more Tasks (SCSI and 7322 iSCSI tasks). The Task Management function codes are listed below. 7323 For a more detailed description of SCSI task management, see 7324 [SAM2]. 7326 1 - ABORT TASK - aborts the task identified by the 7327 Referenced Task Tag field. 7329 2 - ABORT TASK SET - aborts all Tasks issued via this 7330 session on the logical unit. 7332 3 - CLEAR ACA - clears the Auto Contingent Allegiance 7333 condition. 7335 4 - CLEAR TASK SET - aborts all Tasks in the appropriate 7336 task set as defined by the TST field in the Control mode 7337 page (see [SPC3]). 7339 5 - LOGICAL UNIT RESET 7341 6 - TARGET WARM RESET 7343 7 - TARGET COLD RESET 7345 8 - TASK REASSIGN - reassigns connection allegiance for the 7346 task identified by the Initiator Task Tag field to this 7347 connection, thus resuming the iSCSI exchanges for the task. 7349 For all these functions, the Task Management function response 7350 MUST be returned as detailed in Section 11.6. All these functions 7351 apply to the referenced tasks regardless of whether they are 7352 proper SCSI tasks or tagged iSCSI operations. Task management 7353 requests must act on all the commands from the same session having 7354 a CmdSN lower than the task management CmdSN. LOGICAL UNIT RESET, 7355 TARGET WARM RESET and TARGET COLD RESET may affect commands from 7356 other sessions or commands from the same session regardless of 7357 their CmdSN value. 7359 If the task management request is marked for immediate delivery, 7360 it must be considered immediately for execution, but the 7361 operations involved (all or part of them) may be postponed to 7362 allow the target to receive all relevant tasks. According to 7363 [SAM2], for all the tasks covered by the Task Management response 7364 (i.e., with CmdSN lower than the task management command CmdSN) 7365 but except the Task Management response to a TASK REASSIGN, 7366 additional responses MUST NOT be delivered to the SCSI layer after 7367 the Task Management response. The iSCSI initiator MAY deliver to 7368 the SCSI layer all responses received before the Task Management 7369 response (i.e., it is a matter of implementation if the SCSI 7370 responses, received before the Task Management response but after 7371 the task management request was issued, are delivered to the SCSI 7372 layer by the iSCSI layer in the initiator). The iSCSI target MUST 7373 ensure that no responses for the tasks covered by a task 7374 management function are delivered to the iSCSI initiator after the 7375 Task Management response except for a task covered by a TASK 7376 REASSIGN. 7378 For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST 7379 continue to respond to all valid target transfer tags (received 7380 via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to 7381 the affected task set, even after issuing the task management 7382 request. The issuing initiator SHOULD however terminate (i.e., by 7383 setting the F-bit to 1) these response sequences as quickly as 7384 possible. The target on its part MUST wait for responses on all 7385 affected target transfer tags before acting on either of these two 7386 task management requests. In case all or part of the response 7387 sequence is not received (due to digest errors) for a valid TTT, 7388 the target MAY treat it as a case of within-command error recovery 7389 class (see Section 6.1.4.1 - "Recovery Within-command") if it is 7390 supporting ErrorRecoveryLevel >= 1, or alternatively may drop the 7391 connection to complete the requested task set function. 7393 If an ABORT TASK is issued for a task created by an immediate 7394 command then RefCmdSN MUST be that of the Task Management request 7395 itself (i.e. CmdSN and RefCmdSN are equal); otherwise RefCmdSN 7396 MUST be set to the CmdSN of the task to be aborted (lower than 7397 CmdSN). 7399 If the connection is still active (it is not undergoing an 7400 implicit or explicit logout), ABORT TASK MUST be issued on the 7401 same connection to which the task to be aborted is allegiant at 7402 the time the Task Management Request is issued. If the connection 7403 is implicitly or explicitly logged out (i.e., no other request 7404 will be issued on the failing connection and no other response 7405 will be received on the failing connection), then an ABORT TASK 7406 function request may be issued on another connection. This Task 7407 Management request will then establish a new allegiance for the 7408 command to be aborted as well as abort it (i.e., the task to be 7409 aborted will not have to be retried or reassigned, and its status, 7410 if sent but not acknowledged, will be resent followed by the Task 7411 Management response). 7413 At the target an ABORT TASK function MUST NOT be executed on a 7414 Task Management request; such a request MUST result in Task 7415 Management response of "Function rejected". 7417 For the LOGICAL UNIT RESET function, the target MUST behave as 7418 dictated by the Logical Unit Reset function in [SAM2]. 7420 The implementation of the TARGET WARM RESET function and the 7421 TARGET COLD RESET function is OPTIONAL and when implemented, 7422 should act as described below. The TARGET WARM RESET is also 7423 subject to SCSI access controls on the requesting initiator as 7424 defined in [SPC3]. When authorization fails at the target, the 7425 appropriate response as described in Targe MUST be returned by the 7426 target. The TARGET COLD RESET function is not subject to SCSI 7427 access controls, but its execution privileges may be managed by 7428 iSCSI mechanisms such as login authentication. 7430 When executing the TARGET WARM RESET and TARGET COLD RESET 7431 functions, the target cancels all pending operations on all 7432 Logical Units known by the issuing initiator. Both functions are 7433 equivalent to the Target Reset function specified by [SAM2]. They 7434 can affect many other initiators logged in with the servicing SCSI 7435 target port. 7437 The target MUST treat the TARGET COLD RESET function additionally 7438 as a power on event, thus terminating all of its TCP connections 7439 to all initiators (all sessions are terminated). For this reason, 7440 the Service Response (defined by [SAM2]) for this SCSI task 7441 management function may not be reliably delivered to the issuing 7442 initiator port. 7444 For the TASK REASSIGN function, the target should reassign the 7445 connection allegiance to this new connection (and thus resume 7446 iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received 7447 by the target after the connection on which the command was 7448 previously executing has been successfully logged-out. The Task 7449 Management response MUST be issued before the reassignment becomes 7450 effective. 7452 For additional usage semantics see Section 6.2 - "Retry and 7453 Reassign in Recovery". 7455 At the target a TASK REASSIGN function request MUST NOT be 7456 executed to reassign the connection allegiance of a Task 7457 Management function request, an active text negotiation task, or a 7458 Logout task; such a request MUST result in Task Management 7459 response of "Function rejected". 7461 TASK REASSIGN MUST be issued as an immediate command. 7463 11.5.2. TotalAHSLength and DataSegmentLength 7465 For this PDU, TotalAHSLength and DataSegmentLength MUST be 0. 7467 11.5.3. LUN 7469 This field is required for functions that address a specific LU 7470 (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL 7471 UNIT RESET) and is reserved in all others. 7473 11.5.4. Referenced Task Tag 7475 The Initiator Task Tag of the task to be aborted for the ABORT 7476 TASK function or reassigned for the TASK REASSIGN function. For 7477 all the other functions this field MUST be set to the reserved 7478 value 0xffffffff. 7480 11.5.5. RefCmdSN 7482 If an ABORT TASK is issued for a task created by an immediate 7483 command then RefCmdSN MUST be that of the Task Management request 7484 itself (i.e. CmdSN and RefCmdSN are equal). 7486 For an ABORT TASK of a task created by non-immediate command 7487 RefCmdSN MUST be set to the CmdSN of the task identified by the 7488 Referenced Task Tag field. Targets must use this field as 7489 described in Res when the task identified by the Referenced Task 7490 Tag field is not with the target. 7492 Otherwise, this field is reserved. 7494 11.5.6. ExpDataSN 7496 For recovery purposes, the iSCSI target and initiator maintain a 7497 data acknowledgement reference number - the first input DataSN 7498 number unacknowledged by the initiator. When issuing a new 7499 command, this number is set to 0. If the function is TASK 7500 REASSIGN, which establishes a new connection allegiance for a 7501 previously issued Read or Bidirectional command, ExpDataSN will 7502 contain an updated data acknowledgement reference number or the 7503 value 0; the latter indicating that the data acknowledgement 7504 reference number is unchanged. The initiator MUST discard any data 7505 PDUs from the previous execution that it did not acknowledge and 7506 the target MUST transmit all Data-in PDUs (if any) starting with 7507 the data acknowledgement reference number. The number of 7508 retransmitted PDUs may or may not be the same as the original 7509 transmission depending on if there was a change in 7510 MaxRecvDataSegmentLength in the reassignment. The target MAY also 7511 send no more Data-In PDUs if all data has been acknowledged. 7513 The value of ExpDataSN MUST be 0 or higher than the DataSN of the 7514 last acknowledged Data-In PDU, but not larger than DataSN+1 of the 7515 last Data-IN PDU sent by the target. Any other value MUST be 7516 ignored by the target. 7518 For other functions this field is reserved. 7520 11.6. Task Management Function Response 7521 Byte/ 0 | 1 | 2 | 3 | 7522 / | | | | 7523 |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| 7524 +---------------+---------------+---------------+--------------+ 7525 0|.|.| 0x22 |1| Reserved | Response | Reserved | 7526 +---------------+---------------+---------------+--------------+ 7527 4|TotalAHSLength | DataSegmentLength | 7528 +--------------------------------------------------------------+ 7529 8/ Reserved / 7530 / / 7531 +---------------+---------------+---------------+--------------+ 7532 16| Initiator Task Tag | 7533 +---------------+---------------+---------------+--------------+ 7534 20| Reserved | 7535 +---------------+---------------+---------------+--------------+ 7536 24| StatSN | 7537 +---------------+---------------+---------------+--------------+ 7538 28| ExpCmdSN | 7539 +---------------+---------------+---------------+--------------+ 7540 32| MaxCmdSN | 7541 +---------------+---------------+---------------+--------------+ 7542 36/ Reserved / 7543 +/ / 7544 +---------------+---------------+---------------+--------------+ 7545 48| Header-Digest (Optional) | 7546 +---------------+---------------+---------------+--------------+ 7548 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR 7549 TASK SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET 7550 and TASK REASSIGN, the target performs the requested Task 7551 Management function and sends a Task Management response back to 7552 the initiator. For TASK REASSIGN, the new connection allegiance 7553 MUST ONLY become effective at the target after the target issues 7554 the Task Management Response. 7556 11.6.1. Response 7558 The target provides a Response, which may take on the following 7559 values: 7561 0 - Function complete. 7562 1 - Task does not exist. 7564 2 - LUN does not exist. 7565 3 - Task still allegiant. 7566 4 - Task allegiance reassignment not supported. 7567 5 - Task management function not supported. 7568 6 - Function authorization failed. 7569 255 - Function rejected. 7571 All other values are reserved. 7573 For a discussion on usage of response codes 3 and 4, see Section 7574 6.2.2 - "Allegiance Reassignment". 7576 For the TARGET COLD RESET and TARGET WARM RESET functions, the 7577 target cancels all pending operations across all Logical Units 7578 known to the issuing initiator. For the TARGET COLD RESET 7579 function, the target MUST then close all of its TCP connections to 7580 all initiators (terminates all sessions). 7582 The mapping of the response code into a SCSI service response code 7583 value, if needed, is outside the scope of this document. However, 7584 in symbolic terms Response values 0 and 1 map to the SCSI service 7585 response of FUNCTION COMPLETE. All other Response values map to 7586 the SCSI service response of FUNCTION REJECTED. If a Task 7587 Management function response PDU does not arrive before the 7588 session is terminated, the SCSI service response is SERVICE 7589 DELIVERY OR TARGET FAILURE. 7591 The response to ABORT TASK SET and CLEAR TASK SET MUST only be 7592 issued by the target after all of the commands affected have been 7593 received by the target, the corresponding task management 7594 functions have been executed by the SCSI target, and the delivery 7595 of all responses delivered until the task management function 7596 completion have been confirmed (acknowledged through ExpStatSN) by 7597 the initiator on all connections of this session. For the exact 7598 timeline of events, refer to Section 4.2.3.3 and Section 4.2.3.4. 7600 For the ABORT TASK function, 7602 If the Referenced Task Tag identifies a valid task leading to 7603 a successful termination, then targets must return the 7604 "Function complete" response. 7606 If the Referenced Task Tag does not identify an existing task, 7607 but if the CmdSN indicated by the RefCmdSN field in the 7608 Task Management function request is within the valid CmdSN 7609 window and less than the CmdSN of the Task Management 7610 function request itself, then targets must consider the 7611 CmdSN received and return the "Function complete" response. 7612 If the Referenced Task Tag does not identify an existing task 7613 and if the CmdSN indicated by the RefCmdSN field in the 7614 Task Management function request is outside the valid CmdSN 7615 window, then targets must return the "Task does not exist" 7616 response. 7618 For response semantics on function types that can potentially 7619 impact multiple active tasks on the target, see Section 4.2.3. 7621 11.6.2. TotalAHSLength and DataSegmentLength 7623 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7625 11.7. SCSI Data-out & SCSI Data-in 7627 The SCSI Data-out PDU for WRITE operations has the following 7628 format: 7630 Byte/ 0 | 1 | 2 | 3 | 7631 / | | | | 7632 |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| 7633 +---------------+---------------+---------------+--------------+ 7634 0|.|.| 0x05 |F| Reserved | 7635 +---------------+---------------+---------------+--------------+ 7636 4|TotalAHSLength | DataSegmentLength | 7637 +---------------+---------------+---------------+--------------+ 7638 8| LUN or Reserved | 7639 + + 7640 12| | 7641 +---------------+---------------+---------------+--------------+ 7642 16| Initiator Task Tag | 7643 +---------------+---------------+---------------+--------------+ 7644 20| Target Transfer Tag or 0xffffffff | 7645 +---------------+---------------+---------------+--------------+ 7646 24| Reserved | 7647 +---------------+---------------+---------------+--------------+ 7648 28| ExpStatSN | 7649 +---------------+---------------+---------------+--------------+ 7650 32| Reserved | 7651 +---------------+---------------+---------------+--------------+ 7652 36| DataSN | 7653 +---------------+---------------+---------------+--------------+ 7654 40| Buffer Offset | 7655 +---------------+---------------+---------------+--------------+ 7656 44| Reserved | 7657 +---------------+---------------+---------------+--------------+ 7658 48| Header-Digest (Optional) | 7659 +---------------+---------------+---------------+--------------+ 7660 / DataSegment / 7661 +/ / 7662 +---------------+---------------+---------------+--------------+ 7663 | Data-Digest (Optional) | 7664 +---------------+---------------+---------------+--------------+ 7666 The SCSI Data-in PDU for READ operations has the following format: 7668 Byte/ 0 | 1 | 2 | 3 | 7669 / | | | | 7670 |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| 7671 +---------------+---------------+---------------+--------------+ 7672 0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd| 7673 +---------------+---------------+---------------+--------------+ 7674 4|TotalAHSLength | DataSegmentLength | 7675 +---------------+---------------+---------------+--------------+ 7676 8| LUN or Reserved | 7677 + + 7678 12| | 7679 +---------------+---------------+---------------+--------------+ 7680 16| Initiator Task Tag | 7681 +---------------+---------------+---------------+--------------+ 7682 20| Target Transfer Tag or 0xffffffff | 7683 +---------------+---------------+---------------+--------------+ 7684 24| StatSN or Reserved | 7685 +---------------+---------------+---------------+--------------+ 7686 28| ExpCmdSN | 7687 +---------------+---------------+---------------+--------------+ 7688 32| MaxCmdSN | 7689 +---------------+---------------+---------------+--------------+ 7690 36| DataSN | 7691 +---------------+---------------+---------------+--------------+ 7692 40| Buffer Offset | 7693 +---------------+---------------+---------------+--------------+ 7694 44| Residual Count | 7695 +---------------+---------------+---------------+--------------+ 7696 48| Header-Digest (Optional) | 7697 +---------------+---------------+---------------+--------------+ 7698 / DataSegment / 7699 +/ / 7700 +---------------+---------------+---------------+--------------+ 7701 | Data-Digest (Optional) | 7702 +---------------+---------------+---------------+--------------+ 7704 Status can accompany the last Data-in PDU if the command did not 7705 end with an exception (i.e., the status is "good status" - GOOD, 7706 CONDITION MET or INTERMEDIATE CONDITION MET). The presence of 7707 status (and of a residual count) is signaled though the S flag 7708 bit. Although targets MAY choose to send even non-exception 7709 status in separate responses, initiators MUST support non- 7710 exception status in Data-In PDUs. 7712 11.7.1. F (Final) Bit 7714 For outgoing data, this bit is 1 for the last PDU of unsolicited 7715 data or the last PDU of a sequence that answers an R2T. 7717 For incoming data, this bit is 1 for the last input (read) data 7718 PDU of a sequence. Input can be split into several sequences, 7719 each having its own F bit. Splitting the data stream into 7720 sequences does not affect DataSN counting on Data-In PDUs. It MAY 7721 be used as a "change direction" indication for Bidirectional 7722 operations that need such a change. 7724 DataSegmentLength MUST NOT exceed MaxRecvDataSegmentLength for the 7725 direction it is sent and the total of all the DataSegmentLength of 7726 all PDUs in a sequence MUST NOT exceed MaxBurstLength (or 7727 FirstBurstLength for unsolicited data). However the number of 7728 individual PDUs in a sequence (or in total) may be higher than the 7729 MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength 7730 ratio (as PDUs may be limited in length by the sender 7731 capabilities). Using DataSegmentLength of 0 may increase beyond 7732 what is reasonable for the number of PDUs and should therefore be 7733 avoided. 7735 For Bidirectional operations, the F bit is 1 for both the end of 7736 the input sequences and the end of the output sequences. 7738 11.7.2. A (Acknowledge) bit 7740 For sessions with ErrorRecoveryLevel 1 or higher, the target sets 7741 this bit to 1 to indicate that it requests a positive 7742 acknowledgement from the initiator for the data received. The 7743 target should use the A bit moderately; it MAY only set the A bit 7744 to 1 once every MaxBurstLength bytes, or on the last Data-In PDU 7745 that concludes the entire requested read data transfer for the 7746 task from the target's perspective, and it MUST NOT do so more 7747 frequently. The target MUST NOT set to 1 the A bit for sessions 7748 with ErrorRecoveryLevel=0. The initiator MUST ignore the A bit set 7749 to 1 for sessions with ErrorRecoveryLevel=0. 7751 On receiving a Data-In PDU with the A bit set to 1 on a session 7752 with ErrorRecoveryLevel greater than 0, if there are no holes in 7753 the read data until that Data-In PDU, the initiator MUST issue a 7754 SNACK of type DataACK except when it is able to acknowledge the 7755 status for the task immediately via ExpStatSN on other outbound 7756 PDUs if the status for the task is also received. In the latter 7757 case (acknowledgement through ExpStatSN), sending a SNACK of type 7758 DataACK in response to the A bit is OPTIONAL, but if it is done, 7759 it must not be sent after the status acknowledgement through 7760 ExpStatSN. If the initiator has detected holes in the read data 7761 prior to that Data-In PDU, it MUST postpone issuing the SNACK of 7762 type DataACK until the holes are filled. An initiator also MUST 7763 NOT acknowledge the status for the task before those holes are 7764 filled. A status acknowledgement for a task that generated the 7765 Data-In PDUs is considered by the target as an implicit 7766 acknowledgement of the Data-In PDUs if such an acknowledgement was 7767 requested by the target. 7769 11.7.3. Flags (byte 1) 7771 The last SCSI Data packet sent from a target to an initiator for a 7772 SCSI command that completed successfully (with a status of GOOD, 7773 CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may 7774 also optionally contain the Status for the data transfer. In this 7775 case, Sense Data cannot be sent together with the Command Status. 7776 If the command is completed with an error, then the response and 7777 sense data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be 7778 sent in a SCSI Data packet). For Bidirectional commands, the 7779 status MUST be sent in a SCSI Response PDU. 7781 bit 2-4 - Reserved. 7783 bit 5-6 - used the same as in a SCSI Response. These bits are 7784 only valid when S is set to 1. For details see SNACK . 7786 bit 7 S (status)- set to indicate that the Command Status 7787 field contains status. If this bit is set to 1, the F bit 7788 MUST also be set to 1. 7790 The fields StatSN, Status, and Residual Count only have meaningful 7791 content if the S bit is set to 1 and their values are defined in 7792 SNACK . 7794 11.7.4. Target Transfer Tag and LUN 7796 On outgoing data, the Target Transfer Tag is provided to the 7797 target if the transfer is honoring an R2T. In this case, the 7798 Target Transfer Tag field is a replica of the Target Transfer Tag 7799 provided with the R2T. 7801 On incoming data, the Target Transfer Tag and LUN MUST be provided 7802 by the target if the A bit is set to 1; otherwise they are 7803 reserved. The Target Transfer Tag and LUN are copied by the 7804 initiator into the SNACK of type DataACK that it issues as a 7805 result of receiving a SCSI Data-in PDU with the A bit set to 1. 7807 The Target Transfer Tag values are not specified by this protocol 7808 except that the value 0xffffffff is reserved and means that the 7809 Target Transfer Tag is not supplied. If the Target Transfer Tag 7810 is provided, then the LUN field MUST hold a valid value and be 7811 consistent with whatever was specified with the command; 7812 otherwise, the LUN field is reserved. 7814 11.7.5. DataSN 7816 For input (read) or bidirectional Data-In PDUs, the DataSN is the 7817 input PDU number within the data transfer for the command 7818 identified by the Initiator Task Tag. 7820 R2T and Data-In PDUs, in the context of bidirectional commands, 7821 share the numbering sequence (see Section 3.2.2.4 - "Data 7822 Sequencing"). 7824 For output (write) data PDUs, the DataSN is the Data-Out PDU 7825 number within the current output sequence. The current output 7826 sequence is either identified by the Initiator Task Tag (for 7827 unsolicited data) or is a data sequence generated for one R2T (for 7828 data solicited through R2T). 7830 11.7.6. Buffer Offset 7832 The Buffer Offset field contains the offset of this PDU payload 7833 data within the complete data transfer. The sum of the buffer 7835 offset and length should not exceed the expected transfer length 7836 for the command. 7838 The order of data PDUs within a sequence is determined by 7839 DataPDUInOrder. When set to Yes, it means that PDUs have to be in 7840 increasing Buffer Offset order and overlays are forbidden. 7842 The ordering between sequences is determined by 7843 DataSequenceInOrder. When set to Yes, it means that sequences have 7844 to be in increasing Buffer Offset order and overlays are 7845 forbidden. 7847 11.7.7. DataSegmentLength 7849 This is the data payload length of a SCSI Data-In or SCSI Data-Out 7850 PDU. The sending of 0 length data segments should be avoided, but 7851 initiators and targets MUST be able to properly receive 0 length 7852 data segments. 7854 The Data Segments of Data-in and Data-out PDUs SHOULD be filled to 7855 the integer number of 4 byte words (real payload) unless the F bit 7856 is set to 1. 7858 11.8. Ready To Transfer (R2T) 7860 Byte/ 0 | 1 | 2 | 3 | 7861 / | | | | 7862 |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| 7863 +---------------+---------------+---------------+--------------+ 7864 0|.|.| 0x31 |1| Reserved | 7865 +---------------+---------------+---------------+--------------+ 7866 4|TotalAHSLength | DataSegmentLength | 7867 +---------------+---------------+---------------+--------------+ 7868 8| LUN | 7869 + + 7870 12| | 7871 +---------------+---------------+---------------+--------------+ 7872 16| Initiator Task Tag | 7873 +---------------+---------------+---------------+--------------+ 7874 20| Target Transfer Tag | 7875 +---------------+---------------+---------------+--------------+ 7876 24| StatSN | 7877 +---------------+---------------+---------------+--------------+ 7878 28| ExpCmdSN | 7879 +---------------+---------------+---------------+--------------+ 7880 32| MaxCmdSN | 7881 +---------------+---------------+---------------+--------------+ 7882 36| R2TSN | 7883 +---------------+---------------+---------------+--------------+ 7884 40| Buffer Offset | 7885 +---------------+---------------+---------------+--------------+ 7886 44| Desired Data Transfer Length | 7887 +--------------------------------------------------------------+ 7888 48| Header-Digest (Optional) | 7889 +---------------+---------------+---------------+--------------+ 7891 When an initiator has submitted a SCSI Command with data that 7892 passes from the initiator to the target (WRITE), the target may 7893 specify which blocks of data it is ready to receive. The target 7894 may request that the data blocks be delivered in whichever order 7895 is convenient for the target at that particular instant. This 7896 information is passed from the target to the initiator in the 7897 Ready To Transfer (R2T) PDU. 7899 In order to allow write operations without an explicit initial 7900 R2T, the initiator and target MUST have negotiated the key 7901 InitialR2T to No during Login. 7903 An R2T MAY be answered with one or more SCSI Data-out PDUs with a 7904 matching Target Transfer Tag. If an R2T is answered with a single 7905 Data-out PDU, the Buffer Offset in the Data PDU MUST be the same 7906 as the one specified by the R2T, and the data length of the Data 7907 PDU MUST be the same as the Desired Data Transfer Length specified 7908 in the R2T. If the R2T is answered with a sequence of Data PDUs, 7909 the Buffer Offset and Length MUST be within the range of those 7910 specified by R2T, and the last PDU MUST have the F bit set to 1. 7911 If the last PDU (marked with the F bit) is received before the 7912 Desired Data Transfer Length is transferred, a target MAY choose 7913 to Reject that PDU with "Protocol error" reason code. 7914 DataPDUInOrder governs the Data-Out PDU ordering. If 7915 DataPDUInOrder is set to Yes, the Buffer Offsets and Lengths for 7916 consecutive PDUs MUST form a continuous non-overlapping range and 7917 the PDUs MUST be sent in increasing offset order. 7919 The target may send several R2T PDUs. It, therefore, can have a 7920 number of pending data transfers. The number of outstanding R2T 7921 PDUs are limited by the value of the negotiated key 7922 MaxOutstandingR2T. Within a task, outstanding R2Ts MUST be 7923 fulfilled by the initiator in the order in which they were 7924 received. 7926 R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T 7927 (Recovery-R2T) is generated by a target upon detecting the loss of 7928 one or more Data-Out PDUs due to: 7930 - Digest error 7932 - Sequence error 7934 - Sequence reception timeout 7936 A Recovery-R2T carries the next unused R2TSN, but requests part of 7937 or the entire data burst that an earlier R2T (with a lower R2TSN) 7938 had already requested. 7940 DataSequenceInOrder governs the buffer offset ordering in 7941 consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive 7942 R2Ts MUST refer to continuous non-overlapping ranges except for 7943 Recovery-R2Ts. 7945 11.8.1. TotalAHSLength and DataSegmentLength 7947 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7949 11.8.2. R2TSN 7951 R2TSN is the R2T PDU input PDU number within the command 7952 identified by the Initiator Task Tag. 7954 For bidirectional commands R2T and Data-In PDUs share the input 7955 PDU numbering sequence (see Section 3.2.2.4 - "Data Sequencing"). 7957 11.8.3. StatSN 7959 The StatSN field will contain the next StatSN. The StatSN for this 7960 connection is not advanced after this PDU is sent. 7962 11.8.4. Desired Data Transfer Length and Buffer Offset 7964 The target specifies how many bytes it wants the initiator to send 7965 because of this R2T PDU. The target may request the data from the 7966 initiator in several chunks, not necessarily in the original order 7967 of the data. The target, therefore, also specifies a Buffer Offset 7968 that indicates the point at which the data transfer should begin, 7969 relative to the beginning of the total data transfer. The Desired 7970 Data Transfer Length MUST NOT be 0 and MUST NOT exceed 7971 MaxBurstLength. 7973 11.8.5. Target Transfer Tag 7975 The target assigns its own tag to each R2T request that it sends 7976 to the initiator. This tag can be used by the target to easily 7977 identify the data it receives. The Target Transfer Tag and LUN are 7978 copied in the outgoing data PDUs and are only used by the target. 7979 There is no protocol rule about the Target Transfer Tag except 7980 that the value 0xffffffff is reserved and MUST NOT be sent by a 7981 target in an R2T. 7983 11.9. Asynchronous Message 7985 An Asynchronous Message may be sent from the target to the 7986 initiator without correspondence to a particular command. The 7987 target specifies the reason for the event and sense data. 7989 Byte/ 0 | 1 | 2 | 3 | 7990 / | | | | 7991 |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| 7992 +---------------+---------------+---------------+--------------+ 7993 0|.|.| 0x32 |1| Reserved | 7994 +---------------+---------------+---------------+--------------+ 7995 4|TotalAHSLength | DataSegmentLength | 7996 +---------------+---------------+---------------+--------------+ 7997 8| LUN or Reserved | 7998 + + 7999 12| | 8000 +---------------+---------------+---------------+--------------+ 8001 16| 0xffffffff | 8002 +---------------+---------------+---------------+--------------+ 8003 20| Reserved | 8004 +---------------+---------------+---------------+--------------+ 8005 24| StatSN | 8006 +---------------+---------------+---------------+--------------+ 8007 28| ExpCmdSN | 8008 +---------------+---------------+---------------+--------------+ 8009 32| MaxCmdSN | 8010 +---------------+---------------+---------------+--------------+ 8011 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | 8012 +---------------+---------------+---------------+--------------+ 8013 40| Parameter2 or Reserved | Parameter3 or Reserved | 8014 +---------------+---------------+---------------+--------------+ 8015 44| Reserved | 8016 +---------------+---------------+---------------+--------------+ 8017 48| Header-Digest (Optional) | 8018 +---------------+---------------+---------------+--------------+ 8019 / DataSegment - Sense Data and iSCSI Event Data / 8020 +/ / 8021 +---------------+---------------+---------------+--------------+ 8022 | Data-Digest (Optional) | 8023 +---------------+---------------+---------------+--------------+ 8025 Some Asynchronous Messages are strictly related to iSCSI while 8026 others are related to SCSI [SAM2]. 8028 StatSN counts this PDU as an acknowledgeable event (StatSN is 8029 advanced), which allows for initiator and target state 8030 synchronization. 8032 11.9.1. AsyncEvent 8034 The codes used for iSCSI Asynchronous Messages (events) are: 8036 0 (SCSI_ASYNC) - a SCSI Asynchronous Event is reported in the 8037 sense data. Sense Data that accompanies the report, in the 8038 data segment, identifies the condition. The sending of a 8039 SCSI Event (Asynchronous Event Reporting in SCSI 8040 terminology) is dependent on the target support for SCSI 8041 asynchronous event reporting (see [SAM2]) as indicated in 8042 the standard INQUIRY data (see [SPC3]). Its use may be 8043 enabled by parameters in the SCSI Control mode page (see 8044 [SPC3]). 8046 1 (REQUEST_LOGOUT) - target requests Logout. This Async 8047 Message MUST be sent on the same connection as the one 8048 requesting to be logged out. The initiator MUST honor this 8049 request by issuing a Logout as early as possible, but no 8050 later than Parameter3 seconds. Initiator MUST send a 8051 Logout with a reason code of "Close the connection" OR 8052 "Close the session" to close all the connections. Once this 8053 message is received, the initiator SHOULD NOT issue new 8054 iSCSI commands on the connection to be logged out. The 8055 target MAY reject any new I/O requests that it receives 8056 after this Message with the reason code "Waiting for 8057 Logout". If the initiator does not Logout in Parameter3 8058 seconds, the target should send an Async PDU with iSCSI 8059 event code "Dropped the connection" if possible, or simply 8060 terminate the transport connection. Parameter1 and 8061 Parameter2 are reserved. 8063 2 (CONNECTION_DROP) - target indicates it will drop the 8064 connection. 8065 The Parameter1 field indicates the CID of the connection 8066 going to be dropped. 8068 The Parameter2 field (Time2Wait) indicates, in seconds, the 8069 minimum time to wait before attempting to reconnect or 8070 reassign. 8072 The Parameter3 field (Time2Retain) indicates the maximum 8073 time allowed to reassign commands after the initial wait (in 8074 Parameter2). 8076 If the initiator does not attempt to reconnect and/or 8077 reassign the outstanding commands within the time specified 8078 by Parameter3, or if Parameter3 is 0, the target will 8079 terminate all outstanding commands on this connection. In 8080 this case, no other responses should be expected from the 8081 target for the outstanding commands on this connection. 8083 A value of 0 for Parameter2 indicates that reconnect can be 8084 attempted immediately. 8086 3 (SESSION_DROP) - target indicates it will drop all the 8087 connections of this session. 8089 Parameter1 field is reserved. 8091 The Parameter2 field (Time2Wait) indicates, in seconds, the 8092 minimum time to wait before attempting to reconnect. 8093 The Parameter3 field (Time2Retain) indicates the maximum 8094 time allowed to reassign commands after the initial wait (in 8095 Parameter2). 8097 If the initiator does not attempt to reconnect and/or 8098 reassign the outstanding commands within the time specified 8099 by Parameter3, or if Parameter3 is 0, the session is 8100 terminated. In this case, the target will terminate all 8101 outstanding commands in this session; no other responses 8102 should be expected from the target for the outstanding 8103 commands in this session. A value of 0 for Parameter2 8104 indicates that reconnect can be attempted immediately. 8106 4 (RENEGOTIATE) - target requests parameter negotiation on 8107 this connection. The initiator MUST honor this request by 8108 issuing a Text Request (that can be empty) on the same 8109 connection as early as possible, but no later than 8110 Parameter3 seconds, unless a Text Request is already pending 8111 on the connection, or by issuing a Logout Request. If the 8112 initiator does not issue a Text Request the target may 8113 reissue the Asynchronous Message requesting parameter 8114 negotiation. 8116 5 (FAST_ABORT) - all active tasks for LU with a matching LUN 8117 field in the Async Message PDU are being terminated. The 8118 receiving initiator iSCSI layer MUST respond to this Message 8119 by taking the following steps in order. 8121 - Stop Data-Out transfers on that connection for all active 8122 TTTs for the affected LUN quoted in the Async Message 8123 PDU. 8124 - Acknowledge the StatSN of the Async Message PDU via a NOP- 8125 Out PDU with ITT=0xffffffff (i.e., non-ping flavor), 8126 while copying the LUN field from the Async Message to 8127 NOP-Out. 8129 This value of AsyncEvent however MUST NOT be used on an 8130 iSCSI session unless the new TaskReporting text key defined 8131 in Section 13.23 was negotiated to FastAbort on the session. 8133 255 - vendor-specific iSCSI Event. The AsyncVCode details the 8134 vendor code, and data MAY accompany the report. 8136 All other event codes are reserved. 8138 11.9.2. AsyncVCode 8140 AsyncVCode is a vendor specific detail code that is only valid if 8141 the AsyncEvent field indicates a vendor specific event. Otherwise, 8142 it is reserved. 8144 11.9.3. LUN 8146 The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this 8147 field is reserved. 8148 11.9.4. Sense Data and iSCSI Event Data 8150 For a SCSI event, this data accompanies the report in the data 8151 segment and identifies the condition. 8153 For an iSCSI event, additional vendor-unique data MAY accompany 8154 the Async event. Initiators MAY ignore the data when not 8155 understood while processing the rest of the PDU. 8157 If the DataSegmentLength is not 0, the format of the DataSegment 8158 is as follows: 8159 Byte/ 0 | 1 | 2 | 3 | 8160 / | | | | 8161 |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| 8162 +---------------+---------------+---------------+--------------+ 8163 0|SenseLength | Sense Data | 8164 +---------------+---------------+---------------+--------------+ 8165 x/ Sense Data / 8166 +---------------+---------------+---------------+--------------+ 8167 y/ iSCSI Event Data / 8168 / / 8169 +---------------+---------------+---------------+--------------+ 8170 z| 8172 11.9.4.1. SenseLength 8174 This is the length of Sense Data. When the Sense Data field is 8175 empty (e.g., the event is not a SCSI event) SenseLength is 0. 8177 11.10. Text Request 8179 The Text Request is provided to allow for the exchange of 8180 information and for future extensions. It permits the initiator to 8181 inform a target of its capabilities or to request some special 8182 operations. 8184 Byte/ 0 | 1 | 2 | 3 | 8185 / | | | | 8186 |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| 8187 +---------------+---------------+---------------+--------------+ 8188 0|.|I| 0x04 |F|C| Reserved | 8189 +---------------+---------------+---------------+--------------+ 8190 4|TotalAHSLength | DataSegmentLength | 8191 +---------------+---------------+---------------+--------------+ 8192 8| LUN or Reserved | 8193 + + 8194 12| | 8195 +---------------+---------------+---------------+--------------+ 8196 16| Initiator Task Tag | 8197 +---------------+---------------+---------------+--------------+ 8198 20| Target Transfer Tag or 0xffffffff | 8199 +---------------+---------------+---------------+--------------+ 8200 24| CmdSN | 8201 +---------------+---------------+---------------+--------------+ 8202 28| ExpStatSN | 8203 +---------------+---------------+---------------+--------------+ 8204 32/ Reserved / 8205 +/ / 8206 +---------------+---------------+---------------+--------------+ 8207 48| Header-Digest (Optional) | 8208 +---------------+---------------+---------------+--------------+ 8209 / DataSegment (Text) / 8210 +/ / 8211 +---------------+---------------+---------------+--------------+ 8212 | Data-Digest (Optional) | 8213 +---------------+---------------+---------------+--------------+ 8215 An initiator MUST NOT have more than one outstanding Text Request 8216 on a connection at any given time. 8218 On a connection failure, an initiator must either explicitly abort 8219 any active allegiant text negotiation task or must cause such a 8220 task to be implicitly terminated by the target. 8222 11.10.1. F (Final) Bit 8224 When set to 1, indicates that this is the last or only text 8225 request in a sequence of Text Requests; otherwise, it indicates 8226 that more Text Requests will follow. 8228 11.10.2. C (Continue) Bit 8230 When set to 1, indicates that the text (set of key=value pairs) 8231 in this Text Request is not complete (it will be continued on 8232 subsequent Text Requests); otherwise, it indicates that this Text 8233 Request ends a set of key=value pairs. A Text Request with the C 8234 bit set to 1 MUST have the F bit set to 0. 8236 11.10.3. Initiator Task Tag 8238 The initiator assigned identifier for this Text Request. If the 8239 command is sent as part of a sequence of text requests and 8240 responses, the Initiator Task Tag MUST be the same for all the 8241 requests within the sequence (similar to linked SCSI commands). 8242 The I bit for all requests in a sequence also MUST be the same. 8244 11.10.4. Target Transfer Tag 8246 When the Target Transfer Tag is set to the reserved value 8247 0xffffffff, it tells the target that this is a new request and the 8248 target resets any internal state associated with the Initiator 8249 Task Tag (resets the current negotiation state). 8251 The target sets the Target Transfer Tag in a text response to a 8252 value other than the reserved value 0xffffffff whenever it 8253 indicates that it has more data to send or more operations to 8254 perform that are associated with the specified Initiator Task Tag. 8255 It MUST do so whenever it sets the F bit to 0 in the response. By 8256 copying the Target Transfer Tag from the response to the next Text 8257 Request, the initiator tells the target to continue the operation 8258 for the specific Initiator Task Tag. The initiator MUST ignore the 8259 Target Transfer Tag in the Text Response when the F bit is set to 8260 1. 8262 This mechanism allows the initiator and target to transfer a large 8263 amount of textual data over a sequence of text-command/text- 8264 response exchanges, or to perform extended negotiation sequences. 8266 If the Target Transfer Tag is not 0xffffffff, the LUN field MUST 8267 be sent by the target in the Text Response. 8269 A target MAY reset its internal negotiation state if an exchange 8270 is stalled by the initiator for a long time or if it is running 8271 out of resources. 8273 Long text responses are handled as in the following example: 8275 I->T Text SendTargets=All (F=1,TTT=0xffffffff) 8277 T->I Text (F=0,TTT=0x12345678) 8279 I->T Text (F=1, TTT=0x12345678) 8281 T->I Text (F=0, TTT=0x12345678) 8283 I->T Text (F=1, TTT=0x12345678) 8285 ... 8287 T->I Text (F=1, TTT=0xffffffff) 8289 11.10.5. Text 8291 The data lengths of a text request MUST NOT exceed the iSCSI 8292 target MaxRecvDataSegmentLength (a per connection and per 8293 direction negotiated parameter). The text format is specified in 8294 Section 5.2 - "Text Mode Negotiation". 8296 Chapter 11 and Chapter 12 list some basic Text key=value pairs, 8297 some of which can be used in Login Request/Response and some in 8298 Text Request/Response. 8300 A key=value pair can span Text request or response boundaries. A 8301 key=value pair can start in one PDU and continue on the next. In 8302 other words the end of a PDU does not necessarily signal the end 8303 of a key=value pair. 8305 The target responds by sending its response back to the initiator. 8306 The response text format is similar to the request text format. 8307 The text response MAY refer to key=value pairs presented in an 8308 earlier text request and the text in the request may refer to 8309 earlier responses. 8311 Chapter 5 details the rules for the Text Requests and Responses. 8313 Text operations are usually meant for parameter 8314 setting/negotiations, but can also be used to perform some long 8315 lasting operations. 8317 Text operations that take a long time should be placed in their 8318 own Text request. 8320 11.11. Text Response 8322 The Text Response PDU contains the target's responses to the 8323 initiator's Text request. The format of the Text field matches 8324 that of the Text request. 8326 Byte/ 0 | 1 | 2 | 3 | 8327 / | | | | 8328 |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| 8329 +---------------+---------------+---------------+--------------+ 8330 0|.|.| 0x24 |F|C| Reserved | 8331 +---------------+---------------+---------------+--------------+ 8332 4|TotalAHSLength | DataSegmentLength | 8333 +---------------+---------------+---------------+--------------+ 8334 8| LUN or Reserved | 8335 + + 8336 12| | 8337 +---------------+---------------+---------------+--------------+ 8338 16| Initiator Task Tag | 8339 +---------------+---------------+---------------+--------------+ 8340 20| Target Transfer Tag or 0xffffffff | 8341 +---------------+---------------+---------------+--------------+ 8342 24| StatSN | 8343 +---------------+---------------+---------------+--------------+ 8344 28| ExpCmdSN | 8345 +---------------+---------------+---------------+--------------+ 8346 32| MaxCmdSN | 8347 +---------------+---------------+---------------+--------------+ 8348 36/ Reserved / 8349 +/ / 8350 +---------------+---------------+---------------+--------------+ 8351 48| Header-Digest (Optional) | 8352 +---------------+---------------+---------------+--------------+ 8353 / DataSegment (Text) / 8354 +/ / 8355 +---------------+---------------+---------------+--------------+ 8356 | Data-Digest (Optional) | 8357 +---------------+---------------+---------------+--------------+ 8359 11.11.1. F (Final) Bit 8361 When set to 1, in response to a Text Request with the Final bit 8362 set to 1, the F bit indicates that the target has finished the 8363 whole operation. Otherwise, if set to 0 in response to a Text 8364 Request with the Final Bit set to 1, it indicates that the target 8365 has more work to do (invites a follow-on text request). A Text 8366 Response with the F bit set to 1 in response to a Text Request 8367 with the F bit set to 0 is a protocol error. 8369 A Text Response with the F bit set to 1 MUST NOT contain key=value 8370 pairs that may require additional answers from the initiator. 8372 A Text Response with the F bit set to 1 MUST have a Target 8373 Transfer Tag field set to the reserved value of 0xffffffff. 8375 A Text Response with the F bit set to 0 MUST have a Target 8376 Transfer Tag field set to a value other than the reserved 8377 0xffffffff. 8379 11.11.2. C (Continue) Bit 8381 When set to 1, indicates that the text (set of key=value pairs) in 8382 this Text Response is not complete (it will be continued on 8383 subsequent Text Responses); otherwise, it indicates that this Text 8384 Response ends a set of key=value pairs. A Text Response with the C 8385 bit set to 1 MUST have the F bit set to 0. 8387 11.11.3. Initiator Task Tag 8389 The Initiator Task Tag matches the tag used in the initial Text 8390 Request. 8392 11.11.4. Target Transfer Tag 8394 When a target has more work to do (e.g., cannot transfer all the 8395 remaining text data in a single Text Response or has to continue 8396 the negotiation) and has enough resources to proceed, it MUST set 8397 the Target Transfer Tag to a value other than the reserved value 8398 of 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to 8399 0xffffffff. 8401 When the Target Transfer Tag is not 0xffffffff, the LUN field may 8402 be significant. 8404 The initiator MUST copy the Target Transfer Tag and LUN in its 8405 next request to indicate that it wants the rest of the data. 8407 When the target receives a Text Request with the Target Transfer 8408 Tag set to the reserved value of 0xffffffff, it resets its 8409 internal information (resets state) associated with the given 8410 Initiator Task Tag (restarts the negotiation). 8412 When a target cannot finish the operation in a single Text 8413 Response, and does not have enough resources to continue, it 8414 rejects the Text Request with the appropriate Reject code. 8416 A target may reset its internal state associated with an Initiator 8417 Task Tag (the current negotiation state), state expressed through 8418 the Target Transfer Tag if the initiator fails to continue the 8419 exchange for some time. The target may reject subsequent Text 8420 Requests with the Target Transfer Tag set to the "stale" value. 8422 11.11.5. StatSN 8424 The target StatSN variable is advanced by each Text Response sent. 8426 11.11.6. Text Response Data 8428 The data lengths of a text response MUST NOT exceed the iSCSI 8429 initiator MaxRecvDataSegmentLength (a per connection and per 8430 direction negotiated parameter). 8432 The text in the Text Response Data is governed by the same rules 8433 as the text in the Text Request Data (see C (Con). 8435 Although the initiator is the requesting party and controls the 8436 request-response initiation and termination, the target can offer 8437 key=value pairs of its own as part of a sequence and not only in 8438 response to the initiator. 8440 11.12. Login Request 8442 After establishing a TCP connection between an initiator and a 8443 target, the initiator MUST start a Login Phase to gain further 8444 access to the target's resources. 8446 The Login Phase (see Chapter 5) consists of a sequence of Login 8447 requests and responses that carry the same Initiator Task Tag. 8449 Login requests are always considered as immediate. 8451 Byte/ 0 | 1 | 2 | 3 | 8452 / | | | | 8453 |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| 8454 +---------------+---------------+---------------+--------------+ 8455 0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min | 8456 +---------------+---------------+---------------+--------------+ 8457 4|TotalAHSLength | DataSegmentLength | 8458 +---------------+---------------+---------------+--------------+ 8459 8| ISID | 8460 + +---------------+--------------+ 8461 12| | TSIH | 8462 +---------------+---------------+---------------+--------------+ 8463 16| Initiator Task Tag | 8464 +---------------+---------------+---------------+--------------+ 8465 20| CID | Reserved | 8466 +---------------+---------------+---------------+--------------+ 8467 24| CmdSN | 8468 +---------------+---------------+---------------+--------------+ 8469 28| ExpStatSN or Reserved | 8470 +---------------+---------------+---------------+--------------+ 8471 32| Reserved | 8472 +---------------+---------------+---------------+--------------+ 8473 36| Reserved | 8474 +---------------+---------------+---------------+--------------+ 8475 40/ Reserved / 8476 +/ / 8477 +---------------+---------------+---------------+--------------+ 8478 48/ DataSegment - Login Parameters in Text request Format / 8479 +/ / 8480 +---------------+---------------+---------------+--------------+ 8482 11.12.1. T (Transit) Bit 8484 If set to 1, indicates that the initiator is ready to transit to 8485 the next stage. 8487 If the T bit is set to 1 and NSG is FullFeaturePhase, then this 8488 also indicates that the initiator is ready for the Final Login 8489 Response (see Chapter 5). 8491 11.12.2. C (Continue) Bit 8493 When set to 1, indicates that the text (set of key=value pairs) 8494 in this Login Request is not complete (it will be continued on 8495 subsequent Login Requests); otherwise, it indicates that this 8496 Login Request ends a set of key=value pairs. A Login Request with 8497 the C bit set to 1 MUST have the T bit set to 0. 8499 11.12.3. CSG and NSG 8501 Through these fields, Current Stage (CSG) and Next Stage (NSG), 8502 the Login negotiation requests and responses are associated with a 8503 specific stage in the session (SecurityNegotiation, 8504 LoginOperationalNegotiation, FullFeaturePhase) and may indicate 8505 the next stage to which they want to move (see Chapter 5). The 8506 next stage value is only valid when the T bit is 1; otherwise, it 8507 is reserved. 8509 The stage codes are: 8511 - 0 - SecurityNegotiation 8513 - 1 - LoginOperationalNegotiation 8515 - 3 - FullFeaturePhase 8517 All other codes are reserved. 8519 11.12.4. Version 8521 The version number of the current draft is 0x00. As such, all 8522 devices MUST carry version 0x00 for both Version-min and Version- 8523 max. 8525 11.12.4.1. Version-max 8527 Maximum Version number supported. 8529 All Login requests within the Login Phase MUST carry the same 8530 Version-max. 8532 The target MUST use the value presented with the first login 8533 request. 8535 11.12.4.2. Version-min 8537 All Login requests within the Login Phase MUST carry the same 8538 Version-min. The target MUST use the value presented with the 8539 first login request. 8541 11.12.5. ISID 8543 This is an initiator-defined component of the session identifier 8544 and is structured as follows (see Section 10.1.1 for details): 8546 Byte/ 0 | 1 | 2 | 3 | 8547 / | | | | 8548 |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| 8549 +---------------+---------------+---------------+--------------+ 8550 8| T | A | B | C | 8551 +---------------+---------------+---------------+--------------+ 8552 12| D | 8553 +---------------+---------------+ 8555 The T field identifies the format and usage of A, B, C, and D as 8556 indicated below: 8558 T 8560 00b OUI-Format 8562 A&B are a 22 bit OUI 8564 (the I/G & U/L bits are omitted) 8566 C&D 24 bit qualifier 8568 01b EN - Format (IANA Enterprise Number) 8570 A - Reserved 8572 B&C EN (IANA Enterprise Number) 8574 D - Qualifier 8576 10b "Random" 8578 A - Reserved 8580 B&C Random 8582 D - Qualifier 8584 11b A,B,C&D Reserved 8586 For the T field values 00b and 01b, a combination of A and B (for 8587 00b) or B and C (for 01b) identifies the vendor or organization 8588 whose component (software or hardware) generates this ISID. A 8589 vendor or organization with one or more OUIs, or one or more 8590 Enterprise Numbers, MUST use at least one of these numbers and 8591 select the appropriate value for the T field when its components 8592 generate ISIDs. An OUI or EN MUST be set in the corresponding 8593 fields in network byte order (byte big-endian). 8595 If the T field is 10b, B and C are set to a random 24-bit unsigned 8596 integer value in network byte order (byte big-endian). See 8597 [RFC3721] for how this affects the principle of "conservative 8598 reuse". 8600 The Qualifier field is a 16 or 24-bit unsigned integer value that 8601 provides a range of possible values for the ISID within the 8602 selected namespace. It may be set to any value within the 8603 constraints specified in the iSCSI protocol (see Section 3.4.3 - 8604 "Consequences of the Model" and Section 9.1.1 - "Conservative 8605 Reuse of ISIDs"). 8607 The T field value of 11b is reserved. 8609 If the ISID is derived from something assigned to a hardware 8610 adapter or interface by a vendor, as a preset default value, it 8611 MUST be configurable to a value assigned according to the SCSI 8612 port behavior desired by the system in which it is installed (see 8613 Section 9.1.1 - "Conservative Reuse of ISIDs" and Section 9.1.2 - 8614 "iSCSI Name, ISID, and TPGT Use"). The resultant ISID MUST also be 8615 persistent over power cycles, reboot, card swap, etc. 8617 11.12.6. TSIH 8619 TSIH must be set in the first Login Request. The reserved value 0 8620 MUST be used on the first connection for a new session. Otherwise, 8621 the TSIH sent by the target at the conclusion of the successful 8622 login of the first connection for this session MUST be used. The 8623 TSIH identifies to the target the associated existing session for 8624 this new connection. 8626 All Login requests within a Login Phase MUST carry the same TSIH. 8628 The target MUST check the value presented with the first login 8629 request and act as specified in Section 5.3.1 - "Login Phase 8630 Start". 8632 11.12.7. Connection ID - CID 8634 A unique ID for this connection within the session. 8636 All Login requests within the Login Phase MUST carry the same CID. 8638 The target MUST use the value presented with the first login 8639 request. 8641 A Login request with a non-zero TSIH and a CID equal to that of an 8642 existing connection implies a logout of the connection followed by 8643 a Login (see Section 6.3.4). For the details of the implicit 8644 Logout Request, see Section 11.14. 8646 11.12.8. CmdSN 8648 CmdSN is either the initial command sequence number of a session 8649 (for the first Login request of a session - the "leading" login), 8650 or the command sequence number in the command stream if the login 8651 is for a new connection in an existing session. 8653 Examples: 8655 - Login on a leading connection - if the leading login carries 8656 the CmdSN 123, all other login requests in the same login 8657 phase carry the CmdSN 123 and the first non-immediate 8658 command in FullFeaturePhase also carries the CmdSN 123. 8660 - Login on other than a leading connection - if the current 8661 CmdSN at the time the first login on the connection is 8662 issued is 500, then that PDU carries CmdSN=500. Subsequent 8663 login requests that are needed to complete this login phase 8664 may carry a CmdSN higher than 500 if non-immediate requests 8665 that were issued on other connections in the same session 8666 advance CmdSN. 8668 If the login request is a leading login request, the target MUST 8669 use the value presented in CmdSN as the target value for ExpCmdSN. 8671 11.12.9. ExpStatSN 8673 For the first Login Request on a connection this is ExpStatSN for 8674 the old connection and this field is only valid if the Login 8675 request restarts a connection (see Section 5.3.4 - "Connection 8676 Reinstatement"). 8678 For subsequent Login Requests it is used to acknowledge the Login 8679 Responses with their increasing StatSN values. 8681 11.12.10. Login Parameters 8683 The initiator MUST provide some basic parameters in order to 8684 enable the target to determine if the initiator may use the 8685 target's resources and the initial text parameters for the 8686 security exchange. 8688 All the rules specified in Section 11.10.5 for text requests also 8689 hold for login requests. Keys and their explanations are listed 8690 in Chapter 11 (security negotiation keys) and Section 13 8691 (operational parameter negotiation keys). All keys in Section 13, 8692 except for the X extension formats, MUST be supported by iSCSI 8693 initiators and targets. Keys in Section 12 only need to be 8695 supported when the function to which they refer is mandatory to 8696 implement. 8698 11.13. Login Response 8700 The Login Response indicates the progress and/or end of the Login 8701 Phase. 8703 Byte/ 0 | 1 | 2 | 3 | 8704 / | | | | 8705 |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| 8706 +---------------+---------------+---------------+--------------+ 8707 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max |Version-active| 8708 +---------------+---------------+---------------+--------------+ 8709 4|TotalAHSLength | DataSegmentLength | 8710 +---------------+---------------+---------------+--------------+ 8711 8| ISID | 8712 + +---------------+--------------+ 8713 12| | TSIH | 8714 +---------------+---------------+---------------+--------------+ 8715 16| Initiator Task Tag | 8716 +---------------+---------------+---------------+--------------+ 8717 20| Reserved | 8718 +---------------+---------------+---------------+--------------+ 8719 24| StatSN | 8720 +---------------+---------------+---------------+--------------+ 8721 28| ExpCmdSN | 8722 +---------------+---------------+---------------+--------------+ 8723 32| MaxCmdSN | 8724 +---------------+---------------+---------------+--------------+ 8725 36| Status-Class | Status-Detail | Reserved | 8726 +---------------+---------------+---------------+--------------+ 8727 40/ Reserved / 8728 +/ / 8729 +---------------+---------------+---------------+--------------+ 8730 48/ DataSegment - Login Parameters in Text request Format / 8731 +/ / 8732 +---------------+---------------+---------------+--------------+ 8734 11.13.1. Version-max 8736 This is the highest version number supported by the target. 8738 All Login responses within the Login Phase MUST carry the same 8739 Version-max. 8741 The initiator MUST use the value presented as a response to the 8742 first login request. 8744 11.13.2. Version-active 8746 Indicates the highest version supported by the target and 8747 initiator. If the target does not support a version within the 8748 range specified by the initiator, the target rejects the login and 8749 this field indicates the lowest version supported by the target. 8751 All Login responses within the Login Phase MUST carry the same 8752 Version-active. 8754 The initiator MUST use the value presented as a response to the 8755 first login request. 8757 11.13.3. TSIH 8759 The TSIH is the target assigned session identifying handle. Its 8760 internal format and content are not defined by this protocol 8761 except for the value 0 that is reserved. With the exception of the 8762 Login Final-Response in a new session, this field should be set to 8763 the TSIH provided by the initiator in the Login Request. For a 8764 new session, the target MUST generate a non-zero TSIH and ONLY 8765 return it in the Login Final-Response (see Section 5.3 - "Login 8766 Phase"). 8768 11.13.4. StatSN 8770 For the first Login Response (the response to the first Login 8771 Request), this is the starting status Sequence Number for the 8772 connection. The next response of any kind, including the next 8773 login response, if any, in the same Login Phase, will carry this 8774 number + 1. This field is only valid if the Status-Class is 0. 8776 11.13.5. Status-Class and Status-Detail 8778 The Status returned in a Login Response indicates the execution 8779 status of the Login Phase. The status includes: 8781 Status-Class 8783 Status-Detail 8785 0 Status-Class indicates success. 8787 A non-zero Status-Class indicates an exception. In this case, 8788 Status-Class is sufficient for a simple initiator to use when 8789 handling exceptions, without having to look at the Status-Detail. 8790 The Status-Detail allows finer-grained exception handling for more 8791 sophisticated initiators and for better information for logging. 8793 The status classes are as follows: 8795 0 - Success - indicates that the iSCSI target successfully 8796 received, understood, and accepted the request. The 8797 numbering fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid 8798 if Status-Class is 0. 8800 1 - Redirection - indicates that the initiator must take 8801 further action to complete the request. This is usually due 8802 to the target moving to a different address. All of the 8803 redirection status class responses MUST return one or more 8804 text key parameters of the type "TargetAddress", which 8805 indicates the target's new address. A redirection response 8806 MAY be issued by a target prior or after completing a 8807 security negotiation if a security negotiation is required. 8808 A redirection SHOULD be accepted by an initiator even 8809 without having the target complete a security negotiation if 8810 any security negotiation is required, and MUST be accepted 8811 by the initiator after the completion of the security 8812 negotiation if any security negotiation is required. 8814 2 - Initiator Error (not a format error) - indicates that the 8815 initiator most likely caused the error. This MAY be due to a 8817 request for a resource for which the initiator does not have 8818 permission. The request should not be tried again. 8820 3 - Target Error - indicates that the target sees no errors in 8821 the initiator's login request, but is currently incapable of 8822 fulfilling the request. The initiator may re-try the same 8823 login request later. 8825 The table below shows all of the currently allocated status codes. 8826 The codes are in hexadecimal; the first byte is the status class 8827 and the second byte is the status detail. 8829 ----------------------------------------------------------------- 8830 Status | Code | Description 8831 |(hex) | 8832 ----------------------------------------------------------------- 8833 Success | 0000 | Login is proceeding OK (*1). 8834 ----------------------------------------------------------------- 8835 Target moved | 0101 | The requested iSCSI Target Name (ITN) 8836 temporarily | | has temporarily moved 8837 | | to the address provided. 8838 ----------------------------------------------------------------- 8839 Target moved | 0102 | The requested ITN has permanently moved 8840 permanently | | to the address provided. 8841 ----------------------------------------------------------------- 8842 Initiator | 0200 | Miscellaneous iSCSI initiator 8843 error | | errors. 8844 ---------------------------------------------------------------- 8845 Authentication| 0201 | The initiator could not be 8846 failure | | successfully authenticated or target 8847 | | authentication is not supported. 8848 ----------------------------------------------------------------- 8849 Authorization | 0202 | The initiator is not allowed access 8850 failure | | to the given target. 8851 ----------------------------------------------------------------- 8852 Not found | 0203 | The requested ITN does not 8853 | | exist at this address. 8854 ----------------------------------------------------------------- 8855 Target removed| 0204 | The requested ITN has been removed and 8856 | |no forwarding address is provided. 8857 ----------------------------------------------------------------- 8858 Unsupported | 0205 | The requested iSCSI version range is 8859 version | | not supported by the target. 8860 ----------------------------------------------------------------- 8861 Too many | 0206 | Too many connections on this SSID. 8862 connections | | 8863 ----------------------------------------------------------------- 8864 Missing | 0207 | Missing parameters (e.g., iSCSI 8865 parameter | | Initiator and/or Target Name). 8866 ----------------------------------------------------------------- 8867 Can't include | 0208 | Target does not support session 8868 in session | | spanning to this connection (address). 8869 ----------------------------------------------------------------- 8870 Session type | 0209 | Target does not support this type of 8871 not supported | | of session or not from this Initiator. 8872 ----------------------------------------------------------------- 8873 Session does | 020a | Attempt to add a connection 8874 not exist | | to a non-existent session. 8875 ----------------------------------------------------------------- 8876 Invalid during| 020b | Invalid Request type during Login. 8877 login | | 8878 ----------------------------------------------------------------- 8879 Target error | 0300 | Target hardware or software error. 8880 ----------------------------------------------------------------- 8881 Service | 0301 | The iSCSI service or target is not 8882 unavailable | | currently operational. 8883 ----------------------------------------------------------------- 8884 Out of | 0302 | The target has insufficient session, 8885 resources | | connection, or other resources. 8886 ----------------------------------------------------------------- 8888 (*1)If the response T bit is 1 in both the request and the 8889 matching response, and the NSG is FullFeaturePhase in both the 8890 request and the matching response, the Login Phase is finished and 8891 the initiator may proceed to issue SCSI commands. 8893 If the Status Class is not 0, the initiator and target MUST close 8894 the TCP connection. 8896 If the target wishes to reject the login request for more than one 8897 reason, it should return the primary reason for the rejection. 8899 11.13.6. T (Transit) bit 8901 The T bit is set to 1 as an indicator of the end of the stage. If 8902 the T bit is set to 1 and NSG is FullFeaturePhase, then this is 8903 also the Final Login Response (see Chapter 5). A T bit of 0 8904 indicates a "partial" response, which means "more negotiation 8905 needed". 8907 A login response with a T bit set to 1 MUST NOT contain key=value 8908 pairs that may require additional answers from the initiator 8909 within the same stage. 8911 If the status class is 0, the T bit MUST NOT be set to 1 if the T 8912 bit in the request was set to 0. 8914 11.13.7. C (Continue) Bit 8916 When set to 1, indicates that the text (set of key=value pairs) in 8917 this Login Response is not complete (it will be continued on 8918 subsequent Login Responses); otherwise, it indicates that this 8919 Login Response ends a set of key=value pairs. A Login Response 8920 with the C bit set to 1 MUST have the T bit set to 0. 8922 11.13.8. Login Parameters 8924 The target MUST provide some basic parameters in order to enable 8925 the initiator to determine if it is connected to the correct port 8926 and the initial text parameters for the security exchange. 8928 All the rules specified in Section 11.11.6 for text responses also 8929 hold for login responses. Keys and their explanations are listed 8930 in Chapter 11 (security negotiation keys) and Chapter 12 8931 (operational parameter negotiation keys). All keys in Section 13, 8932 except for the X extension formats, MUST be supported by iSCSI 8933 initiators and targets. Keys in Section 12, only need to be 8934 supported when the function to which they refer is mandatory to 8935 implement. 8937 11.14. Logout Request 8939 The Logout request is used to perform a controlled closing of a 8940 connection. 8942 An initiator MAY use a logout request to remove a connection from 8943 a session or to close an entire session. 8945 After sending the Logout request PDU, an initiator MUST NOT send 8946 any new iSCSI requests on the closing connection. If the Logout 8947 request is intended to close the session, new iSCSI requests MUST 8948 NOT be sent on any of the connections participating in the 8949 session. 8951 When receiving a Logout request with the reason code of "close the 8952 connection" or "close the session", the target MUST terminate all 8953 pending commands, whether acknowledged via ExpCmdSN or not, on 8954 that connection or session respectively. 8956 When receiving a Logout request with the reason code "remove 8957 connection for recovery", the target MUST discard all requests not 8958 yet acknowledged via ExpCmdSN that were issued on the specified 8959 connection, and suspend all data/status/R2T transfers on behalf of 8960 pending commands on the specified connection. 8962 The target then issues the Logout response and half-closes the TCP 8963 connection (sends FIN). After receiving the Logout response and 8964 attempting to receive the FIN (if still possible), the initiator 8965 MUST completely close the logging-out connection. For the 8966 terminated commands, no additional responses should be expected. 8968 A Logout for a CID may be performed on a different transport 8969 connection when the TCP connection for the CID has already been 8970 terminated. In such a case, only a logical "closing" of the iSCSI 8971 connection for the CID is implied with a Logout. 8973 All commands that were not terminated or not completed (with 8974 status) and acknowledged when the connection is closed completely 8975 can be reassigned to a new connection if the target supports 8976 connection recovery. 8978 If an initiator intends to start recovery for a failing 8979 connection, it MUST use the Logout request to "clean-up" the 8980 target end of a failing connection and enable recovery to start, 8981 or the Login request with a non-zero TSIH and the same CID on a 8982 new connection for the same effect. In sessions with a single 8983 connection, the connection can be closed and then a new connection 8984 reopened. A connection reinstatement login can be used for 8985 recovery (see Section 5.3.4 - "Connection Reinstatement"). 8987 A successful completion of a logout request with the reason code 8988 of "close the connection" or "remove the connection for recovery" 8989 results at the target in the discarding of unacknowledged commands 8990 received on the connection being logged out. These are commands 8991 that have arrived on the connection being logged out, but have not 8992 been delivered to SCSI because one or more commands with a smaller 8993 CmdSN has not been received by iSCSI. See Section 3.2.2.1 - 8994 "Command Numbering and Acknowledging". The resulting holes in the 8995 command sequence numbers will have to be handled by appropriate 8996 recovery (see Chapter 6) unless the session is also closed. 8998 The entire logout discussion in this section is also applicable 8999 for an implicit Logout realized by way of a connection 9000 reinstatement or session reinstatement. When a Login Request 9001 performs an implicit Logout, the implicit Logout is performed as 9002 if having the reason codes specified below: 9004 Reason code Type of implicit Logout 9006 ------------------------------------------- 9008 0 session reinstatement 9010 1 connection reinstatement when the operational 9011 ErrorRecoveryLevel < 2 9013 2 connection reinstatement when the operational 9014 ErrorRecoveryLevel = 2 9016 Byte/ 0 | 1 | 2 | 3 | 9017 / | | | | 9018 |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| 9019 +---------------+---------------+---------------+--------------+ 9020 0|.|I| 0x06 |1| Reason Code | Reserved | 9021 +---------------+---------------+---------------+--------------+ 9022 4|TotalAHSLength | DataSegmentLength | 9023 +--------------------------------------------------------------+ 9024 8/ Reserved / 9025 +/ / 9026 +---------------+---------------+---------------+--------------+ 9027 16| Initiator Task Tag | 9028 +---------------+---------------+---------------+--------------+ 9029 20| CID or Reserved | Reserved | 9030 +---------------+---------------+---------------+--------------+ 9031 24| CmdSN | 9032 +---------------+---------------+---------------+--------------+ 9033 28| ExpStatSN | 9034 +---------------+---------------+---------------+--------------+ 9035 32/ Reserved / 9036 +/ / 9037 +---------------+---------------+---------------+--------------+ 9038 48| Header-Digest (Optional) | 9039 +---------------+---------------+---------------+--------------+ 9041 11.14.1. Reason Code 9043 Reason Code indicates the reason for Logout as follows: 9045 0 - close the session. All commands associated with the 9046 session (if any) are terminated. 9048 1 - close the connection. All commands associated with 9049 connection (if any) are terminated. 9051 2 - remove the connection for recovery. Connection is closed 9052 and all commands associated with it, if any, are to be 9053 prepared for a new allegiance. 9055 All other values are reserved. 9057 11.14.2. TotalAHSLength and DataSegmentLength 9059 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9061 11.14.3. CID 9063 This is the connection ID of the connection to be closed 9064 (including closing the TCP stream). This field is only valid if 9065 the reason code is not "close the session". 9067 11.14.4. ExpStatSN 9069 This is the last ExpStatSN value for the connection to be closed. 9071 11.14.5. Implicit termination of tasks 9073 A target implicitly terminates the active tasks due to the iSCSI 9074 protocol in the following cases: 9076 When a connection is implicitly or explicitly logged out with 9077 the reason code of "Close the connection" and there are 9078 active tasks allegiant to that connection. 9080 When a connection fails and eventually the connection state 9081 times out (state transition M1 in Section 7.2.2 - "State 9082 Transition Descriptions for Initiators and Targets") and 9083 there are active tasks allegiant to that connection. 9085 When a successful recovery Logout is performed while there are 9086 active tasks allegiant to that connection, and those tasks 9087 eventually time out after the Time2Wait and Time2Retain 9088 periods without allegiance reassignment. 9090 When a connection is implicitly or explicitly logged out with 9091 the reason code of "Close the session" and there are active 9092 tasks in that session. 9094 If the tasks terminated in any of the above cases are SCSI tasks, 9095 they must be internally terminated as if with CHECK CONDITION 9096 status. This status is only meaningful for appropriately handling 9097 the internal SCSI state and SCSI side effects with respect to 9098 ordering because this status is never communicated back as a 9099 terminating status to the initiator. However additional actions 9100 may have to be taken at SCSI level depending on the SCSI context 9101 as defined by the SCSI standards (e.g., queued commands and ACA, 9102 UA for the next command on the I_T nexus in cases a), b), and c), 9103 after the tasks are terminated, the target MUST report a Unit 9104 Attention condition on the next command processed on any 9105 connection for each affected I_T_L nexus with the status of CHECK 9106 CONDITION, and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS 9107 CLEARED BY ISCSI PROTOCOL EVENT" - etc. - see [SAM4] and [SPC3]). 9109 11.15. Logout Response 9111 The logout response is used by the target to indicate if the 9112 cleanup operation for the connection(s) has completed. 9114 After Logout, the TCP connection referred by the CID MUST be 9115 closed at both ends (or all connections must be closed if the 9116 logout reason was session close). 9118 Byte/ 0 | 1 | 2 | 3 | 9119 / | | | | 9120 |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| 9121 +---------------+---------------+---------------+--------------+ 9122 0|.|.| 0x26 |1| Reserved | Response | Reserved | 9123 +---------------+---------------+---------------+--------------+ 9124 4|TotalAHSLength | DataSegmentLength | 9125 +--------------------------------------------------------------+ 9126 8/ Reserved / 9127 +/ / 9128 +---------------+---------------+---------------+--------------+ 9129 16| Initiator Task Tag | 9130 +---------------+---------------+---------------+--------------+ 9131 20| Reserved | 9132 +---------------+---------------+---------------+--------------+ 9133 24| StatSN | 9134 +---------------+---------------+---------------+--------------+ 9135 28| ExpCmdSN | 9136 +---------------+---------------+---------------+--------------+ 9137 32| MaxCmdSN | 9138 +---------------+---------------+---------------+--------------+ 9139 36| Reserved | 9140 +--------------------------------------------------------------+ 9141 40| Time2Wait | Time2Retain | 9142 +---------------+---------------+---------------+--------------+ 9143 44| Reserved | 9144 +---------------+---------------+---------------+--------------+ 9145 48| Header-Digest (Optional) | 9146 +---------------+---------------+---------------+--------------+ 9148 11.15.1. Response 9150 Logout response: 9152 0 - connection or session closed successfully. 9154 1 - CID not found. 9156 2 - connection recovery is not supported. If Logout reason 9157 code was recovery and target does not support it as 9158 indicated by the ErrorRecoveryLevel. 9160 3 - cleanup failed for various reasons. 9162 11.15.2. TotalAHSLength and DataSegmentLength 9164 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9166 11.15.3. Time2Wait 9168 If the Logout response code is 0 and if the operational 9169 ErrorRecoveryLevel is 2, this is the minimum amount of time, in 9170 seconds, to wait before attempting task reassignment. If the 9171 Logout response code is 0 and if the operational 9172 ErrorRecoveryLevel is less than 2, this field is to be ignored. 9174 This field is invalid if the Logout response code is 1. 9176 If the Logout response code is 2 or 3, this field specifies the 9177 minimum time to wait before attempting a new implicit or explicit 9178 logout. 9180 If Time2Wait is 0, the reassignment or a new Logout may be 9181 attempted immediately. 9183 11.15.4. Time2Retain 9185 If the Logout response code is 0 and if the operational 9186 ErrorRecoveryLevel is 2, this is the maximum amount of time, in 9187 seconds, after the initial wait (Time2Wait), the target waits for 9188 the allegiance reassignment for any active task after which the 9189 task state is discarded. If the Logout response code is 0 and if 9190 the operational ErrorRecoveryLevel is less than 2, this field is 9191 to be ignored. 9193 This field is invalid if the Logout response code is 1. 9195 If the Logout response code is 2 or 3, this field specifies the 9196 maximum amount of time, in seconds, after the initial wait 9197 (Time2Wait), the target waits for a new implicit or explicit 9198 logout. 9200 If it is the last connection of a session, the whole session state 9201 is discarded after Time2Retain. 9203 If Time2Retain is 0, the target has already discarded the 9204 connection (and possibly the session) state along with the task 9205 states. No reassignment or Logout is required in this case. 9207 11.16. SNACK Request 9209 Byte/ 0 | 1 | 2 | 3 | 9210 / | | | 9211 | 9212 |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| 9213 +---------------+---------------+---------------+--------------+ 9214 0|.|.| 0x10 |1|.|.|.| Type | Reserved | 9215 +---------------+---------------+---------------+--------------+ 9216 4|TotalAHSLength | DataSegmentLength | 9217 +---------------+---------------+---------------+--------------+ 9218 8| LUN or Reserved | 9219 + + 9220 12| | 9221 +---------------+---------------+---------------+--------------+ 9222 16| Initiator Task Tag or 0xffffffff | 9223 +---------------+---------------+---------------+--------------+ 9224 20| Target Transfer Tag or SNACK Tag or 0xffffffff | 9225 +---------------+---------------+---------------+--------------+ 9226 24| Reserved | 9227 +---------------+---------------+---------------+--------------+ 9228 28| ExpStatSN | 9229 +---------------+---------------+---------------+--------------+ 9230 32/ Reserved / 9231 +/ / 9232 +---------------+---------------+---------------+--------------+ 9233 40| BegRun | 9234 +--------------------------------------------------------------+ 9235 44| RunLength | 9236 +--------------------------------------------------------------+ 9237 48| Header-Digest (Optional) | 9238 +---------------+---------------+---------------+--------------+ 9240 If the implementation supports ErrorRecoveryLevel greater than 9241 zero, it MUST support all SNACK types. 9243 The SNACK is used by the initiator to request the retransmission 9244 of numbered-responses, data, or R2T PDUs from the target. The 9245 SNACK request indicates the numbered-responses or data "runs" 9246 whose retransmission is requested by the target, where the run 9247 starts with the first StatSN, DataSN, or R2TSN whose 9248 retransmission is requested and indicates the number of Status, 9249 Data, or R2T PDUs requested including the first. 0 has special 9250 meaning when used as a starting number and length: 9252 - When used in RunLength, it means all PDUs starting with the 9253 initial. 9255 - When used in both BegRun and RunLength, it means all 9256 unacknowledged PDUs. 9258 The numbered-response(s) or R2T(s), requested by a SNACK, MUST be 9259 delivered as exact replicas of the ones that the target 9260 transmitted originally except for the fields ExpCmdSN, MaxCmdSN, 9261 and ExpDataSN, which MUST carry the current values. 9262 R2T(s)requested by SNACK MUST also carry the current value of 9263 StatSN. 9265 The numbered Data-In PDUs, requested by a Data SNACK MUST be 9266 delivered as exact replicas of the ones that the target 9267 transmitted originally except for the fields ExpCmdSN and 9268 MaxCmdSN, which MUST carry the current values and except for 9269 resegmentation (see Resegmentation). 9271 Any SNACK that requests a numbered-response, Data, or R2T that was 9272 not sent by the target or was already acknowledged by the 9273 initiator, MUST be rejected with a reason code of "Protocol 9274 error". 9276 11.16.1. Type 9278 This field encodes the SNACK function as follows: 9280 0-Data/R2T SNACK - requesting retransmission of one or more 9281 Data-In or R2T PDUs. 9283 1-Status SNACK - requesting retransmission of one or more 9284 numbered responses. 9286 2-DataACK - positively acknowledges Data-In PDUs. 9288 3-R-Data SNACK - requesting retransmission of Data-In PDUs 9289 with possible resegmentation and status tagging. 9291 All other values are reserved. 9293 Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST 9294 precede status acknowledgement for the given command. 9296 11.16.2. Data Acknowledgement 9298 If an initiator operates at ErrorRecoveryLevel 1 or higher, it 9299 MUST issue a SNACK of type DataACK after receiving a Data-In PDU 9300 with the A bit set to 1. However, if the initiator has detected 9301 holes in the input sequence, it MUST postpone issuing the SNACK of 9302 type DataACK until the holes are filled. An initiator MAY ignore 9303 the A bit if it deems that the bit is being set aggressively by 9304 the target (i.e., before the MaxBurstLength limit is 9305 reached). 9307 The DataACK is used to free resources at the target and not to 9308 request or imply data retransmission. 9310 An initiator MUST NOT request retransmission for any data it had 9311 already acknowledged. 9313 11.16.3. Resegmentation 9315 If the initiator MaxRecvDataSegmentLength changed between the 9316 original transmission and the time the initiator requests 9317 retransmission, the initiator MUST issue a R-Data SNACK (see 9318 Type). With R-Data SNACK, the initiator indicates that it discards 9319 all the unacknowledged data and expects the target to resend it. 9320 It also expects resegmentation. In this case, the retransmitted 9321 Data-In PDUs MAY be different from the ones originally sent in 9322 order to reflect changes in MaxRecvDataSegmentLength. Their DataSN 9323 starts with the BegRun of the last DataACK received by the target 9324 if any was received; otherwise it starts with 0 and is increased 9325 by 1 for each resent Data-In PDU. 9327 A target that has received a R-Data SNACK MUST return a SCSI 9328 Response that contains a copy of the SNACK Tag field from the R- 9329 Data SNACK in the SCSI Response SNACK Tag field as its last or 9330 only Response. For example, if it has already sent a response 9331 containing another value in the SNACK Tag field or had the status 9332 included in the last Data-In PDU, it must send a new SCSI Response 9333 PDU. If a target sends more than one SCSI Response PDU due to this 9334 rule, all SCSI responses must carry the same StatSN (see SNACK ). 9335 If an initiator attempts to recover a lost SCSI Response (with a 9336 Status-SNACK, see Type) when more than one response has been sent, 9337 the target will send the SCSI Response with the latest content 9338 known to the target, including the last SNACK Tag for the command. 9340 For considerations in allegiance reassignment of a task to a 9341 connection with a different MaxRecvDataSegmentLength, refer to 9342 Section 6.2.2 - "Allegiance Reassignment". 9344 11.16.4. Initiator Task Tag 9346 For Status SNACK and DataACK, the Initiator Task Tag MUST be set 9347 to the reserved value 0xffffffff. In all other cases, the 9348 Initiator Task Tag field MUST be set to the Initiator Task Tag of 9349 the referenced command. 9351 11.16.5. Target Transfer Tag or SNACK Tag 9353 For an R-Data SNACK, this field MUST contain a value that is 9354 different from 0 or 0xffffffff and is unique for the task 9355 (identified by the Initiator Task Tag). This value MUST be copied 9356 by the iSCSI target in the last or only SCSI Response PDU it 9357 issues for the command. 9359 For DataACK, the Target Transfer Tag MUST contain a copy of the 9360 Target Transfer Tag and LUN provided with the SCSI Data-In PDU 9361 with the A bit set to 1. 9363 In all other cases, the Target Transfer Tag field MUST be set to 9364 the reserved value of 0xffffffff. 9366 11.16.6. BegRun 9368 The DataSN, R2TSN, or StatSN of the first PDU whose retransmission 9369 is requested (Data/R2T and Status SNACK), or the next expected 9370 DataSN (DataACK SNACK). 9372 BegRun 0 when used in conjunction with RunLength 0 means resend 9373 all unacknowledged Data-In, R2T or Response PDUs. 9375 BegRun MUST be 0 for a R-Data SNACK. 9377 11.16.7. RunLength 9379 The number of PDUs whose retransmission is requested. 9381 RunLength 0 signals that all Data-In, R2T, or Response PDUs 9382 carrying the numbers equal to or greater than BegRun have to be 9383 resent. 9385 The RunLength MUST also be 0 for a DataACK SNACK in addition to R- 9386 Data SNACK. 9388 11.17. Reject 9390 Byte/ 0 | 1 | 2 | 3 | 9391 / | | | | 9392 |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| 9393 +---------------+---------------+---------------+--------------+ 9394 0|.|.| 0x3f |1| Reserved | Reason | Reserved | 9395 +---------------+---------------+---------------+--------------+ 9396 4|TotalAHSLength | DataSegmentLength | 9397 +---------------+---------------+---------------+--------------+ 9398 8/ Reserved / 9399 +/ / 9400 +---------------+---------------+---------------+--------------+ 9401 16| 0xffffffff | 9402 +---------------+---------------+---------------+--------------+ 9403 20| Reserved | 9404 +---------------+---------------+---------------+--------------+ 9405 24| StatSN | 9406 +---------------+---------------+---------------+--------------+ 9407 28| ExpCmdSN | 9408 +---------------+---------------+---------------+--------------+ 9409 32| MaxCmdSN | 9410 +---------------+---------------+---------------+--------------+ 9411 36| DataSN/R2TSN or Reserved | 9412 +---------------+---------------+---------------+--------------+ 9413 40| Reserved | 9414 +---------------+---------------+---------------+--------------+ 9415 44| Reserved | 9416 +---------------+---------------+---------------+--------------+ 9417 48| Header-Digest (Optional) | 9418 +---------------+---------------+---------------+--------------+ 9419 xx/ Complete Header of Bad PDU / 9420 +/ / 9421 +---------------+---------------+---------------+--------------+ 9422 yy/Vendor specific data (if any) / 9423 / / 9424 +---------------+---------------+---------------+--------------+ 9425 zz| Data-Digest (Optional) | 9426 +---------------+---------------+---------------+--------------+ 9428 Reject is used to indicate an iSCSI error condition (protocol, 9429 unsupported option, etc.). 9431 11.17.1. Reason 9433 The reject Reason is coded as follows: 9435 +------+----------------------------------------+----------------+ 9436 | Code | Explanation |Can the original| 9437 | (hex)| |PDU be re-sent? | 9438 +------+----------------------------------------+----------------+ 9439 | 0x01 | Reserved | no | 9440 | | | | 9441 | 0x02 | Data (payload) Digest Error | yes (Note 1) | 9442 | | | | 9443 | 0x03 | SNACK Reject | yes | 9444 | | | | 9445 | 0x04 | Protocol Error (e.g., SNACK request for| no | 9446 | | a status that was already acknowledged)| | 9447 | | | | 9448 | 0x05 | Command not supported | no | 9449 | | | | 9450 | 0x06 | Immediate Command Reject - too many | yes | 9451 | | immediate commands | | 9452 | | | | 9453 | 0x07 | Task in progress | no | 9454 | | | | 9455 | 0x08 | Invalid Data ACK | no | 9456 | | | | 9457 | 0x09 | Invalid PDU field | no (Note 2) | 9458 | | | | 9459 | 0x0a | Long Operation Reject - Can't generate | yes | 9460 | | Target Transfer Tag - out of resources | | 9461 | | | | 9462 | 0x0c | Waiting for Logout | no | 9463 +------+----------------------------------------+----------------+ 9465 Note 1: For iSCSI, Data-Out PDU retransmission is only done if the 9466 target requests retransmission with a recovery R2T. However, if 9467 this is the data digest error on immediate data, the initiator may 9468 choose to retransmit the whole PDU including the immediate data. 9470 Note 2: A target should use this reason code for all invalid 9471 values of PDU fields that are meant to describe a task, a 9472 response, or a data transfer. Some examples are invalid TTT/ITT, 9473 buffer offset, LUN qualifying a TTT, and an invalid sequence 9474 number in a SNACK. 9476 Note 3: Reason code 0x0b ("Negotiation reset") defined in 9477 [RFC3720] is deprecated and MUST NOT be used by implementations. 9478 An implementation receiving reason code 0x0b MUST treat it as a 9479 negotiation failure that terminates the Login Phase and the TCP 9480 connection, as specified in Section 7.12. 9482 All other values for Reason are reserved. 9484 In all the cases in which a pre-instantiated SCSI task is 9485 terminated because of the reject, the target MUST issue a proper 9486 SCSI command response with CHECK CONDITION as described in Section 9487 11.4.3. In these cases in which a status for the SCSI task was 9488 already sent before the reject, no additional status is required. 9489 If the error is detected while data from the initiator is still 9490 expected (i.e., the command PDU did not contain all the data and 9491 the target has not received a Data-out PDU with the Final bit set 9492 to 1 for the unsolicited data, if any, and all outstanding R2Ts, 9493 if any), the target MUST wait until it receives the last expected 9494 Data-out PDUs with the F bit set to 1 before sending the Response 9495 PDU. 9497 For additional usage semantics of Reject PDU, see Section 6.3 - 9498 "Usage Of Reject PDU in Recovery". 9500 11.17.2. DataSN/R2TSN 9502 This field is only valid if the rejected PDU is a Data/R2T SNACK 9503 and the Reject reason code is "Protocol error" (see SNACK). The 9504 DataSN/R2TSN is the next Data/R2T sequence number that the target 9505 would send for the task, if any. 9507 11.17.3. StatSN, ExpCmdSN and MaxCmdSN 9509 These fields carry their usual values and are not related to the 9510 rejected command. StatSN is advanced after a Reject. 9512 11.17.4. Complete Header of Bad PDU 9514 The target returns the header (not including digest) of the PDU in 9515 error as the data of the response. 9517 11.18. NOP-Out 9519 Byte/ 0 | 1 | 2 | 3 | 9520 / | | | | 9521 |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| 9522 +---------------+---------------+---------------+--------------+ 9523 0|.|I| 0x00 |1| Reserved | 9524 +---------------+---------------+---------------+--------------+ 9525 4|TotalAHSLength | DataSegmentLength | 9526 +---------------+---------------+---------------+--------------+ 9527 8| LUN or Reserved | 9528 + + 9529 12| | 9530 +---------------+---------------+---------------+--------------+ 9531 16| Initiator Task Tag or 0xffffffff | 9532 +---------------+---------------+---------------+--------------+ 9533 20| Target Transfer Tag or 0xffffffff | 9534 +---------------+---------------+---------------+--------------+ 9535 24| CmdSN | 9536 +---------------+---------------+---------------+--------------+ 9537 28| ExpStatSN | 9538 +---------------+---------------+---------------+--------------+ 9539 32/ Reserved / 9540 +/ / 9541 +---------------+---------------+---------------+--------------+ 9542 48| Header-Digest (Optional) | 9543 +---------------+---------------+---------------+--------------+ 9544 / DataSegment - Ping Data (optional) / 9545 +/ / 9546 +---------------+---------------+---------------+--------------+ 9547 | Data-Digest (Optional) | 9548 +---------------+---------------+---------------+--------------+ 9550 A NOP-Out may be used by an initiator as a "ping request" to 9551 verify that a connection/session is still active and all its 9553 components are operational. The NOP-In response is the "ping 9554 echo". 9556 A NOP-Out is also sent by an initiator in response to a NOP-In. 9558 A NOP-Out may also be used to confirm a changed ExpStatSN if 9559 another PDU will not be available for a long time. 9561 Upon receipt of a NOP-In with the Target Transfer Tag set to a 9562 valid value (not the reserved 0xffffffff), the initiator MUST 9563 respond with a NOP-Out. In this case, the NOP-Out Target Transfer 9564 Tag MUST contain a copy of the NOP-In Target Transfer Tag. 9566 11.18.1. Initiator Task Tag 9568 The NOP-Out MUST have the Initiator Task Tag set to a valid value 9569 only if a response in the form of NOP-In is requested (i.e., the 9570 NOP-Out is used as a ping request). Otherwise, the Initiator Task 9571 Tag MUST be set to 0xffffffff. 9573 When a target receives the NOP-Out with a valid Initiator Task 9574 Tag, it MUST respond with a Nop-In Response (see Login and Full 9575 Feature Phase Negotiation). 9577 If the Initiator Task Tag contains 0xffffffff, the I bit MUST be 9578 set to 1 and the CmdSN is not advanced after this PDU is sent. 9580 11.18.2. Target Transfer Tag 9582 A target assigned identifier for the operation. 9584 The NOP-Out MUST only have the Target Transfer Tag set if it is 9585 issued in response to a NOP-In with a valid Target Transfer Tag. 9586 In this case, it copies the Target Transfer Tag from the NOP-In 9587 PDU. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff. 9589 When the Target Transfer Tag is set to a value other than 9590 0xffffffff, the LUN field MUST also be copied from the NOP-In. 9592 11.18.3. Ping Data 9594 Ping data are reflected in the NOP-In Response. The length of the 9595 reflected data are limited to MaxRecvDataSegmentLength. The length 9596 of ping data are indicated by the DataSegmentLength. 0 is a valid 9597 value for the DataSegmentLength and indicates the absence of ping 9598 data. 9600 11.19. NOP-In 9602 Byte/ 0 | 1 | 2 | 3 | 9603 / | | | | 9604 |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| 9605 +---------------+---------------+---------------+--------------+ 9606 0|.|.| 0x20 |1| Reserved | 9607 +---------------+---------------+---------------+--------------+ 9608 4|TotalAHSLength | DataSegmentLength | 9609 +---------------+---------------+---------------+--------------+ 9610 8| LUN or Reserved | 9611 + + 9612 12| | 9613 +---------------+---------------+---------------+--------------+ 9614 16| Initiator Task Tag or 0xffffffff | 9615 +---------------+---------------+---------------+--------------+ 9616 20| Target Transfer Tag or 0xffffffff | 9617 +---------------+---------------+---------------+--------------+ 9618 24| StatSN | 9619 +---------------+---------------+---------------+--------------+ 9620 28| ExpCmdSN | 9621 +---------------+---------------+---------------+--------------+ 9622 32| MaxCmdSN | 9623 +---------------+---------------+---------------+--------------+ 9624 36/ Reserved / 9625 +/ / 9626 +---------------+---------------+---------------+--------------+ 9627 48| Header-Digest (Optional) | 9628 +---------------+---------------+---------------+--------------+ 9629 / DataSegment - Return Ping Data / 9630 +/ / 9631 +---------------+---------------+---------------+--------------+ 9632 | Data-Digest (Optional) | 9633 +---------------+---------------+---------------+--------------+ 9635 NOP-In is either sent by a target as a response to a NOP-Out, as a 9636 "ping" to an initiator, or as a means to carry a changed ExpCmdSN 9637 and/or MaxCmdSN if another PDU will not be available for a long 9638 time (as determined by the target). 9640 When a target receives the NOP-Out with a valid Initiator Task Tag 9641 (not the reserved value 0xffffffff), it MUST respond with a NOP-In 9642 with the same Initiator Task Tag that was provided in the NOP-Out 9643 request. It MUST also duplicate up to the first 9644 MaxRecvDataSegmentLength bytes of the initiator provided Ping 9645 Data. For such a response, the Target Transfer Tag MUST be 9646 0xffffffff. 9648 Otherwise, when a target sends a NOP-In that is not a response to 9649 a Nop-Out received from the initiator, the Initiator Task Tag MUST 9650 be set to 0xffffffff and the Data Segment MUST NOT contain any 9651 data (DataSegmentLength MUST be 0). 9653 11.19.1. Target Transfer Tag 9655 If the target is responding to a NOP-Out, this is set to the 9656 reserved value 0xffffffff. 9658 If the target is sending a NOP-In as a Ping (intending to receive 9659 a corresponding NOP-Out), this field is set to a valid value (not 9660 the reserved 0xffffffff). 9662 If the target is initiating a NOP-In without wanting to receive a 9663 corresponding NOP-Out, this field MUST hold the reserved value of 9664 0xffffffff. 9666 11.19.2. StatSN 9668 The StatSN field will always contain the next StatSN. However, 9669 when the Initiator Task Tag is set to 0xffffffff StatSN for the 9670 connection is not advanced after this PDU is sent. 9672 11.19.3. LUN 9674 A LUN MUST be set to a correct value when the Target Transfer Tag 9675 is valid (not the reserved value 0xffffffff). 9677 12. iSCSI Security Text Keys and Authentication Methods 9679 Only the following keys are used during the SecurityNegotiation 9680 stage of the Login Phase: 9682 SessionType 9684 InitiatorName 9686 TargetName 9688 TargetAddress 9690 InitiatorAlias 9692 TargetAlias 9694 TargetPortalGroupTag 9696 AuthMethod and the keys used by the authentication methods 9697 specified under Section 12.1 along with all of their 9698 associated keys as well as Vendor Specific Authentication 9699 Methods. 9701 Other keys MUST NOT be used. 9703 SessionType, InitiatorName, TargetName, InitiatorAlias, 9704 TargetAlias, and TargetPortalGroupTag are described in Section 13 9705 as they can be used also in the OperationalNegotiation stage. 9707 All security keys have connection-wide applicability. 9709 12.1. AuthMethod 9711 Use: During Login - Security Negotiation 9712 Senders: Initiator and Target 9713 Scope: connection 9715 AuthMethod = 9717 The main item of security negotiation is the authentication method 9718 (AuthMethod). 9720 The authentication methods that can be used (appear in the list- 9721 of-values) are either those listed in the following table or are 9722 vendor-unique methods: 9724 +------------------------------------------------------------+ 9725 | Name | Description | 9726 +------------------------------------------------------------+ 9727 | KRB5 | Kerberos V5 - defined in [RFC4120] | 9728 +------------------------------------------------------------+ 9729 | SRP | Secure Remote Password | 9730 | | defined in [RFC2945] | 9731 +------------------------------------------------------------+ 9732 | CHAP | Challenge Handshake Authentication Protocol| 9733 | | defined in [RFC1994] | 9734 +------------------------------------------------------------+ 9735 | None | No authentication | 9736 +------------------------------------------------------------+ 9738 The AuthMethod selection is followed by an "authentication 9739 exchange" specific to the authentication method selected. 9741 The authentication method proposal may be made by either the 9742 initiator or the target. However the initiator MUST make the first 9743 step specific to the selected authentication method as soon as it 9744 is selected. It follows that if the target makes the 9745 authentication method proposal the initiator sends the first 9746 key(s) of the exchange together with its authentication method 9747 selection. 9749 The authentication exchange authenticates the initiator to the 9750 target, and optionally, the target to the initiator. 9751 Authentication is OPTIONAL to use but MUST be supported by the 9752 target and initiator. 9754 The initiator and target MUST implement CHAP. All other 9755 authentication methods are OPTIONAL. 9757 Private or public extension algorithms MAY also be negotiated for 9758 authentication methods. Whenever a private or public extension 9759 algorithm is part of the default offer (the offer made in absence 9760 of explicit administrative action) the implementer MUST ensure 9761 that CHAP is listed as an alternative in the default offer and 9762 "None" is not part of the default offer. 9764 Extension authentication methods MUST be named using one of the 9765 following two formats: 9767 i) Z-reversed.vendor.dns_name.do_something= 9768 ii) Z<#>= 9770 Authentication methods named using the Z- format are used as 9771 private extensions. Authentication methods named using the Z# 9772 format are used as public extensions that must be registered with 9773 IANA and MUST be described by a standards track RFC, an 9774 experimental RFC, or an informational RFC. 9776 For all of the public or private extension authentication methods, 9777 the method specific keys MUST conform to the format specified in 9778 Section 5.1 - "Text Format" for standard-label. 9780 To identify the vendor for private extension authentication 9781 methods, we suggest you use the reversed DNS-name as a prefix to 9782 the proper digest names. 9784 The part of digest-name following Z- and Z# MUST conform to the 9785 format for standard-label specified in Section 5.1 - "Text 9786 Format". 9788 Support for public or private extension authentication methods is 9789 OPTIONAL. 9791 The following subsections define the specific exchanges for each 9792 of the standardized authentication methods. As mentioned earlier 9793 the first step is always done by the initiator. 9795 12.1.1. Kerberos 9797 For KRB5 (Kerberos V5) [RFC4120] and [RFC1964], the initiator MUST 9798 use: 9800 KRB_AP_REQ= 9802 where KRB_AP_REQ is the client message as defined in [RFC4120]. 9804 The default principal name assumed by an iSCSI initiator or target 9805 (prior to any administrative configuration action) MUST be the 9806 iSCSI Initiator Name or iSCSI Target Name respectively, prefixed 9807 by the string "iscsi/". 9809 If the initiator authentication fails, the target MUST respond 9810 with a Login reject with "Authentication Failure" status. 9811 Otherwise, if the initiator has selected the mutual authentication 9812 option (by setting MUTUAL-REQUIRED in the ap-options field of the 9813 KRB_AP_REQ), the target MUST reply with: 9815 KRB_AP_REP= 9817 where KRB_AP_REP is the server's response message as defined in 9818 [RFC4120]. 9820 If mutual authentication was selected and target authentication 9821 fails, the initiator MUST close the connection. 9823 KRB_AP_REQ and KRB_AP_REP are binary-values and their binary 9824 length (not the length of the character string that represents 9825 them in encoded form) MUST NOT exceed 65536 bytes. 9827 12.1.2. Secure Remote Password (SRP) 9829 For SRP [RFC2945], the initiator MUST use: 9831 SRP_U= TargetAuth=Yes /* or TargetAuth=No */ 9833 The target MUST answer with a Login reject with the "Authorization 9834 Failure" status or reply with: 9836 SRP_GROUP= SRP_s= 9838 Where G1,G2... are proposed groups, in order of preference. 9840 The initiator MUST either close the connection or continue with: 9842 SRP_A= SRP_GROUP= 9844 Where G is one of G1,G2... that were proposed by the target. 9846 The target MUST answer with a Login reject with the 9847 "Authentication Failure" status or reply with: 9849 SRP_B= 9851 The initiator MUST close the connection or continue with: 9853 SRP_M= 9855 If the initiator authentication fails, the target MUST answer with 9856 a Login reject with "Authentication Failure" status. Otherwise, if 9857 the initiator sent TargetAuth=Yes in the first message (requiring 9858 target authentication), the target MUST reply with: 9860 SRP_HM= 9862 If the target authentication fails, the initiator MUST close the 9863 connection. 9865 Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] 9866 (using the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn 9867 stands for G1,G2...) are identifiers of SRP groups specified in 9868 [RFC3723]. G, Gn, and U are text strings, s,A,B,M, and H(A | M | 9869 K) are binary-values. The length of s,A,B,M and H(A | M | K) in 9870 binary form (not the length of the character string that 9871 represents them in encoded form) MUST NOT exceed 1024 bytes. 9873 For the SRP_GROUP, all the groups specified in [RFC3723] up to 9874 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be 9875 supported by initiators and targets. To guarantee 9876 interoperability, targets MUST always offer "SRP-1536" as one of 9877 the proposed groups. 9879 12.1.3. Challenge Handshake Authentication Protocol (CHAP) 9881 For CHAP [RFC1994], the initiator MUST use: 9883 CHAP_A= 9885 Where A1,A2... are proposed algorithms, in order of preference. 9887 The target MUST answer with a Login reject with the 9888 "Authentication Failure" status or reply with: 9890 CHAP_A= CHAP_I= CHAP_C= 9892 Where A is one of A1,A2... that were proposed by the initiator. 9894 The initiator MUST continue with: 9896 CHAP_N= CHAP_R= 9898 or, if it requires target authentication, with: 9900 CHAP_N= CHAP_R= CHAP_I= CHAP_C= 9902 If the initiator authentication fails, the target MUST answer with 9903 a Login reject with "Authentication Failure" status. Otherwise, if 9904 the initiator required target authentication, the target MUST 9905 either answer with a Login reject with "Authentication Failure" or 9906 reply with: 9908 CHAP_N= CHAP_R= 9910 If target authentication fails, the initiator MUST close the 9911 connection. 9913 Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, 9914 Algorithm, Identifier, Challenge, and Response as defined in 9915 [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C 9916 and R are binary-values and their binary length (not the length of 9917 the character string that represents them in encoded form) MUST 9918 NOT exceed 1024 bytes. 9920 For the Algorithm, as stated in [RFC1994], one value is required 9921 to be implemented: 9923 5 (CHAP with MD5) 9925 To guarantee interoperability, initiators MUST always offer it as 9926 one of the proposed algorithms. 9928 13. Login/Text Operational Text Keys 9930 Some session specific parameters MUST only be carried on the 9931 leading connection and cannot be changed after the leading 9932 connection login (e.g., MaxConnections, the maximum number of 9933 connections). This holds for a single connection session with 9934 regard to connection restart. The keys that fall into this 9935 category have the use: LO (Leading Only). 9937 Keys that can only be used during login have the use: IO 9938 (initialize only), while those that can be used in both the Login 9939 Phase and Full Feature Phase have the use: ALL. 9941 Keys that can only be used during Full Feature Phase use FFPO 9942 (Full Feature Phase only). 9944 Keys marked as Any-Stage may also appear in the 9945 SecurityNegotiation stage while all other keys described in this 9946 chapter are operational keys. 9948 Keys that do not require an answer are marked as Declarative. 9950 Key scope is indicated as session-wide (SW) or connection-only 9951 (CO). 9953 Result function, wherever mentioned, states the function that can 9954 be applied to check the validity of the responder selection. 9955 Minimum means that the selected value cannot exceed the offered 9956 value. Maximum means that the selected value cannot be lower than 9957 the offered value. AND means that the selected value must be a 9958 possible result of a Boolean "and" function with an arbitrary 9959 Boolean value (e.g., if the offered value is No the selected value 9960 must be No). OR means that the selected value must be a possible 9961 result of a Boolean "or" function with an arbitrary Boolean value 9962 (e.g., if the offered value is Yes the selected value must be 9963 Yes). 9965 13.1. HeaderDigest and DataDigest 9967 Use: IO 9968 Senders: Initiator and Target 9969 Scope: CO 9970 HeaderDigest = 9971 DataDigest = 9973 Default is None for both HeaderDigest and DataDigest. 9975 Digests enable the checking of end-to-end, non-cryptographic data 9976 integrity beyond the integrity checks provided by the link layers 9977 and the covering of the whole communication path including all 9978 elements that may change the network level PDUs such as routers, 9979 switches, and proxies. 9981 The following table lists cyclic integrity checksums that can be 9982 negotiated for the digests and that MUST be implemented by every 9983 iSCSI initiator and target. These digest options only have error 9984 detection significance. 9986 +---------------------------------------------+ 9987 | Name | Description | Generator | 9988 +---------------------------------------------+ 9989 | CRC32C | 32 bit CRC |0x11edc6f41| 9990 +---------------------------------------------+ 9991 | None | no digest | 9992 +---------------------------------------------+ 9994 The generator polynomial for this digest is given in hex-notation 9995 (e.g., 0x3b stands for 0011 1011 and the polynomial is 9996 x**5+X**4+x**3+x+1). 9998 When the Initiator and Target agree on a digest, this digest MUST 9999 be used for every PDU in Full Feature Phase. 10001 Padding bytes, when present in a segment covered by a CRC, SHOULD 10002 be set to 0 and are included in the CRC. 10004 The CRC MUST be calculated by a method that produces the same 10005 results as the following process: 10007 - The PDU bits are considered as the coefficients of a 10008 polynomial M(x) of degree n-1; bit 7 of the lowest numbered 10009 byte is considered the most significant bit (x^n-1), 10011 followed by bit 6 of the lowest numbered byte through bit 0 10012 of the highest numbered byte (x^0). 10014 - The most significant 32 bits are complemented. 10016 - The polynomial is multiplied by x^32 then divided by G(x). 10017 The generator polynomial produces a remainder R(x) of degree 10018 <= 31. 10020 - The coefficients of R(x) are considered a 32 bit sequence. 10022 - The bit sequence is complemented and the result is the CRC. 10024 - The CRC bits are mapped into the digest word. The x^31 10025 coefficient in bit 7 of the lowest numbered byte of the 10026 digest continuing through to the byte up to the x^24 10027 coefficient in bit 0 of the lowest numbered byte, continuing 10028 with the x^23 coefficient in bit 7 of next byte through x^0 10029 in bit 0 of the highest numbered byte. 10031 - Computing the CRC over any segment (data or header) extended 10032 to include the CRC built using the generator 0x11edc6f41 10033 will always get the value 0x1c2d19ed as its final remainder 10034 (R(x)). This value is given here in its polynomial form 10035 (i.e., not mapped as the digest word). 10037 For a discussion about selection criteria for the CRC, see 10038 [RFC3385]. For a detailed analysis of the iSCSI polynomial, see 10039 [Castagnoli93]. 10041 Private or public extension algorithms MAY also be negotiated for 10042 digests. Whenever a private or public digest extension algorithm 10043 is part of the default offer (the offer made in absence of 10044 explicit administrative action) the implementer MUST ensure that 10045 CRC32C is listed as an alternative in the default offer and "None" 10046 is not part of the default offer. 10048 Extension digest algorithms MUST be named using one of the 10049 following two formats: 10051 iii) Y-reversed.vendor.dns_name.do_something= 10052 iv) Y<#>= 10054 Digests named using the Y- format are used for private purposes 10055 (unregistered). Digests named using the Y# format (public 10056 extension) must be registered with IANA and MUST be described by a 10057 standards track RFC, an experimental RFC, or an informational RFC. 10059 For private extension digests, to identify the vendor, we suggest 10060 you use the reversed DNS-name as a prefix to the proper digest 10061 names. 10063 The part of digest-name following Y- and Y# MUST conform to the 10064 format for standard-label specified in Section 6.1. 10066 Support for public or private extension digests is OPTIONAL. 10068 13.2. MaxConnections 10070 Use: LO 10071 Senders: Initiator and Target 10072 Scope: SW 10073 Irrelevant when: SessionType=Discovery 10075 MaxConnections= 10077 Default is 1. 10078 Result function is Minimum. 10080 Initiator and target negotiate the maximum number of connections 10081 requested/acceptable. 10083 13.3. SendTargets 10085 Use: FFPO 10086 Senders: Initiator 10087 Scope: SW 10089 For a complete description, see Appendix D. - "SendTargets 10090 Operation". 10092 13.4. TargetName 10094 Use: IO by initiator, FFPO by target - only as response to a 10095 SendTargets, Declarative, Any-Stage 10096 Senders: Initiator and Target 10097 Scope: SW 10099 TargetName= 10101 Examples: 10103 TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 10105 TargetName=eui.020000023B040506 10107 TargetName=naa.62004567BA64678D0123456789ABCDEF 10109 The initiator of the TCP connection MUST provide this key to the 10110 remote endpoint in the first login request if the initiator is not 10111 establishing a discovery session. The iSCSI Target Name specifies 10112 the worldwide unique name of the target. 10114 The TargetName key may also be returned by the "SendTargets" text 10115 request (which is its only use when issued by a target). 10117 TargetName MUST NOT be redeclared within the login phase. 10119 13.5. InitiatorName 10121 Use: IO, Declarative, Any-Stage 10122 Senders: Initiator 10123 Scope: SW 10125 InitiatorName= 10127 Examples: 10129 InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345 10131 InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90 10132 InitiatorName=naa.52004567BA64678D 10134 The initiator of the TCP connection MUST provide this key to the 10135 remote endpoint at the first Login of the Login Phase for every 10136 connection. The InitiatorName key enables the initiator to 10137 identify itself to the remote endpoint. 10139 InitiatorName MUST NOT be redeclared within the login phase. 10141 13.6. TargetAlias 10143 Use: ALL, Declarative, Any-Stage 10144 Senders: Target 10145 Scope: SW 10147 TargetAlias= 10149 Examples: 10151 TargetAlias=Bob-s Disk 10153 TargetAlias=Database Server 1 Log Disk 10155 TargetAlias=Web Server 3 Disk 20 10157 If a target has been configured with a human-readable name or 10158 description, this name SHOULD be communicated to the initiator 10159 during a Login Response PDU if SessionType=Normal (see 13.21). 10160 This string is not used as an identifier, nor is it meant to be 10161 used for authentication or authorization decisions. It can be 10162 displayed by the initiator's user interface in a list of targets 10163 to which it is connected. 10165 13.7. InitiatorAlias 10167 Use: ALL, Declarative, Any-Stage 10168 Senders: Initiator 10169 Scope: SW 10171 InitiatorAlias= 10172 Examples: 10174 InitiatorAlias=Web Server 4 10176 InitiatorAlias=spyalley.nsa.gov 10178 InitiatorAlias=Exchange Server 10180 If an initiator has been configured with a human-readable name or 10181 description, it SHOULD be communicated to the target during a 10182 Login Request PDU. If not, the host name can be used instead. This 10183 string is not used as an identifier, nor is meant to be used for 10184 authentication or authorization decisions. It can be displayed by 10185 the target's user interface in a list of initiators to which it is 10186 connected. 10188 13.8. TargetAddress 10190 Use: ALL, Declarative, Any-Stage 10191 Senders: Target 10192 Scope: SW 10194 TargetAddress=domainname[:port][,portal-group-tag] 10196 The domainname can be specified as either a DNS host name, a 10197 dotted-decimal IPv4 address, or a bracketed IPv6 address as 10198 specified in [RFC3986]. 10200 If the TCP port is not specified, it is assumed to be the IANA- 10201 assigned default port for iSCSI (see Section 13 -"IANA 10202 Considerations"). 10204 If the TargetAddress is returned as the result of a redirect 10205 status in a login response, the comma and portal group tag MUST be 10206 omitted. 10208 If the TargetAddress is returned within a SendTargets response, 10209 the portal group tag MUST be included. 10211 Examples: 10213 TargetAddress=10.0.0.1:5003,1 10215 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 10217 TargetAddress=[1080::8:800:200C:417A]:5003,1 10219 TargetAddress=computingcenter.example.com,23 10221 Use of the portal-group-tag is described in Appendix D. - 10222 "SendTargets Operation". The formats for the port and portal- 10223 group-tag are the same as the one specified in 10224 TargetPortalGroupTag. 10226 13.9. TargetPortalGroupTag 10228 Use: IO by target, Declarative, Any-Stage 10229 Senders: Target 10230 Scope: SW 10232 TargetPortalGroupTag=<16-bit-binary-value> 10234 Examples: 10235 TargetPortalGroupTag=1 10237 The target portal group tag is a 16-bit binary-value that uniquely 10238 identifies a portal group within an iSCSI target node. This key 10239 carries the value of the tag of the portal group that is servicing 10240 the Login request. The iSCSI target returns this key to the 10241 initiator in the Login Response PDU to the first Login Request PDU 10242 that has the C bit set to 0 when TargetName is given by the 10243 initiator. 10245 [SAM2] and [SAM3] specifications note in their informative text 10246 that TPGT value should be non-zero, note that it is incorrect. A 10247 zero value is allowed as a legal value for TPGT. This discrepancy 10248 currently stands corrected in [SAM4]. 10250 For the complete usage expectations of this key see Section 6.3. 10252 13.10. InitialR2T 10254 Use: LO 10255 Senders: Initiator and Target 10256 Scope: SW 10257 Irrelevant when: SessionType=Discovery 10259 InitialR2T= 10261 Examples: 10263 I->InitialR2T=No 10265 T->InitialR2T=No 10267 Default is Yes. 10268 Result function is OR. 10270 The InitialR2T key is used to turn off the default use of R2T for 10271 unidirectional and the output part of bidirectional commands, thus 10272 allowing an initiator to start sending data to a target as if it 10273 has received an initial R2T with Buffer Offset=Immediate Data 10274 Length and Desired Data Transfer Length=(min(FirstBurstLength, 10275 Expected Data Transfer Length) - Received Immediate Data Length). 10277 The default action is that R2T is required, unless both the 10278 initiator and the target send this key-pair attribute specifying 10279 InitialR2T=No. Only the first outgoing data burst (immediate data 10280 and/or separate PDUs) can be sent unsolicited (i.e., not requiring 10281 an explicit R2T). 10283 13.11. ImmediateData 10285 Use: LO 10286 Senders: Initiator and Target 10287 Scope: SW 10288 Irrelevant when: SessionType=Discovery 10290 ImmediateData= 10292 Default is Yes. 10294 Result function is AND. 10296 The initiator and target negotiate support for immediate data. To 10297 turn immediate data off, the initiator or target must state its 10298 desire to do so. ImmediateData can be turned on if both the 10299 initiator and target have ImmediateData=Yes. 10301 If ImmediateData is set to Yes and InitialR2T is set to Yes 10302 (default), then only immediate data are accepted in the first 10303 burst. 10305 If ImmediateData is set to No and InitialR2T is set to Yes, then 10306 the initiator MUST NOT send unsolicited data and the target MUST 10307 reject unsolicited data with the corresponding response code. 10309 If ImmediateData is set to No and InitialR2T is set to No, then 10310 the initiator MUST NOT send unsolicited immediate data, but MAY 10311 send one unsolicited burst of Data-OUT PDUs. 10313 If ImmediateData is set to Yes and InitialR2T is set to No, then 10314 the initiator MAY send unsolicited immediate data and/or one 10315 unsolicited burst of Data-OUT PDUs. 10317 The following table is a summary of unsolicited data options: 10319 +----------+-------------+------------------+--------------+ 10320 |InitialR2T|ImmediateData| Unsolicited |Immediate Data| 10321 | | | Data Out PDUs | | 10322 +----------+-------------+------------------+--------------+ 10323 | No | No | Yes | No | 10324 +----------+-------------+------------------+--------------+ 10325 | No | Yes | Yes | Yes | 10326 +----------+-------------+------------------+--------------+ 10327 | Yes | No | No | No | 10328 +----------+-------------+------------------+--------------+ 10329 | Yes | Yes | No | Yes | 10330 +----------+-------------+------------------+--------------+ 10332 13.12. MaxRecvDataSegmentLength 10334 Use: ALL, Declarative 10335 Senders: Initiator and Target 10336 Scope: CO 10338 MaxRecvDataSegmentLength= 10340 Default is 8192 bytes. 10342 The initiator or target declares the maximum data segment length 10343 in bytes it can receive in an iSCSI PDU. 10345 The transmitter (initiator or target) is required to send PDUs 10346 with a data segment that does not exceed MaxRecvDataSegmentLength 10347 of the receiver. 10349 A target receiver is additionally limited by MaxBurstLength for 10350 solicited data and FirstBurstLength for unsolicited data. An 10351 initiator MUST NOT send solicited PDUs exceeding MaxBurstLength 10352 nor unsolicited PDUs exceeding FirstBurstLength (or 10353 FirstBurstLength-Immediate Data Length if immediate data were 10354 sent). 10356 13.13. MaxBurstLength 10358 Use: LO 10359 Senders: Initiator and Target 10360 Scope: SW 10361 Irrelevant when: SessionType=Discovery 10363 MaxBurstLength= 10365 Default is 262144 (256 Kbytes). 10366 Result function is Minimum. 10368 The initiator and target negotiate maximum SCSI data payload in 10369 bytes in a Data-In or a solicited Data-Out iSCSI sequence. A 10370 sequence consists of one or more consecutive Data-In or Data-Out 10371 PDUs that end with a Data-In or Data-Out PDU with the F bit set to 10372 one. 10374 13.14. FirstBurstLength 10376 Use: LO 10377 Senders: Initiator and Target 10378 Scope: SW 10379 Irrelevant when: SessionType=Discovery 10380 Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) 10382 FirstBurstLength= 10384 Default is 65536 (64 Kbytes). 10385 Result function is Minimum. 10387 The initiator and target negotiate the maximum amount in bytes of 10388 unsolicited data an iSCSI initiator may send to the target during 10389 the execution of a single SCSI command. This covers the immediate 10390 data (if any) and the sequence of unsolicited Data-Out PDUs (if 10391 any) that follow the command. 10393 FirstBurstLength MUST NOT exceed MaxBurstLength. 10395 13.15. DefaultTime2Wait 10397 Use: LO 10398 Senders: Initiator and Target 10399 Scope: SW 10401 DefaultTime2Wait= 10403 Default is 2. 10404 Result function is Maximum. 10406 The initiator and target negotiate the minimum time, in seconds, 10407 to wait before attempting an explicit/implicit logout or an active 10408 task reassignment after an unexpected connection termination or a 10409 connection reset. 10411 A value of 0 indicates that logout or active task reassignment can 10412 be attempted immediately. 10414 13.16. DefaultTime2Retain 10416 Use: LO 10417 Senders: Initiator and Target 10418 Scope: SW 10419 DefaultTime2Retain= 10421 Default is 20. 10422 Result function is Minimum. 10424 The initiator and target negotiate the maximum time, in seconds 10425 after an initial wait (Time2Wait), before which an active task 10426 reassignment is still possible after an unexpected connection 10427 termination or a connection reset. 10429 This value is also the session state timeout if the connection in 10430 question is the last LOGGED_IN connection in the session. 10432 A value of 0 indicates that connection/task state is immediately 10433 discarded by the target. 10435 13.17. MaxOutstandingR2T 10437 Use: LO 10438 Senders: Initiator and Target 10439 Scope: SW 10441 MaxOutstandingR2T= 10442 Irrelevant when: SessionType=Discovery 10444 Default is 1. 10445 Result function is Minimum. 10447 Initiator and target negotiate the maximum number of outstanding 10448 R2Ts per task, excluding any implied initial R2T that might be 10449 part of that task. An R2T is considered outstanding until the last 10450 data PDU (with the F bit set to 1) is transferred, or a sequence 10451 reception timeout (Section 7.1.4.1) is encountered for that data 10452 sequence. 10454 13.18. DataPDUInOrder 10456 Use: LO 10457 Senders: Initiator and Target 10458 Scope: SW 10459 Irrelevant when: SessionType=Discovery 10460 DataPDUInOrder= 10462 Default is Yes. 10463 Result function is OR. 10465 No is used by iSCSI to indicate that the data PDUs within 10466 sequences can be in any order. Yes is used to indicate that data 10467 PDUs within sequences have to be at continuously increasing 10468 addresses and overlays are forbidden. 10470 13.19. DataSequenceInOrder 10472 Use: LO 10473 Senders: Initiator and Target 10474 Scope: SW 10475 Irrelevant when: SessionType=Discovery 10477 DataSequenceInOrder= 10479 Default is Yes. 10480 Result function is OR. 10482 A Data Sequence is a sequence of Data-In or Data-Out PDUs that end 10483 with a Data-In or Data-Out PDU with the F bit set to one. A Data- 10484 out sequence is sent either unsolicited or in response to an R2T. 10485 Sequences cover an offset-range. 10487 If DataSequenceInOrder is set to No, Data PDU sequences may be 10488 transferred in any order. 10490 If DataSequenceInOrder is set to Yes, Data Sequences MUST be 10491 transferred using continuously non-decreasing sequence offsets 10492 (R2T buffer offset for writes, or the smallest SCSI Data-In buffer 10493 offset within a read data sequence). 10495 If DataSequenceInOrder is set to Yes, a target may retry at most 10496 the last R2T, and an initiator may at most request retransmission 10497 for the last read data sequence. For this reason, if 10498 ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes 10499 then MaxOustandingR2T MUST be set to 1. 10501 13.20. ErrorRecoveryLevel 10503 Use: LO 10504 Senders: Initiator and Target 10505 Scope: SW 10507 ErrorRecoveryLevel= 10509 Default is 0. 10510 Result function is Minimum. 10512 The initiator and target negotiate the recovery level supported. 10514 Recovery levels represent a combination of recovery capabilities. 10515 Each recovery level includes all the capabilities of the lower 10516 recovery levels and adds some new ones to them. 10518 In the description of recovery mechanisms, certain recovery 10519 classes are specified. Section 7.1.5 describes the mapping between 10520 the classes and the levels. 10522 13.21. SessionType 10524 Use: LO, Declarative, Any-Stage 10525 Senders: Initiator 10526 Scope: SW 10528 SessionType= 10530 Default is Normal. 10532 The Initiator indicates the type of session it wants to create. 10533 The target can either accept it or reject it. 10535 A Discovery session indicates to the Target that the only purpose 10536 of this Session is discovery. The only requests a target accepts 10537 in this type of session are a text request with a SendTargets key 10538 and a logout request with reason "close the session". 10540 The Discovery session implies MaxConnections = 1 and overrides 10541 both the default and an explicit setting. As section 7.4.1 10543 states, ErrorRecoveryLevel MUST be 0 (zero) for Discovery 10544 sessions. 10546 Depending on the type of the session, a target may decide on 10547 resources to allocate and the security to enforce, etc. for the 10548 session. If the SessionType key is thus going to be offered as 10549 "Discovery", it SHOULD be offered in the initial Login request by 10550 the initiator. 10552 13.22. The Private or Public Extension Key Format 10554 Use: ALL 10555 Senders: Initiator and Target 10556 Scope: specific key dependent 10558 X-reversed.vendor.dns_name.do_something= 10560 or 10562 X<#>= 10564 Keys with this format are used for public or private extension 10565 purposes. These keys always start with X- if unregistered with 10566 IANA (private) or X# if registered with IANA (public). 10568 For unregistered keys, to identify the vendor, we suggest you use 10569 the reversed DNS-name as a prefix to the key-proper. 10571 The part of key-name following X- and X# MUST conform to the 10572 format for key-name specified in Section 5.1 -"Text Format". 10574 For IANA registered keys the string following X# must be 10575 registered with IANA and the use of the key MUST be described by a 10576 standards track RFC, an experimental RFC, or an informational RFC. 10578 Vendor specific keys MUST ONLY be used in normal sessions. 10580 Support for public or private extension keys is OPTIONAL. 10582 13.23. Task Reporting 10584 Use: LO 10585 Senders: Initiator and Target 10586 Scope: SW 10587 Irrelevant when: SessionType=Discovery 10588 TaskReporting= 10590 Default is RFC3720. 10591 Result function is AND. 10593 This key is used to negotiate the task completion reporting 10594 semantics from the SCSI target. The following table describes the 10595 semantics that an iSCSI target MUST support for respective 10596 negotiated key values. Whenever this key is negotiated, at least 10597 the RFC3720 and ResponseFence values MUST be offered as options by 10598 the negotiation originator. 10599 +--------------+------------------------------------------+ 10600 | Name | Description | 10601 +--------------+------------------------------------------+ 10602 | RFC3720 | RFC 3720-compliant semantics. Response | 10603 | | fencing is not guaranteed and fast | 10604 | | completion of multi-task aborting is not | 10605 | | supported | 10606 +--------------+------------------------------------------+ 10607 | ResponseFence| Response Fence (section 4.2.2.3.3) | 10608 | | semantics MUST be supported in reporting | 10609 | | task completions | 10610 +--------------+------------------------------------------+ 10611 | FastAbort | Updated fast multi-task abort semantics | 10612 | | defined in Section 4.2.3.4 MUST be | 10613 | | supported. Support for Response Fence is | 10614 | | implied -- i.e., (Section 4.2.2.3.3) | 10615 | | semantics MUST be supported as well | 10616 +--------------+------------------------------------------+ 10617 When TaskReporting is not negotiated to FastAbort, the standard 10618 multi-task abort semantics in Section 4.2.3.3 MUST be used. 10620 13.24. iSCSIProtocolLevel Negotiation 10622 The iSCSIProtocolLevel associated with this document is "1". As a 10623 responder or an originator in a negotiation of this key, an iSCSI 10624 implementation compliant to this document alone, without any 10625 future protocol extensions, MUST use this value as defined by the 10626 [iSCSI-SAM] document. 10628 13.25. Obsoleted Keys 10630 This document obsoletes the following keys defined in [RFC3720]: 10631 IFMarker, OFMarker, OFMarkInt, IFMarkInt. However, iSCSI 10632 implementations compliant to this document may still receive these 10633 obsoleted keys - i.e. in a responder role - in a text negotiation. 10635 When IFMarker or OFMarker key is received, a compliant iSCSI 10636 implementation SHOULD respond with the constant "Reject" value. 10637 The implementation MAY alternatively respond with a "No" value. 10638 However, the implementation MUST NOT respond with a 10639 "NotUnderstood" value for either of these keys. 10641 When IFMarkInt or OFMarkInt key is received, a compliant iSCSI 10642 implementation MUST respond with the constant "Reject" value. 10643 The implementation MUST NOT respond with a "NotUnderstood" value 10644 for either of these keys. 10646 13.26. X#NodeArchitecture 10648 13.26.1. Definition 10650 Use: LO, Declarative 10651 Senders: Initiator and Target 10652 Scope: SW 10654 X#NodeArchitecture= 10656 Default is none. 10658 Examples: 10659 X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a 10660 X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 10661 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 10663 This document does not define the structure or content of the list 10664 of values. 10666 The initiator or target declares the details of its iSCSI node 10667 architecture to the remote endpoint. These details may include, 10668 but are not limited to, iSCSI vendor software, firmware, or 10670 hardware versions, the OS version, or hardware architecture. This 10671 key may be declared on a Discovery session or a Normal session. 10673 The length of the key value (total length of the list-of-values) 10674 MUST NOT be greater than 255 bytes. 10676 X#NodeArchitecture MUST NOT be redeclared during the login phase. 10678 13.26.2. Implementation Requirements 10680 Functional behavior of the iSCSI node (this includes the iSCSI 10681 protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT 10682 depend on the presence, absence, or content of the 10683 X#NodeArchitecture key. The key MUST NOT be used by iSCSI nodes 10684 for interoperability, or exclusion of other nodes. To ensure 10685 proper use, key values SHOULD be set by the node itself, and there 10686 SHOULD NOT be provisions for the key values to contain user- 10687 defined text. 10689 Nodes implementing this key MUST choose one of the following 10690 implementation options: 10692 only transmit the key, 10693 only log the key values received from other nodes, or 10694 both transmit and log the key values. 10695 Each node choosing to implement transmission of the key values 10696 MUST be prepared to handle the response of iSCSI Nodes that do not 10697 understand the key. 10699 Nodes that implement transmission and/or logging of the key values 10700 may also implement administrative mechanisms that disable and/or 10701 change the logging and key transmission detail (see Section 8.4 - 10702 "Security Considerations for the X#NodeArchitecture Key"). Thus, a 10703 valid behavior for this key may be that a node is completely 10704 silent (the node does not transmit any key value, and simply 10705 discards any key values it receives without issuing a 10706 NotUnderstood response). 10708 14. IANA Considerations 10710 The well-known TCP port number for iSCSI connections assigned by 10711 IANA is 3260 and this is the default iSCSI port. Implementations 10712 needing a system TCP port number may use port 860, the port 10713 assigned by IANA as the iSCSI system port; however in order to use 10714 port 860, it MUST be explicitly specified - implementations MUST 10715 NOT default to use of port 860, as 3260 is the only allowed 10716 default. 10718 [RFC3720] instructs that three text key registries be set up, one 10719 for each of Extension keys, authentication methods, or digest keys 10720 - with the stipulation that the key prefix (X#, Y# or Z#) be not 10721 recorded. However, [RFC4850] indicates that the key prefix was 10722 recorded by IANA as part of the key name. Consequently, storm 10723 working group (which published this document) instructs IANA that: 10724 (i) It maintain a single text key registry for iSCSI keys, and, 10725 (ii) MUST always record the key prefix as part of the recorded 10726 string 10728 This is being done with the intent to not have to change what IANA 10729 already did while publishing [RFC4850]. 10731 All the other IANA considerations stated in [RFC3720] and 10732 [RFC5048] remain unchanged. 10734 This document obsoletes the SPKM1 and SPKM2 key values for the 10735 AuthMethod text key. Consequently, the SPKM_ text key prefix MUST 10736 be treated as obsolete and be not reused. 10738 References 10740 Normative References 10742 [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", 10743 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 10745 [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling 10746 Interface (FC-FS). 10748 [iSCSI-SAM] Knight, F., Chadalapaka, M., "Internet Small 10749 Computer Systems Interface (iSCSI) Update", draft-ietf- 10750 storm-iscsi-sam-01.txt (work in progress), April 2010 10752 [OUI] "IEEE OUI and Company_Id Assignments", 10753 http://standards.ieee.org/regauth/oui 10755 [RFC791] INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL 10756 SPECIFICATION, September 1981. 10758 [RFC793] TRANSMISSION CONTROL PROTOCOL, DARPA INTERNET PROGRAM 10759 PROTOCOL SPECIFICATION, September 1981. 10761 [RFC1035] P. Mockapetris, DOMAIN NAMES - IMPLEMENTATION AND 10762 SPECIFICATION, November 1987. 10764 [RFC1122] Requirements for Internet Hosts-Communication Layer 10765 RFC1122, R. Braden (editor). 10767 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 10768 June 1996. 10770 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", 10771 August 1996. 10773 [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication 10774 Protocol (CHAP)", August 1996. 10776 [RFC2025] C. Adams, "The Simple Public-Key GSS-API Mechanism 10777 (SPKM)", October 1996. 10779 [RFC2045] N. Borenstein, N. Freed, "MIME (Multipurpose 10780 Internet Mail Extensions) Part One: Mechanisms for 10781 Specifying and Describing the Format of Internet Message 10782 Bodies", November 1996. 10784 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 10785 Requirement Levels", BCP 14, March 1997. 10787 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 10788 Architecture", February 2006. 10790 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 10791 within ESP and AH", November 1998. 10793 [RFC2451] R. Pereira, R. Adams " The ESP CBC-Mode Cipher 10794 Algorithms". 10796 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange 10797 System", September 2000. 10799 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 10800 Internationalized Strings ("stringprep")", RFC 3454, 10801 December 2002. 10803 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 10804 Algorithm and Its Use With IPsec", RFC 3566, September 2003. 10806 [RFC3629] Yergeau, F., "UTF-8, a Transformation Format of ISO 10807 10646", RFC 3629, November 2003 10809 [RFC3686] Housley, R., "Using Advanced Encryption Standard 10810 (AES) Counter Mode with IPsec Encapsulating Security Payload 10811 (ESP)", RFC 3686, January 2004. 10813 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 10814 M., and E. Zeidner, "Internet Small Computer Systems 10815 Interface (iSCSI)", RFC 3720, April 2004. 10817 [RFC3722] Bakke, M., "String Profile for Internet Small 10818 Computer Systems Interface (iSCSI) Names", RFC 3722, March 10819 2004. 10821 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. 10822 Travostino, "Securing Block Storage Protocols over IP", RFC 10823 3723, March 2004. 10825 [RFC3980] Krueger, M., Chadalapaka, M., Elliott, R., "T11 10826 Network Address Authority (NAA) Naming Format for iSCSI Node 10827 Names", RFC 3980, February 2005. 10829 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter "Uniform 10830 Resource Identifier (URI): Generic Syntax", January 2005. 10832 [RFC4120] Neuman, C., Yu, T., Hartman, S., Raeburn, K, "The 10833 Kerberos Network Authentication Service (V5)", RFC 4120, 10834 July 2005. 10836 [RFC4171] J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, 10837 J. Souza, "Internet Storage Name Service (iSNS)", September 10838 2005. 10840 [RFC4301] S. Kent, K.Seo, "Security Architecture for the 10841 Internet Protocol", December 2005. 10843 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 10844 RFC 4303, December 2005 10846 [RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, 10847 "Internet Key Exchange Protocol Version 2 (IKEv2) ", RFC 5996, 10848 September 2010.. 10850 [RFC5646] A. Phillips, M. Davis, "Tags for Identifying 10851 Languages", RFC 5646, September 2009. 10853 [RFC4850] Wysochanski, D., "Declarative Public Extension Key 10854 for Internet Small Computer Systems Interface (iSCSI) Node 10855 Architecture", RFC 4850, April 2007. 10857 [RFC5048] Chadalapaka, M., "Internet Small Computer Systems 10858 Interface (iSCSI) Corrections and Clarifications", RFC 5048, 10859 October 2007. 10861 [RFC5226] T. Narten, and H. Avestrand, "Guidelines for Writing 10862 an IANA Considerations Section in RFCs.", May 2008. 10864 [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). 10866 [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). 10868 [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). 10870 [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC). 10872 [SPC3] T10/1416-D, SCSI Primary Commands-3. 10874 [UML] ISO/IEC 19501, Unified Modeling Language 10875 Specification Version 1.4.2. 10877 [UNICODE] Unicode Standard Annex #15, "Unicode Normalization 10878 Forms", http://www.unicode.org/unicode/reports/tr15 10880 Informative References 10882 [RFC1737] K. Sollins, L. Masinter "Functional Requirements for 10883 Uniform Resource Names". 10885 [IB] InfiniBand{tm} Architecture Specification, Vol. 1, 10886 Rel.1.0.a, InfiniBand 10887 TradezAssociation(http://www.infinibandta.org). 10889 [RFC4173] P. Sarkar, D. Missimer, C. Sapuntzakis, 10890 "Bootstrapping Clients using the Internet Small Computer 10891 System Interface (iSCSI) Protocol", RFC 4173, September 10892 2005. 10894 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman 10895 "Optimization of Cyclic Redundancy-Check Codes with 24 and 10896 32 Parity Bits", IEEE Transact. on Communications, Vol. 41, 10897 No. 6, June 1993. 10899 [CRC] ISO 3309, High-Level Data Link Control (CRC 32). 10901 [RFC3347] Krueger, M., Haagens, R., Sapuntzakis, C. and M. 10902 Bakke, "Small Computer Systems Interface protocol over the 10903 Internet (iSCSI) Requirements and Design Considerations", 10904 RFC 3347, July 2002. 10906 [RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. 10907 Cavanna, "Internet Protocol Small Computer System Interface 10908 (iSCSI) Cyclic Redundancy Check (CRC)/Checksum 10909 Considerations", RFC 3385, September 2002. 10911 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. 10912 and M. Krueger, "Internet Small Computer Systems Interface 10913 (iSCSI) Naming and Discovery", RFC 3721, March 2004 10915 [RFC3783] M. Chadalapaka, R. Elliott, "Small Computer Systems 10916 Interface (SCSI) Command Ordering Considerations with iSCSI", 10917 RFC 3783, May 2004. 10919 [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, 10920 "Remote Direct Memory Access (RDMA) over IP Problem 10921 Statement", RFC 4297, October 2004 10923 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., 10924 Shah, H., and P. Thaler, "Internet Small Computer System 10925 Interface (iSCSI) Extensions for Remote Direct Memory Access 10926 (RDMA)", RFC 5046, October 2007 10928 [Schneier] B. Schneier, "Applied Cryptography: Protocols, 10929 Algorithms, and Source Code in C", 2nd edition, John Wiley & 10930 Sons, New York, NY, 1996. 10932 [SAS] INCITS 376-2003, Serial Attached SCSI (SAS). 10934 [SRP] INCITS 365-2002, SCSI RDMA Protocol (SRP). 10936 Appendix A. Examples 10938 Read Operation Example 10940 +------------------+-----------------------+---------------------+ 10941 |Initiator Function| PDU Type | Target Function | 10942 +------------------+-----------------------+---------------------+ 10943 | Command request |SCSI Command (READ)>>> | | 10944 | (read) | | | 10945 +------------------+-----------------------+---------------------+ 10946 | | |Prepare Data Transfer| 10947 +------------------+-----------------------+---------------------+ 10948 | Receive Data | <<< SCSI Data-in | Send Data | 10949 +------------------+-----------------------+---------------------+ 10950 | Receive Data | <<< SCSI Data-in | Send Data | 10951 +------------------+-----------------------+---------------------+ 10952 | Receive Data | <<< SCSI Data-in | Send Data | 10953 +------------------+-----------------------+---------------------+ 10954 | | <<< SCSI Response |Send Status and Sense| 10955 +------------------+-----------------------+---------------------+ 10956 | Command Complete | | | 10957 +------------------+-----------------------+---------------------+ 10959 Write Operation Example 10961 +------------------+-----------------------+---------------------+ 10962 |Initiator Function| PDU Type | Target Function | 10963 +------------------+-----------------------+---------------------+ 10964 | Command request |SCSI Command (WRITE)>>>| Receive command | 10965 | (write) | | and queue it | 10966 +------------------+-----------------------+---------------------+ 10967 | | | Process old commands| 10968 +------------------+-----------------------+---------------------+ 10969 | | | Ready to process | 10970 | | <<< R2T | WRITE command | 10971 +------------------+-----------------------+---------------------+ 10972 | Send Data | SCSI Data-out >>> | Receive Data | 10973 +------------------+-----------------------+---------------------+ 10974 | | <<< R2T | Ready for data | 10975 +------------------+-----------------------+---------------------+ 10976 | | <<< R2T | Ready for data | 10977 +------------------+-----------------------+---------------------+ 10978 | Send Data | SCSI Data-out >>> | Receive Data | 10979 +------------------+-----------------------+---------------------+ 10980 | Send Data | SCSI Data-out >>> | Receive Data | 10981 +------------------+-----------------------+---------------------+ 10982 | | <<< SCSI Response |Send Status and Sense| 10983 +------------------+-----------------------+---------------------+ 10984 | Command Complete | | | 10985 +------------------+-----------------------+---------------------+ 10987 R2TSN/DataSN Use Examples 10989 Output (write) data DataSN/R2TSN Example 10990 +------------------+-----------------------+---------------------+ 10991 |Initiator Function| PDU Type & Content | Target Function | 10992 +------------------+-----------------------+---------------------+ 10993 | Command request |SCSI Command (WRITE)>>>| Receive command | 10994 | (write) | | and queue it | 10995 +------------------+-----------------------+---------------------+ 10996 | | | Process old commands| 10997 +------------------+-----------------------+---------------------+ 10998 | | <<< R2T | Ready for data | 10999 | | R2TSN = 0 | | 11000 +------------------+-----------------------+---------------------+ 11001 | | <<< R2T | Ready for more data | 11002 | | R2TSN = 1 | | 11003 +------------------+-----------------------+---------------------+ 11004 | Send Data | SCSI Data-out >>> | Receive Data | 11005 | for R2TSN 0 | DataSN = 0, F=0 | | 11006 +------------------+-----------------------+---------------------+ 11007 | Send Data | SCSI Data-out >>> | Receive Data | 11008 | for R2TSN 0 | DataSN = 1, F=1 | | 11009 +------------------+-----------------------+---------------------+ 11010 | Send Data | SCSI Data >>> | Receive Data | 11011 | for R2TSN 1 | DataSN = 0, F=1 | | 11012 +------------------+-----------------------+---------------------+ 11013 | | <<< SCSI Response |Send Status and Sense| 11014 | | ExpDataSN = 0 | | 11015 +------------------+-----------------------+---------------------+ 11016 | Command Complete | | | 11017 +------------------+-----------------------+---------------------+ 11019 Input (read) data DataSN Example 11021 +------------------+-----------------------+---------------------+ 11022 |Initiator Function| PDU Type | Target Function | 11023 +------------------+-----------------------+---------------------+ 11024 | Command request |SCSI Command (READ)>>> | | 11025 | (read) | | | 11026 +------------------+-----------------------+---------------------+ 11027 | | |Prepare Data Transfer| 11028 +------------------+-----------------------+---------------------+ 11029 | Receive Data | <<< SCSI Data-in | Send Data | 11030 | | DataSN = 0, F=0 | | 11031 +------------------+-----------------------+---------------------+ 11032 | Receive Data | <<< SCSI Data-in | Send Data | 11033 | | DataSN = 1, F=0 | | 11034 +------------------+-----------------------+---------------------+ 11035 | Receive Data | <<< SCSI Data-in | Send Data | 11036 | | DataSN = 2, F=1 | | 11037 +------------------+-----------------------+---------------------+ 11038 | | <<< SCSI Response |Send Status and Sense| 11039 | | ExpDataSN = 3 | | 11040 +------------------+-----------------------+---------------------+ 11041 | Command Complete | | | 11042 +------------------+-----------------------+---------------------+ 11044 Bidirectional DataSN Example 11046 +------------------+-----------------------+---------------------+ 11047 |Initiator Function| PDU Type | Target Function | 11048 +------------------+-----------------------+---------------------+ 11049 | Command request |SCSI Command >>> | | 11050 | (Read-Write) | Read-Write | | 11051 +------------------+-----------------------+---------------------+ 11052 | | | Process old commands| 11053 +------------------+-----------------------+---------------------+ 11054 | | <<< R2T | Ready to process | 11055 | | R2TSN = 0 | WRITE command | 11056 +------------------+-----------------------+---------------------+ 11057 | * Receive Data | <<< SCSI Data-in | Send Data | 11058 | | DataSN = 0, F=0 | | 11059 +------------------+-----------------------+---------------------+ 11060 | * Receive Data | <<< SCSI Data-in | Send Data | 11061 | | DataSN = 1, F=1 | | 11062 +------------------+-----------------------+---------------------+ 11063 | * Send Data | SCSI Data-out >>> | Receive Data | 11064 | for R2TSN 0 | DataSN = 0, F=1 | | 11065 +------------------+-----------------------+---------------------+ 11066 | | <<< SCSI Response |Send Status and Sense| 11067 | | ExpDataSN = 2 | | 11068 +------------------+-----------------------+---------------------+ 11069 | Command Complete | | | 11070 +------------------+-----------------------+---------------------+ 11072 *) Send data and Receive Data may be transferred simultaneously as 11073 in an atomic Read-Old-Write-New or sequentially as in an atomic 11074 Read-Update-Write (in the latter case the R2T may follow the 11075 received data). 11077 Unsolicited and immediate output (write) data with DataSN Example 11078 +------------------+-----------------------+---------------------+ 11079 |Initiator Function| PDU Type & Content | Target Function | 11080 +------------------+-----------------------+---------------------+ 11081 | Command request |SCSI Command (WRITE)>>>| Receive command | 11082 | (write) |F=0 | and data | 11083 |+ immediate data | | and queue it | 11084 +------------------+-----------------------+---------------------+ 11085 | Send Unsolicited | SCSI Write Data >>> | Receive more Data | 11086 | Data | DataSN = 0, F=1 | | 11087 +------------------+-----------------------+---------------------+ 11088 | | | Process old commands| 11089 +------------------+-----------------------+---------------------+ 11090 | | <<< R2T | Ready for more data | 11091 | | R2TSN = 0 | | 11092 +------------------+-----------------------+---------------------+ 11093 | Send Data | SCSI Write Data >>> | Receive Data | 11094 | for R2TSN 0 | DataSN = 0, F=1 | | 11095 +------------------+-----------------------+---------------------+ 11096 | | <<< SCSI Response |Send Status and Sense| 11097 | | | | 11098 +------------------+-----------------------+---------------------+ 11099 | Command Complete | | | 11100 +------------------+-----------------------+---------------------+ 11102 CRC Examples 11104 N.B. all Values are Hexadecimal 11106 32 bytes of zeroes: 11108 Byte: 0 1 2 3 11110 0: 00 00 00 00 11111 ... 11112 28: 00 00 00 00 11114 CRC: aa 36 91 8a 11116 32 bytes of ones: 11118 Byte: 0 1 2 3 11119 0: ff ff ff ff 11120 ... 11121 28: ff ff ff ff 11123 CRC: 43 ab a8 62 11125 32 bytes of incrementing 00..1f: 11127 Byte: 0 1 2 3 11129 0: 00 01 02 03 11130 ... 11131 28: 1c 1d 1e 1f 11133 CRC: 4e 79 dd 46 11135 32 bytes of decrementing 1f..00: 11137 Byte: 0 1 2 3 11139 0: 1f 1e 1d 1c 11140 ... 11141 28: 03 02 01 00 11143 CRC: 5c db 3f 11 11145 An iSCSI - SCSI Read (10) Command PDU 11147 Byte: 0 1 2 3 11149 0: 01 c0 00 00 11150 4: 00 00 00 00 11151 8: 00 00 00 00 11152 12: 00 00 00 00 11153 16: 14 00 00 00 11154 20: 00 00 04 00 11155 24: 00 00 00 14 11156 28: 00 00 00 18 11157 32: 28 00 00 00 11158 36: 00 00 00 00 11159 40: 02 00 00 00 11160 44: 00 00 00 00 11162 CRC: 56 3a 96 d9 11164 Appendix B. Login Phase Examples 11166 In the first example, the initiator and target authenticate each 11167 other via Kerberos: 11169 I-> Login (CSG,NSG=0,1 T=1) 11170 InitiatorName=iqn.1999-07.com.os:hostid.77 11171 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11172 AuthMethod=KRB5,SRP,None 11174 T-> Login (CSG,NSG=0,0 T=0) 11175 AuthMethod=KRB5 11177 I-> Login (CSG,NSG=0,1 T=1) 11178 KRB_AP_REQ= 11180 (krb_ap_req contains the Kerberos V5 ticket and authenticator with 11181 MUTUAL-REQUIRED set in the ap-options field) 11183 If the authentication is successful, the target proceeds with: 11185 T-> Login (CSG,NSG=0,1 T=1) 11186 KRB_AP_REP= 11188 (krb_ap_rep is the Kerberos V5 mutual authentication reply) 11190 If the authentication is successful, the initiator may proceed 11191 with: 11193 I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192 11194 T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096 11195 MaxBurstLength=8192 11196 I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192 11197 ... more iSCSI Operational Parameters 11199 T-> Login (CSG,NSG=1,0 T=0) 11200 ... more iSCSI Operational Parameters 11202 And at the end: 11204 I-> Login (CSG,NSG=1,3 T=1) 11205 optional iSCSI parameters 11207 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11209 If the initiator's authentication by the target is not successful, 11210 the target responds with: 11212 T-> Login "login reject" 11214 instead of the Login KRB_AP_REP message, and terminates the 11215 connection. 11217 If the target's authentication by the initiator is not successful, 11218 the initiator terminates the connection (without responding to the 11219 Login KRB_AP_REP message). 11221 In the next example only the initiator is authenticated by the 11222 target via Kerberos: 11224 I-> Login (CSG,NSG=0,1 T=1) 11225 InitiatorName=iqn.1999-07.com.os:hostid.77 11226 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11227 AuthMethod=SRP,KRB5,None 11229 T-> Login-PR (CSG,NSG=0,0 T=0) 11230 AuthMethod=KRB5 11232 I-> Login (CSG,NSG=0,1 T=1) 11233 KRB_AP_REQ=krb_ap_req 11235 (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req) 11237 If the authentication is successful, the target proceeds with: 11239 T-> Login (CSG,NSG=0,1 T=1) 11241 I-> Login (CSG,NSG=1,0 T=0) 11242 ... iSCSI parameters 11244 T-> Login (CSG,NSG=1,0 T=0) 11245 ... iSCSI parameters 11247 . . . 11249 T-> Login (CSG,NSG=1,3 T=1)"login accept" 11251 In the next example, the initiator and target authenticate each 11252 other via SRP: 11254 I-> Login (CSG,NSG=0,1 T=1) 11255 InitiatorName=iqn.1999-07.com.os:hostid.77 11256 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11257 AuthMethod=KRB5,SRP,None 11259 T-> Login-PR (CSG,NSG=0,0 T=0) 11260 AuthMethod=SRP 11262 I-> Login (CSG,NSG=0,0 T=0) 11263 SRP_U= 11264 TargetAuth=Yes 11266 T-> Login (CSG,NSG=0,0 T=0) 11267 SRP_N= 11268 SRP_g= 11269 SRP_s= 11271 I-> Login (CSG,NSG=0,0 T=0) 11272 SRP_A= 11274 T-> Login (CSG,NSG=0,0 T=0) 11275 SRP_B= 11277 I-> Login (CSG,NSG=0,1 T=1) 11278 SRP_M= 11280 If the initiator authentication is successful, the target 11281 proceeds: 11283 T-> Login (CSG,NSG=0,1 T=1) 11284 SRP_HM= 11286 Where N, g, s, A, B, M, and H(A | M | K) are defined in 11287 [RFC2945]. 11289 If the target authentication is not successful, the initiator 11290 terminates the connection; otherwise, it proceeds. 11292 I-> Login (CSG,NSG=1,0 T=0) 11293 ... iSCSI parameters 11295 T-> Login (CSG,NSG=1,0 T=0) 11296 ... iSCSI parameters 11298 And at the end: 11300 I-> Login (CSG,NSG=1,3 T=1) 11301 optional iSCSI parameters 11303 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11305 If the initiator authentication is not successful, the target 11306 responds with: 11308 T-> Login "login reject" 11310 Instead of the T-> Login SRP_HM= message and 11311 terminates the connection. 11313 In the next example, only the initiator is authenticated by the 11314 target via SRP: 11316 I-> Login (CSG,NSG=0,1 T=1) 11317 InitiatorName=iqn.1999-07.com.os:hostid.77 11318 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11319 AuthMethod=KRB5,SRP,None 11321 T-> Login-PR (CSG,NSG=0,0 T=0) 11322 AuthMethod=SRP 11324 I-> Login (CSG,NSG=0,0 T=0) 11325 SRP_U= 11326 TargetAuth=No 11328 T-> Login (CSG,NSG=0,0 T=0) 11329 SRP_N= 11330 SRP_g= 11331 SRP_s= 11333 I-> Login (CSG,NSG=0,0 T=0) 11334 SRP_A= 11336 T-> Login (CSG,NSG=0,0 T=0) 11337 SRP_B= 11339 I-> Login (CSG,NSG=0,1 T=1) 11340 SRP_M= 11342 If the initiator authentication is successful, the target 11343 proceeds: 11345 T-> Login (CSG,NSG=0,1 T=1) 11347 I-> Login (CSG,NSG=1,0 T=0) 11349 ... iSCSI parameters 11351 T-> Login (CSG,NSG=1,0 T=0) 11353 ... iSCSI parameters 11355 And at the end: 11357 I-> Login (CSG,NSG=1,3 T=1) 11359 optional iSCSI parameters 11361 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11363 In the next example the initiator and target authenticate each 11364 other via CHAP: 11366 I-> Login (CSG,NSG=0,0 T=0) 11368 InitiatorName=iqn.1999-07.com.os:hostid.77 11370 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11372 AuthMethod=KRB5,CHAP,None 11374 T-> Login-PR (CSG,NSG=0,0 T=0) 11376 AuthMethod=CHAP 11378 I-> Login (CSG,NSG=0,0 T=0) 11380 CHAP_A= 11382 T-> Login (CSG,NSG=0,0 T=0) 11383 CHAP_A= 11384 CHAP_I= 11385 CHAP_C= 11387 I-> Login (CSG,NSG=0,1 T=1) 11389 CHAP_N= 11391 CHAP_R= 11393 CHAP_I= 11395 CHAP_C= 11397 If the initiator authentication is successful, the target 11398 proceeds: 11400 T-> Login (CSG,NSG=0,1 T=1) 11402 CHAP_N= 11404 CHAP_R= 11406 If the target authentication is not successful, the initiator 11407 aborts the connection; otherwise, it proceeds. 11409 I-> Login (CSG,NSG=1,0 T=0) 11411 ... iSCSI parameters 11413 T-> Login (CSG,NSG=1,0 T=0) 11415 ... iSCSI parameters 11417 And at the end: 11419 I-> Login (CSG,NSG=1,3 T=1) 11421 optional iSCSI parameters 11423 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11425 If the initiator authentication is not successful, the target 11426 responds with: 11428 T-> Login "login reject" 11430 Instead of the Login CHAP_R= "proceed and change 11431 stage" message and terminates the connection. 11433 In the next example, only the initiator is authenticated by the 11434 target via CHAP: 11436 I-> Login (CSG,NSG=0,1 T=0) 11438 InitiatorName=iqn.1999-07.com.os:hostid.77 11440 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11442 AuthMethod=KRB5,CHAP,None 11444 T-> Login-PR (CSG,NSG=0,0 T=0) 11446 AuthMethod=CHAP 11448 I-> Login (CSG,NSG=0,0 T=0) 11450 CHAP_A= 11452 T-> Login (CSG,NSG=0,0 T=0) 11453 CHAP_A= 11454 CHAP_I= 11455 CHAP_C= 11457 I-> Login (CSG,NSG=0,1 T=1) 11459 CHAP_N= 11461 CHAP_R= 11463 If the initiator authentication is successful, the target 11464 proceeds: 11466 T-> Login (CSG,NSG=0,1 T=1) 11468 I-> Login (CSG,NSG=1,0 T=0) 11470 ... iSCSI parameters 11472 T-> Login (CSG,NSG=1,0 T=0) 11474 ... iSCSI parameters 11476 And at the end: 11478 I-> Login (CSG,NSG=1,3 T=1) 11480 optional iSCSI parameters 11482 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11484 In the next example, the initiator does not offer any security 11485 parameters. It therefore may offer iSCSI parameters on the Login 11486 PDU with the T bit set to 1, and the target may respond with a 11487 final Login Response PDU immediately: 11489 I-> Login (CSG,NSG=1,3 T=1) 11491 InitiatorName=iqn.1999-07.com.os:hostid.77 11493 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11495 ... iSCSI parameters 11497 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11499 ... ISCSI parameters 11501 In the next example, the initiator does offer security 11502 parameters on the Login PDU, but the target does not choose 11503 any (i.e., chooses the "None" values): 11505 I-> Login (CSG,NSG=0,1 T=1) 11507 InitiatorName=iqn.1999-07.com.os:hostid.77 11509 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11511 AuthMethod=KRB5,SRP,None 11513 T-> Login-PR (CSG,NSG=0,1 T=1) 11515 AuthMethod=None 11517 I-> Login (CSG,NSG=1,0 T=0) 11519 ... iSCSI parameters 11521 T-> Login (CSG,NSG=1,0 T=0) 11523 ... iSCSI parameters 11525 And at the end: 11527 I-> Login (CSG,NSG=1,3 T=1) 11529 optional iSCSI parameters 11531 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11533 Appendix C. SendTargets Operation 11535 To reduce the amount of configuration required on an initiator, 11536 iSCSI provides the SendTargets text request. The initiator uses 11537 the SendTargets request to get a list of targets to which it may 11538 have access, as well as the list of addresses (IP address and TCP 11539 port) on which these targets may be accessed. 11541 To make use of SendTargets, an initiator must first establish one 11542 of two types of sessions. If the initiator establishes 11543 the session using the key "SessionType=Discovery", the session is 11544 a discovery session, and a target name does not need to be 11545 specified. Otherwise, the session is a normal, operational 11546 session. The SendTargets command MUST only be sent during the 11547 Full Feature Phase of a normal or discovery session. 11549 A system that contains targets MUST support discovery sessions on 11550 each of its iSCSI IP address-port pairs, and MUST support the 11551 SendTargets command on the discovery session. In a discovery 11552 session, a target MUST return all path information (IP address- 11553 port pairs and portal group tags) for the targets on the target 11554 network entity which the requesting initiator is authorized to 11555 access. 11557 A target MUST support the SendTargets command on operational 11558 sessions; these will only return path information about the target 11559 to which the session is connected, and do not need to return 11560 information about other target names that may be defined in the 11561 responding system. 11563 An initiator MAY make use of the SendTargets as it sees fit. 11565 A SendTargets command consists of a single Text request PDU. 11566 This PDU contains exactly one text key and value. The text key 11567 MUST be SendTargets. The expected response depends upon the 11568 value, as well as whether the session is a discovery or 11569 operational session. 11571 The value must be one of: 11573 All 11575 The initiator is requesting that information on all relevant 11576 targets known to the implementation be returned. This value 11577 MUST be supported on a discovery session, and MUST NOT be 11578 supported on an operational session. 11580 11581 If an iSCSI target name is specified, the session should 11582 respond with addresses for only the named target, if 11583 possible. This value MUST be supported on discovery 11584 sessions. A discovery session MUST be capable of returning 11585 addresses for those targets that would have been returned 11586 had value=All been designated. 11588 11590 The session should only respond with addresses for the target 11591 to which the session is logged in. This MUST be supported 11592 on operational sessions, and MUST NOT return targets other 11593 than the one to which the session is logged in. 11595 The response to this command is a text response that contains a 11596 list of zero or more targets and, optionally, their addresses. 11597 Each target is returned as a target record. A target record 11598 begins with the TargetName text key, followed by a list of 11599 TargetAddress text keys, and bounded by the end of the text 11600 response or the next TargetName key, which begins a new record. 11601 No text keys other than TargetName and TargetAddress are permitted 11602 within a SendTargets response. 11604 For the format of the TargetName, see Section 12.4 - "TargetName". 11606 A discovery session MAY respond to a SendTargets request with its 11607 complete list of targets, or with a list of targets that is based 11608 on the name of the initiator logged in to the session. 11610 A SendTargets response MUST NOT contain target names if there are 11611 no targets for the requesting initiator to access. 11613 Each target record returned includes zero or more TargetAddress 11614 fields. 11616 Each target record starts with one text key of the form: 11618 TargetName= 11620 Followed by zero or more address keys of the form: 11622 TargetAddress=[:], 11625 The hostname-or-ipaddress contains a domain name, IPv4 address, or 11626 IPv6 address, as specified for the TargetAddress key. 11628 A hostname-or-ipaddress duplicated in TargetAddress responses for 11629 a given node (the port is absent or equal) would probably indicate 11630 that multiple address families are in use at once (IPv6 and IPv4). 11632 Each TargetAddress belongs to a portal group, identified by its 11633 numeric portal group tag (as in Section 12.9 - 11634 "TargetPortalGroupTag"). The iSCSI target name, together with this 11635 tag, constitutes the SCSI port identifier; the tag only needs to 11636 be unique within a given target's name list of addresses. 11638 Multiple-connection sessions can span iSCSI addresses that belong 11639 to the same portal group. 11641 Multiple-connection sessions cannot span iSCSI addresses that 11642 belong to different portal groups. 11644 If a SendTargets response reports an iSCSI address for a target, 11645 it SHOULD also report all other addresses in its portal group in 11646 the same response. 11648 A SendTargets text response can be longer than a single Text 11649 Response PDU, and makes use of the long text responses as 11650 specified. 11652 After obtaining a list of targets from the discovery target 11653 session, 11654 an iSCSI initiator may initiate new sessions to log in to the 11655 discovered targets for full operation. The initiator MAY keep the 11656 discovery session open, and MAY send subsequent SendTargets 11657 commands to discover new targets. 11659 Examples: 11661 This example is the SendTargets response from a single target that 11662 has no other interface ports. 11664 Initiator sends text request that contains: 11666 SendTargets=All 11668 Target sends a text response that contains: 11670 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11672 All the target had to return in the simple case was the target 11673 name. It is assumed by the initiator that the IP address and TCP 11674 port for this target are the same as used on the current 11675 connection to the default iSCSI target. 11677 The next example has two internal iSCSI targets, each accessible 11678 via two different ports with different IP addresses. The 11679 following is the text response: 11681 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11683 TargetAddress=10.1.0.45:3000,1 11685 TargetAddress=10.1.1.45:3000,2 11687 TargetName=iqn.1993-11.com.example:diskarray.sn.1234567 11689 TargetAddress=10.1.0.45:3000,1 11691 TargetAddress=10.1.1.45:3000,2 11693 Both targets share both addresses; the multiple addresses are 11694 likely used to provide multi-path support. The initiator may 11695 connect to either target name on either address. Each of the 11696 addresses has its own portal group tag; they do not support 11697 spanning multiple-connection sessions with each other. Keep in 11698 mind that the portal group tags for the two named targets are 11699 independent of one another; portal group "1" on the first target 11700 is not necessarily the same as portal group "1" on the second 11701 target. 11703 In the above example, a DNS host name or an IPv6 address could 11704 have been returned instead of an IPv4 address. 11706 The next text response shows a target that supports spanning 11707 sessions across multiple addresses, and further illustrates the 11708 use of the portal group tags: 11710 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11712 TargetAddress=10.1.0.45:3000,1 11714 TargetAddress=10.1.1.46:3000,1 11716 TargetAddress=10.1.0.47:3000,2 11718 TargetAddress=10.1.1.48:3000,2 11720 TargetAddress=10.1.1.49:3000,3 11722 In this example, any of the target addresses can be used to reach 11723 the same target. A single-connection session can be established 11724 to any of these TCP addresses. A multiple-connection session 11725 could span addresses .45 and .46 or .47 and .48, but cannot span 11726 any other combination. A TargetAddress with its own tag (.49) 11727 cannot be combined with any other address within the same session. 11729 This SendTargets response does not indicate whether .49 supports 11730 multiple connections per session; it is communicated via the 11731 MaxConnections text key upon login to the target. 11733 Appendix D. Algorithmic Presentation of Error Recovery Classes 11735 This appendix illustrates the error recovery classes using a 11736 pseudo-programming-language. The procedure names are chosen to be 11737 obvious to most implementers. Each of the recovery classes 11738 described has initiator procedures as well as target procedures. 11739 These algorithms focus on outlining the mechanics of error 11740 recovery classes, and do not exhaustively describe all other 11741 aspects/cases. Examples of this approach are: 11743 - Handling for only certain Opcode types is shown. 11745 - Only certain reason codes (e.g., Recovery in Logout command) 11746 are outlined. 11748 - Resultant cases, such as recovery of Synchronization on a 11749 header digest error are considered out-of-scope in these 11750 algorithms. In this particular example, a header digest 11751 error may lead to connection recovery if some type of sync 11752 and steering layer is not implemented. 11754 These algorithms strive to convey the iSCSI error recovery 11755 concepts in the simplest terms, and are not designed to be 11756 optimal. 11758 D.1. General Data Structure and 11759 Procedure Description 11761 This section defines the procedures and data structures that are 11762 commonly used by all the error recovery algorithms. The structures 11763 may not be the exhaustive representations of what is required for 11764 a typical implementation. 11766 Data structure definitions - 11767 struct TransferContext { 11768 int TargetTransferTag; 11769 int ExpectedDataSN; 11770 }; 11772 struct TCB { /* task control block */ 11773 Boolean SoFarInOrder; 11774 int ExpectedDataSN; /* used for both R2Ts, and Data */ 11775 int MissingDataSNList[MaxMissingDPDU]; 11776 Boolean FbitReceived; 11777 Boolean StatusXferd; 11778 Boolean CurrentlyAllegiant; 11779 int ActiveR2Ts; 11780 int Response; 11781 char *Reason; 11782 struct TransferContext 11783 TransferContextList[MaxOutStandingR2T]; 11784 int InitiatorTaskTag; 11785 int CmdSN; 11786 int SNACK_Tag; 11787 }; 11789 struct Connection { 11790 struct Session SessionReference; 11791 Boolean SoFarInOrder; 11792 int CID; 11793 int State; 11794 int CurrentTimeout; 11795 int ExpectedStatSN; 11796 int MissingStatSNList[MaxMissingSPDU]; 11797 Boolean PerformConnectionCleanup; 11798 }; 11800 struct Session { 11801 int NumConnections; 11802 int CmdSN; 11803 int Maxconnections; 11804 int ErrorRecoveryLevel; 11805 struct iSCSIEndpoint OtherEndInfo; 11806 struct Connection ConnectionList[MaxSupportedConns]; 11807 }; 11809 Procedure descriptions - 11810 Receive-a-In-PDU(transport connection, inbound PDU); 11811 check-basic-validity(inbound PDU); 11812 Start-Timer(timeout handler, argument, timeout value); 11813 Build-And-Send-Reject(transport connection, bad PDU, reason 11814 code); 11815 D.2. Within-command Error Recovery 11816 Algorithms 11818 D.2.1. Procedure Descriptions 11820 Recover-Data-if-Possible(last required DataSN, task control 11821 block); 11822 Build-And-Send-DSnack(task control block); 11823 Build-And-Send-RDSnack(task control block); 11824 Build-And-Send-Abort(task control block); 11825 SCSI-Task-Completion(task control block); 11826 Build-And-Send-A-Data-Burst(transport connection, data- 11827 descriptor, 11828 task control 11829 block); 11830 Build-And-Send-R2T(transport connection, data-descriptor, 11831 task control 11832 block); 11833 Build-And-Send-Status(transport connection, task control block); 11834 Transfer-Context-Timeout-Handler(transfer context); 11836 Notes: 11838 - One procedure used in this section: Handle-Status-SNACK- 11839 request is defined in Within-connection recovery algorithms. 11841 - The Response processing pseudo-code, shown in the target 11842 algorithms, applies to all solicited PDUs that carry StatSN 11843 - SCSI Response, Text Response etc. 11845 D.2.2. Initiator Algorithms 11847 Recover-Data-if-Possible(LastRequiredDataSN, TCB) 11848 { 11849 if (operational ErrorRecoveryLevel > 0) { 11850 if (# of missing PDUs is trackable) { 11851 Note the missing DataSNs in TCB. 11852 if (the task spanned a change in 11853 MaxRecvDataSegmentLength) { 11855 if (TCB.StatusXferd is TRUE) 11856 drop the status PDU; 11857 Build-And-Send-RDSnack(TCB); 11858 } else { 11859 Build-And-Send-DSnack(TCB); 11860 } 11861 } else { 11862 TCB.Reason = "Protocol service CRC error"; 11863 } 11864 } else { 11865 TCB.Reason = "Protocol service CRC error"; 11866 } 11867 if (TCB.Reason == "Protocol service CRC error") { 11868 Clear the missing PDU list in the TCB. 11869 if (TCB.StatusXferd is not TRUE) 11870 Build-And-Send-Abort(TCB); 11871 } 11872 } 11874 Receive-a-In-PDU(Connection, CurrentPDU) 11875 { 11876 check-basic-validity(CurrentPDU); 11877 if (Header-Digest-Bad) discard, return; 11878 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11879 if ((CurrentPDU.type == Data) 11880 or (CurrentPDU.type = R2T)) { 11881 if (Data-Digest-Bad for Data) { 11882 send-data-SNACK = TRUE; 11883 LastRequiredDataSN = CurrentPDU.DataSN; 11884 } else { 11885 if (TCB.SoFarInOrder = TRUE) { 11886 if (current DataSN is expected) { 11887 Increment TCB.ExpectedDataSN. 11888 } else { 11889 TCB.SoFarInOrder = FALSE; 11890 send-data-SNACK = TRUE; 11891 } 11892 } else { 11893 if (current DataSN was considered 11894 missing) { 11895 remove current DataSN from missing 11896 PDU list. 11897 } else if (current DataSN is higher than 11898 expected) { 11899 send-data-SNACK = TRUE; 11900 } else { 11901 discard, return; 11902 } 11903 Adjust TCB.ExpectedDataSN if 11904 appropriate. 11905 } 11906 LastRequiredDataSN = CurrentPDU.DataSN - 1; 11907 } 11908 if (send-data-SNACK is TRUE and 11909 task is not already considered failed) { 11910 Recover-Data-if-Possible(LastRequiredDataSN, TCB); 11911 } 11912 if (missing data PDU list is empty) { 11913 TCB.SoFarInOrder = TRUE; 11914 } 11915 if (CurrentPDU.type == R2T) { 11916 Increment ActiveR2Ts for this task. 11917 Create a data-descriptor for the data burst. 11918 Build-And-Send-A-Data-Burst(Connection, data- 11919 descriptor, 11920 TCB); 11921 } 11922 } else if (CurrentPDU.type == Response) { 11923 if (Data-Digest-Bad) { 11924 send-status-SNACK = TRUE; 11925 } else { 11926 TCB.StatusXferd = TRUE; 11927 Store the status information in TCB. 11928 if (ExpDataSN does not match) { 11929 TCB.SoFarInOrder = FALSE; 11930 Recover-Data-if-Possible(current DataSN, TCB); 11931 } 11932 if (missing data PDU list is empty) { 11933 TCB.SoFarInOrder = TRUE; 11934 } 11936 } 11937 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 11938 SHOWN */ 11939 } 11940 if ((TCB.SoFarInOrder == TRUE) and 11941 (TCB.StatusXferd == TRUE)) { 11942 SCSI-Task-Completion(TCB); 11943 } 11944 } 11946 D.2.3. Target Algorithms 11948 Receive-a-In-PDU(Connection, CurrentPDU) 11949 { 11950 check-basic-validity(CurrentPDU); 11951 if (Header-Digest-Bad) discard, return; 11952 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11953 if (CurrentPDU.type == Data) { 11954 Retrieve TContext from CurrentPDU.TargetTransferTag; 11955 if (Data-Digest-Bad) { 11956 Build-And-Send-Reject(Connection, CurrentPDU, 11957 Payload-Digest-Error); 11958 Note the missing data PDUs in MissingDataRange[]. 11959 send-recovery-R2T = TRUE; 11960 } else { 11961 if (current DataSN is not expected) { 11962 Note the missing data PDUs in MissingDataRange[]. 11963 send-recovery-R2T = TRUE; 11964 } 11965 if (CurrentPDU.Fbit == TRUE) { 11966 if (current PDU is solicited) { 11967 Decrement TCB.ActiveR2Ts. 11968 } 11969 if ((current PDU is unsolicited and 11970 data received is less than I/O length and 11971 data received is less than 11972 FirstBurstLength) 11973 or (current PDU is solicited and the length of 11974 this burst is less than expected)) { 11975 send-recovery-R2T = TRUE; 11976 Note the missing data in MissingDataRange[]. 11977 } 11978 } 11979 } 11980 Increment TContext.ExpectedDataSN. 11981 if (send-recovery-R2T is TRUE and 11982 task is not already considered failed) { 11983 if (operational ErrorRecoveryLevel > 0) { 11984 Increment TCB.ActiveR2Ts. 11985 Create a data-descriptor for the data burst 11986 from MissingDataRange. 11987 Build-And-Send-R2T(Connection, data-descriptor, 11988 TCB); 11989 } else { 11990 if (current PDU is the last unsolicited) 11991 TCB.Reason = "Not enough unsolicited data"; 11992 else 11993 TCB.Reason = "Protocol service CRC error"; 11994 } 11995 } 11996 if (TCB.ActiveR2Ts == 0) { 11997 Build-And-Send-Status(Connection, TCB); 11998 } 11999 } else if (CurrentPDU.type == SNACK) { 12000 snack-failure = FALSE; 12001 if (operational ErrorRecoveryLevel > 0) { 12002 if (CurrentPDU.type == Data/R2T) { 12003 if (the request is satisfiable) { 12004 if (request for Data) { 12005 Create a data-descriptor for the data burst 12006 from BegRun and RunLength. 12007 Build-And-Send-A-Data-Burst(Connection, 12008 data-descriptor, TCB); 12009 } else { /* R2T */ 12010 Create a data-descriptor for the data burst 12011 from BegRun and RunLength. 12012 Build-And-Send-R2T(Connection, data- 12013 descriptor, 12014 TCB); 12015 } 12016 } else { 12017 snack-failure = TRUE; 12018 } 12019 } else if (CurrentPDU.type == status) { 12020 Handle-Status-SNACK-request(Connection, 12021 CurrentPDU); 12022 } else if (CurrentPDU.type == DataACK) { 12023 Consider all data upto CurrentPDU.BegRun as 12024 acknowledged. 12025 Free up the retransmission resources for that data. 12026 } else if (CurrentPDU.type == R-Data SNACK) { 12027 Create a data descriptor for a data burst 12028 covering 12029 all unacknowledged data. 12030 Build-And-Send-A-Data-Burst(Connection, 12031 data-descriptor, TCB); 12032 TCB.SNACK_Tag = CurrentPDU.SNACK_Tag; 12033 if (there's no more data to send) { 12034 Build-And-Send-Status(Connection, TCB); 12035 } 12036 } 12037 } else { /* operational ErrorRecoveryLevel = 0 */ 12038 snack-failure = TRUE; 12039 } 12040 if (snack-failure == TRUE) { 12041 Build-And-Send-Reject(Connection, CurrentPDU, 12042 SNACK-Reject); 12043 if (TCB.StatusXferd != TRUE) { 12044 TCB.Reason = "SNACK Rejected"; 12045 Build-And-Send-Status(Connection, TCB); 12046 } 12047 } 12049 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 12050 SHOWN */ 12051 } 12052 } 12054 Transfer-Context-Timeout-Handler(TContext) 12055 { 12056 Retrieve TCB and Connection from TContext. 12057 Decrement TCB.ActiveR2Ts. 12059 if (operational ErrorRecoveryLevel > 0 and 12060 task is not already considered failed) { 12061 Note the missing data PDUs in MissingDataRange[]. 12062 Create a data-descriptor for the data burst 12063 from MissingDataRange[]. 12064 Build-And-Send-R2T(Connection, data-descriptor, TCB); 12065 } else { 12066 TCB.Reason = "Protocol service CRC error"; 12067 if (TCB.ActiveR2Ts = 0) { 12068 Build-And-Send-Status(Connection, TCB); 12069 } 12070 } 12071 } 12073 D.3. Within-connection Recovery 12074 Algorithms 12076 D.3.1. Procedure Descriptions 12078 Procedure descriptions: 12079 Recover-Status-if-Possible(transport connection, 12080 currently received PDU); 12081 Evaluate-a-StatSN(transport connection, currently received PDU); 12082 Retransmit-Command-if-Possible(transport connection, CmdSN); 12083 Build-And-Send-SSnack(transport connection); 12084 Build-And-Send-Command(transport connection, task control 12085 block); 12086 Command-Acknowledge-Timeout-Handler(task control block); 12087 Status-Expect-Timeout-Handler(transport connection); 12088 Build-And-Send-Nop-Out(transport connection); 12089 Handle-Status-SNACK-request(transport connection, status SNACK 12090 PDU); 12091 Retransmit-Status-Burst(status SNACK, task control block); 12092 Is-Acknowledged(beginning StatSN, run length); 12094 Implementation-specific tunables: 12095 InitiatorProactiveSNACKEnabled 12097 Notes: 12098 - The initiator algorithms only deal with unsolicited Nop-In 12099 PDUs for generating status SNACKs. A solicited Nop-In PDU 12100 has an assigned StatSN, which, when out of order, could 12101 trigger the out of order StatSN handling in Within-command 12102 algorithms, again leading to Recover-Status-if-Possible. 12104 - The pseudo-code shown may result in the retransmission of 12105 unacknowledged commands in more cases than necessary. This 12106 will not, however, affect the correctness of the operation 12107 because the target is required to discard the duplicate 12108 CmdSNs. 12110 - The procedure Build-And-Send-Async is defined in the 12111 Connection recovery algorithms. 12113 - The procedure Status-Expect-Timeout-Handler describes how 12114 initiators may proactively attempt to retrieve the Status if 12115 they so choose. This procedure is assumed to be triggered 12116 much before the standard ULP timeout. 12118 D.3.2. Initiator Algorithms 12120 Recover-Status-if-Possible(Connection, CurrentPDU) 12121 { 12122 if ((Connection.state == LOGGED_IN) and 12123 connection is not already considered 12124 failed) { 12125 if (operational ErrorRecoveryLevel > 0) { 12126 if (# of missing PDUs is trackable) { 12127 Note the missing StatSNs in Connection 12128 that were not already requested with SNACK; 12129 Build-And-Send-SSnack(Connection); 12130 } else { 12131 Connection.PerformConnectionCleanup = TRUE; 12132 } 12133 } else { 12134 Connection.PerformConnectionCleanup = TRUE; 12136 } 12137 if (Connection.PerformConnectionCleanup == TRUE) { 12138 Start-Timer(Connection-Cleanup-Handler, Connection, 12139 0); 12140 } 12141 } 12142 } 12144 Retransmit-Command-if-Possible(Connection, CmdSN) 12145 { 12146 if (operational ErrorRecoveryLevel > 0) { 12147 Retrieve the InitiatorTaskTag, and thus TCB for the 12148 CmdSN. 12149 Build-And-Send-Command(Connection, TCB); 12150 } 12151 } 12153 Evaluate-a-StatSN(Connection, CurrentPDU) 12154 { 12155 send-status-SNACK = FALSE; 12156 if (Connection.SoFarInOrder == TRUE) { 12157 if (current StatSN is the expected) { 12158 Increment Connection.ExpectedStatSN. 12159 } else { 12160 Connection.SoFarInOrder = FALSE; 12161 send-status-SNACK = TRUE; 12162 } 12163 } else { 12164 if (current StatSN was considered missing) { 12165 remove current StatSN from the missing list. 12166 } else { 12167 if (current StatSN is higher than expected){ 12168 send-status-SNACK = TRUE; 12169 } else { 12170 send-status-SNACK = FALSE; 12171 discard the PDU; 12172 } 12173 } 12174 Adjust Connection.ExpectedStatSN if appropriate. 12175 if (missing StatSN list is empty) { 12176 Connection.SoFarInOrder = TRUE; 12177 } 12178 } 12179 return send-status-SNACK; 12180 } 12182 Receive-a-In-PDU(Connection, CurrentPDU) 12183 { 12184 check-basic-validity(CurrentPDU); 12185 if (Header-Digest-Bad) discard, return; 12186 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12187 if (CurrentPDU.type == Nop-In) { 12188 if (the PDU is unsolicited) { 12189 if (current StatSN is not expected) { 12190 Recover-Status-if-Possible(Connection, 12191 CurrentPDU); 12192 } 12193 if (current ExpCmdSN is not Session.CmdSN) { 12194 Retransmit-Command-if-Possible(Connection, 12195 CurrentPDU.ExpCmdSN); 12196 } 12197 } 12198 } else if (CurrentPDU.type == Reject) { 12199 if (it is a data digest error on immediate data) { 12200 Retransmit-Command-if-Possible(Connection, 12202 CurrentPDU.BadPDUHeader.CmdSN); 12203 } 12204 } else if (CurrentPDU.type == Response) { 12205 send-status-SNACK = Evaluate-a-StatSN(Connection, 12206 CurrentPDU); 12207 if (send-status-SNACK == TRUE) 12208 Recover-Status-if-Possible(Connection, CurrentPDU); 12209 } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY, 12210 * NOT SHOWN */ 12211 } 12212 } 12214 Command-Acknowledge-Timeout-Handler(TCB) 12215 { 12216 Retrieve the Connection for TCB. 12217 Retransmit-Command-if-Possible(Connection, TCB.CmdSN); 12218 } 12220 Status-Expect-Timeout-Handler(Connection) 12221 { 12222 if (operational ErrorRecoveryLevel > 0) { 12223 Build-And-Send-Nop-Out(Connection); 12224 } else if (InitiatorProactiveSNACKEnabled){ 12225 if ((Connection.state == LOGGED_IN) and 12226 connection is not already considered 12227 failed) { 12228 Build-And-Send-SSnack(Connection); 12229 } 12230 } 12231 } 12233 E.3.3 Target Algorithms 12235 Handle-Status-SNACK-request(Connection, CurrentPDU) 12236 { 12237 if (operational ErrorRecoveryLevel > 0) { 12238 if (request for an acknowledged run) { 12239 Build-And-Send-Reject(Connection, CurrentPDU, 12240 Protocol-Error); 12241 } else if (request for an untransmitted run) { 12242 discard, return; 12243 } else { 12244 Retransmit-Status-Burst(CurrentPDU, TCB); 12245 } 12246 } else { 12247 Build-And-Send-Async(Connection, DroppedConnection, 12248 DefaultTime2Wait, 12249 DefaultTime2Retain); 12250 } 12251 } 12252 D.4. Connection Recovery Algorithms 12254 D.4.1. Procedure Descriptions 12256 Build-And-Send-Async(transport connection, reason code, 12257 minimum time, maximum time); 12258 Pick-A-Logged-In-Connection(session); 12259 Build-And-Send-Logout(transport connection, logout connection 12260 identifier, reason code); 12261 PerformImplicitLogout(transport connection, logout connection 12262 identifier, target information); 12263 PerformLogin(transport connection, target information); 12264 CreateNewTransportConnection(target information); 12265 Build-And-Send-Command(transport connection, task control 12266 block); 12267 Connection-Cleanup-Handler(transport connection); 12268 Connection-Resource-Timeout-Handler(transport connection); 12269 Quiesce-And-Prepare-for-New-Allegiance(session, task control 12270 block); 12271 Build-And-Send-Logout-Response(transport connection, 12272 CID of connection in recovery, reason 12273 code); 12274 Build-And-Send-TaskMgmt-Response(transport connection, 12275 task mgmt command PDU, response code); 12276 Establish-New-Allegiance(task control block, transport 12277 connection); 12278 Schedule-Command-To-Continue(task control block); 12280 Notes: 12281 - Transport exception conditions, such as unexpected 12282 connection termination, connection reset, and hung 12283 connection while the connection is in the full-feature 12284 phase, are all assumed to be asynchronously signaled to the 12285 iSCSI layer using the Transport_Exception_Handler procedure. 12287 D.4.2. Initiator Algorithms 12289 Receive-a-In-PDU(Connection, CurrentPDU) 12290 { 12291 check-basic-validity(CurrentPDU); 12292 if (Header-Digest-Bad) discard, return; 12293 Retrieve TCB from CurrentPDU.InitiatorTaskTag. 12294 if (CurrentPDU.type == Async) { 12295 if (CurrentPDU.AsyncEvent == ConnectionDropped) { 12296 Retrieve the AffectedConnection for 12297 CurrentPDU.Parameter1. 12298 AffectedConnection.CurrentTimeout = 12299 CurrentPDU.Parameter3; 12300 AffectedConnection.State = CLEANUP_WAIT; 12301 Start-Timer(Connection-Cleanup-Handler, 12302 AffectedConnection, 12303 CurrentPDU.Parameter2); 12304 } else if (CurrentPDU.AsyncEvent == LogoutRequest)) { 12305 AffectedConnection = Connection; 12306 AffectedConnection.State = LOGOUT_REQUESTED; 12307 AffectedConnection.PerformConnectionCleanup = TRUE; 12308 AffectedConnection.CurrentTimeout = 12309 CurrentPDU.Parameter3; 12310 Start-Timer(Connection-Cleanup-Handler, 12311 AffectedConnection, 0); 12312 } else if (CurrentPDU.AsyncEvent == SessionDropped)) { 12313 for (each Connection) { 12314 Connection.State = CLEANUP_WAIT; 12315 Connection.CurrentTimeout = CurrentPDU.Parameter3; 12316 Start-Timer(Connection-Cleanup-Handler, 12317 Connection, CurrentPDU.Parameter2); 12318 } 12319 Session.state = FAILED; 12320 } 12322 } else if (CurrentPDU.type == LogoutResponse) { 12323 Retrieve the CleanupConnection for CurrentPDU.CID. 12324 if (CurrentPDU.Response = failure) { 12325 CleanupConnection.State = CLEANUP_WAIT; 12326 } else { 12327 CleanupConnection.State = FREE; 12328 } 12329 } else if (CurrentPDU.type == LoginResponse) { 12330 if (this is a response to an implicit Logout) { 12331 Retrieve the CleanupConnection. 12332 if (successful) { 12333 CleanupConnection.State = FREE; 12334 Connection.State = LOGGED_IN; 12335 } else { 12336 CleanupConnection.State = CLEANUP_WAIT; 12337 DestroyTransportConnection(Connection); 12338 } 12339 } 12340 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12341 * NOT SHOWN */ 12342 } 12343 if (CleanupConnection.State == FREE) { 12344 for (each command that was active on CleanupConnection) { 12345 /* Establish new connection allegiance */ 12346 NewConnection = Pick-A-Logged-In- 12347 Connection(Session); 12348 Build-And-Send-Command(NewConnection, TCB); 12349 } 12350 } 12351 } 12353 Connection-Cleanup-Handler(Connection) 12354 { 12355 Retrieve Session from Connection. 12356 if (Connection can still exchange iSCSI PDUs) { 12357 NewConnection = Connection; 12358 } else { 12359 Start-Timer(Connection-Resource-Timeout-Handler, 12360 Connection, Connection.CurrentTimeout); 12361 if (there are other logged-in connections) { 12362 NewConnection = Pick-A-Logged-In- 12363 Connection(Session); 12364 } else { 12365 NewConnection = 12367 CreateTransportConnection(Session.OtherEndInfo); 12368 Initiate an implicit Logout on NewConnection for 12369 Connection.CID. 12370 return; 12372 } 12373 } 12374 Build-And-Send-Logout(NewConnection, Connection.CID, 12375 RecoveryRemove); 12376 } 12378 Transport_Exception_Handler(Connection) 12379 { 12380 Connection.PerformConnectionCleanup = TRUE; 12381 if (the event is an unexpected transport disconnect) { 12382 Connection.State = CLEANUP_WAIT; 12383 Connection.CurrentTimeout = DefaultTime2Retain; 12384 Start-Timer(Connection-Cleanup-Handler, Connection, 12385 DefaultTime2Wait); 12387 } else { 12388 Connection.State = FREE; 12389 } 12390 } 12392 D.4.3. Target Algorithms 12394 Receive-a-In-PDU(Connection, CurrentPDU) 12395 { 12396 check-basic-validity(CurrentPDU); 12397 if (Header-Digest-Bad) discard, return; 12398 else if (Data-Digest-Bad) { 12399 Build-And-Send-Reject(Connection, CurrentPDU, 12400 Payload-Digest-Error); 12401 discard, return; 12402 } 12403 Retrieve TCB and Session. 12404 if (CurrentPDU.type == Logout) { 12405 if (CurrentPDU.ReasonCode = RecoveryRemove) { 12406 Retrieve the CleanupConnection from CurrentPDU.CID). 12407 for (each command active on CleanupConnection) { 12408 Quiesce-And-Prepare-for-New-Allegiance(Session, 12409 TCB); 12410 TCB.CurrentlyAllegiant = FALSE; 12411 } 12412 Cleanup-Connection-State(CleanupConnection); 12413 if ((quiescing successful) and (cleanup successful)) 12414 { 12415 Build-And-Send-Logout-Response(Connection, 12416 CleanupConnection.CID, 12417 Success); 12418 } else { 12419 Build-And-Send-Logout-Response(Connection, 12420 CleanupConnection.CID, 12421 Failure); 12422 } 12423 } 12424 } else if ((CurrentPDU.type == Login) and 12425 operational ErrorRecoveryLevel == 2) { 12426 Retrieve the CleanupConnection from CurrentPDU.CID). 12427 for (each command active on CleanupConnection) { 12428 Quiesce-And-Prepare-for-New-Allegiance(Session, 12429 TCB); 12430 TCB.CurrentlyAllegiant = FALSE; 12431 } 12432 Cleanup-Connection-State(CleanupConnection); 12433 if ((quiescing successful) and (cleanup successful)) 12434 { 12435 Continue with the rest of the Login processing; 12436 } else { 12437 Build-And-Send-Login-Response(Connection, 12438 CleanupConnection.CID, Target 12439 Error); 12440 } 12441 } 12442 } else if (CurrentPDU.type == TaskManagement) { 12443 if (CurrentPDU.function == "TaskReassign") { 12444 if (Session.ErrorRecoveryLevel < 2) { 12445 Build-And-Send-TaskMgmt-Response(Connection, 12446 CurrentPDU, "Allegiance reassignment 12447 not supported"); 12448 } else if (task is not found) { 12449 Build-And-Send-TaskMgmt-Response(Connection, 12450 CurrentPDU, "Task not in task set"); 12451 } else if (task is currently allegiant) { 12452 Build-And-Send-TaskMgmt-Response(Connection, 12453 CurrentPDU, "Task still allegiant"); 12454 } else { 12455 Establish-New-Allegiance(TCB, Connection); 12456 TCB.CurrentlyAllegiant = TRUE; 12457 Schedule-Command-To-Continue(TCB); 12458 } 12459 } 12460 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12461 * NOT SHOWN */ 12462 } 12463 } 12465 Transport_Exception_Handler(Connection) 12466 { 12467 Connection.PerformConnectionCleanup = TRUE; 12468 if (the event is an unexpected transport disconnect) { 12469 Connection.State = CLEANUP_WAIT; 12470 Start-Timer(Connection-Resource-Timeout-Handler, 12471 Connection, 12473 (DefaultTime2Wait+DefaultTime2Retain)); 12474 if (this Session has full-feature phase connections 12475 left) { 12476 DifferentConnection = 12477 Pick-A-Logged-In-Connection(Session); 12478 Build-And-Send-Async(DifferentConnection, 12479 DroppedConnection, DefaultTime2Wait, 12480 DefaultTime2Retain); 12481 } 12482 } else { 12483 Connection.State = FREE; 12484 } 12485 } 12486 Appendix E. Clearing Effects of Various Events on Targets 12488 E.1. Clearing Effects on iSCSI Objects 12490 The following tables describe the target behavior on receiving the 12491 events specified in the rows of the table. The second table is 12493 an extension of the first table and defines clearing actions for 12494 more objects on the same events. The legend is: 12496 Y = Yes (cleared/discarded/reset on the event specified in 12497 the row). Unless otherwise noted, the clearing action is 12498 only applicable for the issuing initiator port. 12500 N = No (not affected on the event specified in the row, 12501 i.e., stays at previous value). 12503 NA = Not Applicable or Not Defined. 12505 +-----+-----+-----+-----+-----+ 12506 |IT(1)|IC(2)|CT(5)|ST(6)|PP(7)| 12507 +---------------------+-----+-----+-----+-----+-----+ 12508 |connection failure(8)|Y |Y |N |N |Y | 12509 +---------------------+-----+-----+-----+-----+-----+ 12510 |connection state |NA |NA |Y |N |NA | 12511 |timeout (9) | | | | | | 12512 +---------------------+-----+-----+-----+-----+-----+ 12513 |session timeout/ |Y |Y |Y |Y |Y(14)| 12514 |closure/reinstatement| | | | | | 12515 |(10) | | | | | | 12516 +---------------------+-----+-----+-----+-----+-----+ 12517 |session continuation |NA |NA |N(11)|N |NA | 12518 |(12) | | | | | | 12519 +---------------------+-----+-----+-----+-----+-----+ 12520 |successful connection|Y |Y |Y |N |Y(13)| 12521 |close logout | | | | | | 12522 +---------------------+-----+-----+-----+-----+-----+ 12523 |session failure (18) |Y |Y |N |N |Y | 12524 +---------------------+-----+-----+-----+-----+-----+ 12525 |successful recovery |Y |Y |N |N |Y(13)| 12526 |Logout | | | | | | 12527 +---------------------+-----+-----+-----+-----+-----+ 12528 |failed Logout |Y |Y |N |N |Y | 12529 +---------------------+-----+-----+-----+-----+-----+ 12530 |connection Login |NA |NA |NA |Y(15)|NA | 12531 |(leading) | | | | | | 12532 +---------------------+-----+-----+-----+-----+-----+ 12533 |connection Login |NA |NA |N(11)|N |Y | 12534 |(non-leading) | | | | | | 12535 +---------------------+-----+-----+-----+-----+-----+ 12536 |target cold reset(16)|Y(20)|Y |Y |Y |Y | 12537 +---------------------+-----+-----+-----+-----+-----+ 12538 |target warm reset(16)|Y(20)|Y |Y |Y |Y | 12539 +---------------------+-----+-----+-----+-----+-----+ 12540 |LU reset(19) |Y(20)|Y |Y |Y |Y | 12541 +---------------------+-----+-----+-----+-----+-----+ 12542 |powercycle(16) |Y |Y |Y |Y |Y | 12543 +---------------------+-----+-----+-----+-----+-----+ 12545 1. Incomplete TTTs - Target Transfer Tags on which the target is 12546 still expecting PDUs to be received. Examples include TTTs 12547 received via R2T, NOP-IN, etc. 12549 2. Immediate Commands - immediate commands, but waiting for 12550 execution on a target. For example, Abort Task Set. 12552 5. Connection Tasks - tasks that are active on the iSCSI connection 12553 in question. 12555 6. Session Tasks - tasks that are active on the entire iSCSI 12556 session. A union of "connection tasks" on all participating 12557 connections. 12559 7. Partial PDUs (if any) - PDUs that are partially sent and waiting 12560 for transport window credit to complete the transmission. 12562 8. Connection failure is a connection exception condition - one of 12563 the transport connections shutdown, transport connections 12564 reset, or transport connections timed out, which abruptly 12565 terminated the iSCSI full-feature phase connection. A 12566 connection failure always takes the connection state machine to 12567 the CLEANUP_WAIT state. 12569 9. Connection state timeout happens if a connection spends more 12570 time than agreed upon during Login negotiation in the 12571 CLEANUP_WAIT state, and this takes the connection to the FREE 12572 state (M1 transition in connection cleanup state diagram). 12574 10.These are defined in Section 6.3.5. 12576 11.This clearing effect is "Y" only if it is a connection 12577 reinstatement and the operational ErrorRecoveryLevel is less 12578 than 2. 12580 12.Session continuation is defined in Section 6.3.5. 12582 13.This clearing effect is only valid if the connection is being 12583 logged out on a different connection and when the connection 12584 being logged out on the target may have some partial PDUs 12585 pending to be sent. In all other cases, the effect is "NA". 12586 14.This clearing effect is only valid for a "close the session" 12587 logout in a multi-connection session. In all other cases, the 12588 effect is "NA". 12589 15.Only applicable if this leading connection login is a session 12590 reinstatement. If this is not the case, it is "NA". 12591 16.This operation affects all logged-in initiators. 12592 18.Session failure is defined in Section 6.3.5. 12593 19.This operation affects all logged-in initiators and the clearing 12594 effects are only applicable to the LU being reset. 12596 20.With Standard multi-task abort semantics (Section 4.2.3.3), a 12597 target warm reset or a target cold reset or an LU reset would 12598 clear the active TTTs upon completion. However, the FastAbort 12599 multi-task abort semantics defined by Section 4.2.3.4 do not 12600 guarantee that the active TTTs are cleared by the end of the 12601 reset operations. In fact, the FastAbort semantics are designed 12602 to allow clearing the TTTs in a "lazy" fashion after the TMF 12603 Response is delivered. Thus, when TaskReporting=FastAbort 12604 (Section 13.23) is operational on a session, the clearing 12605 effects of reset operations on "Incomplete TTTs" is "N". 12607 +-----+-----+-----+-----+-----+ 12608 |DC(1)|DD(2)|SS(3)|CS(4)|DS(5)| 12609 +---------------------+-----+-----+-----+-----+-----+ 12610 |connection failure |N |Y |N |N |N | 12611 +---------------------+-----+-----+-----+-----+-----+ 12612 |connection state |Y |NA |Y |N |NA | 12613 |timeout | | | | | | 12614 +---------------------+-----+-----+-----+-----+-----+ 12615 |session timeout/ |Y |Y |Y(7) |Y |NA | 12616 |closure/reinstatement| | | | | | 12617 +---------------------+-----+-----+-----+-----+-----+ 12618 |session continuation |N(11)|NA*12|NA |N |NA*13| 12619 +---------------------+-----+-----+-----+-----+-----+ 12620 |successful connection|Y |Y |Y |N |NA | 12621 |close Logout | | | | | | 12622 +---------------------+-----+-----+-----+-----+-----+ 12623 |session failure |N |Y |N |N |N | 12624 +---------------------+-----+-----+-----+-----+-----+ 12625 |successful recovery |Y |Y |Y |N |N | 12626 |Logout | | | | | | 12627 +---------------------+-----+-----+-----+-----+-----+ 12628 |failed Logout |N |Y(9) |N |N |N | 12629 +---------------------+-----+-----+-----+-----+-----+ 12630 |connection Login |NA |NA |N(8) |N(8) |NA | 12631 |(leading | | | | | | 12632 +---------------------+-----+-----+-----+-----+-----+ 12633 |connection Login |N(11)|NA*12|N(8) |N |NA*13| 12634 |(non-leading) | | | | | | 12635 +---------------------+-----+-----+-----+-----+-----+ 12636 |target cold reset |Y |Y |Y |Y(10)|NA | 12637 +---------------------+-----+-----+-----+-----+-----+ 12638 |target warm reset |Y |Y |N |N |NA | 12639 +---------------------+-----+-----+-----+-----+-----+ 12640 |LU reset |N |Y |N |N |N | 12641 +---------------------+-----+-----+-----+-----+-----+ 12642 |powercycle |Y |Y |Y |Y(10)|NA | 12643 +---------------------+-----+-----+-----+-----+-----+ 12645 1. Discontiguous Commands - commands allegiant to the connection 12646 in question and waiting to be reordered in the iSCSI layer. All 12647 "Y"s in this column assume that the task causing the event (if 12648 indeed the event is the result of a task) is issued as an 12649 immediate command, because the discontiguities can be ahead of the 12650 task. 12652 2. Discontiguous Data - data PDUs received for the task in 12653 question and waiting to be reordered due to prior discontiguities 12654 in DataSN. 12656 3. StatSN 12658 4. CmdSN 12660 5. DataSN 12662 7. It clears the StatSN on all the connections. 12664 8. This sequence number is instantiated on this event. 12666 9. A logout failure drives the connection state machine to the 12667 CLEANUP_WAIT state, similar to the connection failure event. 12668 Hence, it has a similar effect on this and several other protocol 12669 aspects. 12671 10. This is cleared by virtue of the fact that all sessions with 12672 all initiators are terminated. 12674 11. This clearing effect is "Y" if it is a connection 12675 reinstatement. 12677 12. This clearing effect is "Y" only if it is a connection 12678 reinstatement and the operational ErrorRecoveryLevel is 2. 12680 13. This clearing effect is "N" only if it is a connection 12681 reinstatement and the operational ErrorRecoveryLevel is 2. 12683 E.2. Clearing Effects on SCSI Objects 12685 The only iSCSI protocol action that can effect clearing actions on 12686 SCSI objects is the "I_T nexus loss" notification (Section 4.3.5.1 12687 Loss of Nexus notification). [SPC3] describes the clearing effects 12688 of this notification on a variety of SCSI attributes. In addition, 12689 SCSI standards documents (such as [SAM2] and [SBC]) define 12690 additional clearing actions that may take place for several SCSI 12691 objects on SCSI events such as LU resets and power-on resets. 12693 Since iSCSI defines a target cold reset as a protocol-equivalent 12694 to a target power-cycle, the iSCSI target cold reset must also be 12695 considered as the power-on reset event in interpreting the actions 12696 defined in the SCSI standards. 12698 When the iSCSI session is reconstructed (between the same SCSI 12699 ports with the same nexus identifier) reestablishing the same I_T 12700 nexus, all SCSI objects that are defined to not clear on the "I_T 12701 nexus loss" notification event, such as persistent reservations, 12702 are automatically associated to this new session. 12704 Acknowledgments 12706 Several individuals on the original IPS Working Group made 12707 significant contributions to the original RFCs 3720, 3980, 4850 12708 and 5048. 12710 Specifically, the authors of the original RFCs - which this draft 12711 consolidates into a single document - were the following: 12713 RFC 3720: Julian Satran, Kalman Meth, Costa Sapuntzakis, 12714 Mallikarjun Chadalapaka, Efri Zeidner 12716 RFC 3980: Marjorie Krueger, Mallikarjun Chadalapaka, Rob Elliott 12718 RFC 4850: David Wysochanski 12720 RFC 5048: Mallikarjun Chadalapaka 12722 Many thanks to Fred Knight for contributing to the UML notations 12723 and drawings in this draft. 12725 We would in addition like to acknowledge the following individuals 12726 who contributed to this revised draft: David Black, David 12727 Harrington, Paul Koning, Mark Edwards. 12729 Authors' Addresses 12731 Mallikarjun Chadalapaka 12732 Microsoft 12733 One Microsoft Way 12734 Redmond WA 98052 USA 12735 E-mail: cbm@chadalapaka.com 12737 Julian Satran 12738 E-mail: Julian.Satran@gmail.com 12740 Kalman Meth 12741 IBM Haifa Research Lab 12742 Haifa University Campus - Mount Carmel 12743 Haifa 31905, Israel 12744 Phone +972.4.829.6341 12745 E-mail: meth@il.ibm.com 12747 Comments may be sent to Mallikarjun Chadalapaka 12749 Acknowledgement 12751 Funding for the RFC Editor function is currently provided by the 12752 Internet Society