idnits 2.17.1 draft-ietf-storm-iscsi-cons-01.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 2788 -- Looks like a reference, but probably isn't: '7' on line 6572 -- Looks like a reference, but probably isn't: '0' on line 6571 == Missing Reference: 'MaxMissingDPDU' is mentioned on line 11614, but not defined == Missing Reference: 'MaxOutStandingR2T' is mentioned on line 11622, but not defined == Missing Reference: 'MaxMissingSPDU' is mentioned on line 11635, but not defined == Missing Reference: 'MaxSupportedConns' is mentioned on line 11645, but not defined == Unused Reference: 'RFC791' is defined on line 10600, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 10603, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 10606, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 10609, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 10621, but no explicit reference was found in the text == Unused Reference: 'RFC2373' is defined on line 10632, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 10651, but no explicit reference was found in the text == Unused Reference: 'RFC3980' is defined on line 10674, but no explicit reference was found in the text == Unused Reference: 'RFC4646' is defined on line 10698, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 10709, but no explicit reference was found in the text == Unused Reference: 'RFC4173' is defined on line 10737, but no explicit reference was found in the text == Unused Reference: 'CRC' is defined on line 10746, but no explicit reference was found in the text == Unused Reference: 'RFC3347' is defined on line 10748, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 10771, 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 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) ** Downref: Normative reference to an Informational RFC: RFC 3783 ** Obsolete normative reference: RFC 3980 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) ** 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' ** Downref: Normative reference to an Informational RFC: RFC 1737 -- Possible downref: Non-RFC (?) normative reference: ref. 'IB' -- Possible downref: Non-RFC (?) normative reference: ref. 'Castagnoli93' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC' ** Downref: Normative reference to an Informational RFC: RFC 3385 ** Downref: Normative reference to an Informational RFC: RFC 3721 ** Downref: Normative reference to an Informational RFC: RFC 4297 ** Obsolete normative reference: RFC 5046 (Obsoleted by RFC 7145) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP' Summary: 16 errors (**), 0 flaws (~~), 21 warnings (==), 26 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 3 draft-ietf-storm-iscsi-cons-01.txt 4 Intended status: Proposed Standard Julian Satran 5 Expires: January 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- 24 Drafts as reference material or to cite them other than as "work 25 in 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 February 3, 2011. 34 Copyright Notice 36 Copyright (c) 2010 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 Please review these documents carefully, as they describe your 50 rights and restrictions with respect to this document. Code 51 Components extracted from this document must include Simplified BSD 52 License text as described in Section 4.e of the Trust Legal 53 Provisions and are provided without warranty as described in the 54 BSD License. 56 Abstract 58 This document describes a transport protocol for SCSI that works on 59 top of TCP. The iSCSI protocol aims to be fully compliant with the 60 standardized SCSI Architecture Model (SAM). RFC 3720 defined the 61 original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples 62 and discovery techniques. Subsequently, RFC 3980 added an 63 additional naming format to iSCSI protocol. RFC 4850 followed up 64 by adding a new public extension key to iSCSI. RFC 5048 offered a 65 number of clarifications and a few improvements and corrections to 66 the original iSCSI protocol. 68 This document consolidates RFCs 3720, 3980, 4850 and 5048 into a 69 single document and makes additional updates to the consolidated 70 specification. This document also updates RFC 3721. The text in 71 this document thus supersedes the text in RFCs 3720, 3721, 3980, 72 4850 and 5048 whenever there is such a question. 74 1. Introduction..................................................... 14 76 2. Definitions and Acronyms......................................... 15 77 2.1. Definitions .................................................. 15 78 2.2. Acronyms ..................................................... 21 79 2.3. Conventions .................................................. 23 80 2.3.1. Word Rule ................................................ 24 81 2.3.2. Half-Word Rule ........................................... 24 82 2.3.3. Byte Rule ................................................ 25 83 3. UML Conventions.................................................. 26 84 3.1. UML Conventions Overview ................................... 26 85 3.2. Multiplicity Notion ........................................ 26 86 3.3. Class Diagram Conventions .................................. 27 87 3.4. Class Diagram Notation for Associations .................... 28 88 3.5. Class Diagram Notation for Aggregations .................... 29 89 3.6. Class Diagram Notation for Generalizations ................. 29 90 4. Overview......................................................... 30 91 4.1. SCSI Concepts ................................................ 30 92 4.2. iSCSI Concepts and Functional Overview ....................... 31 93 4.2.1. Layers and Sessions ...................................... 31 94 4.2.2. Ordering and iSCSI Numbering ............................. 32 95 4.2.2.1. Command Numbering and Acknowledging .................. 33 96 4.2.2.2. Response/Status Numbering and Acknowledging .......... 37 97 4.2.2.3. Response Ordering .................................... 37 98 4.2.2.3.1. Need for Response Ordering ....................... 37 99 4.2.2.3.2. Response Ordering Model Description .............. 38 100 4.2.2.3.3. iSCSI Semantics with the Interface Model ......... 39 101 4.2.2.3.4. Current List of Fenced Response Use Cases ........ 39 102 4.2.2.4. Data Sequencing ...................................... 40 103 4.2.3. iSCSI Task Management .................................... 41 104 4.2.3.1. Task Management Overview ............................. 41 105 4.2.3.2. Notion of Affected Tasks ............................. 41 106 4.2.3.3. Standard Multi-task Abort Semantics .................. 42 107 4.2.3.4. FastAbort Multi-task Abort Semantics .................43 108 4.2.3.5. Affected Tasks Shared across Standard and FastAbort 109 Sessions ..................................................... 45 110 4.2.3.6. Rationale behind the FastAbort Semantics ............ 46 111 4.2.4. iSCSI Login ............................................. 48 112 4.2.5. iSCSI Full Feature Phase ................................ 50 113 4.2.5.1. Command Connection Allegiance ....................... 50 114 4.2.5.2. Data Transfer Overview .............................. 51 115 4.2.5.3. Tags and Integrity Checks ........................... 52 116 4.2.5.4. Task Management ..................................... 53 117 4.2.6. iSCSI Connection Termination ............................ 53 118 4.2.7. iSCSI Names ............................................. 54 119 4.2.7.1. iSCSI Name Properties ............................... 55 120 4.2.7.2. iSCSI Name Encoding ................................. 56 121 4.2.7.3. iSCSI Name Structure ................................ 57 122 4.2.7.4. Type "iqn." (iSCSI Qualified Name) .................. 59 123 4.2.7.5. Type "eui." (IEEE EUI-64 format) .................... 60 124 4.2.7.6. Type "naa." - Network Address Authority ............. 61 125 4.2.8. Persistent State ........................................ 62 126 4.2.9. Message Synchronization and Steering .................... 62 127 4.2.9.1. Sync/Steering and iSCSI PDU Length .................. 63 128 4.3. iSCSI Session Types ......................................... 64 129 4.4. SCSI to iSCSI Concepts Mapping Model ........................ 64 130 4.4.1. iSCSI Architecture Model ................................ 65 131 4.4.2. SCSI Architecture Model ................................. 68 132 4.4.3. Consequences of the Model ............................... 70 133 4.4.3.1. I_T Nexus State ..................................... 71 134 4.5. iSCSI UML Model ............................................. 71 135 4.6. Request/Response Summary .................................... 74 136 4.6.1. Request/Response Types Carrying SCSI Payload ............ 74 137 4.6.1.1. SCSI-Command ........................................ 74 138 4.6.1.2. SCSI-Response ....................................... 75 139 4.6.1.3. Task Management Function Request .................... 75 140 4.6.1.4. Task Management Function Response ................... 76 141 4.6.1.5. SCSI Data-out and SCSI Data-in ...................... 76 142 4.6.1.6. Ready To Transfer (R2T) ............................. 77 144 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload .......78 145 4.6.2.1. Asynchronous Message .................................78 146 4.6.3. Requests/Responses Carrying iSCSI Only Payload ...........78 147 4.6.3.1. Text Request and Text Response .......................78 148 4.6.3.2. Login Request and Login Response .....................79 149 4.6.3.3. Logout Request and Response ..........................80 150 4.6.3.4. SNACK Request ........................................80 151 4.6.3.5. Reject ...............................................80 152 4.6.3.6. NOP-Out Request and NOP-In Response ..................81 153 5. SCSI Mode Parameters for iSCSI.................................. 82 155 6. Login and Full Feature Phase Negotiation........................ 83 156 6.1. Text Format ................................................. 84 157 6.2. Text Mode Negotiation ....................................... 89 158 6.2.1. List negotiations ....................................... 93 159 6.2.2. Simple-value Negotiations ............................... 93 160 6.3. Login Phase ................................................. 94 161 6.3.1. Login Phase Start ....................................... 97 162 6.3.2. iSCSI Security Negotiation ..............................101 163 6.3.3. Operational Parameter Negotiation During the Login Phase 102 164 6.3.4. Connection Reinstatement ................................103 165 6.3.5. Session Reinstatement, Closure, and Timeout .............104 166 6.3.5.1. Loss of Nexus Notification ..........................104 167 6.3.6. Session Continuation and Failure ........................105 168 6.4. Operational Parameter Negotiation Outside the Login Phase ...105 169 7. iSCSI Error Handling and Recovery...............................107 170 7.1. Overview ....................................................107 171 7.1.1. Background ..............................................107 172 7.1.2. Goals ...................................................107 173 7.1.3. Protocol Features and State Expectations ................108 174 7.1.4. Recovery Classes ........................................109 175 7.1.4.1. Recovery Within-command .............................110 176 7.1.4.2. Recovery Within-connection ..........................111 177 7.1.4.3. Connection Recovery .................................112 178 7.1.4.4. Session Recovery ....................................113 180 7.1.5. Error Recovery Hierarchy ................................113 181 7.2. Retry and Reassign in Recovery ..............................115 182 7.2.1. Usage of Retry ..........................................115 183 7.2.2. Allegiance Reassignment .................................116 184 7.3. Usage Of Reject PDU in Recovery .............................117 185 7.4. Error Recovery Considerations for Discovery Sessions ........118 186 7.4.1. ErrorRecoveryLevel for Discovery Sessions ...............118 187 7.4.2. Reinstatement Semantics for Discovery Sessions ..........118 188 7.4.2.1. Unnamed Discovery Sessions ..........................119 189 7.4.2.2. Named Discovery Session .............................120 190 7.4.3. Target PDUs During Discovery ............................120 191 7.5. Connection Timeout Management ...............................120 192 7.5.1. Timeouts on Transport Exception Events ..................121 193 7.5.2. Timeouts on Planned Decommissioning .....................121 194 7.6. Implicit Termination of Tasks ...............................121 195 7.7. Format Errors ...............................................122 196 7.8. Digest Errors ...............................................123 197 7.9. Sequence Errors .............................................125 198 7.10. Message Error Checking .....................................125 199 7.11. SCSI Timeouts ..............................................126 200 7.12. Negotiation Failures .......................................127 201 7.13. Protocol Errors ............................................127 202 7.14. Connection Failures ........................................128 203 7.15. Session Errors .............................................129 204 8. State Transitions...............................................130 205 8.1. Standard Connection State Diagrams ..........................130 206 8.1.1. State Descriptions for Initiators and Targets ...........130 207 8.1.2. State Transition Descriptions for Initiators and Targets 131 208 8.1.3. Standard Connection State Diagram for an Initiator ......135 209 8.1.4. Standard Connection State Diagram for a Target ..........137 210 8.2. Connection Cleanup State Diagram for Initiators and Targets .139 211 8.2.1. State Descriptions for Initiators and Targets ...........141 212 8.2.2. State Transition Descriptions for Initiators and Targets 141 213 8.3. Session State Diagrams ......................................143 214 8.3.1. Session State Diagram for an Initiator ..................143 215 8.3.2. Session State Diagram for a Target ......................144 216 8.3.3. State Descriptions for Initiators and Targets ...........146 217 8.3.4. State Transition Descriptions for Initiators and Targets 147 218 9. Security Considerations.........................................149 219 9.1. iSCSI Security Mechanisms ...................................149 220 9.2. In-band Initiator-Target Authentication .....................150 221 9.2.1. CHAP Considerations .....................................151 222 9.2.2. SRP Considerations ......................................153 223 9.3. IPsec .......................................................154 224 9.3.1. Data Integrity and Authentication .......................154 225 9.3.2. Confidentiality .........................................155 226 9.3.3. Policy, Security Associations, and Cryptographic Key 227 Management .....................................................155 228 9.4. Security Considerations for the X#NodeArchitecture Key ......157 229 10. Notes to Implementers..........................................159 230 10.1. Multiple Network Adapters ..................................159 231 10.1.1. Conservative Reuse of ISIDs ............................159 232 10.1.2. iSCSI Name, ISID, and TPGT Use .........................160 233 10.2. Autosense and Auto Contingent Allegiance (ACA) .............162 234 10.3. iSCSI Timeouts .............................................162 235 10.4. Command Retry and Cleaning Old Command Instances ...........163 236 10.5. Synch and Steering Layer and Performance ...................164 237 10.6. Considerations for State-dependent Devices and Long-lasting 238 SCSI Operations ..................................................164 239 10.6.1. Determining the Proper ErrorRecoveryLevel ..............165 240 10.7. Multi-task Abort Implementation Considerations .............166 241 11. iSCSI PDU Formats..............................................167 242 11.1. iSCSI PDU Length and Padding ...............................167 243 11.2. PDU Template, Header, and Opcodes ..........................167 244 11.2.1. Basic Header Segment (BHS) .............................168 245 11.2.1.1. I ..................................................169 246 11.2.1.2. Opcode .............................................169 247 11.2.1.3. Final (F) bit ......................................171 248 11.2.1.4. Opcode-specific Fields .............................171 249 11.2.1.5. TotalAHSLength .....................................171 250 11.2.1.6. DataSegmentLength ..................................171 251 11.2.1.7. LUN ................................................171 252 11.2.1.8. Initiator Task Tag .................................172 253 11.2.2. Additional Header Segment (AHS) ........................172 254 11.2.2.1. AHSType ............................................172 255 11.2.2.2. AHSLength ..........................................173 256 11.2.2.3. Extended CDB AHS ...................................173 257 11.2.2.4. Bidirectional Expected Read-Data Length AHS ........173 258 11.2.3. Header Digest and Data Digest ..........................174 259 11.2.4. Data Segment ...........................................174 260 11.3. SCSI Command ...............................................174 261 11.3.1. Flags and Task Attributes (byte 1) .....................175 262 11.3.2. CmdSN - Command Sequence Number ........................176 263 11.3.3. ExpStatSN ..............................................177 264 11.3.4. Expected Data Transfer Length ..........................177 265 11.3.5. CDB - SCSI Command Descriptor Block ....................178 266 11.3.6. Data Segment - Command Data ............................178 267 11.4. SCSI Response ..............................................178 268 11.4.1. Flags (byte 1) .........................................179 269 11.4.2. Status .................................................180 270 11.4.3. Response ...............................................181 271 11.4.4. SNACK Tag ..............................................182 272 11.4.5. Residual Count .........................................182 273 11.4.5.1. Field Semantics ....................................182 274 11.4.5.2. Residuals Concepts Overview ........................183 275 11.4.5.3. SCSI REPORT LUNS and Residual Overflow .............183 276 11.4.6. Bidirectional Read Residual Count ......................185 277 11.4.7. Data Segment - Sense and Response Data Segment .........185 278 11.4.7.1. SenseLength ........................................186 279 11.4.7.2. Sense Data .........................................186 280 11.4.8. ExpDataSN ..............................................187 281 11.4.9. StatSN - Status Sequence Number ........................187 282 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator ....188 283 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator ..........188 284 11.5. Task Management Function Request ...........................189 285 11.5.1. Function ...............................................189 286 11.5.2. TotalAHSLength and DataSegmentLength ...................193 287 11.5.3. LUN ....................................................193 288 11.5.4. Referenced Task Tag ....................................193 289 11.5.5. RefCmdSN ...............................................193 290 11.5.6. ExpDataSN ..............................................194 291 11.6. Task Management Function Response ..........................194 292 11.6.1. Response ...............................................195 293 11.6.2. TotalAHSLength and DataSegmentLength ...................197 294 11.7. SCSI Data-out & SCSI Data-in ...............................197 295 11.7.1. F (Final) Bit ..........................................200 296 11.7.2. A (Acknowledge) bit ....................................200 297 11.7.3. Flags (byte 1) .........................................201 298 11.7.4. Target Transfer Tag and LUN ............................202 299 11.7.5. DataSN .................................................202 300 11.7.6. Buffer Offset ..........................................203 301 11.7.7. DataSegmentLength ......................................203 302 11.8. Ready To Transfer (R2T) ....................................204 303 11.8.1. TotalAHSLength and DataSegmentLength ...................206 304 11.8.2. R2TSN ..................................................206 305 11.8.3. StatSN .................................................206 306 11.8.4. Desired Data Transfer Length and Buffer Offset .........206 307 11.8.5. Target Transfer Tag ....................................206 308 11.9. Asynchronous Message .......................................207 309 11.9.1. AsyncEvent .............................................209 310 11.9.2. AsyncVCode .............................................212 311 11.9.3. LUN ....................................................212 312 11.9.4. Sense Data and iSCSI Event Data ........................212 313 11.9.4.1. SenseLength ........................................212 314 11.10. Text Request ..............................................213 315 11.10.1. F (Final) Bit .........................................214 316 11.10.2. C (Continue) Bit ......................................214 317 11.10.3. Initiator Task Tag ....................................214 318 11.10.4. Target Transfer Tag ...................................214 319 11.10.5. Text ..................................................215 320 11.11. Text Response .............................................216 321 11.11.1. F (Final) Bit .........................................217 322 11.11.2. C (Continue) Bit ......................................218 323 11.11.3. Initiator Task Tag ....................................218 324 11.11.4. Target Transfer Tag ...................................218 325 11.11.5. StatSN ................................................219 326 11.11.6. Text Response Data ....................................219 327 11.12. Login Request .............................................219 328 11.12.1. T (Transit) Bit .......................................220 329 11.12.2. C (Continue) Bit ......................................221 330 11.12.3. CSG and NSG ...........................................221 331 11.12.4. Version ...............................................221 332 11.12.4.1. Version-max .......................................221 333 11.12.4.2. Version-min .......................................222 334 11.12.5. ISID ..................................................222 335 11.12.6. TSIH ..................................................224 336 11.12.7. Connection ID - CID ...................................224 337 11.12.8. CmdSN .................................................224 338 11.12.9. ExpStatSN .............................................225 339 11.12.10. Login Parameters .....................................225 340 11.13. Login Response ............................................226 341 11.13.1. Version-max ...........................................226 342 11.13.2. Version-active ........................................227 343 11.13.3. TSIH ..................................................227 344 11.13.4. StatSN ................................................227 345 11.13.5. Status-Class and Status-Detail ........................227 346 11.13.6. T (Transit) bit .......................................231 347 11.13.7. C (Continue) Bit ......................................232 348 11.13.8. Login Parameters ......................................232 349 11.14. Logout Request ............................................232 350 11.14.1. Reason Code ...........................................235 351 11.14.2. TotalAHSLength and DataSegmentLength ..................236 352 11.14.3. CID ...................................................236 353 11.14.4. ExpStatSN .............................................236 354 11.14.5. Implicit termination of tasks .........................236 355 11.15. Logout Response ...........................................237 356 11.15.1. Response ..............................................238 357 11.15.2. TotalAHSLength and DataSegmentLength .................. 239 358 11.15.3. Time2Wait ............................................. 239 359 11.15.4. Time2Retain ........................................... 239 360 11.16. SNACK Request ............................................. 241 361 11.16.1. Type .................................................. 242 362 11.16.2. Data Acknowledgement .................................. 243 363 11.16.3. Resegmentation ........................................ 243 364 11.16.4. Initiator Task Tag .................................... 244 365 11.16.5. Target Transfer Tag or SNACK Tag ...................... 244 366 11.16.6. BegRun ................................................ 245 367 11.16.7. RunLength ............................................. 245 368 11.17. Reject .................................................... 246 369 11.17.1. Reason ................................................ 247 370 11.17.2. DataSN/R2TSN .......................................... 248 371 11.17.3. StatSN, ExpCmdSN and MaxCmdSN ......................... 248 372 11.17.4. Complete Header of Bad PDU ............................ 249 373 11.18. NOP-Out ................................................... 249 374 11.18.1. Initiator Task Tag .................................... 250 375 11.18.2. Target Transfer Tag ................................... 250 376 11.18.3. Ping Data ............................................. 250 377 11.19. NOP-In .................................................... 251 378 11.19.1. Target Transfer Tag ................................... 252 379 11.19.2. StatSN ................................................ 252 380 11.19.3. LUN ................................................... 252 381 12. iSCSI Security Text Keys and Authentication Methods............ 253 382 12.1. AuthMethod ................................................. 253 383 12.1.1. Kerberos ............................................... 255 384 12.1.2. Secure Remote Password (SRP) ........................... 256 385 12.1.3. Challenge Handshake Authentication Protocol (CHAP) ..... 257 386 13. Login/Text Operational Text Keys............................... 260 387 13.1. HeaderDigest and DataDigest .............................. 260 388 13.2. MaxConnections ........................................... 263 389 13.3. SendTargets .............................................. 263 390 13.4. TargetName ............................................... 264 391 13.5. InitiatorName ............................................ 264 392 13.6. TargetAlias ............................................... 265 393 13.7. InitiatorAlias ............................................ 265 394 13.8. TargetAddress ............................................. 266 395 13.9. TargetPortalGroupTag ...................................... 267 396 13.10. InitialR2T ............................................... 268 397 13.11. ImmediateData ............................................ 268 398 13.12. MaxRecvDataSegmentLength ................................. 269 399 13.13. MaxBurstLength ........................................... 270 400 13.14. FirstBurstLength ......................................... 270 401 13.15. DefaultTime2Wait ......................................... 271 402 13.16. DefaultTime2Retain ....................................... 271 403 13.17. MaxOutstandingR2T ........................................ 272 404 13.18. DataPDUInOrder ........................................... 272 405 13.19. DataSequenceInOrder ...................................... 273 406 13.20. ErrorRecoveryLevel ....................................... 274 407 13.21. SessionType .............................................. 274 408 13.22. The Private or Public Extension Key Format ............... 275 409 13.23. Task Reporting ........................................... 275 410 13.24. X#NodeArchitecture ....................................... 276 411 13.24.1. Definition ........................................... 276 412 13.24.2. Implementation Requirements .......................... 277 413 14. IANA Considerations........................................... 279 415 Appendix A. Examples ............................................. 285 416 Read Operation Example .......................................... 285 417 Write Operation Example ......................................... 286 418 R2TSN/DataSN Use Examples ....................................... 286 419 CRC Examples .................................................... 290 420 Appendix B. Login Phase Examples ................................. 292 422 Appendix C. SendTargets Operation ................................ 302 424 Appendix D. Algorithmic Presentation of Error Recovery Classes ... 307 425 D.2.1. Procedure Descriptions ................................. 310 426 Appendix E. Clearing Effects of Various Events on Targets ........ 326 427 1. Introduction 429 The Small Computer Systems Interface (SCSI) is a popular family of 430 protocols for communicating with I/O devices, especially storage 431 devices. SCSI is a client-server architecture. Clients of a SCSI 432 interface are called "initiators". Initiators issue SCSI 433 "commands" to request services from components, logical units of a 434 server known as a "target". A "SCSI transport" maps the client- 435 server SCSI protocol to a specific interconnect. An Initiator is 436 one endpoint of a SCSI transport and a target is the other 437 endpoint. 439 The SCSI protocol has been mapped over various transports, 440 including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre 441 Channel. These transports are I/O specific and have limited 442 distance capabilities. 444 The iSCSI protocol defined in this document describes a means of 445 transporting of the SCSI packets over TCP/IP, providing for an 446 interoperable solution which can take advantage of existing 447 Internet infrastructure, Internet management facilities and address 448 distance limitations. 450 2. Definitions and Acronyms 452 2.1. Definitions 454 - Alias: An alias string can also be associated with an iSCSI Node. 455 The alias allows an organization to associate a user-friendly 456 string with the iSCSI Name. However, the alias string is not a 457 substitute for the iSCSI Name. 459 - CID (Connection ID): Connections within a session are identified 460 by a connection ID. It is a unique ID for this connection within 461 the session for the initiator. It is generated by the initiator and 462 presented to the target during login requests and during logouts 463 that close connections. 465 - Connection: A connection is a TCP connection. Communication 466 between the initiator and target occurs over one or more TCP 467 connections. The TCP connections carry control messages, SCSI 468 commands, parameters, and data within iSCSI Protocol Data Units 469 (iSCSI PDUs). 471 - I/O Buffer:A buffer that is used in a SCSI Read or Write 472 operation so SCSI data may be sent from or received into that 473 buffer. For a read or write data transfer to take place for a task, 474 an I/O Buffer is required on the initiator and at least one is 475 required on the 476 target. 478 - INCITS: INCITS stands for InterNational Committee of Information 479 Technology Standards. The INCITS has a broad standardization scope 480 within the field of Information and Communications Technologies 481 (ICT), encompassing storage, processing, transfer, display, 482 management, organization, and retrieval of information. INCITS 483 serves as ANSI's Technical Advisory Group for the ISO/IEC Joint 484 Technical Committee 1 (JTC 1). See http://www.incits.org. 486 - InfiniBand: An I/O architecture originally intended to replace 487 PCI and to address high performance server interconnectivity [IB]. 489 - iSCSI Device: A SCSI Device using an iSCSI service delivery 490 subsystem. Service Delivery Subsystem is defined by [SAM2] as a 491 transport mechanism for SCSI commands and responses. 493 - iSCSI Initiator Name: The iSCSI Initiator Name specifies the 494 worldwide unique name of the initiator. 496 - iSCSI Initiator Node: The "initiator" device. The word 497 "initiator" has been appropriately qualified as either a port or a 498 device in the rest of the document when the context is ambiguous. 499 All unqualified usages of "initiator" refer to an initiator port 500 (or device) depending on the context. 502 - iSCSI Layer: This layer builds/receives iSCSI PDUs and 503 relays/receives them to/from one or more TCP connections that form 504 an initiator-target "session". 506 - iSCSI Name: The name of an iSCSI initiator or iSCSI target. 508 - iSCSI Node: The iSCSI Node represents a single iSCSI initiator or 509 iSCSI target or a single instance of each. There are one or more 510 iSCSI Nodes within a Network Entity. The iSCSI Node is accessible 511 via one or more Network Portals. An iSCSI Node is identified by its 512 iSCSI Name. The separation of the iSCSI Name from the addresses 513 used by and for the iSCSI Node allows multiple iSCSI nodes to use 514 the same address, and the same iSCSI node to use multiple 515 addresses. 517 - iSCSI Target Name: The iSCSI Target Name specifies the worldwide 518 unique name of the target. 520 - iSCSI Target Node: The "target" device. The word "target" has 521 been appropriately qualified as either a port or a device in the 522 rest of the document when the context is ambiguous. All 523 unqualified usages of "target" refer to a target port (or device) 524 depending on the context. 526 - iSCSI Task: An iSCSI task is an iSCSI request for which a 527 response is expected. 529 - iSCSI Transfer Direction: The iSCSI transfer direction is defined 530 with regard to the initiator. Outbound or outgoing transfers are 531 transfers from the initiator to the target, while inbound or 532 incoming transfers are from the target to the initiator. 534 - ISID: The initiator part of the Session Identifier. It is 535 explicitly specified by the initiator during Login. 537 - I_T nexus: According to [SAM2], the I_T nexus is a relationship 538 between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, 539 this relationship is a session, defined as a relationship between 540 an iSCSI Initiator's end of the session (SCSI Initiator Port) and 541 the iSCSI Target's Portal Group. The I_T nexus can be identified by 542 the conjunction of the SCSI port names; that is, the I_T nexus 543 identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI 544 Target Name + ',t,'+ Portal Group Tag). 546 - NAA: Network Address Authority, a naming format defined by the 547 INCITS T11 Fibre Channel protocols [FC-FS]. 549 - Network Entity: The Network Entity represents a device or gateway 550 that is accessible from the IP network. A Network Entity must have 551 one or more Network Portals, each of which can be used to gain 552 access to the IP network by some iSCSI Nodes contained in that 553 Network Entity. 555 - Network Portal: The Network Portal is a component of a Network 556 Entity that has a TCP/IP network address and that may be used by an 557 iSCSI Node within that Network Entity for the connection(s) within 558 one of its iSCSI sessions. A Network Portal in an initiator is 559 identified by its IP address. A Network Portal in a target is 560 identified by its IP address and its listening TCP port. 562 - Originator: In a negotiation or exchange, the party that 563 initiates the negotiation or exchange. 565 - PDU (Protocol Data Unit): The initiator and target divide their 566 communications into messages. The term "iSCSI protocol data unit" 567 (iSCSI PDU) is used for these messages. 569 - Portal Groups: iSCSI supports multiple connections within the 570 same session; some implementations will have the ability to combine 571 connections in a session across multiple Network Portals. A Portal 572 Group defines a set of Network Portals within an iSCSI Network 573 Entity that collectively supports the capability of coordinating a 574 session with connections spanning these portals. Not all Network 575 Portals within a Portal Group need participate in every session 576 connected through that Portal Group. One or more Portal Groups may 577 provide access to an iSCSI Node. Each Network Portal, as utilized 578 by a given iSCSI Node, belongs to exactly one portal group within 579 that node. 581 - Portal Group Tag: This 16-bit quantity identifies a Portal Group 582 within an iSCSI Node. All Network Portals with the same portal 583 group tag in the context of a given iSCSI Node are in the same 584 Portal Group. 586 - Recovery R2T: An R2T generated by a target upon detecting the 587 loss of one or more Data-Out PDUs through one of the following 588 means: a digest error, a sequence error, or a sequence reception 589 timeout. A recovery R2T carries the next unused R2TSN, but requests 590 all or part of the data burst that an earlier R2T (with a lower 591 R2TSN) had already requested. 593 - Responder: In a negotiation or exchange, the party that responds 594 to the originator of the negotiation or exchange. 596 - SAS: Serial Attached SCSI. The Serial Attached SCSI (SAS) 597 standard 598 contains both a physical layer compatible with Serial ATA, and 599 protocols for transporting SCSI commands to SAS devices and ATA 600 commands to SATA devices [SAS]. 602 - SCSI Device: This is the SAM2 term for an entity that contains 603 one or more SCSI ports that are connected to a service delivery 604 subsystem and supports a SCSI application protocol. For example, a 605 SCSI Initiator Device contains one or more SCSI Initiator Ports and 606 zero or more application clients. A Target Device contains one or 607 more SCSI Target Ports and one or more device servers and 608 associated logical units. For iSCSI, the SCSI Device is the 609 component within an iSCSI Node that provides the SCSI 610 functionality. As such, there can be, at most, one SCSI Device 611 within a given iSCSI Node. Access to the SCSI Device can only be 612 achieved in an iSCSI normal operational session. The SCSI Device 613 Name is defined to be the iSCSI Name of the node. 615 - SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor 616 Blocks) and relays/receives them with the remaining command execute 617 [SAM2] parameters to/from the iSCSI Layer. 619 - Session: The group of TCP connections that link an initiator with 620 a target form a session (loosely equivalent to a SCSI I-T nexus). 621 TCP connections can be added and removed from a session. Across all 622 connections within a session, an initiator sees one and the same 623 target. 625 - SCSI Initiator Port: This maps to the endpoint of an iSCSI normal 626 operational session. An iSCSI normal operational session is 627 negotiated through the login process between an iSCSI initiator 628 node and an iSCSI target node. At successful completion of this 629 process, a SCSI Initiator Port is created within the SCSI Initiator 630 Device. The SCSI Initiator Port Name and SCSI Initiator Port 631 Identifier are both defined to be the iSCSI Initiator Name together 632 with (a) a label that identifies it as an initiator port 633 name/identifier and (b) the ISID portion of the session identifier. 635 - SCSI Port: This is the SAM2 term for an entity in a SCSI Device 636 that provides the SCSI functionality to interface with a service 637 delivery subsystem. For iSCSI, the definition of the SCSI Initiator 638 Port and the SCSI Target Port are different. 640 - SCSI Port Name: A name made up as UTF-8 characters and includes 641 the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag. 643 - SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the 644 aggregate data length of the data that the SCSI layer logically 645 "presents" to the iSCSI layer for a Data-In or Data-Out transfer in 646 the context of a SCSI task. For a bidirectional task, there are two 647 SPDTL values -- one for Data-In and one for Data-Out. Note that the 648 notion of "presenting" includes immediate data per the data 649 transfer model in [SAM2], and excludes overlapping data transfers, 650 if any, requested by the SCSI layer. 652 - SCSI Target Port: This maps to an iSCSI Target Portal Group. 654 - SCSI Target Port Name and SCSI Target Port Identifier: These are 655 both defined to be the iSCSI Target Name together with (a) a label 656 that identifies it as a target port name/identifier and (b) the 657 portal group tag. 659 - SRP: SCSI RDMA Protocol. SRP defines a SCSI protocol mapping onto 660 the InfiniBand (tm) Architecture and/or functionally similar Remote 661 DMA-capable protocols [SRP]. 663 - SSID (Session ID): A session between an iSCSI initiator and an 664 iSCSI target is defined by a session ID that is a tuple composed of 665 an initiator part (ISID) and a target part (Target Portal Group 666 Tag). The ISID is explicitly specified by the initiator at session 667 establishment. The Target Portal Group Tag is implied by the 668 initiator through the selection of the TCP endpoint at connection 669 establishment. The TargetPortalGroupTag key must also be returned 670 by the target as a confimation during connection establishment. 672 - T10: A technical committee within INCITS that develops standards 673 and technical reports on I/O interfaces, particularly the series of 674 SCSI (Small Computer Systems Interface) standards. See 675 http://www.t10.org. 677 - T11: A technical committee within INCITS responsible for 678 standards development in the areas of Intelligent Peripheral 679 Interface (IPI), High-Performance Parallel Interface (HIPPI) and 680 Fibre Channel (FC). See http://www.t11.org. 682 - Target Portal Group Tag: A numerical identifier (16-bit) for an 683 iSCSI Target Portal Group. 685 - Third-party: A term used in this document to denote nexus objects 686 (I_T or I_T_L) and iSCSI sessions that reap the side effects of 687 actions that take place in the context of a separate iSCSI session, 688 while being third parties to the action that caused the side 689 effects. One example of a third-party session is an iSCSI session 690 hosting an I_T_L nexus to an LU that is reset with an LU Reset TMF 691 via a separate I_T nexus. 693 - TSIH (Target Session Identifying Handle): A target assigned tag 694 for a session with a specific named initiator. The target generates 695 it during session establishment. Other than defining it as a 16 bit 696 binary string, its internal format and content are not defined by 697 this protocol but for the all 0 value that is reserved and used by 698 the initiator to indicate a new session. It is given to the target 699 during additional connection establishment for the same session. 701 2.2. Acronyms 703 Acronym Definition 704 -------------------------------------------------------------- 705 3DES Triple Data Encryption Standard 706 ACA Auto Contingent Allegiance 707 AEN Asynchronous Event Notification 708 AES Advanced Encryption Standard 709 AH Additional Header (not the IPsec AH!) 710 AHS Additional Header Segment 711 API Application Programming Interface 712 ASC Additional Sense Code 713 ASCII American Standard Code for Information Interchange 714 ASCQ Additional Sense Code Qualifier 715 BHS Basic Header Segment 716 CBC Cipher Block Chaining 717 CD Compact Disk 718 CDB Command Descriptor Block 719 CHAP Challenge Handshake Authentication Protocol 720 CID Connection ID 721 CO Connection Only 722 CRC Cyclic Redundancy Check 723 CRL Certificate Revocation List 724 CSG Current Stage 725 CSM Connection State Machine 726 DES Data Encryption Standard 727 DNS Domain Name Server 728 DOI Domain of Interpretation 729 DVD Digital Versatile Disk 730 EDTL Expected Data Transfer Length 731 ESP Encapsulating Security Payload 732 EUI Extended Unique Identifier 733 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 740 I_T_L Initiator_Target_LUN 741 IANA Internet Assigned Numbers Authority 742 IB InfiniBand 743 ID Identifier 744 IDN Internationalized Domain Name 745 IEEE Institute of Electrical & Electronics Engineers 746 IETF Internet Engineering Task Force 747 IKE Internet Key Exchange 748 I/O Input & Output 749 IO Initialize Only 750 IP Internet Protocol 751 IPsec Internet Protocol Security 752 IPv4 Internet Protocol Version 4 753 IPv6 Internet Protocol Version 6 754 IQN iSCSI Qualified Name 755 iSCSI Internet SCSI 756 iSER iSCSI Extensions for RDMA 757 ISID Initiator Session ID 758 iSNS Internet Storage Name Service (see [RFC4171]) 759 ITN iSCSI Target Name 760 ITT Initiator Task Tag 761 KRB5 Kerberos V5 762 LFL Lower Functional Layer 763 LTDS Logical-Text-Data-Segment 764 LO Leading Only 765 LU Logical Unit 766 LUN Logical Unit Number 767 MAC Message Authentication Codes 768 NA Not Applicable 769 NAA Network Address Authority 770 NIC Network Interface Card 771 NOP No Operation 772 NSG Next Stage 773 OS Operating System 774 PDU Protocol Data Unit 775 PKI Public Key Infrastructure 776 R2T Ready To Transfer 777 R2TSN Ready To Transfer Sequence Number 778 RDMA Remote Direct Memory Access 779 RFC Request For Comments 780 SAM SCSI Architecture Model 781 SAM2 SCSI Architecture Model - 2 782 SAN Storage Area Network 783 SAS Serial Attached SCSI 784 SCSI Small Computer Systems Interface 785 SN Sequence Number 786 SNACK Selective Negative Acknowledgment - also 787 Sequence Number Acknowledgement for data 788 SPDTL SCSI-Presented Data Transfer Length 789 SPKM Simple Public-Key Mechanism 790 SRP Secure Remote Password, also SCSI RDMA Protocol 791 SSID Session ID 792 SW Session Wide 793 TCB Task Control Block 794 TCP Transmission Control Protocol 795 TMF Task Management Function 796 TPGT Target Portal Group Tag 797 TSIH Target Session Identifying Handle 798 TTT Target Transfer Tag 799 UFL Upper Functional Layer 800 ULP Upper Level Protocol 801 URN Uniform Resource Names 802 UTF Universal Transformation Format 803 WG Working Group 805 2.3. Conventions 807 In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator 808 and target respectively. 810 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 811 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 812 this document are to be interpreted as described in RFC 2119 813 [RFC2119]. 815 iSCSI messages - PDUs - are represented by diagrams as in the 816 following example: 818 Byte/ 0 | 1 | 2 | 3 | 819 / | | | | 820 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 821 +---------------+---------------+---------------+---------------+ 822 0| Basic Header Segment (BHS) | 823 +---------------+---------------+---------------+---------------+ 824 ---------- 825 +| | 826 +---------------+---------------+---------------+---------------+ 828 The diagrams include byte and bit numbering. 830 The following representation and ordering rules are observed in 831 this document: 833 - Word Rule 835 - Half-word Rule 837 - Byte Rule 839 2.3.1. Word Rule 841 A word holds four consecutive bytes. Whenever a word has numeric 842 content, it is considered an unsigned number in base 2 positional 843 representation with the lowest numbered byte (e.g., byte 0) bit 0 844 representing 2**31 and bit 1 representing 2**30 through lowest 845 numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0. 847 Decimal and hexadecimal representation of word values map this 848 representation to decimal or hexadecimal positional notation. 850 2.3.2. Half-Word Rule 852 A half-word holds two consecutive bytes. Whenever a half-word has 853 numeric content it is considered an unsigned number in base 2 854 positional representation with the lowest numbered byte (e.g., byte 855 0) bit 0 representing 2**15 and bit 1 representing 2**14 through 856 lowest numbered byte + 1 (e.g., byte 1) bit 7 representing 2**0. 858 Decimal and hexadecimal representation of half-word values map this 859 representation to decimal or hexadecimal positional notation. 861 2.3.3. Byte Rule 863 For every PDU, bytes are sent and received in increasing numbered 864 order (network order). 866 Whenever a byte has numerical content it is considered an unsigned 867 number in base 2 positional representation with bit 0 representing 868 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0. 870 3. UML Conventions 872 3.1. UML Conventions Overview 874 The SCSI Architecture Model (SAM) uses class diagrams and object 875 diagrams with notation that is based on the Unified Modeling 876 Language [UML]. Therefore, this document also uses UML to model 877 the relationships for SCSI and iSCSI objects. 879 A treatise on the graphical notation used in UML is beyond the 880 scope of this document. However, given the use of ASCII drawing 881 for UML static class diagrams, a description of the notational 882 conventions used in this document is included in the remainder of 883 this section. 885 3.2. Multiplicity Notion 887 Not specified The number of instances of an attribute is not 888 specified. 890 1 One instance of the class or attribute exists. 892 0..* Zero or more instances of the class or attribute exist. 894 1..* One or more instances of the class or attribute exist. 896 0..1 Zero or one instance of the class or attribute exists. 898 n..m n to m instances of the class or attribute exist 899 (e.g., 2..8). 901 x, n..m Multiple disjoint instances of the class or 902 attribute exist (e.g., 2, 8..15). 904 3.3. Class Diagram Conventions 906 +--------------+ +--------------+ +--------------+ 907 | Class Name | | Class Name | | Class Name | 908 +--------------+ +--------------+ +--------------+ 909 | | | | 910 +--------------+ +--------------+ 911 | | 912 +--------------+ 913 The previous three diagrams are examples of a class with no 914 attributes and with no operations. 916 +-------------------+ +-------------------+ 917 | Class Name | | Class Name | 918 +-------------------+ +-------------------+ 919 | attribute 01[1] | | attribute 01[1] | 920 | attribute 02[1] | | attribute 02[1] | 921 +-------------------+ +-------------------+ 922 | | 923 +-------------------+ 924 The preceding two diagrams are examples of a class with attributes 925 and with no operations. 927 +------------------------+ 928 | Class Name | 929 +------------------------+ 930 | attribute 01[1..*] | 931 | attribute 02[1] | 932 +------------------------+ 933 | operation 01() | 934 | operation 02() | 935 +------------------------+ 936 The preceding diagram is an example of a class with attributes that 937 have a specified multiplicity and operations. 939 3.4. Class Diagram Notation for Associations 941 +-----------------+ 942 | Class A | 943 +-----------------+ association_name +-----------------+ 944 | attribute 01[1] |<------------------>| Class B | 945 | attribute 02[1] | 1..* 0..1 +-----------------+ 946 +-----------------+ | attribute 03[1] | 947 | operation 1() | +-----------------+ 948 +-----------------+ 949 The preceding diagram is an example where Class A knows about Class 950 B (i.e., read as "Class A association_name ClassB") and Class B 951 knows about Class A (i.e., read as "Class B association_name Class 952 A"). The use of association_name is optional. The multiplicity 953 notation (1..* and 0..1) indicates the number of instances of the 954 object. 956 +--------------------+ 957 | Class A | 958 +--------------------+ +--------------------+ 959 | attribute 01[1] |<-------------| Class B | 960 | attribute 02[1] | 1 0..1 +--------------------+ 961 +--------------------+ | attribute 03[1] | 962 | operation 1() | +--------------------+ 963 +--------------------+ 964 The preceding diagram is an example where Class B knows about Class 965 A (i.e., read as "Class B knows about Class A") but Class A does 966 not know about Class B. 968 +----------------------+ 969 | Class A | 970 +----------------------+ +--------------------+ 971 | attribute 01[1] |----------->| Class B | 972 | attribute 02[1] | 0..* 1 +--------------------+ 973 +----------------------+ | attribute 03[1] | 974 | operation 1() | +--------------------+ 975 +----------------------+ 976 The preceding diagram is an example where Class A knows about Class 977 B (i.e., read as "Class A knows about Class B") but Class B does 978 not know about Class A. 980 3.5. Class Diagram Notation for Aggregations 982 +---------------+ +--------------+ 983 | Class whole |o------------| Class part | 984 +---------------+ +--------------+ 985 The preceding diagram is an example where Class whole is an 986 aggregate that contains Class part and where Class part may 987 continue to exist even if Class whole is removed (i.e., read as 988 "the whole contains the part"). 990 +---------------+ +--------------+ 991 | Class whole |@------------| Class part | 992 +---------------+ +--------------+ 993 The preceding diagram is an example where Class whole is an 994 aggregate that contains Class part where Class part shall only 995 belong to one Class whole, and the Class part shall not continue to 996 exist if the Class whole is removed (i.e., read as "the whole 997 contains the part"). 999 +-------------+ 1000 | | 1001 +-------------+ 1002 | | 1003 + =(a)= + 1004 | | 1005 The preceding diagram is an example where there is a constraint 1006 between the associations where the (a) footnote describes the 1007 constraint. 1009 3.6. Class Diagram Notation for Generalizations 1011 +---------------+ 1012 | Superclass | 1013 +-------^-------+ 1014 /_\ 1015 | 1016 +---------------+ 1017 | Subclass | 1018 +---------------+ 1019 The preceding diagram is an example where the subclass is a kind of 1020 superclass. A subclass shares all the attributes and operations of 1021 the superclass (i.e., the subclass inherits from the superclass). 1023 4. Overview 1025 4.1. SCSI Concepts 1027 The SCSI Architecture Model-2 [SAM2] describes in detail the 1028 architecture of the SCSI family of I/O protocols. This section 1029 provides a brief background of the SCSI architecture and is 1030 intended to familiarize readers with its terminology. 1032 At the highest level, SCSI is a family of interfaces for requesting 1033 services from I/O devices, including hard drives, tape drives, CD 1034 and DVD drives, printers, and scanners. In SCSI terminology, an 1035 individual I/O device is called a "logical unit" (LU). 1037 SCSI is a client-server architecture. Clients of a SCSI interface 1038 are called "initiators". Initiators issue SCSI "commands" to 1039 request services from components, logical units, of a server known 1040 as a "target". The "device server" on the logical unit accepts SCSI 1041 commands and processes them. 1043 A "SCSI transport" maps the client-server SCSI protocol to a 1044 specific interconnect. Initiator is one endpoint of a SCSI 1045 transport. The "target" is the other endpoint. A target can contain 1046 multiple Logical Units (LUs). Each Logical Unit has an address 1047 within a target called a Logical Unit Number (LUN). 1049 A SCSI task is a SCSI command or possibly a linked set of SCSI 1050 commands. Some LUs support multiple pending (queued) tasks, but the 1051 queue of tasks is managed by the logical unit. The target uses an 1052 initiator provided "task tag" to distinguish between tasks. Only 1053 one command in a task can be outstanding at any given time. 1055 Each SCSI command results in an optional data phase and a required 1056 response phase. In the data phase, information can travel from the 1057 initiator to target (e.g., WRITE), target to initiator (e.g., 1058 READ), or in both directions. In the response phase, the target 1059 returns the final status of the operation, including any errors. 1061 Command Descriptor Blocks (CDB) are the data structures used to 1062 contain the command parameters that an initiator sends to a target. 1063 The CDB content and structure is defined by [SAM2] and device-type 1064 specific SCSI standards. 1066 4.2. iSCSI Concepts and Functional Overview 1068 The iSCSI protocol is a mapping of the SCSI command, event and task 1069 management model (see [SAM2]) over the TCP protocol. SCSI commands 1070 are carried by iSCSI requests and SCSI responses and status are 1071 carried by iSCSI responses. iSCSI also uses the request response 1072 mechanism for iSCSI protocol mechanisms. 1074 For the remainder of this document, the terms "initiator" and 1075 "target" refer to "iSCSI initiator node" and "iSCSI target node", 1076 respectively (see iSCS) unless otherwise qualified. 1078 In keeping with similar protocols, the initiator and target divide 1079 their communications into messages. This document uses the term 1080 "iSCSI protocol data unit" (iSCSI PDU) for these messages. 1082 For performance reasons, iSCSI allows a "phase-collapse". A command 1083 and its associated data may be shipped together from initiator to 1084 target, and data and responses may be shipped together from 1085 targets. 1087 The iSCSI transfer direction is defined with respect to the 1088 initiator. Outbound or outgoing transfers are transfers from an 1089 initiator to a target, while inbound or incoming transfers are from 1090 a target to an initiator. 1092 An iSCSI task is an iSCSI request for which a response is expected. 1094 In this document "iSCSI request", "iSCSI command", request, or 1095 (unqualified) command have the same meaning. Also, unless otherwise 1096 specified, status, response, or numbered response have the same 1097 meaning. 1099 4.2.1. Layers and Sessions 1101 The following conceptual layering model is used to specify 1102 initiator and target actions and the way in which they relate to 1103 transmitted and received Protocol Data Units: 1105 the SCSI layer builds/receives SCSI CDBs (Command Descriptor 1106 Blocks) and passes/receives them with the remaining command 1107 execute parameters ([SAM2]) to/from 1108 the iSCSI layer that builds/receives iSCSI PDUs and 1109 relays/receives them to/from one or more TCP connections; 1110 the group of connections form an initiator-target "session". 1112 Communication between the initiator and target occurs over one or 1113 more TCP connections. The TCP connections carry control messages, 1114 SCSI commands, parameters, and data within iSCSI Protocol Data 1115 Units (iSCSI PDUs). The group of TCP connections that link an 1116 initiator with a target form a session (equivalent to a SCSI I_T 1117 nexus, see SCSI ). A session is defined by a session ID that is 1118 composed of an initiator part and a target part. TCP connections 1119 can be added and removed from a session. Each connection within a 1120 session is identified by a connection ID (CID). 1122 Across all connections within a session, an initiator sees one 1123 "target image". All target identifying elements, such as LUN, are 1124 the same. A target also sees one "initiator image" across all 1125 connections within a session. Initiator-identifying elements, such 1126 as the Initiator Task Tag, are global across the session regardless 1127 of the connection on which they are sent or received. 1129 iSCSI targets and initiators MUST support at least one TCP 1130 connection and MAY support several connections in a session. For 1131 error recovery purposes, targets and initiators that support a 1132 single active connection in a session SHOULD support two 1133 connections during recovery. 1135 4.2.2. Ordering and iSCSI Numbering 1137 iSCSI uses Command and Status numbering schemes and a Data 1138 sequencing scheme. 1140 Command numbering is session-wide and is used for ordered command 1141 delivery over multiple connections. It can also be used as a 1142 mechanism for command flow control over a session. 1144 Status numbering is per connection and is used to enable missing 1145 status detection and recovery in the presence of transient or 1146 permanent communication errors. 1148 Data sequencing is per command or part of a command (R2T-triggered 1149 sequence) and is used to detect missing data and/or R2T PDUs due to 1150 header digest errors. 1152 Typically, fields in the iSCSI PDUs communicate the Sequence 1153 Numbers between the initiator and target. During periods when 1154 traffic on a connection is unidirectional, iSCSI NOP-Out/In PDUs 1155 may be utilized to synchronize the command and status ordering 1156 counters of the target and initiator. 1158 The iSCSI session abstraction is equivalent to the SCSI I_T nexus, 1159 and the iSCSI session provides an ordered command delivery from the 1160 SCSI initiator to the SCSI target. For detailed design 1161 considerations that led to the iSCSI session model as it is defined 1162 here and how it relates the SCSI command ordering features defined 1163 in SCSI specifications to the iSCSI concepts see [RFC3783]. 1165 4.2.2.1. Command Numbering and Acknowledging 1167 iSCSI performs ordered command delivery within a session. All 1168 commands (initiator-to-target PDUs) in transit from the initiator 1169 to the target are numbered. 1171 iSCSI considers a task to be instantiated on the target in response 1172 to every request issued by the initiator. A set of task management 1173 operations including abort and reassign (see Section 10.5 "Task 1174 Management Function Request") may be performed on any iSCSI task. 1176 Some iSCSI tasks are SCSI tasks, and many SCSI activities are 1177 related to a SCSI task ([SAM2]). In all cases, the task is 1178 identified by the Initiator Task Tag for the life of the task. 1180 The command number is carried by the iSCSI PDU as CmdSN (Command- 1181 Sequence-Number). The numbering is session-wide. Outgoing iSCSI 1182 PDUs carry this number. The iSCSI initiator allocates CmdSNs with a 1183 32-bit unsigned counter (modulo 2**32). Comparisons and arithmetic 1184 on CmdSN use Serial Number Arithmetic as defined in [RFC1982] where 1185 SERIAL_BITS = 32. 1187 Commands meant for immediate delivery are marked with an immediate 1188 delivery flag; they MUST also carry the current CmdSN. CmdSN does 1189 not advance after a command marked for immediate delivery is sent. 1191 Command numbering starts with the first login request on the first 1192 connection of a session (the leading login on the leading 1193 connection) and command numbers are incremented by 1 for every non- 1194 immediate command issued afterwards. 1196 If immediate delivery is used with task management commands, these 1197 commands may reach the target before the tasks on which they are 1198 supposed to act. However their CmdSN serves as a marker of their 1199 position in the stream of commands. The initiator and target must 1200 ensure that the task management commands act as specified by 1201 [SAM2]. For example, both commands and responses appear as if 1202 delivered in order. Whenever CmdSN for an outgoing PDU is not 1203 specified by an explicit rule, CmdSN will carry the current value 1204 of the local CmdSN variable (see later in this section). 1206 The means by which an implementation decides to mark a PDU for 1207 immediate delivery or by which iSCSI decides by itself to mark a 1208 PDU for immediate delivery are beyond the scope of this document. 1210 The number of commands used for immediate delivery is not limited 1211 and their delivery to execution is not acknowledged through the 1212 numbering scheme. Immediate commands MAY be rejected by the iSCSI 1213 target layer due to lack of resources. An iSCSI target MUST be able 1214 to handle at least one immediate task management command and one 1215 immediate non-task-management iSCSI command per connection at any 1216 time. 1218 In this document, delivery for execution means delivery to the SCSI 1219 execution engine or an iSCSI protocol specific execution engine 1220 (e.g., for text requests with public or private extension keys 1221 involving an execution component). With the exception of the 1222 commands marked for immediate delivery, the iSCSI target layer MUST 1223 deliver the commands for execution in the order specified by CmdSN. 1224 Commands marked for immediate delivery may be delivered by the 1225 iSCSI target layer for execution as soon as detected. iSCSI may 1226 avoid delivering some commands to the SCSI target layer if required 1227 by a prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task 1228 Management request received before all the commands on which it was 1229 supposed to act). 1231 On any connection, the iSCSI initiator MUST send the commands in 1232 increasing order of CmdSN, except for commands that are 1233 retransmitted due to digest error recovery and connection recovery. 1235 For the numbering mechanism, the initiator and target maintain the 1236 following three variables for each session: 1238 - CmdSN - the current command Sequence Number, advanced by 1 1239 on each command shipped except for commands marked for 1240 immediate delivery. CmdSN always contains the number to be 1241 assigned to the next Command PDU. 1243 - ExpCmdSN - the next expected command by the target. The 1244 target acknowledges all commands up to, but not including, 1245 this number. The initiator treats all commands with CmdSN 1246 less than ExpCmdSN as acknowledged. The target iSCSI layer 1247 sets the ExpCmdSN to the largest non-immediate CmdSN that it 1248 can deliver for execution "plus 1" per [RFC1982]. There MUST 1249 NOT be any holes in the acknowledged CmdSN sequence. 1251 - MaxCmdSN - the maximum number to be shipped. The queuing 1252 capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN 1253 + 1. 1255 The initiator's ExpCmdSN and MaxCmdSN are derived from target-to- 1256 initiator PDU fields. Comparisons and arithmetic on ExpCmdSN and 1257 MaxCmdSN MUST use Serial Number Arithmetic as defined in [RFC1982] 1258 where SERIAL_BITS = 32. 1260 The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN- 1261 1. For non-immediate commands, the CmdSN field can take any value 1262 from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently 1263 ignore any non-immediate command outside of this range or non- 1264 immediate duplicates within the range. The CmdSN carried by 1265 immediate commands may lie outside the ExpCmdSN to MaxCmdSN range. 1266 For example, if the initiator has previously sent a non-immediate 1267 command carrying the CmdSN equal to MaxCmdSN, the target window is 1268 closed. For group task management commands issued as immediate 1269 commands, CmdSN indicates the scope of the group action (e.g., on 1270 ABORT TASK SET indicates which commands are to be aborted). 1272 MaxCmdSN and ExpCmdSN fields are processed by the initiator as 1273 follows: 1275 -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial 1276 Arithmetic Sense), they are both ignored. 1278 -If the PDU MaxCmdSN is greater than the local MaxCmdSN (in 1279 Serial Arithmetic Sense), it updates the local MaxCmdSN; 1280 otherwise, it is ignored. 1282 -If the PDU ExpCmdSN is greater than the local ExpCmdSN (in 1283 Serial Arithmetic Sense), it updates the local ExpCmdSN; 1284 otherwise, it is ignored. 1286 This sequence is required because updates may arrive out of order 1287 (e.g., the updates are sent on different TCP connections). 1289 iSCSI initiators and targets MUST support the command numbering 1290 scheme. 1292 A numbered iSCSI request will not change its allocated CmdSN, 1293 regardless of the number of times and circumstances in which it is 1294 reissued (see Section 6.2.1 "Usage of Retry"). At the target, CmdSN 1295 is only relevant while the command has not created any state 1296 related to its execution (execution state); afterwards, CmdSN 1297 becomes irrelevant. Testing for the execution state (represented by 1298 identifying the Initiator Task Tag) MUST precede any other action 1299 at the target. If no execution state is found, it is followed by 1300 ordering and delivery. If an execution state is found, it is 1301 followed by delivery if it has not already been delivered. 1303 If an initiator issues a command retry for a command with CmdSN R 1304 on 1305 a connection when the session CmdSN value is Q, it MUST NOT advance 1306 the CmdSN past R + 2**31 -1 unless the connection is no longer 1307 operational (i.e., it has returned to the FREE state, see Section 1308 7.1.3 "Standard Connection State Diagram for an Initiator"), the 1309 connection has been reinstated (see Section 5.3.4 "Connection 1310 Reinstatement"), or a non-immediate command with CmdSN equal or 1311 greater than Q was issued subsequent to the command retry on the 1312 same connection and the reception of that command is acknowledged 1313 by the target (see Section 9.4 "Command Retry and Cleaning Old 1314 Command Instances"). 1316 A target command response or Data-in PDU with status MUST NOT 1317 precede the command acknowledgement. However, the acknowledgement 1318 MAY be included in the response or the Data-in PDU. 1320 4.2.2.2. Response/Status Numbering and Acknowledging 1322 Responses in transit from the target to the initiator are numbered. 1323 The StatSN (Status Sequence Number) is used for this purpose. 1324 StatSN is a counter maintained per connection. ExpStatSN is used by 1325 the initiator to acknowledge status. The status sequence number 1326 space is 32-bit unsigned-integers and the arithmetic operations are 1327 the regular mod(2**32) arithmetic. 1329 Status numbering starts with the Login response to the first Login 1330 request of the connection. The Login response includes an initial 1331 value for status numbering (any initial value is valid). 1333 To enable command recovery, the target MAY maintain enough state 1334 information for data and status recovery after a connection 1335 failure. A target doing so can safely discard all of the state 1336 information maintained for recovery of a command after the delivery 1337 of the status for the command (numbered StatSN) is acknowledged 1338 through ExpStatSN. 1340 A large absolute difference between StatSN and ExpStatSN may 1341 indicate a failed connection. Initiators MUST undertake recovery 1342 actions if the difference is greater than an implementation defined 1343 constant that MUST NOT exceed 2**31-1. 1345 Initiators and Targets MUST support the response-numbering scheme. 1347 4.2.2.3. Response Ordering 1349 4.2.2.3.1. Need for Response Ordering 1350 Whenever an iSCSI session is composed of multiple connections, the 1351 Response PDUs (task responses or TMF responses) originating in the 1352 target SCSI layer are distributed onto the multiple connections by 1353 the target iSCSI layer according to iSCSI connection allegiance 1354 rules. This process generally may not preserve the ordering of the 1355 responses by the time they are delivered to the initiator SCSI 1356 layer. 1358 Since ordering is not expected across SCSI responses anyway, this 1359 approach works fine in the general case. However, to address the 1360 special cases where some ordering is desired by the SCSI layer, the 1361 following "Response Fence" semantics are defined with respect to 1362 handling SCSI response messages as they are handed off from the 1363 SCSI protocol layer to the iSCSI layer. 1365 4.2.2.3.2. Response Ordering Model Description 1367 The target SCSI protocol layer hands off the SCSI response messages 1368 to the target iSCSI layer by invoking the "Send Command Complete" 1369 protocol data service ([SAM2], clause 5.4.2) and "Task Management 1370 Function Executed" ([SAM2], clause 6.9) service. On receiving the 1371 SCSI response message, the iSCSI layer exhibits the Response Fence 1372 behavior for certain SCSI response messages (Section 4.2.2.3.4 1373 describes the specific instances where the semantics must be 1374 realized). 1376 Whenever the Response Fence behavior is required for a SCSI 1377 response message, the target iSCSI layer MUST ensure that the 1378 following conditions are met in delivering the response message to 1379 the initiator iSCSI layer: 1381 Response with Response Fence MUST be delivered chronologically 1382 after all the "preceding" responses on the I_T_L nexus, if 1383 the preceding responses are delivered at all, to the 1384 initiator iSCSI layer. 1385 Response with Response Fence MUST be delivered chronologically 1386 prior to all the "following" responses on the I_T_L nexus. 1388 The "preceding" and "following" notions refer to the order of 1389 handoff of a response message from the target SCSI protocol layer 1390 to the target iSCSI layer. 1392 4.2.2.3.3. iSCSI Semantics with the Interface Model 1394 Whenever the TaskReporting key (Section 12.23 "Task Reporting") is 1395 negotiated to ResponseFence or FastAbort for an iSCSI session and 1396 the Response Fence behavior is required for a SCSI response 1397 message, the target iSCSI layer MUST perform the actions described 1398 in this section for that session. 1400 If it is a single-connection session, no special processing is 1401 required. The standard SCSI Response PDU build and dispatch 1402 process happens. 1403 If it is a multi-connection session, the target iSCSI layer 1404 takes note of the last-sent and unacknowledged StatSN on 1405 each of the connections in the iSCSI session, and waits for 1406 an acknowledgement (NOP-In PDUs MAY be used to solicit 1407 acknowledgements as needed in order to accelerate this 1408 process) of each such StatSN to clear the fence. The SCSI 1409 response requiring Response Fence behavior MUST NOT be sent 1410 to the initiator before acknowledgements are received for 1411 each of the unacknowledged StatSNs. 1412 The target iSCSI layer must wait for an acknowledgement of the 1413 SCSI Response PDU that carried the SCSI response requiring 1414 the Response Fence behavior. The fence MUST be considered 1415 cleared only after receiving the acknowledgement. 1416 All further status processing for the LU is resumed only after 1417 clearing the fence. If any new responses for the I_T_L nexus 1418 are received from the SCSI layer before the fence is 1419 cleared, those Response PDUs MUST be held and queued at the 1420 iSCSI layer until the fence is cleared. 1422 4.2.2.3.4. Current List of Fenced Response Use Cases 1424 This section lists the fenced response use cases that iSCSI 1425 implementations MUST comply with. However, this is not an 1426 exhaustive enumeration. It is expected that as SCSI protocol 1427 specifications evolve, the specifications will specify when 1428 response fencing is required on a case-by-case basis. 1430 Whenever the TaskReporting key (Section 13.23) is negotiated to 1431 ResponseFence or FastAbort for an iSCSI session, the target iSCSI 1432 layer MUST assume that the Response Fence is required for the 1433 following SCSI completion messages: 1435 1. The first completion message carrying the UA after the 1436 multi-task abort on issuing and third-party sessions. See 1437 Section 4.2.3.2 for related TMF discussion. 1439 2. The TMF Response carrying the multi-task TMF Response on the 1440 issuing session. 1442 3. The completion message indicating ACA establishment on the 1443 issuing session. 1445 4. The first completion message carrying the ACA ACTIVE status 1446 after ACA establishment on issuing and third-party sessions. 1448 5. The TMF Response carrying the Clear ACA response on the 1449 issuing session. 1451 6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT 1452 command. 1454 Note: 1455 - Due to the absence of ACA-related fencing requirements in 1456 [RFC3720], initiator implementations SHOULD NOT use ACA on 1457 multi-connection iSCSI sessions with targets complying only 1458 with [RFC3720]. 1460 - Initiators that want to employ ACA on multi-connection iSCSI 1461 sessions SHOULD first assess response-fencing behavior via 1462 negotiating for ResponseFence or FastAbort values for the 1463 TaskReporting (Section 13.23) key. 1465 4.2.2.4. Data Sequencing 1467 Data and R2T PDUs transferred as part of some command execution 1468 MUST be sequenced. The DataSN field is used for data sequencing. 1469 For input (read) data PDUs, DataSN starts with 0 for the first data 1470 PDU of an input command and advances by 1 for each subsequent data 1471 PDU. For output data PDUs, DataSN starts with 0 for the first data 1472 PDU of a sequence (the initial unsolicited sequence or any data PDU 1473 sequence issued to satisfy an R2T) and advances by 1 for each 1474 subsequent data PDU. R2Ts are also sequenced per command. For 1475 example, the first R2T has an R2TSN of 0 and advances by 1 for each 1476 subsequent R2T. For bidirectional commands, the target uses the 1477 DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous 1478 sequence (undifferentiated). Unlike command and status, data PDUs 1479 and R2Ts are not acknowledged by a field in regular outgoing PDUs. 1480 Data-In PDUs can be acknowledged on demand by a special form of the 1481 SNACK PDU. Data and R2T PDUs are implicitly acknowledged by status 1482 for the command. The DataSN/R2TSN field enables the initiator to 1483 detect missing data or R2T PDUs. 1485 For any read or bidirectional command, a target MUST issue less 1486 than 2**32 combined R2T and Data-In PDUs. Any output data sequence 1487 MUST contain less than 2**32 Data-Out PDUs. 1489 4.2.3. iSCSI Task Management 1491 4.2.3.1. Task Management Overview 1493 iSCSI task management features allow an initiator to control the 1494 active iSCSI tasks on an operational iSCSI session that it has with 1495 an iSCSI target. Section 11.5 defines the task management function 1496 types that this specification defines - ABORT TASK, ABORT TASK SET, 1497 CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, 1498 TARGET COLD RESET, and TASK REASSIGN. 1500 Out of these function types, ABORT TASK and TASK REASSIGN functions 1501 manage a single active task, whereas ABORT TASK SET, CLEAR TASK 1502 SET, LOGICAL UNIT RESET, TARGET WARM RESET and TARGET COLD RESET 1503 functions can each potentially affect multiple active tasks. 1505 4.2.3.2. Notion of Affected Tasks 1507 This section defines the notion of "affected tasks" in multi-task 1508 abort scenarios. Scope definitions in this section apply to both 1509 the Standard Multi-task Abort semantics (Section 4.2.3.3) and the 1510 FastAbort Multi-task Abort semantics behavior (Section 4.2.3.4). 1512 ABORT TASK SET: All outstanding tasks for the I_T_L nexus 1513 identified by the LUN field in the ABORT TASK SET TMF Request PDU 1514 (Section 11.5). 1516 CLEAR TASK SET: All outstanding tasks in the task set for the LU 1517 identified by the LUN field in the CLEAR TASK SET TMF Request PDU. 1518 See [SPC3] for the definition of a "task set". 1520 LOGICAL UNIT RESET: All outstanding tasks from all initiators for 1521 the LU identified by the LUN field in the LOGICAL UNIT RESET 1522 Request PDU. 1524 TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from all 1525 initiators across all LUs to which the TMF-issuing session has 1526 access on the SCSI target device hosting the iSCSI session. 1528 Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is 1529 an iSCSI TMF Request PDU with the "Function" field set to "ABORT 1530 TASK SET" as defined in Section 11.5. Similar usage is employed 1531 for other scope descriptions. 1533 4.2.3.3. Standard Multi-task Abort Semantics 1535 All iSCSI implementations MUST support the protocol behavior 1536 defined in this section as the default behavior. The execution of 1537 ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM 1538 RESET, and TARGET COLD RESET TMF Requests consists of the following 1539 sequence of actions in the specified order on the specified party. 1541 The initiator iSCSI layer: 1542 a. MUST continue to respond to each TTT received for the 1543 affected tasks. 1544 b. SHOULD process any responses received for affected tasks in 1545 the normal fashion. This is acceptable because the responses 1546 are guaranteed to have been sent prior to the TMF response. 1547 c. SHOULD receive the TMF Response concluding all the tasks in 1548 the set of affected tasks unless the initiator has done 1549 something (e.g., LU reset, connection drop) that may prevent 1550 the TMF Response from being sent or received. The initiator 1551 MUST thus conclude all affected tasks as part of this step 1552 in either case, and MUST discard any TMF Response received 1553 after the affected tasks are concluded. 1555 The target iSCSI layer: 1557 a. MUST wait for responses on currently valid target-transfer 1558 tags of the affected tasks from the issuing initiator. MAY 1559 wait for responses on currently valid target-transfer tags 1560 of the affected tasks from third-party initiators. 1561 b. MUST wait (concurrent with the wait in Step a) for all 1562 commands of the affected tasks to be received based on the 1563 CmdSN ordering. SHOULD NOT wait for new commands on third- 1564 party affected sessions -- only the instantiated tasks have 1565 to be considered for the purpose of determining the affected 1566 tasks. In the case of target-scoped requests (i.e., TARGET 1567 WARM RESET and TARGET COLD RESET), all of the commands that 1568 are not yet received on the issuing session in the command 1569 stream however can be considered to have been received with 1570 no command waiting period -- i.e., the entire CmdSN space up 1571 to the CmdSN of the task management function can be 1572 "plugged". 1573 c. MUST propagate the TMF request to and receive the response 1574 from the target SCSI layer. 1575 d. MUST provide the Response Fence behavior for the TMF 1576 Response on the issuing session as specified in Section 1577 4.2.2.3.2. 1578 e. MUST provide the Response Fence behavior on the first post- 1579 TMF Response on third-party sessions as specified in Section 1580 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L 1581 nexuses, then the means by which the target ensures that all 1582 affected tasks have returned their status to the initiator 1583 are defined by the specific non-iSCSI transport protocol(s). 1585 Technically, the TMF servicing is complete in Step d. Data 1586 transfers corresponding to terminated tasks may however still be in 1587 progress on third-party iSCSI sessions even at the end of Step e. 1588 The TMF Response MUST NOT be sent by the target iSCSI layer before 1589 the end of Step d, and MAY be sent at the end of Step d despite 1590 these outstanding data transfers until after Step e. 1592 4.2.3.4. FastAbort Multi-task Abort Semantics 1594 Protocol behavior defined in this section MUST be implemented by 1595 all iSCSI implementations complying with this document. Protocol 1596 behavior defined in this section MUST be exhibited by iSCSI 1597 implementations on an iSCSI session when they negotiate the 1598 TaskReporting (Section 13.23) key to "FastAbort" on that session. 1599 The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT 1600 RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests 1601 consists of the following sequence of actions in the specified 1602 order on the specified party. 1604 The initiator iSCSI layer: 1605 a. MUST NOT send any more Data-Out PDUs for affected tasks on 1606 the issuing connection of the issuing iSCSI session once the 1607 TMF is sent to the target. 1608 b. SHOULD process any responses received for affected tasks in 1609 the normal fashion. This is acceptable because the responses 1610 are guaranteed to have been sent prior to the TMF response. 1611 c. MUST respond to each Async Message PDU with FAST_ABORT 1612 AsyncEvent as defined in Section 11.9. 1613 d. MUST treat the TMF response as terminating all affected 1614 tasks for which responses have not been received, and MUST 1615 discard any responses for affected tasks received after the 1616 TMF response is passed to the SCSI layer (although the 1617 semantics defined in this section ensure that such an out- 1618 of-order scenario will never happen with a compliant target 1619 implementation). 1621 The target iSCSI layer: 1622 a. MUST wait for all commands of the affected tasks to be 1623 received based on the CmdSN ordering on the issuing session. 1624 SHOULD NOT wait for new commands on third-party affected 1625 sessions - only the instantiated tasks have to be considered 1626 for the purpose of determining the affected tasks. In the 1627 case of target-scoped requests (i.e., TARGET WARM RESET and 1628 TARGET COLD RESET), all the commands that are not yet 1629 received on the issuing session in the command stream can be 1630 considered to have been received with no command waiting 1631 period -- i.e., the entire CmdSN space up to the CmdSN of 1632 the task management function can be "plugged". 1633 b. MUST propagate the TMF request to and receive the response 1634 from the target SCSI layer. 1635 c. MUST leave all active "affected TTTs" (i.e., active TTTs 1636 associated with affected tasks) valid. 1638 d. MUST send an Asynchronous Message PDU with AsyncEvent=5 1639 (Section 11.9) on: 1640 i) each connection of each third-party session to which 1641 at least one affected task is allegiant if 1642 TaskReporting=FastAbort is operational on that third- 1643 party session, and, 1644 ii) each connection except the issuing connection of the 1645 issuing session that has at least one allegiant affected 1646 task. 1647 If there are multiple affected LUs (say, due to a target 1648 reset), then one Async Message PDU MUST be sent for each such 1649 LU on each connection that has at least one allegiant 1650 affected task. The LUN field in the Asynchronous Message PDU 1651 MUST be set to match the LUN for each such LU. 1652 e. MUST address the Response Fence flag on the TMF Response on 1653 the issuing session as defined in Section 4.2.2.3.3. 1654 f. MUST address the Response Fence flag on the first post-TMF 1655 Response on third-party sessions as defined in Section 1656 4.2.2.3.3. If some tasks originate from non-iSCSI I_T_L 1657 nexuses, then the means by which the target ensures that all 1658 affected tasks have returned their status to the initiator 1659 are defined by the specific non-iSCSI transport protocol(s). 1660 g. MUST free up the affected TTTs (and STags, if applicable) 1661 and the corresponding buffers, if any, once it receives each 1662 associated NOP-Out acknowledgement that the initiator 1663 generated in response to each Async Message. 1665 Technically, the TMF servicing is complete in Step e. Data 1666 transfers corresponding to terminated tasks may however still be in 1667 progress even at the end of Step f. A TMF Response MUST NOT be 1668 sent by the target iSCSI layer before the end of Step e, and MAY be 1669 sent at the end of Step e despite these outstanding Data transfers 1670 until Step g. Step g specifies an event to free up any such 1671 resources that may have been reserved to support outstanding data 1672 transfers. 1674 4.2.3.5. Affected Tasks Shared across Standard and FastAbort Sessions 1676 If an iSCSI target implementation is capable of supporting 1677 TaskReporting=FastAbort functionality (Section 13.23), it may end 1678 up in a situation where some sessions have TaskReporting=RFC3720 1679 operational (RFC 3720 sessions) while some other sessions have 1680 TaskReporting=FastAbort operational (FastAbort sessions) even while 1681 accessing a shared set of affected tasks (Section 4.2.3.2). If the 1682 issuing session is an RFC 3720 session, the iSCSI target 1683 implementation is FastAbort-capable, and the third-party affected 1684 session is a FastAbort session, the following behavior SHOULD be 1685 exhibited by the iSCSI target layer: 1686 a. Between Steps c and d of the target behavior in Section 1687 4.2.3.3, send an Asynchronous Message PDU with AsyncEvent=5 1688 (Section 11.9) on each connection of each third-party 1689 session to which at least one affected task is allegiant. If 1690 there are multiple affected LUs, then send one Async Message 1691 PDU for each such LU on each connection that has at least 1692 one allegiant affected task. When sent, the LUN field in the 1693 Asynchronous Message PDU MUST be set to match the LUN for 1694 each such LU. 1695 b. After Step e of the target behavior in Section 4.2.3.3, free 1696 up the affected TTTs (and STags, if applicable) and the 1697 corresponding buffers, if any, once each associated NOP-Out 1698 acknowledgement is received that the third-party initiator 1699 generated in response to each Async Message sent in Step a. 1701 If the issuing session is a FastAbort session, the iSCSI target 1702 implementation is FastAbort-capable, and the third-party affected 1703 session is an RFC 3720 session, the following behavior MUST be 1704 exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST 1705 NOT be sent on the third-party session to prompt the FastAbort 1706 behavior. 1708 If the third-party affected session is a FastAbort session and the 1709 issuing session is a FastAbort session, the initiator in the third- 1710 party role MUST respond to each Async Message PDU with AsyncEvent=5 1711 as defined in Section 11.9. Note that an initiator MAY thus receive 1712 these Async Messages on a third-party affected session even if the 1713 session is a single-connection session. 1715 4.2.3.6. Rationale behind the FastAbort Semantics 1717 There are fundamentally three basic objectives behind the semantics 1718 specified in Sections 4.2.3.3 and 4.2.3.4. 1720 1. Maintaining an ordered command flow I_T nexus abstraction to 1721 the target SCSI layer even with multi-connection sessions. 1722 - Target iSCSI processing of a TMF request must maintain 1723 the single flow illusion. Target behavior in Step b of 1724 Section 4.2.3.3 and Step a of Section 4.2.3.4 correspond 1725 to this objective. 1726 2. Maintaining a single ordered response flow I_T nexus 1727 abstraction to the initiator SCSI layer even with multi- 1728 connection sessions when one response (i.e., TMF response) 1729 could imply the status of other unfinished tasks from the 1730 initiator's perspective. 1731 - The target must ensure that the initiator does not see 1732 "old" task responses (that were placed on the wire 1733 chronologically earlier than the TMF Response) after 1734 seeing the TMF response. The target behavior in Step d 1735 of Section 4.2.3.3 and Step e of Section 4.2.3.4 1736 correspond to this objective. 1737 - Whenever the result of a TMF action is visible across 1738 multiple I_T_L nexuses, [SAM2] requires the SCSI device 1739 server to trigger a UA on each of the other I_T_L 1740 nexuses. Once an initiator is notified of such an UA, 1741 the application client on the receiving initiator is 1742 required to clear its task state (clause 5.5 in [SAM2]) 1743 for the affected tasks. It would thus be inappropriate 1744 to deliver a SCSI Response for a task after the task 1745 state is cleared on the initiator, i.e., after the UA is 1746 notified. The UA notification contained in the first 1747 SCSI Response PDU on each affected Third-party I_T_L 1748 nexus after the TMF action thus MUST NOT pass the 1749 affected task responses on any of the iSCSI sessions 1750 accessing the LU. The target behavior in Step e of 1751 Section 4.2.3.3 and Step f of Section 4.2.3.4 correspond 1752 to this objective. 1753 3. Draining all active TTTs corresponding to affected tasks in 1754 a deterministic fashion. 1755 - Data-Out PDUs with stale TTTs arriving after the tasks 1756 are terminated can create a buffer management problem 1757 even for traditional iSCSI implementations, and is fatal 1758 for the connection for iSCSI/iSER implementations. 1759 Either the termination of affected tasks should be 1760 postponed until the TTTs are retired (as in Step a of 1761 Section 4.2.3.3), or the TTTs and the buffers should 1762 stay allocated beyond task termination to be 1763 deterministically freed up later (as in Steps c and g of 1764 Section 4.2.3.4). 1766 The only other notable optimization is the plugging. If all tasks 1767 on an I_T nexus will be aborted anyway (as with a target reset), 1768 there is no need to wait to receive all commands to plug the CmdSN 1769 holes. The target iSCSI layer can simply plug all missing CmdSN 1770 slots and move on with TMF processing. The first objective 1771 (maintaining a single ordered command flow) is still met with this 1772 optimization because the target SCSI layer only sees ordered 1773 commands. 1775 4.2.4. iSCSI Login 1777 The purpose of the iSCSI login is to enable a TCP connection for 1778 iSCSI use, authentication of the parties, negotiation of the 1779 session's parameters and marking of the connection as belonging to 1780 an iSCSI session. 1782 A session is used to identify to a target all the connections with 1783 a given initiator that belong to the same I_T nexus. (For more 1784 details on how a session relates to an I_T nexus, see section 1785 4.4.2). 1787 The targets listen on a well-known TCP port or other TCP port for 1788 incoming connections. The initiator begins the login process by 1789 connecting to one of these TCP ports. 1791 As part of the login process, the initiator and target SHOULD 1792 authenticate each other and MAY set a security association protocol 1793 for the session. This can occur in many different ways and is 1794 subject to negotiation. 1796 To protect the TCP connection, an IPsec security association MAY be 1797 established before the Login request. For information on using 1798 IPsec security for iSCSI see Chapter 8 and [RFC3723]. 1800 The iSCSI Login Phase is carried through Login requests and 1801 responses. Once suitable authentication has occurred and 1802 operational parameters have been set, the session transitions to 1803 Full Feature Phase and the initiator may start to send SCSI 1804 commands. The security policy for whether, and by what means, a 1805 target chooses to authorize an initiator is beyond the scope of 1806 this document. For a more detailed description of the Login Phase, 1807 see Chapter 5. 1809 The login PDU includes the ISID part of the session ID (SSID). The 1810 target portal group that services the login is implied by the 1811 selection of the connection endpoint. For a new session, the TSIH 1812 is zero. As part of the response, the target generates a TSIH. 1814 During session establishment, the target identifies the SCSI 1815 initiator port (the "I" in the "I_T nexus") through the value pair 1816 (InitiatorName, ISID). We describe InitiatorName later in this 1817 section. Any persistent state (e.g., persistent reservations) on 1818 the target that is associated with a SCSI initiator port is 1819 identified based on this value pair. Any state associated with the 1820 SCSI target port (the "T" in the "I_T nexus") is identified 1821 externally by the TargetName and portal group tag (see Section 1822 4.4.1). ISID is subject to reuse restrictions because it is used to 1823 identify a persistent state (see Section 4.4.3). 1825 Before the Full Feature Phase is established, only Login Request 1826 and Login Response PDUs are allowed. Login requests and responses 1827 MUST be used exclusively during Login. On any connection, the login 1828 phase MUST immediately follow TCP connection establishment and a 1829 subsequent Login Phase MUST NOT occur before tearing down a 1830 connection. 1832 A target receiving any PDU except a Login request before the Login 1833 phase is started MUST immediately terminate the connection on which 1834 the PDU was received. Once the Login phase has started, if the 1835 target receives any PDU except a Login request, it MUST send a 1836 Login reject (with Status "invalid during login") and then 1837 disconnect. If the initiator receives any PDU except a Login 1838 response, it MUST immediately terminate the connection. 1840 4.2.5. iSCSI Full Feature Phase 1842 Once the initiator is authorized to do so, the iSCSI session is in 1843 the iSCSI Full Feature Phase. A session is in Full Feature Phase 1844 after successfully finishing the Login Phase on the first (leading) 1845 connection of a session. A connection is in Full Feature Phase if 1846 the session is in Full Feature Phase and the connection login has 1847 completed successfully. An iSCSI connection is not in Full Feature 1848 Phase 1850 when it does not have an established transport connection, 1851 OR 1852 when it has a valid transport connection, but a successful 1853 login was not performed or the connection is currently 1854 logged out. 1856 In a normal Full Feature Phase, the initiator may send SCSI 1857 commands and data to the various LUs on the target by encapsulating 1858 them in iSCSI PDUs that go over the established iSCSI session. 1860 4.2.5.1. Command Connection Allegiance 1862 For any iSCSI request issued over a TCP connection, the 1863 corresponding response and/or other related PDU(s) MUST be sent 1864 over the same connection. We call this "connection allegiance". If 1865 the original connection fails before the command is completed, the 1866 connection allegiance of the command may be explicitly reassigned 1867 to a different transport connection as described in detail in 1868 Section 6.2 "Retry and Reassign in Recovery". 1870 Thus, if an initiator issues a READ command, the target MUST send 1871 the requested data, if any, followed by the status to the initiator 1872 over the same TCP connection that was used to deliver the SCSI 1873 command. If an initiator issues a WRITE command, the initiator MUST 1874 send the data, if any, for that command over the same TCP 1875 connection that was used to deliver the SCSI command. The target 1876 MUST return Ready To Transfer (R2T), if any, and the status over 1877 the same TCP connection that was used to deliver the SCSI command. 1878 Retransmission requests (SNACK PDUs) and the data and status that 1879 they generate MUST also use the same connection. 1881 However, consecutive commands that are part of a SCSI linked 1882 command-chain task (see [SAM2]) MAY use different connections. 1883 Connection allegiance is strictly per-command and not per-task. 1884 During the iSCSI Full Feature Phase, the initiator and target MAY 1885 interleave unrelated SCSI commands, their SCSI Data, and responses 1886 over the session. 1888 4.2.5.2. Data Transfer Overview 1890 Outgoing SCSI data (initiator to target user data or command 1891 parameters) is sent as either solicited data or unsolicited data. 1892 Solicited data are sent in response to R2T PDUs. Unsolicited data 1893 can be sent as part of an iSCSI command PDU ("immediate data") or 1894 in separate iSCSI data PDUs. 1896 Immediate data are assumed to originate at offset 0 in the 1897 initiator SCSI write-buffer (outgoing data buffer). All other Data 1898 PDUs have the buffer offset set explicitly in the PDU header. 1900 An initiator may send unsolicited data up to FirstBurstLength as 1901 immediate (up to the negotiated maximum PDU length), in a separate 1902 PDU sequence or both. All subsequent data MUST be solicited. The 1903 maximum length of an individual data PDU or the immediate-part of 1904 the first unsolicited burst MAY be negotiated at login. 1906 The maximum amount of unsolicited data that can be sent with a 1907 command is negotiated at login through the FirstBurstLength key. A 1908 target MAY separately enable immediate data (through the 1909 ImmediateData key) without enabling the more general (separate data 1910 PDUs) form of unsolicited data (through the InitialR2T key). 1912 Unsolicited data on write are meant to reduce the effect of latency 1913 on throughput (no R2T is needed to start sending data). In 1914 addition, immediate data is meant to reduce the protocol overhead 1915 (both bandwidth and execution time). 1917 An iSCSI initiator MAY choose not to send unsolicited data, only 1918 immediate data or FirstBurstLength bytes of unsolicited data with a 1919 command. If any non-immediate unsolicited data is sent, the total 1920 unsolicited data MUST be either FirstBurstLength, or all of the 1921 data if the total amount is less than the FirstBurstLength. 1923 It is considered an error for an initiator to send unsolicited data 1924 PDUs to a target that operates in R2T mode (only solicited data are 1925 allowed). It is also an error for an initiator to send more 1926 unsolicited data, whether immediate or as separate PDUs, than 1927 FirstBurstLength. 1929 An initiator MUST honor an R2T data request for a valid outstanding 1930 command (i.e., carrying a valid Initiator Task Tag) and deliver all 1931 the requested data provided the command is supposed to deliver 1932 outgoing data and the R2T specifies data within the command bounds. 1933 The initiator action is unspecified for receiving an R2T request 1934 that specifies data, all or part, outside of the bounds of the 1935 command. 1937 A target SHOULD NOT silently discard data and then request 1938 retransmission through R2T. Initiators SHOULD NOT keep track of the 1939 data transferred to or from the target (scoreboarding). SCSI 1940 targets perform residual count calculation to check how much data 1941 was actually transferred to or from the device by a command. This 1942 may differ from the amount the initiator sent and/or received for 1943 reasons such as retransmissions and errors. Read or bidirectional 1944 commands implicitly solicit the transmission of the entire amount 1945 of data covered by the command. SCSI data packets are matched to 1946 their corresponding SCSI commands by using tags specified in the 1947 protocol. 1949 In addition, iSCSI initiators and targets MUST enforce some 1950 ordering rules. When unsolicited data is used, the order of the 1951 unsolicited data on each connection MUST match the order in which 1952 the commands on that connection are sent. Command and unsolicited 1953 data PDUs may be interleaved on a single connection as long as the 1954 ordering requirements of each are maintained (e.g., command N+1 MAY 1955 be sent before the unsolicited Data-Out PDUs for command N, but the 1956 unsolicited Data-Out PDUs for command N MUST precede the 1957 unsolicited Data-Out PDUs of command N+1). A target that receives 1958 data out of order MAY terminate the session. 1960 4.2.5.3. Tags and Integrity Checks 1962 Initiator tags for pending commands are unique initiator-wide for a 1963 session. Target tags are not strictly specified by the protocol. It 1964 is assumed that target tags are used by the target to tag (alone or 1965 in combination with the LUN) the solicited data. Target tags are 1966 generated by the target and "echoed" by the initiator. These 1967 mechanisms are designed to accomplish efficient data delivery along 1968 with a large degree of control over the data flow. 1970 As the Initiator Task Tag is used to identify a task during its 1971 execution the iSCSI initiator and target MUST verify that all other 1972 fields used in task related PDUs have values that are consistent 1973 with the values used at the task instantiation based on Initiator 1974 Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the 1975 one used in the SCSI command PDU used to instantiate the task). 1976 Using inconsistent field values is considered a protocol error. 1978 4.2.5.4. Task Management 1980 SCSI task management assumes that individual tasks and task groups 1981 can be aborted solely based on the task tags (for individual tasks) 1982 or the timing of the task management command (for task groups) and 1983 that the task management action is executed synchronously - i.e, no 1984 message involving an aborted task will be seen by the SCSI 1985 initiator after receiving the task management response. In iSCSI 1986 initiators and targets interact asynchronously over several 1987 connections. iSCSI specifies the protocol mechanism and 1988 implementation requirements needed to present a synchronous view 1989 while using an asynchronous infrastructure. 1991 4.2.6. iSCSI Connection Termination 1993 An iSCSI connection may be terminated by use of a transport 1994 connection shutdown or a transport reset. Transport reset is 1995 assumed to be an exceptional event. 1997 Graceful TCP connection shutdowns are done by sending TCP FINs. A 1998 graceful transport connection shutdown SHOULD only be initiated by 1999 either party when the connection is not in iSCSI Full Feature 2000 Phase. A target MAY terminate a Full Feature Phase connection on 2001 internal exception events, but it SHOULD announce the fact through 2002 an Asynchronous Message PDU. Connection termination with 2003 outstanding commands may require recovery actions. 2005 If a connection is terminated while in Full Feature Phase, 2006 connection cleanup (see section 7) is required prior to recovery. 2008 By doing connection cleanup before starting recovery, the initiator 2009 and target will avoid receiving stale PDUs after recovery. 2011 4.2.7. iSCSI Names 2013 Both targets and initiators require names for the purpose of 2014 identification. In addition, names enable iSCSI storage resources 2015 to be managed regardless of location (address). An iSCSI node name 2016 is also the SCSI device name contained in the iSCSI Node. The iSCSI 2017 name of a SCSI device is the principal object used in 2018 authentication of targets to initiators and initiators to targets. 2019 This name is also used to identify and manage iSCSI storage 2020 resources. 2022 iSCSI names must be unique within the operation domain of the end 2023 user. However, because the operation domain of an IP network is 2024 potentially worldwide, the iSCSI name formats are architected to be 2025 worldwide unique. To assist naming authorities in the construction 2026 of worldwide unique names, iSCSI provides three name formats for 2027 different types of naming authorities. 2029 iSCSI names are associated with iSCSI nodes, and not iSCSI network 2030 adapter cards, to ensure that the replacement of network adapter 2031 cards does not require reconfiguration of all SCSI and iSCSI 2032 resource allocation information. 2034 Some SCSI commands require that protocol-specific identifiers be 2035 communicated within SCSI CDBs. See SCSI for the definition of the 2036 SCSI port name/identifier for iSCSI ports. 2038 An initiator may discover the iSCSI Target Names to which it has 2039 access, along with their addresses, using the SendTargets text 2040 request, or other techniques discussed in [RFC3721]. 2042 iSCSI equipment that needs discovery functions beyond SendTargets 2043 SHOULD implement iSNS (see [RFC4171]) for extended discovery 2044 management capabilities and interoperability. Although [RFC3721] 2045 implies an SLP implementation requirement, SLP has not been widely 2046 implemented or deployed for use with iSCSI in practice. iSCSI 2047 implementations therefore SHOULD NOT rely on SLP-based discovery 2048 interoperability. 2050 4.2.7.1. iSCSI Name Properties 2052 Each iSCSI node, whether it is an initiator or target or both, MUST 2053 have an iSCSI name. 2055 Initiators and targets MUST support the receipt of iSCSI names of 2056 up to the maximum length of 223 bytes. 2058 The initiator MUST present both its iSCSI Initiator Name and the 2059 iSCSI Target Name to which it wishes to connect in the first login 2060 request of a new session or connection. The only exception is if a 2061 discovery session (see Section 2.3 iSCSI Session Types) is to be 2062 established. In this case, the iSCSI Initiator Name is still 2063 required, but the iSCSI Target Name MAY be omitted. 2065 iSCSI names have the following properties: 2067 iSCSI names are globally unique. No two initiators or targets 2068 can have the same name. 2069 iSCSI names are permanent. An iSCSI initiator node or target 2070 node has the same name for its lifetime. 2071 iSCSI names do not imply a location or address. An iSCSI 2072 initiator or target can move, or have multiple addresses. A 2073 change of address does not imply a change of name. 2074 iSCSI names do not rely on a central name broker; the naming 2075 authority is distributed. 2076 iSCSI names support integration with existing unique naming 2077 schemes. 2078 iSCSI names rely on existing naming authorities. iSCSI does not 2079 create any new naming authority. 2081 The encoding of an iSCSI name has the following properties: 2083 iSCSI names have the same encoding method regardless of the 2084 underlying protocols. 2085 iSCSI names are relatively simple to compare. The algorithm for 2086 comparing two iSCSI names for equivalence does not rely on 2087 an external server. 2088 iSCSI names are composed only of displayable characters. iSCSI 2089 names allow the use of international character sets but are 2090 not case sensitive. No whitespace characters are used in 2091 iSCSI names. 2092 iSCSI names may be transported using both binary and ASCII- 2093 based protocols. 2095 An iSCSI name really names a logical software entity, and is not 2096 tied to a port or other hardware that can be changed. For instance, 2097 an initiator name should name the iSCSI initiator node, not a 2098 particular NIC or HBA. When multiple NICs are used, they should 2099 generally all present the same iSCSI initiator name to the targets, 2100 because they are simply paths to the same SCSI layer. In most 2101 operating systems, the named entity is the operating system image. 2103 Similarly, a target name should not be tied to hardware interfaces 2104 that can be changed. A target name should identify the logical 2105 target and must be the same for the target regardless of the 2106 physical portion being addressed. This assists iSCSI initiators in 2107 determining that the two targets it has discovered are really two 2108 paths to the same target. 2110 The iSCSI name is designed to fulfill the functional requirements 2111 for Uniform Resource Names (URN) [RFC1737]. For example, it is 2112 required that the name have a global scope, be independent of 2113 address or location, and be persistent and globally unique. Names 2114 must be extensible and scalable with the use of naming authorities. 2115 The name encoding should be both human and machine readable. See 2116 [RFC1737] for further requirements. 2118 4.2.7.2. iSCSI Name Encoding 2120 An iSCSI name MUST be a UTF-8 encoding of a string of Unicode 2121 characters with the following properties: 2123 - It is in Normalization Form C (see "Unicode Normalization 2124 Forms" [UNICODE]). 2126 - It only contains characters allowed by the output of the 2127 iSCSI stringprep template (described in [RFC3722]). 2129 - The following characters are used for formatting iSCSI names: 2131 - dash ('-'=U+002d) 2132 - dot ('.'=U+002e) 2133 - colon (':'=U+003a) 2135 - The UTF-8 encoding of the name is not larger than 223 bytes. 2137 The stringprep process is described in [RFC3454]; iSCSI's use of 2138 the stringprep process is described in [RFC3722]. Stringprep is a 2139 method designed by the Internationalized Domain Name (IDN) working 2140 group to translate human-typed strings into a format that can be 2141 compared as opaque strings. Strings MUST NOT include punctuation, 2142 spacing, diacritical marks, or other characters that could get in 2143 the way of readability. The stringprep process also converts 2144 strings into equivalent strings of lower-case characters. 2146 The stringprep process does not need to be implemented if the names 2147 are only generated using numeric and lower-case (any character set) 2148 alphabetic characters. 2150 Once iSCSI names encoded in UTF-8 are "normalized" they may be 2151 safely compared byte-for-byte. 2153 4.2.7.3. iSCSI Name Structure 2155 An iSCSI name consists of two parts - a type designator followed by a 2156 unique name string. 2158 iSCSI uses three existing naming authorities in constructing 2159 globally unique iSCSI names. Type designator in an iSCSI name 2160 indicates the naming authority on which the name is based. The 2161 three iSCSI name formats are the following: 2163 iSCSI-Qualified Name: it is based on domain names to identify a 2164 naming authority, 2165 NAA format Name: it is based on a naming format defined by [FC- 2166 FS] for constructing globally unique identifiers, referred 2167 to as the Network Address Authority (NAA), and, 2169 EUI format Name: it is based on EUI names where the IEEE 2170 Registration Authority assists in the formation of worldwide 2171 unique names (EUI-64 format). 2173 The corresponding type designator strings currently defined are: 2175 iqn. - iSCSI Qualified name 2177 naa. - Remainder of the string is an INCITS T11-defined 2178 Network Address Authority identifier, in ASCII-encoded 2179 hexadecimal. 2181 eui. - Remainder of the string is an IEEE EUI-64 identifier, in 2182 ASCII-encoded hexadecimal. 2184 These three naming authority designators were considered sufficient 2185 at the time of writing this document. The creation of additional 2186 naming type designators for iSCSI may be considered by the IETF and 2187 detailed in separate RFCs. 2189 The following table summarizes the current SCSI transport protocols 2190 and their naming formats. 2192 SCSI Transport Protocol Naming Format 2193 +----------------------------+-------+-----+----+ 2194 | | EUI-64| NAA |IQN | 2195 |----------------------------|-------|-----|----| 2196 | iSCSI (Internet SCSI) | X | X | X | 2197 |----------------------------|-------|-----|----| 2198 | FCP (Fibre Channel) | | X | | 2199 |----------------------------|-------|-----|----| 2200 | SAS (Serial Attached SCSI) | | X | | 2201 |----------------------------|-------|-----|----| 2202 | SRP (for InfiniBand) | X | | | 2203 +----------------------------+-------+-----+----+ 2205 4.2.7.4. Type "iqn." (iSCSI Qualified Name) 2207 This iSCSI name type can be used by any organization that owns a 2208 domain name. This naming format is useful when an end user or 2209 service provider wishes to assign iSCSI names for targets and/or 2210 initiators. 2212 To generate names of this type, the person or organization 2213 generating the name must own a registered domain name. This domain 2214 name does not have to be active, and does not have to resolve to an 2215 address; it just needs to be reserved to prevent others from 2216 generating iSCSI names using the same domain name. 2218 Since a domain name can expire, be acquired by another entity, or 2219 may be used to generate iSCSI names by both owners, the domain name 2220 must be additionally qualified by a date during which the naming 2221 authority owned the domain name. A date code is provided as part of 2222 the "iqn." format for this reason. 2224 The iSCSI qualified name string consists of: 2226 - The string "iqn.", used to distinguish these names from 2227 "eui." formatted names. 2229 - A date code, in yyyy-mm format. This date MUST be a date 2230 during which the naming authority owned the domain name used 2231 in this format, and SHOULD be the first month in which the 2232 domain name was owned by this naming authority at 00:01 GMT 2233 of the first day of the month. This date code uses the 2234 Gregorian calendar. All four digits in the year must be 2235 present. Both digits of the month must be present, with 2236 January == "01" and December == "12". The dash must be 2237 included. 2239 - A dot "." 2241 - The reversed domain name of the naming authority (person or 2242 organization) creating this iSCSI name. 2244 - An optional, colon (:) prefixed, string within the character 2245 set and length boundaries that the owner of the domain name 2246 deems appropriate. This may contain product types, serial 2248 numbers, host identifiers, or software keys (e.g, it may 2249 include colons to separate organization boundaries). With the 2250 exception of the colon prefix, the owner of the domain name 2251 can assign everything after the reversed domain name as 2252 desired. It is the responsibility of the entity that is the 2253 naming authority to ensure that the iSCSI names it assigns 2254 are worldwide unique. For example, "Example Storage Arrays, 2255 Inc.", might own the domain name "example.com". 2257 The following are examples of iSCSI qualified names that might be 2258 generated by "EXAMPLE Storage Arrays, Inc." 2260 Naming String defined by 2261 Type Date Auth "example.com" naming authority 2262 +--++-----+ +---------+ +--------------------------------+ 2263 | || | | | | | 2265 iqn.2001-04.com.example:storage:diskarrays-sn-a8675309 2266 iqn.2001-04.com.example 2267 iqn.2001-04.com.example:storage.tape1.sys1.xyz 2268 iqn.2001-04.com.example:storage.disk2.sys1.xyz 2270 4.2.7.5. Type "eui." (IEEE EUI-64 format) 2272 The IEEE Registration Authority provides a service for assigning 2273 globally unique identifiers [EUI]. The EUI-64 format is used to 2274 build a global identifier in other network protocols. For example, 2275 Fibre Channel defines a method of encoding it into a WorldWideName. 2276 For more information on registering for EUI identifiers, see [OUI]. 2278 The format is "eui." followed by an EUI-64 identifier (16 ASCII- 2279 encoded hexadecimal digits). 2281 Example iSCSI name: 2283 Type EUI-64 identifier (ASCII-encoded hexadecimal) 2285 +--++--------------+ 2287 | || | 2288 eui.02004567A425678D 2290 The IEEE EUI-64 iSCSI name format might be used when a manufacturer 2291 is already registered with the IEEE Registration Authority and uses 2292 EUI-64 formatted worldwide unique names for its products. 2294 More examples of name construction are discussed in [RFC3721]. 2296 4.2.7.6. Type "naa." - Network Address Authority 2298 The INCITS T11 Framing and Signaling Specification [FC-FS] defines 2299 a format called the Network Address Authority (NAA) format for 2300 constructing worldwide unique identifiers that use various 2301 identifier registration authorities. This identifier format is used 2302 by the Fibre Channel and SAS SCSI transport protocols. As FC and 2303 SAS constitute a large fraction of networked SCSI ports, the NAA 2304 format is a widely used format for SCSI transports. The objective 2305 behind iSCSI supporting a direct representation of an NAA-format 2306 name is to facilitate construction of a target device name that 2307 translates easily across multiple namespaces for a SCSI storage 2308 device containing ports served by different transports. More 2309 specifically, this format allows implementations wherein one NAA 2310 identifier can be assigned as the basis for the SCSI device name 2311 for a SCSI target with both SAS ports and iSCSI ports. 2313 The iSCSI NAA naming format is "naa.", followed by an NAA 2314 identifier represented in ASCII-encoded hexadecimal digits. 2316 An example of an iSCSI name with a 64-bit NAA value follows: 2318 Type NAA identifier (ASCII-encoded hexadecimal) 2319 +--++--------------+ 2320 | || | 2321 naa.52004567BA64678D 2323 An example of an iSCSI name with a 128-bit NAA value follows: 2325 Type NAA identifier (ASCII-encoded hexadecimal) 2326 +--++------------------------------+ 2327 | || | 2328 naa.62004567BA64678D0123456789ABCDEF 2329 The iSCSI NAA naming format might be used in an implementation when 2330 the infrastructure for generating NAA worldwide unique names is 2331 already in place because the device contains both SAS and iSCSI 2332 SCSI ports. 2334 The NAA identifier formatted in an ASCII-hexadecimal representation 2335 has a maximum size of 32 characters (128 bit NAA format). As a 2336 result, there is no issue with this naming format exceeding the 2337 maximum size for iSCSI node names. 2339 4.2.8. Persistent State 2341 iSCSI does not require any persistent state maintenance across 2342 sessions. However, in some cases, SCSI requires persistent 2343 identification of the SCSI initiator port name (See Section 4.4.2 2344 and Section 4.4.3). 2346 iSCSI sessions do not persist through power cycles and boot 2347 operations. 2349 All iSCSI session and connection parameters are re-initialized on 2350 session and connection creation. 2352 Commands persist beyond connection termination if the session 2353 persists and command recovery within the session is supported. 2354 However, when a connection is dropped, command execution, as 2355 perceived by iSCSI (i.e., involving iSCSI protocol exchanges for 2356 the affected task), is suspended until a new allegiance is 2357 established by the 'task reassign' task management function. (See 2358 Section 10.5 "Task Management Function Request".) 2360 4.2.9. Message Synchronization and Steering 2362 iSCSI presents a mapping of the SCSI protocol onto TCP. This 2363 encapsulation is accomplished by sending iSCSI PDUs of varying 2364 lengths. Unfortunately, TCP does not have a built-in mechanism for 2365 signaling message boundaries at the TCP layer. iSCSI overcomes this 2366 obstacle by placing the message length in the iSCSI message header. 2367 This serves to delineate the end of the current message as well as 2368 the beginning of the next message. 2370 In situations where IP packets are delivered in order from the 2371 network, iSCSI message framing is not an issue and messages are 2372 processed one after the other. In the presence of IP packet 2373 reordering (i.e., frames being dropped), legacy TCP implementations 2374 store the "out of order" TCP segments in temporary buffers until 2375 the missing TCP segments arrive, upon which the data must be copied 2376 to the application buffers. In iSCSI, it is desirable to steer the 2377 SCSI data within these out of order TCP segments into the pre- 2378 allocated SCSI buffers rather than store them in temporary buffers. 2379 This decreases the need for dedicated reassembly buffers as well as 2380 the latency and bandwidth related to extra copies. 2382 Relying solely on the "message length" information from the iSCSI 2383 message header may make it impossible to find iSCSI message 2384 boundaries in subsequent TCP segments due to the loss of a TCP 2385 segment that contains the iSCSI message length. The missing TCP 2386 segment(s) must be received before any of the following segments 2387 can be steered to the correct SCSI buffers (due to the inability to 2388 determine the iSCSI message boundaries). Since these segments 2389 cannot be steered to the correct location, they must be saved in 2390 temporary buffers that must then be copied to the SCSI buffers. 2392 Different schemes can be used to recover synchronization. The 2393 details of any such schemes are beyond this protocol specification, 2394 but it suffices to note that [RFC4297] provides an overview of the 2395 direct data placement problem on IP networks, and [RFC5046] 2396 specifies a protocol extension for iSCSI that facilitates this 2397 direct data placement objective. 2399 Under normal circumstances (no PDU loss or data reception out of 2400 order), iSCSI data steering can be accomplished by using the 2401 identifying tag and the data offset fields in the iSCSI header in 2402 addition to the TCP sequence number from the TCP header. The 2403 identifying tag helps associate the PDU with a SCSI buffer address 2404 while the data offset and TCP sequence number are used to determine 2405 the offset within the buffer. 2407 4.2.9.1. Sync/Steering and iSCSI PDU Length 2409 When a large iSCSI message is sent, the TCP segment(s) that contain 2410 the iSCSI header may be lost. The remaining TCP segment(s) up to 2411 the next iSCSI message must be buffered (in temporary buffers) 2412 because the iSCSI header that indicates to which SCSI buffers the 2413 data are to be steered was lost. To minimize the amount of 2414 buffering, it is recommended that the iSCSI PDU length be 2415 restricted to a small value (perhaps a few TCP segments in length). 2416 During login, each end of the iSCSI session specifies the maximum 2417 iSCSI PDU length it will accept. 2419 4.3. iSCSI Session Types 2421 iSCSI defines two types of sessions: 2423 Normal operational session - an unrestricted session. 2425 Discovery-session - a session only opened for target discovery. 2426 The target MUST ONLY accept text requests with the 2427 SendTargets key and a logout request with reason "close the 2428 session". All other requests MUST be rejected. 2430 The session type is defined during login with key=value parameter 2431 in the login command. 2433 4.4. SCSI to iSCSI Concepts Mapping Model 2435 The following diagram shows an example of how multiple iSCSI Nodes 2436 (targets in this case) can coexist within the same Network Entity 2437 and can share Network Portals (IP addresses and TCP ports). Other 2438 more complex configurations are also possible. For detailed 2439 descriptions of the components of these diagrams, see section 2440 4.4.1. 2442 +-----------------------------------+ 2443 | Network Entity (iSCSI Client) | 2444 | | 2445 | +-------------+ | 2446 | | iSCSI Node | | 2447 | | (Initiator) | | 2448 | +-------------+ | 2449 | | | | 2450 | +--------------+ +--------------+ | 2451 | |Network Portal| |Network Portal| | 2452 | | 192.0.2.4 | | 192.0.2.5 | | 2453 +-+--------------+-+--------------+-+ 2454 | | 2455 | IP Networks | 2456 | | 2457 +-+--------------+-+--------------+-+ 2458 | |Network Portal| |Network Portal| | 2459 | | 198.51.100.21| | 198.51.100.3| | 2460 | | TCP Port 3260| | TCP Port 3260| | 2461 | +--------------+ +--------------+ | 2462 | | | | 2463 | ----------------- | 2464 | | | | 2465 | +-------------+ +--------------+ | 2466 | | iSCSI Node | | iSCSI Node | | 2467 | | (Target) | | (Target) | | 2468 | +-------------+ +--------------+ | 2469 | | 2470 | Network Entity (iSCSI Server) | 2471 +-----------------------------------+ 2473 4.4.1. iSCSI Architecture Model 2475 This section describes the part of the iSCSI architecture model 2476 that has the most bearing on the relationship between iSCSI and the 2477 SCSI Architecture Model. 2479 Network Entity - represents a device or gateway that is 2480 accessible from the IP network. A Network Entity must have 2481 one or more Network Portals (see a following item), each of 2482 which can be used by some iSCSI Nodes (see the following 2483 item) contained in that Network Entity to gain access to the 2484 IP network. 2486 iSCSI Node - represents a single iSCSI initiator or iSCSI 2487 target or an instance of each. There are one or more iSCSI 2488 Nodes within a Network Entity. The iSCSI Node is accessible 2489 via one or more Network Portals (see item d). An iSCSI Node 2490 is identified by its iSCSI Name (see Section 4.2.7 and 2491 Section 13). The separation of the iSCSI Name from the 2492 addresses used by and for the iSCSI node allows multiple 2493 iSCSI nodes to use the same addresses, and the same iSCSI 2494 node to use multiple addresses. 2496 An alias string may also be associated with an iSCSI Node. The 2497 alias allows an organization to associate a user friendly 2498 string with the iSCSI Name. However, the alias string is not 2499 a substitute for the iSCSI Name. 2501 Network Portal - a component of a Network Entity that has a 2502 TCP/IP network address and that may be used by an iSCSI Node 2503 within that Network Entity for the connection(s) within one 2504 of its iSCSI sessions. In an initiator, it is identified by 2505 its IP address. In a target, it is identified by its IP 2506 address and its listening TCP port. 2508 Portal Groups - iSCSI supports multiple connections within the 2509 same session; some implementations will have the ability to 2510 combine connections in a session across multiple Network 2511 Portals. A Portal Group defines a set of Network Portals 2512 within an iSCSI Node that collectively supports the 2513 capability of coordinating a session with connections that 2514 span these portals. Not all Network Portals within a Portal 2515 Group need to participate in every session connected through 2516 that Portal Group. One or more Portal Groups may provide 2517 access to an iSCSI Node. Each Network Portal, as utilized by 2518 a given iSCSI Node, belongs to exactly one portal group 2519 within that node. Portal Groups are identified within an 2520 iSCSI Node by a portal group tag, a simple unsigned-integer 2521 between 0 and 65535 (see Section 12.3 "SendTargets"). All 2522 Network Portals with the same portal group tag in the 2523 context of a given iSCSI Node are in the same Portal Group. 2525 Both iSCSI Initiators and iSCSI Targets have portal groups, 2526 though only the iSCSI Target Portal Groups are used directly 2527 in the iSCSI protocol (e.g., in SendTargets). For references 2528 to the Initiator Portal Groups, see Section 10.1.1. 2530 Portals within a Portal Group should support similar session 2531 parameters, because they may participate in a common 2532 session. 2534 The following diagram shows an example of one such configuration on 2535 a target and how a session that shares Network Portals within a 2536 Portal Group may be established. 2538 ----------------------------IP Network--------------------- 2539 | | | 2540 +----|---------------|-----+ +----|---------+ 2541 | +---------+ +---------+ | | +---------+ | 2542 | | Network | | Network | | | | Network | | 2543 | | Portal | | Portal | | | | Portal | | 2544 | +--|------+ +---------+ | | +---------+ | 2545 | | | | | | | 2546 | | Portal | | | | Portal | 2547 | | Group 1 | | | | Group 2 | 2548 +--------------------------+ +--------------+ 2549 | | | 2550 +--------|---------------|--------------------|-------------------+ 2551 | | | | | 2552 | +----------------------------+ +-----------------------------+| 2553 | | iSCSI Session (Target side)| | iSCSI Session (Target side) || 2554 | | | | || 2555 | | (TSIH = 56) | | (TSIH = 48) || 2556 | +----------------------------+ +-----------------------------+| 2557 | | 2558 | iSCSI Target Node | 2559 | (within Network Entity, not shown) | 2560 +-----------------------------------------------------------------+ 2562 4.4.2. SCSI Architecture Model 2564 This section describes the relationship between the SCSI 2565 Architecture Model [SAM2] and constructs of the SCSI device, SCSI 2566 port and I_T nexus, and the iSCSI constructs described in Section 2567 4.4.1. 2569 This relationship implies implementation requirements in order to 2570 conform to the SAM2 model and other SCSI operational functions. 2571 These requirements are detailed in Section 4.4.3. 2573 The following list outlines mappings of SCSI architectural elements 2574 to iSCSI. 2576 SCSI Device - the SAM2 term for an entity that contains one or 2577 more SCSI ports that are connected to a service delivery 2578 subsystem and supports a SCSI application protocol. For 2579 example, a SCSI Initiator Device contains one or more SCSI 2580 Initiator Ports and zero or more application clients. A SCSI 2581 Target Device contains one or more SCSI Target Ports and one 2582 or more logical units. For iSCSI, the SCSI Device is the 2583 component within an iSCSI Node that provides the SCSI 2584 functionality. As such, there can be one SCSI Device, at 2585 most, within an iSCSI Node. Access to the SCSI Device can 2586 only be achieved in an iSCSI normal operational session (see 2587 Section 4.3). The SCSI Device Name is defined to be the 2588 iSCSI Name of the node and MUST be used in the iSCSI 2589 protocol. 2591 SCSI Port - the SAM2 term for an entity in a SCSI Device that 2592 provides the SCSI functionality to interface with a service 2593 delivery subsystem or transport. For iSCSI, the definition 2594 of SCSI Initiator Port and SCSI Target Port are different. 2596 SCSI Initiator Port: This maps to one endpoint of an iSCSI 2597 normal operational session (see Section 4.3). An iSCSI 2598 normal operational session is negotiated through the login 2599 process between an iSCSI initiator node and an iSCSI target 2600 node. At successful completion of this process, a SCSI 2601 Initiator Port is created within the SCSI Initiator Device. 2602 The SCSI Initiator Port Name and SCSI Initiator Port 2603 Identifier are both defined to be the iSCSI Initiator Name 2604 together with (a) a label that identifies it as an initiator 2605 port name/identifier and (b) the ISID portion of the session 2606 identifier. 2608 SCSI Target Port: This maps to an iSCSI Target Portal Group. 2609 The SCSI Target Port Name and the SCSI Target Port 2610 Identifier are both defined to be the iSCSI Target Name 2611 together with (a) a label that identifies it as a target 2612 port name/identifier and (b) the portal group tag. 2614 The SCSI Port Name MUST be used in iSCSI. When used in SCSI 2615 parameter data, the SCSI port name MUST be encoded as: 2616 - The iSCSI Name in UTF-8 format, followed by 2617 - a comma separator (1 byte), followed by 2618 - the ASCII character 'i' (for SCSI Initiator Port) or the 2619 ASCII character 't' (for SCSI Target Port) (1 byte), 2620 followed by 2621 - a comma separator (1 byte), followed by 2622 - a text encoding as a hex-constant (see Section 5.1 "Text 2623 Format") of the ISID (for SCSI initiator port) or the 2624 portal group tag (for SCSI target port) including the 2625 initial 0X or 0x and the terminating null (14 bytes). 2627 The ASCII character 'i' or 't' is the label that 2628 identifies this port as either a SCSI Initiator Port or a 2629 SCSI Target Port. 2631 I_T nexus - a relationship between a SCSI Initiator Port and a 2632 SCSI Target Port, according to [SAM2]. For iSCSI, this 2633 relationship is a session, defined as a relationship between 2634 an iSCSI Initiator's end of the session (SCSI Initiator 2635 Port) and the iSCSI Target's Portal Group. The I_T nexus can 2636 be identified by the conjunction of the SCSI port names or 2637 by the iSCSI session identifier SSID. iSCSI defines the I_T 2638 nexus identifier to be the tuple (iSCSI Initiator Name + 'i' 2639 + ISID, iSCSI Target Name + 't' + Portal Group Tag). 2641 NOTE: The I_T nexus identifier is not equal to the session 2642 identifier (SSID). 2644 4.4.3. Consequences of the Model 2646 This section describes implementation and behavioral requirements 2647 that result from the mapping of SCSI constructs to the iSCSI 2648 constructs defined above. Between a given SCSI initiator port and a 2649 given SCSI target port, only one I_T nexus (session) can exist. No 2650 more than one nexus relationship (parallel nexus) is allowed by 2651 [SAM2]. Therefore, at any given time, only one session with the 2652 same session identifier (SSID) can exist between a given iSCSI 2653 initiator node and an iSCSI target node. 2655 These assumptions lead to the following conclusions and 2656 requirements: 2658 ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal 2659 Group (SCSI target port), there can only be one session with a 2660 given value for ISID that identifies the SCSI initiator port. See 2661 Section 10.12.5 "ISID". 2663 The structure of the ISID that contains a naming authority 2664 component (see Section 10.12.5 "ISID" and [RFC3721]) provides a 2665 mechanism to facilitate compliance with the ISID rule. (See Section 2666 9.1.1 "Conservative Reuse of ISIDs".) 2668 The iSCSI Initiator Node should manage the assignment of ISIDs 2669 prior to session initiation. The "ISID RULE" does not preclude the 2670 use of the same ISID from the same iSCSI Initiator with different 2671 Target Portal Groups on the same iSCSI target or on other iSCSI 2672 targets (see Section 9.1.1 "Conservative Reuse of ISIDs"). Allowing 2673 this would be analogous to a single SCSI Initiator Port having 2674 relationships (nexus) with multiple SCSI target ports on the same 2675 SCSI target device or SCSI target ports on other SCSI target 2676 devices. It is also possible to have multiple sessions with 2677 different ISIDs to the same Target Portal Group. Each such session 2678 would be considered to be with a different initiator even when the 2679 sessions originate from the same initiator device. The same ISID 2680 may be used by a different iSCSI initiator because it is the iSCSI 2681 Name together with the ISID that identifies the SCSI Initiator 2682 Port. 2684 NOTE: A consequence of the ISID RULE and the specification for the 2685 I_T nexus identifier is that two nexus with the same identifier 2686 should never exist at the same time. 2688 TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH 2689 at session creation (when an initiator presents a 0 value at 2690 Login). After being selected, the same TSIH value MUST be used 2691 whenever initiator or target refers to the session and a TSIH is 2692 required. 2694 4.4.3.1. I_T Nexus State 2696 Certain nexus relationships contain an explicit state (e.g., 2697 initiator-specific mode pages) that may need to be preserved by the 2698 device server [SAM2] in a logical unit through changes or failures 2699 in the iSCSI layer (e.g., session failures). In order for that 2700 state to be restored, the iSCSI initiator should reestablish its 2701 session (re-login) to the same Target Portal Group using the 2702 previous ISID. That is, it should perform session recovery as 2703 described in Chapter 6. This is because the SCSI initiator port 2704 identifier and the SCSI target port identifier (or relative target 2705 port) form the datum that the SCSI logical unit device server uses 2706 to identify the I_T nexus. 2708 4.5. iSCSI UML Model 2710 This section presents the application of the UML modeling concepts 2711 discussed in Section 3 to the iSCSI and SCSI architecture model 2712 discussed in Section 4.4. 2714 +----------------+ 2715 | Network Entity | 2716 +----------------+ 2717 @ 1 @ 1 2718 | | 2719 +--------------------+ | 2720 | | 2721 | | 0..* 2722 | +------------------+ 2723 | | iSCSI Node | 2724 | +------------------+ 2725 | @ @ 2726 | | | 2727 | +--------------+ =(a)= +-------------+ 2728 | | | 2729 | | 0..1 | 0..1 2730 | +------------------------+ +----------------------+ 2731 | | iSCSI Target Node | | iSCSI Initiator Node | 2732 | +------------------------+ +----------------------+ 2733 | @ 1 @ 1 2734 | +--------------+ | 2735 | 1..* | | 1..* 2736 | +-----------------------------+ 2737 | | Portal Group | 2738 | +-----------------------------+ 2739 | O 1 2740 | | 2741 | | 1..* 2742 | 1..* +------------------------+ 2743 +--------------------| Network Portal | 2744 +------------------------+ 2746 (a) Each instance of an iSCSI Node class MUST contain one iSCSI 2747 Target Node instance or one iSCSI Initiator Node instance, or 2748 both. 2750 +----------------+ 2751 | Network Entity | 2752 +----------------+ 2753 @ 1 @ 1 2754 | | +-------------------+ 2755 +---------------------+ | | iSCSI Session | 2756 | | +-------------------+ 2757 | | 0..* | SSID[1] | 2758 | +--------------------+ | ISID[1] | 2759 | | iSCSI Node | +-------------------+ 2760 | +--------------------+ @ 1 2761 | | iSCSI Node Name[1] | | 2762 | | Alias [0..1] | | 0..* 2763 | +--------------------+ +------------------+ 2764 | | | | iSCSI Connection | 2765 | +--------------------+ +------------------+ 2766 | @ 1 @ 1 | CID[1] | 2767 | | | +------------------+ 2768 | +-------------+ ==(b)== +----------+ 0..* | 2769 | | 1 | 1 | 2770 | +------------------------+ +------------------------+ | 2771 | | iSCSI Target Node | | iSCSI Initiator Node | | 2772 | +------------------------+ +------------------------+ | 2773 | | iSCSI Target name [1] | |iSCSI Initiator Name [1]| | 2774 | +------------------------+ +------------------------+ | 2775 | @ 1 @ 1 | 2776 | | 1..* | 1..* | 2777 | +--------------------------+ +------------------------+ | 2778 | | Target Portal Group | | Initiator Portal Group | | 2779 | +--------------------------+ +------------------------+ | 2780 | |Target Portal Group Tag[1]| | Portal group tag[1] | | 2781 | +--------------------------+ +------------------------+ | 2782 | o 1 o 1 | 2783 | +------------+ +---------+ | 2784 | 1..* | | 1..* | 2785 | +-------------------------+ | 2786 | | Network Portal | | 2787 | +-------------------------+ | 2788 | 1..* | IP Address [1] | 1 | 2789 +----------------| TCP Port [0..1] |<----------------------+ 2790 +-------------------------+ 2792 (b) Each instance of an iSCSI Node class MUST contain one iSCSI 2793 Target Node instance or one iSCSI Initiator Node instance, or 2794 both. 2796 4.6. Request/Response Summary 2798 This section lists and briefly describes all the iSCSI PDU types 2799 (request and responses). 2801 All iSCSI PDUs are built as a set of one or more header segments 2802 (basic and auxiliary) and zero or one data segments. The header 2803 group and the data segment may each be followed by a CRC (digest). 2805 The basic header segment has a fixed length of 48 bytes. 2807 4.6.1. Request/Response Types Carrying SCSI Payload 2809 4.6.1.1. SCSI-Command 2811 This request carries the SCSI CDB and all the other SCSI execute 2812 command procedure call (see [SAM2]) IN arguments such as task 2813 attributes, Expected Data Transfer Length for one or both transfer 2814 directions (the latter for bidirectional commands), and Task Tag 2815 (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the 2816 initiator and target from the LUN field in the request and the I_T 2817 nexus is implicit in the session identification. 2819 In addition, the SCSI-command PDU carries information required for 2820 the proper operation of the iSCSI protocol - the command sequence 2821 number (CmdSN) and the expected status number (ExpStatSN) on the 2822 connection it is issued. 2824 All or part of the SCSI output (write) data associated with the 2825 SCSI command may be sent as part of the SCSI-Command PDU as a data 2826 segment. 2828 4.6.1.2. SCSI-Response 2830 The SCSI-Response carries all the SCSI execute-command procedure 2831 call (see [SAM2]) OUT arguments and the SCSI execute-command 2832 procedure call return value. 2834 The SCSI-Response contains the residual counts from the operation, 2835 if any, an indication of whether the counts represent an overflow 2836 or an underflow, and the SCSI status if the status is valid or a 2837 response code (a non-zero return value for the execute-command 2838 procedure call) if the status is not valid. 2840 For a valid status that indicates that the command has been 2841 processed, but resulted in an exception (e.g., a SCSI CHECK 2842 CONDITION), the PDU data segment contains the associated sense 2843 data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI. 2845 Some data segment content may also be associated (in the data 2846 segment) with a non-zero response code. 2848 In addition, the SCSI-Response PDU carries information required for 2849 the proper operation of the iSCSI protocol: 2851 - The number of Data-In PDUs that a target has sent (to enable 2852 the initiator to check that all have arrived). 2854 - StatSN - the Status Sequence Number on this connection. 2856 - ExpCmdSN - the next Expected Command Sequence Number at the 2857 target. 2859 - MaxCmdSN - the maximum CmdSN acceptable at the target from 2860 this initiator. 2862 4.6.1.3. Task Management Function Request 2864 The Task Management function request provides an initiator with a 2865 way to explicitly control the execution of one or more SCSI Tasks 2866 or iSCSI functions. The PDU carries a function identifier (which 2867 task management function to perform) and enough information to 2868 unequivocally identify the task or task-set on which to perform the 2869 action, even if the task(s) to act upon has not yet arrived or has 2870 been discarded due to an error. 2872 The referenced tag identifies an individual task if the function 2873 refers to an individual task. 2875 The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is 2876 identified by the LUN and the session identification (the session 2877 identifies an I_T nexus). 2879 For task sets, the CmdSN of the Task Management function request 2880 helps identify the tasks upon which to act, namely all tasks 2881 associated with a LUN and having a CmdSN preceding the Task 2882 Management function request CmdSN. 2884 For a Task Management function, the coordination between responses 2885 to the tasks affected and the Task Management function response is 2886 done by the target. 2888 4.6.1.4. Task Management Function Response 2890 The Task Management function response carries an indication of 2891 function completion for a Task Management function request 2892 including how it completed (response and qualifier) and additional 2893 information for failure responses. 2895 After the Task Management response indicates Task Management 2896 function completion, the initiator will not receive any additional 2897 responses from the affected tasks. 2899 4.6.1.5. SCSI Data-out and SCSI Data-in 2901 SCSI Data-out and SCSI Data-in are the main vehicles by which SCSI 2902 data payload is carried between initiator and target. Data payload 2903 is associated with a specific SCSI command through the Initiator 2904 Task Tag. For target convenience, outgoing solicited data also 2905 carries a Target Transfer Tag (copied from R2T) and the LUN. Each 2906 PDU contains the payload length and the data offset relative to the 2907 buffer address contained in the SCSI execute command procedure 2908 call. 2910 In each direction, the data transfer is split into "sequences". An 2911 end-of-sequence is indicated by the F bit. 2913 An outgoing sequence is either unsolicited (only the first sequence 2914 can be unsolicited) or consists of all the Data-Out PDUs sent in 2915 response to an R2T. 2917 Input sequences enable the switching of direction for bidirectional 2918 commands as required. 2920 For input, the target may request positive acknowledgement of input 2921 data. This is limited to sessions that support error recovery and 2922 is implemented through the A bit in the SCSI Data-in PDU header. 2924 Data-in and Data-out PDUs also carry the DataSN to enable the 2925 initiator and target to detect missing PDUs (discarded due to an 2926 error). 2928 In addition, StatSN is carried by the Data-In PDUs. 2930 To enable a SCSI command to be processed while involving a minimum 2931 number of messages, the last SCSI Data-in PDU passed for a command 2932 may also contain the status if the status indicates termination 2933 with no exceptions (no sense or response involved). 2935 4.6.1.6. Ready To Transfer (R2T) 2937 R2T is the mechanism by which the SCSI target "requests" the 2938 initiator for output data. R2T specifies to the initiator the 2939 offset of the requested data relative to the buffer address from 2940 the execute command procedure call and the length of the solicited 2941 data. 2943 To help the SCSI target associate the resulting Data-out with an 2944 R2T, the R2T carries a Target Transfer Tag that will be copied by 2945 the initiator in the solicited SCSI Data-out PDUs. There are no 2946 protocol specific requirements with regard to the value of these 2947 tags, but it is assumed that together with the LUN, they will 2948 enable the target to associate data with an R2T. 2950 R2T also carries information required for proper operation of the 2951 iSCSI protocol, such as: 2953 - R2TSN (to enable an initiator to detect a missing R2T) 2955 - StatSN 2957 - ExpCmdSN 2959 - MaxCmdSN 2961 4.6.2. Requests/Responses carrying SCSI and iSCSI Payload 2963 4.6.2.1. Asynchronous Message 2965 Asynchronous Messages are used to carry SCSI asynchronous events 2966 (AEN) and iSCSI asynchronous messages. 2968 When carrying an AEN, the event details are reported as sense data 2969 in the data segment. 2971 4.6.3. Requests/Responses Carrying iSCSI Only Payload 2973 4.6.3.1. Text Request and Text Response 2975 Text requests and responses are designed as a parameter negotiation 2976 vehicle and as a vehicle for future extension. 2978 In the data segment Text Requests/Responses carry text information 2979 using a simple "key=value" syntax. 2981 Text Request/Responses may form extended sequences using the same 2982 Initiator Task Tag. The initiator uses the F (Final) flag bit in 2983 the text request header to indicate its readiness to terminate a 2984 sequence. The target uses the F (Final) flag bit in the text 2985 response header to indicate its consent to sequence termination. 2987 Text Request and Responses also use the Target Transfer Tag to 2988 indicate continuation of an operation or a new beginning. A target 2989 that wishes to continue an operation will set the Target Transfer 2990 Tag in a Text Response to a value different from the default 2991 0xffffffff. An initiator willing to continue will copy this value 2992 into the Target Transfer Tag of the next Text Request. If the 2993 initiator wants to restart the current target negotiation (start 2994 fresh) will set the Target Transfer Tag to 0xffffffff. 2996 Although a complete exchange is always started by the initiator, 2997 specific parameter negotiations may be initiated by the initiator 2998 or target. 3000 4.6.3.2. Login Request and Login Response 3002 Login Requests and Responses are used exclusively during the Login 3003 Phase of each connection to set up the session and connection 3004 parameters. (The Login Phase consists of a sequence of login 3005 requests and responses carrying the same Initiator Task Tag.) 3007 A connection is identified by an arbitrarily selected connection-ID 3008 (CID) that is unique within a session. 3010 Similar to the Text Requests and Responses, Login 3011 Requests/Responses carry key=value text information with a simple 3012 syntax in the data segment. 3014 The Login Phase proceeds through several stages (security 3015 negotiation, operational parameter negotiation) that are selected 3016 with two binary coded fields in the header - the "current stage" 3017 (CSG) and the "next stage" (NSG) with the appearance of the latter 3018 being signaled by the "transit" flag (T). 3020 The first Login Phase of a session plays a special role, called the 3021 leading login, which determines some header fields (e.g., the 3022 version number, the maximum number of connections, and the session 3023 identification). 3025 The CmdSN initial value is also set by the leading login. 3027 StatSN for each connection is initiated by the connection login. 3029 A login request may indicate an implied logout (cleanup) of the 3030 connection to be logged in (a connection restart) by using the same 3031 Connection ID (CID) as an existing connection as well as the same 3032 session identifying elements of the session to which the old 3033 connection was associated. 3035 4.6.3.3. Logout Request and Response 3037 Logout Requests and Responses are used for the orderly closing of 3038 connections for recovery or maintenance. The logout request may be 3039 issued following a target prompt (through an asynchronous message) 3040 or at an initiators initiative. When issued on the connection to be 3041 logged out no other request may follow it. 3043 The Logout response indicates that the connection or session 3044 cleanup is completed and no other responses will arrive on the 3045 connection (if received on the logging out connection). In 3046 addition, the Logout Response indicates how long the target will 3047 continue to hold resources for recovery (e.g., command execution 3048 that continues on a new connection) in the text key Time2Retain and 3049 how long the initiator must wait before proceeding with recovery in 3050 the text key Time2Wait. 3052 4.6.3.4. SNACK Request 3054 With the SNACK Request, the initiator requests retransmission of 3055 numbered-responses or data from the target. A single SNACK request 3056 covers a contiguous set of missing items, called a run, of a given 3057 type of items. The type is indicated in a type field in the PDU 3058 header. The run is composed of an initial item (StatSN, DataSN, 3059 R2TSN) and the number of missed Status, Data, or R2T PDUs. For long 3060 data-in sequences, the target may request (at predefined minimum 3061 intervals) a positive acknowledgement for the data sent. A SNACK 3062 request with a type field that indicates ACK and the number of 3063 Data-In PDUs acknowledged conveys this positive acknowledgement. 3065 4.6.3.5. Reject 3067 Reject enables the target to report an iSCSI error condition (e.g., 3068 protocol, unsupported option) that uses a Reason field in the PDU 3069 header and includes the complete header of the bad PDU in the 3070 Reject PDU data segment. 3072 4.6.3.6. NOP-Out Request and NOP-In Response 3074 This request/response pair may be used by an initiator and target 3075 as a "ping" mechanism to verify that a connection/session is still 3076 active and all of its components are operational. Such a ping may 3077 be triggered by the initiator or target. The triggering party 3078 indicates that it wants a reply by setting a value different from 3079 the default 0xffffffff in the corresponding Initiator/Target 3080 Transfer Tag. 3082 NOP-In/NOP-Out may also be used "unidirectional" to convey to the 3083 initiator/target command, status or data counter values when there 3084 is no other "carrier" and there is a need to update the 3085 initiator/target. 3087 5. SCSI Mode Parameters for iSCSI 3089 There are no iSCSI specific mode pages. 3091 6. Login and Full Feature Phase Negotiation 3093 iSCSI parameters are negotiated at session or connection 3094 establishment by using Login Requests and Responses (see Section 3095 3.2.3 - "iSCSI Login") and during Full Feature Phase (Section 3.2.4 3096 - "iSCSI Full Feature Phase") by using Text Requests and Responses. 3097 In both cases the mechanism used is an exchange of iSCSI-text- 3098 key=value pairs. For brevity, iSCSI-text-keys are called just keys 3099 in the rest of this document. 3101 Keys are either declarative or require negotiation and the key 3102 description indicates if the key is declarative or requires 3103 negotiation. 3105 For the declarative keys the declaring party sets a value for the 3106 key. The key specification indicates if the key can be declared by 3107 the initiator, target or both. 3109 For the keys that require negotiation, one of the parties (the 3110 proposing party) proposes a value or set of values by including the 3111 key=value in the data part of a Login or Text Request or Response. 3112 The other party (the accepting party) makes a selection based on 3113 the value or list of values proposed and includes the selected 3114 value in a key=value in the data part of the following Login or 3115 Text Response or Request. For most of the keys, both the initiator 3116 and target can be proposing parties. 3118 The login process proceeds in two stages - the security negotiation 3119 stage and the operational parameter negotiation stage. Both stages 3120 are optional but at least one of them has to be present to enable 3121 setting some mandatory parameters. 3123 If present, the security negotiation stage precedes the operational 3124 parameter negotiation stage. 3126 Progression from stage to stage is controlled by the T (Transition) 3127 bit in the Login Request/Response PDU header. Through the T bit set 3128 to 1, the initiator indicates that it would like to transition. The 3129 target agrees to the transition (and selects the next stage) when 3130 ready. A field in the Login PDU header indicates the current stage 3131 (CSG) and during transition, another field indicates the next stage 3132 (NSG) proposed (initiator) and selected (target). 3134 The Text negotiation process is used to negotiate or declare 3135 operational parameters. The negotiation process is controlled by 3136 the F (final) bit in the PDU header. During text negotiations, the 3137 F bit is used by the initiator to indicate that it is ready to 3138 finish the negotiation and by the Target to acquiesce the end of 3139 negotiation. 3141 Since some key=value pairs may not fit entirely in a single PDU, 3142 the C (continuation) bit is used (both in Login and Text) to 3143 indicate that "more follows". 3145 The text negotiation uses an additional mechanism by which a target 3146 may deliver larger amounts of data to an enquiring initiator. The 3147 target sets a Target Task Tag to be used as a bookmark which when 3148 returned by the initiator, means "go on". If reset to a "neutral 3149 value", it means "forget about the rest". 3151 This chapter details types of keys and values used, the syntax 3152 rules for parameter formation, and the negotiation schemes to be 3153 used with different types of parameters. 3155 6.1. Text Format 3157 The initiator and target send a set of key=value pairs encoded in 3158 UTF-8 Unicode. All the text keys and text values specified in this 3159 document are to be presented and interpreted in the case in which 3160 they appear in this document. They are case sensitive. 3162 The following character symbols are used in this document for text 3163 items (the hexadecimal values represent Unicode code points): 3165 (a-z, A-Z) - letters 3166 (0-9) - digits 3167 " " (0x20) - space 3168 "." (0x2e) - dot 3169 "-" (0x2d) - minus 3170 "+" (0x2b) - plus 3171 "@" (0x40) - commercial at 3172 "_" (0x5f) - underscore 3173 "=" (0x3d) - equal 3174 ":" (0x3a) - colon 3176 "/" (0x2f) - solidus or slash 3177 "[" (0x5b) - left bracket 3178 "]" (0x5d) - right bracket 3179 null (0x00) - null separator 3180 "," (0x2c) - comma 3181 "~" (0x7e) - tilde 3183 Key=value pairs may span PDU boundaries. An initiator or target 3184 that sends partial key=value text within a PDU indicates that more 3185 text follows by setting the C bit in the Text or Login Request or 3186 Text or Login Response to 1. Data segments in a series of PDUs that 3187 have the C bit set to 1 and end with a PDU that have the C bit set 3188 to 0, or include a single PDU that has the C bit set to 0 have to 3189 be considered as forming a single logical-text-data-segment (LTDS). 3191 Every key=value pair, including the last or only pair in a LTDS, 3192 MUST be followed by one null (0x00) delimiter. 3194 A key-name is whatever precedes the first = in the key=value pair. 3195 The term key is used frequently in this document in place of key- 3196 name. 3198 A value is whatever follows the first = in the key=value pair up to 3199 the end of the key=value pair, but not including the null 3200 delimiter. 3202 The following definitions will be used in the rest of this 3203 document: 3205 standard-label: A string of one or more characters that consist 3206 of letters, digits, dot, minus, plus, commercial at, or 3207 underscore. A standard-label MUST begin with a capital letter 3208 and must not exceed 63 characters. 3210 key-name: A standard-label. 3212 text-value: A string of zero or more characters that consist of 3213 letters, digits, dot, minus, plus, commercial at, underscore, 3214 slash, left bracket, right bracket, or colon. 3216 iSCSI-name-value: A string of one or more characters that 3217 consist of minus, dot, colon, or any character allowed by the 3218 output of the iSCSI string-prep template as specified in 3219 [RFC3722] (see also Section 3.2.6.2 - "iSCSI Name Encoding"). 3221 iSCSI-local-name-value: A UTF-8 string; no null characters are 3222 allowed in the string. This encoding is to be used for 3223 localized (internationalized) aliases. 3225 boolean-value: The string "Yes" or "No". 3227 hex-constant: A hexadecimal constant encoded as a string that 3228 starts with "0x" or "0X" followed by one or more digits or 3229 the letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex- 3230 constants are used to encode numerical values or binary 3231 strings. When used to encode numerical values, the excessive 3232 use of leading 0 digits is discouraged. The string following 3233 0X (or 0x) represents a base16 number that starts with the 3234 most significant base16 digit, followed by all other digits 3235 in decreasing order of significance and ending with the 3236 least-significant base16 digit. When used to encode binary 3237 strings, hexadecimal constants have an implicit byte-length 3238 that includes four bits for every hexadecimal digit of the 3239 constant, including leading zeroes. For example, a hex- 3240 constant of n hexadecimal digits has a byte-length of (the 3241 integer part of) (n+1)/2. 3243 decimal-constant: An unsigned decimal number with the digit 0 3244 or a string of one or more digits that start with a non-zero 3246 digit. Decimal-constants are used to encode numerical values 3247 or binary strings. Decimal constants can only be used to 3248 encode binary strings if the string length is explicitly 3249 specified. There is no implicit length for decimal strings. 3250 Decimal-constant MUST NOT be used for parameter values if the 3251 values can be equal or greater than 2**64 (numerical) or for 3252 binary strings that can be longer than 64 bits. 3254 base64-constant: base64 constant encoded as a string that 3255 starts with "0b" or "0B" followed by 1 or more digits or 3256 letters or plus or slash or equal. The encoding is done 3257 according to [RFC2045] and each character, except equal, 3258 represents a base64 digit or a 6-bit binary string. Base64- 3259 constants are used to encode numerical-values or binary 3260 strings. When used to encode numerical values, the excessive 3261 use of leading 0 digits (encoded as A) is discouraged. The 3262 string following 0B (or 0b) represents a base64 number that 3263 starts with the most significant base64 digit, followed by 3264 all other digits in decreasing order of significance and 3265 ending with the least-significant base64 digit; the least 3266 significant base64 digit may be optionally followed by pad 3267 digits (encoded as equal) that are not considered as part of 3268 the number. When used to encode binary strings, base64- 3269 constants have an implicit byte-length that includes six bits 3270 for every character of the constant, excluding trailing 3271 equals (i.e., a base64-constant of n base64 characters 3272 excluding the trailing equals has a byte-length of ((the 3273 integer part of) (n*3/4)). Correctly encoded base64 strings 3274 cannot have n values of 1, 5 ... k*4+1. 3276 numerical-value: An unsigned integer always less than 2**64 3277 encoded as a decimal-constant or a hex-constant. Unsigned 3278 integer arithmetic applies to numerical-values. 3280 large-numerical-value: An unsigned integer that can be larger 3281 than or equal to 2**64 encoded as a hex constant, or base64- 3282 constant. Unsigned integer arithmetic applies to large- 3283 numeric-values. 3285 numeric-range: Two numerical-values separated by a tilde where 3286 the value to the right of tilde must not be lower than the 3287 value to the left. 3289 regular-binary-value: A binary string not longer than 64 bits 3290 encoded as a decimal constant, hex constant, or base64- 3291 constant. The length of the string is either specified by the 3292 key definition or is the implicit byte-length of the encoded 3293 string. 3295 large-binary-value: A binary string longer than 64 bits encoded 3296 as a hex-constant or base64-constant. The length of the 3297 string is either specified by the key definition or is the 3298 implicit byte-length of the encoded string. 3300 binary-value: A regular-binary-value or a large-binary-value. 3301 Operations on binary values are key specific. 3303 simple-value: Text-value, iSCSI-name-value, boolean-value, 3304 numeric-value, a numeric-range, or a binary-value. 3306 list-of-values: A sequence of text-values separated by a comma. 3308 If not otherwise specified, the maximum length of a simple-value 3309 (not its encoded representation) is 255 bytes not including the 3310 delimiter (comma or zero byte). 3312 Any iSCSI target or initiator MUST support receiving at least 8192 3313 bytes of key=value data in a negotiation sequence. When proposing 3314 or accepting authentication methods that explicitly require support 3315 for very long authentication items, the initiator and target MUST 3316 support receiving of at least 64 kilobytes of key=value data. 3318 6.2. Text Mode Negotiation 3320 During login, and thereafter, some session or connection parameters 3321 are either declared or negotiated through an exchange of textual 3322 information. 3324 The initiator starts the negotiation and/or declaration through a 3325 Text or Login request and indicates when it is ready for completion 3326 (by setting the F bit to 1 and keeping it to 1 in a Text Request or 3327 the T bit in the Login Request). As negotiation text may span PDU 3328 boundaries, a Text or Login Request or Text or Login Response PDU 3329 that have the C bit set to 1 MUST NOT have the F/T bit set to 1. 3331 A target receiving a Text or Login Request with the C bit set to 1 3332 MUST answer with a Text or Login Response with no data segment 3333 (DataSegmentLength 0). An initiator receiving a Text or Login 3334 Response with the C bit set to 1 MUST answer with a Text or Login 3335 Request with no data segment (DataSegmentLength 0). 3337 A target or initiator SHOULD NOT use a Text or Login Response or 3338 Text or Login Request with no data segment (DataSegmentLength 0) 3339 unless explicitly required by a general or a key-specific 3340 negotiation rule. 3342 There MUST NOT be more than one outstanding Text Request, or Text 3343 Response PDU on an iSCSI connection. An outstanding PDU in this 3344 context is one that has not been acknowledged by the remote iSCSI 3345 side. 3347 The format of a declaration is: 3349 Declarer-> = 3351 The general format of text negotiation is: 3353 Proposer-> = 3355 Acceptor-> ={|NotUnderstood|Irrelevant|Reject} 3357 Thus a declaration is a one-way textual exchange (unless the key is 3358 not understood by the receiver) while a negotiation is a two-way 3359 exchange. 3361 The proposer or declarer can either be the initiator or the target, 3362 and the acceptor can either be the target or initiator, 3363 respectively. Targets are not limited to respond to key=value pairs 3364 as proposed by the initiator. The target may propose key=value 3365 pairs of its own. 3367 All negotiations are explicit (i.e., the result MUST only be based 3368 on newly exchanged or declared values). There are no implicit 3369 proposals. If a proposal is not made, then a reply cannot be 3370 expected. Conservative design also requires that default values 3371 should not be relied upon when use of some other value has serious 3372 consequences. 3374 The value proposed or declared can be a numerical-value, a 3375 numerical-range defined by lower and upper value with both integers 3376 separated by tilde, a binary value, a text-value, an iSCSI-name- 3377 value, an iSCSI-local-name-value, a boolean-value (Yes or No), or a 3378 list of comma separated text-values. A range, a large-numerical- 3379 value, an iSCSI-name-value and an iSCSI-local-name-value MAY ONLY 3380 be used if it is explicitly allowed. An accepted value can be a 3381 numerical-value, a large-numerical-value, a text-value, or a 3382 boolean-value. 3384 If a specific key is not relevant for the current negotiation, the 3385 acceptor may answer with the constant "Irrelevant" for all types of 3386 negotiation. However the negotiation is not considered as failed if 3387 the answer is "Irrelevant". The "Irrelevant" answer is meant for 3388 those cases in which several keys are presented by a proposing 3389 party but the selection made by the acceptor for one of the keys 3390 makes other keys irrelevant. The following example illustrates the 3391 use of "Irrelevant": 3393 I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192 3394 T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant 3396 I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb) 3397 T->I X#vkey1=None,X#vkey2=Irrelevant 3399 Any key not understood by the acceptor may be ignored by the 3400 acceptor without affecting the basic function. However, the answer 3401 for a key not understood MUST be key=NotUnderstood. Note that 3402 NotUnderstood is a valid answer for both declarative and negotiated 3403 keys. The general iSCSI philosophy is that comprehension precedes 3404 processing for any iSCSI key. A proposer of an iSCSI key, 3405 negotiated or declarative, in a text key exchange MUST thus be able 3406 to properly handle a NotUnderstood response. 3408 The proper way to handle a NotUnderstood response depends on where 3409 the key is specified and whether the key is declarative vs. 3410 negotiated. All keys defined in [RFC3720] MUST be supported by all 3411 compliant implementations; a NotUnderstood answer on any of the 3412 [RFC3720] keys therefore MUST be considered a protocol error and 3413 handled accordingly. For all other later keys, a NotUnderstood 3414 answer concludes the negotiation for a negotiated key whereas for a 3415 declarative key, a NotUnderstood answer simply informs the declarer 3416 of a lack of comprehension by the receiver. 3418 In either case, a NotUnderstood answer always requires that the 3419 protocol behavior associated with that key not be used within the 3420 scope of the key (connection/session) by either side. 3422 The constants "None", "Reject", "Irrelevant", and "NotUnderstood" 3423 are reserved and MUST ONLY be used as described here. Violation of 3424 this rule is a protocol error (in particular the use of "Reject", 3425 "Irrelevant", and "NotUnderstood" as proposed values). 3427 Reject or Irrelevant are legitimate negotiation options where 3428 allowed but their excessive use is discouraged. A negotiation is 3429 considered complete when the acceptor has sent the key value pair 3430 even if the value is "Reject", "Irrelevant", or "NotUnderstood". 3431 Sending the key again would be a re-negotiation and is forbidden 3432 for many keys. 3434 If the acceptor sends "Reject" as an answer the negotiated key is 3435 left at its current value (or default if no value was set). If the 3436 current value is not acceptable to the proposer on the connection 3437 or to the session it is sent, the proposer MAY choose to terminate 3438 the connection or session. 3440 All keys in this document, except for the X extension formats, MUST 3441 be supported by iSCSI initiators and targets when used as specified 3442 here. If used as specified, these keys MUST NOT be answered with 3443 NotUnderstood. 3445 Implementers may introduce new keys by prefixing them with X- 3446 followed by their (reversed) domain name, or with new keys 3447 registered with IANA prefixing them with X#. For example, the 3448 entity owning the domain example.com can issue: 3450 X-com.example.bar.foo.do_something=3 3452 or a new registered key may be used as in: 3454 X#SuperCalyPhraGilistic=Yes 3456 Implementers MAY also introduce new values, but ONLY for new keys 3457 or authentication methods (see Section 11 - "iSCSI Security Text 3458 Keys and Authentication Methods"), or digests (see Section 12.1 - 3459 "HeaderDigest and DataDigest"). 3461 Whenever parameter action or acceptance are dependent on other 3462 parameters, the dependency rules and parameter sequence must be 3463 specified with the parameters. 3465 In the Login Phase (see Login Phase), every stage is a separate 3466 negotiation. In the FullFeaturePhase, a Text Request Response 3467 sequence is a negotiation. Negotiations MUST be handled as atomic 3468 operations. For example, all negotiated values go into effect after 3469 the negotiation concludes in agreement or are ignored if the 3470 negotiation fails. 3472 Some parameters may be subject to integrity rules (e.g., parameter- 3473 x must not exceed parameter-y or parameter-u not 1 implies 3474 parameter-v be Yes). Whenever required, integrity rules are 3475 specified with the keys. Checking for compliance with the integrity 3476 rule must only be performed after all the parameters are available 3477 (the existent and the newly negotiated). An iSCSI target MUST 3478 perform integrity checking before the new parameters take effect. 3479 An initiator MAY perform integrity checking. 3481 An iSCSI initiator or target MAY terminate a negotiation that does 3482 not end within a reasonable time or number of exchanges. 3484 6.2.1. List negotiations 3486 In list negotiation, the originator sends a list of values (which 3487 may include "None") in its order of preference. 3489 The responding party MUST respond with the same key and the first 3490 value that it supports (and is allowed to use for the specific 3491 originator) selected from the originator list. 3493 The constant "None" MUST always be used to indicate a missing 3494 function. However, "None" is only a valid selection if it is 3495 explicitly proposed. 3497 If an acceptor does not understand any particular value in a list, 3498 it MUST ignore it. If an acceptor does not support, does not 3499 understand, or is not allowed to use any of the proposed options 3500 with a specific originator, it may use the constant "Reject" or 3501 terminate the negotiation. The selection of a value not proposed 3502 MUST be handled as a protocol error. 3504 6.2.2. Simple-value Negotiations 3506 For simple-value negotiations, the accepting party MUST answer with 3507 the same key. The value it selects becomes the negotiation result. 3509 Proposing a value not admissible (e.g., not within the specified 3510 bounds) MAY be answered with the constant "Reject" or the acceptor 3511 MAY select an admissible value. 3513 The selection, by the acceptor, of a value not admissible under the 3514 selection rules is considered a protocol error. The selection rules 3515 are key-specific. 3517 For a numerical range the value selected must be an integer within 3518 the proposed range or "Reject" (if the range is unacceptable). 3520 For Boolean negotiations (i.e., keys taking the values Yes or No), 3521 the accepting party MUST answer with the same key and the result of 3522 the negotiation when the received value does not determine that 3523 result by itself. The last value transmitted becomes the 3524 negotiation result. The rules for selecting the value to answer 3525 with are expressed as Boolean functions of the value received, and 3526 the value that the accepting party would have selected if given a 3527 choice. 3529 Specifically, the two cases in which answers are OPTIONAL are: 3531 - The Boolean function is "AND" and the value "No" is received. 3532 The outcome of the negotiation is "No". 3534 - The Boolean function is "OR" and the value "Yes" is received. 3535 The outcome of the negotiation is "Yes". 3537 Responses are REQUIRED in all other cases, and the value chosen and 3538 sent by the acceptor becomes the outcome of the negotiation. 3540 6.3. Login Phase 3542 The Login Phase establishes an iSCSI connection between an 3543 initiator and a target; it creates also a new session or associates 3544 the connection to an existing session. The Login Phase sets the 3545 iSCSI protocol parameters, security parameters, and authenticates 3546 the initiator and target to each other. 3548 The Login Phase is only implemented via Login request and 3549 responses. The whole Login Phase is considered as a single task and 3550 has a single Initiator Task Tag (similar to the linked SCSI 3551 commands). 3553 There MUST NOT be more than one outstanding Login Request, or Login 3554 Response on an iSCSI connection. An outstanding PDU in this 3555 context is one that has not been acknowledged by the remote iSCSI 3556 side. 3558 The default MaxRecvDataSegmentLength is used during Login. 3560 The Login Phase sequence of requests and responses proceeds as 3561 follows: 3563 - Login initial request 3565 - Login partial response (optional) 3567 - More Login requests and responses (optional) 3569 - Login Final-Response (mandatory) 3571 The initial login request of any connection MUST include the 3572 InitiatorName key=value pair. The initial login request of the 3573 first connection of a session MAY also include the SessionType 3574 key=value pair. For any connection within a session whose type is 3575 not "Discovery", the first login request MUST also include the 3576 TargetName key=value pair. 3578 The Login Final-response accepts or rejects the Login request. 3580 The Login Phase MAY include a SecurityNegotiation stage and a 3581 LoginOperationalNegotiation stage and MUST include at least one of 3582 them, but the included stage MAY be empty except for the mandatory 3583 names. 3585 The login requests and responses contain a field (CSG) that 3586 indicates the current negotiation stage (SecurityNegotiation or 3587 LoginOperationalNegotiation). If both stages are used, the 3588 SecurityNegotiation MUST precede the LoginOperationalNegotiation. 3590 Some operational parameters can be negotiated outside the login 3591 through Text requests and responses. 3593 Security MUST be completely negotiated within the Login Phase. The 3594 use of underlying IPsec security is specified in Chapter 8 and in 3595 [RFC3723]. iSCSI support for security within the protocol only 3596 consists of authentication in the Login Phase. 3598 In some environments, a target or an initiator is not interested in 3599 authenticating its counterpart. It is possible to bypass 3600 authentication through the Login request and response. 3602 The initiator and target MAY want to negotiate iSCSI authentication 3603 parameters. Once this negotiation is completed, the channel is 3604 considered secure. 3606 Most of the negotiation keys are only allowed in a specific stage. 3607 The SecurityNegotiation keys appear in Chapter 11 and the 3608 LoginOperationalNegotiation keys appear in Chapter 12. Only a 3609 limited set of keys (marked as Any-Stage in Chapter 12) may be used 3610 in any of the two stages. 3612 Any given Login request or response belongs to a specific stage; 3613 this determines the negotiation keys allowed with the request or 3614 response. It is considered to be a protocol error to send a key not 3615 allowed in the current stage. 3617 Stage transition is performed through a command exchange 3618 (request/response) that carries the T bit and the same CSG code. 3619 During this exchange, the next stage is selected by the target 3620 through the "next stage" code (NSG). The selected NSG MUST NOT 3621 exceed the value stated by the initiator. The initiator can request 3622 a transition whenever it is ready, but a target can only respond 3623 with a transition after one is proposed by the initiator. 3625 In a negotiation sequence, the T bit settings in one pair of login 3626 request-responses have no bearing on the T bit settings of the next 3627 pair. An initiator that has a T bit set to 1 in one pair and is 3628 answered with a T bit setting of 0 may issue the next request with 3629 T bit set to 0. 3631 When a transition is requested by the initiator and acknowledged by 3632 the target, both the initiator and target switch to the selected 3633 stage. 3635 Targets MUST NOT submit parameters that require an additional 3636 initiator login request in a login response with the T bit set to 3637 1. 3639 Stage transitions during login (including entering and exit) are 3640 only possible as outlined in the following table: 3642 +-----------------------------------------------------------+ 3643 |From To -> | Security | Operational | FullFeature | 3644 | | | | | | 3645 | V | | | | 3646 +-----------------------------------------------------------+ 3647 | (start) | yes | yes | no | 3648 +-----------------------------------------------------------+ 3649 | Security | no | yes | yes | 3650 +-----------------------------------------------------------+ 3651 | Operational | no | no | yes | 3652 +-----------------------------------------------------------+ 3654 The Login Final-Response that accepts a Login Request can only come 3655 as a response to a Login request with the T bit set to 1, and both 3656 the request and response MUST indicate FullFeaturePhase as the next 3657 phase via the NSG field. 3659 Neither the initiator nor the target should attempt to declare or 3660 negotiate a parameter more than once during login except for 3661 responses to specific keys that explicitly allow repeated key 3662 declarations (e.g., TargetAddress). An attempt to 3663 renegotiate/redeclare parameters not specifically allowed MUST be 3664 detected by the initiator and target. If such an attempt is 3665 detected by the target, the target MUST respond with Login reject 3666 (initiator error); if detected by the initiator, the initiator MUST 3667 drop the connection. 3669 6.3.1. Login Phase Start 3671 The Login Phase starts with a login request from the initiator to 3672 the target. The initial login request includes: 3674 -Protocol version supported by the initiator. 3676 -iSCSI Initiator Name and iSCSI Target Name 3678 -ISID, TSIH, and connection Ids 3680 -Negotiation stage that the initiator is ready to enter. 3682 A login may create a new session or it may add a connection to an 3683 existing session. Between a given iSCSI Initiator Node (selected 3684 only by an InitiatorName) and a given iSCSI target defined by an 3685 iSCSI TargetName and a Target Portal Group Tag, the login results 3686 are defined by the following table: 3688 +------------------------------------------------------------------ 3689 + 3690 |ISID | TSIH | CID | Target action 3691 | 3692 +------------------------------------------------------------------ 3693 + 3694 |new | non-zero | any | fail the login 3695 | 3696 | | | | ("session does not exist") 3697 | 3698 +------------------------------------------------------------------ 3699 + 3700 |new | zero | any | instantiate a new session 3701 | 3702 +------------------------------------------------------------------ 3703 + 3704 |existing | zero | any | do session reinstatement 3705 | 3706 | | | | (see Section 6.3.5) 3707 | +---------------------------------------------------------------- 3708 --+ 3709 |existing | non-zero | new | add a new connection to 3710 | 3711 | | existing | | the session 3712 | 3713 +------------------------------------------------------------------ 3714 + 3715 |existing | non-zero |existing| do connection 3716 reinstatement| 3717 | | existing | | (see Conne) | 3718 +------------------------------------------------------------------ 3719 + 3720 |existing | non-zero | any | fail the login 3721 | 3722 | | new | | ("session does not exist") 3723 | 3724 +------------------------------------------------------------------ 3725 + 3727 Determination of "existing" or "new" are made by the target. 3729 Optionally, the login request may include: 3731 -Security parameters 3732 OR 3734 -iSCSI operational parameters 3735 AND/OR 3737 -The next negotiation stage that the initiator is ready to 3738 enter. 3740 The target can answer the login in the following ways: 3742 -Login Response with Login reject. This is an immediate 3743 rejection from the target that causes the connection to 3744 terminate and the session to terminate if this is the first 3745 (or only) connection of a new session. The T bit and the CSG 3746 and NSG fields are reserved. 3748 -Login Response with Login accept as a final response (T bit 3749 set to 1 and the NSG in both request and response are set to 3750 FullFeaturePhase). The response includes the protocol version 3751 supported by the target and the session ID, and may include 3752 iSCSI operational or security parameters (that depend on the 3753 current stage). 3755 -Login Response with Login Accept as a partial response (NSG 3756 not set to FullFeaturePhase in both request and response) 3757 that indicates the start of a negotiation sequence. The 3758 response includes the protocol version supported by the 3759 target and either security or iSCSI parameters (when no 3760 security mechanism is chosen) supported by the target. 3762 If the initiator decides to forego the SecurityNegotiation stage, 3763 it issues the Login with the CSG set to LoginOperationalNegotiation 3764 and the target may reply with a Login Response that indicates that 3765 it is unwilling to accept the connection (see Section 10.13 - 3766 "Login Response") without SecurityNegotiation and will terminate 3767 the connection with a response of Authentication failure (see 3768 Section 10.13.5 - "Status-Class and Status-Detail"). 3770 If the initiator is willing to negotiate iSCSI security, but is 3771 unwilling to make the initial parameter proposal and may accept a 3772 connection without iSCSI security, it issues the Login with the T 3773 bit set to 1, the CSG set to SecurityNegotiation, and NSG set to 3774 LoginOperationalNegotiation. If the target is also ready to skip 3775 security, the login response only contains the TargetPortalGroupTag 3776 key (see Section 12.9 - "TargetPortalGroupTag"), the T bit set to 3777 1, the CSG set to SecurityNegotiation, and NSG set to 3778 LoginOperationalNegotiation. 3780 An initiator that chooses to operate without iSCSI security and 3781 with all the operational parameters taking the default values 3782 issues the Login with the T bit set to 1, the CSG set to 3783 LoginOperationalNegotiation, and NSG set to FullFeaturePhase. If 3784 the target is also ready to forego security and can finish its 3785 LoginOperationalNegotiation, the Login response has T bit set to 1, 3786 the CSG set to LoginOperationalNegotiation, and NSG set to 3787 FullFeaturePhase in the next stage. 3789 During the Login Phase the iSCSI target MUST return the 3790 TargetPortalGroupTag key with the first Login Response PDU with 3791 which it is allowed to do so (i.e., the first Login Response issued 3792 after the first Login Request with the C bit set to 0) for all 3793 session types. The TargetPortalGroupTag key value indicates the 3794 iSCSI portal group servicing the Login Request PDU. If the 3795 reconfiguration of iSCSI portal groups is a concern in a given 3796 environment, the iSCSI initiator should use this key to ascertain 3797 that it had indeed initiated the Login Phase with the intended 3798 target portal group. 3800 6.3.2. iSCSI Security Negotiation 3802 The security exchange sets the security mechanism and authenticates 3803 the initiator user and the target to each other. The exchange 3804 proceeds according to the authentication method chosen in the 3805 negotiation phase and is conducted using the login requests' and 3806 responses' key=value parameters. 3808 An initiator directed negotiation proceeds as follows: 3810 -The initiator sends a login request with an ordered list of 3811 the options it supports (authentication algorithm). The 3812 options are listed in the initiator's order of preference. 3813 The initiator MAY also send private or public extension 3814 options. 3816 -The target MUST reply with the first option in the list it 3817 supports and is allowed to use for the specific initiator 3818 unless it does not support any in which case it MUST answer 3819 with "Reject" (see Text Mode Negotiation). The parameters are 3820 encoded in UTF8 as key=value. For security parameters, see 3821 Chapter 11. 3823 -When the initiator considers that it is ready to conclude the 3824 SecurityNegotiation stage, it sets the T bit to 1 and the NSG 3825 to what it would like the next stage to be. The target will 3826 then set the T bit to 1 and set NSG to the next stage in the 3827 Login response when it finishes sending its security keys. 3829 The next stage selected will be the one the target selected. 3830 If the next stage is FullFeaturePhase, the target MUST 3831 respond with a Login Response with the TSIH value. 3833 If the security negotiation fails at the target, then the target 3834 MUST send the appropriate Login Response PDU. If the security 3835 negotiation fails at the initiator, the initiator SHOULD close the 3836 connection. 3838 It should be noted that the negotiation might also be directed by 3839 the target if the initiator does support security, but is not ready 3840 to direct the negotiation (propose options). 3842 6.3.3. Operational Parameter Negotiation During the Login Phase 3844 Operational parameter negotiation during the login MAY be done: 3846 - Starting with the first Login request if the initiator does 3847 not propose any security/ integrity option. 3849 - Starting immediately after the security negotiation if the 3850 initiator and target perform such a negotiation. 3852 Operational parameter negotiation MAY involve several Login 3853 request-response exchanges started and terminated by the initiator. 3854 The initiator MUST indicate its intent to terminate the negotiation 3855 by setting the T bit to 1; the target sets the T bit to 1 on the 3856 last response. 3858 If the target responds to a Login request that has the T bit set to 3859 1 with a Login response that has the T bit set to 0, the initiator 3860 should keep sending the Login request (even empty) with the T bit 3861 set to 1, while it still wants to switch stage, until it receives 3862 the Login Response that has the T bit set to 1 or it receives a key 3863 that requires it to set the T bit to 0. 3865 Some session specific parameters can only be specified during the 3866 Login Phase of the first connection of a session (i.e., begun by a 3867 login request that contains a zero-valued TSIH) - the leading Login 3868 Phase (e.g., the maximum number of connections that can be used for 3869 this session). 3871 A session is operational once it has at least one connection in 3872 FullFeaturePhase. New or replacement connections can only be added 3873 to a session after the session is operational. 3875 For operational parameters, see Chapter 12. 3877 6.3.4. Connection Reinstatement 3879 Connection reinstatement is the process of an initiator logging in 3880 with a ISID-TSIH-CID combination that is possibly active from the 3881 target's perspective, which causes the implicit logging out of the 3882 connection corresponding to the CID and reinstating a new Full 3883 Feature Phase iSCSI connection in its place (with the same CID). 3884 Thus, the TSIH in the Login Request PDU MUST be non-zero and CID 3885 does not change during a connection reinstatement. The Login 3886 request performs the logout function of the old connection if an 3887 explicit logout was not performed earlier. In sessions with a 3888 single connection, this may imply the opening of a second 3889 connection with the sole purpose of cleaning up the first. Targets 3890 MUST support opening a second connection even when they do not 3891 support multiple connections in Full Feature Phase if 3892 ErrorRecoveryLevel is 2 and SHOULD support opening a second 3893 connection if ErrorRecoveryLevel is less than 2. 3895 If the operational ErrorRecoveryLevel is 2, connection 3896 reinstatement enables future task reassignment. If the operational 3897 ErrorRecoveryLevel is less than 2, connection reinstatement is the 3898 replacement of the old CID without enabling task reassignment. In 3899 this case, all the tasks that were active on the old CID must be 3900 immediately terminated without further notice to the initiator. 3902 The initiator connection state MUST be CLEANUP_WAIT (section 7.1.3) 3903 when the initiator attempts a connection reinstatement. 3905 In practical terms, in addition to the implicit logout of the old 3906 connection, reinstatement is equivalent to a new connection login. 3908 6.3.5. Session Reinstatement, Closure, and Timeout 3910 Session reinstatement is the process of the initiator logging in 3911 with an ISID that is possibly active from the target's perspective. 3912 Thus implicitly logging out the session that corresponds to the 3913 ISID and reinstating a new iSCSI session in its place (with the 3914 same ISID). Therefore, the TSIH in the Login PDU MUST be zero to 3915 signal session reinstatement. Session reinstatement causes all the 3916 tasks that were active on the old session to be immediately 3917 terminated by the target without further notice to the initiator. 3919 The initiator session state MUST be FAILED (Section 7.3 - "Session 3920 State Diagrams") when the initiator attempts a session 3921 reinstatement. 3923 Session closure is an event defined to be one of the following: 3925 - A successful "session close" logout. 3927 - A successful "connection close" logout for the last Full 3928 Feature Phase connection when no other connection in the 3929 session is waiting for cleanup (Section 7.2 - "Connection 3930 Cleanup State Diagram for Initiators and Targets") and no 3931 tasks in the session are waiting for reassignment. 3933 Session timeout is an event defined to occur when the last 3934 connection state timeout expires and no tasks are waiting for 3935 reassignment. This takes the session to the FREE state (N6 3936 transition in the session state diagram). 3938 6.3.5.1. Loss of Nexus Notification 3940 The iSCSI layer provides the SCSI layer with the "I_T nexus loss" 3941 notification when any one of the following events happens: 3943 Successful completion of session reinstatement. 3944 Session closure event. 3946 Session timeout event. 3948 Certain SCSI object clearing actions may result due to the 3949 notification in the SCSI end nodes, as documented in Appendix F. - 3950 Clearing Effects of Various Events on Targets. 3952 6.3.6. Session Continuation and Failure 3954 Session continuation is the process by which the state of a 3955 preexisting session continues to be used by connection 3956 reinstatement (Section 6.3.4), or by adding a connection with a new 3957 CID. Either of these actions associates the new transport 3958 connection with the session state. 3960 Session failure is an event where the last Full Feature Phase 3961 connection reaches the CLEANUP_WAIT state (Section 8.2), or 3962 completes a successful recovery logout thus causing all active 3963 tasks (that are formerly allegiant to the connection) to start 3964 waiting for task reassignment. 3966 6.4. Operational Parameter Negotiation Outside the Login Phase 3968 Some operational parameters MAY be negotiated outside (after) the 3969 Login Phase. 3971 Parameter negotiation in Full Feature Phase is done through Text 3972 requests and responses. Operational parameter negotiation MAY 3973 involve several Text request-response exchanges, which the 3974 initiator always starts, terminates, and uses the same Initiator 3975 Task Tag. The initiator MUST indicate its intent to terminate the 3976 negotiation by setting the F bit to 1; the target sets the F bit to 3977 1 on the last response. 3979 If the target responds to a Text request with the F bit set to 1 3980 with a Text response with the F bit set to 0 , the initiator should 3981 keep sending the Text request (even empty) with the F bit set to 1, 3982 while it still wants to finish the negotiation, until it receives 3983 the Text response with the F bit set to 1. Responding to a Text 3984 request with the F bit set to 1 with an empty (no key=value pairs) 3985 response with the F bit set to 0 is discouraged. 3987 Targets MUST NOT submit parameters that require an additional 3988 initiator Text request in a Text response with the F bit set to 1. 3990 In a negotiation sequence, the F bit settings in one pair of Text 3991 request-responses have no bearing on the F bit settings of the next 3992 pair. An initiator that has the F bit set to 1 in a request and is 3993 being answered with an F bit setting of 0 may issue the next 3994 request with the F bit set to 0. 3996 Whenever the target responds with the F bit set to 0, it MUST set 3997 the Target Transfer Tag to a value other than the default 3998 0xffffffff. 4000 An initiator MAY reset an operational parameter negotiation by 4001 issuing a Text request with the Target Transfer Tag set to the 4002 value 0xffffffff after receiving a response with the Target 4003 Transfer Tag set to a value other than 0xffffffff. A target may 4004 reset an operational parameter negotiation by answering a Text 4005 request with a Reject PDU. 4007 Neither the initiator nor the target should attempt to declare or 4008 negotiate a parameter more than once during any negotiation 4009 sequence, except for responses to specific keys that explicitly 4010 allow repeated key declarations (e.g., TargetAddress). If detected 4011 by the target, this MUST result in a Reject PDU with a reason of 4012 "protocol error". The initiator MUST reset the negotiation as 4013 outlined above. 4015 Parameters negotiated by a text exchange negotiation sequence only 4016 become effective after the negotiation sequence is completed. 4018 7. iSCSI Error Handling and Recovery 4020 7.1. Overview 4022 7.1.1. Background 4024 The following two considerations prompted the design of much of the 4025 error recovery functionality in iSCSI: 4027 An iSCSI PDU may fail the digest check and be dropped, despite 4028 being received by the TCP layer. The iSCSI layer must 4029 optionally be allowed to recover such dropped PDUs. 4031 A TCP connection may fail at any time during the data transfer. 4032 All the active tasks must optionally be allowed to be 4033 continued on a different TCP connection within the same 4034 session. 4036 Implementations have considerable flexibility in deciding what 4037 degree of error recovery to support, when to use it and by which 4038 mechanisms to achieve the required behavior. Only the externally 4039 visible actions of the error recovery mechanisms must be 4040 standardized to ensure interoperability. 4042 This chapter describes a general model for recovery in support of 4043 interoperability. See Appendix E. - "Algorithmic Presentation of 4044 Error Recovery Classes" for further detail on how the described 4045 model may be implemented. Compliant implementations do not have to 4046 match the implementation details of this model as presented, but 4047 the external behavior of such implementations must correspond to 4048 the externally observable characteristics of the presented model. 4050 7.1.2. Goals 4052 The major design goals of the iSCSI error recovery scheme are as 4053 follows: 4055 Allow iSCSI implementations to meet different requirements 4056 by defining a collection of error recovery mechanisms that 4057 implementations may choose from. 4058 Ensure interoperability between any two implementations 4059 supporting different sets of error recovery capabilities. 4061 Define the error recovery mechanisms to ensure command 4062 ordering even in the face of errors, for initiators that 4063 demand ordering. 4064 Do not make additions in the fast path, but allow moderate 4065 complexity in the error recovery path. 4066 Prevent both the initiator and target from attempting to 4067 recover the same set of PDUs at the same time. For example, 4068 there must be a clear "error recovery functionality 4069 distribution" between the initiator and target. 4071 7.1.3. Protocol Features and State Expectations 4073 The initiator mechanisms defined in connection with error recovery 4074 are: 4076 NOP-OUT to probe sequence numbers of the target (Section 10.18) 4077 Command retry (Section 7.2.1) 4078 Recovery R2T support (Section 7.8) 4079 Requesting retransmission of status/data/R2T using the SNACK 4080 facility (section 10.16) 4081 Acknowledging the receipt of the data (section 10.16) 4082 Reassigning the connection allegiance of a task to a 4083 different TCP connection (Section 7.2.2) 4084 Terminating the entire iSCSI session to start afresh (Session 4085 Recovery) 4087 The target mechanisms defined in connection with error recovery 4088 are: 4090 NOP-IN to probe sequence numbers of the initiator (section 4091 10.19) 4092 Requesting retransmission of data using the recovery R2T 4093 feature (iSCSI Erro) 4094 SNACK support (section 10.16) 4095 Requesting that parts of read data be acknowledged (section 4096 10.7.2) 4097 Allegiance reassignment support (Section 7.2.2) 4098 Terminating the entire iSCSI session to force the initiator 4099 to start over (Session Recovery) 4101 For any outstanding SCSI command, it is assumed that iSCSI, in 4102 conjunction with SCSI at the initiator, is able to keep enough 4103 information to be able to rebuild the command PDU, and that 4104 outgoing data is available (in host memory) for retransmission 4105 while the command is outstanding. It is also assumed that at the 4106 target, incoming data (read data) MAY be kept for recovery or it 4107 can be reread from a device server. 4109 It is further assumed that a target will keep the "status & sense" 4110 for a command it has executed if it supports status retransmission. 4111 A target that agrees to support data retransmission is expected to 4112 be prepared to retransmit the outgoing data (i.e., Data-In) on 4113 request until either the status for the completed command is 4114 acknowledged, or the data in question has been separately 4115 acknowledged. 4117 7.1.4. Recovery Classes 4119 iSCSI enables the following classes of recovery (in the order of 4120 increasing scope of affected iSCSI tasks): 4122 - Within a command (i.e., without requiring command restart). 4124 - Within a connection (i.e., without requiring the connection 4125 to be rebuilt, but perhaps requiring command restart). 4127 - Connection recovery (i.e., perhaps requiring connections to 4128 be rebuilt and commands to be reissued). 4130 - Session recovery. 4132 The recovery scenarios detailed in the rest of this section are 4133 representative rather than exclusive. In every case, they detail 4134 the lowest class recovery that MAY be attempted. The implementer is 4135 left to decide under which circumstances to escalate to the next 4136 recovery class and/or what recovery classes to implement. Both the 4137 iSCSI target and initiator MAY escalate the error handling to an 4138 error recovery class, which impacts a larger number of iSCSI tasks 4139 in any of the cases identified in the following discussion. 4141 In all classes, the implementer has the choice of deferring errors 4142 to the SCSI initiator (with an appropriate response code), in which 4143 case the task, if any, has to be removed from the target and all 4144 the side-effects, such as ACA, must be considered. 4146 Use of within-connection and within-command recovery classes MUST 4147 NOT be attempted before the connection is in Full Feature Phase. 4149 In the detailed description of the recover classes the 4150 mandating terms (MUST, SHOULD, MAY, etc.) indicate normative 4151 actions to be executed if the recovery class is supported and used. 4153 7.1.4.1. Recovery Within-command 4155 At the target, the following cases lend themselves to within- 4156 command recovery: 4158 - Lost data PDU - realized through one of the following: 4160 Data digest error - dealt with as specified in Section 7.8, 4161 using the option of a recovery R2T. 4162 Sequence reception timeout (no data or partial-data-and-no-F- 4163 bit) - considered an implicit sequence error and dealt with 4164 as specified in Section 7.9, using the option of a recovery 4165 R2T. 4166 Header digest error, which manifests as a sequence reception 4167 timeout or a sequence error - dealt with as specified in 4168 Section 7.9, using the option of a recovery R2T. 4170 At the initiator, the following cases lend themselves to within- 4171 command recovery: 4173 Lost data PDU or lost R2T - realized through one of the 4174 following: 4176 Data digest error - dealt with as specified in Section 7.8, 4177 using the option of a SNACK. 4178 Sequence reception timeout (no status) or response reception 4179 timeout - dealt with as specified in Section 7.9, using the 4180 option of a SNACK. 4182 Header digest error, which manifests as a sequence reception 4183 timeout or a sequence error - dealt with as specified in 4184 Section 7.9, using the option of a SNACK. 4186 To avoid a race with the target, which may already have a recovery 4187 R2T or a termination response on its way, an initiator SHOULD NOT 4188 originate a SNACK for an R2T based on its internal timeouts (if 4189 any). Recovery in this case is better left to the target. 4191 The timeout values used by the initiator and target are outside the 4192 scope of this document. Sequence reception timeout is generally a 4193 large enough value to allow the data sequence transfer to be 4194 complete. 4196 7.1.4.2. Recovery Within-connection 4198 At the initiator, the following cases lend themselves to within- 4199 connection recovery: 4201 - Requests not acknowledged for a long time. Requests are 4202 acknowledged explicitly through ExpCmdSN or implicitly by 4203 receiving data and/or status. The initiator MAY retry non- 4204 acknowledged commands as specified in Retry an. 4206 - Lost iSCSI numbered Response. It is recognized by either 4207 identifying a data digest error on a Response PDU or a Data- 4208 In PDU carrying the status, or by receiving a Response PDU 4209 with a higher StatSN than expected. In the first case, digest 4210 error handling is done as specified in Section 7.8 using the 4211 option of a SNACK. In the second case, sequence error 4212 handling is done as specified in Section 7.9, using the 4213 option of a SNACK. 4215 At the target, the following cases lend themselves to within- 4216 connection recovery: 4218 - Status/Response not acknowledged for a long time. The target 4219 MAY issue a NOP-IN (with a valid Target Transfer Tag or 4220 otherwise) that carries the next status sequence number it is 4221 going to use in the StatSN field. This helps the initiator 4222 detect any missing StatSN(s) and issue a SNACK for the 4223 status. 4225 The timeout values used by the initiator and the target are outside 4226 the scope of this document. 4228 7.1.4.3. Connection Recovery 4230 At an iSCSI initiator, the following cases lend themselves to 4231 connection recovery: 4233 - TCP connection failure: The initiator MUST close the 4234 connection. It then MUST either implicitly or explicitly 4235 logout the failed connection with the reason code "remove the 4236 connection for recovery" and reassign connection allegiance 4237 for all commands still in progress associated with the failed 4238 connection on one or more connections (some or all of which 4239 MAY be newly established connections) using the "Task 4240 reassign" task management function (see Section 10.5.1 - 4241 "Function"). For an initiator, a command is in progress as 4242 long as it has not received a response or a Data-In PDU 4243 including status. 4245 Note: The logout function is mandatory. However, a new 4246 connection establishment is only mandatory if the failed 4247 connection was the last or only connection in the session. 4249 - Receiving an Asynchronous Message that indicates one or all 4250 connections in a session has been dropped. The initiator 4251 MUST handle it as a TCP connection failure for the 4252 connection(s) referred to in the Message. 4254 At an iSCSI target, the following cases lend themselves to 4255 connection recovery: 4257 - TCP connection failure. The target MUST close the connection 4258 and, if more than one connection is available, the target 4259 SHOULD send an Asynchronous Message that indicates it has 4260 dropped the connection. Then, the target will wait for the 4261 initiator to continue recovery. 4263 7.1.4.4. Session Recovery 4265 Session recovery should be performed when all other recovery 4266 attempts have failed. Very simple initiators and targets MAY 4267 perform session recovery on all iSCSI errors and rely on recovery 4268 on the SCSI layer and above. 4270 Session recovery implies the closing of all TCP connections, 4271 internally aborting all executing and queued tasks for the given 4272 initiator at the target, terminating all outstanding SCSI commands 4273 with an appropriate SCSI service response at the initiator, and 4274 restarting a session on a new set of connection(s) (TCP connection 4275 establishment and login on all new connections). 4277 For possible clearing effects of session recovery on SCSI and iSCSI 4278 objects, refer to Appendix F. - "Clearing Effects of Various Events 4279 on Targets". 4281 7.1.5. Error Recovery Hierarchy 4283 The error recovery classes described so far are organized into a 4284 hierarchy for ease in understanding and to limit the implementation 4285 complexity. With few and well defined recovery levels 4286 interoperability is easier to achieve. The attributes of this 4287 hierarchy are as follows: 4289 Each level is a superset of the capabilities of the previous 4290 level. For example, Level 1 support implies supporting all 4291 capabilities of Level 0 and more. 4292 As a corollary, supporting a higher error recovery level means 4293 increased sophistication and possibly an increase in 4294 resource requirements. 4295 Supporting error recovery level "n" is advertised and 4296 negotiated by each iSCSI entity by exchanging the text key 4297 "ErrorRecoveryLevel=n". The lower of the two exchanged 4298 values is the operational ErrorRecoveryLevel for the 4299 session. 4301 The following diagram represents the error recovery hierarchy. 4303 + 4304 / \ 4305 / 2 \ <-- Connection recovery 4306 +-----+ 4307 / 1 \ <-- Digest failure recovery 4308 +---------+ 4309 / 0 \ <-- Session failure recovery 4310 +-------------+ 4312 The following table lists the error recovery capabilities expected 4313 from the implementations that support each error recovery level. 4315 +-------------------+--------------------------------------------+ 4316 |ErrorRecoveryLevel | Associated Error recovery capabilities | 4317 +-------------------+--------------------------------------------+ 4318 | 0 | Session recovery class | 4319 | | (Session Recovery) | 4320 +-------------------+--------------------------------------------+ 4321 | 1 | Digest failure recovery (See Note below.) | 4322 | | plus the capabilities of ER Level 0 | 4323 +-------------------+--------------------------------------------+ 4324 | 2 | Connection recovery class | 4325 | | (Connection Recovery) | 4326 | | plus the capabilities of ER Level 1 | 4327 +-------------------+--------------------------------------------+ 4329 Note: Digest failure recovery is comprised of two recovery classes: 4330 Within-Connection recovery class (Recovery Within-connection) and 4331 Within-Command recovery class (Recovery Within-command ). 4333 When a defined value of ErrorRecoveryLevel is proposed by an 4334 originator in a text negotiation, the originator MUST support the 4335 functionality defined for the proposed value and additionally, 4336 functionality corresponding to any defined value numerically less 4337 than the proposed. When a defined value of ErrorRecoveryLevel is 4338 returned by a responder in a text negotiation, the responder MUST 4339 support the functionality corresponding to the ErrorRecoveryLevel 4340 it is accepting. 4342 When either party attempts to use error recovery functionality 4343 beyond what is negotiated, the recovery attempts MAY fail unless an 4344 apriori agreement outside the scope of this document exists between 4345 the two parties to provide such support. 4347 Implementations MUST support error recovery level "0", while the 4348 rest are OPTIONAL to implement. In implementation terms, the above 4349 striation means that the following incremental sophistication with 4350 each level is required. 4352 +-------------------+---------------------------------------------+ 4353 |Level transition | Incremental requirement | 4354 +-------------------+---------------------------------------------+ 4355 | 0->1 | PDU retransmissions on the same connection | 4356 +-------------------+---------------------------------------------+ 4357 | 1->2 | Retransmission across connections and | 4358 | | allegiance reassignment | 4359 +-------------------+---------------------------------------------+ 4361 7.2. Retry and Reassign in Recovery 4363 This section summarizes two important and somewhat related iSCSI 4364 protocol features used in error recovery. 4366 7.2.1. Usage of Retry 4368 By resending the same iSCSI command PDU ("retry") in the absence of 4369 a command acknowledgement (by way of an ExpCmdSN update) or a 4370 response, an initiator attempts to "plug" (what it thinks are) the 4371 discontinuities in CmdSN ordering on the target end. Discarded 4372 command PDUs, due to digest errors, may have created these 4373 discontinuities. 4375 Retry MUST NOT be used for reasons other than plugging command 4376 sequence gaps, and in particular, cannot be used for requesting PDU 4377 retransmissions from a target. Any such PDU retransmission requests 4378 for a currently allegiant command in progress may be made using the 4379 SNACK mechanism described in section 10.16, although the usage of 4380 SNACK is OPTIONAL. 4382 If initiators, as part of plugging command sequence gaps as 4383 described above, inadvertently issue retries for allegiant commands 4384 already in progress (i.e., targets did not see the discontinuities 4385 in CmdSN ordering), the duplicate commands are silently ignored by 4386 targets as specified in section 3.2.2.1. 4388 When an iSCSI command is retried, the command PDU MUST carry the 4389 original Initiator Task Tag and the original operational attributes 4390 (e.g., flags, function names, LUN, CDB etc.) as well as the 4391 original CmdSN. The command being retried MUST be sent on the same 4392 connection as the original command unless the original connection 4393 was already successfully logged out. 4395 7.2.2. Allegiance Reassignment 4397 By issuing a "task reassign" task management request (Section 4398 10.5.1 - "Function"), the initiator signals its intent to continue 4399 an already active command (but with no current connection 4400 allegiance) as part of connection recovery. This means that a new 4401 connection allegiance is requested for the command, which seeks to 4402 associate it to the connection on which the task management request 4403 is being issued. Before the allegiance reassignment is attempted 4404 for a task, an implicit or explicit Logout with the reason code 4405 "remove the connection for recovery" ( see section 10.14) MUST be 4406 successfully completed for the previous connection to which the 4407 task was allegiant. 4409 In reassigning connection allegiance for a command, the targets 4410 SHOULD continue the command from its current state. For example, 4411 when reassigning read commands, the target SHOULD take advantage of 4412 the ExpDataSN field provided by the Task Management function 4413 request (which must be set to zero if there was no data transfer) 4414 and bring the read command to completion by sending the remaining 4415 data and sending (or resending) the status. ExpDataSN acknowledges 4416 all data sent up to, but not including, the Data-In PDU and or R2T 4417 with DataSN (or R2TSN) equal to ExpDataSN. However, targets may 4418 choose to send/receive all unacknowledged data or all of the data 4419 on a reassignment of connection allegiance if unable to recover or 4420 maintain accurate an state. Initiators MUST NOT subsequently 4421 request data retransmission through Data SNACK for PDUs numbered 4422 less than ExpDataSN (i.e., prior to the acknowledged sequence 4423 number). For all types of commands, a reassignment request implies 4424 that the task is still considered in progress by the initiator and 4425 the target must conclude the task appropriately if the target 4426 returns the "Function Complete" response to the reassignment 4427 request. This might possibly involve retransmission of 4428 data/R2T/status PDUs as necessary, but MUST involve the 4429 (re)transmission of the status PDU. 4431 It is OPTIONAL for targets to support the allegiance reassignment. 4432 This capability is negotiated via the ErrorRecoveryLevel text key 4433 during the login time. When a target does not support allegiance 4434 reassignment, it MUST respond with a Task Management response code 4435 of "Allegiance reassignment not supported". If allegiance 4436 reassignment is supported by the target, but the task is still 4437 allegiant to a different connection, or a successful recovery 4438 Logout of the previously allegiant connection was not performed, 4439 the target MUST respond with a Task Management response code of 4440 "Task still allegiant". 4442 If allegiance reassignment is supported by the target, the Task 4443 Management response to the reassignment request MUST be issued 4444 before the reassignment becomes effective. 4446 If a SCSI Command that involves data input is reassigned, any SNACK 4447 Tag it holds for a final response from the original connection is 4448 deleted and the default value of 0 MUST be used instead. 4450 7.3. Usage Of Reject PDU in Recovery 4452 Targets MUST NOT implicitly terminate an active task by sending a 4453 Reject PDU for any PDU exchanged during the life of the task. If 4454 the target decides to terminate the task, a Response PDU (SCSI, 4455 Text, Task, etc.) must be returned by the target to conclude the 4456 task. If the task had never been active before the Reject (i.e., 4457 the Reject is on the command PDU), targets should not send any 4458 further responses because the command itself is being discarded. 4460 The above rule means that the initiator can eventually expect a 4461 response on receiving Rejects, if the received Reject is for a PDU 4462 other than the command PDU itself. The non-command Rejects only 4463 have diagnostic value in logging the errors, and they can be used 4464 for retransmission decisions by the initiators. 4466 The CmdSN of the rejected command PDU (if it is a non-immediate 4467 command) MUST NOT be considered received by the target (i.e., a 4468 command sequence gap must be assumed for the CmdSN), even though 4469 the CmdSN of the rejected command PDU may be reliably ascertained. 4470 Upon receiving the Reject, the initiator MUST plug the CmdSN gap in 4471 order to continue to use the session. The gap may be plugged either 4472 by transmitting a command PDU with the same CmdSN, or by aborting 4473 the task (see SCS on how an abort may plug a CmdSN gap). 4475 When a data PDU is rejected and its DataSN can be ascertained, a 4476 target MUST advance ExpDataSN for the current data burst if a 4477 recovery R2T is being generated. The target MAY advance its 4478 ExpDataSN if it does not attempt to recover the lost data PDU. 4480 7.4. Error Recovery Considerations for Discovery Sessions 4482 7.4.1. ErrorRecoveryLevel for Discovery Sessions 4484 The negotiation of the key ErrorRecoveryLevel is not required for 4485 Discovery sessions -- i.e., for sessions that negotiated 4486 "SessionType=Discovery" -- because the default value of 0 is 4487 necessary and sufficient for Discovery sessions. It is however 4488 possible that some legacy iSCSI implementations might attempt to 4489 negotiate the ErrorRecoveryLevel key on Discovery sessions. When 4490 such a negotiation attempt is made by the remote side, a compliant 4491 iSCSI implementation MUST propose a value of 0 (zero) in response. 4492 The operational ErrorRecoveryLevel for Discovery sessions thus MUST 4493 be 0. This naturally follows from the functionality constraints 4494 that Section 4.3 imposes on Discovery sessions. 4496 7.4.2. Reinstatement Semantics for Discovery Sessions 4498 Discovery sessions are intended to be relatively short-lived. 4499 Initiators are not expected to establish multiple Discovery 4500 sessions to the same iSCSI Network Portal. An initiator may use the 4501 same iSCSI Initiator Name and ISID when establishing different 4502 unique sessions with different targets and/or different portal 4503 groups. This behavior is discussed in Section 10.1.1 and is, in 4504 fact, encouraged as conservative reuse of ISIDs. 4506 The ISID RULE in Section 4.4.3 states that there must not be more 4507 than one session with a matching 4-tuple: . While the spirit of the ISID 4509 RULE applies to Discovery sessions the same as it does for Normal 4510 sessions, note that some Discovery sessions differ from the Normal 4511 sessions in two important aspects: 4513 Because Appendix D allows a Discovery session to be established 4514 without specifying a TargetName key in the Login Request PDU 4515 (let us call such a session an "Unnamed" Discovery session), 4516 there is no Target Node context to enforce the ISID RULE. 4518 Portal Groups are defined only in the context of a Target Node. 4519 When the TargetName key is NULL-valued (i.e., not specified), 4520 the TargetPortalGroupTag thus cannot be ascertained to 4521 enforce the ISID RULE. 4523 The following two sections describe each of the two scenarios -- 4524 Named Discovery sessions and Unnamed Discovery sessions. 4526 7.4.2.1. Unnamed Discovery Sessions 4528 For Unnamed Discovery sessions, neither the TargetName nor the 4529 TargetPortalGroupTag is available to the targets in order to 4530 enforce the ISID RULE. So the following rule applies. 4532 UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the 4533 following 4-tuple for Unnamed Discovery sessions: . The following semantics are implied by 4535 this uniqueness requirement. 4537 Targets SHOULD allow concurrent establishment of one Discovery 4538 session with each of its Network Portals by the same initiator port 4539 with a given iSCSI Node Name and an ISID. Each of the concurrent 4540 Discovery sessions, if established by the same initiator port to 4541 other Network Portals, MUST be treated as independent sessions -- 4542 i.e., one session MUST NOT reinstate the other. 4544 A new Unnamed Discovery session that has a matching to an existing Discovery session MUST 4546 reinstate the existing Unnamed Discovery session. Note thus that 4547 only an Unnamed Discovery session may reinstate an Unnamed 4548 Discovery session. 4550 7.4.2.2. Named Discovery Session 4552 For a Named Discovery session, the TargetName key is specified by 4553 the initiator and thus the target can unambiguously ascertain the 4554 TargetPortalGroupTag as well. Since all the four elements of the 4- 4555 tuple are known, the ISID RULE MUST be enforced by targets with no 4556 changes from Section 4.4.3 semantics. A new session with a matching 4557 thus will 4558 reinstate an existing session. Note in this case that any new iSCSI 4559 session (Discovery or Normal) with the matching 4-tuple may 4560 reinstate an existing Named Discovery iSCSI session. 4562 7.4.3. Target PDUs During Discovery 4564 Targets SHOULD NOT send any responses other than a Text Response 4565 and Logout Response on a Discovery session, once in Full Feature 4566 Phase. 4568 Implementation Note: A target may simply drop the connection in a 4569 Discovery session when it would have requested a Logout via an 4570 Async Message on Normal sessions. 4572 7.5. Connection Timeout Management 4574 iSCSI defines two session-global timeout values (in seconds) - 4575 Time2Wait and Time2Retain - that are applicable when an iSCSI Full 4576 Feature Phase connection is taken out of service either 4577 intentionally or by an exception. Time2Wait is the initial "respite 4578 time" before attempting an explicit/implicit Logout for the CID in 4579 question or task reassignment for the affected tasks (if any). 4580 Time2Retain is the maximum time after the initial respite interval 4581 that the task and/or connection state(s) is/are guaranteed to be 4582 maintained on the target to cater to a possible recovery attempt. 4583 Recovery attempts for the connection and/or task(s) SHOULD NOT be 4584 made before Time2Wait seconds, but MUST be completed within 4585 Time2Retain seconds after that initial Time2Wait waiting period. 4587 7.5.1. Timeouts on Transport Exception Events 4589 A transport connection shutdown or a transport reset without any 4590 preceding iSCSI protocol interactions informing the end-points of 4591 the fact causes a Full Feature Phase iSCSI connection to be 4592 abruptly terminated. The timeout values to be used in this case are 4593 the negotiated values of defaultTime2Wait (Section 12.15 - 4594 "DefaultTime2Wait") and DefaultTime2Retain (Section 12.16 - 4595 "DefaultTime2Retain") text keys for the session. 4597 7.5.2. Timeouts on Planned Decommissioning 4599 Any planned decommissioning of a Full Feature Phase iSCSI 4600 connection is preceded by either a Logout Response PDU, or an Async 4601 Message PDU. The Time2Wait and Time2Retain field values (section 4602 10.15) in a Logout Response PDU, and the Parameter2 and Parameter3 4603 fields of an Async Message (AsyncEvent types "drop the connection" 4604 or "drop all the connections"; section 10.9.1) specify the timeout 4605 values to be used in each of these cases. 4607 These timeout values are only applicable for the affected 4608 connection, and the tasks active on that connection. These timeout 4609 values have no bearing on initiator timers (if any) that are 4610 already running on connections or tasks associated with that 4611 session. 4613 7.6. Implicit Termination of Tasks 4615 A target implicitly terminates the active tasks due to iSCSI 4616 protocol dynamics in the following cases: 4618 When a connection is implicitly or explicitly logged out with 4619 the reason code of "Close the connection" and there are 4620 active tasks allegiant to that connection. 4622 When a connection fails and eventually the connection state 4623 times out (state transition M1 in Section 7.2.2 - "State 4624 Transition Descriptions for Initiators and Targets") and 4625 there are active tasks allegiant to that connection. 4627 When a successful Logout with the reason code of "remove the 4628 connection for recovery" is performed while there are active 4629 tasks allegiant to that connection, and those tasks 4630 eventually time out after the Time2Wait and Time2Retain 4631 periods without allegiance reassignment. 4633 When a connection is implicitly or explicitly logged out with 4634 the reason code of "Close the session" and there are active 4635 tasks in that session. 4637 If the tasks terminated in the above cases a), b, c) and d)are SCSI 4638 tasks, they must be internally terminated as if with CHECK 4639 CONDITION status. This status is only meaningful for appropriately 4640 handling the internal SCSI state and SCSI side effects with respect 4641 to ordering because this status is never communicated back as a 4642 terminating status to the initiator. However additional actions may 4643 have to be taken at SCSI level depending on the SCSI context as 4644 defined by the SCSI standards (e.g., queued commands and ACA, UA 4645 for the next command on the I_T nexus in cases a), b), and c) etc. 4646 - see [SAM2] and [SPC3]). 4648 7.7. Format Errors 4650 The following two explicit violations of PDU layout rules are 4651 format errors: 4653 Illegal contents of any PDU header field except the Opcode 4654 (legal values are specified in Section 10 - "iSCSI PDU 4655 Formats"). 4656 Inconsistent field contents (consistent field contents are 4657 specified in Section 10 - "iSCSI PDU Formats"). 4659 Format errors indicate a major implementation flaw in one of the 4660 parties. 4662 When a target or an initiator receives an iSCSI PDU with a format 4663 error, it MUST immediately terminate all transport connections in 4664 the session either with a connection close or with a connection 4665 reset and escalate the format error to session recovery (see 4666 Section Session Recovery). 4668 All initiator-detected PDU construction errors MUST be considered 4669 as format errors. Some examples of such errors are: 4670 - NOP-In with a valid TTT but an invalid LUN 4672 - NOP-In with a valid ITT (i.e., a NOP-In response) and also a 4673 valid TTT 4675 - SCSI Response PDU with Status=CHECK CONDITION, but 4676 DataSegmentLength = 0 4678 7.8. Digest Errors 4680 The discussion of the legal choices in handling digest errors below 4681 excludes session recovery as an explicit option, but either party 4682 detecting a digest error may choose to escalate the error to 4683 session recovery. 4685 When a target or an initiator receives any iSCSI PDU, with a header 4686 digest error, it MUST either discard the header and all data up to 4687 the beginning of a later PDU or close the connection. Because the 4688 digest error indicates that the length field of the header may have 4689 been corrupted, the location of the beginning of a later PDU needs 4690 to be reliably ascertained by other means such as the operation of 4691 a sync and steering layer. 4693 When a target receives any iSCSI PDU with a payload digest error, 4694 it MUST answer with a Reject PDU with a reason code of Data-Digest- 4695 Error and discard the PDU. 4697 - If the discarded PDU is a solicited or unsolicited iSCSI data 4698 PDU (for immediate data in a command PDU, non-data PDU rule 4699 below applies), the target MUST do one of the following: 4701 i) Request retransmission with a recovery R2T. 4702 ii) Terminate the task with a response PDU with a CHECK 4703 CONDITION Status and an iSCSI Condition of "protocol 4704 service CRC error" (Section 10.4.7.2 - "Sense Data"). If 4705 the target chooses to implement this option, it MUST 4706 wait to receive all the data (signaled by a Data PDU 4707 with the final bit set for all outstanding R2Ts) before 4708 sending the response PDU. A task management command 4709 (such as an abort task) from the initiator during this 4710 wait may also conclude the task. 4711 - No further action is necessary for targets if the discarded 4712 PDU is a non-data PDU. In case of immediate data being 4713 present on a discarded command, the immediate data is 4714 implicitly recovered when the task is retried (see Section 4715 7.2.1) followed by the entire data transfer for the task. 4717 When an initiator receives any iSCSI PDU with a payload digest 4718 error, it MUST discard the PDU. 4720 - If the discarded PDU is an iSCSI data PDU, the initiator MUST 4721 do one of the following: 4723 Request the desired data PDU through SNACK. In response to 4724 the SNACK, the target MUST either resend the data 4725 PDU or reject the SNACK with a Reject PDU with a 4726 reason code of "SNACK reject" in which case: 4727 If the status has not already been sent for the command, 4728 the target MUST terminate the command with a CHECK 4729 CONDITION Status and an iSCSI Condition of "SNACK 4730 rejected" (Section 10.4.7.2 - "Sense Data"). 4731 If the status was already sent, no further action is 4732 necessary for the target. The initiator in this 4733 case MUST wait for the status to be received and 4734 then discard it, so as to internally signal the 4735 completion with CHECK CONDITION Status and an 4736 iSCSI Condition of "protocol service CRC error" 4737 (Section 10.4.7.2 - "Sense Data"). 4738 Abort the task and terminate the command with an error. 4740 - If the discarded PDU is a response PDU or an unsolicited PDU 4741 (e.g. Async, Reject), the initiator MUST do one of the 4742 following: 4744 Request PDU retransmission with a status SNACK. 4745 Logout the connection for recovery and continue the tasks 4746 on a different connection instance as described in 4747 Retry an. 4749 Logout to close the connection (abort all the commands 4750 associated with the connection). 4752 Note that an unsolicited PDU carries the next StatSN value on 4753 an iSCSI connection, thereby advancing the StatSN. When an 4754 initiator discards one of these PDUs due to a payload digest 4755 error, the entire PDU including the header MUST be discarded. 4756 Consequently, the initiator MUST treat the exception like a 4757 loss of any other solicited response PDU. 4759 7.9. Sequence Errors 4761 When an initiator receives an iSCSI R2T/data PDU with an out of 4762 order R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that 4763 implies missing data PDU(s), it means that the initiator must have 4764 detected a header or payload digest error on one or more earlier 4765 R2T/data PDUs. The initiator MUST address these implied digest 4766 errors as described in Section 7.8. When a target receives a data 4767 PDU with an out of order DataSN, it means that the target must have 4768 hit a header or payload digest error on at least one of the earlier 4769 data PDUs. The target MUST address these implied digest errors as 4770 described in Section 7.8. 4772 When an initiator receives an iSCSI status PDU with an out of order 4773 StatSN that implies missing responses, it MUST address the one or 4774 more missing status PDUs as described in Section 7.8. As a side 4775 effect of receiving the missing responses, the initiator may 4776 discover missing data PDUs. If the initiator wants to recover the 4777 missing data for a command, it MUST NOT acknowledge the received 4778 responses that start from the StatSN of the relevant command, until 4779 it has completed receiving all the data PDUs of the command. 4781 When an initiator receives duplicate R2TSNs (due to proactive 4782 retransmission of R2Ts by the target) or duplicate DataSNs (due to 4783 proactive SNACKs by the initiator), it MUST discard the duplicates. 4785 7.10. Message Error Checking 4787 In the iSCSI implementations till date, there has been some 4788 uncertainty on the extent to which incoming messages have to be 4789 checked for protocol errors, beyond what is strictly required for 4790 processing the inbound message. This section addresses this 4791 question. 4793 Unless this document requires it, an iSCSI implementation is not 4794 required to do an exhaustive protocol conformance check on an 4795 incoming iSCSI PDU. The iSCSI implementation especially is not 4796 required to double-check the remote iSCSI implementation's 4797 conformance to protocol requirements. 4799 7.11. SCSI Timeouts 4801 An iSCSI initiator MAY attempt to plug a command sequence gap on 4802 the target end (in the absence of an acknowledgement of the command 4803 by way of ExpCmdSN) before the ULP timeout by retrying the 4804 unacknowledged command, as described in Section 7.2. 4806 On a ULP timeout for a command (that carried a CmdSN of n), if the 4807 iSCSI initiator intends to continue the session it MUST abort the 4808 command by either using an appropriate Task Management function 4809 request for the specific command, or a "close the connection" 4810 Logout. When using an ABORT TASK, if the ExpCmdSN is still less 4811 than (n+1), the target may see the abort request while missing the 4812 original command itself due to one of the following reasons: 4814 - Original command was dropped due to digest error. 4816 - Connection on which the original command was sent was 4817 successfully logged out. On logout, the unacknowledged 4818 commands issued on the connection being logged out are 4819 discarded. 4821 If the abort request is received and the original command is 4822 missing, targets MUST consider the original command with that 4823 RefCmdSN to be received and issue a Task Management response with 4824 the response code: "Function Complete". This response concludes the 4825 task on both ends. If the abort request is received and the target 4826 can determine (based on the Referenced Task Tag) that the command 4827 was received and executed and also that the response was sent prior 4828 to the abort, then the target MUST respond with the response code 4829 of "Task Does Not Exist". 4831 7.12. Negotiation Failures 4833 Text request and response sequences, when used to set/negotiate 4834 operational parameters, constitute the negotiation/parameter 4835 setting. A negotiation failure is considered to be one or more of 4836 the following: 4838 - None of the choices, or the stated value, is acceptable to 4839 one of the sides in the negotiation. 4841 - The text request timed out and possibly terminated. 4843 - The text request was answered with a Reject PDU. 4845 The following two rules should be used to address negotiation 4846 failures: 4848 - During Login, any failure in negotiation MUST be considered a 4849 login process failure and the Login Phase must be terminated, 4850 and with it, the connection. If the target detects the 4851 failure, it must terminate the login with the appropriate 4852 login response code. 4854 - A failure in negotiation, while in the Full Feature Phase, 4855 will terminate the entire negotiation sequence that may 4856 consist of a series of text requests that use the same 4857 Initiator Task Tag. The operational parameters of the 4858 session or the connection MUST continue to be the values 4859 agreed upon during an earlier successful negotiation (i.e., 4860 any partial results of this unsuccessful negotiation MUST NOT 4861 take effect and MUST be discarded). 4863 7.13. Protocol Errors 4865 Mapping framed messages over a "stream" connection, such as TCP, 4866 makes the proposed mechanisms vulnerable to simple software framing 4867 errors. On the other hand, the introduction of framing mechanisms 4868 to limit the effects of these errors may be onerous on performance 4869 for simple implementations. Command Sequence Numbers and the above 4870 mechanisms for connection drop and reestablishment help handle this 4871 type of mapping errors. 4873 All violations of iSCSI PDU exchange sequences specified in this 4874 draft are also protocol errors. This category of errors can only 4875 be 4876 addressed by fixing the implementations; iSCSI defines Reject and 4877 response codes to enable this. 4879 7.14. Connection Failures 4881 iSCSI can keep a session in operation if it is able to 4882 keep/establish at least one TCP connection between the initiator 4883 and the target in a timely fashion. Targets and/or initiators may 4884 recognize a failing connection by either transport level means 4885 (TCP), a gap in the command sequence number, a response stream that 4886 is not filled for a long time, or by a failing iSCSI NOP (acting as 4887 a ping). The latter MAY be used periodically to increase the speed 4888 and likelihood of detecting connection failures. Initiators and 4889 targets MAY also use the keep-alive option on the TCP connection to 4890 enable early link failure detection on otherwise idle links. 4892 On connection failure, the initiator and target MUST do one of the 4893 following: 4895 - Attempt connection recovery within the session (Connection 4896 Recovery). 4898 - Logout the connection with the reason code "closes the 4899 connection" (Section 10.14.5 - "Implicit termination of 4900 tasks"), re-issue missing commands, and implicitly terminate 4901 all active commands. This option requires support for the 4902 within-connection recovery class (Recovery Within- 4903 connection). 4905 - Perform session recovery (Session Recovery). 4907 Either side may choose to escalate to session recovery (via the 4908 initiator dropping all the connections, or via an Async Message 4909 that announces the similar intent from a target), and the other 4910 side MUST give it precedence. On a connection failure, a target 4911 MUST terminate and/or discard all of the active immediate commands 4912 regardless of which of the above options is used (i.e., immediate 4913 commands are not recoverable across connection failures). 4915 7.15. Session Errors 4917 If all of the connections of a session fail and cannot be 4918 reestablished in a short time, or if initiators detect protocol 4919 errors repeatedly, an initiator may choose to terminate a session 4920 and establish a new session. 4922 In this case, the initiator takes the following actions: 4924 - Resets or closes all the transport connections. 4926 - Terminates all outstanding requests with an appropriate 4927 response before initiating a new session. If the same I_T 4928 nexus is intended to be reestablished, the initiator MUST 4929 employ session reinstatement (see section 5.3.5). 4931 When the session timeout (the connection state timeout for the last 4932 failed connection) happens on the target, it takes the following 4933 actions: 4935 - Resets or closes the TCP connections (closes the session). 4937 - Terminates all active tasks that were allegiant to the 4938 connection(s) that constituted the session. 4940 A target MUST also be prepared to handle a session reinstatement 4941 request from the initiator, that may be addressing session errors. 4943 8. State Transitions 4945 iSCSI connections and iSCSI sessions go through several well- 4946 defined states from the time they are created to the time they are 4947 cleared. 4949 The connection state transitions are described in two separate but 4950 dependent state diagrams for ease in understanding. The first 4951 diagram, "standard connection state diagram", describes the 4952 connection state transitions when the iSCSI connection is not 4953 waiting for, or undergoing, a cleanup by way of an explicit or 4954 implicit Logout. The second diagram, "connection cleanup state 4955 diagram", describes the connection state transitions while 4956 performing the iSCSI connection cleanup. 4958 The "session state diagram" describes the state transitions an 4959 iSCSI session would go through during its lifetime, and it depends 4960 on the states of possibly multiple iSCSI connections that 4961 participate in the session. 4963 States and transitions are described in text, tables and diagrams. 4964 The diagrams are used for illustration. The text and the tables are 4965 the governing specification. 4967 8.1. Standard Connection State Diagrams 4969 8.1.1. State Descriptions for Initiators and Targets 4971 State descriptions for the standard connection state diagram are as 4972 follows: 4973 -S1: FREE 4974 -initiator: State on instantiation, or after successful 4975 connection closure. 4976 -target: State on instantiation, or after successful 4977 connection closure. 4978 -S2: XPT_WAIT 4979 -initiator: Waiting for a response to its transport 4980 connection establishment request. 4981 -target: Illegal 4982 -S3: XPT_UP 4983 -initiator: Illegal 4984 -target: Waiting for the Login process to commence. 4986 -S4: IN_LOGIN 4987 -initiator: Waiting for the Login process to conclude, 4988 possibly involving several PDU exchanges. 4989 -target: Waiting for the Login process to conclude, possibly 4990 involving several PDU exchanges. 4991 -S5: LOGGED_IN 4992 -initiator: In Full Feature Phase, waiting for all internal, 4993 iSCSI, and transport events. 4994 -target: In Full Feature Phase, waiting for all internal, 4995 iSCSI, and transport events. 4996 -S6: IN_LOGOUT 4997 -initiator: Waiting for a Logout response. 4998 -target: Waiting for an internal event signaling completion 4999 of logout processing. 5000 -S7: LOGOUT_REQUESTED 5001 -initiator: Waiting for an internal event signaling 5002 readiness to proceed with Logout. 5003 -target: Waiting for the Logout process to start after 5004 having requested a Logout via an Async Message. 5005 -S8: CLEANUP_WAIT 5006 -initiator: Waiting for the context and/or resources to 5007 initiate the cleanup processing for this CSM. 5008 -target: Waiting for the cleanup process to start for this 5009 CSM. 5010 8.1.2. State Transition Descriptions for Initiators and Targets 5012 -T1: 5013 -initiator: Transport connect request was made (e.g., TCP 5014 SYN sent). 5015 -target: Illegal 5016 -T2: 5017 -initiator: Transport connection request timed out, a 5018 transport reset was received, or an internal event of 5019 receiving a Logout response (success) on another connection 5020 for a "close the session" Logout request was received. 5021 -target:Illegal 5022 -T3: 5023 -initiator: Illegal 5024 -target: Received a valid transport connection request that 5025 establishes the transport connection. 5026 -T4: 5028 -initiator: Transport connection established, thus prompting 5029 the initiator to start the iSCSI Login. 5030 -target: Initial iSCSI Login request was received. 5031 -T5: 5032 -initiator: The final iSCSI Login response with a Status- 5033 Class of zero was received. 5034 -target: The final iSCSI Login request to conclude the Login 5035 Phase was received, thus prompting the target to send the 5036 final iSCSI Login response with a Status-Class of zero. 5037 -T6: 5038 -initiator: Illegal 5039 -target: Timed out waiting for an iSCSI Login, transport 5040 disconnect indication was received, transport reset was 5041 received, or an internal event indicating a transport 5042 timeout was received. In all these cases, the connection is 5043 to be closed. 5044 -T7: 5045 -initiator - one of the following events caused the 5046 transition: 5047 - The final iSCSI Login response was received with a 5048 non-zero Status-Class. 5049 - Login timed out. 5050 - A transport disconnect indication was received. 5051 - A transport reset was received. 5052 - An internal event indicating a transport timeout was 5053 received. 5054 - An internal event of receiving a Logout response 5055 (success) on another connection for a "close the 5056 session" Logout request was received. 5058 In all these cases, the transport connection is closed. 5060 -target - one of the following events caused the transition: 5061 - The final iSCSI Login request to conclude the Login 5062 Phase was received, prompting the target to send the 5063 final iSCSI Login response with a non-zero Status- 5064 Class. 5065 - Login timed out. 5066 - Transport disconnect indication was received. 5067 - Transport reset was received. 5069 - An internal event indicating a transport timeout was 5070 received . 5071 - On another connection a "close the session" Logout 5072 request was received. 5074 In all these cases, the connection is to be closed. 5075 -T8: 5076 -initiator: An internal event of receiving a Logout response 5077 (success) on another connection for a "close the session" 5078 Logout request was received, thus closing this connection 5079 requiring no further cleanup. 5080 -target: An internal event of sending a Logout response 5081 (success) on another connection for a "close the session" 5082 Logout request was received, or an internal event of a 5083 successful connection/session reinstatement is received, 5084 thus prompting the target to close this connection cleanly. 5085 -T9, T10: 5086 -initiator: An internal event that indicates the readiness 5087 to start the Logout process was received, thus prompting an 5088 iSCSI Logout to be sent by the initiator. 5089 -target: An iSCSI Logout request was received. 5090 -T11, T12: 5091 -initiator: Async PDU with AsyncEvent "Request Logout" was 5092 received. 5093 -target: An internal event that requires the decommissioning 5094 of the connection is received, thus causing an Async PDU 5095 with an AsyncEvent "Request Logout" to be sent. 5096 -T13: 5097 -initiator: An iSCSI Logout response (success) was received, 5098 or an internal event of receiving a Logout response 5099 (success) on another connection for a "close the session" 5100 Logout request was received. 5101 -target: An internal event was received that indicates 5102 successful processing of the Logout, which prompts an iSCSI 5103 Logout response (success) to be sent; an internal event of 5104 sending a Logout response (success) on another connection 5105 for a "close the session" Logout request was received; or an 5106 internal event of a successful connection/session 5107 reinstatement is received. In all these cases, the transport 5108 connection is closed. 5110 -T14: 5111 -initiator: Async PDU with AsyncEvent "Request Logout" was 5112 received again. 5113 -target: Illegal 5114 -T15, T16: 5115 -initiator: One or more of the following events caused this 5116 transition: 5117 -Internal event that indicates a transport connection 5118 timeout was received thus prompting transport RESET or 5119 transport connection closure. 5120 -A transport RESET. 5121 -A transport disconnect indication. 5122 -Async PDU with AsyncEvent "Drop connection" (for this 5123 CID). 5124 -Async PDU with AsyncEvent "Drop all connections". 5125 -target: One or more of the following events caused this 5126 transition: 5127 -Internal event that indicates a transport connection 5128 timeout was received, thus prompting transport RESET or 5129 transport connection closure. 5130 -An internal event of a failed connection/session 5131 reinstatement is received. 5132 -A transport RESET. 5133 -A transport disconnect indication. 5134 -Internal emergency cleanup event was received which 5135 prompts an Async PDU with AsyncEvent "Drop connection" 5136 (for this CID), or event "Drop all connections". 5138 -T17: 5139 -initiator: One or more of the following events caused this 5140 transition: 5141 -Logout response, (failure i.e., a non-zero status) was 5142 received, or Logout timed out. 5143 -Any of the events specified for T15 and T16. 5144 -target: One or more of the following events caused this 5145 transition: 5146 -Internal event that indicates a failure of the Logout 5147 processing was received, which prompts a Logout response 5148 (failure, i.e., a non-zero status) to be sent. 5150 -Any of the events specified for T15 and T16. 5151 -T18: 5152 -initiator: An internal event of receiving a Logout response 5153 (success) on another connection for a "close the session" 5154 Logout request was received. 5156 -target: An internal event of sending a Logout response 5157 (success) on another connection for a "close the session" 5158 Logout request was received, or an internal event of a 5159 successful connection/session reinstatement is received. In 5160 both these cases, the connection is closed. 5162 The CLEANUP_WAIT state (S8) implies that there are possible iSCSI 5163 tasks that have not reached conclusion and are still considered 5164 busy. 5166 8.1.3. Standard Connection State Diagram for an Initiator 5168 Symbolic names for States: 5170 S1: FREE 5172 S2: XPT_WAIT 5174 S4: IN_LOGIN 5176 S5: LOGGED_IN 5178 S6: IN_LOGOUT 5180 S7: LOGOUT_REQUESTED 5182 S8: CLEANUP_WAIT 5184 States S5, S6, and S7 constitute the Full Feature Phase operation 5185 of the connection. 5187 The state diagram is as follows: 5189 -------<-------------+ 5190 +--------->/ S1 \<----+ | 5191 T13| +->\ /<-+ \ | 5192 | / ---+--- \ \ | 5193 | / | T2 \ | | 5194 | T8 | |T1 | | | 5195 | | | / |T7 | 5196 | | | / | | 5197 | | | / | | 5198 | | V / / | 5199 | | ------- / / | 5200 | | / S2 \ / | 5201 | | \ / / | 5202 | | ---+--- / | 5203 | | |T4 / | 5204 | | V / | T18 5205 | | ------- / | 5206 | | / S4 \ | 5207 | | \ / | 5208 | | ---+--- | T15 5209 | | |T5 +--------+---------+ 5210 | | | /T16+-----+------+ | 5211 | | | / -+-----+--+ | | 5212 | | | / / S7 \ |T12| | 5213 | | | / +->\ /<-+ V V 5214 | | | / / -+----- ------- 5215 | | | / /T11 |T10 / S8 \ 5216 | | V / / V +----+ \ / 5217 | | ---+-+- ----+-- | ------- 5218 | | / S5 \T9 / S6 \<+ ^ 5219 | +-----\ /--->\ / T14 | 5220 | ------- --+----+------+T17 5221 +---------------------------+ 5223 The following state transition table represents the above diagram. 5224 Each row represents the starting state for a given transition, 5225 which after taking a transition marked in a table cell would end in 5226 the state represented by the column of the cell. For example, from 5227 state S1, the connection takes the T1 transition to arrive at state 5228 S2. The fields marked "-" correspond to undefined transitions. 5230 +----+---+---+---+---+----+---+ 5231 |S1 |S2 |S4 |S5 |S6 |S7 |S8 | 5232 ---+----+---+---+---+---+----+---+ 5233 S1| - |T1 | - | - | - | - | - | 5234 ---+----+---+---+---+---+----+---+ 5235 S2|T2 |- |T4 | - | - | - | - | 5236 ---+----+---+---+---+---+----+---+ 5237 S4|T7 |- |- |T5 | - | - | - | 5238 ---+----+---+---+---+---+----+---+ 5239 S5|T8 |- |- | - |T9 |T11 |T15| 5240 ---+----+---+---+---+---+----+---+ 5241 S6|T13 |- |- | - |T14|- |T17| 5242 ---+----+---+---+---+---+----+---+ 5243 S7|T18 |- |- | - |T10|T12 |T16| 5244 ---+----+---+---+---+---+----+---+ 5245 S8| - |- |- | - | - | - | - | 5246 ---+----+---+---+---+---+----+---+ 5248 8.1.4. Standard Connection State Diagram for a Target 5250 Symbolic names for States: 5251 S1: FREE 5253 S3: XPT_UP 5255 S4: IN_LOGIN 5257 S5: LOGGED_IN 5259 S6: IN_LOGOUT 5261 S7: LOGOUT_REQUESTED 5263 S8: CLEANUP_WAIT 5265 States S5, S6, and S7 constitute the Full Feature Phase operation 5266 of the connection. 5268 The state diagram is as follows: 5270 -------<-------------+ 5271 +--------->/ S1 \<----+ | 5272 T13| +->\ /<-+ \ | 5273 | / ---+--- \ \ | 5274 | / | T6 \ | | 5275 | T8 | |T3 | | | 5276 | | | / |T7 | 5277 | | | / | | 5278 | | | / | | 5279 | | V / / | 5280 | | ------- / / | 5281 | | / S3 \ / | 5282 | | \ / / | T18 5283 | | ---+--- / | 5284 | | |T4 / | 5285 | | V / | 5286 | | ------- / | 5287 | | / S4 \ | 5288 | | \ / | 5289 | | ---+--- T15 | 5290 | | |T5 +--------+---------+ 5291 | | | /T16+-----+------+ | 5292 | | | / -+-----+---+ | | 5293 | | | / / S7 \ |T12| | 5294 | | | / +->\ /<-+ V V 5295 | | | / / -+----- ------- 5296 | | | / /T11 |T10 / S8 \ 5297 | | V / / V \ / 5298 | | ---+-+- ------- ------- 5299 | | / S5 \T9 / S6 \ ^ 5300 | +-----\ /--->\ / | 5301 | ------- --+----+--------+T17 5302 +---------------------------+ 5304 The following state transition table represents the above diagram, 5305 and follows the conventions described for the initiator diagram. 5307 +----+---+---+---+---+----+---+ 5308 |S1 |S3 |S4 |S5 |S6 |S7 |S8 | 5309 ---+----+---+---+---+---+----+---+ 5310 S1| - |T3 | - | - | - | - | - | 5311 ---+----+---+---+---+---+----+---+ 5312 S3|T6 |- |T4 | - | - | - | - | 5313 ---+----+---+---+---+---+----+---+ 5314 S4|T7 |- |- |T5 | - | - | - | 5315 ---+----+---+---+---+---+----+---+ 5316 S5|T8 |- |- | - |T9 |T11 |T15| 5317 ---+----+---+---+---+---+----+---+ 5318 S6|T13 |- |- | - |- |- |T17| 5319 ---+----+---+---+---+---+----+---+ 5320 S7|T18 |- |- | - |T10|T12 |T16| 5321 ---+----+---+---+---+---+----+---+ 5322 S8| - |- |- | - | - | - | - | 5323 ---+----+---+---+---+---+----+---+ 5325 8.2. Connection Cleanup State Diagram for Initiators and Targets 5327 Symbolic names for states: 5329 R1: CLEANUP_WAIT (same as S8) 5331 R2: IN_CLEANUP 5333 R3: FREE (same as S1) 5335 Whenever a connection state machine in cleanup (let's call it CSM- 5336 C) enters the CLEANUP_WAIT state (S8), it must go through the state 5337 transitions described in the connection cleanup state diagram 5338 either a) using a separate full-feature phase connection (let's 5339 call it CSM-E, for explicit) in the LOGGED_IN state in the same 5340 session, or b) using a new transport connection (let's call it CSM- 5341 I, for implicit) in the FREE state that is to be added to the same 5342 session. In the CSM-E case, an explicit logout for the CID that 5343 corresponds to CSM-C (either as a connection or session logout) 5344 needs to be performed to complete the cleanup. In the CSM-I case, 5345 an implicit logout for the CID that corresponds to CSM-C needs to 5346 be performed by way of connection reinstatement (section 5.3.4) for 5347 that CID. In either case, the protocol exchanges on CSM-E or CSM-I 5348 determine the state transitions for CSM-C. Therefore, this cleanup 5349 state diagram is only applicable to the instance of the connection 5350 in cleanup (i.e., CSM-C). In the case of an implicit logout for 5351 example, CSM-C reaches FREE (R3) at the time CSM-I reaches 5352 LOGGED_IN. In the case of an explicit logout, CSM-C reaches FREE 5353 (R3) when CSM-E receives a successful logout response while 5354 continuing to be in the LOGGED_IN state. 5356 An initiator must initiate an explicit or implicit connection 5357 logout for a connection in the CLEANUP_WAIT state, if the initiator 5358 intends to continue using the associated iSCSI session. 5360 The following state diagram applies to both initiators and targets. 5362 ------- 5363 / R1 \ 5364 +--\ /<-+ 5365 / ---+--- \ 5366 / | \ M3 5367 M1 | |M2 | 5368 | | / 5369 | | / 5370 | | / 5371 | V / 5372 | ------- / 5373 | / R2 \ 5374 | \ / 5375 | ------- 5376 | | 5377 | |M4 5378 | | 5379 | | 5380 | | 5381 | V 5382 | ------- 5383 | / R3 \ 5384 +---->\ / 5385 ------- 5387 The following state transition table represents the above diagram, 5388 and follows the same conventions as in earlier sections. 5390 +----+----+----+ 5391 |R1 |R2 |R3 | 5392 -----+----+----+----+ 5393 R1 | - |M2 |M1 | 5394 -----+----+----+----+ 5395 R2 |M3 | - |M4 | 5396 -----+----+----+----+ 5397 R3 | - | - | - | 5398 -----+----+----+----+ 5400 8.2.1. State Descriptions for Initiators and Targets 5402 -R1: CLEANUP_WAIT (Same as S8) 5403 -initiator: Waiting for the internal event to initiate the 5404 cleanup processing for CSM-C. 5405 -target: Waiting for the cleanup process to start for CSM-C. 5406 -R2: IN_CLEANUP 5407 -initiator: Waiting for the connection cleanup process to 5408 conclude for CSM-C. 5409 -target: Waiting for the connection cleanup process to 5410 conclude for CSM-C. 5411 -R3: FREE (Same as S1) 5412 -initiator: End state for CSM-C. 5413 -target: End state for CSM-C. 5415 8.2.2. State Transition Descriptions for Initiators and Targets 5417 -M1: One or more of the following events was received: 5418 -initiator: 5419 -An internal event that indicates connection state 5420 timeout. 5421 -An internal event of receiving a successful Logout 5422 response on a different connection for a "close the 5423 session" Logout. 5424 -target: 5425 -An internal event that indicates connection state 5426 timeout. 5428 -An internal event of sending a Logout response 5429 (success) on a different connection for a "close the 5430 session" Logout request. 5432 -M2: An implicit/explicit logout process was initiated by the 5433 initiator. 5434 -In CSM-I usage: 5435 -initiator: An internal event requesting the connection 5436 (or session) reinstatement was received, thus prompting 5437 a connection (or session) reinstatement Login to be sent 5438 transitioning CSM-I to state IN_LOGIN. 5439 -target: A connection/session reinstatement Login was 5440 received while in state XPT_UP. 5441 -In CSM-E usage: 5442 -initiator: An internal event that indicates that an 5443 explicit logout was sent for this CID in state 5444 LOGGED_IN. 5445 -target: An explicit logout was received for this CID in 5446 state LOGGED_IN. 5447 -M3: Logout failure detected 5448 -In CSM-I usage: 5449 -initiator: CSM-I failed to reach LOGGED_IN and arrived 5450 into FREE instead. 5451 -target: CSM-I failed to reach LOGGED_IN and arrived 5452 into FREE instead. 5453 -In CSM-E usage: 5454 -initiator: CSM-E either moved out of LOGGED_IN, or 5455 Logout timed out and/or aborted, or Logout response 5456 (failure) was received. 5457 -target: CSM-E either moved out of LOGGED_IN, Logout 5458 timed out and/or aborted, or an internal event that 5459 indicates a failed Logout processing was received. A 5460 Logout response (failure) was sent in the last case. 5462 -M4: Successful implicit/explicit logout was performed. 5463 - In CSM-I usage: 5464 -initiator: CSM-I reached state LOGGED_IN, or an 5465 internal event of receiving a Logout response (success) 5466 on another connection for a "close the session" Logout 5467 request was received. 5468 -target: CSM-I reached state LOGGED_IN, or an internal 5469 event of sending a Logout response (success) on a 5470 different connection for a "close the session" Logout 5471 request was received. 5472 - In CSM-E usage: 5473 -initiator: CSM-E stayed in LOGGED_IN and received a 5474 Logout response (success), or an internal event of 5475 receiving a Logout response (success) on another 5476 connection for a "close the session" Logout request was 5477 received. 5478 -target: CSM-E stayed in LOGGED_IN and an internal event 5479 indicating a successful Logout processing was received, 5480 or an internal event of sending a Logout response 5481 (success) on a different connection for a "close the 5482 session" Logout request was received. 5484 8.3. Session State Diagrams 5486 8.3.1. Session State Diagram for an Initiator 5488 Symbolic Names for States: 5490 Q1: FREE 5492 Q3: LOGGED_IN 5494 Q4: FAILED 5496 State Q3 represents the Full Feature Phase operation of the 5497 session. 5499 The state diagram is as follows: 5501 ------- 5502 / Q1 \ 5503 +------>\ /<-+ 5504 / ---+--- | 5505 / | |N3 5506 N6 | |N1 | 5507 | | | 5508 | N4 | | 5509 | +--------+ | / 5510 | | | | / 5511 | | | | / 5512 | | V V / 5513 -+--+-- -----+- 5514 / Q4 \ N5 / Q3 \ 5515 \ /<---\ / 5516 ------- ------- 5518 The state transition table is as follows: 5520 +----+----+----+ 5521 |Q1 |Q3 |Q4 | 5522 -----+----+----+----+ 5523 Q1 | - |N1 | - | 5524 -----+----+----+----+ 5525 Q3 |N3 | - |N5 | 5526 -----+----+----+----+ 5527 Q4 |N6 |N4 | - | 5528 -----+----+----+----+ 5530 8.3.2. Session State Diagram for a Target 5532 Symbolic Names for States: 5534 Q1: FREE 5536 Q2: ACTIVE 5538 Q3: LOGGED_IN 5540 Q4: FAILED 5541 Q5: IN_CONTINUE 5543 State Q3 represents the Full Feature Phase operation of the 5544 session. 5546 The state diagram is as follows: 5548 ------- 5549 +------------------>/ Q1 \ 5550 / +-------------->\ /<-+ 5551 | | ---+--- | 5552 | | ^ | |N3 5553 N6 | |N11 N9| V N1 | 5554 | | +------ | 5555 | | / Q2 \ | 5556 | | \ / | 5557 | --+---- +--+--- | 5558 | / Q5 \ | | 5559 | \ / N10 | | 5560 | +-+---+------------+ |N2 / 5561 | ^ | | | / 5562 |N7| |N8 | | / 5563 | | | | V / 5564 -+--+-V V----+- 5565 / Q4 \ N5 / Q3 \ 5566 \ /<-------------\ / 5567 ------- ------- 5569 The state transition table is as follows: 5571 +----+----+----+----+----+ 5572 |Q1 |Q2 |Q3 |Q4 |Q5 | 5573 -----+----+----+----+----+----+ 5574 Q1 | - |N1 | - | - | - | 5575 -----+----+----+----+----+----+ 5576 Q2 |N9 | - |N2 | - | - | 5577 -----+----+----+----+----+----+ 5578 Q3 |N3 | - | - |N5 | - | 5579 -----+----+----+----+----+----+ 5580 Q4 |N6 | - | - | - |N7 | 5581 -----+----+----+----+----+----+ 5582 Q5 |N11 | - |N10 |N8 | - | 5583 -----+----+----+----+----+----+ 5585 8.3.3. State Descriptions for Initiators and Targets 5587 -Q1: FREE 5588 -initiator: State on instantiation or after cleanup. 5589 -target: State on instantiation or after cleanup. 5590 -Q2: ACTIVE 5591 -initiator: Illegal. 5592 -target: The first iSCSI connection in the session 5593 transitioned to IN_LOGIN, waiting for it to complete the 5594 login process. 5595 -Q3: LOGGED_IN 5596 -initiator: Waiting for all session events. 5597 -target: Waiting for all session events. 5598 -Q4: FAILED 5599 -initiator: Waiting for session recovery or session 5600 continuation. 5601 -target: Waiting for session recovery or session 5602 continuation. 5603 -Q5: IN_CONTINUE 5604 -initiator: Illegal. 5605 -target: Waiting for session continuation attempt to reach a 5606 conclusion. 5608 8.3.4. State Transition Descriptions for Initiators and Targets 5610 -N1: 5611 -initiator: At least one transport connection reached the 5612 LOGGED_IN state. 5613 -target: The first iSCSI connection in the session had 5614 reached the IN_LOGIN state. 5615 -N2: 5616 -initiator: Illegal. 5617 -target: At least one iSCSI connection reached the LOGGED_IN 5618 state. 5619 -N3: 5620 -initiator: Graceful closing of the session via session 5621 closure (Section 5.3.6 - "Session Continuation and 5622 Failure"). 5623 -target: Graceful closing of the session via session closure 5624 (Section 5.3.6 - "Session Continuation and Failure") or a 5625 successful session reinstatement cleanly closed the session. 5626 -N4: 5627 -initiator: A session continuation attempt succeeded. 5628 -target: Illegal. 5629 -N5: 5630 -initiator: Session failure (Section 5.3.6 - "Session 5631 Continuation and Failure") occurred. 5632 -target: Session failure (Section 5.3.6 - "Session 5633 Continuation and Failure") occurred. 5634 -N6: 5635 -initiator: Session state timeout occurred, or a session 5636 reinstatement cleared this session instance. This results 5637 in the freeing of all associated resources and the session 5638 state is discarded. 5639 -target: Session state timeout occurred, or a session 5640 reinstatement cleared this session instance. This results 5641 in the freeing of all associated resources and the session 5642 state is discarded. 5643 -N7: 5644 -initiator: Illegal. 5645 -target: A session continuation attempt is initiated. 5646 -N8: 5647 -initiator: Illegal. 5648 -target: The last session continuation attempt failed. 5650 -N9: 5651 -initiator: Illegal. 5652 -target: Login attempt on the leading connection failed. 5653 -N10: 5654 -initiator: Illegal. 5655 -target: A session continuation attempt succeeded. 5656 -N11: 5657 -initiator: Illegal. 5658 -target: A successful session reinstatement cleanly closed 5659 the session. 5661 9. Security Considerations 5663 Historically, native storage systems have not had to consider 5664 security because their environments offered minimal security risks. 5665 That is, these environments consisted of storage devices either 5666 directly attached to hosts or connected via a Storage Area Network 5667 (SAN) distinctly separate from the communications network. The use 5668 of storage protocols, such as SCSI, over IP-networks requires that 5669 security concerns be addressed. iSCSI implementations MUST provide 5670 means of protection against active attacks (e.g., pretending to be 5671 another identity, message insertion, deletion, modification, and 5672 replaying) and passive attacks (e.g.,eavesdropping, gaining 5673 advantage by analyzing the data sent over the line). 5675 Although technically possible, iSCSI SHOULD NOT be configured 5676 without security. iSCSI configured without security should be 5677 confined, in extreme cases, to closed environments without any 5678 security risk. [RFC3723] specifies the mechanisms that must be used 5679 in order to mitigate risks fully described in that document. 5681 The following section describes the security mechanisms provided by 5682 an iSCSI implementation. 5684 9.1. iSCSI Security Mechanisms 5686 The entities involved in iSCSI security are the initiator, target, 5687 and the IP communication end points. iSCSI scenarios in which 5688 multiple initiators or targets share a single communication end 5689 point are expected. To accommodate such scenarios, iSCSI uses two 5690 separate security mechanisms: In-band authentication between the 5691 initiator and the target at the iSCSI connection level (carried out 5692 by exchange of iSCSI Login PDUs), and packet protection (integrity, 5693 authentication, and confidentiality) by IPsec at the IP level. The 5694 two security mechanisms complement each other. The in-band 5695 authentication provides end-to-end trust (at login time) between 5696 the iSCSI initiator and the target while IPsec provides a secure 5697 channel between the IP communication end points. 5699 Further details on typical iSCSI scenarios and the relation between 5700 the initiators, targets, and the communication end points can be 5701 found in [RFC3723]. 5703 9.2. In-band Initiator-Target Authentication 5705 During login, the target MUST authenticate the initiator and the 5706 initiator MAY authenticate the target. The authentication is 5707 performed on every new iSCSI connection by an exchange of iSCSI 5708 Login PDUs using a negotiated authentication method. 5710 The authentication method cannot assume an underlying IPsec 5711 protection, because IPsec is optional to use. An attacker should 5712 gain as little advantage as possible by inspecting the 5713 authentication phase PDUs. Therefore, a method using clear text (or 5714 equivalent) passwords is not acceptable; on the other hand, 5715 identity protection is not strictly required. 5717 The authentication mechanism protects against an unauthorized login 5718 to storage resources by using a false identity (spoofing). Once the 5719 authentication phase is completed, if the underlying IPsec is not 5720 used, all PDUs are sent and received in clear. The authentication 5721 mechanism alone (without underlying IPsec) should only be used when 5722 there is no risk of eavesdropping, message insertion, deletion, 5723 modification, and replaying. 5725 Section 11 - "iSCSI Security Text Keys and Authentication Methods" 5726 defines several authentication methods and the exact steps that 5727 must be followed in each of them, including the iSCSI-text-keys and 5728 their allowed values in each step. Whenever an iSCSI initiator gets 5729 a response whose keys, or their values, are not according to the 5730 step definition, it MUST abort the connection. Whenever an iSCSI 5731 target gets a response whose keys, or their values, are not 5732 according to the step definition, it MUST answer with a Login 5733 reject with the "Initiator Error" or "Missing Parameter" status. 5734 These statuses are not intended for cryptographically incorrect 5735 values such as the CHAP response, for which "Authentication 5736 Failure" status MUST be specified. The importance of this rule can 5737 be illustrated in CHAP with target authentication (see Section 5738 11.1.4 - "Challenge Handshake Authentication Protocol (CHAP)") 5739 where the initiator would have been able to conduct a reflection 5740 attack by omitting his response key (CHAP_R) using the same CHAP 5741 challenge as the target and reflecting the target's response back 5742 to the target. In CHAP, this is prevented because the target must 5743 answer the missing CHAP_R key with a Login reject with the "Missing 5744 Parameter" status. 5746 For some of the authentication methods, a key specifies the 5747 identity of the iSCSI initiator or target for authentication 5748 purposes. The value associated with that key MAY be different from 5749 the iSCSI name and SHOULD be configurable. (CHAP_N, see Section 5750 11.1.4 - "Challenge Handshake Authentication Protocol (CHAP)" and 5751 SRP_U, see Section 11.1.3 - "Secure Remote Password (SRP)"). 5753 9.2.1. CHAP Considerations 5755 Compliant iSCSI initiators and targets MUST implement the CHAP 5756 authentication method [RFC1994] (according to Section 11.1.4 - 5757 "Challenge Handshake Authentication Protocol (CHAP)" including the 5758 target authentication option). 5760 When CHAP is performed over a non-encrypted channel, it is 5761 vulnerable to an off-line dictionary attack. Implementations MUST 5762 support use of up to 128 bit random CHAP secrets, including the 5763 means to generate such secrets and to accept them from an external 5764 generation source. Implementations MUST NOT provide secret 5765 generation (or expansion) means other than random generation. 5767 An administrative entity of an environment in which CHAP is used 5768 with a secret that has less than 96 random bits MUST enforce IPsec 5769 encryption (according to the implementation requirements in 5770 Confidentiality) to protect the connection. Moreover, in this case 5771 IKE authentication with group pre-shared cryptographic keys SHOULD 5772 NOT be used unless it is not essential to protect group members 5773 against off-line dictionary attacks by other members. 5775 CHAP secrets MUST be an integral number of bytes (octets). A 5776 compliant implementation SHOULD NOT continue with the login step in 5777 which it should send a CHAP response (CHAP_R, Section 11.1.4 - 5778 "Challenge Handshake Authentication Protocol (CHAP)") unless it can 5779 verify that the CHAP secret is at least 96 bits, or that IPsec 5780 encryption is being used to protect the connection. 5782 Any CHAP secret used for initiator authentication MUST NOT be 5783 configured for authentication of any target, and any CHAP secret 5784 used for target authentication MUST NOT be configured for 5785 authentication of any initiator. If the CHAP response received by 5786 one end of an iSCSI connection is the same as the CHAP response 5787 that the receiving endpoint would have generated for the same CHAP 5788 challenge, the response MUST be treated as an authentication 5789 failure and cause the connection to close (this ensures that the 5790 same CHAP secret is not used for authentication in both 5791 directions). Also, if 5792 an iSCSI implementation can function as both initiator and target, 5793 different CHAP secrets and identities MUST be configured for these 5794 two roles. The following is an example of the attacks prevented by 5795 the above requirements: 5797 Rogue wants to impersonate Storage to Alice, and knows that a 5798 single secret is used for both directions of Storage-Alice 5799 authentication. 5801 Rogue convinces Alice to open two connections to Rogue, and 5802 Rogue identifies itself as Storage on both connections. 5804 Rogue issues a CHAP challenge on connection 1, waits for Alice 5805 to respond, and then reflects Alice's challenge as the 5806 initial challenge to Alice on connection 2. 5808 If Alice doesn't check for the reflection across connections, 5809 Alice's response on connection 2 enables Rogue to impersonate 5810 Storage on connection 1, even though Rogue does not know the 5811 Alice-Storage CHAP secret. 5813 Originators MUST NOT reuse the CHAP challenge sent by the Responder 5814 for the other direction of a bidirectional authentication. 5815 Responders MUST check for this condition and close the iSCSI TCP 5816 connection if it occurs. 5818 The same CHAP secret SHOULD NOT be configured for authentication of 5819 multiple initiators or multiple targets, as this enables any of 5820 them to impersonate any other one of them, and compromising one of 5821 them enables the attacker to impersonate any of them. It is 5822 recommended that iSCSI implementations check for use of identical 5823 CHAP secrets by different peers when this check is feasible, and 5824 take appropriate measures to warn users and/or administrators when 5825 this is detected. 5827 When an iSCSI initiator or target authenticates itself to 5828 counterparts in multiple administrative domains, it SHOULD use a 5829 different CHAP secret for each administrative domain to avoid 5830 propagating security compromises across domains. 5832 Within a single administrative domain: 5833 - A single CHAP secret MAY be used for authentication of an 5834 initiator to multiple targets. 5836 - A single CHAP secret MAY be used for an authentication of a 5837 target to multiple initiators when the initiators use an 5838 external server (e.g., RADIUS) to verify the target's CHAP 5839 responses and do not know the target's CHAP secret. 5841 If an external response verification server (e.g., RADIUS) is not 5842 used, employing a single CHAP secret for authentication of a target 5843 to multiple initiators requires that all such initiators know that 5844 target secret. Any of these initiators can impersonate the target 5845 to any other such initiator, and compromise of such an initiator 5846 enables an attacker to impersonate the target to all such 5847 initiators. Targets SHOULD use separate CHAP secrets for 5848 authentication to each initiator when such risks are of concern; in 5849 this situation it may be useful to configure a separate logical 5850 iSCSI target with its own iSCSI Node Name for each initiator or 5851 group of initiators among which such separation is desired. 5853 9.2.2. SRP Considerations 5855 The strength of the SRP authentication method (specified in 5856 [RFC2945]) is dependent on the characteristics of the group being 5857 used (i.e., the prime modulus N and generator g). As described in 5858 [RFC2945], N is required to be a Sophie-German prime (of the form N 5859 = 2q + 1, where q is also prime) and the generator g is a primitive 5860 root of GF(n). In iSCSI authentication, the prime modulus N MUST be 5861 at least 768 bits. 5863 The list of allowed SRP groups is provided in [RFC3723]. 5865 9.3. IPsec 5867 iSCSI uses the IPsec mechanism for packet protection (cryptographic 5868 integrity, authentication, and confidentiality) at the IP level 5869 between the iSCSI communicating end points. The following sections 5870 describe the IPsec protocols that must be implemented for data 5871 integrity and authentication, confidentiality, and cryptographic 5872 key management. 5874 An iSCSI initiator or target may provide the required IPsec support 5875 fully integrated or in conjunction with an IPsec front-end device. 5876 In the latter case, the compliance requirements with regard to 5877 IPsec support apply to the "combined device". Only the "combined 5878 device" is to be considered an iSCSI device. 5880 Detailed considerations and recommendations for using IPsec for 5881 iSCSI are provided in [RFC3723]. 5883 9.3.1. Data Integrity and Authentication 5885 Data authentication and integrity is provided by a cryptographic 5886 keyed Message Authentication Code in every sent packet. This code 5887 protects against message insertion, deletion, and modification. 5888 Protection against message replay is realized by using a sequence 5889 counter. 5891 An iSCSI compliant initiator or target MUST provide data integrity 5892 and authentication by implementing IPsec [RFC4301] with ESP 5893 [RFC4303] in tunnel mode and MAY provide data integrity and 5894 authentication by implementing IPsec with ESP in transport mode. 5895 The IPsec implementation MUST fulfill the following iSCSI specific 5896 requirements: 5898 - HMAC-SHA1 MUST be implemented [RFC2404]. 5900 - AES CBC MAC with XCBC extensions SHOULD be implemented 5901 [RFC3566]. 5903 The ESP anti-replay service MUST also be implemented. 5905 At the high speeds iSCSI is expected to operate, a single IPsec SA 5906 could rapidly cycle through the 32-bit IPsec sequence number space. 5907 In view of this, an iSCSI implementation that operates at speeds of 5908 1 Gbps or greater MUST implement the IPsec sequence number 5909 extension [RFC4303] and SHOULD use it on iSCSI connections. 5911 9.3.2. Confidentiality 5913 Confidentiality is provided by encrypting the data in every packet. 5914 When confidentiality is used it MUST be accompanied by data 5915 integrity and authentication to provide comprehensive protection 5916 against eavesdropping, message insertion, deletion, modification, 5917 and replaying. 5919 An iSCSI compliant initiator or target MUST provide confidentiality 5920 by implementing IPsec [RFC4301] with ESP [RFC4303] in tunnel mode 5921 and MAY provide confidentiality by implementing IPsec with ESP in 5922 transport mode, with the following iSCSI specific requirements: 5924 - 3DES in CBC mode MUST be implemented [RFC2451]. 5926 - AES in Counter mode SHOULD be implemented [RFC3686]. 5928 DES in CBC mode SHOULD NOT be used due to its inherent weakness. 5929 The NULL encryption algorithm MUST also be implemented. 5931 9.3.3. Policy, Security Associations, and Cryptographic Key Management 5933 A compliant iSCSI implementation MUST meet the cryptographic key 5934 management requirements of the IPsec protocol suite. 5935 Authentication, security association negotiation, and cryptographic 5936 key management MUST be provided by implementing IKE [RFC4306] using 5937 the IPsec DOI [RFC4306] with the following iSCSI specific 5938 requirements: 5940 - Peer authentication using a pre-shared cryptographic key MUST 5941 be supported. Certificate-based peer authentication using 5942 digital signatures MAY be supported. Peer authentication 5943 using the public key encryption methods outlined in IKE 5944 sections 5.2 and 5.3[7] SHOULD NOT be used. 5946 - When digital signatures are used to achieve authentication, 5947 an IKE negotiator SHOULD use IKE Certificate Request 5948 Payload(s) to specify the certificate authority. IKE 5949 negotiators SHOULD check the pertinent Certificate Revocation 5950 List (CRL) before accepting a PKI certificate for use in IKE 5951 authentication procedures. 5953 - Conformant iSCSI implementations MUST support IKE Main Mode 5954 and SHOULD support Aggressive Mode. IKE main mode with pre- 5955 shared key authentication method SHOULD NOT be used when 5956 either the initiator or the target uses dynamically assigned 5957 IP addresses. While in many cases pre-shared keys offer good 5958 security, situations in which dynamically assigned addresses 5959 are used force the use of a group pre-shared key, which 5960 creates vulnerability to a man-in-the-middle attack. 5962 - In the IKE Phase 2 Quick Mode, exchanges for creating the 5963 Phase 2 SA, the Identity Payload, fields MUST be present. 5964 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports 5965 IPv6) and ID_FQDN Identity payloads MUST be supported; 5966 ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address 5967 Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN formats SHOULD NOT 5968 be used. The ID_KEY_ID Identity Payload MUST NOT be used. 5970 Manual cryptographic keying MUST NOT be used because it does not 5971 provide the necessary re-keying support. 5973 When IPsec is used, the receipt of an IKE Phase 2 delete message 5974 SHOULD NOT be interpreted as a reason for tearing down the iSCSI 5975 TCP connection. If additional traffic is sent on it, a new IKE 5976 Phase 2 SA will be created to protect it. 5978 The method used by the initiator to determine whether the target 5979 should be connected using IPsec is regarded as an issue of IPsec 5980 policy administration, and thus not defined in the iSCSI standard. 5982 If an iSCSI target is discovered via a SendTargets request in a 5983 discovery session not using IPsec, the initiator should assume that 5984 it does not need IPsec to establish a session to that target. If an 5985 iSCSI target is discovered using a discovery session that does use 5986 IPsec, the initiator SHOULD use IPsec when establishing a session 5987 to that target. 5989 9.4. Security Considerations for the X#NodeArchitecture Key 5991 The security considerations in this section are specific to the 5992 X#NodeArchitecture discussed in Section 12.24 - 5993 "X#NodeArchitecture". 5995 This extension key transmits specific implementation details about 5996 the node that sends it; such details may be considered sensitive in 5997 some environments. For example, if a certain software or firmware 5998 version is known to contain security weaknesses, announcing the 5999 presence of that version via this key may not be desirable. The 6000 countermeasures for this security concern are: 6002 - sending less detailed information in the key values, 6003 - not sending the extension key, or 6004 - using IPsec ([RFC4303]) to provide confidentiality for 6005 the iSCSI connection on which the key is sent 6006 To support the first and second countermeasures, all 6007 implementations of this extension key MUST provide an 6008 administrative mechanism to disable sending the key. In addition, 6009 all implementations SHOULD provide an administrative mechanism to 6010 configure a verbosity level of the key value, thereby controlling 6011 the amount of information sent. 6013 For example, a lower verbosity might enable transmission of node 6014 architecture component names only, but no version numbers. The 6015 choice of which countermeasure is most appropriate depends on the 6016 environment. However, sending less detailed information in the key 6017 values may be an acceptable countermeasure in many environments, 6018 since it provides a compromise between sending too much information 6019 and the other more complete countermeasures of not sending the key 6020 at all or using IPsec. 6022 In addition to security considerations involving transmission of 6023 the key contents, any logging method(s) used for the key values 6024 MUST keep the information secure from intruders. For all 6025 implementations, the requirements to address this security concern 6026 are: 6028 - Display of the log MUST only be possible with administrative 6029 rights to the node. 6031 - Options to disable logging to disk and to keep logs for a 6032 fixed duration SHOULD be provided. 6034 Finally, it is important to note that different nodes may have 6035 different levels of risk, and these differences may affect the 6036 implementation. The components of risk include assets, threats, and 6037 vulnerabilities. Consider the following example iSCSI nodes, which 6038 demonstrate differences in assets and vulnerabilities of the nodes, 6039 and as a result, differences in implementation: 6041 One iSCSI target based on a special-purpose operating system: 6042 Since the iSCSI target controls access to the data storage 6043 containing company assets, the asset level is seen as very 6044 high. Also, because of the special-purpose operating 6045 system, in which vulnerabilities are less well-known, the 6046 vulnerability level is viewed as low. 6048 Multiple iSCSI initiators in a blade farm, each running a 6049 general purpose operating system: The asset level of each 6050 node is viewed as low, since blades are replaceable and low 6051 cost. However, the vulnerability level is viewed as high, 6052 since there may be many wellknown vulnerabilities to that 6053 general-purpose operating system. For this target, an 6054 appropriate implementation might be logging of received key 6055 values, but no transmission of the key. For this initiator, 6056 an appropriate implementation might be transmission of the 6057 key, but no logging of received key values. 6059 10. Notes to Implementers 6061 This section notes some of the performance and reliability 6062 considerations of the iSCSI protocol. This protocol was designed to 6063 allow efficient silicon and software implementations. The iSCSI 6064 task tag mechanism was designed to enable Direct Data Placement 6065 (DDP - a DMA form) at the iSCSI level or lower. 6067 The guiding assumption made throughout the design of this protocol 6068 is that targets are resource constrained relative to initiators. 6070 Implementers are also advised to consider the implementation 6071 consequences of the iSCSI to SCSI mapping model as outlined in 6072 Section 3.4.3 - "Consequences of the Model". 6074 10.1. Multiple Network Adapters 6076 The iSCSI protocol allows multiple connections, not all of which 6077 need to go over the same network adapter. If multiple network 6078 connections are to be utilized with hardware support, the iSCSI 6079 protocol command-data-status allegiance to one TCP connection 6080 ensures that there is no need to replicate information across 6081 network adapters or otherwise require them to cooperate. 6083 However, some task management commands may require some loose form 6084 of cooperation or replication at least on the target. 6086 10.1.1. Conservative Reuse of ISIDs 6088 Historically, the SCSI model (and implementations and applications 6089 based on that model) has assumed that SCSI ports are static, 6090 physical entities. Recent extensions to the SCSI model have taken 6091 advantage of persistent worldwide unique names for these ports. In 6092 iSCSI however, the SCSI initiator ports are the endpoints of 6093 dynamically created sessions, so the presumptions of "static and 6094 physical" do not apply. In any case, the model clauses 6095 (particularly, Section 3.4.2 - "SCSI Architecture Model") provide 6096 for persistent, reusable names for the iSCSI-type SCSI initiator 6097 ports even though there does not need to be any physical entity 6098 bound to these names. 6100 To both minimize the disruption of legacy applications and to 6101 better facilitate the SCSI features that rely on persistent names 6102 for SCSI ports, iSCSI implementations SHOULD attempt to provide a 6103 stable presentation of SCSI Initiator Ports (both to the upper OS- 6104 layers and to the targets to which they connect). This can be 6105 achieved in an initiator implementation by conservatively reusing 6106 ISIDs. In other words, the same ISID should be used in the Login 6107 process to multiple target portal groups (of the same iSCSI Target 6108 or different iSCSI Targets). The ISID RULE (Section 3.4.3 - 6109 "Consequences of the Model") only prohibits reuse to the same 6110 target portal group. It does not "preclude" reuse to other target 6111 portal groups. 6112 The principle of conservative reuse "encourages" reuse to other 6113 target portal groups. When a SCSI target device sees the same 6114 (InitiatorName, ISID) pair in different sessions to different 6115 target portal groups, it can identify the underlying SCSI Initiator 6116 Port on each session as the same SCSI port. In effect, it can 6117 recognize multiple paths from the same source. 6119 10.1.2. iSCSI Name, ISID, and TPGT Use 6121 The designers of the iSCSI protocol are aware that legacy SCSI 6122 transports rely on initiator identity to assign access to storage 6123 resources. Although newer techniques are available and simplify 6124 access control, support for configuration and authentication 6125 schemes that are based on initiator identity is deemed important in 6126 order to support legacy systems and administration software. iSCSI 6127 thus supports the notion that it should be possible to assign 6128 access to storage resources based on "initiator device" identity. 6130 When there are multiple hardware or software components coordinated 6131 as a single iSCSI Node, there must be some (logical) entity that 6132 represents the iSCSI Node that makes the iSCSI Node Name available 6133 to all components involved in session creation and login. 6134 Similarly, this entity that represents the iSCSI Node must be able 6135 to coordinate session identifier resources (ISID for initiators) to 6136 enforce both the ISID and TSIH RULES (see Section 3.4.3 - 6137 "Consequences of the Model"). 6139 For targets, because of the closed environment, implementation of 6140 this entity should be straightforward. However, vendors of iSCSI 6141 hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide 6142 mechanisms for configuration of the iSCSI Node Name across the 6143 portal groups instantiated by multiple instances of these 6144 components within a target. 6146 However, complex targets making use of multiple Target Portal Group 6147 Tags may reconfigure them to achieve various quality goals. The 6148 initiators have two mechanisms at their disposal to discover and/or 6149 check reconfiguring targets - the discovery session type and a key 6150 returned by the target during login to confirm the TPGT. An 6151 initiator should attempt to "rediscover" the target configuration 6152 anytime a session is terminated unexpectedly. 6154 For initiators, in the long term, it is expected that operating 6155 system vendors will take on the role of this entity and provide 6156 standard APIs that can inform components of their iSCSI Node Name 6157 and can configure and/or coordinate ISID allocation, use, and 6158 reuse. 6160 Recognizing that such initiator APIs are not available today, other 6161 implementations of the role of this entity are possible. For 6162 example, a human may instantiate the (common) Node name as part of 6163 the installation process of each iSCSI component involved in 6164 session creation and login. This may be done either by pointing the 6165 component to a vendor-specific location for this datum or to a 6166 system-wide location. The structure of the ISID namespace (see 6167 Section 10.12.5 - "ISID" and [RFC3721]) facilitates implementation 6168 of the ISID coordination by allowing each component vendor to 6169 independently (of other vendor's components) coordinate allocation, 6170 use, and reuse of its own partition of the ISID namespace in a 6171 vendor-specific manner. Partitioning of the ISID namespace within 6172 initiator portal groups managed by that vendor allows each such 6173 initiator portal group to act independently of all other portal 6174 groups when selecting an ISID for a login; this facilitates 6175 enforcement of the ISID RULE (see Section 3.4.3 - "Consequences of 6176 the Model") at the initiator. 6178 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in 6179 initiators MUST implement a mechanism for configuring the iSCSI 6180 Node Name. Vendors, and administrators must ensure that iSCSI Node 6181 Names are unique worldwide. It is therefore important that when one 6182 chooses to reuse the iSCSI Node Name of a disabled unit, not to re- 6183 assign that name to the original unit unless its worldwide 6184 uniqueness can be ascertained again. 6186 In addition, a vendor of iSCSI hardware must implement a mechanism 6187 to configure and/or coordinate ISIDs for all sessions managed by 6188 multiple instances of that hardware within a given iSCSI Node. Such 6189 configuration might be either permanently pre-assigned at the 6190 factory (in a necessarily globally unique way), statically assigned 6191 (e.g., partitioned across all the NICs at initialization in a 6192 locally unique way), or dynamically assigned (e.g., on-line 6193 allocator, also in a locally unique way). In the latter two cases, 6194 the configuration may be via public APIs (perhaps driven by an 6195 independent vendor's software, such as the OS vendor) or via 6196 private APIs driven by the vendor's own software. 6198 The process of name assignment and coordination has to be as 6199 encompassing and automated as possible as years of legacy usage 6200 have shown it to be highly error-prone. It is to be mentioned that 6201 SCSI has today alternative schemes of access control that can be 6202 used by all transports and their security is not dependent on 6203 strict naming coordination. 6205 10.2. Autosense and Auto Contingent Allegiance (ACA) 6207 Autosense refers to the automatic return of sense data to the 6208 initiator in case a command did not complete successfully. iSCSI 6209 initiators and targets MUST support and use autosense. 6211 ACA helps preserve ordered command execution in the presence of 6212 errors. As iSCSI can have many commands in-flight between initiator 6213 and target, iSCSI initiators and targets SHOULD support ACA. 6215 10.3. iSCSI Timeouts 6217 iSCSI recovery actions are often dependent on iSCSI time-outs being 6218 recognized and acted upon before SCSI time-outs. Determining the 6219 right time-outs to use for various iSCSI actions (command 6220 acknowledgements expected, status acknowledgements, etc.) is very 6221 much dependent on infrastructure (hardware, links, TCP/IP stack, 6222 iSCSI driver). As a guide, the implementer may use an average Nop- 6223 Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 6224 4) as a good estimate for the basic delay of the iSCSI stack for a 6225 given connection. The safety factor should account for the network 6226 load variability. For connection teardown the implementer may want 6227 to consider also TCP common practice for the given infrastructure. 6229 Text negotiations MAY also be subject to either time-limits or 6230 limits in the number of exchanges. Those SHOULD be generous enough 6231 to avoid affecting interoperability (e.g., allowing each key to be 6232 negotiated on a separate exchange). 6234 The relation between iSCSI timeouts and SCSI timeouts should also 6235 be considered. SCSI timeouts should be longer than iSCSI timeouts 6236 plus the time required for iSCSI recovery whenever iSCSI recovery 6237 is planned. Alternatively, an implementer may choose to interlock 6238 iSCSI timeouts and recovery with SCSI timeouts so that SCSI 6239 recovery will become active only where iSCSI is not planned to, or 6240 failed to, recover. 6242 The implementer may also want to consider the interaction between 6243 various iSCSI exception events - such as a digest failure - and 6244 subsequent timeouts. When iSCSI error recovery is active, a digest 6245 failure is likely to result in discovering a missing command or 6246 data PDU. In these cases, an implementer may want to lower the 6247 timeout values to enable faster initiation for recovery procedures. 6249 10.4. Command Retry and Cleaning Old Command Instances 6251 To avoid having old, retried command instances appear in a valid 6252 command window after a command sequence number wrap around, the 6253 protocol requires (see Section 3.2.2.1 - "Command Numbering and 6254 Acknowledging") that on every connection on which a retry has been 6255 issued, a non-immediate command be issued and acknowledged within a 6256 2**31-1 commands interval from the CmdSN of the retried command. 6257 This requirement can be fulfilled by an implementation in several 6258 ways. 6260 The simplest technique to use is to send a (non-retry) non- 6261 immediate SCSI command (or a NOP if no SCSI command is available 6262 for a while) after every command retry on the connection on which 6263 the retry was attempted. As errors are deemed rare events, this 6264 technique is probably the most effective, as it does not involve 6265 additional checks at the initiator when issuing commands. 6267 10.5. Synch and Steering Layer and Performance 6269 While a synch and steering layer is optional, an initiator/target 6270 that does not have it working against a target/initiator that 6271 demands synch and steering may experience performance degradation 6272 caused by packet reordering and loss. Providing a synch and 6273 steering mechanism is recommended for all high-speed 6274 implementations. 6276 10.6. Considerations for State-dependent Devices and Long-lasting SCSI 6277 Operations 6279 Sequential access devices operate on the principle that the 6280 position of the device is based on the last command processed. As 6281 such, command processing order and knowledge of whether or not the 6282 previous command was processed is of the utmost importance to 6283 maintain data integrity. For example, inadvertent retries of SCSI 6284 commands when it is not known if the previous SCSI command was 6285 processed is a potential data integrity risk. 6287 For a sequential access device, consider the scenario in which a 6288 SCSI SPACE command to backspace one filemark is issued and then re- 6289 issued due to no status received for the command. If the first 6290 SPACE command was actually processed, the re-issued SPACE command, 6291 if processed, will cause the position to change. Thus, a subsequent 6292 write operation will write data to the wrong position and any 6293 previous data at that position will be overwritten. 6295 For a medium changer device, consider the scenario in which an 6296 EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION ADDRESS 6297 are the same thus performing a swap) is issued and then re-issued 6298 due to no status received for the command. If the first EXCHANGE 6299 MEDIUM command was actually processed, the re-issued EXCHANGE 6300 MEDIUM command, if processed, will perform the swap again. The net 6301 effect is no swap was performed thus leaving a data integrity 6302 exposure. 6304 All commands that change the state of the device (as in SPACE 6305 commands for sequential access devices, and EXCHANGE MEDIUM for 6306 medium changer device), MUST be issued as non-immediate commands 6307 for deterministic and in order delivery to iSCSI targets. 6309 For many of those state changing commands, the execution model also 6310 assumes that the command is executed exactly once. Devices 6311 implementing READ POSITION and LOCATE provide a means for SCSI 6312 level command recovery and new tape-class devices 6313 should support those commands. In their absence a retry at SCSI 6314 level is difficult and error recovery at iSCSI level is advisable. 6316 Devices operating on long latency delivery subsystems and 6317 performing long lasting SCSI operations may need mechanisms that 6318 enable connection replacement while commands are running (e.g., 6319 during an extended copy operation). 6321 10.6.1. Determining the Proper ErrorRecoveryLevel 6323 The implementation and use of a specific ErrorRecoveryLevel should 6324 be determined based on the deployment scenarios of a given iSCSI 6325 implementation. Generally, the following factors must be 6326 considered before deciding on the proper level of recovery: 6328 Application resilience to I/O failures. 6329 Required level of availability in the face of transport 6330 connection failures. 6331 Probability of transport layer "checksum escape". This in turn 6332 decides the iSCSI digest failure frequency, and thus the 6333 criticality of iSCSI-level error recovery. The details of 6334 estimating this probability are outside the scope of this 6335 document. 6337 A consideration of the above factors for SCSI tape devices as an 6338 example suggests that implementations SHOULD use 6339 ErrorRecoveryLevel=1 when transport connection failure is not a 6340 concern and SCSI level recovery is unavailable, and 6341 ErrorRecoveryLevel=2 when the connection failure is also of high 6342 likelihood during a backup/retrieval. 6344 For extended copy operations, implementations SHOULD use 6345 ErrorRecoveryLevel=2 whenever there is a relatively high likelihood 6346 of connection failure. 6348 10.7. Multi-task Abort Implementation Considerations 6350 Multi-task abort operations are typically issued in emergencies 6351 such as clearing a device lock-up, HA failover/failback etc. In 6352 these circumstances, it is desirable to rapidly go through the 6353 error handling process as opposed to the target waiting on multiple 6354 third-party initiators who may not even be functional anymore - 6355 especially if this emergency is triggered because of one such 6356 initiator failure. Therefore, both iSCSI target and initiator 6357 implementations SHOULD support FastAbort multi-task abort semantics 6358 (Section 4.2.3.4). 6360 Note that both in standard semantics (Section 4.2.3.3) and 6361 FastAbort semantics (Section 4.2.3.4), there may be outstanding 6362 data transfers even after the TMF completion is reported on the 6363 issuing session. In the case of iSCSI/iSER [iSER], these would be 6364 tagged data transfers for STags not owned by any active tasks. 6365 Whether or not real buffers support these data transfers is 6366 implementation-dependent. However, the data transfers logically 6367 MUST be silently discarded by the target iSCSI layer in all cases. 6368 A target MAY, on an implementation-defined internal timeout, also 6369 choose to drop the connections on which it did not receive the 6370 expected Data-Out sequences (Section 4.2.3.3) or NOP-Out 6371 acknowledgements (Section 4.2.3.4) so as to reclaim the associated 6372 buffer, STag, and TTT resources as appropriate. 6374 11. iSCSI PDU Formats 6376 All multi-byte integers that are specified in formats defined in 6377 this document are to be represented in network byte order (i.e., 6378 big endian). Any field that appears in this document assumes that 6379 the most significant byte is the lowest numbered byte and the most 6380 significant bit (within byte or field) is the lowest numbered bit 6381 unless specified otherwise. 6383 Any compliant sender MUST set all bits not defined and all reserved 6384 fields to zero unless specified otherwise. Any compliant receiver 6385 MUST ignore any bit not defined and all reserved fields unless 6386 specified otherwise. Receipt of reserved code values in defined 6387 fields MUST be reported as a protocol error. 6389 Reserved fields are marked by the word "reserved", some 6390 abbreviation of "reserved", or by "." for individual bits when no 6391 other form of marking is technically feasible. 6393 11.1. iSCSI PDU Length and Padding 6395 iSCSI PDUs are padded to the closest integer number of four byte 6396 words. The padding bytes SHOULD be sent as 0. 6398 11.2. PDU Template, Header, and Opcodes 6400 All iSCSI PDUs have one or more header segments and, optionally, a 6401 data segment. After the entire header segment group a header-digest 6402 MAY follow. The data segment MAY also be followed by a data-digest. 6404 The Basic Header Segment (BHS) is the first segment in all of the 6405 iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It 6406 MAY be followed by Additional Header Segments (AHS), a Header- 6407 Digest, a Data Segment, and/or a Data-Digest. 6409 The overall structure of an iSCSI PDU is as follows: 6411 Byte/ 0 | 1 | 2 | 3 | 6412 / | | | | 6413 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6414 +---------------+---------------+---------------+---------------+ 6415 0/ Basic Header Segment (BHS) / 6416 +/ / 6417 +---------------+---------------+---------------+---------------+ 6418 48/ Additional Header Segment 1 (AHS) (optional) / 6419 +/ / 6420 +---------------+---------------+---------------+---------------+ 6421 / Additional Header Segment 2 (AHS) (optional) / 6422 +/ / 6423 +---------------+---------------+---------------+---------------+ 6424 ---- 6425 +---------------+---------------+---------------+---------------+ 6426 / Additional Header Segment n (AHS) (optional) / 6427 +/ / 6428 +---------------+---------------+---------------+---------------+ 6429 ---- 6430 +---------------+---------------+---------------+---------------+ 6431 k/ Header-Digest (optional) / 6432 +/ / 6433 +---------------+---------------+---------------+---------------+ 6434 l/ Data Segment(optional) / 6435 +/ / 6436 +---------------+---------------+---------------+---------------+ 6437 m/ Data-Digest (optional) / 6438 +/ / 6439 +---------------+---------------+---------------+---------------+ 6441 All PDU segments and digests are padded to the closest integer 6442 number of four byte words. For example, all PDU segments and 6443 digests start at a four byte word boundary and the padding ranges 6444 from 0 to 3 bytes. The padding bytes SHOULD be sent as 0. 6446 iSCSI response PDUs do not have AH Segments. 6448 11.2.1. Basic Header Segment (BHS) 6450 The BHS is 48 bytes long. The Opcode and DataSegmentLength fields 6451 appear in all iSCSI PDUs. In addition, when used, the Initiator 6452 Task Tag and Logical Unit Number always appear in the same location 6453 in the header. 6455 The format of the BHS is: 6457 Byte/ 0 | 1 | 2 | 3 | 6458 / | | | | 6459 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6460 +---------------+---------------+---------------+---------------+ 6461 0|.|I| Opcode |F| Opcode-specific fields | 6462 +---------------+---------------+---------------+---------------+ 6463 4|TotalAHSLength | DataSegmentLength | 6464 +---------------+---------------+---------------+---------------+ 6465 8| LUN or Opcode-specific fields | 6466 + + 6467 12| | 6468 +---------------+---------------+---------------+---------------+ 6469 16| Initiator Task Tag | 6470 +---------------+---------------+---------------+---------------+ 6471 20/ Opcode-specific fields / 6472 +/ / 6473 +---------------+---------------+---------------+---------------+ 6474 48 6476 11.2.1.1. I 6478 For request PDUs, the I bit set to 1 is an immediate delivery 6479 marker. 6481 11.2.1.2. Opcode 6483 The Opcode indicates the type of iSCSI PDU the header encapsulates. 6485 The Opcodes are divided into two categories: initiator opcodes and 6486 target opcodes. Initiator opcodes are in PDUs sent by the initiator 6487 (request PDUs). Target opcodes are in PDUs sent by the target 6488 (response PDUs). 6490 Initiators MUST NOT use target opcodes and targets MUST NOT use 6491 initiator opcodes. 6493 Initiator opcodes defined in this specification are: 6495 0x00 NOP-Out 6497 0x01 SCSI Command (encapsulates a SCSI Command Descriptor 6498 Block) 6500 0x02 SCSI Task Management function request 6502 0x03 Login Request 6504 0x04 Text Request 6506 0x05 SCSI Data-out (for WRITE operations) 6508 0x06 Logout Request 6510 0x10 SNACK Request 6512 0x1c-0x1e Vendor specific codes 6514 Target opcodes are: 6516 0x20 NOP-In 6518 0x21 SCSI Response - contains SCSI status and possibly sense 6519 information or other response information. 6521 0x22 SCSI Task Management function response 6523 0x23 Login Response 6525 0x24 Text Response 6527 0x25 SCSI Data-in - for READ operations. 6529 0x26 Logout Response 6531 0x31 Ready To Transfer (R2T) - sent by target when it is ready 6532 to receive data. 6534 0x32 Asynchronous Message - sent by target to indicate certain 6535 special conditions. 6537 0x3c-0x3e Vendor specific codes 6539 0x3f Reject 6541 All other opcodes are reserved. 6543 11.2.1.3. Final (F) bit 6545 When set to 1 it indicates the final (or only) PDU of a sequence. 6547 11.2.1.4. Opcode-specific Fields 6549 These fields have different meanings for different opcode types. 6551 11.2.1.5. TotalAHSLength 6553 Total length of all AHS header segments in units of four byte words 6554 including padding, if any. 6556 The TotalAHSLength is only used in PDUs that have an AHS and MUST 6557 be 0 in all other PDUs. 6559 11.2.1.6. DataSegmentLength 6561 This is the data segment payload length in bytes (excluding 6562 padding). The DataSegmentLength MUST be 0 whenever the PDU has no 6563 data segment. 6565 11.2.1.7. LUN 6567 Some opcodes operate on a specific Logical Unit. The Logical Unit 6568 Number (LUN) field identifies which Logical Unit. If the opcode 6569 does not relate to a Logical Unit, this field is either ignored or 6570 may be used in an opcode specific way. The LUN field is 64-bits and 6571 should be formatted in accordance with [SAM2]. For example, LUN[0] 6572 from [SAM2] is BHS byte 8 and so on up to LUN[7] from [SAM2], which 6573 is BHS byte 15. 6575 11.2.1.8. Initiator Task Tag 6577 The initiator assigns a Task Tag to each iSCSI task it issues. 6578 While a task exists, this tag MUST uniquely identify the task 6579 session-wide. SCSI may also use the initiator task tag as part of 6580 the SCSI task identifier when the timespan during which an iSCSI 6581 initiator task tag must be unique extends over the timespan during 6582 which a SCSI task tag must be unique. However, the iSCSI Initiator 6583 Task Tag must exist and be unique even for untagged SCSI commands. 6585 An ITT value of 0xffffffff is reserved and MUST NOT be assigned for 6586 a task by the initiator. The only instance in which it may be seen 6587 on the wire is in a target-initiated NOP-In PDU (Section 11.19) and 6588 in the initiator response to that PDU, if necessary. 6590 11.2.2. Additional Header Segment (AHS) 6592 The general format of an AHS is: 6594 Byte/ 0 | 1 | 2 | 3 | 6595 / | | | | 6596 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6597 +---------------+---------------+---------------+---------------+ 6598 0| AHSLength | AHSType | AHS-Specific | 6599 +---------------+---------------+---------------+---------------+ 6600 4/ AHS-Specific / 6601 +/ / 6602 +---------------+---------------+---------------+---------------+ 6603 x 6605 11.2.2.1. AHSType 6607 The AHSType field is coded as follows: 6609 bit 0-1 - Reserved 6611 bit 2-7 - AHS code 6613 0 - Reserved 6615 1 - Extended CDB 6616 2 - Expected Bidirectional Read Data Length 6618 3 - 63 Reserved 6620 11.2.2.2. AHSLength 6622 This field contains the effective length in bytes of the AHS 6623 excluding AHSType and AHSLength and padding, if any. The AHS is 6624 padded to the smallest integer number of 4 byte words (i.e., from 0 6625 up to 3 padding bytes). 6627 11.2.2.3. Extended CDB AHS 6629 The format of the Extended CDB AHS is: 6631 Byte/ 0 | 1 | 2 | 3 | 6632 / | | | | 6633 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6634 +---------------+---------------+---------------+---------------+ 6635 0| AHSLength (CDBLength-15) | 0x01 | Reserved | 6636 +---------------+---------------+---------------+---------------+ 6637 4/ ExtendedCDB...+padding / 6638 +/ / 6639 +---------------+---------------+---------------+---------------+ 6640 x 6642 This type of AHS MUST NOT be used if the CDBLength is less than 17. 6643 The length includes the reserved byte 3. 6645 11.2.2.4. Bidirectional Expected Read-Data Length AHS 6647 The format of the Bidirectional Read Expected Data Transfer Length 6648 AHS is: 6650 Byte/ 0 | 1 | 2 | 3 | 6651 / | | | | 6652 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6653 +---------------+---------------+---------------+---------------+ 6654 0| AHSLength (0x0005) | 0x02 | Reserved | 6655 +---------------+---------------+---------------+---------------+ 6656 4| Expected Read-Data Length | 6657 +---------------+---------------+---------------+---------------+ 6658 8 6660 11.2.3. Header Digest and Data Digest 6662 Optional header and data digests protect the integrity of the 6663 header and data, respectively. The digests, if present, are 6664 located, respectively, after the header and PDU-specific data, and 6665 cover respectively the header and the PDU data, each including the 6666 padding bytes, if any. 6668 The existence and type of digests are negotiated during the Login 6669 Phase. 6671 The separation of the header and data digests is useful in iSCSI 6672 routing applications, in which only the header changes when a 6673 message is forwarded. In this case, only the header digest should 6674 be recalculated. 6676 Digests are not included in data or header length fields. 6678 A zero-length Data Segment also implies a zero-length data-digest. 6680 11.2.4. Data Segment 6682 The (optional) Data Segment contains PDU associated data. Its 6683 payload effective length is provided in the BHS field - 6684 DataSegmentLength. The Data Segment is also padded to an integer 6685 number of 4 byte words. 6687 11.3. SCSI Command 6689 The format of the SCSI Command PDU is: 6691 Byte/ 0 | 1 | 2 | 3 | 6692 / | | | | 6693 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6694 +---------------+---------------+---------------+---------------+ 6695 0|.|I| 0x01 |F|R|W|. .|ATTR | Reserved | 6696 +---------------+---------------+---------------+---------------+ 6697 4|TotalAHSLength | DataSegmentLength | 6698 +---------------+---------------+---------------+---------------+ 6699 8| Logical Unit Number (LUN) | 6700 + + 6701 12| | 6702 +---------------+---------------+---------------+---------------+ 6703 16| Initiator Task Tag | 6704 +---------------+---------------+---------------+---------------+ 6705 20| Expected Data Transfer Length | 6706 +---------------+---------------+---------------+---------------+ 6707 24| CmdSN | 6708 +---------------+---------------+---------------+---------------+ 6709 28| ExpStatSN | 6710 +---------------+---------------+---------------+---------------+ 6711 32/ SCSI Command Descriptor Block (CDB) / 6712 +/ / 6713 +---------------+---------------+---------------+---------------+ 6714 48/ AHS (Optional) / 6715 +---------------+---------------+---------------+---------------+ 6716 x/ Header Digest (Optional) / 6717 +---------------+---------------+---------------+---------------+ 6718 y/ (DataSegment, Command Data) (Optional) / 6719 +/ / 6720 +---------------+---------------+---------------+---------------+ 6721 z/ Data Digest (Optional) / 6722 +---------------+---------------+---------------+---------------+ 6724 11.3.1. Flags and Task Attributes (byte 1) 6726 The flags for a SCSI Command are: 6728 bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs 6729 follow this PDU. When F=1 for a write and if Expected Data 6730 Transfer Length is larger than the DataSegmentLength, the 6731 target may solicit additional data through R2T. 6733 bit 1 (R) is set to 1 when the command is expected to input 6734 data. 6736 bit 2 (W) is set to 1 when the command is expected to output 6737 data. 6739 bit 3-4 Reserved. 6741 bit 5-7 contains Task Attributes. 6743 Task Attributes (ATTR) have one of the following integer values 6744 (see [SAM2] for details): 6746 0 - Untagged 6748 1 - Simple 6750 2 - Ordered 6752 3 - Head of Queue 6754 4 - ACA 6756 5-7 - Reserved 6758 Setting both the W and the F bit to 0 is an error. 6759 Either or both of R and W MAY be 1 when either the Expected Data 6760 Transfer Length and/or Bidirectional Read Expected Data Transfer 6761 Length are 0, but they MUST NOT both be 0 when the Expected Data 6762 Transfer Length and/or Bidirectional Read Expected Data Transfer 6763 Length are not 0 (i.e., when some data transfer is expected the 6764 transfer direction is indicated by the R and/or W bit). 6766 11.3.2. CmdSN - Command Sequence Number 6768 Enables ordered delivery across multiple connections in a single 6769 session. 6771 11.3.3. ExpStatSN 6773 Command responses up to ExpStatSN-1 (mod 2**32) have been received 6774 (acknowledges status) on the connection. 6776 11.3.4. Expected Data Transfer Length 6778 For unidirectional operations, the Expected Data Transfer Length 6779 field contains the number of bytes of data involved in this SCSI 6780 operation. For a unidirectional write operation (W flag set to 1 6781 and R flag set to 0), the initiator uses this field to specify the 6782 number of bytes of data it expects to transfer for this operation. 6783 For a unidirectional read operation (W flag set to 0 and R flag set 6784 to 1), the initiator uses this field to specify the number of bytes 6785 of data it expects the target to transfer to the initiator. It 6786 corresponds to the SAM2 byte count. 6788 For bidirectional operations (both R and W flags are set to 1), 6789 this field contains the number of data bytes involved in the write 6790 transfer. For bidirectional operations, an additional header 6791 segment MUST be present in the header sequence that indicates the 6792 Bidirectional Read Expected Data Transfer Length. The Expected 6793 Data Transfer Length field and the Bidirectional Read Expected Data 6794 Transfer Length field correspond to the SAM2 byte count. 6796 If the Expected Data Transfer Length for a write and the length of 6797 the immediate data part that follows the command (if any) are the 6798 same, then no more data PDUs are expected to follow. In this case, 6799 the F bit MUST be set to 1. 6801 If the Expected Data Transfer Length is higher than the 6802 FirstBurstLength (the negotiated maximum amount of unsolicited data 6803 the target will accept), the initiator MUST send the maximum amount 6804 of unsolicited data OR ONLY the immediate data, if any. 6806 Upon completion of a data transfer, the target informs the 6807 initiator (through residual counts) of how many bytes were actually 6808 processed (sent and/or received) by the target. 6810 11.3.5. CDB - SCSI Command Descriptor Block 6812 There are 16 bytes in the CDB field to accommodate the commonly 6813 used CDBs. Whenever the CDB is larger than 16 bytes, an Extended 6814 CDB AHS MUST be used to contain the CDB spillover. 6816 11.3.6. Data Segment - Command Data 6818 Some SCSI commands require additional parameter data to accompany 6819 the SCSI command. This data may be placed beyond the boundary of 6820 the iSCSI header in a data segment. Alternatively, user data 6821 (e.g., from a WRITE operation) can be placed in the data segment 6822 (both cases are referred to as immediate data). These data are 6823 governed by the rules for solicited vs. unsolicited data outlined 6824 in Section 3.2.4.2 - "Data Transfer Overview". 6826 11.4. SCSI Response 6828 The format of the SCSI Response PDU is: 6830 Byte/ 0 | 1 | 2 | 3 | 6831 / | | | | 6832 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6833 +---------------+---------------+---------------+---------------+ 6834 0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status | 6835 +---------------+---------------+---------------+---------------+ 6836 4|TotalAHSLength | DataSegmentLength | 6837 +---------------+---------------+---------------+---------------+ 6838 8| Reserved | 6839 + + 6840 12| | 6841 +---------------+---------------+---------------+---------------+ 6842 16| Initiator Task Tag | 6843 +---------------+---------------+---------------+---------------+ 6844 20| SNACK Tag or Reserved | 6845 +---------------+---------------+---------------+---------------+ 6846 24| StatSN | 6847 +---------------+---------------+---------------+---------------+ 6848 28| ExpCmdSN | 6849 +---------------+---------------+---------------+---------------+ 6850 32| MaxCmdSN | 6851 +---------------+---------------+---------------+---------------+ 6852 36| ExpDataSN or Reserved | 6853 +---------------+---------------+---------------+---------------+ 6854 40| Bidirectional Read Residual Count or Reserved | 6855 +---------------+---------------+---------------+---------------+ 6856 44| Residual Count or Reserved | 6857 +---------------+---------------+---------------+---------------+ 6858 48| Header-Digest (Optional) | 6859 +---------------+---------------+---------------+---------------+ 6860 / Data Segment (Optional) / 6861 +/ / 6862 +---------------+---------------+---------------+---------------+ 6863 | Data-Digest (Optional) | 6864 +---------------+---------------+---------------+---------------+ 6866 11.4.1. Flags (byte 1) 6868 bit 1-2 Reserved. 6870 bit 3 - (o) set for Bidirectional Read Residual Overflow. In 6871 this case, the Bidirectional Read Residual Count indicates 6872 the number of bytes that were not transferred to the 6873 initiator because the initiator's Expected Bidirectional Read 6874 Data Transfer Length was not sufficient. 6876 bit 4 - (u) set for Bidirectional Read Residual Underflow. In 6877 this case, the Bidirectional Read Residual Count indicates 6878 the number of bytes that were not transferred to the 6879 initiator out of the number of bytes expected to be 6880 transferred. 6882 bit 5 - (O) set for Residual Overflow. In this case, the 6883 Residual Count indicates the number of bytes that were not 6884 transferred because the initiator's Expected Data Transfer 6885 Length was not sufficient. For a bidirectional operation, the 6886 Residual Count contains the residual for the write operation. 6888 bit 6 - (U) set for Residual Underflow. In this case, the 6889 Residual Count indicates the number of bytes that were not 6890 transferred out of the number of bytes that were expected to 6891 be transferred. For a bidirectional operation, the Residual 6892 Count contains the residual for the write operation. 6894 bit 7 - (0) Reserved. 6896 Bits O and U and bits o and u are mutually exclusive (i.e., having 6897 both o and u or O and U set to 1 is a protocol error). 6898 For a response other than "Command Completed at Target", bits 3-6 6899 MUST be 0. 6901 11.4.2. Status 6903 The Status field is used to report the SCSI status of the command 6904 (as specified in [SAM2]) and is only valid if the Response Code is 6905 Command Completed at target. 6907 Some of the status codes defined in [SAM2] are: 6909 0x00 GOOD 6910 0x02 CHECK CONDITION 6912 0x08 BUSY 6914 0x18 RESERVATION CONFLICT 6916 0x28 TASK SET FULL 6918 0x30 ACA ACTIVE 6920 0x40 TASK ABORTED 6922 See [SAM2] for the complete list and definitions. 6924 If a SCSI device error is detected while data from the initiator is 6925 still expected (the command PDU did not contain all the data and 6926 the target has not received a Data PDU with the final bit Set), the 6927 target MUST wait until it receives a Data PDU with the F bit set in 6928 the last expected sequence before sending the Response PDU. 6930 11.4.3. Response 6932 This field contains the iSCSI service response. 6934 iSCSI service response codes defined in this specification are: 6936 0x00 - Command Completed at Target 6938 0x01 - Target Failure 6940 0x80-0xff - Vendor specific 6942 All other response codes are reserved. 6944 The Response is used to report a Service Response. The mapping of 6945 the response code into a SCSI service response code value, if 6946 needed, is outside the scope of this document. However, in symbolic 6947 terms response value 0x00 maps to the SCSI service response (see 6948 [SAM2] and [SPC3]) of TASK COMPLETE or LINKED COMMAND COMPLETE. All 6949 other Response values map to the SCSI service response of SERVICE 6950 DELIVERY OR TARGET FAILURE. 6952 If a SCSI Response PDU does not arrive before the session is 6953 terminated, the SCSI service response is SERVICE DELIVERY OR TARGET 6954 FAILURE. 6956 A non-zero response field indicates a failure to execute the 6957 command in which case the Status and Flag fields are undefined. 6959 11.4.4. SNACK Tag 6961 This field contains a copy of the SNACK Tag of the last SNACK Tag 6962 accepted by the target on the same connection and for the command 6963 for which the response is issued. Otherwise it is reserved and 6964 should be set to 0. 6966 After issuing a R-Data SNACK the initiator must discard any SCSI 6967 status unless contained in an SCSI Response PDU carrying the same 6968 SNACK Tag as the last issued R-Data SNACK for the SCSI command on 6969 the current connection. 6971 For a detailed discussion on R-Data SNACK see SNACK. 6973 11.4.5. Residual Count 6975 11.4.5.1. Field Semantics 6977 The Residual Count field MUST be valid in the case where either the 6978 U bit or the O bit is set. If neither bit is set, the Residual 6979 Count field is reserved. Targets may set the residual count and 6980 initiators may use it when the response code is "completed at 6981 target" (even if the status returned is not GOOD). If the O bit is 6982 set, the Residual Count indicates the number of bytes that were not 6983 transferred because the initiator's Expected Data Transfer Length 6984 was not sufficient. If the U bit is set, the Residual Count 6985 indicates the number of bytes that were not transferred out of the 6986 number of bytes expected to be transferred. 6988 11.4.5.2. Residuals Concepts Overview 6990 SCSI-Presented Data Transfer Length (SPDTL) is the term this 6991 document uses (see Section 1.1 for definition) to represent the 6992 aggregate data length that the target SCSI layer attempts to 6993 transfer using the local iSCSI layer for a task. Expected Data 6994 Transfer Length (EDTL) is the iSCSI term that represents the length 6995 of data that the iSCSI layer expects to transfer for a task. EDTL 6996 is specified in the SCSI Command PDU. 6998 When SPDTL = EDTL for a task, the target iSCSI layer completes the 6999 task with no residuals. Whenever SPDTL differs from EDTL for a 7000 task, that task is said to have a residual. 7002 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the 7003 SCSI Response PDU as specified in Section 11.4.5.1. The Residual 7004 Count MUST be set to the numerical value of (SPDTL - EDTL). 7006 If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the 7007 SCSI Response PDU as specified in Section 11.4.5.1. The Residual 7008 Count MUST be set to the numerical value of (EDTL - SPDTL). 7010 Note that the Overflow and Underflow scenarios are independent of 7011 Data-In and Data-Out. Either scenario is logically possible in 7012 either direction of data transfer. 7014 11.4.5.3. SCSI REPORT LUNS and Residual Overflow 7016 This section discusses the residual overflow issues citing the 7017 example of the SCSI REPORT LUNS command. Note however that there 7018 are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH 7019 fields following the same underlying rules. The semantics in the 7020 rest of the section apply to all such SCSI commands. 7022 The specification of the SCSI REPORT LUNS command requires that the 7023 SCSI target limit the amount of data transferred to a maximum size 7024 (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS 7025 CDB. 7027 If the Expected Data Transfer Length (EDTL) in the iSCSI header of 7028 the SCSI Command PDU for a REPORT LUNS command is set to at least 7029 as large as that ALLOCATION LENGTH, the SCSI layer truncation 7030 prevents an iSCSI Residual Overflow from occurring. A SCSI 7031 initiator can detect that such truncation has occurred via other 7032 information at theS CSI layer. The rest of the section elaborates 7033 this required behavior. 7035 The SCSI REPORT LUNS command requests a target SCSI layer to return 7036 a logical unit inventory (LUN list) to the initiator SCSI layer 7037 (see Section 6.21 of [SPC3]). The size of this LUN list may not be 7038 known to the initiator SCSI layer when it issues the REPORT LUNS 7039 command; to avoid transferring more LUN list data than the 7040 initiator is prepared for, the REPORT LUNS CDB contains an 7041 ALLOCATION LENGTH field to specify the maximum amount of data to be 7042 transferred to the initiator for this command. If the initiator 7043 SCSI layer has underestimated the number of logical units at the 7044 target, it is possible that the complete logical unit inventory 7045 does not fit in the specified ALLOCATION LENGTH. In this situation, 7046 Section 4.3.3.6 in [SPC3] requires that the target SCSI layer 7047 "shall terminate transfers to the Data-In Buffer" when the number 7048 of bytes specified by the ALLOCATION LENGTH field have been 7049 transferred. 7051 Therefore, in response to a REPORT LUNS command, the SCSI layer at 7052 the target presents at most ALLOCATION LENGTH bytes of data 7053 (logical unit inventory) to iSCSI for transfer to the initiator. 7054 For a REPORT LUNS command, if the iSCSI EDTL is at least as large 7055 as the ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL 7056 will accommodate all of the data to be transferred. If all of the 7057 logical unit inventory data presented to the iSCSI layer -- i.e., 7058 the data remaining after any SCSI truncation -- is transferred to 7059 the initiator by the iSCSI layer, an iSCSI Residual Overflow has 7060 not occurred and the iSCSI (O) bit MUST NOT be set in the SCSI 7061 Response or final SCSI Data-Out PDU. Note that this behavior is 7062 implied by the combination of Section 11.4.5.1 along with the 7063 specification of the REPORT LUNS command in [SPC3]. However, if the 7064 iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario, 7065 note that the iSCSI Underflow MUST be signaled in the SCSI Response 7066 PDU. An iSCSI Underflow MUST also be signaled when the iSCSI EDTL 7067 is equal to the ALLOCATION LENGTH but the logical unit inventory 7068 data presented to the iSCSI layer is smaller than the ALLOCATION 7069 LENGTH. 7071 The LUN LIST LENGTH field in the logical unit inventory (the first 7072 field in the inventory) is not affected by truncation of the 7073 inventory to fit in ALLOCATION LENGTH; this enables a SCSI 7074 initiator to determine that the received inventory is incomplete by 7075 noticing that the LUN LIST LENGTH in the inventory is larger than 7076 the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A 7077 common initiator behavior in this situation is to re-issue the 7078 REPORT LUNS command with a larger ALLOCATION LENGTH. 7080 11.4.6. Bidirectional Read Residual Count 7082 The Bidirectional Read Residual Count field MUST be valid in the 7083 case where either the u bit or the o bit is set. If neither bit is 7084 set, the Bidirectional Read Residual Count field is reserved. 7085 Targets may set the Bidirectional Read Residual Count and 7086 initiators may use it when the response code is "completed at 7087 target". If the o bit is set, the Bidirectional Read Residual Count 7088 indicates the number of bytes that were not transferred to the 7089 initiator because the initiator's Expected Bidirectional Read 7090 Transfer Length was not sufficient. If the u bit is set, the 7091 Bidirectional Read Residual Count indicates the number of bytes 7092 that were not transferred to the initiator out of the number of 7093 bytes expected to be transferred. 7095 11.4.7. Data Segment - Sense and Response Data Segment 7097 iSCSI targets MUST support and enable autosense. If Status is CHECK 7098 CONDITION (0x02), then the Data Segment MUST contain sense data for 7099 the failed command. 7101 For some iSCSI responses, the response data segment MAY contain 7102 some response related information, (e.g., for a target failure, it 7103 may contain a vendor specific detailed description of the failure). 7105 If the DataSegmentLength is not 0, the format of the Data Segment 7106 is as follows: 7108 Byte/ 0 | 1 | 2 | 3 | 7109 / | | | | 7110 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7111 +---------------+---------------+---------------+---------------+ 7112 0|SenseLength | Sense Data | 7113 +---------------+---------------+---------------+---------------+ 7114 x/ Sense Data / 7115 +---------------+---------------+---------------+---------------+ 7116 y/ Response Data / 7117 / / 7118 +---------------+---------------+---------------+---------------+ 7119 z| 7121 11.4.7.1. SenseLength 7123 Length of Sense Data. 7125 11.4.7.2. Sense Data 7127 The Sense Data contains detailed information about a check 7128 condition and [SPC3] specifies the format and content of the Sense 7129 Data. 7131 Certain iSCSI conditions result in the command being terminated at 7132 the target (response Command Completed at Target) with a SCSI Check 7133 Condition Status as outlined in the next table: 7135 +--------------------------+----------+---------------------------+ 7136 | iSCSI Condition |Sense | Additional Sense Code & | 7137 | |Key | Qualifier | 7138 +--------------------------+----------+---------------------------+ 7139 | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c | 7140 | data |Command-0B| Write Error | 7141 +--------------------------+----------+---------------------------+ 7142 | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d | 7143 | |Command-0B| Write Error | 7144 +--------------------------+----------+---------------------------+ 7145 | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 | 7146 | error |Command-0B| CRC Error Detected | 7147 +--------------------------+----------+---------------------------+ 7148 | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 | 7149 | |Command-0B| Read Error | 7150 +--------------------------+----------+---------------------------+ 7152 The target reports the "Incorrect amount of data" condition if 7153 during data output the total data length to output is greater than 7154 FirstBurstLength and the initiator sent unsolicited non-immediate 7155 data but the total amount of unsolicited data is different than 7156 FirstBurstLength. The target reports the same error when the amount 7157 of data sent as a reply to an R2T does not match the amount 7158 requested. 7160 11.4.8. ExpDataSN 7162 The number of Data-In (read) PDUs the target has sent for the 7163 command. 7165 This field MUST be 0 if the response code is not Command Completed 7166 at Target or the target sent no Data-In PDUs for the command. 7167 11.4.9. StatSN - Status Sequence Number 7169 StatSN is a Sequence Number that the target iSCSI layer generates 7170 per connection and that in turn, enables the initiator to 7171 acknowledge status reception. StatSN is incremented by 1 for every 7172 response/status sent on a connection except for responses sent as a 7173 result of a retry or SNACK. In the case of responses sent due to a 7174 retransmission request, the StatSN MUST be the same as the first 7175 time the PDU was sent unless the connection has since been 7176 restarted. 7178 11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator 7180 ExpCmdSN is a Sequence Number that the target iSCSI returns to the 7181 initiator to acknowledge command reception. It is used to update a 7182 local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1 7183 indicates that the target cannot accept new commands. 7185 11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 7187 MaxCmdSN is a Sequence Number that the target iSCSI returns to the 7188 initiator to indicate the maximum CmdSN the initiator can send. It 7189 is used to update a local variable with the same name. If MaxCmdSN 7190 is equal to ExpCmdSN-1, this indicates to the initiator that the 7191 target cannot receive any additional commands. When MaxCmdSN 7192 changes at the target while the target has no pending PDUs to 7193 convey this information to the initiator, it MUST generate a NOP-IN 7194 to carry the new MaxCmdSN. 7196 11.5. Task Management Function Request 7198 Byte/ 0 | 1 | 2 | 3 | 7199 / | | | | 7200 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7201 +---------------+---------------+---------------+---------------+ 7202 0|.|I| 0x02 |1| Function | Reserved | 7203 +---------------+---------------+---------------+---------------+ 7204 4|TotalAHSLength | DataSegmentLength | 7205 +---------------+---------------+---------------+---------------+ 7206 8| Logical Unit Number (LUN) or Reserved | 7207 + + 7208 12| | 7209 +---------------+---------------+---------------+---------------+ 7210 16| Initiator Task Tag | 7211 +---------------+---------------+---------------+---------------+ 7212 20| Referenced Task Tag or 0xffffffff | 7213 +---------------+---------------+---------------+---------------+ 7214 24| CmdSN | 7215 +---------------+---------------+---------------+---------------+ 7216 28| ExpStatSN | 7217 +---------------+---------------+---------------+---------------+ 7218 32| RefCmdSN or Reserved | 7219 +---------------+---------------+---------------+---------------+ 7220 36| ExpDataSN or Reserved | 7221 +---------------+---------------+---------------+---------------+ 7222 40/ Reserved / 7223 +/ / 7224 +---------------+---------------+---------------+---------------+ 7225 48| Header-Digest (Optional) | 7226 +---------------+---------------+---------------+---------------+ 7228 11.5.1. Function 7230 The Task Management functions provide an initiator with a way to 7231 explicitly control the execution of one or more Tasks (SCSI and 7232 iSCSI tasks). The Task Management function codes are listed below. 7233 For a more detailed description of SCSI task management, see 7234 [SAM2]. 7236 1 - ABORT TASK - aborts the task identified by the Referenced 7237 Task Tag field. 7239 2 - ABORT TASK SET - aborts all Tasks issued via this session 7240 on the logical unit. 7242 3 - CLEAR ACA - clears the Auto Contingent Allegiance 7243 condition. 7245 4 - CLEAR TASK SET - aborts all Tasks in the appropriate task 7246 set as defined by the TST field in the Control mode page (see 7247 [SPC3]). 7249 5 - LOGICAL UNIT RESET 7251 6 - TARGET WARM RESET 7253 7 - TARGET COLD RESET 7255 8 - TASK REASSIGN - reassigns connection allegiance for the 7256 task identified by the Initiator Task Tag field to this 7257 connection, thus resuming the iSCSI exchanges for the task. 7259 For all these functions, the Task Management function response MUST 7260 be returned as detailed in Section 11.6. All these functions apply 7261 to the referenced tasks regardless of whether they are proper SCSI 7262 tasks or tagged iSCSI operations. Task management requests must 7263 act on all the commands from the same session having a CmdSN lower 7264 than the task management CmdSN. LOGICAL UNIT RESET, TARGET WARM 7265 RESET and TARGET COLD RESET may affect commands from other sessions 7266 or commands from the same session regardless of their CmdSN value. 7268 If the task management request is marked for immediate delivery, it 7269 must be considered immediately for execution, but the operations 7270 involved (all or part of them) may be postponed to allow the target 7271 to receive all relevant tasks. According to [SAM2], for all the 7272 tasks covered by the Task Management response (i.e., with CmdSN 7273 lower than the task management command CmdSN) but except the Task 7274 Management response to a TASK REASSIGN, additional responses MUST 7275 NOT be delivered to the SCSI layer after the Task Management 7276 response. The iSCSI initiator MAY deliver to the SCSI layer all 7277 responses received before the Task Management response (i.e., it is 7278 a matter of implementation if the SCSI responses, received before 7279 the Task Management response but after the task management request 7280 was issued, are delivered to the SCSI layer by the iSCSI layer in 7281 the initiator). The iSCSI target MUST ensure that no responses for 7282 the tasks covered by a task management function are delivered to 7283 the iSCSI initiator after the Task Management response except for a 7284 task covered by a TASK REASSIGN. 7286 For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST 7287 continue to respond to all valid target transfer tags (received via 7288 R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to the 7289 affected task set, even after issuing the task management request. 7290 The issuing initiator SHOULD however terminate (i.e., by setting 7291 the F-bit to 1) these response sequences as quickly as possible. 7292 The target on its part MUST wait for responses on all affected 7293 target transfer tags before acting on either of these two task 7294 management requests. In case all or part of the response sequence 7295 is not received (due to digest errors) for a valid TTT, the target 7296 MAY treat it as a case of within-command error recovery class (see 7297 Section 6.1.4.1 - "Recovery Within-command") if it is supporting 7298 ErrorRecoveryLevel >= 1, or alternatively may drop the connection 7299 to complete the requested task set function. 7301 If an ABORT TASK is issued for a task created by an immediate 7302 command then RefCmdSN MUST be that of the Task Management request 7303 itself (i.e. CmdSN and RefCmdSN are equal); otherwise RefCmdSN MUST 7304 be set to the CmdSN of the task to be aborted (lower than CmdSN). 7306 If the connection is still active (it is not undergoing an implicit 7307 or explicit logout), ABORT TASK MUST be issued on the same 7308 connection to which the task to be aborted is allegiant at the time 7309 the Task Management Request is issued. If the connection is 7310 implicitly or explicitly logged out (i.e., no other request will be 7311 issued on the failing connection and no other response will be 7312 received on the failing connection), then an ABORT TASK function 7313 request may be issued on another connection. This Task Management 7314 request will then establish a new allegiance for the command to be 7315 aborted as well as abort it (i.e., the task to be aborted will not 7316 have to be retried or reassigned, and its status, if sent but not 7317 acknowledged, will be resent followed by the Task Management 7318 response). 7320 At the target an ABORT TASK function MUST NOT be executed on a Task 7321 Management request; such a request MUST result in Task Management 7322 response of "Function rejected". 7324 For the LOGICAL UNIT RESET function, the target MUST behave as 7325 dictated by the Logical Unit Reset function in [SAM2]. 7327 The implementation of the TARGET WARM RESET function and the TARGET 7328 COLD RESET function is OPTIONAL and when implemented, should act as 7329 described below. The TARGET WARM RESET is also subject to SCSI 7330 access controls on the requesting initiator as defined in [SPC3]. 7331 When authorization fails at the target, the appropriate response as 7332 described in Targe MUST be returned by the target. The TARGET COLD 7333 RESET function is not subject to SCSI access controls, but its 7334 execution privileges may be managed by iSCSI mechanisms such as 7335 login authentication. 7337 When executing the TARGET WARM RESET and TARGET COLD RESET 7338 functions, the target cancels all pending operations on all Logical 7339 Units known by the issuing initiator. Both functions are equivalent 7340 to the Target Reset function specified by [SAM2]. They can affect 7341 many other initiators logged in with the servicing SCSI target 7342 port. 7344 The target MUST treat the TARGET COLD RESET function additionally 7345 as a power on event, thus terminating all of its TCP connections to 7346 all initiators (all sessions are terminated). For this reason, the 7347 Service Response (defined by [SAM2]) for this SCSI task management 7348 function may not be reliably delivered to the issuing initiator 7349 port. 7351 For the TASK REASSIGN function, the target should reassign the 7352 connection allegiance to this new connection (and thus resume iSCSI 7353 exchanges for the task). TASK REASSIGN MUST ONLY be received by the 7354 target after the connection on which the command was previously 7355 executing has been successfully logged-out. The Task Management 7356 response MUST be issued before the reassignment becomes effective. 7357 For additional usage semantics see Section 6.2 - "Retry and 7358 Reassign in Recovery". 7360 At the target a TASK REASSIGN function request MUST NOT be executed 7361 to reassign the connection allegiance of a Task Management function 7362 request, an active text negotiation task, or a Logout task; such a 7363 request MUST result in Task Management response of "Function 7364 rejected". 7366 TASK REASSIGN MUST be issued as an immediate command. 7368 11.5.2. TotalAHSLength and DataSegmentLength 7370 For this PDU, TotalAHSLength and DataSegmentLength MUST be 0. 7372 11.5.3. LUN 7374 This field is required for functions that address a specific LU 7375 (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL 7376 UNIT RESET) and is reserved in all others. 7378 11.5.4. Referenced Task Tag 7380 The Initiator Task Tag of the task to be aborted for the ABORT TASK 7381 function or reassigned for the TASK REASSIGN function. For all the 7382 other functions this field MUST be set to the reserved value 7383 0xffffffff. 7385 11.5.5. RefCmdSN 7387 If an ABORT TASK is issued for a task created by an immediate 7388 command then RefCmdSN MUST be that of the Task Management request 7389 itself (i.e. CmdSN and RefCmdSN are equal). 7391 For an ABORT TASK of a task created by non-immediate command 7392 RefCmdSN MUST be set to the CmdSN of the task identified by the 7393 Referenced Task Tag field. Targets must use this field as described 7394 in Res when the task identified by the Referenced Task Tag field is 7395 not with the target. 7397 Otherwise, this field is reserved. 7399 11.5.6. ExpDataSN 7401 For recovery purposes, the iSCSI target and initiator maintain a 7402 data acknowledgement reference number - the first input DataSN 7403 number unacknowledged by the initiator. When issuing a new command, 7404 this number is set to 0. If the function is TASK REASSIGN, which 7405 establishes a new connection allegiance for a previously issued 7406 Read or Bidirectional command, ExpDataSN will contain an updated 7407 data acknowledgement reference number or the value 0; the latter 7408 indicating that the data acknowledgement reference number is 7409 unchanged. The initiator MUST discard any data PDUs from the 7410 previous execution that it did not acknowledge and the target MUST 7411 transmit all Data-in PDUs (if any) starting with the data 7412 acknowledgement reference number. The number of retransmitted PDUs 7413 may or may not be the same as the original transmission depending 7414 on if there was a change in MaxRecvDataSegmentLength in the 7415 reassignment. The target MAY also send no more Data-In PDUs if all 7416 data has been acknowledged. 7418 The value of ExpDataSN MUST be 0 or higher than the DataSN of the 7419 last acknowledged Data-In PDU, but not larger than DataSN+1 of the 7420 last Data-IN PDU sent by the target. Any other value MUST be 7421 ignored by the target. 7423 For other functions this field is reserved. 7425 11.6. Task Management Function Response 7426 Byte/ 0 | 1 | 2 | 3 | 7427 / | | | | 7428 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7429 +---------------+---------------+---------------+---------------+ 7430 0|.|.| 0x22 |1| Reserved | Response | Reserved | 7431 +---------------+---------------+---------------+---------------+ 7432 4|TotalAHSLength | DataSegmentLength | 7433 +---------------------------------------------------------------+ 7434 8/ Reserved / 7435 / / 7436 +---------------+---------------+---------------+---------------+ 7437 16| Initiator Task Tag | 7438 +---------------+---------------+---------------+---------------+ 7439 20| Reserved | 7440 +---------------+---------------+---------------+---------------+ 7441 24| StatSN | 7442 +---------------+---------------+---------------+---------------+ 7443 28| ExpCmdSN | 7444 +---------------+---------------+---------------+---------------+ 7445 32| MaxCmdSN | 7446 +---------------+---------------+---------------+---------------+ 7447 36/ Reserved / 7448 +/ / 7449 +---------------+---------------+---------------+---------------+ 7450 48| Header-Digest (Optional) | 7451 +---------------+---------------+---------------+---------------+ 7453 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK 7454 SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET and 7455 TASK REASSIGN, the target performs the requested Task Management 7456 function and sends a Task Management response back to the 7457 initiator. For TASK REASSIGN, the new connection allegiance MUST 7458 ONLY become effective at the target after the target issues the 7459 Task Management Response. 7461 11.6.1. Response 7463 The target provides a Response, which may take on the following 7464 values: 7466 0 - Function complete. 7467 1 - Task does not exist. 7469 2 - LUN does not exist. 7470 3 - Task still allegiant. 7471 4 - Task allegiance reassignment not supported. 7472 5 - Task management function not supported. 7473 6 - Function authorization failed. 7474 255 - Function rejected. 7476 All other values are reserved. 7478 For a discussion on usage of response codes 3 and 4, see Section 7479 6.2.2 - "Allegiance Reassignment". 7481 For the TARGET COLD RESET and TARGET WARM RESET functions, the 7482 target cancels all pending operations across all Logical Units 7483 known to the issuing initiator. For the TARGET COLD RESET 7484 function, the target MUST then close all of its TCP connections to 7485 all initiators (terminates all sessions). 7487 The mapping of the response code into a SCSI service response code 7488 value, if needed, is outside the scope of this document. However, 7489 in symbolic terms Response values 0 and 1 map to the SCSI service 7490 response of FUNCTION COMPLETE. All other Response values map to 7491 the SCSI service response of FUNCTION REJECTED. If a Task 7492 Management function response PDU does not arrive before the session 7493 is terminated, the SCSI service response is SERVICE DELIVERY OR 7494 TARGET FAILURE. 7496 The response to ABORT TASK SET and CLEAR TASK SET MUST only be 7497 issued by the target after all of the commands affected have been 7498 received by the target, the corresponding task management functions 7499 have been executed by the SCSI target, and the delivery of all 7500 responses delivered until the task management function completion 7501 have been confirmed (acknowledged through ExpStatSN) by the 7502 initiator on all connections of this session. For the exact 7503 timeline of events, refer to Section 4.2.3.3 and Section 4.2.3.4. 7505 For the ABORT TASK function, 7507 If the Referenced Task Tag identifies a valid task leading to a 7508 successful termination, then targets must return the 7509 "Function complete" response. 7511 If the Referenced Task Tag does not identify an existing task, 7512 but if the CmdSN indicated by the RefCmdSN field in the Task 7513 Management function request is within the valid CmdSN window 7514 and less than the CmdSN of the Task Management function 7515 request itself, then targets must consider the CmdSN 7516 received and return the "Function complete" response. 7517 If the Referenced Task Tag does not identify an existing task 7518 and if the CmdSN indicated by the RefCmdSN field in the Task 7519 Management function request is outside the valid CmdSN 7520 window, then targets must return the "Task does not exist" 7521 response. 7523 For response semantics on function types that can potentially 7524 impact multiple active tasks on the target, see Section 4.2.3. 7526 11.6.2. TotalAHSLength and DataSegmentLength 7528 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7530 11.7. SCSI Data-out & SCSI Data-in 7532 The SCSI Data-out PDU for WRITE operations has the following 7533 format: 7535 Byte/ 0 | 1 | 2 | 3 | 7536 / | | | | 7537 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7538 +---------------+---------------+---------------+---------------+ 7539 0|.|.| 0x05 |F| Reserved | 7540 +---------------+---------------+---------------+---------------+ 7541 4|TotalAHSLength | DataSegmentLength | 7542 +---------------+---------------+---------------+---------------+ 7543 8| LUN or Reserved | 7544 + + 7545 12| | 7546 +---------------+---------------+---------------+---------------+ 7547 16| Initiator Task Tag | 7548 +---------------+---------------+---------------+---------------+ 7549 20| Target Transfer Tag or 0xffffffff | 7550 +---------------+---------------+---------------+---------------+ 7551 24| Reserved | 7552 +---------------+---------------+---------------+---------------+ 7553 28| ExpStatSN | 7554 +---------------+---------------+---------------+---------------+ 7555 32| Reserved | 7556 +---------------+---------------+---------------+---------------+ 7557 36| DataSN | 7558 +---------------+---------------+---------------+---------------+ 7559 40| Buffer Offset | 7560 +---------------+---------------+---------------+---------------+ 7561 44| Reserved | 7562 +---------------+---------------+---------------+---------------+ 7563 48| Header-Digest (Optional) | 7564 +---------------+---------------+---------------+---------------+ 7565 / DataSegment / 7566 +/ / 7567 +---------------+---------------+---------------+---------------+ 7568 | Data-Digest (Optional) | 7569 +---------------+---------------+---------------+---------------+ 7571 The SCSI Data-in PDU for READ operations has the following format: 7573 Byte/ 0 | 1 | 2 | 3 | 7574 / | | | | 7575 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7576 +---------------+---------------+---------------+---------------+ 7577 0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd | 7578 +---------------+---------------+---------------+---------------+ 7579 4|TotalAHSLength | DataSegmentLength | 7580 +---------------+---------------+---------------+---------------+ 7581 8| LUN or Reserved | 7582 + + 7583 12| | 7584 +---------------+---------------+---------------+---------------+ 7585 16| Initiator Task Tag | 7586 +---------------+---------------+---------------+---------------+ 7587 20| Target Transfer Tag or 0xffffffff | 7588 +---------------+---------------+---------------+---------------+ 7589 24| StatSN or Reserved | 7590 +---------------+---------------+---------------+---------------+ 7591 28| ExpCmdSN | 7592 +---------------+---------------+---------------+---------------+ 7593 32| MaxCmdSN | 7594 +---------------+---------------+---------------+---------------+ 7595 36| DataSN | 7596 +---------------+---------------+---------------+---------------+ 7597 40| Buffer Offset | 7598 +---------------+---------------+---------------+---------------+ 7599 44| Residual Count | 7600 +---------------+---------------+---------------+---------------+ 7601 48| Header-Digest (Optional) | 7602 +---------------+---------------+---------------+---------------+ 7603 / DataSegment / 7604 +/ / 7605 +---------------+---------------+---------------+---------------+ 7606 | Data-Digest (Optional) | 7607 +---------------+---------------+---------------+---------------+ 7609 Status can accompany the last Data-in PDU if the command did not 7610 end with an exception (i.e., the status is "good status" - GOOD, 7611 CONDITION MET or INTERMEDIATE CONDITION MET). The presence of 7612 status (and of a residual count) is signaled though the S flag bit. 7614 Although targets MAY choose to send even non-exception status in 7615 separate responses, initiators MUST support non-exception status in 7616 Data-In PDUs. 7618 11.7.1. F (Final) Bit 7620 For outgoing data, this bit is 1 for the last PDU of unsolicited 7621 data or the last PDU of a sequence that answers an R2T. 7623 For incoming data, this bit is 1 for the last input (read) data PDU 7624 of a sequence. Input can be split into several sequences, each 7625 having its own F bit. Splitting the data stream into sequences does 7626 not affect DataSN counting on Data-In PDUs. It MAY be used as a 7627 "change direction" indication for Bidirectional operations that 7628 need such a change. 7630 DataSegmentLength MUST NOT exceed MaxRecvDataSegmentLength for the 7631 direction it is sent and the total of all the DataSegmentLength of 7632 all PDUs in a sequence MUST NOT exceed MaxBurstLength (or 7633 FirstBurstLength for unsolicited data). However the number of 7634 individual PDUs in a sequence (or in total) may be higher than the 7635 MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength 7636 ratio (as PDUs may be limited in length by the sender 7637 capabilities). Using DataSegmentLength of 0 may increase beyond 7638 what is reasonable for the number of PDUs and should therefore be 7639 avoided. 7641 For Bidirectional operations, the F bit is 1 for both the end of 7642 the input sequences and the end of the output sequences. 7644 11.7.2. A (Acknowledge) bit 7646 For sessions with ErrorRecoveryLevel 1 or higher, the target sets 7647 this bit to 1 to indicate that it requests a positive 7648 acknowledgement from the initiator for the data received. The 7649 target should use the A bit moderately; it MAY only set the A bit 7650 to 1 once every MaxBurstLength bytes, or on the last Data-In PDU 7651 that concludes the entire requested read data transfer for the task 7652 from the target's perspective, and it MUST NOT do so more 7653 frequently. The target MUST NOT set to 1 the A bit for sessions 7654 with ErrorRecoveryLevel=0. The initiator MUST ignore the A bit set 7655 to 1 for sessions with ErrorRecoveryLevel=0. 7657 On receiving a Data-In PDU with the A bit set to 1 on a session 7658 with ErrorRecoveryLevel greater than 0, if there are no holes in 7659 the read data until that Data-In PDU, the initiator MUST issue a 7660 SNACK of type DataACK except when it is able to acknowledge the 7661 status for the task immediately via ExpStatSN on other outbound 7662 PDUs if the status for the task is also received. In the latter 7663 case (acknowledgement through ExpStatSN), sending a SNACK of type 7664 DataACK in response to the A bit is OPTIONAL, but if it is done, it 7665 must not be sent after the status acknowledgement through 7666 ExpStatSN. If the initiator has detected holes in the read data 7667 prior to that Data-In PDU, it MUST postpone issuing the SNACK of 7668 type DataACK until the holes are filled. An initiator also MUST NOT 7669 acknowledge the status for the task before those holes are filled. 7670 A status acknowledgement for a task that generated the Data-In PDUs 7671 is considered by the target as an implicit acknowledgement of the 7672 Data-In PDUs if such an acknowledgement was requested by the 7673 target. 7675 11.7.3. Flags (byte 1) 7677 The last SCSI Data packet sent from a target to an initiator for a 7678 SCSI command that completed successfully (with a status of GOOD, 7679 CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may also 7680 optionally contain the Status for the data transfer. In this case, 7681 Sense Data cannot be sent together with the Command Status. If the 7682 command is completed with an error, then the response and sense 7683 data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in 7684 a SCSI Data packet). For Bidirectional commands, the status MUST be 7685 sent in a SCSI Response PDU. 7687 bit 2-4 - Reserved. 7689 bit 5-6 - used the same as in a SCSI Response. These bits are 7690 only valid when S is set to 1. For details see SNACK . 7692 bit 7 S (status)- set to indicate that the Command Status field 7693 contains status. If this bit is set to 1, the F bit MUST also 7694 be set to 1. 7696 The fields StatSN, Status, and Residual Count only have meaningful 7697 content if the S bit is set to 1 and their values are defined in 7698 SNACK . 7700 11.7.4. Target Transfer Tag and LUN 7702 On outgoing data, the Target Transfer Tag is provided to the target 7703 if the transfer is honoring an R2T. In this case, the Target 7704 Transfer Tag field is a replica of the Target Transfer Tag provided 7705 with the R2T. 7707 On incoming data, the Target Transfer Tag and LUN MUST be provided 7708 by the target if the A bit is set to 1; otherwise they are 7709 reserved. The Target Transfer Tag and LUN are copied by the 7710 initiator into the SNACK of type DataACK that it issues as a result 7711 of receiving a SCSI Data-in PDU with the A bit set to 1. 7713 The Target Transfer Tag values are not specified by this protocol 7714 except that the value 0xffffffff is reserved and means that the 7715 Target Transfer Tag is not supplied. If the Target Transfer Tag is 7716 provided, then the LUN field MUST hold a valid value and be 7717 consistent with whatever was specified with the command; otherwise, 7718 the LUN field is reserved. 7720 11.7.5. DataSN 7722 For input (read) or bidirectional Data-In PDUs, the DataSN is the 7723 input PDU number within the data transfer for the command 7724 identified by the Initiator Task Tag. 7726 R2T and Data-In PDUs, in the context of bidirectional commands, 7727 share the numbering sequence (see Section 3.2.2.4 - "Data 7728 Sequencing"). 7730 For output (write) data PDUs, the DataSN is the Data-Out PDU number 7731 within the current output sequence. The current output sequence is 7732 either identified by the Initiator Task Tag (for unsolicited data) 7733 or is a data sequence generated for one R2T (for data solicited 7734 through R2T). 7736 11.7.6. Buffer Offset 7738 The Buffer Offset field contains the offset of this PDU payload 7739 data within the complete data transfer. The sum of the buffer 7740 offset and length should not exceed the expected transfer length 7741 for the command. 7743 The order of data PDUs within a sequence is determined by 7744 DataPDUInOrder. When set to Yes, it means that PDUs have to be in 7745 increasing Buffer Offset order and overlays are forbidden. 7747 The ordering between sequences is determined by 7748 DataSequenceInOrder. When set to Yes, it means that sequences have 7749 to be in increasing Buffer Offset order and overlays are forbidden. 7751 11.7.7. DataSegmentLength 7753 This is the data payload length of a SCSI Data-In or SCSI Data-Out 7754 PDU. The sending of 0 length data segments should be avoided, but 7755 initiators and targets MUST be able to properly receive 0 length 7756 data segments. 7758 The Data Segments of Data-in and Data-out PDUs SHOULD be filled to 7759 the integer number of 4 byte words (real payload) unless the F bit 7760 is set to 1. 7762 11.8. Ready To Transfer (R2T) 7764 Byte/ 0 | 1 | 2 | 3 | 7765 / | | | | 7766 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7767 +---------------+---------------+---------------+---------------+ 7768 0|.|.| 0x31 |1| Reserved | 7769 +---------------+---------------+---------------+---------------+ 7770 4|TotalAHSLength | DataSegmentLength | 7771 +---------------+---------------+---------------+---------------+ 7772 8| LUN | 7773 + + 7774 12| | 7775 +---------------+---------------+---------------+---------------+ 7776 16| Initiator Task Tag | 7777 +---------------+---------------+---------------+---------------+ 7778 20| Target Transfer Tag | 7779 +---------------+---------------+---------------+---------------+ 7780 24| StatSN | 7781 +---------------+---------------+---------------+---------------+ 7782 28| ExpCmdSN | 7783 +---------------+---------------+---------------+---------------+ 7784 32| MaxCmdSN | 7785 +---------------+---------------+---------------+---------------+ 7786 36| R2TSN | 7787 +---------------+---------------+---------------+---------------+ 7788 40| Buffer Offset | 7789 +---------------+---------------+---------------+---------------+ 7790 44| Desired Data Transfer Length | 7791 +---------------------------------------------------------------+ 7792 48| Header-Digest (Optional) | 7793 +---------------+---------------+---------------+---------------+ 7795 When an initiator has submitted a SCSI Command with data that 7796 passes from the initiator to the target (WRITE), the target may 7797 specify which blocks of data it is ready to receive. The target may 7798 request that the data blocks be delivered in whichever order is 7799 convenient for the target at that particular instant. This 7800 information is passed from the target to the initiator in the Ready 7801 To Transfer (R2T) PDU. 7803 In order to allow write operations without an explicit initial R2T, 7804 the initiator and target MUST have negotiated the key InitialR2T to 7805 No during Login. 7807 An R2T MAY be answered with one or more SCSI Data-out PDUs with a 7808 matching Target Transfer Tag. If an R2T is answered with a single 7809 Data-out PDU, the Buffer Offset in the Data PDU MUST be the same as 7810 the one specified by the R2T, and the data length of the Data PDU 7811 MUST be the same as the Desired Data Transfer Length specified in 7812 the R2T. If the R2T is answered with a sequence of Data PDUs, the 7813 Buffer Offset and Length MUST be within the range of those 7814 specified by R2T, and the last PDU MUST have the F bit set to 1. If 7815 the last PDU (marked with the F bit) is received before the Desired 7816 Data Transfer Length is transferred, a target MAY choose to Reject 7817 that PDU with "Protocol error" reason code. DataPDUInOrder governs 7818 the Data-Out PDU ordering. If DataPDUInOrder is set to Yes, the 7819 Buffer Offsets and Lengths for consecutive PDUs MUST form a 7820 continuous non-overlapping range and the PDUs MUST be sent in 7821 increasing offset order. 7823 The target may send several R2T PDUs. It, therefore, can have a 7824 number of pending data transfers. The number of outstanding R2T 7825 PDUs are limited by the value of the negotiated key 7826 MaxOutstandingR2T. Within a task, outstanding R2Ts MUST be 7827 fulfilled by the initiator in the order in which they were 7828 received. 7830 R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T 7831 (Recovery-R2T) is generated by a target upon detecting the loss of 7832 one or more Data-Out PDUs due to: 7834 - Digest error 7836 - Sequence error 7838 - Sequence reception timeout 7840 A Recovery-R2T carries the next unused R2TSN, but requests part of 7841 or the entire data burst that an earlier R2T (with a lower R2TSN) 7842 had already requested. 7844 DataSequenceInOrder governs the buffer offset ordering in 7845 consecutive R2Ts. If DataSequenceInOrder is Yes, then consecutive 7846 R2Ts MUST refer to continuous non-overlapping ranges except for 7847 Recovery-R2Ts. 7849 11.8.1. TotalAHSLength and DataSegmentLength 7851 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7853 11.8.2. R2TSN 7855 R2TSN is the R2T PDU input PDU number within the command identified 7856 by the Initiator Task Tag. 7858 For bidirectional commands R2T and Data-In PDUs share the input PDU 7859 numbering sequence (see Section 3.2.2.4 - "Data Sequencing"). 7861 11.8.3. StatSN 7863 The StatSN field will contain the next StatSN. The StatSN for this 7864 connection is not advanced after this PDU is sent. 7866 11.8.4. Desired Data Transfer Length and Buffer Offset 7868 The target specifies how many bytes it wants the initiator to send 7869 because of this R2T PDU. The target may request the data from the 7870 initiator in several chunks, not necessarily in the original order 7871 of the data. The target, therefore, also specifies a Buffer Offset 7872 that indicates the point at which the data transfer should begin, 7873 relative to the beginning of the total data transfer. The Desired 7874 Data Transfer Length MUST NOT be 0 and MUST NOT exceed 7875 MaxBurstLength. 7877 11.8.5. Target Transfer Tag 7879 The target assigns its own tag to each R2T request that it sends to 7880 the initiator. This tag can be used by the target to easily 7881 identify the data it receives. The Target Transfer Tag and LUN are 7882 copied in the outgoing data PDUs and are only used by the target. 7883 There is no protocol rule about the Target Transfer Tag except that 7884 the value 0xffffffff is reserved and MUST NOT be sent by a target 7885 in an R2T. 7887 11.9. Asynchronous Message 7889 An Asynchronous Message may be sent from the target to the 7890 initiator without correspondence to a particular command. The 7891 target specifies the reason for the event and sense data. 7893 Byte/ 0 | 1 | 2 | 3 | 7894 / | | | | 7895 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7896 +---------------+---------------+---------------+---------------+ 7897 0|.|.| 0x32 |1| Reserved | 7898 +---------------+---------------+---------------+---------------+ 7899 4|TotalAHSLength | DataSegmentLength | 7900 +---------------+---------------+---------------+---------------+ 7901 8| LUN or Reserved | 7902 + + 7903 12| | 7904 +---------------+---------------+---------------+---------------+ 7905 16| 0xffffffff | 7906 +---------------+---------------+---------------+---------------+ 7907 20| Reserved | 7908 +---------------+---------------+---------------+---------------+ 7909 24| StatSN | 7910 +---------------+---------------+---------------+---------------+ 7911 28| ExpCmdSN | 7912 +---------------+---------------+---------------+---------------+ 7913 32| MaxCmdSN | 7914 +---------------+---------------+---------------+---------------+ 7915 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | 7916 +---------------+---------------+---------------+---------------+ 7917 40| Parameter2 or Reserved | Parameter3 or Reserved | 7918 +---------------+---------------+---------------+---------------+ 7919 44| Reserved | 7920 +---------------+---------------+---------------+---------------+ 7921 48| Header-Digest (Optional) | 7922 +---------------+---------------+---------------+---------------+ 7923 / DataSegment - Sense Data and iSCSI Event Data / 7924 +/ / 7925 +---------------+---------------+---------------+---------------+ 7926 | Data-Digest (Optional) | 7927 +---------------+---------------+---------------+---------------+ 7929 Some Asynchronous Messages are strictly related to iSCSI while 7930 others are related to SCSI [SAM2]. 7932 StatSN counts this PDU as an acknowledgeable event (StatSN is 7933 advanced), which allows for initiator and target state 7934 synchronization. 7936 11.9.1. AsyncEvent 7938 The codes used for iSCSI Asynchronous Messages (events) are: 7940 0 (SCSI_ASYNC) - a SCSI Asynchronous Event is reported in the 7941 sense data. Sense Data that accompanies the report, in the 7942 data segment, identifies the condition. The sending of a SCSI 7943 Event (Asynchronous Event Reporting in SCSI terminology) is 7944 dependent on the target support for SCSI asynchronous event 7945 reporting (see [SAM2]) as indicated in the standard INQUIRY 7946 data (see [SPC3]). Its use may be enabled by parameters in 7947 the SCSI Control mode page (see [SPC3]). 7949 1 (REQUEST_LOGOUT) - target requests Logout. This Async Message 7950 MUST be sent on the same connection as the one requesting to 7951 be logged out. The initiator MUST honor this request by 7952 issuing a Logout as early as possible, but no later than 7953 Parameter3 seconds. Initiator MUST send a Logout with a 7954 reason code of "Close the connection" OR "Close the session" 7955 to close all the connections. Once this message is received, 7956 the initiator SHOULD NOT issue new iSCSI commands on the 7957 connection to be logged out. The target MAY reject any new 7958 I/O requests that it receives after this Message with the 7959 reason code "Waiting for Logout". If the initiator does not 7960 Logout in Parameter3 seconds, the target should send an Async 7961 PDU with iSCSI event code "Dropped the connection" if 7962 possible, or simply terminate the transport connection. 7963 Parameter1 and Parameter2 are reserved. 7965 2 (CONNECTION_DROP) - target indicates it will drop the 7966 connection. 7967 The Parameter1 field indicates the CID of the connection 7968 going to be dropped. 7970 The Parameter2 field (Time2Wait) indicates, in seconds, the 7972 minimum time to wait before attempting to reconnect or 7973 reassign. 7975 The Parameter3 field (Time2Retain) indicates the maximum time 7976 allowed to reassign commands after the initial wait (in 7977 Parameter2). 7979 If the initiator does not attempt to reconnect and/or 7980 reassign the outstanding commands within the time specified 7981 by Parameter3, or if Parameter3 is 0, the target will 7982 terminate all outstanding commands on this connection. In 7983 this case, no other responses should be expected from the 7984 target for the outstanding commands on this connection. 7986 A value of 0 for Parameter2 indicates that reconnect can be 7987 attempted immediately. 7989 3 (SESSION_DROP) - target indicates it will drop all the 7990 connections of this session. 7992 Parameter1 field is reserved. 7994 The Parameter2 field (Time2Wait) indicates, in seconds, the 7995 minimum time to wait before attempting to reconnect. 7996 The Parameter3 field (Time2Retain) indicates the maximum time 7997 allowed to reassign commands after the initial wait (in 7998 Parameter2). 8000 If the initiator does not attempt to reconnect and/or 8001 reassign the outstanding commands within the time specified 8002 by Parameter3, or if Parameter3 is 0, the session is 8003 terminated. In this case, the target will terminate all 8004 outstanding commands in this session; no other responses 8005 should be expected from the target for the outstanding 8006 commands in this session. A value of 0 for Parameter2 8007 indicates that reconnect can be attempted immediately. 8009 4 (RENEGOTIATE) - target requests parameter negotiation on this 8010 connection. The initiator MUST honor this request by issuing 8011 a Text Request (that can be empty) on the same connection as 8012 early as possible, but no later than Parameter3 seconds, 8013 unless a Text Request is already pending on the connection, 8014 or by issuing a Logout Request. If the initiator does not 8015 issue a Text Request the target may reissue the Asynchronous 8016 Message requesting parameter negotiation. 8018 5 (FAST_ABORT) - all active tasks for LU with a matching LUN 8019 field in the Async Message PDU are being terminated. The 8020 receiving initiator iSCSI layer MUST respond to this Message 8021 by taking the following steps in order. 8023 - Stop Data-Out transfers on that connection for all active 8024 TTTs for the affected LUN quoted in the Async Message PDU. 8025 - Acknowledge the StatSN of the Async Message PDU via a NOP- 8026 Out PDU with ITT=0xffffffff (i.e., non-ping flavor), while 8027 copying the LUN field from the Async Message to NOP-Out. 8029 This value of AsyncEvent however MUST NOT be used on an iSCSI 8030 session unless the new TaskReporting text key defined in 8031 Section 13.23 was negotiated to FastAbort on the session. 8033 255 vendor-specific iSCSI Event. The AsyncVCode details the 8034 vendor code, and data MAY accompany the report. 8036 All other event codes are reserved. 8038 11.9.2. AsyncVCode 8040 AsyncVCode is a vendor specific detail code that is only valid if 8041 the AsyncEvent field indicates a vendor specific event. Otherwise, 8042 it is reserved. 8044 11.9.3. LUN 8046 The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this 8047 field is reserved. 8048 11.9.4. Sense Data and iSCSI Event Data 8050 For a SCSI event, this data accompanies the report in the data 8051 segment and identifies the condition. 8053 For an iSCSI event, additional vendor-unique data MAY accompany the 8054 Async event. Initiators MAY ignore the data when not understood 8055 while processing the rest of the PDU. 8057 If the DataSegmentLength is not 0, the format of the DataSegment is 8058 as follows: 8059 Byte/ 0 | 1 | 2 | 3 | 8060 / | | | | 8061 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8062 +---------------+---------------+---------------+---------------+ 8063 0|SenseLength | Sense Data | 8064 +---------------+---------------+---------------+---------------+ 8065 x/ Sense Data / 8066 +---------------+---------------+---------------+---------------+ 8067 y/ iSCSI Event Data / 8068 / / 8069 +---------------+---------------+---------------+---------------+ 8070 z| 8072 11.9.4.1. SenseLength 8074 This is the length of Sense Data. When the Sense Data field is 8075 empty (e.g., the event is not a SCSI event) SenseLength is 0. 8077 11.10. Text Request 8079 The Text Request is provided to allow for the exchange of 8080 information and for future extensions. It permits the initiator to 8081 inform a target of its capabilities or to request some special 8082 operations. 8084 Byte/ 0 | 1 | 2 | 3 | 8085 / | | | | 8086 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8087 +---------------+---------------+---------------+---------------+ 8088 0|.|I| 0x04 |F|C| Reserved | 8089 +---------------+---------------+---------------+---------------+ 8090 4|TotalAHSLength | DataSegmentLength | 8091 +---------------+---------------+---------------+---------------+ 8092 8| LUN or Reserved | 8093 + + 8094 12| | 8095 +---------------+---------------+---------------+---------------+ 8096 16| Initiator Task Tag | 8097 +---------------+---------------+---------------+---------------+ 8098 20| Target Transfer Tag or 0xffffffff | 8099 +---------------+---------------+---------------+---------------+ 8100 24| CmdSN | 8101 +---------------+---------------+---------------+---------------+ 8102 28| ExpStatSN | 8103 +---------------+---------------+---------------+---------------+ 8104 32/ Reserved / 8105 +/ / 8106 +---------------+---------------+---------------+---------------+ 8107 48| Header-Digest (Optional) | 8108 +---------------+---------------+---------------+---------------+ 8109 / DataSegment (Text) / 8110 +/ / 8111 +---------------+---------------+---------------+---------------+ 8112 | Data-Digest (Optional) | 8113 +---------------+---------------+---------------+---------------+ 8115 An initiator MUST NOT have more than one outstanding Text Request 8116 on a connection at any given time. 8118 On a connection failure, an initiator must either explicitly abort 8119 any active allegiant text negotiation task or must cause such a 8120 task to be implicitly terminated by the target. 8122 11.10.1. F (Final) Bit 8124 When set to 1, indicates that this is the last or only text 8125 request in a sequence of Text Requests; otherwise, it indicates 8126 that more Text Requests will follow. 8128 11.10.2. C (Continue) Bit 8130 When set to 1, indicates that the text (set of key=value pairs) in 8131 this Text Request is not complete (it will be continued on 8132 subsequent Text Requests); otherwise, it indicates that this Text 8133 Request ends a set of key=value pairs. A Text Request with the C 8134 bit set to 1 MUST have the F bit set to 0. 8136 11.10.3. Initiator Task Tag 8138 The initiator assigned identifier for this Text Request. If the 8139 command is sent as part of a sequence of text requests and 8140 responses, the Initiator Task Tag MUST be the same for all the 8141 requests within the sequence (similar to linked SCSI commands). The 8142 I bit for all requests in a sequence also MUST be the same. 8144 11.10.4. Target Transfer Tag 8146 When the Target Transfer Tag is set to the reserved value 8147 0xffffffff, it tells the target that this is a new request and the 8148 target resets any internal state associated with the Initiator Task 8149 Tag (resets the current negotiation state). 8151 The target sets the Target Transfer Tag in a text response to a 8152 value other than the reserved value 0xffffffff whenever it 8153 indicates that it has more data to send or more operations to 8154 perform that are associated with the specified Initiator Task Tag. 8155 It MUST do so whenever it sets the F bit to 0 in the response. By 8156 copying the Target Transfer Tag from the response to the next Text 8157 Request, the initiator tells the target to continue the operation 8158 for the specific Initiator Task Tag. The initiator MUST ignore the 8159 Target Transfer Tag in the Text Response when the F bit is set to 8160 1. 8162 This mechanism allows the initiator and target to transfer a large 8163 amount of textual data over a sequence of text-command/text- 8164 response exchanges, or to perform extended negotiation sequences. 8166 If the Target Transfer Tag is not 0xffffffff, the LUN field MUST be 8167 sent by the target in the Text Response. 8169 A target MAY reset its internal negotiation state if an exchange is 8170 stalled by the initiator for a long time or if it is running out of 8171 resources. 8173 Long text responses are handled as in the following example: 8175 I->T Text SendTargets=All (F=1,TTT=0xffffffff) 8177 T->I Text (F=0,TTT=0x12345678) 8179 I->T Text (F=1, TTT=0x12345678) 8181 T->I Text (F=0, TTT=0x12345678) 8183 I->T Text (F=1, TTT=0x12345678) 8185 ... 8187 T->I Text (F=1, TTT=0xffffffff) 8189 11.10.5. Text 8191 The data lengths of a text request MUST NOT exceed the iSCSI target 8192 MaxRecvDataSegmentLength (a per connection and per direction 8193 negotiated parameter). The text format is specified in Section 5.2 8194 - "Text Mode Negotiation". 8196 Chapter 11 and Chapter 12 list some basic Text key=value pairs, 8197 some of which can be used in Login Request/Response and some in 8198 Text Request/Response. 8200 A key=value pair can span Text request or response boundaries. A 8201 key=value pair can start in one PDU and continue on the next. In 8202 other words the end of a PDU does not necessarily signal the end of 8203 a key=value pair. 8205 The target responds by sending its response back to the initiator. 8206 The response text format is similar to the request text format. 8207 The text response MAY refer to key=value pairs presented in an 8208 earlier text request and the text in the request may refer to 8209 earlier responses. 8211 Chapter 5 details the rules for the Text Requests and Responses. 8213 Text operations are usually meant for parameter 8214 setting/negotiations, but can also be used to perform some long 8215 lasting operations. 8217 Text operations that take a long time should be placed in their own 8218 Text request. 8220 11.11. Text Response 8222 The Text Response PDU contains the target's responses to the 8223 initiator's Text request. The format of the Text field matches that 8224 of the Text request. 8226 Byte/ 0 | 1 | 2 | 3 | 8227 / | | | | 8228 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8229 +---------------+---------------+---------------+---------------+ 8230 0|.|.| 0x24 |F|C| Reserved | 8231 +---------------+---------------+---------------+---------------+ 8232 4|TotalAHSLength | DataSegmentLength | 8233 +---------------+---------------+---------------+---------------+ 8234 8| LUN or Reserved | 8235 + + 8236 12| | 8237 +---------------+---------------+---------------+---------------+ 8238 16| Initiator Task Tag | 8239 +---------------+---------------+---------------+---------------+ 8240 20| Target Transfer Tag or 0xffffffff | 8241 +---------------+---------------+---------------+---------------+ 8242 24| StatSN | 8243 +---------------+---------------+---------------+---------------+ 8244 28| ExpCmdSN | 8245 +---------------+---------------+---------------+---------------+ 8246 32| MaxCmdSN | 8247 +---------------+---------------+---------------+---------------+ 8248 36/ Reserved / 8249 +/ / 8250 +---------------+---------------+---------------+---------------+ 8251 48| Header-Digest (Optional) | 8252 +---------------+---------------+---------------+---------------+ 8253 / DataSegment (Text) / 8254 +/ / 8255 +---------------+---------------+---------------+---------------+ 8256 | Data-Digest (Optional) | 8257 +---------------+---------------+---------------+---------------+ 8259 11.11.1. F (Final) Bit 8261 When set to 1, in response to a Text Request with the Final bit set 8262 to 1, the F bit indicates that the target has finished the whole 8263 operation. Otherwise, if set to 0 in response to a Text Request 8264 with the Final Bit set to 1, it indicates that the target has more 8265 work to do (invites a follow-on text request). A Text Response with 8266 the F bit set to 1 in response to a Text Request with the F bit set 8267 to 0 is a protocol error. 8269 A Text Response with the F bit set to 1 MUST NOT contain key=value 8270 pairs that may require additional answers from the initiator. 8272 A Text Response with the F bit set to 1 MUST have a Target Transfer 8273 Tag field set to the reserved value of 0xffffffff. 8275 A Text Response with the F bit set to 0 MUST have a Target Transfer 8276 Tag field set to a value other than the reserved 0xffffffff. 8278 11.11.2. C (Continue) Bit 8280 When set to 1, indicates that the text (set of key=value pairs) in 8281 this Text Response is not complete (it will be continued on 8282 subsequent Text Responses); otherwise, it indicates that this Text 8283 Response ends a set of key=value pairs. A Text Response with the C 8284 bit set to 1 MUST have the F bit set to 0. 8286 11.11.3. Initiator Task Tag 8288 The Initiator Task Tag matches the tag used in the initial Text 8289 Request. 8291 11.11.4. Target Transfer Tag 8293 When a target has more work to do (e.g., cannot transfer all the 8294 remaining text data in a single Text Response or has to continue 8295 the negotiation) and has enough resources to proceed, it MUST set 8296 the Target Transfer Tag to a value other than the reserved value of 8297 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to 8298 0xffffffff. 8300 When the Target Transfer Tag is not 0xffffffff, the LUN field may 8301 be significant. 8303 The initiator MUST copy the Target Transfer Tag and LUN in its next 8304 request to indicate that it wants the rest of the data. 8306 When the target receives a Text Request with the Target Transfer 8307 Tag set to the reserved value of 0xffffffff, it resets its internal 8308 information (resets state) associated with the given Initiator Task 8309 Tag (restarts the negotiation). 8311 When a target cannot finish the operation in a single Text 8312 Response, and does not have enough resources to continue, it 8313 rejects the Text Request with the appropriate Reject code. 8315 A target may reset its internal state associated with an Initiator 8316 Task Tag (the current negotiation state), state expressed through 8317 the Target Transfer Tag if the initiator fails to continue the 8318 exchange for some time. The target may reject subsequent Text 8319 Requests with the Target Transfer Tag set to the "stale" value. 8321 11.11.5. StatSN 8323 The target StatSN variable is advanced by each Text Response sent. 8325 11.11.6. Text Response Data 8327 The data lengths of a text response MUST NOT exceed the iSCSI 8328 initiator MaxRecvDataSegmentLength (a per connection and per 8329 direction negotiated parameter). 8331 The text in the Text Response Data is governed by the same rules as 8332 the text in the Text Request Data (see C (Con). 8334 Although the initiator is the requesting party and controls the 8335 request-response initiation and termination, the target can offer 8336 key=value pairs of its own as part of a sequence and not only in 8337 response to the initiator. 8339 11.12. Login Request 8341 After establishing a TCP connection between an initiator and a 8342 target, the initiator MUST start a Login Phase to gain further 8343 access to the target's resources. 8345 The Login Phase (see Chapter 5) consists of a sequence of Login 8346 requests and responses that carry the same Initiator Task Tag. 8348 Login requests are always considered as immediate. 8350 Byte/ 0 | 1 | 2 | 3 | 8351 / | | | | 8352 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8353 +---------------+---------------+---------------+---------------+ 8354 0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min | 8355 +---------------+---------------+---------------+---------------+ 8356 4|TotalAHSLength | DataSegmentLength | 8357 +---------------+---------------+---------------+---------------+ 8358 8| ISID | 8359 + +---------------+---------------+ 8360 12| | TSIH | 8361 +---------------+---------------+---------------+---------------+ 8362 16| Initiator Task Tag | 8363 +---------------+---------------+---------------+---------------+ 8364 20| CID | Reserved | 8365 +---------------+---------------+---------------+---------------+ 8366 24| CmdSN | 8367 +---------------+---------------+---------------+---------------+ 8368 28| ExpStatSN or Reserved | 8369 +---------------+---------------+---------------+---------------+ 8370 32| Reserved | 8371 +---------------+---------------+---------------+---------------+ 8372 36| Reserved | 8373 +---------------+---------------+---------------+---------------+ 8374 40/ Reserved / 8375 +/ / 8376 +---------------+---------------+---------------+---------------+ 8377 48/ DataSegment - Login Parameters in Text request Format / 8378 +/ / 8379 +---------------+---------------+---------------+---------------+ 8381 11.12.1. T (Transit) Bit 8383 If set to 1, indicates that the initiator is ready to transit to 8384 the next stage. 8386 If the T bit is set to 1 and NSG is FullFeaturePhase, then this 8387 also indicates that the initiator is ready for the Final Login 8388 Response (see Chapter 5). 8390 11.12.2. C (Continue) Bit 8392 When set to 1, indicates that the text (set of key=value pairs) in 8393 this Login Request is not complete (it will be continued on 8394 subsequent Login Requests); otherwise, it indicates that this Login 8395 Request ends a set of key=value pairs. A Login Request with the C 8396 bit set to 1 MUST have the T bit set to 0. 8398 11.12.3. CSG and NSG 8400 Through these fields, Current Stage (CSG) and Next Stage (NSG), the 8401 Login negotiation requests and responses are associated with a 8402 specific stage in the session (SecurityNegotiation, 8403 LoginOperationalNegotiation, FullFeaturePhase) and may indicate the 8404 next stage to which they want to move (see Chapter 5). The next 8405 stage value is only valid when the T bit is 1; otherwise, it is 8406 reserved. 8408 The stage codes are: 8410 - 0 - SecurityNegotiation 8412 - 1 - LoginOperationalNegotiation 8414 - 3 - FullFeaturePhase 8416 All other codes are reserved. 8418 11.12.4. Version 8420 The version number of the current draft is 0x00. As such, all 8421 devices MUST carry version 0x00 for both Version-min and Version- 8422 max. 8424 11.12.4.1. Version-max 8426 Maximum Version number supported. 8428 All Login requests within the Login Phase MUST carry the same 8429 Version-max. 8431 The target MUST use the value presented with the first login 8432 request. 8434 11.12.4.2. Version-min 8436 All Login requests within the Login Phase MUST carry the same 8437 Version-min. The target MUST use the value presented with the first 8438 login request. 8440 11.12.5. ISID 8442 This is an initiator-defined component of the session identifier 8443 and is structured as follows (see Section 10.1.1 for details): 8445 Byte/ 0 | 1 | 2 | 3 | 8446 / | | | | 8447 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8448 +---------------+---------------+---------------+---------------+ 8449 8| T | A | B | C | 8450 +---------------+---------------+---------------+---------------+ 8451 12| D | 8452 +---------------+---------------+ 8454 The T field identifies the format and usage of A, B, C, and D as 8455 indicated below: 8457 T 8459 00b OUI-Format 8461 A&B are a 22 bit OUI 8463 (the I/G & U/L bits are omitted) 8465 C&D 24 bit qualifier 8467 01b EN - Format (IANA Enterprise Number) 8469 A - Reserved 8471 B&C EN (IANA Enterprise Number) 8473 D - Qualifier 8475 10b "Random" 8477 A - Reserved 8479 B&C Random 8481 D - Qualifier 8483 11b A,B,C&D Reserved 8485 For the T field values 00b and 01b, a combination of A and B (for 8486 00b) or B and C (for 01b) identifies the vendor or organization 8487 whose component (software or hardware) generates this ISID. A 8488 vendor or organization with one or more OUIs, or one or more 8489 Enterprise Numbers, MUST use at least one of these numbers and 8490 select the appropriate value for the T field when its components 8491 generate ISIDs. An OUI or EN MUST be set in the corresponding 8492 fields in network byte order (byte big-endian). 8494 If the T field is 10b, B and C are set to a random 24-bit unsigned 8495 integer value in network byte order (byte big-endian). See 8496 [RFC3721] for how this affects the principle of "conservative 8497 reuse". 8499 The Qualifier field is a 16 or 24-bit unsigned integer value that 8500 provides a range of possible values for the ISID within the 8501 selected namespace. It may be set to any value within the 8502 constraints specified in the iSCSI protocol (see Section 3.4.3 - 8503 "Consequences of the Model" and Section 9.1.1 - "Conservative Reuse 8504 of ISIDs"). 8506 The T field value of 11b is reserved. 8508 If the ISID is derived from something assigned to a hardware 8509 adapter or interface by a vendor, as a preset default value, it 8510 MUST be configurable to a value assigned according to the SCSI port 8511 behavior desired by the system in which it is installed (see 8512 Section 9.1.1 - "Conservative Reuse of ISIDs" and Section 9.1.2 - 8513 "iSCSI Name, ISID, and TPGT Use"). The resultant ISID MUST also be 8514 persistent over power cycles, reboot, card swap, etc. 8516 11.12.6. TSIH 8518 TSIH must be set in the first Login Request. The reserved value 0 8519 MUST be used on the first connection for a new session. Otherwise, 8520 the TSIH sent by the target at the conclusion of the successful 8521 login of the first connection for this session MUST be used. The 8522 TSIH identifies to the target the associated existing session for 8523 this new connection. 8525 All Login requests within a Login Phase MUST carry the same TSIH. 8527 The target MUST check the value presented with the first login 8528 request and act as specified in Section 5.3.1 - "Login Phase 8529 Start". 8531 11.12.7. Connection ID - CID 8533 A unique ID for this connection within the session. 8535 All Login requests within the Login Phase MUST carry the same CID. 8537 The target MUST use the value presented with the first login 8538 request. 8540 A Login request with a non-zero TSIH and a CID equal to that of an 8541 existing connection implies a logout of the connection followed by 8542 a Login (see Section 6.3.4). For the details of the implicit Logout 8543 Request, see Section 11.14. 8545 11.12.8. CmdSN 8547 CmdSN is either the initial command sequence number of a session 8548 (for the first Login request of a session - the "leading" login), 8549 or the command sequence number in the command stream if the login 8550 is for a new connection in an existing session. 8552 Examples: 8554 - Login on a leading connection - if the leading login carries 8555 the CmdSN 123, all other login requests in the same login 8556 phase carry the CmdSN 123 and the first non-immediate command 8557 in FullFeaturePhase also carries the CmdSN 123. 8559 - Login on other than a leading connection - if the current 8560 CmdSN at the time the first login on the connection is issued 8561 is 500, then that PDU carries CmdSN=500. Subsequent login 8562 requests that are needed to complete this login phase may 8563 carry a CmdSN higher than 500 if non-immediate requests that 8564 were issued on other connections in the same session advance 8565 CmdSN. 8567 If the login request is a leading login request, the target MUST 8568 use the value presented in CmdSN as the target value for ExpCmdSN. 8570 11.12.9. ExpStatSN 8572 For the first Login Request on a connection this is ExpStatSN for 8573 the old connection and this field is only valid if the Login 8574 request restarts a connection (see Section 5.3.4 - "Connection 8575 Reinstatement"). 8577 For subsequent Login Requests it is used to acknowledge the Login 8578 Responses with their increasing StatSN values. 8580 11.12.10. Login Parameters 8582 The initiator MUST provide some basic parameters in order to enable 8583 the target to determine if the initiator may use the target's 8584 resources and the initial text parameters for the security 8585 exchange. 8587 All the rules specified in Section 11.10.5 for text requests also 8588 hold for login requests. Keys and their explanations are listed in 8589 Chapter 11 (security negotiation keys) and Section 13 (operational 8590 parameter negotiation keys). All keys in Section 13, except for the 8591 X extension formats, MUST be supported by iSCSI initiators and 8592 targets. Keys in Section 12 only need to be supported when the 8593 function to which they refer is mandatory to implement. 8595 11.13. Login Response 8597 The Login Response indicates the progress and/or end of the Login 8598 Phase. 8600 Byte/ 0 | 1 | 2 | 3 | 8601 / | | | | 8602 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8603 +---------------+---------------+---------------+---------------+ 8604 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max | Version-active| 8605 +---------------+---------------+---------------+---------------+ 8606 4|TotalAHSLength | DataSegmentLength | 8607 +---------------+---------------+---------------+---------------+ 8608 8| ISID | 8609 + +---------------+---------------+ 8610 12| | TSIH | 8611 +---------------+---------------+---------------+---------------+ 8612 16| Initiator Task Tag | 8613 +---------------+---------------+---------------+---------------+ 8614 20| Reserved | 8615 +---------------+---------------+---------------+---------------+ 8616 24| StatSN | 8617 +---------------+---------------+---------------+---------------+ 8618 28| ExpCmdSN | 8619 +---------------+---------------+---------------+---------------+ 8620 32| MaxCmdSN | 8621 +---------------+---------------+---------------+---------------+ 8622 36| Status-Class | Status-Detail | Reserved | 8623 +---------------+---------------+---------------+---------------+ 8624 40/ Reserved / 8625 +/ / 8626 +---------------+---------------+---------------+---------------+ 8627 48/ DataSegment - Login Parameters in Text request Format / 8628 +/ / 8629 +---------------+---------------+---------------+---------------+ 8631 11.13.1. Version-max 8633 This is the highest version number supported by the target. 8635 All Login responses within the Login Phase MUST carry the same 8636 Version-max. 8638 The initiator MUST use the value presented as a response to the 8639 first login request. 8641 11.13.2. Version-active 8643 Indicates the highest version supported by the target and 8644 initiator. If the target does not support a version within the 8645 range specified by the initiator, the target rejects the login and 8646 this field indicates the lowest version supported by the target. 8648 All Login responses within the Login Phase MUST carry the same 8649 Version-active. 8651 The initiator MUST use the value presented as a response to the 8652 first login request. 8654 11.13.3. TSIH 8656 The TSIH is the target assigned session identifying handle. Its 8657 internal format and content are not defined by this protocol except 8658 for the value 0 that is reserved. With the exception of the Login 8659 Final-Response in a new session, this field should be set to the 8660 TSIH provided by the initiator in the Login Request. For a new 8661 session, the target MUST generate a non-zero TSIH and ONLY return 8662 it in the Login Final-Response (see Section 5.3 - "Login Phase"). 8664 11.13.4. StatSN 8666 For the first Login Response (the response to the first Login 8667 Request), this is the starting status Sequence Number for the 8668 connection. The next response of any kind, including the next login 8669 response, if any, in the same Login Phase, will carry this number + 8670 1. This field is only valid if the Status-Class is 0. 8672 11.13.5. Status-Class and Status-Detail 8674 The Status returned in a Login Response indicates the execution 8675 status of the Login Phase. The status includes: 8677 Status-Class 8679 Status-Detail 8681 0 Status-Class indicates success. 8683 A non-zero Status-Class indicates an exception. In this case, 8684 Status-Class is sufficient for a simple initiator to use when 8685 handling exceptions, without having to look at the Status-Detail. 8686 The Status-Detail allows finer-grained exception handling for more 8687 sophisticated initiators and for better information for logging. 8689 The status classes are as follows: 8691 0 - Success - indicates that the iSCSI target successfully 8692 received, understood, and accepted the request. The numbering 8693 fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if Status- 8694 Class is 0. 8696 1 - Redirection - indicates that the initiator must take 8697 further action to complete the request. This is usually due 8698 to the target moving to a different address. All of the 8699 redirection status class responses MUST return one or more 8700 text key parameters of the type "TargetAddress", which 8701 indicates the target's new address. A redirection response 8702 MAY be issued by a target prior or after completing a 8703 security negotiation if a security negotiation is required. A 8704 redirection SHOULD be accepted by an initiator even without 8705 having the target complete a security negotiation if any 8706 security negotiation is required, and MUST be accepted by the 8707 initiator after the completion of the security negotiation if 8708 any security negotiation is required. 8710 2 - Initiator Error (not a format error) - indicates that the 8711 initiator most likely caused the error. This MAY be due to a 8712 request for a resource for which the initiator does not have 8713 permission. The request should not be tried again. 8715 3 - Target Error - indicates that the target sees no errors in 8716 the initiator's login request, but is currently incapable of 8718 fulfilling the request. The initiator may re-try the same 8719 login request later. 8721 The table below shows all of the currently allocated status codes. 8722 The codes are in hexadecimal; the first byte is the status class 8723 and the second byte is the status detail. 8725 ----------------------------------------------------------------- 8726 Status | Code | Description 8727 |(hex) | 8728 ----------------------------------------------------------------- 8729 Success | 0000 | Login is proceeding OK (*1). 8730 ----------------------------------------------------------------- 8731 Target moved | 0101 | The requested iSCSI Target Name (ITN) 8732 temporarily | | has temporarily moved 8733 | | to the address provided. 8734 ----------------------------------------------------------------- 8735 Target moved | 0102 | The requested ITN has permanently moved 8736 permanently | | to the address provided. 8737 ----------------------------------------------------------------- 8738 Initiator | 0200 | Miscellaneous iSCSI initiator 8739 error | | errors. 8740 ---------------------------------------------------------------- 8741 Authentication| 0201 | The initiator could not be 8742 failure | | successfully authenticated or target 8743 | | authentication is not supported. 8744 ----------------------------------------------------------------- 8745 Authorization | 0202 | The initiator is not allowed access 8746 failure | | to the given target. 8747 ----------------------------------------------------------------- 8748 Not found | 0203 | The requested ITN does not 8749 | | exist at this address. 8750 ----------------------------------------------------------------- 8751 Target removed| 0204 | The requested ITN has been removed and 8752 | |no forwarding address is provided. 8753 ----------------------------------------------------------------- 8754 Unsupported | 0205 | The requested iSCSI version range is 8755 version | | not supported by the target. 8756 ----------------------------------------------------------------- 8757 Too many | 0206 | Too many connections on this SSID. 8758 connections | | 8759 ----------------------------------------------------------------- 8760 Missing | 0207 | Missing parameters (e.g., iSCSI 8761 parameter | | Initiator and/or Target Name). 8762 ----------------------------------------------------------------- 8763 Can't include | 0208 | Target does not support session 8764 in session | | spanning to this connection (address). 8765 ----------------------------------------------------------------- 8766 Session type | 0209 | Target does not support this type of 8767 not supported | | of session or not from this Initiator. 8768 ----------------------------------------------------------------- 8769 Session does | 020a | Attempt to add a connection 8770 not exist | | to a non-existent session. 8771 ----------------------------------------------------------------- 8772 Invalid during| 020b | Invalid Request type during Login. 8773 login | | 8774 ----------------------------------------------------------------- 8775 Target error | 0300 | Target hardware or software error. 8776 ----------------------------------------------------------------- 8777 Service | 0301 | The iSCSI service or target is not 8778 unavailable | | currently operational. 8779 ----------------------------------------------------------------- 8780 Out of | 0302 | The target has insufficient session, 8781 resources | | connection, or other resources. 8782 ----------------------------------------------------------------- 8784 (*1)If the response T bit is 1 in both the request and the matching 8785 response, and the NSG is FullFeaturePhase in both the request and 8786 the matching response, the Login Phase is finished and the 8787 initiator may proceed to issue SCSI commands. 8789 If the Status Class is not 0, the initiator and target MUST close 8790 the TCP connection. 8792 If the target wishes to reject the login request for more than one 8793 reason, it should return the primary reason for the rejection. 8795 11.13.6. T (Transit) bit 8797 The T bit is set to 1 as an indicator of the end of the stage. If 8798 the T bit is set to 1 and NSG is FullFeaturePhase, then this is 8799 also the Final Login Response (see Chapter 5). A T bit of 0 8800 indicates a "partial" response, which means "more negotiation 8801 needed". 8803 A login response with a T bit set to 1 MUST NOT contain key=value 8804 pairs that may require additional answers from the initiator within 8805 the same stage. 8807 If the status class is 0, the T bit MUST NOT be set to 1 if the T 8808 bit in the request was set to 0. 8810 11.13.7. C (Continue) Bit 8812 When set to 1, indicates that the text (set of key=value pairs) in 8813 this Login Response is not complete (it will be continued on 8814 subsequent Login Responses); otherwise, it indicates that this 8815 Login Response ends a set of key=value pairs. A Login Response with 8816 the C bit set to 1 MUST have the T bit set to 0. 8818 11.13.8. Login Parameters 8820 The target MUST provide some basic parameters in order to enable 8821 the initiator to determine if it is connected to the correct port 8822 and the initial text parameters for the security exchange. 8824 All the rules specified in Section 11.11.6 for text responses also 8825 hold for login responses. Keys and their explanations are listed 8826 in Chapter 11 (security negotiation keys) and Chapter 12 8827 (operational parameter negotiation keys). All keys in Section 13, 8828 except for the X extension formats, MUST be supported by iSCSI 8829 initiators and targets. Keys in Section 12, only need to be 8830 supported when the function to which they refer is mandatory to 8831 implement. 8833 11.14. Logout Request 8835 The Logout request is used to perform a controlled closing of a 8836 connection. 8838 An initiator MAY use a logout request to remove a connection from a 8839 session or to close an entire session. 8841 After sending the Logout request PDU, an initiator MUST NOT send 8842 any new iSCSI requests on the closing connection. If the Logout 8843 request is intended to close the session, new iSCSI requests MUST 8844 NOT be sent on any of the connections participating in the session. 8846 When receiving a Logout request with the reason code of "close the 8847 connection" or "close the session", the target MUST terminate all 8848 pending commands, whether acknowledged via ExpCmdSN or not, on that 8849 connection or session respectively. 8851 When receiving a Logout request with the reason code "remove 8852 connection for recovery", the target MUST discard all requests not 8853 yet acknowledged via ExpCmdSN that were issued on the specified 8854 connection, and suspend all data/status/R2T transfers on behalf of 8855 pending commands on the specified connection. 8857 The target then issues the Logout response and half-closes the TCP 8858 connection (sends FIN). After receiving the Logout response and 8859 attempting to receive the FIN (if still possible), the initiator 8860 MUST completely close the logging-out connection. For the 8861 terminated commands, no additional responses should be expected. 8863 A Logout for a CID may be performed on a different transport 8864 connection when the TCP connection for the CID has already been 8865 terminated. In such a case, only a logical "closing" of the iSCSI 8866 connection for the CID is implied with a Logout. 8868 All commands that were not terminated or not completed (with 8869 status) and acknowledged when the connection is closed completely 8870 can be reassigned to a new connection if the target supports 8871 connection recovery. 8873 If an initiator intends to start recovery for a failing connection, 8874 it MUST use the Logout request to "clean-up" the target end of a 8875 failing connection and enable recovery to start, or the Login 8876 request with a non-zero TSIH and the same CID on a new connection 8877 for the same effect. In sessions with a single connection, the 8878 connection can be closed and then a new connection reopened. A 8879 connection reinstatement login can be used for recovery (see 8880 Section 5.3.4 - "Connection Reinstatement"). 8882 A successful completion of a logout request with the reason code of 8883 "close the connection" or "remove the connection for recovery" 8884 results at the target in the discarding of unacknowledged commands 8885 received on the connection being logged out. These are commands 8886 that have arrived on the connection being logged out, but have not 8887 been delivered to SCSI because one or more commands with a smaller 8888 CmdSN has not been received by iSCSI. See Section 3.2.2.1 - 8889 "Command Numbering and Acknowledging". The resulting holes in the 8890 command sequence numbers will have to be handled by appropriate 8891 recovery (see Chapter 6) unless the session is also closed. 8893 The entire logout discussion in this section is also applicable for 8894 an implicit Logout realized by way of a connection reinstatement or 8895 session reinstatement. When a Login Request performs an implicit 8896 Logout, the implicit Logout is performed as if having the reason 8897 codes specified below: 8899 Reason code Type of implicit Logout 8901 ------------------------------------------- 8903 0 session reinstatement 8905 1 connection reinstatement when the operational 8906 ErrorRecoveryLevel < 2 8908 2 connection reinstatement when the operational 8909 ErrorRecoveryLevel = 2 8911 Byte/ 0 | 1 | 2 | 3 | 8912 / | | | | 8913 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8914 +---------------+---------------+---------------+---------------+ 8915 0|.|I| 0x06 |1| Reason Code | Reserved | 8916 +---------------+---------------+---------------+---------------+ 8917 4|TotalAHSLength | DataSegmentLength | 8918 +---------------------------------------------------------------+ 8919 8/ Reserved / 8920 +/ / 8921 +---------------+---------------+---------------+---------------+ 8922 16| Initiator Task Tag | 8923 +---------------+---------------+---------------+---------------+ 8924 20| CID or Reserved | Reserved | 8925 +---------------+---------------+---------------+---------------+ 8926 24| CmdSN | 8927 +---------------+---------------+---------------+---------------+ 8928 28| ExpStatSN | 8929 +---------------+---------------+---------------+---------------+ 8930 32/ Reserved / 8931 +/ / 8932 +---------------+---------------+---------------+---------------+ 8933 48| Header-Digest (Optional) | 8934 +---------------+---------------+---------------+---------------+ 8936 11.14.1. Reason Code 8938 Reason Code indicates the reason for Logout as follows: 8940 0 - close the session. All commands associated with the session 8941 (if any) are terminated. 8943 1 - close the connection. All commands associated with 8944 connection (if any) are terminated. 8946 2 - remove the connection for recovery. Connection is closed 8947 and all commands associated with it, if any, are to be 8948 prepared for a new allegiance. 8950 All other values are reserved. 8952 11.14.2. TotalAHSLength and DataSegmentLength 8954 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 8956 11.14.3. CID 8958 This is the connection ID of the connection to be closed (including 8959 closing the TCP stream). This field is only valid if the reason 8960 code is not "close the session". 8962 11.14.4. ExpStatSN 8964 This is the last ExpStatSN value for the connection to be closed. 8966 11.14.5. Implicit termination of tasks 8968 A target implicitly terminates the active tasks due to the iSCSI 8969 protocol in the following cases: 8971 When a connection is implicitly or explicitly logged out with 8972 the reason code of "Close the connection" and there are 8973 active tasks allegiant to that connection. 8975 When a connection fails and eventually the connection state 8976 times out (state transition M1 in Section 7.2.2 - "State 8977 Transition Descriptions for Initiators and Targets") and 8978 there are active tasks allegiant to that connection. 8980 When a successful recovery Logout is performed while there are 8981 active tasks allegiant to that connection, and those tasks 8982 eventually time out after the Time2Wait and Time2Retain 8983 periods without allegiance reassignment. 8985 When a connection is implicitly or explicitly logged out with 8986 the reason code of "Close the session" and there are active 8987 tasks in that session. 8989 If the tasks terminated in any of the above cases are SCSI tasks, 8990 they must be internally terminated as if with CHECK CONDITION 8991 status. This status is only meaningful for appropriately handling 8992 the internal SCSI state and SCSI side effects with respect to 8993 ordering because this status is never communicated back as a 8994 terminating status to the initiator. However additional actions may 8995 have to be taken at SCSI level depending on the SCSI context as 8996 defined by the SCSI standards (e.g., queued commands and ACA, UA 8997 for the next command on the I_T nexus in cases a), b), and c), 8998 after the tasks are terminated, the target MUST report a Unit 8999 Attention condition on the next command processed on any connection 9000 for each affected I_T_L nexus with the status of CHECK CONDITION, 9001 and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI 9002 PROTOCOL EVENT" - etc. - see [SAM4] and [SPC3]). 9004 11.15. Logout Response 9006 The logout response is used by the target to indicate if the 9007 cleanup operation for the connection(s) has completed. 9009 After Logout, the TCP connection referred by the CID MUST be closed 9010 at both ends (or all connections must be closed if the logout 9011 reason was session close). 9013 Byte/ 0 | 1 | 2 | 3 | 9014 / | | | | 9015 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 9016 +---------------+---------------+---------------+---------------+ 9017 0|.|.| 0x26 |1| Reserved | Response | Reserved | 9018 +---------------+---------------+---------------+---------------+ 9019 4|TotalAHSLength | DataSegmentLength | 9020 +---------------------------------------------------------------+ 9021 8/ Reserved / 9022 +/ / 9023 +---------------+---------------+---------------+---------------+ 9024 16| Initiator Task Tag | 9025 +---------------+---------------+---------------+---------------+ 9026 20| Reserved | 9027 +---------------+---------------+---------------+---------------+ 9028 24| StatSN | 9029 +---------------+---------------+---------------+---------------+ 9030 28| ExpCmdSN | 9031 +---------------+---------------+---------------+---------------+ 9032 32| MaxCmdSN | 9033 +---------------+---------------+---------------+---------------+ 9034 36| Reserved | 9035 +---------------------------------------------------------------+ 9036 40| Time2Wait | Time2Retain | 9037 +---------------+---------------+---------------+---------------+ 9038 44| Reserved | 9039 +---------------+---------------+---------------+---------------+ 9040 48| Header-Digest (Optional) | 9041 +---------------+---------------+---------------+---------------+ 9043 11.15.1. Response 9045 Logout response: 9047 0 - connection or session closed successfully. 9049 1 - CID not found. 9051 2 - connection recovery is not supported. If Logout reason code 9052 was recovery and target does not support it as indicated by 9053 the ErrorRecoveryLevel. 9055 3 - cleanup failed for various reasons. 9057 11.15.2. TotalAHSLength and DataSegmentLength 9059 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 9061 11.15.3. Time2Wait 9063 If the Logout response code is 0 and if the operational 9064 ErrorRecoveryLevel is 2, this is the minimum amount of time, in 9065 seconds, to wait before attempting task reassignment. If the Logout 9066 response code is 0 and if the operational ErrorRecoveryLevel is 9067 less than 2, this field is to be ignored. 9069 This field is invalid if the Logout response code is 1. 9071 If the Logout response code is 2 or 3, this field specifies the 9072 minimum time to wait before attempting a new implicit or explicit 9073 logout. 9075 If Time2Wait is 0, the reassignment or a new Logout may be 9076 attempted immediately. 9078 11.15.4. Time2Retain 9080 If the Logout response code is 0 and if the operational 9081 ErrorRecoveryLevel is 2, this is the maximum amount of time, in 9082 seconds, after the initial wait (Time2Wait), the target waits for 9083 the allegiance reassignment for any active task after which the 9084 task state is discarded. If the Logout response code is 0 and if 9085 the operational ErrorRecoveryLevel is less than 2, this field is to 9086 be ignored. 9088 This field is invalid if the Logout response code is 1. 9090 If the Logout response code is 2 or 3, this field specifies the 9091 maximum amount of time, in seconds, after the initial wait 9092 (Time2Wait), the target waits for a new implicit or explicit 9093 logout. 9095 If it is the last connection of a session, the whole session state 9096 is discarded after Time2Retain. 9098 If Time2Retain is 0, the target has already discarded the 9099 connection (and possibly the session) state along with the task 9100 states. No reassignment or Logout is required in this case. 9102 11.16. SNACK Request 9104 Byte/ 0 | 1 | 2 | 3 | 9105 / | | | | 9106 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 9107 +---------------+---------------+---------------+---------------+ 9108 0|.|.| 0x10 |1|.|.|.| Type | Reserved | 9109 +---------------+---------------+---------------+---------------+ 9110 4|TotalAHSLength | DataSegmentLength | 9111 +---------------+---------------+---------------+---------------+ 9112 8| LUN or Reserved | 9113 + + 9114 12| | 9115 +---------------+---------------+---------------+---------------+ 9116 16| Initiator Task Tag or 0xffffffff | 9117 +---------------+---------------+---------------+---------------+ 9118 20| Target Transfer Tag or SNACK Tag or 0xffffffff | 9119 +---------------+---------------+---------------+---------------+ 9120 24| Reserved | 9121 +---------------+---------------+---------------+---------------+ 9122 28| ExpStatSN | 9123 +---------------+---------------+---------------+---------------+ 9124 32/ Reserved / 9125 +/ / 9126 +---------------+---------------+---------------+---------------+ 9127 40| BegRun | 9128 +---------------------------------------------------------------+ 9129 44| RunLength | 9130 +---------------------------------------------------------------+ 9131 48| Header-Digest (Optional) | 9132 +---------------+---------------+---------------+---------------+ 9134 If the implementation supports ErrorRecoveryLevel greater than 9135 zero, it MUST support all SNACK types. 9137 The SNACK is used by the initiator to request the retransmission of 9138 numbered-responses, data, or R2T PDUs from the target. The SNACK 9139 request indicates the numbered-responses or data "runs" whose 9140 retransmission is requested by the target, where the run starts 9141 with the first StatSN, DataSN, or R2TSN whose retransmission is 9142 requested and indicates the number of Status, Data, or R2T PDUs 9143 requested including the first. 0 has special meaning when used as a 9144 starting number and length: 9146 - When used in RunLength, it means all PDUs starting with the 9147 initial. 9149 - When used in both BegRun and RunLength, it means all 9150 unacknowledged PDUs. 9152 The numbered-response(s) or R2T(s), requested by a SNACK, MUST be 9153 delivered as exact replicas of the ones that the target transmitted 9154 originally except for the fields ExpCmdSN, MaxCmdSN, and ExpDataSN, 9155 which MUST carry the current values. R2T(s)requested by SNACK MUST 9156 also carry the current value of StatSN. 9158 The numbered Data-In PDUs, requested by a Data SNACK MUST be 9159 delivered as exact replicas of the ones that the target transmitted 9160 originally except for the fields ExpCmdSN and MaxCmdSN, which MUST 9161 carry the current values and except for resegmentation (see 9162 Resegmentation). 9164 Any SNACK that requests a numbered-response, Data, or R2T that was 9165 not sent by the target or was already acknowledged by the 9166 initiator, MUST be rejected with a reason code of "Protocol error". 9168 11.16.1. Type 9170 This field encodes the SNACK function as follows: 9172 0-Data/R2T SNACK - requesting retransmission of one or more 9173 Data-In or R2T PDUs. 9175 1-Status SNACK - requesting retransmission of one or more 9176 numbered responses. 9178 2-DataACK - positively acknowledges Data-In PDUs. 9180 3-R-Data SNACK - requesting retransmission of Data-In PDUs with 9181 possible resegmentation and status tagging. 9183 All other values are reserved. 9185 Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST 9186 precede status acknowledgement for the given command. 9188 11.16.2. Data Acknowledgement 9190 If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST 9191 issue a SNACK of type DataACK after receiving a Data-In PDU with 9192 the A bit set to 1. However, if the initiator has detected holes in 9193 the input sequence, it MUST postpone issuing the SNACK of type 9194 DataACK until the holes are filled. An initiator MAY ignore the A 9195 bit if it deems that the bit is being set aggressively by the 9196 target (i.e., before the MaxBurstLength limit is reached). 9198 The DataACK is used to free resources at the target and not to 9199 request or imply data retransmission. 9201 An initiator MUST NOT request retransmission for any data it had 9202 already acknowledged. 9204 11.16.3. Resegmentation 9206 If the initiator MaxRecvDataSegmentLength changed between the 9207 original transmission and the time the initiator requests 9208 retransmission, the initiator MUST issue a R-Data SNACK (see Type). 9209 With R-Data SNACK, the initiator indicates that it discards all the 9210 unacknowledged data and expects the target to resend it. It also 9211 expects resegmentation. In this case, the retransmitted Data-In 9212 PDUs MAY be different from the ones originally sent in order to 9213 reflect changes in MaxRecvDataSegmentLength. Their DataSN starts 9214 with the BegRun of the last DataACK received by the target if any 9215 was received; otherwise it starts with 0 and is increased by 1 for 9216 each resent Data-In PDU. 9218 A target that has received a R-Data SNACK MUST return a SCSI 9219 Response that contains a copy of the SNACK Tag field from the R- 9220 Data SNACK in the SCSI Response SNACK Tag field as its last or only 9221 Response. For example, if it has already sent a response containing 9222 another value in the SNACK Tag field or had the status included in 9223 the last Data-In PDU, it must send a new SCSI Response PDU. If a 9224 target sends more than one SCSI Response PDU due to this rule, all 9225 SCSI responses must carry the same StatSN (see SNACK ). If an 9226 initiator attempts to recover a lost SCSI Response (with a Status- 9227 SNACK, see Type) when more than one response has been sent, the 9228 target will send the SCSI Response with the latest content known to 9229 the target, including the last SNACK Tag for the command. 9231 For considerations in allegiance reassignment of a task to a 9232 connection with a different MaxRecvDataSegmentLength, refer to 9233 Section 6.2.2 - "Allegiance Reassignment". 9235 11.16.4. Initiator Task Tag 9237 For Status SNACK and DataACK, the Initiator Task Tag MUST be set to 9238 the reserved value 0xffffffff. In all other cases, the Initiator 9239 Task Tag field MUST be set to the Initiator Task Tag of the 9240 referenced command. 9242 11.16.5. Target Transfer Tag or SNACK Tag 9244 For an R-Data SNACK, this field MUST contain a value that is 9245 different from 0 or 0xffffffff and is unique for the task 9246 (identified by the Initiator Task Tag). This value MUST be copied 9247 by the iSCSI target in the last or only SCSI Response PDU it issues 9248 for the command. 9250 For DataACK, the Target Transfer Tag MUST contain a copy of the 9251 Target Transfer Tag and LUN provided with the SCSI Data-In PDU with 9252 the A bit set to 1. 9254 In all other cases, the Target Transfer Tag field MUST be set to 9255 the reserved value of 0xffffffff. 9257 11.16.6. BegRun 9259 The DataSN, R2TSN, or StatSN of the first PDU whose retransmission 9260 is requested (Data/R2T and Status SNACK), or the next expected 9261 DataSN (DataACK SNACK). 9263 BegRun 0 when used in conjunction with RunLength 0 means resend all 9264 unacknowledged Data-In, R2T or Response PDUs. 9266 BegRun MUST be 0 for a R-Data SNACK. 9268 11.16.7. RunLength 9270 The number of PDUs whose retransmission is requested. 9272 RunLength 0 signals that all Data-In, R2T, or Response PDUs 9273 carrying the numbers equal to or greater than BegRun have to be 9274 resent. 9276 The RunLength MUST also be 0 for a DataACK SNACK in addition to R- 9277 Data SNACK. 9279 11.17. Reject 9281 Byte/ 0 | 1 | 2 | 3 | 9282 / | | | | 9283 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 9284 +---------------+---------------+---------------+---------------+ 9285 0|.|.| 0x3f |1| Reserved | Reason | Reserved | 9286 +---------------+---------------+---------------+---------------+ 9287 4|TotalAHSLength | DataSegmentLength | 9288 +---------------+---------------+---------------+---------------+ 9289 8/ Reserved / 9290 +/ / 9291 +---------------+---------------+---------------+---------------+ 9292 16| 0xffffffff | 9293 +---------------+---------------+---------------+---------------+ 9294 20| Reserved | 9295 +---------------+---------------+---------------+---------------+ 9296 24| StatSN | 9297 +---------------+---------------+---------------+---------------+ 9298 28| ExpCmdSN | 9299 +---------------+---------------+---------------+---------------+ 9300 32| MaxCmdSN | 9301 +---------------+---------------+---------------+---------------+ 9302 36| DataSN/R2TSN or Reserved | 9303 +---------------+---------------+---------------+---------------+ 9304 40| Reserved | 9305 +---------------+---------------+---------------+---------------+ 9306 44| Reserved | 9307 +---------------+---------------+---------------+---------------+ 9308 48| Header-Digest (Optional) | 9309 +---------------+---------------+---------------+---------------+ 9310 xx/ Complete Header of Bad PDU / 9311 +/ / 9312 +---------------+---------------+---------------+---------------+ 9313 yy/Vendor specific data (if any) / 9314 / / 9315 +---------------+---------------+---------------+---------------+ 9316 zz| Data-Digest (Optional) | 9317 +---------------+---------------+---------------+---------------+ 9319 Reject is used to indicate an iSCSI error condition (protocol, 9320 unsupported option, etc.). 9322 11.17.1. Reason 9324 The reject Reason is coded as follows: 9326 +------+----------------------------------------+-----------------+ 9327 | Code | Explanation | Can the original| 9328 | (hex)| | PDU be re-sent? | 9329 +------+----------------------------------------+-----------------+ 9330 | 0x01 | Reserved | no | 9331 | | | | 9332 | 0x02 | Data (payload) Digest Error | yes (Note 1) | 9333 | | | | 9334 | 0x03 | SNACK Reject | yes | 9335 | | | | 9336 | 0x04 | Protocol Error (e.g., SNACK request for| no | 9337 | | a status that was already acknowledged)| | 9338 | | | | 9339 | 0x05 | Command not supported | no | 9340 | | | | 9341 | 0x06 | Immediate Command Reject - too many | yes | 9342 | | immediate commands | | 9343 | | | | 9344 | 0x07 | Task in progress | no | 9345 | | | | 9346 | 0x08 | Invalid Data ACK | no | 9347 | | | | 9348 | 0x09 | Invalid PDU field | no (Note 2) | 9349 | | | | 9350 | 0x0a | Long Operation Reject - Can't generate | yes | 9351 | | Target Transfer Tag - out of resources | | 9352 | | | | 9353 | 0x0c | Waiting for Logout | no | 9354 +------+----------------------------------------+-----------------+ 9356 Note 1: For iSCSI, Data-Out PDU retransmission is only done if the 9357 target requests retransmission with a recovery R2T. However, if 9358 this is the data digest error on immediate data, the initiator may 9359 choose to retransmit the whole PDU including the immediate data. 9361 Note 2: A target should use this reason code for all invalid values 9362 of PDU fields that are meant to describe a task, a response, or a 9363 data transfer. Some examples are invalid TTT/ITT, buffer offset, 9364 LUN qualifying a TTT, and an invalid sequence number in a SNACK. 9366 Note 3: Reason code 0x0b ("Negotiation reset") defined in [RFC3720] 9367 is deprecated and MUST NOT be used by implementations. An 9368 implementation receiving reason code 0x0b MUST treat it as a 9369 negotiation failure that terminates the Login Phase and the TCP 9370 connection, as specified in Section 7.12. 9372 All other values for Reason are reserved. 9374 In all the cases in which a pre-instantiated SCSI task is 9375 terminated because of the reject, the target MUST issue a proper 9376 SCSI command response with CHECK CONDITION as described in Section 9377 11.4.3. In these cases in which a status for the SCSI task was 9378 already sent before the reject, no additional status is required. 9379 If the error is detected while data from the initiator is still 9380 expected (i.e., the command PDU did not contain all the data and 9381 the target has not received a Data-out PDU with the Final bit set 9382 to 1 for the unsolicited data, if any, and all outstanding R2Ts, if 9383 any), the target MUST wait until it receives the last expected 9384 Data-out PDUs with the F bit set to 1 before sending the Response 9385 PDU. 9387 For additional usage semantics of Reject PDU, see Section 6.3 - 9388 "Usage Of Reject PDU in Recovery". 9390 11.17.2. DataSN/R2TSN 9392 This field is only valid if the rejected PDU is a Data/R2T SNACK 9393 and the Reject reason code is "Protocol error" (see SNACK). The 9394 DataSN/R2TSN is the next Data/R2T sequence number that the target 9395 would send for the task, if any. 9397 11.17.3. StatSN, ExpCmdSN and MaxCmdSN 9399 These fields carry their usual values and are not related to the 9400 rejected command. StatSN is advanced after a Reject. 9402 11.17.4. Complete Header of Bad PDU 9404 The target returns the header (not including digest) of the PDU in 9405 error as the data of the response. 9407 11.18. NOP-Out 9409 Byte/ 0 | 1 | 2 | 3 | 9410 / | | | | 9411 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 9412 +---------------+---------------+---------------+---------------+ 9413 0|.|I| 0x00 |1| Reserved | 9414 +---------------+---------------+---------------+---------------+ 9415 4|TotalAHSLength | DataSegmentLength | 9416 +---------------+---------------+---------------+---------------+ 9417 8| LUN or Reserved | 9418 + + 9419 12| | 9420 +---------------+---------------+---------------+---------------+ 9421 16| Initiator Task Tag or 0xffffffff | 9422 +---------------+---------------+---------------+---------------+ 9423 20| Target Transfer Tag or 0xffffffff | 9424 +---------------+---------------+---------------+---------------+ 9425 24| CmdSN | 9426 +---------------+---------------+---------------+---------------+ 9427 28| ExpStatSN | 9428 +---------------+---------------+---------------+---------------+ 9429 32/ Reserved / 9430 +/ / 9431 +---------------+---------------+---------------+---------------+ 9432 48| Header-Digest (Optional) | 9433 +---------------+---------------+---------------+---------------+ 9434 / DataSegment - Ping Data (optional) / 9435 +/ / 9436 +---------------+---------------+---------------+---------------+ 9437 | Data-Digest (Optional) | 9438 +---------------+---------------+---------------+---------------+ 9440 A NOP-Out may be used by an initiator as a "ping request" to verify 9441 that a connection/session is still active and all its components 9442 are operational. The NOP-In response is the "ping echo". 9444 A NOP-Out is also sent by an initiator in response to a NOP-In. 9446 A NOP-Out may also be used to confirm a changed ExpStatSN if 9447 another PDU will not be available for a long time. 9449 Upon receipt of a NOP-In with the Target Transfer Tag set to a 9450 valid value (not the reserved 0xffffffff), the initiator MUST 9451 respond with a NOP-Out. In this case, the NOP-Out Target Transfer 9452 Tag MUST contain a copy of the NOP-In Target Transfer Tag. 9454 11.18.1. Initiator Task Tag 9456 The NOP-Out MUST have the Initiator Task Tag set to a valid value 9457 only if a response in the form of NOP-In is requested (i.e., the 9458 NOP-Out is used as a ping request). Otherwise, the Initiator Task 9459 Tag MUST be set to 0xffffffff. 9461 When a target receives the NOP-Out with a valid Initiator Task Tag, 9462 it MUST respond with a Nop-In Response (see Login and Full Feature 9463 Phase Negotiation). 9465 If the Initiator Task Tag contains 0xffffffff, the I bit MUST be 9466 set to 1 and the CmdSN is not advanced after this PDU is sent. 9468 11.18.2. Target Transfer Tag 9470 A target assigned identifier for the operation. 9472 The NOP-Out MUST only have the Target Transfer Tag set if it is 9473 issued in response to a NOP-In with a valid Target Transfer Tag. In 9474 this case, it copies the Target Transfer Tag from the NOP-In PDU. 9475 Otherwise, the Target Transfer Tag MUST be set to 0xffffffff. 9477 When the Target Transfer Tag is set to a value other than 9478 0xffffffff, the LUN field MUST also be copied from the NOP-In. 9480 11.18.3. Ping Data 9482 Ping data are reflected in the NOP-In Response. The length of the 9483 reflected data are limited to MaxRecvDataSegmentLength. The length 9484 of ping data are indicated by the DataSegmentLength. 0 is a valid 9485 value for the DataSegmentLength and indicates the absence of ping 9486 data. 9488 11.19. NOP-In 9490 Byte/ 0 | 1 | 2 | 3 | 9491 / | | | | 9492 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 9493 +---------------+---------------+---------------+---------------+ 9494 0|.|.| 0x20 |1| Reserved | 9495 +---------------+---------------+---------------+---------------+ 9496 4|TotalAHSLength | DataSegmentLength | 9497 +---------------+---------------+---------------+---------------+ 9498 8| LUN or Reserved | 9499 + + 9500 12| | 9501 +---------------+---------------+---------------+---------------+ 9502 16| Initiator Task Tag or 0xffffffff | 9503 +---------------+---------------+---------------+---------------+ 9504 20| Target Transfer Tag or 0xffffffff | 9505 +---------------+---------------+---------------+---------------+ 9506 24| StatSN | 9507 +---------------+---------------+---------------+---------------+ 9508 28| ExpCmdSN | 9509 +---------------+---------------+---------------+---------------+ 9510 32| MaxCmdSN | 9511 +---------------+---------------+---------------+---------------+ 9512 36/ Reserved / 9513 +/ / 9514 +---------------+---------------+---------------+---------------+ 9515 48| Header-Digest (Optional) | 9516 +---------------+---------------+---------------+---------------+ 9517 / DataSegment - Return Ping Data / 9518 +/ / 9519 +---------------+---------------+---------------+---------------+ 9520 | Data-Digest (Optional) | 9521 +---------------+---------------+---------------+---------------+ 9523 NOP-In is either sent by a target as a response to a NOP-Out, as a 9524 "ping" to an initiator, or as a means to carry a changed ExpCmdSN 9525 and/or MaxCmdSN if another PDU will not be available for a long 9526 time (as determined by the target). 9528 When a target receives the NOP-Out with a valid Initiator Task Tag 9529 (not the reserved value 0xffffffff), it MUST respond with a NOP-In 9530 with the same Initiator Task Tag that was provided in the NOP-Out 9531 request. It MUST also duplicate up to the first 9532 MaxRecvDataSegmentLength bytes of the initiator provided Ping Data. 9533 For such a response, the Target Transfer Tag MUST be 0xffffffff. 9535 Otherwise, when a target sends a NOP-In that is not a response to a 9536 Nop-Out received from the initiator, the Initiator Task Tag MUST be 9537 set to 0xffffffff and the Data Segment MUST NOT contain any data 9538 (DataSegmentLength MUST be 0). 9540 11.19.1. Target Transfer Tag 9542 If the target is responding to a NOP-Out, this is set to the 9543 reserved value 0xffffffff. 9545 If the target is sending a NOP-In as a Ping (intending to receive a 9546 corresponding NOP-Out), this field is set to a valid value (not the 9547 reserved 0xffffffff). 9549 If the target is initiating a NOP-In without wanting to receive a 9550 corresponding NOP-Out, this field MUST hold the reserved value of 9551 0xffffffff. 9553 11.19.2. StatSN 9555 The StatSN field will always contain the next StatSN. However, when 9556 the Initiator Task Tag is set to 0xffffffff StatSN for the 9557 connection is not advanced after this PDU is sent. 9559 11.19.3. LUN 9561 A LUN MUST be set to a correct value when the Target Transfer Tag 9562 is valid (not the reserved value 0xffffffff). 9564 12. iSCSI Security Text Keys and Authentication Methods 9566 Only the following keys are used during the SecurityNegotiation 9567 stage of the Login Phase: 9569 SessionType 9571 InitiatorName 9573 TargetName 9575 TargetAddress 9577 InitiatorAlias 9579 TargetAlias 9581 TargetPortalGroupTag 9583 AuthMethod and the keys used by the authentication methods 9584 specified under Section 12.1 along with all of their 9585 associated keys as well as Vendor Specific Authentication 9586 Methods. 9588 Other keys MUST NOT be used. 9590 SessionType, InitiatorName, TargetName, InitiatorAlias, 9591 TargetAlias, and TargetPortalGroupTag are described in Section 13 9592 as they can be used also in the OperationalNegotiation stage. 9594 All security keys have connection-wide applicability. 9596 12.1. AuthMethod 9598 Use: During Login - Security Negotiation 9599 Senders: Initiator and Target 9600 Scope: connection 9602 AuthMethod = 9604 The main item of security negotiation is the authentication method 9605 (AuthMethod). 9607 The authentication methods that can be used (appear in the list-of- 9608 values) are either those listed in the following table or are 9609 vendor-unique methods: 9611 +------------------------------------------------------------+ 9612 | Name | Description | 9613 +------------------------------------------------------------+ 9614 | KRB5 | Kerberos V5 - defined in [RFC4120] | 9615 +------------------------------------------------------------+ 9616 | SRP | Secure Remote Password | 9617 | | defined in [RFC2945] | 9618 +------------------------------------------------------------+ 9619 | CHAP | Challenge Handshake Authentication Protocol| 9620 | | defined in [RFC1994] | 9621 +------------------------------------------------------------+ 9622 | None | No authentication | 9623 +------------------------------------------------------------+ 9625 The AuthMethod selection is followed by an "authentication 9626 exchange" specific to the authentication method selected. 9628 The authentication method proposal may be made by either the 9629 initiator or the target. However the initiator MUST make the first 9630 step specific to the selected authentication method as soon as it 9631 is selected. It follows that if the target makes the authentication 9632 method proposal the initiator sends the first key(s) of the 9633 exchange together with its authentication method selection. 9635 The authentication exchange authenticates the initiator to the 9636 target, and optionally, the target to the initiator. 9637 Authentication is OPTIONAL to use but MUST be supported by the 9638 target and initiator. 9640 The initiator and target MUST implement CHAP. All other 9641 authentication methods are OPTIONAL. 9643 Private or public extension algorithms MAY also be negotiated for 9644 authentication methods. Whenever a private or public extension 9645 algorithm is part of the default offer (the offer made in absence 9646 of explicit administrative action) the implementer MUST ensure that 9647 CHAP is listed as an alternative in the default offer and "None" 9648 is not part of the default offer. 9650 Extension authentication methods MUST be named using one of the 9651 following two formats: 9653 i) Z-reversed.vendor.dns_name.do_something= 9654 i) Z<#>= 9656 Authentication methods named using the Z- format are used as 9657 private extensions. Authentication methods named using the Z# 9658 format are used as public extensions that must be registered with 9659 IANA and MUST be described by a standards track RFC, an 9660 experimental RFC, or an informational RFC. 9662 For all of the public or private extension authentication methods, 9663 the method specific keys MUST conform to the format specified in 9664 Section 5.1 - "Text Format" for standard-label. 9666 To identify the vendor for private extension authentication 9667 methods, we suggest you use the reversed DNS-name as a prefix to 9668 the proper digest names. 9670 The part of digest-name following Z- and Z# MUST conform to the 9671 format for standard-label specified in Section 5.1 - "Text Format". 9673 Support for public or private extension authentication methods is 9674 OPTIONAL. 9676 The following subsections define the specific exchanges for each of 9677 the standardized authentication methods. As mentioned earlier the 9678 first step is always done by the initiator. 9680 12.1.1. Kerberos 9682 For KRB5 (Kerberos V5) [RFC4120] and [RFC1964], the initiator MUST 9683 use: 9685 KRB_AP_REQ= 9687 where KRB_AP_REQ is the client message as defined in [RFC4120]. 9689 The default principal name assumed by an iSCSI initiator or target 9690 (prior to any administrative configuration action) MUST be the 9691 iSCSI Initiator Name or iSCSI Target Name respectively, prefixed by 9692 the string "iscsi/". 9694 If the initiator authentication fails, the target MUST respond with 9695 a Login reject with "Authentication Failure" status. Otherwise, if 9696 the initiator has selected the mutual authentication option (by 9697 setting MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), 9698 the target MUST reply with: 9700 KRB_AP_REP= 9702 where KRB_AP_REP is the server's response message as defined in 9703 [RFC4120]. 9705 If mutual authentication was selected and target authentication 9706 fails, the initiator MUST close the connection. 9708 KRB_AP_REQ and KRB_AP_REP are binary-values and their binary length 9709 (not the length of the character string that represents them in 9710 encoded form) MUST NOT exceed 65536 bytes. 9712 12.1.2. Secure Remote Password (SRP) 9714 For SRP [RFC2945], the initiator MUST use: 9716 SRP_U= TargetAuth=Yes /* or TargetAuth=No */ 9718 The target MUST answer with a Login reject with the "Authorization 9719 Failure" status or reply with: 9721 SRP_GROUP= SRP_s= 9723 Where G1,G2... are proposed groups, in order of preference. 9725 The initiator MUST either close the connection or continue with: 9727 SRP_A= SRP_GROUP= 9728 Where G is one of G1,G2... that were proposed by the target. 9730 The target MUST answer with a Login reject with the "Authentication 9731 Failure" status or reply with: 9733 SRP_B= 9735 The initiator MUST close the connection or continue with: 9737 SRP_M= 9739 If the initiator authentication fails, the target MUST answer with 9740 a Login reject with "Authentication Failure" status. Otherwise, if 9741 the initiator sent TargetAuth=Yes in the first message (requiring 9742 target authentication), the target MUST reply with: 9744 SRP_HM= 9746 If the target authentication fails, the initiator MUST close the 9747 connection. 9749 Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] 9750 (using the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn 9751 stands for G1,G2...) are identifiers of SRP groups specified in 9752 [RFC3723]. G, Gn, and U are text strings, s,A,B,M, and H(A | M | K) 9753 are binary-values. The length of s,A,B,M and H(A | M | K) in binary 9754 form (not the length of the character string that represents them 9755 in encoded form) MUST NOT exceed 1024 bytes. 9757 For the SRP_GROUP, all the groups specified in [RFC3723] up to 1536 9758 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be 9759 supported by initiators and targets. To guarantee interoperability, 9760 targets MUST always offer "SRP-1536" as one of the proposed groups. 9762 12.1.3. Challenge Handshake Authentication Protocol (CHAP) 9764 For CHAP [RFC1994], the initiator MUST use: 9766 CHAP_A= 9768 Where A1,A2... are proposed algorithms, in order of preference. 9770 The target MUST answer with a Login reject with the "Authentication 9771 Failure" status or reply with: 9773 CHAP_A= CHAP_I= CHAP_C= 9775 Where A is one of A1,A2... that were proposed by the initiator. 9777 The initiator MUST continue with: 9779 CHAP_N= CHAP_R= 9781 or, if it requires target authentication, with: 9783 CHAP_N= CHAP_R= CHAP_I= CHAP_C= 9785 If the initiator authentication fails, the target MUST answer with 9786 a Login reject with "Authentication Failure" status. Otherwise, if 9787 the initiator required target authentication, the target MUST 9788 either answer with a Login reject with "Authentication Failure" or 9789 reply with: 9791 CHAP_N= CHAP_R= 9793 If target authentication fails, the initiator MUST close the 9794 connection. 9796 Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, 9797 Algorithm, Identifier, Challenge, and Response as defined in 9798 [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C 9799 and R are binary-values and their binary length (not the length of 9800 the character string that represents them in encoded form) MUST NOT 9801 exceed 1024 bytes. 9803 For the Algorithm, as stated in [RFC1994], one value is required 9804 to be implemented: 9806 5 (CHAP with MD5) 9808 To guarantee interoperability, initiators MUST always offer it as 9809 one of the proposed algorithms. 9811 13. Login/Text Operational Text Keys 9813 Some session specific parameters MUST only be carried on the 9814 leading connection and cannot be changed after the leading 9815 connection login (e.g., MaxConnections, the maximum number of 9816 connections). This holds for a single connection session with 9817 regard to connection restart. The keys that fall into this category 9818 have the use: LO (Leading Only). 9820 Keys that can only be used during login have the use: IO 9821 (initialize only), while those that can be used in both the Login 9822 Phase and Full Feature Phase have the use: ALL. 9824 Keys that can only be used during Full Feature Phase use FFPO (Full 9825 Feature Phase only). 9827 Keys marked as Any-Stage may also appear in the SecurityNegotiation 9828 stage while all other keys described in this chapter are 9829 operational keys. 9831 Keys that do not require an answer are marked as Declarative. 9833 Key scope is indicated as session-wide (SW) or connection-only 9834 (CO). 9836 Result function, wherever mentioned, states the function that can 9837 be applied to check the validity of the responder selection. 9838 Minimum means that the selected value cannot exceed the offered 9839 value. Maximum means that the selected value cannot be lower than 9840 the offered value. AND means that the selected value must be a 9841 possible result of a Boolean "and" function with an arbitrary 9842 Boolean value (e.g., if the offered value is No the selected value 9843 must be No). OR means that the selected value must be a possible 9844 result of a Boolean "or" function with an arbitrary Boolean value 9845 (e.g., if the offered value is Yes the selected value must be Yes). 9847 13.1. HeaderDigest and DataDigest 9849 Use: IO 9850 Senders: Initiator and Target 9851 Scope: CO 9852 HeaderDigest = 9853 DataDigest = 9855 Default is None for both HeaderDigest and DataDigest. 9857 Digests enable the checking of end-to-end, non-cryptographic data 9858 integrity beyond the integrity checks provided by the link layers 9859 and the covering of the whole communication path including all 9860 elements that may change the network level PDUs such as routers, 9861 switches, and proxies. 9863 The following table lists cyclic integrity checksums that can be 9864 negotiated for the digests and that MUST be implemented by every 9865 iSCSI initiator and target. These digest options only have error 9866 detection significance. 9868 +---------------------------------------------+ 9869 | Name | Description | Generator | 9870 +---------------------------------------------+ 9871 | CRC32C | 32 bit CRC |0x11edc6f41| 9872 +---------------------------------------------+ 9873 | None | no digest | 9874 +---------------------------------------------+ 9876 The generator polynomial for this digest is given in hex-notation 9877 (e.g., 0x3b stands for 0011 1011 and the polynomial is 9878 x**5+X**4+x**3+x+1). 9880 When the Initiator and Target agree on a digest, this digest MUST 9881 be used for every PDU in Full Feature Phase. 9883 Padding bytes, when present in a segment covered by a CRC, SHOULD 9884 be set to 0 and are included in the CRC. 9886 The CRC MUST be calculated by a method that produces the same 9887 results as the following process: 9889 - The PDU bits are considered as the coefficients of a 9890 polynomial M(x) of degree n-1; bit 7 of the lowest numbered 9891 byte is considered the most significant bit (x^n-1), followed 9893 by bit 6 of the lowest numbered byte through bit 0 of the 9894 highest numbered byte (x^0). 9896 - The most significant 32 bits are complemented. 9898 - The polynomial is multiplied by x^32 then divided by G(x). 9899 The generator polynomial produces a remainder R(x) of degree 9900 <= 31. 9902 - The coefficients of R(x) are considered a 32 bit sequence. 9904 - The bit sequence is complemented and the result is the CRC. 9906 - The CRC bits are mapped into the digest word. The x^31 9907 coefficient in bit 7 of the lowest numbered byte of the 9908 digest continuing through to the byte up to the x^24 9909 coefficient in bit 0 of the lowest numbered byte, continuing 9910 with the x^23 coefficient in bit 7 of next byte through x^0 9911 in bit 0 of the highest numbered byte. 9913 - Computing the CRC over any segment (data or header) extended 9914 to include the CRC built using the generator 0x11edc6f41 will 9915 always get the value 0x1c2d19ed as its final remainder 9916 (R(x)). This value is given here in its polynomial form 9917 (i.e., not mapped as the digest word). 9919 For a discussion about selection criteria for the CRC, see 9920 [RFC3385]. For a detailed analysis of the iSCSI polynomial, see 9921 [Castagnoli93]. 9923 Private or public extension algorithms MAY also be negotiated for 9924 digests. Whenever a private or public digest extension algorithm is 9925 part of the default offer (the offer made in absence of explicit 9926 administrative action) the implementer MUST ensure that CRC32C is 9927 listed as an alternative in the default offer and "None" is not 9928 part of the default offer. 9930 Extension digest algorithms MUST be named using one of the 9931 following two formats: 9933 ii) Y-reversed.vendor.dns_name.do_something= 9934 iii) Y<#>= 9936 Digests named using the Y- format are used for private purposes 9937 (unregistered). Digests named using the Y# format (public 9938 extension) must be registered with IANA and MUST be described by a 9939 standards track RFC, an experimental RFC, or an informational RFC. 9941 For private extension digests, to identify the vendor, we suggest 9942 you use the reversed DNS-name as a prefix to the proper digest 9943 names. 9945 The part of digest-name following Y- and Y# MUST conform to the 9946 format for standard-label specified in Section 6.1. 9948 Support for public or private extension digests is OPTIONAL. 9950 13.2. MaxConnections 9952 Use: LO 9953 Senders: Initiator and Target 9954 Scope: SW 9955 Irrelevant when: SessionType=Discovery 9957 MaxConnections= 9959 Default is 1. 9960 Result function is Minimum. 9962 Initiator and target negotiate the maximum number of connections 9963 requested/acceptable. 9965 13.3. SendTargets 9967 Use: FFPO 9968 Senders: Initiator 9969 Scope: SW 9971 For a complete description, see Appendix D. - "SendTargets 9972 Operation". 9974 13.4. TargetName 9976 Use: IO by initiator, FFPO by target - only as response to a 9977 SendTargets, Declarative, Any-Stage 9978 Senders: Initiator and Target 9979 Scope: SW 9981 TargetName= 9983 Examples: 9985 TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678 9987 TargetName=eui.020000023B040506 9989 TargetName=naa.62004567BA64678D0123456789ABCDEF 9991 The initiator of the TCP connection MUST provide this key to the 9992 remote endpoint in the first login request if the initiator is not 9993 establishing a discovery session. The iSCSI Target Name specifies 9994 the worldwide unique name of the target. 9996 The TargetName key may also be returned by the "SendTargets" text 9997 request (which is its only use when issued by a target). 9999 TargetName MUST NOT be redeclared within the login phase. 10001 13.5. InitiatorName 10003 Use: IO, Declarative, Any-Stage 10004 Senders: Initiator 10005 Scope: SW 10007 InitiatorName= 10009 Examples: 10011 InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345 10013 InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90 10014 InitiatorName=naa.52004567BA64678D 10016 The initiator of the TCP connection MUST provide this key to the 10017 remote endpoint at the first Login of the Login Phase for every 10018 connection. The InitiatorName key enables the initiator to identify 10019 itself to the remote endpoint. 10021 InitiatorName MUST NOT be redeclared within the login phase. 10023 13.6. TargetAlias 10025 Use: ALL, Declarative, Any-Stage 10026 Senders: Target 10027 Scope: SW 10029 TargetAlias= 10031 Examples: 10033 TargetAlias=Bob-s Disk 10035 TargetAlias=Database Server 1 Log Disk 10037 TargetAlias=Web Server 3 Disk 20 10039 If a target has been configured with a human-readable name or 10040 description, this name SHOULD be communicated to the initiator 10041 during a Login Response PDU if SessionType=Normal (see 13.21). This 10042 string is not used as an identifier, nor is it meant to be used for 10043 authentication or authorization decisions. It can be displayed by 10044 the initiator's user interface in a list of targets to which it is 10045 connected. 10047 13.7. InitiatorAlias 10049 Use: ALL, Declarative, Any-Stage 10050 Senders: Initiator 10051 Scope: SW 10053 InitiatorAlias= 10054 Examples: 10056 InitiatorAlias=Web Server 4 10058 InitiatorAlias=spyalley.nsa.gov 10060 InitiatorAlias=Exchange Server 10062 If an initiator has been configured with a human-readable name or 10063 description, it SHOULD be communicated to the target during a Login 10064 Request PDU. If not, the host name can be used instead. This string 10065 is not used as an identifier, nor is meant to be used for 10066 authentication or authorization decisions. It can be displayed by 10067 the target's user interface in a list of initiators to which it is 10068 connected. 10070 13.8. TargetAddress 10072 Use: ALL, Declarative, Any-Stage 10073 Senders: Target 10074 Scope: SW 10076 TargetAddress=domainname[:port][,portal-group-tag] 10078 The domainname can be specified as either a DNS host name, a 10079 dotted-decimal IPv4 address, or a bracketed IPv6 address as 10080 specified in [RFC3986]. 10082 If the TCP port is not specified, it is assumed to be the IANA- 10083 assigned default port for iSCSI (see Section 13 -"IANA 10084 Considerations"). 10086 If the TargetAddress is returned as the result of a redirect status 10087 in a login response, the comma and portal group tag MUST be 10088 omitted. 10090 If the TargetAddress is returned within a SendTargets response, the 10091 portal group tag MUST be included. 10093 Examples: 10095 TargetAddress=10.0.0.1:5003,1 10097 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 10099 TargetAddress=[1080::8:800:200C:417A]:5003,1 10101 TargetAddress=computingcenter.example.com,23 10103 Use of the portal-group-tag is described in Appendix D. - 10104 "SendTargets Operation". The formats for the port and portal-group- 10105 tag are the same as the one specified in TargetPortalGroupTag. 10107 13.9. TargetPortalGroupTag 10109 Use: IO by target, Declarative, Any-Stage 10110 Senders: Target 10111 Scope: SW 10113 TargetPortalGroupTag=<16-bit-binary-value> 10115 Examples: 10116 TargetPortalGroupTag=1 10118 The target portal group tag is a 16-bit binary-value that uniquely 10119 identifies a portal group within an iSCSI target node. This key 10120 carries the value of the tag of the portal group that is servicing 10121 the Login request. The iSCSI target returns this key to the 10122 initiator in the Login Response PDU to the first Login Request PDU 10123 that has the C bit set to 0 when TargetName is given by the 10124 initiator. 10126 [SAM2] and [SAM3] specifications note in their informative text 10127 that TPGT value should be non-zero, note that it is incorrect. A 10128 zero value is allowed as a legal value for TPGT. This discrepancy 10129 currently stands corrected in [SAM4]. 10131 For the complete usage expectations of this key see Section 6.3. 10133 13.10. InitialR2T 10135 Use: LO 10136 Senders: Initiator and Target 10137 Scope: SW 10138 Irrelevant when: SessionType=Discovery 10140 InitialR2T= 10142 Examples: 10144 I->InitialR2T=No 10146 T->InitialR2T=No 10148 Default is Yes. 10149 Result function is OR. 10151 The InitialR2T key is used to turn off the default use of R2T for 10152 unidirectional and the output part of bidirectional commands, thus 10153 allowing an initiator to start sending data to a target as if it 10154 has received an initial R2T with Buffer Offset=Immediate Data 10155 Length and Desired Data Transfer Length=(min(FirstBurstLength, 10156 Expected Data Transfer Length) - Received Immediate Data Length). 10158 The default action is that R2T is required, unless both the 10159 initiator and the target send this key-pair attribute specifying 10160 InitialR2T=No. Only the first outgoing data burst (immediate data 10161 and/or separate PDUs) can be sent unsolicited (i.e., not requiring 10162 an explicit R2T). 10164 13.11. ImmediateData 10166 Use: LO 10167 Senders: Initiator and Target 10168 Scope: SW 10169 Irrelevant when: SessionType=Discovery 10171 ImmediateData= 10173 Default is Yes. 10175 Result function is AND. 10177 The initiator and target negotiate support for immediate data. To 10178 turn immediate data off, the initiator or target must state its 10179 desire to do so. ImmediateData can be turned on if both the 10180 initiator and target have ImmediateData=Yes. 10182 If ImmediateData is set to Yes and InitialR2T is set to Yes 10183 (default), then only immediate data are accepted in the first 10184 burst. 10186 If ImmediateData is set to No and InitialR2T is set to Yes, then 10187 the initiator MUST NOT send unsolicited data and the target MUST 10188 reject unsolicited data with the corresponding response code. 10190 If ImmediateData is set to No and InitialR2T is set to No, then the 10191 initiator MUST NOT send unsolicited immediate data, but MAY send 10192 one unsolicited burst of Data-OUT PDUs. 10194 If ImmediateData is set to Yes and InitialR2T is set to No, then 10195 the initiator MAY send unsolicited immediate data and/or one 10196 unsolicited burst of Data-OUT PDUs. 10198 The following table is a summary of unsolicited data options: 10200 +----------+-------------+------------------+--------------+ 10201 |InitialR2T|ImmediateData| Unsolicited |Immediate Data| 10202 | | | Data Out PDUs | | 10203 +----------+-------------+------------------+--------------+ 10204 | No | No | Yes | No | 10205 +----------+-------------+------------------+--------------+ 10206 | No | Yes | Yes | Yes | 10207 +----------+-------------+------------------+--------------+ 10208 | Yes | No | No | No | 10209 +----------+-------------+------------------+--------------+ 10210 | Yes | Yes | No | Yes | 10211 +----------+-------------+------------------+--------------+ 10213 13.12. MaxRecvDataSegmentLength 10215 Use: ALL, Declarative 10216 Senders: Initiator and Target 10217 Scope: CO 10219 MaxRecvDataSegmentLength= 10221 Default is 8192 bytes. 10223 The initiator or target declares the maximum data segment length in 10224 bytes it can receive in an iSCSI PDU. 10226 The transmitter (initiator or target) is required to send PDUs with 10227 a data segment that does not exceed MaxRecvDataSegmentLength of the 10228 receiver. 10230 A target receiver is additionally limited by MaxBurstLength for 10231 solicited data and FirstBurstLength for unsolicited data. An 10232 initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor 10233 unsolicited PDUs exceeding FirstBurstLength (or FirstBurstLength- 10234 Immediate Data Length if immediate data were sent). 10236 13.13. MaxBurstLength 10238 Use: LO 10239 Senders: Initiator and Target 10240 Scope: SW 10241 Irrelevant when: SessionType=Discovery 10243 MaxBurstLength= 10245 Default is 262144 (256 Kbytes). 10246 Result function is Minimum. 10248 The initiator and target negotiate maximum SCSI data payload in 10249 bytes in a Data-In or a solicited Data-Out iSCSI sequence. A 10250 sequence consists of one or more consecutive Data-In or Data-Out 10251 PDUs that end with a Data-In or Data-Out PDU with the F bit set to 10252 one. 10254 13.14. FirstBurstLength 10256 Use: LO 10257 Senders: Initiator and Target 10258 Scope: SW 10259 Irrelevant when: SessionType=Discovery 10260 Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) 10262 FirstBurstLength= 10264 Default is 65536 (64 Kbytes). 10265 Result function is Minimum. 10267 The initiator and target negotiate the maximum amount in bytes of 10268 unsolicited data an iSCSI initiator may send to the target during 10269 the execution of a single SCSI command. This covers the immediate 10270 data (if any) and the sequence of unsolicited Data-Out PDUs (if 10271 any) that follow the command. 10273 FirstBurstLength MUST NOT exceed MaxBurstLength. 10275 13.15. DefaultTime2Wait 10277 Use: LO 10278 Senders: Initiator and Target 10279 Scope: SW 10281 DefaultTime2Wait= 10283 Default is 2. 10284 Result function is Maximum. 10286 The initiator and target negotiate the minimum time, in seconds, to 10287 wait before attempting an explicit/implicit logout or an active 10288 task reassignment after an unexpected connection termination or a 10289 connection reset. 10291 A value of 0 indicates that logout or active task reassignment can 10292 be attempted immediately. 10294 13.16. DefaultTime2Retain 10296 Use: LO 10297 Senders: Initiator and Target 10298 Scope: SW 10299 DefaultTime2Retain= 10301 Default is 20. 10302 Result function is Minimum. 10304 The initiator and target negotiate the maximum time, in seconds 10305 after an initial wait (Time2Wait), before which an active task 10306 reassignment is still possible after an unexpected connection 10307 termination or a connection reset. 10309 This value is also the session state timeout if the connection in 10310 question is the last LOGGED_IN connection in the session. 10312 A value of 0 indicates that connection/task state is immediately 10313 discarded by the target. 10315 13.17. MaxOutstandingR2T 10317 Use: LO 10318 Senders: Initiator and Target 10319 Scope: SW 10321 MaxOutstandingR2T= 10322 Irrelevant when: SessionType=Discovery 10324 Default is 1. 10325 Result function is Minimum. 10327 Initiator and target negotiate the maximum number of outstanding 10328 R2Ts per task, excluding any implied initial R2T that might be part 10329 of that task. An R2T is considered outstanding until the last data 10330 PDU (with the F bit set to 1) is transferred, or a sequence 10331 reception timeout (Section 7.1.4.1) is encountered for that data 10332 sequence. 10334 13.18. DataPDUInOrder 10336 Use: LO 10337 Senders: Initiator and Target 10338 Scope: SW 10339 Irrelevant when: SessionType=Discovery 10340 DataPDUInOrder= 10342 Default is Yes. 10343 Result function is OR. 10345 No is used by iSCSI to indicate that the data PDUs within sequences 10346 can be in any order. Yes is used to indicate that data PDUs within 10347 sequences have to be at continuously increasing addresses and 10348 overlays are forbidden. 10350 13.19. DataSequenceInOrder 10352 Use: LO 10353 Senders: Initiator and Target 10354 Scope: SW 10355 Irrelevant when: SessionType=Discovery 10357 DataSequenceInOrder= 10359 Default is Yes. 10360 Result function is OR. 10362 A Data Sequence is a sequence of Data-In or Data-Out PDUs that end 10363 with a Data-In or Data-Out PDU with the F bit set to one. A Data- 10364 out sequence is sent either unsolicited or in response to an R2T. 10365 Sequences cover an offset-range. 10367 If DataSequenceInOrder is set to No, Data PDU sequences may be 10368 transferred in any order. 10370 If DataSequenceInOrder is set to Yes, Data Sequences MUST be 10371 transferred using continuously non-decreasing sequence offsets (R2T 10372 buffer offset for writes, or the smallest SCSI Data-In buffer 10373 offset within a read data sequence). 10375 If DataSequenceInOrder is set to Yes, a target may retry at most 10376 the last R2T, and an initiator may at most request retransmission 10377 for the last read data sequence. For this reason, if 10378 ErrorRecoveryLevel is not 0 and DataSequenceInOrder is set to Yes 10379 then MaxOustandingR2T MUST be set to 1. 10381 13.20. ErrorRecoveryLevel 10383 Use: LO 10384 Senders: Initiator and Target 10385 Scope: SW 10387 ErrorRecoveryLevel= 10389 Default is 0. 10390 Result function is Minimum. 10392 The initiator and target negotiate the recovery level supported. 10394 Recovery levels represent a combination of recovery capabilities. 10395 Each recovery level includes all the capabilities of the lower 10396 recovery levels and adds some new ones to them. 10398 In the description of recovery mechanisms, certain recovery classes 10399 are specified. Section 7.1.5 describes the mapping between the 10400 classes and the levels. 10402 13.21. SessionType 10404 Use: LO, Declarative, Any-Stage 10405 Senders: Initiator 10406 Scope: SW 10408 SessionType= 10410 Default is Normal. 10412 The Initiator indicates the type of session it wants to create. The 10413 target can either accept it or reject it. 10415 A Discovery session indicates to the Target that the only purpose 10416 of this Session is discovery. The only requests a target accepts in 10417 this type of session are a text request with a SendTargets key and 10418 a logout request with reason "close the session". 10420 The Discovery session implies MaxConnections = 1 and overrides both 10421 the default and an explicit setting. As section 7.4.1 states, 10422 ErrorRecoveryLevel MUST be 0 (zero) for Discovery sessions. 10424 Depending on the type of the session, a target may decide on 10425 resources to allocate and the security to enforce, etc. for the 10426 session. If the SessionType key is thus going to be offered as 10427 "Discovery", it SHOULD be offered in the initial Login request by 10428 the initiator. 10430 13.22. The Private or Public Extension Key Format 10432 Use: ALL 10433 Senders: Initiator and Target 10434 Scope: specific key dependent 10436 X-reversed.vendor.dns_name.do_something= 10438 or 10440 X<#>= 10442 Keys with this format are used for public or private extension 10443 purposes. These keys always start with X- if unregistered with IANA 10444 (private) or X# if registered with IANA (public). 10446 For unregistered keys, to identify the vendor, we suggest you use 10447 the reversed DNS-name as a prefix to the key-proper. 10449 The part of key-name following X- and X# MUST conform to the format 10450 for key-name specified in Section 5.1 -"Text Format". 10452 For IANA registered keys the string following X# must be registered 10453 with IANA and the use of the key MUST be described by a standards 10454 track RFC, an experimental RFC, or an informational RFC. 10456 Vendor specific keys MUST ONLY be used in normal sessions. 10458 Support for public or private extension keys is OPTIONAL. 10460 13.23. Task Reporting 10462 Use: LO 10463 Senders: Initiator and Target 10464 Scope: SW 10465 Irrelevant when: SessionType=Discovery 10466 TaskReporting= 10468 Default is RFC3720. 10469 Result function is AND. 10471 This key is used to negotiate the task completion reporting 10472 semantics from the SCSI target. The following table describes the 10473 semantics that an iSCSI target MUST support for respective 10474 negotiated key values. Whenever this key is negotiated, at least 10475 the RFC3720 and ResponseFence values MUST be offered as options by 10476 the negotiation originator. 10477 +--------------+------------------------------------------+ 10478 | Name | Description | 10479 +--------------+------------------------------------------+ 10480 | RFC3720 | RFC 3720-compliant semantics. Response | 10481 | | fencing is not guaranteed and fast | 10482 | | completion of multi-task aborting is not | 10483 | | supported | 10484 +--------------+------------------------------------------+ 10485 | ResponseFence| Response Fence (section 4.2.2.3.3) | 10486 | | semantics MUST be supported in reporting | 10487 | | task completions | 10488 +--------------+------------------------------------------+ 10489 | FastAbort | Updated fast multi-task abort semantics | 10490 | | defined in Section 4.2.3.4 MUST be | 10491 | | supported. Support for Response Fence is | 10492 | | implied -- i.e., (Section 4.2.2.3.3) | 10493 | | semantics MUST be supported as well | 10494 +--------------+------------------------------------------+ 10495 When TaskReporting is not negotiated to FastAbort, the standard 10496 multi-task abort semantics in Section 4.2.3.3 MUST be used. 10498 13.24. X#NodeArchitecture 10500 13.24.1. Definition 10502 Use: LO, Declarative 10503 Senders: Initiator and Target 10504 Scope: SW 10506 X#NodeArchitecture= 10508 Default is none. 10510 Examples: 10511 X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a 10512 X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 10513 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 10515 This document does not define the structure or content of the list 10516 of values. 10518 The initiator or target declares the details of its iSCSI node 10519 architecture to the remote endpoint. These details may include, but 10520 are not limited to, iSCSI vendor software, firmware, or hardware 10521 versions, the OS version, or hardware architecture. This key may 10522 be declared on a Discovery session or a Normal session. 10524 The length of the key value (total length of the list-of-values) 10525 MUST NOT be greater than 255 bytes. 10527 X#NodeArchitecture MUST NOT be redeclared during the login phase. 10529 13.24.2. Implementation Requirements 10531 Functional behavior of the iSCSI node (this includes the iSCSI 10532 protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT 10533 depend on the presence, absence, or content of the 10534 X#NodeArchitecture key. The key MUST NOT be used by iSCSI nodes for 10535 interoperability, or exclusion of other nodes. To ensure proper 10536 use, key values SHOULD be set by the node itself, and there SHOULD 10537 NOT be provisions for the key values to contain user-defined text. 10539 Nodes implementing this key MUST choose one of the following 10540 implementation options: 10542 only transmit the key, 10543 only log the key values received from other nodes, or 10544 both transmit and log the key values. 10545 Each node choosing to implement transmission of the key values MUST 10546 be prepared to handle the response of iSCSI Nodes that do not 10547 understand the key. 10549 Nodes that implement transmission and/or logging of the key values 10550 may also implement administrative mechanisms that disable and/or 10551 change the logging and key transmission detail (see Section 8.4 - 10552 "Security Considerations for the X#NodeArchitecture Key"). Thus, a 10553 valid behavior for this key may be that a node is completely silent 10554 (the node does not transmit any key value, and simply discards any 10555 key values it receives without issuing a NotUnderstood response). 10557 14. IANA Considerations 10559 The well-known TCP port number for iSCSI connections assigned by 10560 IANA is 3260 and this is the default iSCSI port. Implementations 10561 needing a system TCP port number may use port 860, the port 10562 assigned by IANA as the iSCSI system port; however in order to use 10563 port 860, it MUST be explicitly specified - implementations MUST 10564 NOT default to use of port 860, as 3260 is the only allowed 10565 default. 10567 [RFC3720] instructs that three text key registries be set up, one 10568 for each of Extension keys, authentication methods, or digest keys 10569 - with the stipulation that the key prefix (X#, Y# or Z#) be not 10570 recorded. However, [RFC4850] indicates that the key prefix was 10571 recorded by IANA as part of the key name. Consequently, storm 10572 working group (which published this document) instructs IANA that: 10573 (i) It maintain a single text key registry for iSCSI keys, and, 10574 (ii) MUST always record the key prefix as part of the recorded 10575 string 10577 This is being done with the intent to not have to change what IANA 10578 already did while publishing [RFC4850]. 10580 All the other IANA considerations stated in [RFC3720] and [RFC5048] 10581 remain unchanged. 10583 This document obsoletes the SPKM1 and SPKM2 key values for the 10584 AuthMethod text key. Consequently, the SPKM_ text key prefix MUST 10585 be treated as obsolete and be not reused. 10587 References 10589 Normative References 10591 [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", 10592 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 10594 [FC-FS] INCITS 373-2003, Fibre Channel Framing and Signaling 10595 Interface (FC-FS). 10597 [OUI] "IEEE OUI and Company_Id Assignments", 10598 http://standards.ieee.org/regauth/oui 10600 [RFC791] INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL 10601 SPECIFICATION, September 1981. 10603 [RFC793] TRANSMISSION CONTROL PROTOCOL, DARPA INTERNET PROGRAM 10604 PROTOCOL SPECIFICATION, September 1981. 10606 [RFC1035] P. Mockapetris, DOMAIN NAMES - IMPLEMENTATION AND 10607 SPECIFICATION, November 1987. 10609 [RFC1122] Requirements for Internet Hosts-Communication Layer 10610 RFC1122, R. Braden (editor). 10612 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 10613 June 1996. 10615 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", August 10616 1996. 10618 [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication 10619 Protocol (CHAP)", August 1996. 10621 [RFC2025] C. Adams, "The Simple Public-Key GSS-API Mechanism 10622 (SPKM)", October 1996. 10624 [RFC2045] N. Borenstein, N. Freed, "MIME (Multipurpose Internet 10625 Mail Extensions) Part One: Mechanisms for Specifying and 10626 Describing the Format of Internet Message Bodies", November 10627 1996. 10629 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 10630 Requirement Levels", BCP 14, March 1997. 10632 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 10633 Architecture", July 1998. 10635 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 within 10636 ESP and AH", November 1998. 10638 [RFC2451] R. Pereira, R. Adams " The ESP CBC-Mode Cipher 10639 Algorithms". 10641 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange 10642 System", September 2000. 10644 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 10645 Internationalized Strings ("stringprep")", RFC 3454, December 10646 2002. 10648 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 10649 Algorithm and Its Use With IPsec", RFC 3566, September 2003. 10651 [RFC3629] Yergeau, F., "UTF-8, a Transformation Format of ISO 10652 10646", RFC 3629, November 2003 10654 [RFC3686] Housley, R., "Using Advanced Encryption Standard 10655 (AES) Counter Mode with IPsec Encapsulating Security Payload 10656 (ESP)", RFC 3686, January 2004. 10658 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 10659 M., and E. Zeidner, "Internet Small Computer Systems 10660 Interface (iSCSI)", RFC 3720, April 2004. 10662 [RFC3722] Bakke, M., "String Profile for Internet Small 10663 Computer Systems Interface (iSCSI) Names", RFC 3722, March 10664 2004. 10666 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. 10667 Travostino, "Securing Block Storage Protocols over IP", RFC 10668 3723, March 2004. 10670 [RFC3783] M. Chadalapaka, R. Elliott, "Small Computer Systems 10671 Interface (SCSI) Command Ordering Considerations with iSCSI", 10672 RFC 3783, May 2004. 10674 [RFC3980] Krueger, M., Chadalapaka, M., Elliott, R., "T11 10675 Network Address Authority (NAA) Naming Format for iSCSI Node 10676 Names", RFC 3980, February 2005. 10678 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter "Uniform 10679 Resource Identifier (URI): Generic Syntax", January 2005. 10681 [RFC4120] Neuman, C., Yu, T., Hartman, S., Raeburn, K, "The 10682 Kerberos Network Authentication Service (V5)", RFC 4120, July 10683 2005. 10685 [RFC4171] J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. 10686 Souza, "Internet Storage Name Service (iSNS)", September 10687 2005. 10689 [RFC4301] S. Kent, K.Seo, "Security Architecture for the 10690 Internet Protocol", December 2005. 10692 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 10693 RFC 4303, December 2005 10695 [RFC4306] C. Kaufman (Ed), "Internet Key Exchange (IKEv2) 10696 Protocol", December 2005. 10698 [RFC4646] A. Phillips, M. Davis, "Tags for the Identification 10699 of Languages", RFC 4646, September 2006. 10701 [RFC4850] Wysochanski, D., "Declarative Public Extension Key 10702 for Internet Small Computer Systems Interface (iSCSI) Node 10703 Architecture", RFC 4850, April 2007. 10705 [RFC5048] Chadalapaka, M., "Internet Small Computer Systems 10706 Interface (iSCSI) Corrections and Clarifications", RFC 5048, 10707 October 2007. 10709 [RFC5226] T. Narten, and H. Avestrand, "Guidelines for Writing 10710 an IANA Considerations Section in RFCs.", May 2008. 10712 [SAM2] T10/1157-D, SCSI Architecture Model - 2 (SAM-2). 10714 [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). 10716 [SAM4] T10/1683-D, SCSI Architecture Model - 4 (SAM-4). 10718 [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC). 10720 [SPC3] T10/1416-D, SCSI Primary Commands-3. 10722 [UML] ISO/IEC 19501, Unified Modeling Language Specification 10723 Version 1.4.2. 10725 [UNICODE] Unicode Standard Annex #15, "Unicode Normalization 10726 Forms", http://www.unicode.org/unicode/reports/tr15 10728 Informative References: 10730 [RFC1737] K. Sollins, L. Masinter "Functional Requirements for 10731 Uniform Resource Names". 10733 [IB] InfiniBand{tm} Architecture Specification, Vol. 1, 10734 Rel.1.0.a, InfiniBand 10735 TradezAssociation(http://www.infinibandta.org). 10737 [RFC4173] P. Sarkar, D. Missimer, C. Sapuntzakis, 10738 "Bootstrapping Clients using the Internet Small Computer 10739 System Interface (iSCSI) Protocol", RFC 4173, September 2005. 10741 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman 10742 "Optimization of Cyclic Redundancy-Check Codes with 24 and 32 10743 Parity Bits", IEEE Transact. on Communications, Vol. 41, No. 10744 6, June 1993. 10746 [CRC] ISO 3309, High-Level Data Link Control (CRC 32). 10748 [RFC3347] Krueger, M., Haagens, R., Sapuntzakis, C. and M. 10749 Bakke, "Small Computer Systems Interface protocol over the 10750 Internet (iSCSI) Requirements and Design Considerations", RFC 10751 3347, July 2002. 10753 [RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. Cavanna, 10754 "Internet Protocol Small Computer System Interface (iSCSI) 10755 Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 10756 3385, September 2002. 10758 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. and 10759 M. Krueger, "Internet Small Computer Systems Interface 10760 (iSCSI) Naming and Discovery", RFC 3721, March 2004 10762 [RFC4297] Romanow, A., Mogul, J., Talpey, T., and S. Bailey, 10763 "Remote Direct Memory Access (RDMA) over IP Problem 10764 Statement", RFC 4297, October 2004 10766 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., 10767 Shah, H., and P. Thaler, "Internet Small Computer System 10768 Interface (iSCSI) Extensions for Remote Direct Memory Access 10769 (RDMA)", RFC 5046, October 2007 10771 [Schneier] B. Schneier, "Applied Cryptography: Protocols, 10772 Algorithms, and Source Code in C", 2nd edition, John Wiley & 10773 Sons, New York, NY, 1996. 10775 [SAS] INCITS 376-2003, Serial Attached SCSI (SAS). 10777 [SRP] INCITS 365-2002, SCSI RDMA Protocol (SRP). 10779 Appendix A. Examples 10781 Read Operation Example 10783 +------------------+-----------------------+----------------------+ 10784 |Initiator Function| PDU Type | Target Function | 10785 +------------------+-----------------------+----------------------+ 10786 | Command request |SCSI Command (READ)>>> | | 10787 | (read) | | | 10788 +------------------+-----------------------+----------------------+ 10789 | | |Prepare Data Transfer | 10790 +------------------+-----------------------+----------------------+ 10791 | Receive Data | <<< SCSI Data-in | Send Data | 10792 +------------------+-----------------------+----------------------+ 10793 | Receive Data | <<< SCSI Data-in | Send Data | 10794 +------------------+-----------------------+----------------------+ 10795 | Receive Data | <<< SCSI Data-in | Send Data | 10796 +------------------+-----------------------+----------------------+ 10797 | | <<< SCSI Response |Send Status and Sense | 10798 +------------------+-----------------------+----------------------+ 10799 | Command Complete | | | 10800 +------------------+-----------------------+----------------------+ 10802 Write Operation Example 10804 +------------------+-----------------------+---------------------+ 10805 |Initiator Function| PDU Type | Target Function | 10806 +------------------+-----------------------+---------------------+ 10807 | Command request |SCSI Command (WRITE)>>>| Receive command | 10808 | (write) | | and queue it | 10809 +------------------+-----------------------+---------------------+ 10810 | | | Process old commands| 10811 +------------------+-----------------------+---------------------+ 10812 | | | Ready to process | 10813 | | <<< R2T | WRITE command | 10814 +------------------+-----------------------+---------------------+ 10815 | Send Data | SCSI Data-out >>> | Receive Data | 10816 +------------------+-----------------------+---------------------+ 10817 | | <<< R2T | Ready for data | 10818 +------------------+-----------------------+---------------------+ 10819 | | <<< R2T | Ready for data | 10820 +------------------+-----------------------+---------------------+ 10821 | Send Data | SCSI Data-out >>> | Receive Data | 10822 +------------------+-----------------------+---------------------+ 10823 | Send Data | SCSI Data-out >>> | Receive Data | 10824 +------------------+-----------------------+---------------------+ 10825 | | <<< SCSI Response |Send Status and Sense| 10826 +------------------+-----------------------+---------------------+ 10827 | Command Complete | | | 10828 +------------------+-----------------------+---------------------+ 10830 R2TSN/DataSN Use Examples 10832 Output (write) data DataSN/R2TSN Example 10833 +------------------+-----------------------+----------------------+ 10834 |Initiator Function| PDU Type & Content | Target Function | 10835 +------------------+-----------------------+----------------------+ 10836 | Command request |SCSI Command (WRITE)>>>| Receive command | 10837 | (write) | | and queue it | 10838 +------------------+-----------------------+----------------------+ 10839 | | | Process old commands | 10840 +------------------+-----------------------+----------------------+ 10841 | | <<< R2T | Ready for data | 10842 | | R2TSN = 0 | | 10843 +------------------+-----------------------+----------------------+ 10844 | | <<< R2T | Ready for more data | 10845 | | R2TSN = 1 | | 10846 +------------------+-----------------------+----------------------+ 10847 | Send Data | SCSI Data-out >>> | Receive Data | 10848 | for R2TSN 0 | DataSN = 0, F=0 | | 10849 +------------------+-----------------------+----------------------+ 10850 | Send Data | SCSI Data-out >>> | Receive Data | 10851 | for R2TSN 0 | DataSN = 1, F=1 | | 10852 +------------------+-----------------------+----------------------+ 10853 | Send Data | SCSI Data >>> | Receive Data | 10854 | for R2TSN 1 | DataSN = 0, F=1 | | 10855 +------------------+-----------------------+----------------------+ 10856 | | <<< SCSI Response |Send Status and Sense | 10857 | | ExpDataSN = 0 | | 10858 +------------------+-----------------------+----------------------+ 10859 | Command Complete | | | 10860 +------------------+-----------------------+----------------------+ 10862 Input (read) data DataSN Example 10864 +------------------+-----------------------+----------------------+ 10865 |Initiator Function| PDU Type | Target Function | 10866 +------------------+-----------------------+----------------------+ 10867 | Command request |SCSI Command (READ)>>> | | 10868 | (read) | | | 10869 +------------------+-----------------------+----------------------+ 10870 | | | Prepare Data Transfer| 10871 +------------------+-----------------------+----------------------+ 10872 | Receive Data | <<< SCSI Data-in | Send Data | 10873 | | DataSN = 0, F=0 | | 10874 +------------------+-----------------------+----------------------+ 10875 | Receive Data | <<< SCSI Data-in | Send Data | 10876 | | DataSN = 1, F=0 | | 10877 +------------------+-----------------------+----------------------+ 10878 | Receive Data | <<< SCSI Data-in | Send Data | 10879 | | DataSN = 2, F=1 | | 10880 +------------------+-----------------------+----------------------+ 10881 | | <<< SCSI Response |Send Status and Sense | 10882 | | ExpDataSN = 3 | | 10883 +------------------+-----------------------+----------------------+ 10884 | Command Complete | | | 10885 +------------------+-----------------------+----------------------+ 10887 Bidirectional DataSN Example 10889 +------------------+-----------------------+----------------------+ 10890 |Initiator Function| PDU Type | Target Function | 10891 +------------------+-----------------------+----------------------+ 10892 | Command request |SCSI Command >>> | | 10893 | (Read-Write) | Read-Write | | 10894 +------------------+-----------------------+----------------------+ 10895 | | | Process old commands | 10896 +------------------+-----------------------+----------------------+ 10897 | | <<< R2T | Ready to process | 10898 | | R2TSN = 0 | WRITE command | 10899 +------------------+-----------------------+----------------------+ 10900 | * Receive Data | <<< SCSI Data-in | Send Data | 10901 | | DataSN = 0, F=0 | | 10902 +------------------+-----------------------+----------------------+ 10903 | * Receive Data | <<< SCSI Data-in | Send Data | 10904 | | DataSN = 1, F=1 | | 10905 +------------------+-----------------------+----------------------+ 10906 | * Send Data | SCSI Data-out >>> | Receive Data | 10907 | for R2TSN 0 | DataSN = 0, F=1 | | 10908 +------------------+-----------------------+----------------------+ 10909 | | <<< SCSI Response |Send Status and Sense | 10910 | | ExpDataSN = 2 | | 10911 +------------------+-----------------------+----------------------+ 10912 | Command Complete | | | 10913 +------------------+-----------------------+----------------------+ 10915 *) Send data and Receive Data may be transferred simultaneously as 10916 in an atomic Read-Old-Write-New or sequentially as in an atomic 10917 Read-Update-Write (in the latter case the R2T may follow the 10918 received data). 10920 Unsolicited and immediate output (write) data with DataSN Example 10921 +------------------+-----------------------+----------------------+ 10922 |Initiator Function| PDU Type & Content | Target Function | 10923 +------------------+-----------------------+----------------------+ 10924 | Command request |SCSI Command (WRITE)>>>| Receive command | 10925 | (write) |F=0 | and data | 10926 |+ immediate data | | and queue it | 10927 +------------------+-----------------------+----------------------+ 10928 | Send Unsolicited | SCSI Write Data >>> | Receive more Data | 10929 | Data | DataSN = 0, F=1 | | 10930 +------------------+-----------------------+----------------------+ 10931 | | | Process old commands | 10932 +------------------+-----------------------+----------------------+ 10933 | | <<< R2T | Ready for more data | 10934 | | R2TSN = 0 | | 10935 +------------------+-----------------------+----------------------+ 10936 | Send Data | SCSI Write Data >>> | Receive Data | 10937 | for R2TSN 0 | DataSN = 0, F=1 | | 10938 +------------------+-----------------------+----------------------+ 10939 | | <<< SCSI Response |Send Status and Sense | 10940 | | | | 10941 +------------------+-----------------------+----------------------+ 10942 | Command Complete | | | 10943 +------------------+-----------------------+----------------------+ 10945 CRC Examples 10947 N.B. all Values are Hexadecimal 10949 32 bytes of zeroes: 10951 Byte: 0 1 2 3 10953 0: 00 00 00 00 10954 ... 10955 28: 00 00 00 00 10957 CRC: aa 36 91 8a 10959 32 bytes of ones: 10961 Byte: 0 1 2 3 10962 0: ff ff ff ff 10963 ... 10964 28: ff ff ff ff 10966 CRC: 43 ab a8 62 10968 32 bytes of incrementing 00..1f: 10970 Byte: 0 1 2 3 10972 0: 00 01 02 03 10973 ... 10974 28: 1c 1d 1e 1f 10976 CRC: 4e 79 dd 46 10978 32 bytes of decrementing 1f..00: 10980 Byte: 0 1 2 3 10982 0: 1f 1e 1d 1c 10983 ... 10984 28: 03 02 01 00 10986 CRC: 5c db 3f 11 10988 An iSCSI - SCSI Read (10) Command PDU 10990 Byte: 0 1 2 3 10992 0: 01 c0 00 00 10993 4: 00 00 00 00 10994 8: 00 00 00 00 10995 12: 00 00 00 00 10996 16: 14 00 00 00 10997 20: 00 00 04 00 10998 24: 00 00 00 14 10999 28: 00 00 00 18 11000 32: 28 00 00 00 11001 36: 00 00 00 00 11002 40: 02 00 00 00 11003 44: 00 00 00 00 11005 CRC: 56 3a 96 d9 11007 Appendix B. Login Phase Examples 11009 In the first example, the initiator and target authenticate each 11010 other via Kerberos: 11012 I-> Login (CSG,NSG=0,1 T=1) 11013 InitiatorName=iqn.1999-07.com.os:hostid.77 11014 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11015 AuthMethod=KRB5,SRP,None 11017 T-> Login (CSG,NSG=0,0 T=0) 11018 AuthMethod=KRB5 11020 I-> Login (CSG,NSG=0,1 T=1) 11021 KRB_AP_REQ= 11023 (krb_ap_req contains the Kerberos V5 ticket and authenticator with 11024 MUTUAL-REQUIRED set in the ap-options field) 11026 If the authentication is successful, the target proceeds with: 11028 T-> Login (CSG,NSG=0,1 T=1) 11029 KRB_AP_REP= 11031 (krb_ap_rep is the Kerberos V5 mutual authentication reply) 11033 If the authentication is successful, the initiator may proceed 11034 with: 11036 I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192 11037 T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096 11038 MaxBurstLength=8192 11039 I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192 11040 ... more iSCSI Operational Parameters 11042 T-> Login (CSG,NSG=1,0 T=0) 11043 ... more iSCSI Operational Parameters 11045 And at the end: 11047 I-> Login (CSG,NSG=1,3 T=1) 11048 optional iSCSI parameters 11050 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11052 If the initiator's authentication by the target is not successful, 11053 the target responds with: 11055 T-> Login "login reject" 11057 instead of the Login KRB_AP_REP message, and terminates the 11058 connection. 11060 If the target's authentication by the initiator is not successful, 11061 the initiator terminates the connection (without responding to the 11062 Login KRB_AP_REP message). 11064 In the next example only the initiator is authenticated by the 11065 target via Kerberos: 11067 I-> Login (CSG,NSG=0,1 T=1) 11068 InitiatorName=iqn.1999-07.com.os:hostid.77 11069 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11070 AuthMethod=SRP,KRB5,None 11072 T-> Login-PR (CSG,NSG=0,0 T=0) 11073 AuthMethod=KRB5 11075 I-> Login (CSG,NSG=0,1 T=1) 11076 KRB_AP_REQ=krb_ap_req 11078 (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req) 11080 If the authentication is successful, the target proceeds with: 11082 T-> Login (CSG,NSG=0,1 T=1) 11084 I-> Login (CSG,NSG=1,0 T=0) 11085 ... iSCSI parameters 11087 T-> Login (CSG,NSG=1,0 T=0) 11088 ... iSCSI parameters 11090 . . . 11092 T-> Login (CSG,NSG=1,3 T=1)"login accept" 11094 In the next example, the initiator and target authenticate each 11095 other via SRP: 11097 I-> Login (CSG,NSG=0,1 T=1) 11098 InitiatorName=iqn.1999-07.com.os:hostid.77 11099 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11100 AuthMethod=KRB5,SRP,None 11102 T-> Login-PR (CSG,NSG=0,0 T=0) 11103 AuthMethod=SRP 11105 I-> Login (CSG,NSG=0,0 T=0) 11106 SRP_U= 11107 TargetAuth=Yes 11109 T-> Login (CSG,NSG=0,0 T=0) 11110 SRP_N= 11111 SRP_g= 11112 SRP_s= 11114 I-> Login (CSG,NSG=0,0 T=0) 11115 SRP_A= 11117 T-> Login (CSG,NSG=0,0 T=0) 11118 SRP_B= 11120 I-> Login (CSG,NSG=0,1 T=1) 11121 SRP_M= 11123 If the initiator authentication is successful, the target proceeds: 11125 T-> Login (CSG,NSG=0,1 T=1) 11126 SRP_HM= 11128 Where N, g, s, A, B, M, and H(A | M | K) are defined in 11129 [RFC2945]. 11131 If the target authentication is not successful, the initiator 11132 terminates the connection; otherwise, it proceeds. 11134 I-> Login (CSG,NSG=1,0 T=0) 11135 ... iSCSI parameters 11137 T-> Login (CSG,NSG=1,0 T=0) 11138 ... iSCSI parameters 11140 And at the end: 11142 I-> Login (CSG,NSG=1,3 T=1) 11143 optional iSCSI parameters 11145 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11147 If the initiator authentication is not successful, the target 11148 responds with: 11150 T-> Login "login reject" 11152 Instead of the T-> Login SRP_HM= message and 11153 terminates the connection. 11155 In the next example, only the initiator is authenticated by the 11156 target via SRP: 11158 I-> Login (CSG,NSG=0,1 T=1) 11159 InitiatorName=iqn.1999-07.com.os:hostid.77 11160 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11161 AuthMethod=KRB5,SRP,None 11163 T-> Login-PR (CSG,NSG=0,0 T=0) 11164 AuthMethod=SRP 11166 I-> Login (CSG,NSG=0,0 T=0) 11167 SRP_U= 11168 TargetAuth=No 11170 T-> Login (CSG,NSG=0,0 T=0) 11171 SRP_N= 11172 SRP_g= 11173 SRP_s= 11175 I-> Login (CSG,NSG=0,0 T=0) 11176 SRP_A= 11178 T-> Login (CSG,NSG=0,0 T=0) 11179 SRP_B= 11181 I-> Login (CSG,NSG=0,1 T=1) 11182 SRP_M= 11184 If the initiator authentication is successful, the target 11185 proceeds: 11187 T-> Login (CSG,NSG=0,1 T=1) 11189 I-> Login (CSG,NSG=1,0 T=0) 11191 ... iSCSI parameters 11193 T-> Login (CSG,NSG=1,0 T=0) 11195 ... iSCSI parameters 11197 And at the end: 11199 I-> Login (CSG,NSG=1,3 T=1) 11201 optional iSCSI parameters 11203 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11205 In the next example the initiator and target authenticate each 11206 other via CHAP: 11208 I-> Login (CSG,NSG=0,0 T=0) 11210 InitiatorName=iqn.1999-07.com.os:hostid.77 11212 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11214 AuthMethod=KRB5,CHAP,None 11216 T-> Login-PR (CSG,NSG=0,0 T=0) 11218 AuthMethod=CHAP 11220 I-> Login (CSG,NSG=0,0 T=0) 11222 CHAP_A= 11224 T-> Login (CSG,NSG=0,0 T=0) 11225 CHAP_A= 11226 CHAP_I= 11227 CHAP_C= 11229 I-> Login (CSG,NSG=0,1 T=1) 11231 CHAP_N= 11233 CHAP_R= 11235 CHAP_I= 11237 CHAP_C= 11239 If the initiator authentication is successful, the target 11240 proceeds: 11242 T-> Login (CSG,NSG=0,1 T=1) 11244 CHAP_N= 11246 CHAP_R= 11248 If the target authentication is not successful, the initiator 11249 aborts the connection; otherwise, it proceeds. 11251 I-> Login (CSG,NSG=1,0 T=0) 11253 ... iSCSI parameters 11255 T-> Login (CSG,NSG=1,0 T=0) 11257 ... iSCSI parameters 11259 And at the end: 11261 I-> Login (CSG,NSG=1,3 T=1) 11263 optional iSCSI parameters 11265 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11267 If the initiator authentication is not successful, the target 11268 responds with: 11270 T-> Login "login reject" 11272 Instead of the Login CHAP_R= "proceed and change 11273 stage" message and terminates the connection. 11275 In the next example, only the initiator is authenticated by the 11276 target via CHAP: 11278 I-> Login (CSG,NSG=0,1 T=0) 11280 InitiatorName=iqn.1999-07.com.os:hostid.77 11282 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11284 AuthMethod=KRB5,CHAP,None 11286 T-> Login-PR (CSG,NSG=0,0 T=0) 11288 AuthMethod=CHAP 11290 I-> Login (CSG,NSG=0,0 T=0) 11291 CHAP_A= 11293 T-> Login (CSG,NSG=0,0 T=0) 11294 CHAP_A= 11295 CHAP_I= 11296 CHAP_C= 11298 I-> Login (CSG,NSG=0,1 T=1) 11300 CHAP_N= 11302 CHAP_R= 11304 If the initiator authentication is successful, the target 11305 proceeds: 11307 T-> Login (CSG,NSG=0,1 T=1) 11309 I-> Login (CSG,NSG=1,0 T=0) 11311 ... iSCSI parameters 11313 T-> Login (CSG,NSG=1,0 T=0) 11315 ... iSCSI parameters 11317 And at the end: 11319 I-> Login (CSG,NSG=1,3 T=1) 11320 optional iSCSI parameters 11322 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11324 In the next example, the initiator does not offer any security 11325 parameters. It therefore may offer iSCSI parameters on the Login 11326 PDU with the T bit set to 1, and the target may respond with a 11327 final Login Response PDU immediately: 11329 I-> Login (CSG,NSG=1,3 T=1) 11331 InitiatorName=iqn.1999-07.com.os:hostid.77 11333 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11335 ... iSCSI parameters 11337 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11339 ... ISCSI parameters 11341 In the next example, the initiator does offer security 11342 parameters on the Login PDU, but the target does not choose 11343 any (i.e., chooses the "None" values): 11345 I-> Login (CSG,NSG=0,1 T=1) 11347 InitiatorName=iqn.1999-07.com.os:hostid.77 11349 TargetName=iqn.1999-07.com.example:diskarray.sn.88 11351 AuthMethod=KRB5,SRP,None 11353 T-> Login-PR (CSG,NSG=0,1 T=1) 11355 AuthMethod=None 11357 I-> Login (CSG,NSG=1,0 T=0) 11359 ... iSCSI parameters 11361 T-> Login (CSG,NSG=1,0 T=0) 11363 ... iSCSI parameters 11365 And at the end: 11367 I-> Login (CSG,NSG=1,3 T=1) 11369 optional iSCSI parameters 11371 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11373 Appendix C. SendTargets Operation 11375 To reduce the amount of configuration required on an initiator, 11376 iSCSI provides the SendTargets text request. The initiator uses 11377 the SendTargets request to get a list of targets to which it may 11378 have access, as well as the list of addresses (IP address and TCP 11379 port) on which these targets may be accessed. 11381 To make use of SendTargets, an initiator must first establish one 11382 of two types of sessions. If the initiator establishes the 11383 session using the key "SessionType=Discovery", the session is a 11384 discovery session, and a target name does not need to be specified. 11385 Otherwise, the session is a normal, operational session. The 11386 SendTargets command MUST only be sent during the Full Feature Phase 11387 of a normal or discovery session. 11389 A system that contains targets MUST support discovery sessions on 11390 each of its iSCSI IP address-port pairs, and MUST support the 11391 SendTargets command on the discovery session. In a discovery 11392 session, a target MUST return all path information (IP address-port 11393 pairs and portal group tags) for the targets on the target network 11394 entity which the requesting initiator is authorized to access. 11396 A target MUST support the SendTargets command on operational 11397 sessions; these will only return path information about the target 11398 to which the session is connected, and do not need to return 11399 information about other target names that may be defined in the 11400 responding system. 11402 An initiator MAY make use of the SendTargets as it sees fit. 11404 A SendTargets command consists of a single Text request PDU. 11405 This PDU contains exactly one text key and value. The text key 11406 MUST be SendTargets. The expected response depends upon the value, 11407 as well as whether the session is a discovery or operational 11408 session. 11410 The value must be one of: 11412 All 11414 The initiator is requesting that information on all relevant 11415 targets known to the implementation be returned. This value 11416 MUST be supported on a discovery session, and MUST NOT be 11417 supported on an operational session. 11419 11421 If an iSCSI target name is specified, the session should 11422 respond with addresses for only the named target, if 11424 possible. This value MUST be supported on discovery 11425 sessions. A discovery session MUST be capable of returning 11426 addresses for those targets that would have been returned had 11427 value=All been designated. 11429 11431 The session should only respond with addresses for the target 11432 to which the session is logged in. This MUST be supported on 11433 operational sessions, and MUST NOT return targets other than 11434 the one to which the session is logged in. 11436 The response to this command is a text response that contains a 11437 list of zero or more targets and, optionally, their addresses. 11438 Each target is returned as a target record. A target record begins 11439 with the TargetName text key, followed by a list of TargetAddress 11440 text keys, and bounded by the end of the text response or the next 11441 TargetName key, which begins a new record. No text keys other than 11442 TargetName and TargetAddress are permitted within a SendTargets 11443 response. 11445 For the format of the TargetName, see Section 12.4 - "TargetName". 11447 A discovery session MAY respond to a SendTargets request with its 11448 complete list of targets, or with a list of targets that is based 11449 on the name of the initiator logged in to the session. 11451 A SendTargets response MUST NOT contain target names if there are 11452 no targets for the requesting initiator to access. 11454 Each target record returned includes zero or more TargetAddress 11455 fields. 11457 Each target record starts with one text key of the form: 11459 TargetName= 11461 Followed by zero or more address keys of the form: 11463 TargetAddress=[:], 11466 The hostname-or-ipaddress contains a domain name, IPv4 address, or 11467 IPv6 address, as specified for the TargetAddress key. 11469 A hostname-or-ipaddress duplicated in TargetAddress responses for a 11470 given node (the port is absent or equal) would probably indicate 11471 that multiple address families are in use at once (IPv6 and IPv4). 11473 Each TargetAddress belongs to a portal group, identified by its 11474 numeric portal group tag (as in Section 12.9 - 11475 "TargetPortalGroupTag"). The iSCSI target name, together with this 11476 tag, constitutes the SCSI port identifier; the tag only needs to be 11477 unique within a given target's name list of addresses. 11479 Multiple-connection sessions can span iSCSI addresses that belong 11480 to the same portal group. 11482 Multiple-connection sessions cannot span iSCSI addresses that 11483 belong to different portal groups. 11485 If a SendTargets response reports an iSCSI address for a target, it 11486 SHOULD also report all other addresses in its portal group in the 11487 same response. 11489 A SendTargets text response can be longer than a single Text 11490 Response PDU, and makes use of the long text responses as 11491 specified. 11493 After obtaining a list of targets from the discovery target 11494 session, 11495 an iSCSI initiator may initiate new sessions to log in to the 11496 discovered targets for full operation. The initiator MAY keep the 11497 discovery session open, and MAY send subsequent SendTargets 11498 commands to discover new targets. 11500 Examples: 11502 This example is the SendTargets response from a single target that 11503 has no other interface ports. 11505 Initiator sends text request that contains: 11507 SendTargets=All 11509 Target sends a text response that contains: 11511 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11513 All the target had to return in the simple case was the target 11514 name. It is assumed by the initiator that the IP address and TCP 11515 port for this target are the same as used on the current connection 11516 to the default iSCSI target. 11518 The next example has two internal iSCSI targets, each accessible 11519 via two different ports with different IP addresses. The following 11520 is the text response: 11522 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11524 TargetAddress=10.1.0.45:3000,1 11526 TargetAddress=10.1.1.45:3000,2 11528 TargetName=iqn.1993-11.com.example:diskarray.sn.1234567 11530 TargetAddress=10.1.0.45:3000,1 11532 TargetAddress=10.1.1.45:3000,2 11534 Both targets share both addresses; the multiple addresses are 11535 likely used to provide multi-path support. The initiator may 11536 connect to either target name on either address. Each of the 11537 addresses has its own portal group tag; they do not support 11538 spanning multiple-connection sessions with each other. Keep in mind 11539 that the portal group tags for the two named targets are 11540 independent of one another; portal group "1" on the first target is 11541 not necessarily the same as portal group "1" on the second target. 11543 In the above example, a DNS host name or an IPv6 address could have 11544 been returned instead of an IPv4 address. 11546 The next text response shows a target that supports spanning 11547 sessions across multiple addresses, and further illustrates the use 11548 of the portal group tags: 11550 TargetName=iqn.1993-11.com.example:diskarray.sn.8675309 11552 TargetAddress=10.1.0.45:3000,1 11554 TargetAddress=10.1.1.46:3000,1 11556 TargetAddress=10.1.0.47:3000,2 11558 TargetAddress=10.1.1.48:3000,2 11560 TargetAddress=10.1.1.49:3000,3 11562 In this example, any of the target addresses can be used to reach 11563 the same target. A single-connection session can be established to 11564 any of these TCP addresses. A multiple-connection session could 11565 span addresses .45 and .46 or .47 and .48, but cannot span any 11566 other combination. A TargetAddress with its own tag (.49) cannot 11567 be combined with any other address within the same session. 11569 This SendTargets response does not indicate whether .49 supports 11570 multiple connections per session; it is communicated via the 11571 MaxConnections text key upon login to the target. 11573 Appendix D. Algorithmic Presentation of Error Recovery Classes 11575 This appendix illustrates the error recovery classes using a 11576 pseudo-programming-language. The procedure names are chosen to be 11577 obvious to most implementers. Each of the recovery classes 11578 described has initiator procedures as well as target procedures. 11579 These algorithms focus on outlining the mechanics of error recovery 11580 classes, and do not exhaustively describe all other aspects/cases. 11581 Examples of this approach are: 11583 - Handling for only certain Opcode types is shown. 11585 - Only certain reason codes (e.g., Recovery in Logout command) 11586 are outlined. 11588 - Resultant cases, such as recovery of Synchronization on a 11589 header digest error are considered out-of-scope in these 11590 algorithms. In this particular example, a header digest 11591 error may lead to connection recovery if some type of sync 11592 and steering layer is not implemented. 11594 These algorithms strive to convey the iSCSI error recovery concepts 11595 in the simplest terms, and are not designed to be optimal. 11597 D.1. General Data Structure and 11598 Procedure Description 11600 This section defines the procedures and data structures that are 11601 commonly used by all the error recovery algorithms. The structures 11602 may not be the exhaustive representations of what is required for a 11603 typical implementation. 11605 Data structure definitions - 11606 struct TransferContext { 11607 int TargetTransferTag; 11608 int ExpectedDataSN; 11609 }; 11611 struct TCB { /* task control block */ 11612 Boolean SoFarInOrder; 11613 int ExpectedDataSN; /* used for both R2Ts, and Data */ 11614 int MissingDataSNList[MaxMissingDPDU]; 11615 Boolean FbitReceived; 11616 Boolean StatusXferd; 11617 Boolean CurrentlyAllegiant; 11618 int ActiveR2Ts; 11619 int Response; 11620 char *Reason; 11621 struct TransferContext 11622 TransferContextList[MaxOutStandingR2T]; 11623 int InitiatorTaskTag; 11624 int CmdSN; 11625 int SNACK_Tag; 11626 }; 11628 struct Connection { 11629 struct Session SessionReference; 11630 Boolean SoFarInOrder; 11631 int CID; 11632 int State; 11633 int CurrentTimeout; 11634 int ExpectedStatSN; 11635 int MissingStatSNList[MaxMissingSPDU]; 11636 Boolean PerformConnectionCleanup; 11637 }; 11639 struct Session { 11640 int NumConnections; 11641 int CmdSN; 11642 int Maxconnections; 11643 int ErrorRecoveryLevel; 11644 struct iSCSIEndpoint OtherEndInfo; 11645 struct Connection ConnectionList[MaxSupportedConns]; 11646 }; 11648 Procedure descriptions - 11649 Receive-a-In-PDU(transport connection, inbound PDU); 11650 check-basic-validity(inbound PDU); 11651 Start-Timer(timeout handler, argument, timeout value); 11652 Build-And-Send-Reject(transport connection, bad PDU, reason 11653 code); 11654 D.2. Within-command Error Recovery 11655 Algorithms 11657 D.2.1. Procedure Descriptions 11659 Recover-Data-if-Possible(last required DataSN, task control 11660 block); 11661 Build-And-Send-DSnack(task control block); 11662 Build-And-Send-RDSnack(task control block); 11663 Build-And-Send-Abort(task control block); 11664 SCSI-Task-Completion(task control block); 11665 Build-And-Send-A-Data-Burst(transport connection, data- 11666 descriptor, 11667 task control 11668 block); 11669 Build-And-Send-R2T(transport connection, data-descriptor, 11670 task control block); 11671 Build-And-Send-Status(transport connection, task control block); 11672 Transfer-Context-Timeout-Handler(transfer context); 11674 Notes: 11676 - One procedure used in this section: Handle-Status-SNACK- 11677 request is defined in Within-connection recovery algorithms. 11679 - The Response processing pseudo-code, shown in the target 11680 algorithms, applies to all solicited PDUs that carry StatSN - 11681 SCSI Response, Text Response etc. 11683 D.2.2. Initiator Algorithms 11685 Recover-Data-if-Possible(LastRequiredDataSN, TCB) 11686 { 11687 if (operational ErrorRecoveryLevel > 0) { 11688 if (# of missing PDUs is trackable) { 11689 Note the missing DataSNs in TCB. 11690 if (the task spanned a change in 11691 MaxRecvDataSegmentLength) { 11692 if (TCB.StatusXferd is TRUE) 11693 drop the status PDU; 11694 Build-And-Send-RDSnack(TCB); 11695 } else { 11696 Build-And-Send-DSnack(TCB); 11697 } 11698 } else { 11699 TCB.Reason = "Protocol service CRC error"; 11700 } 11701 } else { 11702 TCB.Reason = "Protocol service CRC error"; 11703 } 11704 if (TCB.Reason == "Protocol service CRC error") { 11705 Clear the missing PDU list in the TCB. 11706 if (TCB.StatusXferd is not TRUE) 11707 Build-And-Send-Abort(TCB); 11708 } 11709 } 11711 Receive-a-In-PDU(Connection, CurrentPDU) 11712 { 11713 check-basic-validity(CurrentPDU); 11714 if (Header-Digest-Bad) discard, return; 11715 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11716 if ((CurrentPDU.type == Data) 11717 or (CurrentPDU.type = R2T)) { 11718 if (Data-Digest-Bad for Data) { 11719 send-data-SNACK = TRUE; 11720 LastRequiredDataSN = CurrentPDU.DataSN; 11721 } else { 11722 if (TCB.SoFarInOrder = TRUE) { 11723 if (current DataSN is expected) { 11724 Increment TCB.ExpectedDataSN. 11725 } else { 11726 TCB.SoFarInOrder = FALSE; 11727 send-data-SNACK = TRUE; 11728 } 11729 } else { 11730 if (current DataSN was considered 11731 missing) { 11732 remove current DataSN from missing PDU 11733 list. 11734 } else if (current DataSN is higher than 11735 expected) { 11736 send-data-SNACK = TRUE; 11737 } else { 11738 discard, return; 11739 } 11740 Adjust TCB.ExpectedDataSN if appropriate. 11741 } 11742 LastRequiredDataSN = CurrentPDU.DataSN - 1; 11743 } 11744 if (send-data-SNACK is TRUE and 11745 task is not already considered failed) { 11746 Recover-Data-if-Possible(LastRequiredDataSN, TCB); 11747 } 11748 if (missing data PDU list is empty) { 11749 TCB.SoFarInOrder = TRUE; 11750 } 11751 if (CurrentPDU.type == R2T) { 11752 Increment ActiveR2Ts for this task. 11753 Create a data-descriptor for the data burst. 11754 Build-And-Send-A-Data-Burst(Connection, data-descriptor, 11755 TCB); 11756 } 11757 } else if (CurrentPDU.type == Response) { 11758 if (Data-Digest-Bad) { 11759 send-status-SNACK = TRUE; 11760 } else { 11761 TCB.StatusXferd = TRUE; 11762 Store the status information in TCB. 11763 if (ExpDataSN does not match) { 11764 TCB.SoFarInOrder = FALSE; 11765 Recover-Data-if-Possible(current DataSN, TCB); 11766 } 11767 if (missing data PDU list is empty) { 11768 TCB.SoFarInOrder = TRUE; 11769 } 11770 } 11772 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 11773 SHOWN */ 11774 } 11775 if ((TCB.SoFarInOrder == TRUE) and 11776 (TCB.StatusXferd == TRUE)) { 11777 SCSI-Task-Completion(TCB); 11778 } 11779 } 11781 D.2.3. Target Algorithms 11783 Receive-a-In-PDU(Connection, CurrentPDU) 11784 { 11785 check-basic-validity(CurrentPDU); 11786 if (Header-Digest-Bad) discard, return; 11787 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11788 if (CurrentPDU.type == Data) { 11789 Retrieve TContext from CurrentPDU.TargetTransferTag; 11790 if (Data-Digest-Bad) { 11791 Build-And-Send-Reject(Connection, CurrentPDU, 11792 Payload-Digest-Error); 11793 Note the missing data PDUs in MissingDataRange[]. 11794 send-recovery-R2T = TRUE; 11795 } else { 11796 if (current DataSN is not expected) { 11797 Note the missing data PDUs in MissingDataRange[]. 11798 send-recovery-R2T = TRUE; 11799 } 11800 if (CurrentPDU.Fbit == TRUE) { 11801 if (current PDU is solicited) { 11802 Decrement TCB.ActiveR2Ts. 11803 } 11804 if ((current PDU is unsolicited and 11805 data received is less than I/O length and 11806 data received is less than 11807 FirstBurstLength) 11808 or (current PDU is solicited and the length of 11809 this burst is less than expected)) { 11810 send-recovery-R2T = TRUE; 11811 Note the missing data in MissingDataRange[]. 11813 } 11814 } 11815 } 11816 Increment TContext.ExpectedDataSN. 11817 if (send-recovery-R2T is TRUE and 11818 task is not already considered failed) { 11819 if (operational ErrorRecoveryLevel > 0) { 11820 Increment TCB.ActiveR2Ts. 11821 Create a data-descriptor for the data burst 11822 from MissingDataRange. 11823 Build-And-Send-R2T(Connection, data-descriptor, 11824 TCB); 11825 } else { 11826 if (current PDU is the last unsolicited) 11827 TCB.Reason = "Not enough unsolicited data"; 11828 else 11829 TCB.Reason = "Protocol service CRC error"; 11830 } 11831 } 11832 if (TCB.ActiveR2Ts == 0) { 11833 Build-And-Send-Status(Connection, TCB); 11834 } 11835 } else if (CurrentPDU.type == SNACK) { 11836 snack-failure = FALSE; 11837 if (operational ErrorRecoveryLevel > 0) { 11838 if (CurrentPDU.type == Data/R2T) { 11839 if (the request is satisfiable) { 11840 if (request for Data) { 11841 Create a data-descriptor for the data burst 11842 from BegRun and RunLength. 11843 Build-And-Send-A-Data-Burst(Connection, 11844 data-descriptor, TCB); 11845 } else { /* R2T */ 11846 Create a data-descriptor for the data burst 11847 from BegRun and RunLength. 11848 Build-And-Send-R2T(Connection, data- 11849 descriptor, 11850 TCB); 11851 } 11852 } else { 11853 snack-failure = TRUE; 11855 } 11856 } else if (CurrentPDU.type == status) { 11857 Handle-Status-SNACK-request(Connection, 11858 CurrentPDU); 11859 } else if (CurrentPDU.type == DataACK) { 11860 Consider all data upto CurrentPDU.BegRun as 11861 acknowledged. 11862 Free up the retransmission resources for that data. 11863 } else if (CurrentPDU.type == R-Data SNACK) { 11864 Create a data descriptor for a data burst 11865 covering 11866 all unacknowledged data. 11867 Build-And-Send-A-Data-Burst(Connection, 11868 data-descriptor, TCB); 11869 TCB.SNACK_Tag = CurrentPDU.SNACK_Tag; 11870 if (there's no more data to send) { 11871 Build-And-Send-Status(Connection, TCB); 11872 } 11873 } 11874 } else { /* operational ErrorRecoveryLevel = 0 */ 11875 snack-failure = TRUE; 11876 } 11877 if (snack-failure == TRUE) { 11878 Build-And-Send-Reject(Connection, CurrentPDU, 11879 SNACK-Reject); 11880 if (TCB.StatusXferd != TRUE) { 11881 TCB.Reason = "SNACK Rejected"; 11882 Build-And-Send-Status(Connection, TCB); 11883 } 11884 } 11886 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT 11887 SHOWN */ 11888 } 11889 } 11891 Transfer-Context-Timeout-Handler(TContext) 11892 { 11893 Retrieve TCB and Connection from TContext. 11894 Decrement TCB.ActiveR2Ts. 11895 if (operational ErrorRecoveryLevel > 0 and 11896 task is not already considered failed) { 11897 Note the missing data PDUs in MissingDataRange[]. 11898 Create a data-descriptor for the data burst 11899 from MissingDataRange[]. 11900 Build-And-Send-R2T(Connection, data-descriptor, TCB); 11901 } else { 11902 TCB.Reason = "Protocol service CRC error"; 11903 if (TCB.ActiveR2Ts = 0) { 11904 Build-And-Send-Status(Connection, TCB); 11905 } 11906 } 11907 } 11909 D.3. Within-connection Recovery 11910 Algorithms 11912 D.3.1. Procedure Descriptions 11914 Procedure descriptions: 11915 Recover-Status-if-Possible(transport connection, 11916 currently received PDU); 11917 Evaluate-a-StatSN(transport connection, currently received PDU); 11918 Retransmit-Command-if-Possible(transport connection, CmdSN); 11919 Build-And-Send-SSnack(transport connection); 11920 Build-And-Send-Command(transport connection, task control block); 11921 Command-Acknowledge-Timeout-Handler(task control block); 11922 Status-Expect-Timeout-Handler(transport connection); 11923 Build-And-Send-Nop-Out(transport connection); 11924 Handle-Status-SNACK-request(transport connection, status SNACK 11925 PDU); 11926 Retransmit-Status-Burst(status SNACK, task control block); 11927 Is-Acknowledged(beginning StatSN, run length); 11929 Implementation-specific tunables: 11930 InitiatorProactiveSNACKEnabled 11932 Notes: 11933 - The initiator algorithms only deal with unsolicited Nop-In 11934 PDUs for generating status SNACKs. A solicited Nop-In PDU 11935 has an assigned StatSN, which, when out of order, could 11936 trigger the out of order StatSN handling in Within-command 11937 algorithms, again leading to Recover-Status-if-Possible. 11939 - The pseudo-code shown may result in the retransmission of 11940 unacknowledged commands in more cases than necessary. This 11941 will not, however, affect the correctness of the operation 11942 because the target is required to discard the duplicate 11943 CmdSNs. 11945 - The procedure Build-And-Send-Async is defined in the 11946 Connection recovery algorithms. 11948 - The procedure Status-Expect-Timeout-Handler describes how 11949 initiators may proactively attempt to retrieve the Status if 11950 they so choose. This procedure is assumed to be triggered 11951 much before the standard ULP timeout. 11953 D.3.2. Initiator Algorithms 11955 Recover-Status-if-Possible(Connection, CurrentPDU) 11956 { 11957 if ((Connection.state == LOGGED_IN) and 11958 connection is not already considered failed) 11959 { 11960 if (operational ErrorRecoveryLevel > 0) { 11961 if (# of missing PDUs is trackable) { 11962 Note the missing StatSNs in Connection 11963 that were not already requested with SNACK; 11964 Build-And-Send-SSnack(Connection); 11965 } else { 11966 Connection.PerformConnectionCleanup = TRUE; 11967 } 11968 } else { 11969 Connection.PerformConnectionCleanup = TRUE; 11970 } 11971 if (Connection.PerformConnectionCleanup == TRUE) { 11972 Start-Timer(Connection-Cleanup-Handler, Connection, 0); 11973 } 11974 } 11975 } 11977 Retransmit-Command-if-Possible(Connection, CmdSN) 11978 { 11979 if (operational ErrorRecoveryLevel > 0) { 11980 Retrieve the InitiatorTaskTag, and thus TCB for the CmdSN. 11981 Build-And-Send-Command(Connection, TCB); 11982 } 11983 } 11985 Evaluate-a-StatSN(Connection, CurrentPDU) 11986 { 11987 send-status-SNACK = FALSE; 11988 if (Connection.SoFarInOrder == TRUE) { 11989 if (current StatSN is the expected) { 11990 Increment Connection.ExpectedStatSN. 11991 } else { 11992 Connection.SoFarInOrder = FALSE; 11993 send-status-SNACK = TRUE; 11994 } 11995 } else { 11996 if (current StatSN was considered missing) { 11997 remove current StatSN from the missing list. 11998 } else { 11999 if (current StatSN is higher than expected){ 12000 send-status-SNACK = TRUE; 12001 } else { 12002 send-status-SNACK = FALSE; 12003 discard the PDU; 12004 } 12005 } 12006 Adjust Connection.ExpectedStatSN if appropriate. 12007 if (missing StatSN list is empty) { 12008 Connection.SoFarInOrder = TRUE; 12009 } 12010 } 12011 return send-status-SNACK; 12012 } 12014 Receive-a-In-PDU(Connection, CurrentPDU) 12015 { 12016 check-basic-validity(CurrentPDU); 12017 if (Header-Digest-Bad) discard, return; 12018 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12019 if (CurrentPDU.type == Nop-In) { 12020 if (the PDU is unsolicited) { 12021 if (current StatSN is not expected) { 12022 Recover-Status-if-Possible(Connection, 12023 CurrentPDU); 12024 } 12025 if (current ExpCmdSN is not Session.CmdSN) { 12026 Retransmit-Command-if-Possible(Connection, 12027 CurrentPDU.ExpCmdSN); 12028 } 12029 } 12030 } else if (CurrentPDU.type == Reject) { 12031 if (it is a data digest error on immediate data) { 12032 Retransmit-Command-if-Possible(Connection, 12034 CurrentPDU.BadPDUHeader.CmdSN); 12035 } 12036 } else if (CurrentPDU.type == Response) { 12037 send-status-SNACK = Evaluate-a-StatSN(Connection, 12038 CurrentPDU); 12039 if (send-status-SNACK == TRUE) 12040 Recover-Status-if-Possible(Connection, CurrentPDU); 12041 } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY, 12042 * NOT SHOWN */ 12043 } 12044 } 12046 Command-Acknowledge-Timeout-Handler(TCB) 12047 { 12048 Retrieve the Connection for TCB. 12049 Retransmit-Command-if-Possible(Connection, TCB.CmdSN); 12050 } 12051 Status-Expect-Timeout-Handler(Connection) 12052 { 12053 if (operational ErrorRecoveryLevel > 0) { 12054 Build-And-Send-Nop-Out(Connection); 12055 } else if (InitiatorProactiveSNACKEnabled){ 12056 if ((Connection.state == LOGGED_IN) and 12057 connection is not already considered failed) 12058 { 12059 Build-And-Send-SSnack(Connection); 12060 } 12061 } 12062 } 12064 E.3.3 Target Algorithms 12066 Handle-Status-SNACK-request(Connection, CurrentPDU) 12067 { 12068 if (operational ErrorRecoveryLevel > 0) { 12069 if (request for an acknowledged run) { 12070 Build-And-Send-Reject(Connection, CurrentPDU, 12071 Protocol-Error); 12072 } else if (request for an untransmitted run) { 12073 discard, return; 12074 } else { 12075 Retransmit-Status-Burst(CurrentPDU, TCB); 12076 } 12077 } else { 12078 Build-And-Send-Async(Connection, DroppedConnection, 12079 DefaultTime2Wait, 12080 DefaultTime2Retain); 12081 } 12082 } 12084 D.4. Connection Recovery Algorithms 12086 D.4.1. Procedure Descriptions 12088 Build-And-Send-Async(transport connection, reason code, 12089 minimum time, maximum time); 12090 Pick-A-Logged-In-Connection(session); 12091 Build-And-Send-Logout(transport connection, logout connection 12092 identifier, reason code); 12093 PerformImplicitLogout(transport connection, logout connection 12094 identifier, target information); 12095 PerformLogin(transport connection, target information); 12096 CreateNewTransportConnection(target information); 12097 Build-And-Send-Command(transport connection, task control block); 12098 Connection-Cleanup-Handler(transport connection); 12099 Connection-Resource-Timeout-Handler(transport connection); 12100 Quiesce-And-Prepare-for-New-Allegiance(session, task control 12101 block); 12102 Build-And-Send-Logout-Response(transport connection, 12103 CID of connection in recovery, reason 12104 code); 12105 Build-And-Send-TaskMgmt-Response(transport connection, 12106 task mgmt command PDU, response code); 12107 Establish-New-Allegiance(task control block, transport 12108 connection); 12109 Schedule-Command-To-Continue(task control block); 12111 Notes: 12112 - Transport exception conditions, such as unexpected connection 12113 termination, connection reset, and hung connection while the 12114 connection is in the full-feature phase, are all assumed to 12115 be asynchronously signaled to the iSCSI layer using the 12116 Transport_Exception_Handler procedure. 12118 D.4.2. Initiator Algorithms 12120 Receive-a-In-PDU(Connection, CurrentPDU) 12121 { 12122 check-basic-validity(CurrentPDU); 12123 if (Header-Digest-Bad) discard, return; 12124 Retrieve TCB from CurrentPDU.InitiatorTaskTag. 12125 if (CurrentPDU.type == Async) { 12126 if (CurrentPDU.AsyncEvent == ConnectionDropped) { 12127 Retrieve the AffectedConnection for 12128 CurrentPDU.Parameter1. 12130 AffectedConnection.CurrentTimeout = 12131 CurrentPDU.Parameter3; 12132 AffectedConnection.State = CLEANUP_WAIT; 12133 Start-Timer(Connection-Cleanup-Handler, 12134 AffectedConnection, 12135 CurrentPDU.Parameter2); 12136 } else if (CurrentPDU.AsyncEvent == LogoutRequest)) { 12137 AffectedConnection = Connection; 12138 AffectedConnection.State = LOGOUT_REQUESTED; 12139 AffectedConnection.PerformConnectionCleanup = TRUE; 12140 AffectedConnection.CurrentTimeout = 12141 CurrentPDU.Parameter3; 12142 Start-Timer(Connection-Cleanup-Handler, 12143 AffectedConnection, 0); 12144 } else if (CurrentPDU.AsyncEvent == SessionDropped)) { 12145 for (each Connection) { 12146 Connection.State = CLEANUP_WAIT; 12147 Connection.CurrentTimeout = CurrentPDU.Parameter3; 12148 Start-Timer(Connection-Cleanup-Handler, 12149 Connection, CurrentPDU.Parameter2); 12150 } 12151 Session.state = FAILED; 12152 } 12154 } else if (CurrentPDU.type == LogoutResponse) { 12155 Retrieve the CleanupConnection for CurrentPDU.CID. 12156 if (CurrentPDU.Response = failure) { 12157 CleanupConnection.State = CLEANUP_WAIT; 12158 } else { 12159 CleanupConnection.State = FREE; 12160 } 12161 } else if (CurrentPDU.type == LoginResponse) { 12162 if (this is a response to an implicit Logout) { 12163 Retrieve the CleanupConnection. 12164 if (successful) { 12165 CleanupConnection.State = FREE; 12166 Connection.State = LOGGED_IN; 12167 } else { 12168 CleanupConnection.State = CLEANUP_WAIT; 12169 DestroyTransportConnection(Connection); 12171 } 12172 } 12173 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12174 * NOT SHOWN */ 12175 } 12176 if (CleanupConnection.State == FREE) { 12177 for (each command that was active on CleanupConnection) { 12178 /* Establish new connection allegiance */ 12179 NewConnection = Pick-A-Logged-In-Connection(Session); 12180 Build-And-Send-Command(NewConnection, TCB); 12181 } 12182 } 12183 } 12185 Connection-Cleanup-Handler(Connection) 12186 { 12187 Retrieve Session from Connection. 12188 if (Connection can still exchange iSCSI PDUs) { 12189 NewConnection = Connection; 12190 } else { 12191 Start-Timer(Connection-Resource-Timeout-Handler, 12192 Connection, Connection.CurrentTimeout); 12193 if (there are other logged-in connections) { 12194 NewConnection = Pick-A-Logged-In- 12195 Connection(Session); 12196 } else { 12197 NewConnection = 12199 CreateTransportConnection(Session.OtherEndInfo); 12200 Initiate an implicit Logout on NewConnection for 12201 Connection.CID. 12202 return; 12203 } 12204 } 12205 Build-And-Send-Logout(NewConnection, Connection.CID, 12206 RecoveryRemove); 12207 } 12209 Transport_Exception_Handler(Connection) 12210 { 12211 Connection.PerformConnectionCleanup = TRUE; 12212 if (the event is an unexpected transport disconnect) { 12213 Connection.State = CLEANUP_WAIT; 12214 Connection.CurrentTimeout = DefaultTime2Retain; 12215 Start-Timer(Connection-Cleanup-Handler, Connection, 12216 DefaultTime2Wait); 12218 } else { 12219 Connection.State = FREE; 12220 } 12221 } 12223 D.4.3. Target Algorithms 12225 Receive-a-In-PDU(Connection, CurrentPDU) 12226 { 12227 check-basic-validity(CurrentPDU); 12228 if (Header-Digest-Bad) discard, return; 12229 else if (Data-Digest-Bad) { 12230 Build-And-Send-Reject(Connection, CurrentPDU, 12231 Payload-Digest-Error); 12232 discard, return; 12233 } 12234 Retrieve TCB and Session. 12235 if (CurrentPDU.type == Logout) { 12236 if (CurrentPDU.ReasonCode = RecoveryRemove) { 12237 Retrieve the CleanupConnection from CurrentPDU.CID). 12238 for (each command active on CleanupConnection) { 12239 Quiesce-And-Prepare-for-New-Allegiance(Session, 12240 TCB); 12241 TCB.CurrentlyAllegiant = FALSE; 12242 } 12243 Cleanup-Connection-State(CleanupConnection); 12244 if ((quiescing successful) and (cleanup successful)) { 12245 Build-And-Send-Logout-Response(Connection, 12246 CleanupConnection.CID, 12247 Success); 12248 } else { 12249 Build-And-Send-Logout-Response(Connection, 12250 CleanupConnection.CID, 12251 Failure); 12252 } 12253 } 12254 } else if ((CurrentPDU.type == Login) and 12255 operational ErrorRecoveryLevel == 2) { 12256 Retrieve the CleanupConnection from CurrentPDU.CID). 12257 for (each command active on CleanupConnection) { 12258 Quiesce-And-Prepare-for-New-Allegiance(Session, 12259 TCB); 12260 TCB.CurrentlyAllegiant = FALSE; 12261 } 12262 Cleanup-Connection-State(CleanupConnection); 12263 if ((quiescing successful) and (cleanup successful)) { 12264 Continue with the rest of the Login processing; 12265 } else { 12266 Build-And-Send-Login-Response(Connection, 12267 CleanupConnection.CID, Target 12268 Error); 12269 } 12270 } 12271 } else if (CurrentPDU.type == TaskManagement) { 12272 if (CurrentPDU.function == "TaskReassign") { 12273 if (Session.ErrorRecoveryLevel < 2) { 12274 Build-And-Send-TaskMgmt-Response(Connection, 12275 CurrentPDU, "Allegiance reassignment 12276 not supported"); 12277 } else if (task is not found) { 12278 Build-And-Send-TaskMgmt-Response(Connection, 12279 CurrentPDU, "Task not in task set"); 12280 } else if (task is currently allegiant) { 12281 Build-And-Send-TaskMgmt-Response(Connection, 12282 CurrentPDU, "Task still allegiant"); 12283 } else { 12284 Establish-New-Allegiance(TCB, Connection); 12285 TCB.CurrentlyAllegiant = TRUE; 12286 Schedule-Command-To-Continue(TCB); 12287 } 12288 } 12289 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12290 * NOT SHOWN */ 12291 } 12292 } 12294 Transport_Exception_Handler(Connection) 12295 { 12296 Connection.PerformConnectionCleanup = TRUE; 12297 if (the event is an unexpected transport disconnect) { 12298 Connection.State = CLEANUP_WAIT; 12299 Start-Timer(Connection-Resource-Timeout-Handler, 12300 Connection, 12302 (DefaultTime2Wait+DefaultTime2Retain)); 12303 if (this Session has full-feature phase connections left) 12304 { 12305 DifferentConnection = 12306 Pick-A-Logged-In-Connection(Session); 12307 Build-And-Send-Async(DifferentConnection, 12308 DroppedConnection, DefaultTime2Wait, 12309 DefaultTime2Retain); 12310 } 12311 } else { 12312 Connection.State = FREE; 12313 } 12314 } 12315 Appendix E. Clearing Effects of Various Events on Targets 12317 E.1. Clearing Effects on iSCSI Objects 12319 The following tables describe the target behavior on receiving the 12320 events specified in the rows of the table. The second table is an 12321 extension of the first table and defines clearing actions for more 12322 objects on the same events. The legend is: 12324 Y = Yes (cleared/discarded/reset on the event specified in 12325 the row). Unless otherwise noted, the clearing action is 12326 only applicable for the issuing initiator port. 12328 N = No (not affected on the event specified in the row, 12329 i.e., stays at previous value). 12331 NA = Not Applicable or Not Defined. 12333 +-----+-----+-----+-----+-----+ 12334 |IT(1)|IC(2)|CT(5)|ST(6)|PP(7)| 12335 +---------------------+-----+-----+-----+-----+-----+ 12336 |connection failure(8)|Y |Y |N |N |Y | 12337 +---------------------+-----+-----+-----+-----+-----+ 12338 |connection state |NA |NA |Y |N |NA | 12339 |timeout (9) | | | | | | 12340 +---------------------+-----+-----+-----+-----+-----+ 12341 |session timeout/ |Y |Y |Y |Y |Y(14)| 12342 |closure/reinstatement| | | | | | 12343 |(10) | | | | | | 12344 +---------------------+-----+-----+-----+-----+-----+ 12345 |session continuation |NA |NA |N(11)|N |NA | 12346 |(12) | | | | | | 12347 +---------------------+-----+-----+-----+-----+-----+ 12348 |successful connection|Y |Y |Y |N |Y(13)| 12349 |close logout | | | | | | 12350 +---------------------+-----+-----+-----+-----+-----+ 12351 |session failure (18) |Y |Y |N |N |Y | 12352 +---------------------+-----+-----+-----+-----+-----+ 12353 |successful recovery |Y |Y |N |N |Y(13)| 12354 |Logout | | | | | | 12355 +---------------------+-----+-----+-----+-----+-----+ 12356 |failed Logout |Y |Y |N |N |Y | 12357 +---------------------+-----+-----+-----+-----+-----+ 12358 |connection Login |NA |NA |NA |Y(15)|NA | 12359 |(leading) | | | | | | 12360 +---------------------+-----+-----+-----+-----+-----+ 12361 |connection Login |NA |NA |N(11)|N |Y | 12362 |(non-leading) | | | | | | 12363 +---------------------+-----+-----+-----+-----+-----+ 12364 |target cold reset(16)|Y(20)|Y |Y |Y |Y | 12365 +---------------------+-----+-----+-----+-----+-----+ 12366 |target warm reset(16)|Y(20)|Y |Y |Y |Y | 12367 +---------------------+-----+-----+-----+-----+-----+ 12368 |LU reset(19) |Y(20)|Y |Y |Y |Y | 12369 +---------------------+-----+-----+-----+-----+-----+ 12370 |powercycle(16) |Y |Y |Y |Y |Y | 12371 +---------------------+-----+-----+-----+-----+-----+ 12373 1. Incomplete TTTs - Target Transfer Tags on which the target is 12374 still expecting PDUs to be received. Examples include TTTs 12375 received via R2T, NOP-IN, etc. 12377 2. Immediate Commands - immediate commands, but waiting for 12378 execution on a target. For example, Abort Task Set. 12380 5. Connection Tasks - tasks that are active on the iSCSI connection 12381 in question. 12383 6. Session Tasks - tasks that are active on the entire iSCSI 12384 session. A union of "connection tasks" on all participating 12385 connections. 12387 7. Partial PDUs (if any) - PDUs that are partially sent and waiting 12388 for transport window credit to complete the transmission. 12390 8. Connection failure is a connection exception condition - one of 12391 the transport connections shutdown, transport connections reset, 12392 or transport connections timed out, which abruptly terminated 12393 the iSCSI full-feature phase connection. A connection failure 12394 always takes the connection state machine to the CLEANUP_WAIT 12395 state. 12397 9. Connection state timeout happens if a connection spends more time 12398 than agreed upon during Login negotiation in the CLEANUP_WAIT 12399 state, and this takes the connection to the FREE state (M1 12400 transition in connection cleanup state diagram). 12402 10.These are defined in Section 6.3.5. 12404 11.This clearing effect is "Y" only if it is a connection 12405 reinstatement and the operational ErrorRecoveryLevel is less 12406 than 2. 12408 12.Session continuation is defined in Section 6.3.5. 12410 13.This clearing effect is only valid if the connection is being 12411 logged out on a different connection and when the connection 12412 being logged out on the target may have some partial PDUs 12413 pending to be sent. In all other cases, the effect is "NA". 12415 14.This clearing effect is only valid for a "close the session" 12416 logout in a multi-connection session. In all other cases, the 12417 effect is "NA". 12418 15.Only applicable if this leading connection login is a session 12419 reinstatement. If this is not the case, it is "NA". 12420 16.This operation affects all logged-in initiators. 12421 18.Session failure is defined in Section 6.3.5. 12422 19.This operation affects all logged-in initiators and the clearing 12423 effects are only applicable to the LU being reset. 12424 20.With Standard multi-task abort semantics (Section 4.2.3.3), a 12425 target warm reset or a target cold reset or an LU reset would 12426 clear the active TTTs upon completion. However, the FastAbort 12427 multi-task abort semantics defined by Section 4.2.3.4 do not 12428 guarantee that the active TTTs are cleared by the end of the 12429 reset operations. In fact, the FastAbort semantics are designed 12430 to allow clearing the TTTs in a "lazy" fashion after the TMF 12431 Response is delivered. Thus, when TaskReporting=FastAbort 12432 (Section 13.23) is operational on a session, the clearing 12433 effects of reset operations on "Incomplete TTTs" is "N". 12435 +-----+-----+-----+-----+-----+ 12436 |DC(1)|DD(2)|SS(3)|CS(4)|DS(5)| 12437 +---------------------+-----+-----+-----+-----+-----+ 12438 |connection failure |N |Y |N |N |N | 12439 +---------------------+-----+-----+-----+-----+-----+ 12440 |connection state |Y |NA |Y |N |NA | 12441 |timeout | | | | | | 12442 +---------------------+-----+-----+-----+-----+-----+ 12443 |session timeout/ |Y |Y |Y(7) |Y |NA | 12444 |closure/reinstatement| | | | | | 12445 +---------------------+-----+-----+-----+-----+-----+ 12446 |session continuation |N(11)|NA*12|NA |N |NA*13| 12447 +---------------------+-----+-----+-----+-----+-----+ 12448 |successful connection|Y |Y |Y |N |NA | 12449 |close Logout | | | | | | 12450 +---------------------+-----+-----+-----+-----+-----+ 12451 |session failure |N |Y |N |N |N | 12452 +---------------------+-----+-----+-----+-----+-----+ 12453 |successful recovery |Y |Y |Y |N |N | 12454 |Logout | | | | | | 12455 +---------------------+-----+-----+-----+-----+-----+ 12456 |failed Logout |N |Y(9) |N |N |N | 12457 +---------------------+-----+-----+-----+-----+-----+ 12458 |connection Login |NA |NA |N(8) |N(8) |NA | 12459 |(leading | | | | | | 12460 +---------------------+-----+-----+-----+-----+-----+ 12461 |connection Login |N(11)|NA*12|N(8) |N |NA*13| 12462 |(non-leading) | | | | | | 12463 +---------------------+-----+-----+-----+-----+-----+ 12464 |target cold reset |Y |Y |Y |Y(10)|NA | 12465 +---------------------+-----+-----+-----+-----+-----+ 12466 |target warm reset |Y |Y |N |N |NA | 12467 +---------------------+-----+-----+-----+-----+-----+ 12468 |LU reset |N |Y |N |N |N | 12469 +---------------------+-----+-----+-----+-----+-----+ 12470 |powercycle |Y |Y |Y |Y(10)|NA | 12471 +---------------------+-----+-----+-----+-----+-----+ 12473 1. Discontiguous Commands - commands allegiant to the connection in 12474 question and waiting to be reordered in the iSCSI layer. All "Y"s 12475 in this column assume that the task causing the event (if indeed 12476 the event is the result of a task) is issued as an immediate 12477 command, because the discontiguities can be ahead of the task. 12479 2. Discontiguous Data - data PDUs received for the task in question 12480 and waiting to be reordered due to prior discontiguities in DataSN. 12482 3. StatSN 12484 4. CmdSN 12486 5. DataSN 12488 7. It clears the StatSN on all the connections. 12490 8. This sequence number is instantiated on this event. 12492 9. A logout failure drives the connection state machine to the 12493 CLEANUP_WAIT state, similar to the connection failure event. Hence, 12494 it has a similar effect on this and several other protocol aspects. 12496 10. This is cleared by virtue of the fact that all sessions with 12497 all initiators are terminated. 12499 11. This clearing effect is "Y" if it is a connection 12500 reinstatement. 12502 12. This clearing effect is "Y" only if it is a connection 12503 reinstatement and the operational ErrorRecoveryLevel is 2. 12505 13. This clearing effect is "N" only if it is a connection 12506 reinstatement and the operational ErrorRecoveryLevel is 2. 12508 E.2. Clearing Effects on SCSI Objects 12510 The only iSCSI protocol action that can effect clearing actions on 12511 SCSI objects is the "I_T nexus loss" notification (Section 4.3.5.1 12512 Loss of Nexus notification). [SPC3] describes the clearing effects 12513 of this notification on a variety of SCSI attributes. In addition, 12514 SCSI standards documents (such as [SAM2] and [SBC]) define 12515 additional clearing actions that may take place for several SCSI 12516 objects on SCSI events such as LU resets and power-on resets. 12518 Since iSCSI defines a target cold reset as a protocol-equivalent to 12519 a target power-cycle, the iSCSI target cold reset must also be 12520 considered as the power-on reset event in interpreting the actions 12521 defined in the SCSI standards. 12523 When the iSCSI session is reconstructed (between the same SCSI 12524 ports with the same nexus identifier) reestablishing the same I_T 12525 nexus, all SCSI objects that are defined to not clear on the "I_T 12526 nexus loss" notification event, such as persistent reservations, 12527 are automatically associated to this new session. 12529 Acknowledgments 12531 Several individuals on the original IPS Working Group made 12532 significant contributions to the original RFCs 3720, 3980, 4850 and 12533 5048. 12535 Specifically, the authors of the original RFCs - which this draft 12536 consolidates into a single document - were the following: 12538 RFC 3720: Julian Satran, Kalman Meth, Costa Sapuntzakis, 12539 Mallikarjun Chadalapaka, Efri Zeidner 12541 RFC 3980: Marjorie Krueger, Mallikarjun Chadalapaka, Rob Elliott 12543 RFC 4850: David Wysochanski 12545 RFC 5048: Mallikarjun Chadalapaka 12547 Many thanks to Fred Knight for contributing to the UML notations 12548 and drawings in this draft. 12550 We would in addition like to acknowledge the following individuals 12551 who contributed to this revised draft: David Black, David 12552 Harrington, Paul Koning, Mark Edwards. 12554 Authors' Addresses 12556 Mallikarjun Chadalapaka 12557 E-mail: cbm@chadalapaka.com 12559 Julian Satran 12560 E-mail: Julian.Satran@gmail.com 12562 Kalman Meth 12563 IBM Haifa Research Lab 12564 Haifa University Campus - Mount Carmel 12565 Haifa 31905, Israel 12566 Phone +972.4.829.6341 12567 E-mail: meth@il.ibm.com 12569 Comments may be sent to Mallikarjun Chadalapaka 12571 Acknowledgement 12573 Funding for the RFC Editor function is currently provided by the 12574 Internet Society