idnits 2.17.1 draft-ietf-ips-iscsi-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 12540 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 11 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 17538 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SEC-IPS], [NDT], [SAM2], [BOOT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 32 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 316: '... - Padding bytes SHOULD be sent as 0 (...' RFC 2119 keyword, line 591: '...ified keys except X-* MUST be accepted...' RFC 2119 keyword, line 681: '... security. MAY be discarded" int...' RFC 2119 keyword, line 1366: '...s and initiators MUST support at least...' RFC 2119 keyword, line 1367: '... connection and MAY support several c...' (408 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 298 has weird spacing: '...Address delet...' == Line 2451 has weird spacing: '... ISIDs for r...' == Line 2619 has weird spacing: '...rements tha...' == Line 2621 has weird spacing: '...hat are the b...' == Line 2625 has weird spacing: '...y given tim...' == (14 more instances...) -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the current value of the CmdSN register is Q, an ini-tiator MUST not advance CmdSN past R + 2**31 - 1 after reissuing a command with CmdSN R on a connection while this connection is operational, unless a new non-immedi-ate command with CmdSN equal or greater than Q was issued on the given connection and its reception acknowledged by the target (see Section 9.3 Command Retry and Cleaning Old Command Instances). The non-immediate command MUST be sent in order after the retried command. A target MUST NOT issue a command response or DATA-In PDU with status before acknowledging the command. However, the acknowledgement can be included in the response or Data-in PDU itself. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An R2T MAY be answered with one or more SCSI Data-out PDUs with a matching Target Transfer Tag. If an R2T is answered with a single Data-out PDU, the Buffer Offset in the Data PDU MUST be the same as the one specified by the R2T. The data length of the Data PDU MUST not exceed the Desired Data Transfer Length specified in the R2T. If the R2T is answered with a sequence of Data PDUs, the Buffer Offset and Length MUST be within the range of those specified by R2T, and the last PDU SHOULD have the F bit set to 1. If the last PDU (marked with the F bit) is received before the Desired Data Transfer Length is transferred, a target MAY choose to Reject that PDU with "Protocol error" reason code. DataPDUInOrder governs the Data-Out PDU ordering. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The target specifies how many bytes it wants the initiator to send because of this R2T PDU. The target may request the data from the initiator in several chunks, not neces-sarily in the original order of the data. The target, therefore, also specifies a Buffer Offset that indicates the point at which the data transfer should begin, rela-tive to the beginning of the total data transfer. The Desired Data Transfer Length SHOULD not be 0 and MUST not exceed MaxBurstSize. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: KRB_AP_REQ and KRB_AP_REP are large binary items and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All the SPKM-* tokens are large binary items and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Where U, N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, i.e., SRP-SHA1), U is a text string, N,g,s,A,B,M, and H(A | M | K) are binary items, and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes. Further restrictions on allowed N,g values are specified in Section 8.2 In-band Initiator-Target Authentication. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algorithm, Identifier, Challenge, and Response as defined in [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C and R are binary items and their binary length (not the length of the character string that repre-sents them in encoded form) MUST not exceed 1024 bytes. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: covery session, and MAY NOT be supported on an operational session. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The session should respond only with addresses for the target to which the session is logged in. This MUST be supported on operational sessions, and MAY NOT return targets other than the one to which the session is logged in. == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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) -- Missing reference section? 'RFC2026' on line 10095 looks like a reference -- Missing reference section? 'SAM2' on line 10134 looks like a reference -- Missing reference section? 'RFC2372' on line 306 looks like a reference -- Missing reference section? 'RFC2373' on line 10110 looks like a reference -- Missing reference section? 'SPC3' on line 377 looks like a reference -- Missing reference section? 'SAM' on line 10132 looks like a reference -- Missing reference section? 'RFC1982' on line 10083 looks like a reference -- Missing reference section? 'SEC-IPS' on line 10145 looks like a reference -- Missing reference section? 'NDT' on line 10066 looks like a reference -- Missing reference section? 'RFC2732' on line 10128 looks like a reference -- Missing reference section? 'RFC2246' on line 10108 looks like a reference -- Missing reference section? 'OR' on line 4429 looks like a reference -- Missing reference section? 'RFC2945' on line 11256 looks like a reference -- Missing reference section? 'RFC2401' on line 10115 looks like a reference -- Missing reference section? 'RFC2406' on line 10120 looks like a reference -- Missing reference section? 'RFC2404' on line 10118 looks like a reference -- Missing reference section? 'AES' on line 10041 looks like a reference -- Missing reference section? 'XCBC' on line 10151 looks like a reference -- Missing reference section? 'SEQ-EXT' on line 10147 looks like a reference -- Missing reference section? 'RFC2451' on line 10126 looks like a reference -- Missing reference section? 'AESCTR' on line 10051 looks like a reference -- Missing reference section? 'RFC2409' on line 10124 looks like a reference -- Missing reference section? 'RFC2407' on line 10122 looks like a reference -- Missing reference section? '7' on line 5117 looks like a reference -- Missing reference section? '0' on line 5603 looks like a reference -- Missing reference section? '8' on line 5604 looks like a reference -- Missing reference section? 'RFC2045' on line 10099 looks like a reference -- Missing reference section? 'RFC1510' on line 10077 looks like a reference -- Missing reference section? 'RFC2025' on line 10093 looks like a reference -- Missing reference section? 'RFC1994' on line 10090 looks like a reference -- Missing reference section? 'AC' on line 10039 looks like a reference -- Missing reference section? 'BOOT' on line 10054 looks like a reference -- Missing reference section? 'CAM' on line 10056 looks like a reference -- Missing reference section? 'Castagnoli93' on line 10057 looks like a reference -- Missing reference section? 'COBS' on line 10458 looks like a reference -- Missing reference section? 'CRC' on line 10064 looks like a reference -- Missing reference section? 'RFC790' on line 10068 looks like a reference -- Missing reference section? 'RFC791' on line 10069 looks like a reference -- Missing reference section? 'RFC793' on line 10071 looks like a reference -- Missing reference section? 'RFC1035' on line 10073 looks like a reference -- Missing reference section? 'RFC1122' on line 10075 looks like a reference -- Missing reference section? 'RFC1766' on line 10079 looks like a reference -- Missing reference section? 'RFC1964' on line 10081 looks like a reference -- Missing reference section? 'RFC2044' on line 10097 looks like a reference -- Missing reference section? 'RFC2119' on line 10103 looks like a reference -- Missing reference section? 'RFC2234' on line 10106 looks like a reference -- Missing reference section? 'RFC2434' on line 10112 looks like a reference -- Missing reference section? 'SBC' on line 10136 looks like a reference -- Missing reference section? 'Schneier' on line 10142 looks like a reference -- Missing reference section? 'SPC' on line 10149 looks like a reference -- Missing reference section? 'MaxMissingDPDU' on line 11764 looks like a reference -- Missing reference section? 'MaxOutStandingR2T' on line 11772 looks like a reference -- Missing reference section? 'MaxMissingSPDU' on line 11783 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 22 warnings (==), 57 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 iSCSI 20-January-02 4 IPS Julian Satran 5 Internet Draft Daniel Smith 6 draft-ietf-ips-iscsi-10.txt Kalman Meth 7 Category: standards-track Ofer Biran 8 Jim Hafner 9 IBM 11 Costa Sapuntzakis 12 Mark Bakke 13 Cisco Systems 15 Matt Wakeley 16 Agilent Technolo- 17 gies 19 Luciano Dalle Ore 20 Quantum 22 Paul Von Stamwitz 23 Adaptec 25 Randy Haagens 26 Mallikarjun Chadal- 27 apaka 28 Hewlett-Packard Co. 30 Efri Zeidner 31 SANGate 33 iSCSI 35 Julian Satran Expires August 2002 1 37 iSCSI 20-January-02 39 Status of this Memo 41 This document is an Internet-Draft and fully conforms to 42 all provisions of Section 10 of [RFC2026]. 44 Internet-Drafts are working documents of the Internet 45 Engineering Task Force (IETF), its areas, and its working 46 groups. Note that other groups may also distribute working 47 documents as Internet-Drafts. Internet-Drafts are draft 48 documents valid for a maximum of six months and may be 49 updated, replaced, or made obsolete by other documents at 50 any time. It is inappropriate to use Internet- Drafts as 51 reference material or to cite them other than as "work in 52 progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be 56 accessed at http://www.ietf.org/shadow.html. 58 Abstract 60 The Small Computer Systems Interface (SCSI) is a popular 61 family of protocols for communicating with I/O devices, 62 especially storage devices. This memo describes a trans- 63 port protocol for SCSI that operates on top of TCP. The 64 iSCSI protocol aims to be fully compliant with the 65 requirements laid out in the SCSI Architecture Model - 2 66 [SAM2] document. 68 Acknowledgements 70 In addition to the authors, a large group of people con- 71 tributed to this work through their review, comments and 72 valuable insights. We are grateful to all of them. We are 73 especially grateful to those who found the time and 74 patience to participate in our weekly phone conferences 75 and intermediate meetings in Almaden and Haifa, thus help- 76 ing to shape this document: John Hufferd, Prasenjit 77 Sarkar, Meir Toledano, John Dowdy, Steve Legg, Alain Aza- 78 gury (IBM), Dave Nagle (CMU), David Black (EMC), John 79 Matze (Veritas - now with Stonefly Networks), Steve 80 DeGroote, Mark Shrandt (NuSpeed), Gabi Hecht (Gadzoox), 81 Robert Snively (Brocade), Nelson Nachum (StorAge), Uri 83 Julian Satran Expires August 2002 2 85 iSCSI 20-January-02 87 Elzur (Broadcom). Many more helped clean up and improve 88 this document within the IPS working group. We are espe- 89 cially grateful to David Robinson and Raghavendra Rao 90 (Sun), Charles Monia, Joshua Tseng (Nishan), Somesh Gupta 91 (Silverback Systems), Michael Krause, Pierre Labat, San- 92 tosh Rao, Matthew Burbridge (HP), Stephen Bailey (Sand- 93 burst), Robert Elliott (Compaq), Steve Senum, Ayman 94 Ghanem (CISCO), Barry Reinhold (Trebia Networks), Bob 95 Russell (UNH), Bill Lynn (Adaptec), Doug Otis (Sanlight), 96 Robert Griswold and Bill Moody (Crossroads). The recovery 97 chapter was enhanced with help from Stephen Bailey (Sand- 98 burst), Somesh Gupta (HP), Venkat Rangan (Rhapsody Net- 99 works), Vince Cavanna, Pat Thaler (Agilent), Eddy 100 Quicksall (iVivity, Inc.) - Eddy also contributed with 101 some examples. Last, but not least, thanks to Ralph Weber 102 for keeping us in line with T10 (SCSI) standardization. 103 We would like to thank Steve Hetzler for his unwavering 104 support and for coming up with such a good name for the 105 protocol, Micky Rodeh, Jai Menon, Clod Barrera and Andy 106 Bechtolsheim for helping this work happen. 108 At the time of the writing, this document has to be con- 109 sidered in conjunction with the "Naming & Discov- 110 ery"[NDT], "Boot"[BOOT] and "Securing iSCSI, iFCP and 111 FCIP"[SEC-IPS] documents. 113 The "Naming & Discovery" document is authored by: 115 Mark Bakke (Cisco), Joe Czap, Jim Hafner, John 116 Hufferd, Kaladhar Voruganti (IBM), Howard Hall 117 (Pirus), Jack Harwood (EMC), Yaron Klein (SANRAD), 118 Lawrence Lamers (San Valley Systems), Todd Sperry 119 (Adaptec) 120 and 121 Joshua 122 Tseng 123 (Nishan). 125 The "Boot" document is authored by: 127 Prasenjit Sarkar (IBM), Duncan Missimer (HP) and 128 Costa Sapuntzakis (CISCO). 130 The "Securing iSCSI, iFCP and FCIP" document is authored 131 by: 133 Bernard Aboba, William Dixon (Microsoft), David Black 134 (EMC), 136 Julian Satran Expires August 2002 3 138 iSCSI 20-January-02 140 Joseph Tardo, Uri Elzur (Broadcom), Mark Bakke, Steve 141 Senum (Cisco Systems), Howard Herbert, Jesse Walker 142 (Intel), Julian Satran, Ofer Biran and Charles Kun- 143 zinger (IBM). 145 We are grateful to all of them for their good work and for 146 helping us correlate this document with the ones they pro- 147 duced. 149 Conventions used in this document 151 In examples, "I->" and "T->" indicate iSCSI PDUs sent by 152 the initiator and target respectively. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 155 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 156 "MAY", and "OPTIONAL" in this document are to be inter- 157 preted as described in RFC2119. 159 Change Log 161 The following changes were made from draft-ietf-ips- 162 iSCSI-09 to draft-ietf-ips-iSCSI-10: 164 - Clarifying MaxOutstandingR2T 165 - Widening the scope of Reject reason code 0x09 to 166 mean "Invalid PDU field". 167 - Changes in the "iSCSI connection termination" sec- 168 tion to make the terminology usage consistent with 169 the rest of the draft. 170 - Adding transition T18 in standard connection state 171 diagram, and its description. 172 - Other minor wording changes in the state transi- 173 tions chapter to address "session close" case and 174 others. 175 - Adding a new state Q5(IN_CONTINUE) to the target 176 session state diagram to resolve transitions N8 and 177 N9 off Q2. 178 - Removed the AHS drop bit feature. 179 - Removed the qualifier field in Task Management 180 Response PDU, and added a new response "Function 181 authorization failed". 182 - Clarified the fate of regular SCSI reservations on 183 a session timeout, compared to a transient session 184 failure. 186 Julian Satran Expires August 2002 4 188 iSCSI 20-January-02 190 - Added wording in R2T section to address the case of 191 receiving a smaller write data sequence than was 192 asked for in an R2T. 193 - Changes and fixes in recovery algorithms to be con- 194 sistent with the rest of the draft. 195 - Changed the "Invalid SNACK" Reject reason code to 196 "Invalid data ACK" since the invalid SNACK is 197 already covered under "Protocol error". Also 198 treating DataSN and R2TSN equivalently in this 199 case. 200 - Change in the SNACK section to require a Reject 201 "Protocol error" on an invalid SNACK. 202 - Time2Retain 0 in Logout Response indicates connec- 203 tion/session can�t recover 204 - Coordinate DataSequenceInOrder with Error recovery 205 level and MaxOutstandingR2T, also stating that only 206 the last read/write sequence is recoverable under 207 digest error recovery if DataSequenceInOrder=yes 208 - Alias designation format appendix is again out(!) - 209 T10 has decided it will go in SPC3 210 - Task Management synchronization moved to the target 211 (task management response given after task manage- 212 ment action and confirmed delivery of all previous 213 responses) 214 - Removed the don�t care value in numerical negotia- 215 tions 216 - Changed Marker negotiation to allow it to be closed 217 in one round 218 - Marker position is not dependent of the length of 219 the login phase 220 - Statement made that reserved bits do not have to be 221 checked at the beginning of Chapter 10 222 - InitialR2T, BidiInitialR2T and ImmediateData 223 changed to LO 224 - I bit (equivalent) in responses made 0 225 - Added a "double response" version for the ? key 226 value to Section 2.2.4 Text Mode Negotiation 227 - ? value can be used only outside Login 228 - added :, [ and ] as allowed in key values 229 - allow 0 in LogoutLoginMax and Min 230 - after task reassign no SNACK mandated, the function 231 must be performed by target with information made 232 available by reassign 233 - removed the third party command section - SCSI now 234 handles everything needed (including iSCSI alias- 235 ing) 237 The following changes were made from draft-ietf-ips- 238 iSCSI-08 to draft-ietf-ips-iSCSI-09: 240 Julian Satran Expires August 2002 5 242 iSCSI 20-January-02 244 - Added Task management response "task management 245 function not supported" 246 - Negotiation (numeric) responder driven 247 - Added vendor specific data to reject 248 - Allow logout in discovery sessions 249 - Variable DataPDULength - renamed MaxRecvPDULength 250 - Key=value pairs can span PDU boundaries 251 - Uniform treatment of text exchange resets 252 - Reintroduced DataACK as a special form of SNACK 253 - Extended ISID in the Login Request 254 - Removed 0 as a "no limit value" (residue from mode 255 pages) 256 - Reintroduced LogoutLoginMinTime 257 - Digests moved to Operational Keys 258 - Removed X bit in all commands and replaced it in 259 Login and added a cleaning rule to CmdSN numbering 260 - Several simplifications in state transition section 261 - standard connection and session state diagrams 262 are separately described for initiators and targets 263 - Several minor technical and language changes in the 264 error recovery section 265 - Added Irrelevant to negotiations 266 - Clarification to logout behavior 267 - Clarification to command ordering 268 - On SCSI timeout task abort instead of session fail- 269 ure 270 - Changed version to 0x03 - ALL VERSION NUMBERS are 271 temporary up to "Rafting" (take them with a grain 272 of salt) 274 The following changes were made from draft-ietf-ips- 275 iSCSI-07 to draft-ietf-ips-iSCSI-08: 277 - Clarified the use of initiator task tag with regard 278 to the SCSI tag in Section 10.2.1.7 Initiator Task 279 Tag 280 - Added a clarification to Section 2.2.2.1 Command 281 Numbering and Acknowledging - response to a command 282 should not precede acknowledgment. 283 - Added clarification to Section 10.7 SCSI Data-out & 284 SCSI Data-in - good status in Data-In must be sup- 285 ported by initiators 286 - Clarified InitiatorName is required at login in 287 Section 4.1 Login Phase Start 288 - Another clarification for SecurityContextComplete 289 in Section 4.2 iSCSI Security Negotiation 290 - Added "command not supported in this session type" 291 to reject reasons 293 Julian Satran Expires August 2002 6 295 iSCSI 20-January-02 297 - Discovery session implies MaxConnections = 1 298 - Second appearance of TargetAddress deleted 299 - Padding forbidden for non-end-of-sequence data PDUs 300 - Removed Boot and Copenhagener Session types 301 - Changed explanation of ExpDataSN 302 - Removed/corrected response 05 in Section 10.4.3 303 Response 304 - Brought Section 2.2.7 Naming and Addressing in line 305 with NDT draft 306 - Fixed the syntax in accordance with [RFC2372] and 307 [RFC2373] 308 - Removed forgotten references to the default iSCSI 309 target 310 - Counters back to Reject Response 311 - Clarification - SendTargets admissible only in full 312 feature phase 313 - Changed name of DataOrder and DataDeliveryOrder to 314 DataSequenceOrder and DataPDUInOrder and clarified 315 appendix text 316 - Padding bytes SHOULD be sent as 0 (instead of MUST 317 be 0) 318 - UA attention behavior for various resets deleted - 319 replaced with reference to SAM2 320 - Removed AccessID 321 - OpParmReset generalized 322 - Clarified the definition of full-feature phase in 323 Section 2.2.5 iSCSI Full Feature Phase 324 - Added new Reject reason codes, tabular listing and 325 a pointer to Section 10.14.3 Reason Code 326 - Added additional Reject usage semantics on CmdSN 327 and DataSN to Section 10.14.3 Reason Code 328 - Added a new Logout Response code for failure 329 - Renamed BUSY as RECOVERY_START, removed 330 RECOVERY_DONE, and merged T11 and T14 transitions 331 into T11-(1,2) in Section 6 State Transitions. 332 - Corrected initiator handling of format errors 333 - Clarified usage of command replay 334 - Removed the delivery in same order as presented 335 from Text Response 336 - Clarified RefCmdSN function fro abort task 337 - Corrected length field for AHS of type Extended CDB 338 - Removed LUN from text management response 339 - Clarified F bit for Bidirectional commands 340 - Removed the Async iSCSI event "target reset" 341 - Removed wording in Section 10.6 Task Management 342 Function Response linking SCSI mode pages to Async 343 Messages 344 - Changed the ASC/ASCQ values to better mean "not 345 enough unsolicited data" 346 - Names examples include date 348 Julian Satran Expires August 2002 7 350 iSCSI 20-January-02 352 - Removed references to S bit in Section 10.4 SCSI 353 Response 354 - Fixed NOP to simplify and avoid it consuming CmdSN 355 - Fixed CRC and examples 356 - Added the T, CSG & NSG fields to Login Command & 357 Response, rewrote Chapter 3, changed all examples 358 in Appendix D. - Login Phase Examples - to fit the 359 above changes 360 - Key=value confined to one response 361 - Add command restart/replay to task management 362 - Removed cryptographic digests 363 - Removed "proxy required" status code 364 - Re-named and fixed descriptions of status codes 365 - Re-formatted login examples for clarity 366 - SCSI/iSCSI parameters - fixed Section 3 SCSI Mode 367 Parameters for iSCSI, out DataPDULength, DataSe- 368 quenceOrder 369 - Changed all sense keys to aborted command in the 370 table in Section 10.4.2 Status 371 - Rearranged requests to have all SCSI related 372 grouped etc. 373 - Fixed Task Management Function Request ABORT TASK 374 and removed the part about it in Chapter 9. 375 - Reintroduced aliases (the data format) in an appen- 376 dix. The aliasing mechanism once part of iSCSI is 377 part of [SPC3] 378 - Login negotiations - using only login request 379 response (instead of former login and text) 380 - F bit in login changed name to T bit 381 - Stated defaults for mode parameters in chapter 3 382 - Updated Chapter 8 to reflect the current consensus 383 on security 384 - Changed all sense keys to aborted command in the 385 table in 2.4.2 386 - Minor language clarifications in sections 1.2.3, 387 1.2.5, 1.2.6, 1.2.8. 388 - Added a new Reject reason code "Task in progress" 389 and clarified language in the same section. 390 - Added more description to the session state transi- 391 tions in Chapter 6. 392 - Several changes in Chapter 7 corresponding to the 393 new task management function "reassign". Other 394 language changes in Chapter 7 for better descrip- 395 tion. Format errors are mandated to cause session 396 failures. 397 - Renamed the erstwhile error recovery levels as 398 error recovery classes, and renamed "within-ses- 399 sion" recovery to "connection recovery" to better 400 reflect the mechanics. 402 Julian Satran Expires August 2002 8 404 iSCSI 20-January-02 406 - Added Section 7.12 Error Recovery Hierarchy to 407 define the error recovery hierarchy. 408 - Modifications to error recovery algorithms in 409 Appendix F. 410 - Added a new Reject reason code "Invalid SNACK", 411 added DataSN to Reject PDU. 412 - Changed Section 10.17 Reject to use the "Invalid 413 SNACK" reason code. 414 - Removed a Logout reason code in Section 10.14 415 Logout Request to be consistent with Section 10.9 416 Asynchronous Message. 417 - Collapsed the two event fields in Async Event and 418 added vendor specific event 419 - Immediate data can be negotiated anytime (consis- 420 tency) 421 - Removed replay as a protocol notion and all refer- 422 ences to it 423 - SNACK RunLength 0 means all 424 - Cleaning the bookmark mechanism for text 425 - New T10 approved ASC/ASQ codes 426 - Added a incipient definitions section - thanks to 427 Eddy Quicksall 428 - Change OpParmReset from yes/no to default/current 429 - Added Base64 to encode large strings 430 - The 255 limit for key values is now "unless speci- 431 fied otherwise" 432 - Cleaned SNACK format 433 - Removed ExpR2TSN from SCSI command response it is 434 too late 435 - MaxBurstSize/FirstBurstSize back as key=value 436 - Removed LogoutLoginMinTime (value provided in 437 exchange) 438 - Clear language on component function in generating 439 ISID/TSID 440 - Negotiation breaking is done through abort/reject 441 - Removed all iSCSI mode pages 443 The following changes were made from draft-ietf-ips- 444 iSCSI-06 to draft-ietf-ips-iSCSI-07: 446 - Clarified the "fate" of immediate commands and 447 resources mandated (1.2.2.1) and introduced a 448 reject-code for rejected immediate commands 449 - Clarify CmdSN handling and checking order for ITT 450 and CmdSN 1.2.2.1 451 - Added a statement to the effect that a receiver 452 must be able to accept 0 length Data Segments to 453 2.7.6. Added also a statement to 2.2.1 that a zero- 454 length data segment implies a zero-length digest 456 Julian Satran Expires August 2002 9 458 iSCSI 20-January-02 460 - SCSI MODE SELECT will not really set the parameters 461 (will not cause an error either). The parameters 462 will be set exclusively with text mode and can be 463 retrieved with either text or Mode-SENSE. This 464 enables us to disable their change after the Login 465 negotiation. Also added to the negotiation (1.2.4) 466 the value "?" with special meaning of enquiry 467 - Changed "task" to "command" wherever relevant 468 - EMDP usage in line with other SCSI protocols. EMDP 469 governs how a target may request data and deliver. 470 Similar to FCP a separate (protocol) parameter gov- 471 erns data PDU ordering within Sequence (DataPDU- 472 InOrder). Cleaned wording of DataOrder. Fixed final 473 bit to define sequences in input stream. 474 - Added a "persistent state" part (1.2.8) 475 - Some Task Management commands may require authori- 476 zation or may not be implemented. If not authorized 477 they will return as if executed with a qualifier 478 indicating "not authorized" or "not implemented" 479 (clear LU and the resets) 480 - Task management commands and responses are "gener- 481 alized" to all iSCSI tagged commands (they are 482 named now Task Management command and response). 483 Their behavior with respect to their CmdSN is clar- 484 ified and mandated 485 - The logic to update ExpCmdSN etc. moved to 1.2.2.1 486 - Explicitly specified that a target can "initiate" 487 negotiating a parameter (offering)(1.2.4) 488 - Returned the "direction" bit and a set of codes 489 similar to version 05 490 - Introduced a "special" session type (CopyMan- 491 agerSession) to be used between a Copy Manager and 492 all of its target; it may help define authentica- 493 tion and limit the type f commands to be executed 494 in such a session 495 - Added 8.4 - How to Abort Safely a Command that Was 496 Not Received 497 - Fixed the Logout Text 498 - AHSLength is now the first field in the AHS 499 - Fixed wording in 2.35 indicating AHS is mandatory 500 for Bi-directional commands 501 - All key=value responses have to be explicit (none, 502 not-understood etc.); no more selection by hiatus 503 - Targets can also offer key=value pairs (i.e., ini- 504 tiate negotiation) stated explicitly in 2.9.3 505 - Logout has a CmdSN field 506 - The Status SNACK can be discarded if the target has 507 no such recovery 508 - Some parameters have been removed and replaced by 509 "reasonable" defaults (read arbitrary defaults!); 511 Julian Satran Expires August 2002 10 513 iSCSI 20-January-02 515 many others can't be changed anymore while the ses- 516 sion is in full-feature phase 517 - NOP-Out specifies how LUN is generated when used 518 (copied from NOP-In) 519 - Initial Marker-Less Interval is not a parameter 520 anymore 521 - A response with F=1 during negotiation may not con- 522 tain key=value pairs that may require additional 523 answers from the initiator 524 - Clarified the meaning of the F bit on Write com- 525 mands with regard to immediate and unsolicited 526 data; F bit 0 means that unsolicited data will fol- 527 low while F bit 1 means that this is the last of 528 them (if any) 529 - You can have both immediate and unsolicited Data- 530 Out PDUs 531 - DataPDULength and FirstBurstSize of 0 are allowed 532 and mean unlimited length 533 - Task management command behavior relative to their 534 own CmdSN is now stated in no uncertain terms (they 535 are mandated to execute as if issued at CmdSN and, 536 in case of aborts and clear/reset no additional 537 response/status is expected for those commands 538 after the task management command response 539 - DataSN field in R2T renamed as R2TSN (better 540 reflects semantics) and SNACK explicitly says that 541 it requests Data or R2T. 542 - A session can have only one outstanding text 543 request (not sequence) 544 - Text for Login Response 0301 changed (removed the 545 maintenance mention) 546 - Clarified when ExpDataSN is reserved in SCSI 547 Response 548 - Clarified the text and parameter (timers) for iSCSI 549 event 550 - Padding bytes should be 0 (2.1) 551 - TotalAHSLength in 2.1.1.1 includes padding 552 - DataSegmentLength in 2.1.1.2 excludes padding 553 - Clarified bits in AHS type 554 - Limit for key/value string lengths (63, 255) in 555 2.8.3 556 - Added an example of SCSI event to Asynchronous Mes- 557 sage 558 - Changed "Who" to "Who can send" in appendix 559 - Clarified meaning of parameters on 2.18.1 - Asyn- 560 chronous Message - iSCSI Event 561 - Clarified the required initiator behavior at logout 562 (not sending other commands) and how one expects 563 the TCP close to be performed in 2.14 565 Julian Satran Expires August 2002 11 567 iSCSI 20-January-02 569 - Added a Login Response code indicating that a ses- 570 sion can't include a given connection (0208) 571 - Clarified transition to full feature phase (per 572 session and per connection and the role of the 573 leading connection) in 1.2.5 574 - Corrected "one outstanding text request per connec- 575 tion" instead of "per session" 576 - For the Login Response TSID must be valid only if 577 Login is accepted and the F bit is 1 578 - Added examples illustrating DataSN and R2TSN (from 579 Eddy Quicksall) 580 - Added more text to the task management command 2.5 581 - Removed EnableACA and its dependents (in task man- 582 agement) and stated the requirement for a Unit 583 Attention conform to SAM2 584 - iSCSI Target Name if used on a connection other 585 than the first must be the same as on the first 586 (4.1) 587 - Fixed the examples in the Login appendix to corre- 588 spond to the new keys 589 - Fixed SCSI Response Flags and made them consistent 590 with the Data-In PDU 591 - All specified keys except X-* MUST be accepted 592 (2.8.3) 593 - Hexadecimal notation is 0xab123cd (not 0x'ab123cd') 594 - Clarified CmdSN usage in immediate commands and the 595 meaning of "execution engine" in 1.2.2.1 596 - Reject response that prevent the creation of a SCSI 597 task or result in a SCSI task being terminated must 598 be followed by a SCSI Response with a Check Condi- 599 tion status 2.19.1 600 - Additional Runs (AddRuns) dropped from the SNACK 601 request (too complex). With it disappeared also the 602 implicit acknowledgement of sequences "between 603 runs" 604 - PDUs delivered because of SNACK will be exact rep- 605 licas of the original PDUs (including all flags) 606 2.16 607 - Added CommandReplaySupport key to negotiate support 608 for full command replay (a command can be replayed 609 after the status has been issued but has not been 610 acknowledged) and a reject cause of unsupported 611 command reply 612 - Added CommandFailoverSupport key to negotiate sup- 613 port for command allegiance change (command retry 614 on another connection) 615 - Status SNACK for an acknowledged status is a proto- 616 col error (cause for reject) 618 Julian Satran Expires August 2002 12 620 iSCSI 20-January-02 622 - Reject cause "Command In Progress" when requesting 623 replay before status is issued and while command is 624 running 625 - Premature SNACKs are silently discarded (2.16) 626 - Status SNACK has to supported only if within com- 627 mand or within connection recovery is supported. If 628 within session recovery is supported SNACK can be 629 discarded and followed by an Async. Message 630 requesting logout 631 - StatSN added to Logout Response 632 - Added "CID not found" to Logout Response reason 633 codes 634 - Async Message - iSCSI event 2 (request logout) has 635 to be sent on the connection to be dropped. Wording 636 fixed. 637 - Naming changes - iqn (stands for iSCSI qualified 638 name) introduced as a replacement to fqn. Iqn pre- 639 fixes also reversed names 640 - text in 8.3 revised (task management implementation 641 mechanism) 642 - Fixed bit 7 byte 1 in Task Management response to 1 643 (consistency) 644 - Clarified in 1.2.2 behavior when "command window" 645 is 0 (MaxCmdSN = ExpCmdSN -1) 646 - Added state transitions part (new part 6) 647 - Refreshed recovery chapter (new part 7) 648 - Added an appendix with detailed recovery mechanisms 649 (Appendix E) 650 - Added session types a brief explanation in part 1 651 - Added DiscoverySession key and SendTargets appendix 652 - SCSI response made to fit having both a Status and 653 a Response field. Needed for target errors that 654 result in a check condition and ACA. In line with 655 SAM2 that requires both fields (former versions 656 where modeled on FCP). 657 - The security appendix list SRP as mandatory to 658 implement 659 - Clarified initial CmdSN and the role of TSID as a 660 serializer 661 - Long Text Responses - additional fields added to 662 the text request and text response 663 - Added a SCSI to iSCSI concept mapping section 1.5 664 - Clarified SNACK wording to indicate that in general 665 command. Request, iSCSI command and iSCSI command 666 have the same meaning. Also status, response or 667 numbered response. 668 - Changed InitStatSN and clarified how it increases 669 - Added requirement for a 0x00 delimiter after each 670 key=value 672 Julian Satran Expires August 2002 13 674 iSCSI 20-January-02 676 - Added binary negotiations (yes|no) explicitly to 677 1.2.4 678 - All keys and values in the spec are case sensitive 679 (stated in the text request) 680 - Changed the "operational parameters sent before the 681 security. MAY be discarded" into MUST be discarded 682 - Changed the login reject 0201 to read - Security 683 Negotiation Failed 684 - Added to 2.3.1 a paragraph about mandatory consis- 685 tencies 686 - Stated clearly that F bit pairing is "local" (per/ 687 pair) and not per negotiation 688 - Clarified dependent parameter status 689 - Added CRC Example 690 - Added OpParmReset=yes 691 - SecurityContextComplete is mandatory if any option 692 offered 693 - Added a warning about the implications of not send- 694 ing all unsolicited data to part 8 695 - Added a recommendation to send unsolicited data at 696 FirstBurstSize and a response (error) for targets 697 not supporting less 698 - Many more minor editorial changes, clarifications, 699 typos etc. 700 - Responses in same position in SCSI response, 701 logout, task etc. 703 Table of Contents 705 Julian Satran Expires August 2002 14 707 iSCSI 20-January-02 709 Status of this Memo . . . . . . . . . . . . . . . . . . 2 710 Abstract . . . . . . . . . . . . . . . . . . . . . . . . 2 711 Acknowledgements . . . . . . . . . . . . . . . . . . . . 2 712 Conventions used in this document . . . . . . . . . . . 4 713 Change Log . . . . . . . . . . . . . . . . . . . . . . . 4 714 1. Definitions . . . . . . . . . . . . . . . . . . . . . 22 715 2. Overview . . . . . . . . . . . . . . . . . . . . . . 27 716 2.1 SCSI Concepts . . . . . . . . . . . . . . . . . . 27 717 2.2 iSCSI Concepts and Functional Overview . . . . . . 28 718 2.2.1 Layers and Sessions . . . . . . . . . . . . . 29 719 2.2.2 Ordering and iSCSI Numbering . . . . . . . . . 30 720 2.2.2.1 Command Numbering and Acknowledging . . . 30 721 2.2.2.2 Response/Status Numbering and Acknowledging 722 34 723 2.2.2.3 Data Sequencing . . . . . . . . . . . . . 34 724 2.2.3 iSCSI Login . . . . . . . . . . . . . . . . . 35 725 2.2.4 Text Mode Negotiation . . . . . . . . . . . . 36 726 2.2.5 iSCSI Full Feature Phase . . . . . . . . . . . 39 727 2.2.6 iSCSI Connection Termination . . . . . . . . . 41 728 2.2.7 Naming and Addressing . . . . . . . . . . . . 42 729 2.2.8 Persistent State . . . . . . . . . . . . . . . 44 730 2.2.9 Message Synchronization and Steering . . . . . 45 731 2.2.9.1 Rationale . . . . . . . . . . . . . . . . 45 732 2.2.9.2 Synchronization (sync) and Steering Functional 733 Model . . . . . . . . . . . . . . . . . . . . . . . . . 46 734 2.2.9.3 Sync and Steering and Other Encapsulation Lay- 735 ers . . . . . . . . . . . . . . . . . . . . . . . . . . 48 736 2.2.9.4 Sync/Steering and iSCSI PDU Size . . . . 49 737 2.3 iSCSI Session Types . . . . . . . . . . . . . . . 50 738 2.4 SCSI to iSCSI Concepts Mapping Model . . . . . . . 50 739 2.4.1 iSCSI Architecture Model . . . . . . . . . . . 51 740 2.4.2 SCSI Architecture Model . . . . . . . . . . . 55 741 2.4.3 Consequences of the Model . . . . . . . . . . 57 742 2.4.3.1 I_T Nexus State . . . . . . . . . . . . . 58 743 2.4.3.2 SCSI Mode Pages . . . . . . . . . . . . . 58 744 2.5 Request/Response Summary . . . . . . . . . . . . . 59 745 2.5.1 Request/Response types carrying SCSI payload . 59 746 2.5.1.1 SCSI-Command . . . . . . . . . . . . . . 59 747 2.5.1.2 SCSI-Response . . . . . . . . . . . . . . 59 748 2.5.1.3 Task Management Function Request . . . . 60 749 2.5.1.4 Task Management Function Response . . . . 61 750 2.5.1.5 SCSI Data-out and SCSI Data-in . . . . . 61 751 2.5.1.6 Ready To Transfer (R2T) . . . . . . . . . 62 753 Julian Satran Expires August 2002 1 755 iSCSI 20-January-02 757 2.5.1.7 Asynchronous Message . . . . . . . . . . 62 758 2.5.2 Requests/Responses carrying iSCSI Only Payload 63 759 2.5.2.1 Text Request and Text Response . . . . . 63 760 2.5.2.2 Login Request and Login Response . . . . 63 761 2.5.2.3 Logout Request and Response . . . . . . . 64 762 2.5.2.4 SNACK Request . . . . . . . . . . . . . 65 763 2.5.2.5 Reject . . . . . . . . . . . . . . . . . 65 764 2.5.2.6 NOP-Out Request and NOP-In Response . . . 65 765 3. SCSI Mode Parameters for iSCSI . . . . . . . . . . . 67 766 4. Login Phase . . . . . . . . . . . . . . . . . . . . . 68 767 4.1 Login Phase Start . . . . . . . . . . . . . . . . 70 768 4.2 iSCSI Security Negotiation . . . . . . . . . . . . 72 769 4.3 Operational Parameter Negotiation During the Login 770 Phase . . . . . . . . . . . . . . . . . . . . . . . . . 73 771 5. Operational Parameter Negotiation Outside the Login Phase 772 75 773 6. State Transitions . . . . . . . . . . . . . . . . . . 77 774 6.1 Standard Connection State Diagrams . . . . . . . . 77 775 6.1.1 Standard Connection State Diagram for an Initiator 776 77 777 6.1.2 Standard Connection State Diagram for a Target 79 778 6.1.3 State Descriptions for Initiators and Targets 81 779 6.1.4 State Transition Descriptions for Initiators and 780 Targets . . . . . . . . . . . . . . . . . . . . . . . . 82 781 6.2 Connection Cleanup State Diagram for Initiators and 782 Targets . . . . . . . . . . . . . . . . . . . . . . . . 86 783 6.2.1 State Descriptions for Initiators and Targets 87 784 6.2.2 State Transition Descriptions for Initiators and 785 Targets . . . . . . . . . . . . . . . . . . . . . . . . 88 786 6.3 Session State Diagram . . . . . . . . . . . . . . 90 787 6.3.1 Session State Diagram for an Initiator . . . . 90 788 6.3.2 Session State Diagram for a Target . . . . . . 91 789 6.3.3 State Descriptions for Initiators and Targets 92 790 6.3.4 State Transition Descriptions for Initiators and 791 Targets . . . . . . . . . . . . . . . . . . . . . . . . 93 792 7. iSCSI Error Handling and Recovery . . . . . . . . . . 95 793 7.1 Retry and Reassign in Recovery . . . . . . . . . . 95 794 7.1.1 Usage of Retry . . . . . . . . . . . . . . . . 95 795 7.1.2 Allegiance Reassignment . . . . . . . . . . . 96 796 7.2 Usage Of Reject PDU in Recovery . . . . . . . . . 97 797 7.3 Format Errors . . . . . . . . . . . . . . . . . . 97 798 7.4 Digest Errors . . . . . . . . . . . . . . . . . . 98 799 7.5 Sequence Errors . . . . . . . . . . . . . . . . . 99 801 Julian Satran Expires August 2002 2 803 iSCSI 20-January-02 805 7.6 SCSI Timeouts . . . . . . . . . . . . . . . . . 100 806 7.7 Negotiation Failures . . . . . . . . . . . . . . 101 807 7.8 Protocol Errors . . . . . . . . . . . . . . . . 102 808 7.9 Connection Failures . . . . . . . . . . . . . . 102 809 7.10 Session Errors . . . . . . . . . . . . . . . . 103 810 7.11 Recovery Classes . . . . . . . . . . . . . . . 103 811 7.11.1 Recovery Within-command . . . . . . . . . . 104 812 7.11.2 Recovery Within-connection . . . . . . . . 105 813 7.11.3 Connection Recovery . . . . . . . . . . . . 106 814 7.11.4 Session Recovery . . . . . . . . . . . . . 107 815 7.12 Error Recovery Hierarchy . . . . . . . . . . . 107 816 8. Security Considerations . . . . . . . . . . . . . . 111 817 8.1 iSCSI Security Mechanisms . . . . . . . . . . . 111 818 8.2 In-band Initiator-Target Authentication . . . . 112 819 8.3 IPsec . . . . . . . . . . . . . . . . . . . . . 113 820 8.3.1 Data Integrity and Authentication . . . . . 113 821 8.3.2 Confidentiality . . . . . . . . . . . . . . 114 822 8.3.3 Security Associations and Key Management . . 114 823 9. Notes to Implementers . . . . . . . . . . . . . . . 116 824 9.1 Multiple Network Adapters . . . . . . . . . . . 116 825 9.1.1 Conservative Reuse of ISIDs . . . . . . . . 116 826 9.1.2 iSCSI Name and ISID/TSID Use . . . . . . . . 117 827 9.2 Autosense and Auto Contingent Allegiance (ACA) . 119 828 9.3 Command Retry and Cleaning Old Command Instances 119 829 9.4 Synch and Steering Layer and Performance . . . . 120 830 9.5 Unsolicited Data and Performance . . . . . . . . 120 831 10. iSCSI PDU Formats . . . . . . . . . . . . . . . . 121 832 10.1 iSCSI PDU Length and Padding . . . . . . . . . 121 833 10.2 PDU Template, Header, and Opcodes . . . . . . . 121 834 10.2.1 Basic Header Segment (BHS) . . . . . . . . 123 835 10.2.1.1 I . . . . . . . . . . . . . . . . . . 124 836 10.2.1.2 Opcode . . . . . . . . . . . . . . . . 125 837 10.2.1.3 Opcode-specific Fields . . . . . . . . 126 838 10.2.1.4 TotalAHSLength . . . . . . . . . . . . 126 839 10.2.1.5 DataSegmentLength . . . . . . . . . . 126 840 10.2.1.6 LUN . . . . . . . . . . . . . . . . . 126 841 10.2.1.7 Initiator Task Tag . . . . . . . . . . 126 842 10.2.2 Additional Header Segment (AHS) . . . . . . 126 843 10.2.2.1 AHSType . . . . . . . . . . . . . . . 127 844 10.2.2.2 AHSLength . . . . . . . . . . . . . . 127 845 10.2.2.3 Extended CDB AHS . . . . . . . . . . . 127 846 10.2.2.4 Bidirectional Expected Read-Data Length AHS 847 128 849 Julian Satran Expires August 2002 3 851 iSCSI 20-January-02 853 10.2.3 Header Digest and Data Digest . . . . . . . 129 854 10.2.4 Data Segment . . . . . . . . . . . . . . . 129 855 10.3 SCSI Command . . . . . . . . . . . . . . . . . . 130 856 10.3.1 Flags and Task Attributes (byte 1) . . . . 132 857 10.3.2 CRN . . . . . . . . . . . . . . . . . . . . 133 858 10.3.3 CmdSN - Command Sequence Number . . . . . . 133 859 10.3.4 ExpStatSN . . . . . . . . . . . . . . . . . 133 860 10.3.5 Expected Data Transfer Length . . . . . . . 133 861 10.3.6 CDB - SCSI Command Descriptor Block . . . . 134 862 10.3.7 Data Segment - Command Data . . . . . . . . 134 863 10.4 SCSI Response . . . . . . . . . . . . . . . . . 135 864 10.4.1 Flags (byte 1) . . . . . . . . . . . . . . 137 865 10.4.2 Status . . . . . . . . . . . . . . . . . . 138 866 10.4.3 Response . . . . . . . . . . . . . . . . . 138 867 10.4.4 Residual Count . . . . . . . . . . . . . . 141 868 10.4.5 Bidirectional Read Residual Count . . . . . 141 869 10.4.6 Data Segment - Sense and Response Data Segment 870 141 871 10.4.6.1 SenseLength . . . . . . . . . . . . . 142 872 10.4.7 ExpDataSN . . . . . . . . . . . . . . . . . 142 873 10.4.8 StatSN - Status Sequence Number . . . . . . 142 874 10.4.9 ExpCmdSN - Next Expected CmdSN from this Initiator 875 143 876 10.4.10 MaxCmdSN - Maximum CmdSN Acceptable from this 877 Initiator . . . . . . . . . . . . . . . . . . . . . . 143 878 10.5 Task Management Function Request . . . . . . . . 144 879 10.5.1 Function . . . . . . . . . . . . . . . . . 145 880 10.5.2 LUN . . . . . . . . . . . . . . . . . . . . 147 881 10.5.3 Referenced Task Tag . . . . . . . . . . . . 147 882 10.5.4 RefCmdSN or ExpDataSN . . . . . . . . . . . 148 883 10.6 Task Management Function Response . . . . . . . 149 884 10.6.1 Response . . . . . . . . . . . . . . . . . 151 885 10.6.2 Referenced Task Tag . . . . . . . . . . . . 152 886 10.7 SCSI Data-out & SCSI Data-in . . . . . . . . . . 153 887 10.7.1 F (Final) Bit . . . . . . . . . . . . . . . 157 888 10.7.2 A (Acknowledge) bit . . . . . . . . . . . . 158 889 10.7.3 Target Transfer Tag . . . . . . . . . . . . 158 890 10.7.4 StatSN . . . . . . . . . . . . . . . . . . 158 891 10.7.5 DataSN . . . . . . . . . . . . . . . . . . 159 892 10.7.6 Buffer Offset . . . . . . . . . . . . . . . 159 893 10.7.7 DataSegmentLength . . . . . . . . . . . . . 159 894 10.7.8 Flags (byte 1) . . . . . . . . . . . . . . 160 895 10.8 Ready To Transfer (R2T) . . . . . . . . . . . . 161 897 Julian Satran Expires August 2002 4 899 iSCSI 20-January-02 901 10.8.1 R2TSN . . . . . . . . . . . . . . . . . . . 163 902 10.8.2 StatSN . . . . . . . . . . . . . . . . . . 163 903 10.8.3 Desired Data Transfer Length and Buffer Offset 904 163 905 10.8.4 Target Transfer Tag . . . . . . . . . . . . 164 906 10.9 Asynchronous Message . . . . . . . . . . . . . . 165 907 10.9.1 AsyncEvent . . . . . . . . . . . . . . . . 167 908 10.9.2 AsyncVCode . . . . . . . . . . . . . . . . 169 909 10.9.3 Sense Data or iSCSI Event Data . . . . . . 169 910 10.10 Text Request . . . . . . . . . . . . . . . . . 170 911 10.10.1 F (Final) Bit . . . . . . . . . . . . . . 172 912 10.10.2 Initiator Task Tag . . . . . . . . . . . . 172 913 10.10.3 Target Transfer Tag . . . . . . . . . . . 172 914 10.10.4 Text . . . . . . . . . . . . . . . . . . . 173 915 10.11 Text Response . . . . . . . . . . . . . . . . . 175 916 10.11.1 F (Final) Bit . . . . . . . . . . . . . . 177 917 10.11.2 Initiator Task Tag . . . . . . . . . . . . 178 918 10.11.3 Target Transfer Tag . . . . . . . . . . . 178 919 10.11.4 Text Response Data . . . . . . . . . . . . 178 920 10.12 Login Request . . . . . . . . . . . . . . . . . 180 921 10.12.1 T (Transit) Bit . . . . . . . . . . . . . 182 922 10.12.2 X - Restart Connection . . . . . . . . . . 182 923 10.12.3 CSG and NSG . . . . . . . . . . . . . . . 183 924 10.12.4 Version-max . . . . . . . . . . . . . . . 183 925 10.12.5 Version-min . . . . . . . . . . . . . . . 184 926 10.12.6 ISID . . . . . . . . . . . . . . . . . . . 184 927 10.12.7 TSID . . . . . . . . . . . . . . . . . . . 185 928 10.12.8 Connection ID - CID . . . . . . . . . . . 185 929 10.12.9 CmdSN . . . . . . . . . . . . . . . . . . 186 930 10.12.10 ExpStatSN . . . . . . . . . . . . . . . . 186 931 10.12.11 Login Parameters . . . . . . . . . . . . 186 932 10.13 Login Response . . . . . . . . . . . . . . . . 187 933 10.13.1 Version-max . . . . . . . . . . . . . . . 189 934 10.13.2 Version-active . . . . . . . . . . . . . . 189 935 10.13.3 TSID . . . . . . . . . . . . . . . . . . . 190 936 10.13.4 StatSN . . . . . . . . . . . . . . . . . . 190 937 10.13.5 Status-Class and Status-Detail . . . . . . 190 938 10.13.6 T (Transit) bit . . . . . . . . . . . . . 193 939 10.14 Logout Request . . . . . . . . . . . . . . . . 194 940 10.14.1 CID . . . . . . . . . . . . . . . . . . . 197 941 10.14.2 ExpStatSN . . . . . . . . . . . . . . . . 197 942 10.14.3 Reason Code . . . . . . . . . . . . . . . 197 943 10.15 Logout Response . . . . . . . . . . . . . . . . 198 945 Julian Satran Expires August 2002 5 947 iSCSI 20-January-02 949 10.15.1 Response . . . . . . . . . . . . . . . . . 200 950 10.15.2 Time2Wait . . . . . . . . . . . . . . . . 200 951 10.15.3 Time2Retain . . . . . . . . . . . . . . . 200 952 10.16 SNACK Request . . . . . . . . . . . . . . . . 202 953 10.16.1 Type . . . . . . . . . . . . . . . . . . . 203 954 10.16.2 BegRun . . . . . . . . . . . . . . . . . . 204 955 10.16.3 RunLength . . . . . . . . . . . . . . . . 204 956 10.17 Reject . . . . . . . . . . . . . . . . . . . . 206 957 10.17.1 Reason . . . . . . . . . . . . . . . . . . 207 958 10.17.2 DataSN . . . . . . . . . . . . . . . . . . 210 959 10.17.3 Complete Header of Bad PDU . . . . . . . . 210 960 10.18 NOP-Out . . . . . . . . . . . . . . . . . . . . 211 961 10.18.1 Initiator Task Tag . . . . . . . . . . . . 212 962 10.18.2 Target Transfer Tag . . . . . . . . . . . 213 963 10.18.3 Ping Data . . . . . . . . . . . . . . . . 213 964 10.19 NOP-In . . . . . . . . . . . . . . . . . . . . 214 965 10.19.1 Target Transfer Tag . . . . . . . . . . . 215 966 10.19.2 LUN . . . . . . . . . . . . . . . . . . . 216 967 11. iSCSI Security Keys and Values . . . . . . . . . . 217 968 11.1 AuthMethod . . . . . . . . . . . . . . . . . . 217 969 11.2 Kerberos . . . . . . . . . . . . . . . . . . . 219 970 11.3 Simple Public-Key Mechanism (SPKM) . . . . . . 219 971 11.4 Secure Remote Password (SRP) . . . . . . . . . 221 972 11.5 Challenge Handshake Authentication Protocol (CHAP) 973 222 974 12. Login/Text Operational Keys . . . . . . . . . . . 224 975 12.1 HeaderDigest and DataDigest . . . . . . . . . . 224 976 12.2 MaxConnections . . . . . . . . . . . . . . . . 226 977 12.3 SendTargets . . . . . . . . . . . . . . . . . . 226 978 12.4 TargetName . . . . . . . . . . . . . . . . . . 226 979 12.5 InitiatorName . . . . . . . . . . . . . . . . . 227 980 12.6 TargetAlias . . . . . . . . . . . . . . . . . . 227 981 12.7 InitiatorAlias . . . . . . . . . . . . . . . . 228 982 12.8 TargetAddress . . . . . . . . . . . . . . . . . 228 983 12.9 InitialR2T . . . . . . . . . . . . . . . . . . 229 984 12.10 BidiInitialR2T . . . . . . . . . . . . . . . . 230 985 12.11 ImmediateData . . . . . . . . . . . . . . . . 230 986 12.12 MaxRecvPDULength . . . . . . . . . . . . . . . 232 987 12.13 MaxBurstSize . . . . . . . . . . . . . . . . . 233 988 12.14 FirstBurstSize . . . . . . . . . . . . . . . . 233 989 12.15 LogoutLoginMaxTime . . . . . . . . . . . . . . 233 990 12.16 LogoutLoginMinTime . . . . . . . . . . . . . . 234 991 12.17 MaxOutstandingR2T . . . . . . . . . . . . . . 234 993 Julian Satran Expires August 2002 6 995 iSCSI 20-January-02 997 12.18 DataPDUInOrder . . . . . . . . . . . . . . . . 235 998 12.19 DataSequenceInOrder . . . . . . . . . . . . . 235 999 12.20 ErrorRecoveryLevel . . . . . . . . . . . . . . 236 1000 12.21 SessionType . . . . . . . . . . . . . . . . . 236 1001 12.22 The Vendor Specific Key Format . . . . . . . . 237 1002 13. IANA Considerations . . . . . . . . . . . . . . . 238 1003 References and Bibliography . . . . . . . . . . . . . 239 1004 Authors' Addresses . . . . . . . . . . . . . . . . . . 241 1005 Appendix A. Sync and Steering with Fixed Interval Markers 1006 244 1007 A.1 Markers At Fixed Intervals . . . . . . . . . . . 245 1008 A.2 Initial Marker-less Interval . . . . . . . . . . 245 1009 A.3 Negotiation . . . . . . . . . . . . . . . . . . 246 1010 Appendix B. Sync and Steering with Constant Overhead Word 1011 Stuffing 1012 (COWS) . . . . . . . . . . . . . . . . . . . . . . . . 248 1013 B.4 Negotiation . . . . . . . . . . . . . . . . . . 251 1014 B.5 Sent PDU processing . . . . . . . . . . . . . . 251 1015 B.6 Received PDU processing . . . . . . . . . . . . 251 1016 B.7 Search for framing processing . . . . . . . . . 251 1017 Appendix C. Examples . . . . . . . . . . . . . . . . . 252 1018 C.8 Read Operation Example . . . . . . . . . . . . . 252 1019 C.9 Write Operation Example . . . . . . . . . . . . 253 1020 C.10 R2TSN/DataSN use Examples . . . . . . . . . . . 254 1021 C.11 CRC Examples . . . . . . . . . . . . . . . . . 259 1022 Appendix D. Login Phase Examples . . . . . . . . . . . 261 1023 Appendix E. SendTargets Operation . . . . . . . . . . 271 1024 Appendix F. Algorithmic Presentation of Error Recovery Class- 1025 es . . . . . . . . . . . . . . . . . . . . . . . . . . 276 1026 F.12 General Data Structure and Procedure Description 276 1027 F.13 Within-command Error Recovery Algorithms . . . 278 1028 F.14 Within-connection Recovery Algorithms . . . . . 283 1029 F.14.1.1 Initiator Algorithms . . . . . . . . . . 284 1030 F.14.1.2 Target Algorithms . . . . . . . . . . . 287 1031 F.14.2.1 Procedure Descriptions . . . . . . . . . 287 1032 F.14.2.2 Initiator Algorithms . . . . . . . . . . 288 1033 F.14.2.3 Target Algorithms . . . . . . . . . . . 291 1034 Full Copyright Statement . . . . . . . . . . . . . . . 294 1036 Julian Satran Expires August 2002 7 1038 iSCSI 20-January-02 1040 1. Definitions 1042 - Alias: An alias string could also be associated with an 1043 iSCSI Node. The alias allows an organization to associate 1044 a user-friendly string with the iSCSI Name. However, the 1045 alias string is not a substitute for the iSCSI Name. 1047 - CID (Connection ID): Connections within a session are 1048 identified by a connection ID. It is a unique ID for this 1049 connection within the session for the initiator. It is 1050 generated by the initiator and presented to the target 1051 during login requests and during logouts that close con- 1052 nections. 1054 - Connection: Communication between the initiator and 1055 target occurs over one or more TCP connections. The TCP 1056 connections carry control messages, SCSI commands, param- 1057 eters, and data within iSCSI Protocol Data Units (iSCSI 1058 PDUs). 1060 - iSCSI Initiator Name: The iSCSI Initiator Name specifies 1061 the worldwide unique name of the initiator. 1063 - iSCSI Initiator Node: The "initiator". 1065 - iSCSI Layer: This layer builds/receives iSCSI PDUs and 1066 relays/receives them to/from one or more TCP connections 1067 that form an initiator-target "session". 1069 - iSCSI Name: The name of an iSCSI initiator or iSCSI tar- 1070 get. 1072 - iSCSI Node: The iSCSI Node represents a single iSCSI 1073 initiator or iSCSI target. There are one or more iSCSI 1074 Nodes within a Network Entity. The iSCSI Node is accessi- 1075 ble via one or more Network Portals. An iSCSI Node is 1076 identified by its iSCSI Name. The separation of the iSCSI 1077 Name from the addresses used by and for the iSCSI node 1078 allows multiple iSCSI nodes to use the same addresses, and 1079 the same iSCSI node to use multiple addresses. iSCSI nodes 1080 also have addresses. An iSCSI address specifies a single 1081 path to an iSCSI node. 1083 Julian Satran Expires August 2002 1 1085 iSCSI 20-January-02 1087 - iSCSI Target Name: The iSCSI Target Name specifies the 1088 worldwide unique name of the target. 1090 - iSCSI Target Node: The "target". 1092 - iSCSI Task: An iSCSI task is an iSCSI request for which 1093 a response is expected. 1095 - iSCSI Transfer Direction: The iSCSI transfer direction 1096 is defined with regard to the initiator. Outbound or out- 1097 going transfers are transfers from the initiator to the 1098 target, while inbound or incoming transfers are from the 1099 target to the initiator. 1101 - I_T nexus: According to [SAM2], the I_T nexus is a rela- 1102 tionship between a SCSI Initiator Port and a SCSI Target 1103 Port. For iSCSI, this relationship is a session, defined 1104 as a relationship between an iSCSI Initiator's end of ses- 1105 sion (SCSI Initiator Port) and the iSCSI Target's Portal 1106 Group. The I_T nexus can be identified by the conjunction 1107 of the SCSI port names; that is, the I_T nexus identifier 1108 is the tuple (iSCSI Initiator Name + 'i'+ ISID, iSCSI Tar- 1109 get Name + 't'+ Portal Group Tag). NOTE: The I_T nexus 1110 identifier is not equal to the session identifier (SSID). 1112 - Network Entity: The Network Entity represents a device 1113 or gateway that is accessible from the IP network. A Net- 1114 work Entity must have one or more Network Portals, each of 1115 which can be used to gain access to the IP network by some 1116 iSCSI Nodes contained in that Network Entity. 1118 - Network Portal: The Network Portal is a component of a 1119 Network Entity that has a TCP/IP network address and that 1120 may be used by an iSCSI Node within that Network Entity 1121 for the connection(s) within one of its iSCSI sessions. A 1122 Network Portal in an initiator is identified by its IP 1123 address. A Network Portal in a target is identified by its 1124 IP address and its listening TCP port. 1126 - Originator - in a negotiation or exchange the party that 1127 initiates the negotiation or exchange. 1129 Julian Satran Expires August 2002 2 1131 iSCSI 20-January-02 1133 - PDU (Protocol Data Unit): The initiator and target 1134 divide their communications into messages. The term 1135 "iSCSI protocol data unit" (iSCSI PDU) is used for these 1136 messages. 1138 - Portal Groups: iSCSI supports multiple connections 1139 within the same session; some implementations will have 1140 the ability to combine connections in a session across 1141 multiple Network Portals. A Portal Group defines a set of 1142 Network Portals within an iSCSI Node that collectively 1143 supports the capability of coordinating a session with 1144 connections spanning these portals. Not all Network Por- 1145 tals within a Portal Group need participate in every ses- 1146 sion connected through that Portal Group. One or more 1147 Portal Groups may provide access to an iSCSI Node. Each 1148 Network Portal as utilized by a given iSCSI Node belongs 1149 to exactly one portal group within that node. 1151 - Portal Group Tag: This simple integer value between 1 1152 and 65535 identifies the Portal Group within an iSCSI 1153 Node. All Network Portals with the same portal group tag 1154 in the context of a given iSCSI Node are in the same Por- 1155 tal Group. 1157 - Responder: In a negotiation or exchange, the party that 1158 responds to the originator of the negotiation or exchange. 1160 - SCSI Device: This is the SAM2 term for an entity that 1161 contains other SCSI entities. For example, a SCSI Initia- 1162 tor Device contains one or more SCSI Initiator Ports and 1163 zero or more application clients; a SCSI Target Device 1164 contains one or more SCSI Target Ports and one or more 1165 logical units. For iSCSI, the SCSI Device is the component 1166 within an iSCSI Node that provides the SCSI functionality. 1167 As such, there can be at most one SCSI Device within a 1168 given iSCSI Node. Access to the SCSI Device can only be 1169 achieved in an iSCSI normal operational session. The SCSI 1170 Device Name is defined to be the iSCSI Name of the node 1171 and its use is mandatory in the iSCSI protocol. 1173 - SCSI Layer: This builds/receives SCSI CDBs (Command 1174 Descriptor Blocks) and relays/receives them with the 1176 Julian Satran Expires August 2002 3 1178 iSCSI 20-January-02 1180 remaining command execute parameters to/from the iSCSI 1181 Layer. 1183 - Session: The group of TCP connections that link an ini- 1184 tiator with a target, form a session (loosely equivalent 1185 to a SCSI I-T nexus). TCP connections can be added and 1186 removed from a session. Across all connections within a 1187 session, an initiator sees one "target image". 1188 - SSID (Session ID): A session is defined by a session ID 1189 that is composed of an initiator part (ISID) and a target 1190 part (TSID). 1192 - SCSI Initiator Port: This maps to the endpoint of an 1193 iSCSI normal operational session. An iSCSI normal opera- 1194 tional session is negotiated through the login process 1195 between an iSCSI initiator node and an iSCSI target node. 1196 At successful completion of this process, a SCSI Initiator 1197 Port is created within the SCSI Initiator Device. The SCSI 1198 Initiator Port Name and SCSI Initiator Port Identifier are 1199 both defined to be the iSCSI Initiator Name together with 1200 (a) a label that identifies it as an initiator port name/ 1201 identifier and (b) the ISID portion of the session identi- 1202 fier. 1204 - SCSI Port: This is the SAM2 term for an entity in a SCSI 1205 Device that provides the SCSI functionality to interface 1206 with a service delivery subsystem or transport. For iSCSI, 1207 the definition of the SCSI Initiator Port and the SCSI 1208 Target Port are different. 1210 - SCSI Port Name: A name made up as UTF-8 characters and 1211 is basically the iSCSI Name + 'i' or 't' + ISID or Portal 1212 Group Tag. 1214 - SCSI Target Port: This maps to an iSCSI Target Portal 1215 Group. 1217 - SCSI Target Port Name and SCSI Target Port Identifier: 1218 These are both defined to be the iSCSI Target Name 1219 together with (a) a label that identifies it as a target 1220 port name/identifier and (b) the portal group tag. 1222 Julian Satran Expires August 2002 4 1224 iSCSI 20-January-02 1226 - TSID (Target Session ID): The TSID is the target 1227 assigned tag for a session with a specific named initiator 1228 that, together with the ISID uniquely identifies a session 1229 with that initiator. 1230 It is given to the target during additional connections 1231 for the same session to identify the associated session. 1233 Julian Satran Expires August 2002 5 1235 iSCSI 20-January-02 1237 1. Overview 1239 1.1 SCSI Concepts 1241 The SCSI Architecture Model-2 [SAM2] describes, in 1242 detail, the architecture of the SCSI family of I/O proto- 1243 cols. This section provides a brief background of the SCSI 1244 architecture and is intended to familiarize readers with 1245 its terminology. 1247 At the highest level, SCSI is a family of interfaces for 1248 requesting services from I/O devices, including hard 1249 drives, tape drives, CD and DVD drives, printers, and 1250 scanners. In SCSI terminology, an individual I/O device is 1251 called a "logical unit" (LU). 1253 SCSI is a client-server architecture. Clients of a SCSI 1254 interface are called "initiators". Initiators issue SCSI 1255 "commands" to request service from a logical unit. The 1256 "device server" on the logical unit accepts SCSI commands 1257 and processes them. 1259 A "SCSI transport" maps the client-server SCSI protocol to 1260 a specific interconnect. Initiators are one endpoint of a 1261 SCSI transport. The "target" is the other endpoint. A tar- 1262 get can contain multiple Logical Units (LUs). Each Logical 1263 Unit has an address within a target called a Logical Unit 1264 Number (LUN). 1266 A SCSI task is a SCSI command or possibly a linked set of 1267 SCSI commands. Some LUs support multiple pending (queued) 1268 tasks, but the queue of tasks is managed by the target. 1269 The target uses an initiator provided "task tag" to dis- 1270 tinguish between tasks. Only one command in a task can be 1271 outstanding at any given time. 1273 Each SCSI command results in an optional data phase and a 1274 required response phase. In the data phase, information 1275 can travel from the initiator to target (e.g., WRITE), 1276 target to initiator (e.g., READ), or in both directions. 1277 In the response phase, the target returns the final status 1278 of the operation, including any errors. A response termi- 1279 nates a SCSI command. 1281 Julian Satran Expires August 2002 1 1283 iSCSI 20-January-02 1285 Command Descriptor Blocks (CDB) are the data structures 1286 used to contain the command parameters that an initiator 1287 hands to a target. The CDB content and structure is 1288 defined by [SAM] and device-type specific SCSI standards. 1290 1.2 iSCSI Concepts and Functional Overview 1292 The iSCSI protocol is a mapping of the SCSI remote proce- 1293 dure invocation model (see [SAM]) over the TCP protocol. 1294 SCSI commands are carried by iSCSI requests and SCSI 1295 responses and status are carried by iSCSI responses. iSCSI 1296 also uses the request response mechanism for iSCSI proto- 1297 col mechanisms. 1299 For the remainder of this document, the terms "initiator" 1300 and "target" refer to "iSCSI initiator node" and "iSCSI 1301 target node", respectively (see Section 1.4.1 iSCSI 1302 Architecture Model) unless otherwise qualified. 1304 In keeping with similar protocols, the initiator and tar- 1305 get divide their communications into messages. This docu- 1306 ment uses the term "iSCSI protocol data unit" (iSCSI PDU) 1307 for these messages. 1309 For performance reasons, iSCSI allows a "phase-collapse". 1310 A command and its associated data may be shipped together 1311 from initiator to target, and data and responses may be 1312 shipped together from targets. 1314 The iSCSI transfer direction is defined with regard to the 1315 initiator. Outbound or outgoing transfers are transfers 1316 from initiator to target, while inbound or incoming trans- 1317 fers are from target to initiator. 1319 An iSCSI task is an iSCSI request for which a response is 1320 expected. 1322 In this document "iSCSI request", "iSCSI command", 1323 request, or (unqualified) command have the same meaning. 1324 Also, unless otherwise specified, status, response, or 1325 numbered response have the same meaning. 1327 Julian Satran Expires August 2002 2 1329 iSCSI 20-January-02 1331 1.2.1 Layers and Sessions 1333 The following conceptual layering model is used to specify 1334 initiator and target actions and how they relate to trans- 1335 mitted and received Protocol Data Units: 1337 -The SCSI layer builds/receives SCSI CDBs (Command 1338 Descriptor Blocks) and relays/receives them with 1339 the remaining command execute parameters (cf. SAM2) 1340 to/from ->. 1341 -The iSCSI layer that builds/receives iSCSI PDUs and 1342 relays/receives them to/from one or more TCP con- 1343 nections that form an initiator-target "session". 1345 Communication between the initiator and target occurs 1346 over one or more TCP connections. The TCP connections 1347 carry control messages, SCSI commands, parameters, and 1348 data within iSCSI Protocol Data Units (iSCSI PDUs). The 1349 group of TCP connections that link an initiator with a 1350 target, form a session (loosely equivalent to a SCSI I-T 1351 nexus - see Section 1.4.2 SCSI Architecture Model). A ses- 1352 sion is defined by a session ID that is composed of an 1353 initiator part and a target part. TCP connections can be 1354 added and removed from a session. Connections within a 1355 session are identified by a connection ID (CID). 1357 Across all connections within a session, an initiator sees 1358 one "target image". All target identifying elements, such 1359 as LUN, are the same. In addition, a target sees one "ini- 1360 tiator image" across all connections within a session. 1361 Initiator that identifying elements, such as the Initia- 1362 tor Task Tag, can be used to identify the same entity 1363 regardless of the connection on which they are sent or 1364 received. 1366 iSCSI targets and initiators MUST support at least one TCP 1367 connection and MAY support several connections in a ses- 1368 sion. For error recovery purposes, targets and initiators 1369 that support a single active connection in a session may 1370 have to support two connections during recovery. 1372 Julian Satran Expires August 2002 3 1374 iSCSI 20-January-02 1376 1.2.2 Ordering and iSCSI Numbering 1378 iSCSI uses Command and Status numbering schemes and a Data 1379 sequencing scheme. 1381 Command numbering is session-wide and is used for ordered 1382 command delivery over multiple connections. It can also be 1383 used as a mechanism for command flow control over a ses- 1384 sion. 1386 Status numbering is per connection and is used to enable 1387 missing status detection and recovery in the presence of 1388 transient or permanent communication errors. 1390 Data sequencing is per command or part of a command (R2T 1391 triggered sequence) and is used to detect missing data 1392 and/or R2T PDUs due to header digest errors. 1394 Typically, fields in the iSCSI PDUs communicate the 1395 Sequence Numbers between the initiator and target. During 1396 periods when traffic on a connection is unidirectional, 1397 iSCSI NOPOut/In PDUs may be utilized to synchronize the 1398 command and status ordering counters of the target and 1399 initiator. 1401 1.2.2.1 Command Numbering and Acknowledging 1403 iSCSI supports ordered command delivery within a session. 1404 All commands (initiator-to-target PDUs) are numbered. 1406 Many SCSI activities are related to a task (SAM2). The 1407 task is identified by the Initiator Task Tag for the life 1408 of the task. 1410 Commands in transit from the initiator to the target are 1411 numbered by iSCSI; the number is carried by the iSCSI PDU 1412 as CmdSN (Command-Sequence-Number). The numbering is ses- 1413 sion-wide. Outgoing iSCSI request PDUs carry this number. 1414 The iSCSI initiator allocates CmdSNs with a 32-bit 1415 unsigned counter (modulo 2**32). Comparisons and arith- 1416 metic on CmdSN SHOULD use Serial Number Arithmetic as 1417 defined in [RFC1982] where SERIAL_BITS = 32. 1419 Julian Satran Expires August 2002 4 1421 iSCSI 20-January-02 1423 Commands meant for immediate delivery are marked with an 1424 immediate delivery flag; they also carry CmdSN. CmdSN does 1425 not advance for commands marked for immediate delivery. 1427 Command numbering starts with the first login request on 1428 the first connection of a session (the leading login on 1429 the leading connection) and command numbers are incre- 1430 mented by 1 for every non-immediate command issued after- 1431 wards. 1433 If immediate delivery is used with task management com- 1434 mands, these commands may reach the target task management 1435 before the tasks on which they are supposed to act. How- 1436 ever, their CmdSN is a marker of their position in the 1437 stream of commands. The task management command MUST carry 1438 the CmdSN that is given to the next non-immediate command. 1439 The initiator and target must ensure that the task manage- 1440 ment commands act as specified by SAM2. For example, both 1441 commands and responses appear as if delivered in order. 1443 Beyond the scope of this document is the means by which 1444 one may request immediate delivery for a command or by 1445 which iSCSI decides by itself to mark a PDU for immediate 1446 delivery. 1448 The number of commands used for immediate delivery is not 1449 limited and their delivery to execution is not acknowl- 1450 edged through the numbering scheme. Immediate commands 1451 can be rejected by the iSCSI target due to a lack of 1452 resources. An iSCSI target MUST be able to handle at least 1453 one immediate task management command and one immediate 1454 non-task-management iSCSI request per connection at any 1455 time. 1457 With the exception of the commands marked for immediate 1458 delivery, the iSCSI target layer MUST deliver the commands 1459 for execution in the order specified by CmdSN. Commands 1460 marked for immediate delivery may be handed over by the 1461 iSCSI target layer for execution as soon as detected. 1462 iSCSI may avoid delivering some commands for execution if 1463 required by a prior SCSI or iSCSI action (e.g., clear task 1464 set Task Management request received before all the com- 1465 mands on which it was supposed to act). Delivery for exe- 1467 Julian Satran Expires August 2002 5 1469 iSCSI 20-January-02 1471 cution means delivery to the SCSI execution engine or an 1472 iSCSI-SCSI protocol specific execution engine (e.g., for 1473 text requests). 1475 On any given connection, the iSCSI initiator MUST send the 1476 commands in increasing order of CmdSN, except for commands 1477 that are retransmitted due to digest error recovery and 1478 connection recovery. 1480 The initiator and target are assumed to have the following 1481 three registers that are unique session wide and that 1482 define the numbering mechanism: 1484 - CmdSN - the current command Sequence Number, 1485 advanced by 1 on each command shipped except for 1486 commands marked for immediate delivery. CmdsN 1487 always contains the number to be assigned next. 1488 - ExpCmdSN - the next expected command by the tar- 1489 get. The target acknowledges all commands up to, 1490 but not including, this number. The initiator has 1491 to mark the acknowledged commands as such as soon 1492 as a PDU with the corresponding ExpCmdSN is 1493 received. The target iSCSI layer sets the ExpCmdSN 1494 to the largest non-immediate CmdSN that it can 1495 deliver for execution plus 1 (no holes in the CmdSN 1496 sequence). 1497 - MaxCmdSN - the maximum number to be shipped. The 1498 queuing capacity of the receiving iSCSI layer is 1499 MaxCmdSN - ExpCmdSN + 1. 1501 ExpCmdSN and MaxCmdSN are derived from target-to-initia- 1502 tor PDU fields. Comparisons and arithmetic on ExpCmdSN and 1503 MaxCmdSN SHOULD use Serial Number Arithmetic as defined in 1504 [RFC1982] where SERIAL_BITS = 32. 1506 MaxCmdSN and ExpCmdSN fields are processed by the initia- 1507 tor as follows: 1509 -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 1510 (in Serial Arithmetic Sense), they are both 1511 ignored. 1512 -If the PDU MaxCmdSN is less than the local MaxCmdSN 1513 (in Serial Arithmetic Sense), it is ignored; other- 1514 wise, it updates the local MaxCmdSN. 1516 Julian Satran Expires August 2002 6 1518 iSCSI 20-January-02 1520 -If the PDU ExpCmdSN is less than the local ExpCmdSN 1521 (in Serial Arithmetic Sense), it is ignored; other- 1522 wise, it updates the local ExpCmdSN. 1524 This sequence is required since updates may arrive out of 1525 order being that they travel on different TCP connections. 1527 The target MUST NOT transmit a MaxCmdSN that is less than 1528 the last ExpCmdSN. For non-immediate commands, the CmdSN 1529 field can take any value from ExpCmdSN to MaxCmdSN. The 1530 target MUST silently ignore any non-immediate command 1531 outside of this range or non-immediate duplicates within 1532 the range. 1534 iSCSI initiators and targets MUST support the command num- 1535 bering scheme. 1537 A numbered iSCSI request will not change its allocated 1538 CmdSN, regardless of the number of times and circumstances 1539 in which it is reissued. At the target, it is assumed that 1540 CmdSN is relevant only while the command has not created 1541 any state related to its execution (execution state); 1542 afterwards, CmdSN becomes irrelevant. Testing for the 1543 execution state (represented by identifying the Initiator 1544 Task Tag) is assumed to precede any other action at the 1545 target, and is followed by ordering and delivery if no 1546 execution state is found or delivery if an execution state 1547 is found. 1549 When the current value of the CmdSN register is Q, an ini- 1550 tiator MUST not advance CmdSN past R + 2**31 - 1 after 1551 reissuing a command with CmdSN R on a connection while 1552 this connection is operational, unless a new non-immedi- 1553 ate command with CmdSN equal or greater than Q was issued 1554 on the given connection and its reception acknowledged by 1555 the target (see Section 9.3 Command Retry and Cleaning Old 1556 Command Instances). The non-immediate command MUST be 1557 sent in order after the retried command. 1558 A target MUST NOT issue a command response or DATA-In PDU 1559 with status before acknowledging the command. However, 1560 the acknowledgement can be included in the response or 1561 Data-in PDU itself. 1563 Julian Satran Expires August 2002 7 1565 iSCSI 20-January-02 1567 1.2.2.2 Response/Status Numbering and Acknowledging 1569 Responses in transit from the target to the initiator are 1570 numbered. The StatSN (Status Sequence Number) is used for 1571 this purpose. StatSN is a counter maintained per connec- 1572 tion. ExpStatSN is used by the initiator to acknowledge 1573 status. The status sequence number space is 32bit integers 1574 and the arithmetic operations are the regular mod(2**32) 1575 arithmetic. 1577 Status numbering starts with the Login response to the 1578 first Login request of the connection. The Login response 1579 includes an initial value for status numbering (any ini- 1580 tial value is valid). 1582 To enable command recovery, the target MAY maintain enough 1583 state information to enable data and status recovery after 1584 a connection failure. A target can discard all the state 1585 information maintained for recovery after the status 1586 delivery is acknowledged through ExpStatSN. 1588 A large absolute difference between StatSN and ExpStatSN 1589 may indicate a failed connection. Initiators undertake 1590 recovery actions if the difference is greater than an 1591 implementation defined constant that SHOULD NOT exceed 1592 2**31-1. 1594 Initiators and Targets MUST support the response-number- 1595 ing scheme. 1597 1.2.2.3 Data Sequencing 1599 Data and R2T PDUs, transferred as part of some command 1600 execution, MUST be sequenced. The DataSN field is used for 1601 data sequencing. For input (read) data PDUs, DataSN starts 1602 with 0 for the first data PDU of an input command and 1603 advances by 1 for each subsequent data PDU. For output 1604 data PDUs, DataSN starts with 0 for the first data PDU of 1605 a sequence (the initial unsolicited sequence or any data 1606 PDU sequence issued to satisfy an R2T) and advances by 1 1607 for each subsequent data PDU. R2Ts are also sequenced per 1608 command. For example, the first R2T has an R2TSN of 0 and 1609 advances by 1 for each subsequent R2T. For bidirectional 1610 commands, the target uses the DataSN/R2TSN to sequence 1612 Julian Satran Expires August 2002 8 1614 iSCSI 20-January-02 1616 Data-In and R2T PDUs in one continuous sequence (undiffer- 1617 entiated). Unlike command and status, data PDUs and R2Ts 1618 are not acknowledged by a field in regular outgoing PDUs. 1619 Data-In PDUs can be acknowledged on demand by a special 1620 form of the SNACK PDU. Data and R2T PDUs are implicitly 1621 acknowledged by status. The DataSN/R2TSN field enables 1622 the initiator to detect missing data or R2T PDUs. 1624 For any given write command, a target must have issued 1625 less than 2**32 R2Ts. Any input or output data sequence 1626 MUST contain less than 2**32 numbered PDUs. 1628 1.2.3 iSCSI Login 1630 The purpose of the iSCSI login is to enable a TCP connec- 1631 tion for iSCSI use, authenticate the parties, negotiate 1632 the session's parameters and mark the connection as 1633 belonging to an iSCSI session. 1635 A session is used to identify all the connections with a 1636 given initiator that belong to the same I_T nexus to a 1637 target. (See Section 1.4.2 SCSI Architecture Model for 1638 more details on how a session relates to an I_T nexus). 1640 The targets listen on a well-known TCP port or other TCP 1641 port for incoming connections. The initiator begins the 1642 login process by connecting to one of these TCP ports. 1644 As part of the login process, the initiator and target MAY 1645 wish to authenticate each other and set a security associ- 1646 ation protocol for the session. This can occur in many 1647 different ways and is subject to negotiation. 1649 In order to protect the TCP connection, an IPsec security 1650 association MAY be established before the Login request. 1651 Using IPsec security for iSCSI is specified in Chapter 8 1652 and in [SEC-IPS]. 1654 The iSCSI Login Phase is carried through Login requests 1655 and responses. Once suitable authentication has occurred 1656 and operational parameters have been set, the initiator 1657 may start to send SCSI commands. How the target chooses to 1659 Julian Satran Expires August 2002 9 1661 iSCSI 20-January-02 1663 authorize an initiator is beyond the scope of this docu- 1664 ment. A more detailed description of the Login Phase can 1665 be found in Chapter 4. 1667 The login PDU includes a session ID that is composed of an 1668 initiator part ISID and a target part TSID. For a new ses- 1669 sion, the TSID is null. As part of the response, the tar- 1670 get generates a TSID. 1672 During session establishment, the target identifies the 1673 SCSI initiator port (the "I" in the "I_T nexus") through 1674 the value pair (InitiatorName, ISID) (InitiatorName is 1675 described later in this part). Any persistent state (e.g., 1676 persistent reservations) on the target that is associated 1677 with a SCSI initiator port is identified based on this 1678 value pair. Any state associated with the SCSI target port 1679 (the "T" in the "I_T nexus") is identified externally by 1680 the TargetName and portal group tag (see Section 1.4.1 1681 iSCSI Architecture Model) and internally in an implemen- 1682 tation dependent way. As ISID is used to identify a per- 1683 sistent state, it is subject to reuse restrictions (see 1684 Section 1.4.3 Consequences of the Model). 1686 Before the Full Feature Phase is established, only Login 1687 Request and Login Response PDUs are allowed. Any other 1688 PDU, when received at initiator or target, is a protocol 1689 error and MUST result in the connection being terminated. 1691 1.2.4 Text Mode Negotiation 1693 During login, and thereafter, some session or connection 1694 parameters are negotiated through an exchange of textual 1695 information. 1697 The initiator starts the negotiation through a Text/Login 1698 request and indicates when it is ready for completion (by 1699 setting to 1 and keeping to 1 the F bit in a Text Request 1700 or the T bit in the Login Request). 1702 The general format of text negotiation is: 1704 Originator-> = 1706 Julian Satran Expires August 2002 10 1708 iSCSI 20-January-02 1710 Responder-> =|NotUnderstood|Irrelevant 1712 The originator can either be the initiator or the target 1713 and the responder can either be the target or initiator, 1714 respectively. Target requests are not limited to respond 1715 to key=value pairs as offered by the initiator. The target 1716 may offer key=value pairs of its own. 1718 All negotiations are stateless (i.e., the result MUST be 1719 based only on newly exchanged values). Not offering a key 1720 for negotiation is not equivalent to offering the current 1721 (or default) value. 1723 The value can be a number, a single literal constant a 1724 Boolean value (yes or no), or a list of comma separated, 1725 literal constant values. 1727 In literal list negotiation, the originator sends a list 1728 of options (literal constants which may include "None") 1729 for each key in its order of preference. 1731 The responding party answers with the first value that it 1732 supports and is allowed to use for the specific originator 1733 selected from the originator list. 1735 The constant "none" MUST always be used to indicate a 1736 missing function. However, none is a valid selection only 1737 if it is explicitly offered. 1739 If a responder does not support or is not allowed to use 1740 all of the offered options with a specific originator, it 1741 may use the constant "Reject". 1743 For numerical and single literal negotiations, the 1744 responding party MUST respond with the required key. The 1745 value it selects, based on the selection rule specific to 1746 the key, becomes the negotiation result. The selection of 1747 a value not admissible under the selection rules is con- 1748 sidered a protocol error and is handled accordingly. 1750 For Boolean negotiations (keys taking the values yes or 1751 no), the responding party MUST respond with the required 1752 key and the result of the negotiation when the received 1754 Julian Satran Expires August 2002 11 1756 iSCSI 20-January-02 1758 value does not determine that result by itself. The last 1759 value transmitted becomes the negotiation result. The 1760 rules for selecting the value with which to respond are 1761 expressed as Boolean functions of the value received and 1762 the value that the responding party would select in the 1763 absence of knowledge of the received value. 1765 Specifically, the two cases in which responses are 1766 OPTIONAL are: 1768 - The Boolean function is "AND" and the value "no" is 1769 received. The outcome of the negotiation is "no". 1770 - The Boolean function is "OR" and the value "yes" is 1771 received. The outcome of the negotiation is "yes". 1773 Responses are REQUIRED in all other cases, and the value 1774 chosen and sent by the responder becomes the outcome of 1775 the negotiation. 1777 If a specific key is not relevant for the current negoti- 1778 ation, the responder may answer with the constant "Irrel- 1779 evant" for all types of negotiation. 1781 Any other key not understood by the responder may be 1782 ignored by the responder without affecting the basic func- 1783 tion. However, the Text Response for a key not understood 1784 MUST be key=NotUnderstood. 1786 The value "?" with any key has the meaning of enquiry and 1787 should be answered with the current value or 1788 "NotUnderstood". The value "?" MUST be used ONLY in Full 1789 Feature Phase. Whenever the responder has 2 two values 1790 for a key - one for the offering-to-responding-party 1791 direction and a second one for the responding-to-offer- 1792 ing-party direction it will answer with the two values 1793 separated by a comma starting with the requesting-to- 1794 offering-party direction. 1796 The constants "None", "Reject", "Irrelevant", and 1797 "NotUnderstood" are reserved and must only be used as 1798 described here. 1800 Julian Satran Expires August 2002 12 1802 iSCSI 20-January-02 1804 Some basic key=value pairs are described in Chapter 12. 1805 All keys in Chapter 12, except for the X- extension for- 1806 mat, MUST be supported by iSCSI initiators and targets. 1808 Manufacturers may introduce new keys by prefixing them 1809 with X- followed by their (reversed) domain name. For 1810 example the company owning the domain acme.com can issue: 1812 X-com.acme.bar.foo.do_something=3 1814 1.2.5 iSCSI Full Feature Phase 1816 Once the initiator is authorized to do so, the iSCSI ses- 1817 sion is in the iSCSI Full Feature Phase. A session is in 1818 Full Feature Phase after successfully finishing the login 1819 phase on the first (leading) connection of a session. A 1820 connection is in Full Feature Phase if the session is in 1821 Full Feature Phase and the connection login has completed 1822 successfully. An iSCSI connection is not in Full Feature 1823 Phase a) when it does not have an established transport 1824 connection, or b) when it has a valid transport connec- 1825 tion, but a successful login was not performed or the con- 1826 nection is currently logged out. In a normal Full Feature 1827 Phase, the initiator may send SCSI commands and data to 1828 the various LUs on the target by wrapping them in iSCSI 1829 PDUs that go over the established iSCSI session. 1831 For an iSCSI request issued over a TCP connection, the 1832 corresponding response and/or requested PDU(s) MUST be 1833 sent over the same connection by default. We call this 1834 "connection allegiance". If the original connection fails 1835 before the command is completed, the connection alle- 1836 giance of the command may be explicitly reassigned to a 1837 different transport connection as described in detail in 1838 Section 7.1 Retry and Reassign in Recovery. 1840 For SCSI commands that require data and/or a parameter 1841 transfer, the (optional) data and the status for a command 1842 MUST be sent over the same TCP connection to which the 1843 SCSI command is currently allegiant, illustrating the 1844 above rule. 1846 Julian Satran Expires August 2002 13 1848 iSCSI 20-January-02 1850 Thus, if an initiator issues a READ command, the target 1851 MUST send the requested data, if any, followed by the sta- 1852 tus to the initiator over the same TCP connection that was 1853 used to deliver the SCSI command. If an initiator issues a 1854 WRITE command, the initiator MUST send the data, if any, 1855 for that command. The target MUST return Ready To Transfer 1856 (R2T), if any, and the status over the same TCP connection 1857 that was used to deliver the SCSI command. Retransmission 1858 requests (SNACK PDUs) and the data and status that they 1859 generate MUST also use the same connection. 1861 However, consecutive commands that are part of a SCSI 1862 linked command-chain task MAY use different connections. 1863 Connection allegiance is strictly per-command and not 1864 per-task. During the iSCSI Full Feature Phase, the initi- 1865 ator and target MAY interleave unrelated SCSI commands, 1866 their SCSI Data, and responses over the session. 1868 Outgoing SCSI data (initiator to target user data or com- 1869 mand parameters) is sent as either solicited data or unso- 1870 licited data. Solicited data is sent in response to R2T 1871 PDUs. Unsolicited data can be sent as part of an iSCSI 1872 command PDU ("immediate data") or in separate iSCSI data 1873 PDUs. An initiator may send unsolicited data as immediate 1874 up to the negotiated maximum PDU size or in a separate PDU 1875 sequence (up to the mode page limit). All subsequent data 1876 MUST be solicited. The maximum size of an individual data 1877 PDU or the immediate-part of the first unsolicited burst 1878 MAY be negotiated at login. 1880 Targets operate in either solicited (R2T) data mode or 1881 unsolicited (non R2T) data mode. In unsolicited mode, an 1882 initial R2T that allows a transfer up to the FirstBurst- 1883 Size is implied. A target MAY separately enable immediate 1884 data without enabling the more general (separate data 1885 PDUs) form of unsolicited data. 1887 An initiator SHOULD honor an R2T data request for a valid 1888 outstanding command (i.e., carrying a valid Initiator 1889 Task Tag) provided the command is supposed to deliver out- 1890 going data and the R2T specifies data within the command 1891 bounds. 1893 Julian Satran Expires August 2002 14 1895 iSCSI 20-January-02 1897 It is considered an error for an initiator to send unso- 1898 licited data PDUs to a target that operates in R2T mode 1899 (only solicited data is allowed). It is also an error for 1900 an initiator to send more data, whether immediate or as 1901 separate PDUs, than the SCSI limit for first burst. At 1902 login, an initiator MAY request to send data blocks and a 1903 first burst of any size; in this case, the target MUST 1904 indicate the size of the first burst and of the immediate 1905 and data blocks that it is ready to accept. 1907 A target SHOULD NOT silently discard data and request 1908 retransmission through R2T. Initiators SHOULD NOT keep 1909 track of the data transferred to or from the target 1910 (scoreboarding); targets perform residual count calcula- 1911 tion. Incoming data for initiators is always implicitly 1912 solicited. SCSI data packets are matched to their corre- 1913 sponding SCSI commands by using Tags specified in the pro- 1914 tocol. 1916 Initiator tags for pending commands are unique initiator- 1917 wide for a session. Target tags are not strictly specified 1918 by the protocol. It is assumed that these tags are used by 1919 the target to tag (alone or in combination with the LUN) 1920 the solicited data. Target tags are generated by the tar- 1921 get and "echoed" by the initiator. The above mechanisms 1922 are designed to accomplish efficient data delivery and a 1923 large degree of control over the data flow. 1925 iSCSI initiators and targets MUST also enforce some order- 1926 ing rules. Unsolicited data MUST be sent on every connec- 1927 tion in the same order in which commands were sent. A 1928 target that receives data out of order MAY terminate the 1929 session. 1931 1.2.6 iSCSI Connection Termination 1933 An iSCSI connection may be terminated by use of a trans- 1934 port connection shutdown, or a transport reset. Transport 1935 reset is assumed to be an exceptional event. 1937 Graceful TCP connection shutdowns are done by sending TCP 1938 FINs. A graceful transport connection shutdown SHOULD be 1939 initiated by either party only when the connection is not 1941 Julian Satran Expires August 2002 15 1943 iSCSI 20-January-02 1945 in iSCSI full-feature phase. A target MAY terminate a 1946 full-feature phase connection on internal exception 1947 events, but it SHOULD announce the fact through an Asyn- 1948 chronous Message PDU. Connection termination with out- 1949 standing commands may require recovery actions. 1951 If a connection is terminated while in full-feature phase, 1952 connection cleanup (section 6) is required as a prelude to 1953 recovery. By doing connection cleanup before starting 1954 recovery, the initiator and target can avoid receiving 1955 stale PDUs after recovery. In this case, the initiator 1956 sends a Logout request on one of the operational connec- 1957 tions of a session that indicates which iSCSI connection 1958 should be logged out. 1960 1.2.7 Naming and Addressing 1962 All iSCSI initiators and targets are named. Each target or 1963 initiator is known by an iSCSI Name. The iSCSI Name is 1964 independent of the location of the initiator and target; 1965 two formats are provided that allow the use of existing 1966 naming authorities to generate names. 1968 One of these formats allows the use of a registered domain 1969 name as a naming authority; it is important not to 1970 confuse this with an address. The iSCSI Name is a UTF-8 1971 text string and is defined in [NDT]. 1973 iSCSI Names are used to provide: 1975 - An initiator identifier for configurations that 1976 provide multiple initiators behind a single IP 1977 address. 1978 - A target identifier for configurations that present 1979 multiple targets behind a single IP address and 1980 port. 1981 - A method to recognize multiple paths to the same 1982 device on different IP addresses and ports. 1983 - An identifier for source and destination targets 1984 for use in third party commands. 1985 - An identifier for initiators and targets to enable 1986 them to recognize each other regardless of IP 1987 address and port mapping on intermediary firewalls. 1989 Julian Satran Expires August 2002 16 1991 iSCSI 20-January-02 1993 The initiator MUST present both its iSCSI Initiator Name 1994 and the iSCSI Target Name to which it wishes to connect in 1995 the first login request of a new session. The only excep- 1996 tion is if a discovery session (see Section 1.3 iSCSI Ses- 1997 sion Types) is to be established; the iSCSI Initiator Name 1998 is still required, but the iSCSI Target Name may be 1999 ignored. The key "SessionType=Discovery" is sent by the 2000 initiator at login to indicate a discovery session. 2002 The default name "iSCSI" is reserved and is not used as an 2003 individual initiator or target name. 2005 iSCSI Names do not require special handling within the 2006 iSCSI layer; they are opaque and case-sensitive for pur- 2007 poses of comparison. 2009 Examples of iSCSI Names: 2011 iqn.1998-03.com.disk-vendor.diskarrays.sn.45678 2012 iqn.2000-01.com.gateways.yourtargets.24 2013 iqn.1987-06.com.os-vendor.plan9.cdrom.12345 2014 iqn.2001-03.com.service-pro- 2015 vider.users.customer235.host90 2016 eui.02004567A425678D 2018 iSCSI nodes also have addresses. An iSCSI address speci- 2019 fies a single path to an iSCSI node and has the following 2020 format: 2022 [:] 2024 Where is one of: 2026 - IPv4 address, in dotted decimal notation. Assumed 2027 if the name contains exactly four numbers, sepa- 2028 rated by dots (.), where each number is in the 2029 range 0..255. 2030 - IPv6 address, in colon-separated hexadecimal nota- 2031 tion, as specified in [RFC2373] and enclosed in "[" 2032 and "]" characters, as specified in [RFC2732]. 2033 - Fully Qualified Domain Name (host name). Assumed if 2034 the is neither an IPv4 nor an IPv6 2035 address. 2037 Julian Satran Expires August 2002 17 2039 iSCSI 20-January-02 2041 For iSCSI targets, the in the address is optional; 2042 if specified, it is the TCP port on which the target is 2043 listening for connections. If the is not specified, 2044 the default port 3260, assigned by IANA, will be assumed. 2045 For iSCSI initiators, the is omitted. 2047 Examples of addresses: 2049 10.40.1.2 2050 [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210] 2051 [1080:0:0:0:8:800:200C:417A] 2052 [3ffe:2a00:100:7031::1] 2053 [1080::8:800:200C:417A] 2054 [::192.9.5.5] 2055 mydisks.example.com 2057 To assist in providing a more human-readable user inter- 2058 face for devices that contain iSCSI targets and initia- 2059 tors, a target or initiator may also provide an alias. 2060 This alias is a simple UTF-8 string, is not globally 2061 unique, and is never interpreted or used to identify an 2062 initiator or device within the iSCSI protocol. Its use is 2063 described in [NDT]. 2065 Third party commands require that protocol-specific 2066 addresses be communicated within SCSI CDBs. The iSCSI pro- 2067 tocol-specific address consists of an iSCSI name, or an 2068 iSCSI name + TCP address. 2070 An initiator may discover the iSCSI Target Names to which 2071 it has access, along with their addresses, using the Send- 2072 Targets text request, or by other techniques discussed in 2073 [NDT]. 2075 1.2.8 Persistent State 2077 iSCSI does not require any persistent state maintenance 2078 across sessions. However in some cases, SCSI requires per- 2079 sistent identification of the SCSI initiator port name 2080 (for iSCSI, the InitiatorName plus the ISID portion of the 2081 session identifier). (See Section 1.4.2 SCSI Architecture 2082 Model and Section 1.4.3 Consequences of the Model.) 2084 Julian Satran Expires August 2002 18 2086 iSCSI 20-January-02 2088 iSCSI sessions do not persist through power cycles and 2089 boot operations. 2091 All iSCSI session and connection parameters are re-ini- 2092 tialized on session and connection creation. 2094 Commands persist beyond connection termination if the 2095 session persists and command recovery within the session 2096 is supported. However, when a connection is dropped, com- 2097 mand execution, as perceived by iSCSI (i.e., involving 2098 iSCSI protocol exchanges for the affected task), is sus- 2099 pended until a new allegiance is established by the 'task 2100 reassign' task management function. (See Section 10.5 2101 Task Management Function Request.) 2103 1.2.9 Message Synchronization and Steering 2105 1.2.9.1 Rationale 2107 iSCSI presents a mapping of the SCSI protocol onto TCP. 2108 This encapsulation is accomplished by sending iSCSI PDUs 2109 of varying lengths. Unfortunately, TCP does not have a 2110 built-in mechanism for signaling message boundaries at 2111 the TCP layer. iSCSI overcomes this obstacle by placing 2112 the message length in the iSCSI message header. This 2113 serves to delineate the end of the current message as well 2114 as the beginning of the next message. 2116 In situations where IP packets are delivered in order from 2117 the network, iSCSI message framing is not an issue and 2118 messages are processed one after the other. In the pres- 2119 ence of IP packet reordering, (i.e., frames being dropped) 2120 legacy TCP implementations store the "out of order" TCP 2121 segments in temporary buffers until the missing TCP seg- 2122 ments arrive, upon which the data must be copied to the 2123 application buffers. In iSCSI, it is desirable to steer 2124 the SCSI data within these out of order TCP segments into 2125 the pre-allocated SCSI buffers rather than store them in 2126 temporary buffers. This decreases the need for dedicated 2127 reassembly buffers as well as the latency and bandwidth 2128 related to extra copies. 2130 Relying solely on the "message length" information from 2131 the iSCSI message header may make it impossible to find 2133 Julian Satran Expires August 2002 19 2135 iSCSI 20-January-02 2137 iSCSI message boundaries in subsequent TCP segments due to 2138 the loss of a TCP segment that contains the iSCSI message 2139 length. The missing TCP segment(s) must be received before 2140 any of the following segments can be steered to the cor- 2141 rect SCSI buffers (due to the inability to determine the 2142 iSCSI message boundaries). Since these segments cannot be 2143 steered to the correct location, they must be saved in 2144 temporary buffers that must then be copied to the SCSI 2145 buffers. 2147 Different schemes can be used to recover synchronization. 2148 One of these schemes is detailed in Appendix A. - Sync and 2149 Steering with Fixed Interval Markers -. To make these 2150 schemes work, iSCSI implementations have to make sure that 2151 the appropriate protocol layers are provided with enough 2152 information to implement a synchronization and/or data 2153 steering mechanism. 2155 1.2.9.2 Synchronization (sync) and Steering Functional 2156 Model 2158 We assume that iSCSI is implemented according to the fol- 2159 lowing layering scheme: 2161 +------------------------+ 2162 | SCSI | 2163 +------------------------+ 2164 | iSCSI | 2165 +------------------------+ 2166 | Sync and Steering | 2167 | +-------------------+ | 2168 | | TCP | | 2169 | +-------------------+ | 2170 +------------------------+ 2171 | Lower Functional Layers| 2172 | (LFL) | 2173 +------------------------+ 2174 | IP | 2175 +------------------------+ 2176 | Link | 2177 +------------------------+ 2179 Julian Satran Expires August 2002 20 2181 iSCSI 20-January-02 2183 In this model, LFL can be IPsec (a mechanism changing the 2184 IP stream and invisible to TCP). We assume that Sync and 2185 Steering operates just underneath iSCSI. An implementa- 2186 tion may choose to place Sync and Steering somewhere else 2187 in the stack if it can translate the information kept by 2188 iSCSI in terms valid for the chosen layer. 2190 According to our layering model, iSCSI considers the 2191 information it delivers to the Sync and Steering layer 2192 (headers and payloads) as a contiguous stream of bytes 2193 mapped to the positive integers from 0 to infinity. In 2194 practice, though, iSCSI is not expected to handle infi- 2195 nitely long streams; stream addressing will wrap around at 2196 2**32-1. 2198 This model assumes that the iSCSI layer will deliver com- 2199 plete PDUs to underlying layers in single (atomic) opera- 2200 tions. The underlying layer does not need to examine the 2201 stream content to discover the PDU boundaries. If a spe- 2202 cific implementation performs PDU delivery to the Sync and 2203 Steering layer through multiple operations, it MUST 2204 bracket an operation set used to deliver a single PDU in a 2205 manner that the Sync and Steering Layer can understand. 2207 The Sync and Steering Layer (which is OPTIONAL) MUST 2208 retain the PDU end address within the stream for every 2209 delivered iSCSI PDU. 2210 To enable the Sync and Steering operation to perform 2211 Steering, additional information, including identifying 2212 tags and buffer offsets, MUST also be retained for every 2213 sent PDU. The Sync and Steering Layer is required to add 2214 enough information to every sent data item (IP packet, TCP 2215 packet or some other superstructure) to enable the 2216 receiver to steer it to a memory location independent of 2217 any other piece. 2219 If the transmission stream is built dynamically, this 2220 information is used to insert Sync and Steering informa- 2221 tion in the transmission stream (at first transmission or 2222 at re-transmission) either through a globally accessible 2223 table or a call-back mechanism. If the transmission stream 2224 is built statically, the Sync and Steering information is 2226 Julian Satran Expires August 2002 21 2228 iSCSI 20-January-02 2230 inserted in the transmission stream when data are first 2231 presented to sync and steering. 2233 The retained information can be released whenever the 2234 transmitted data is acknowledged by the receiver. (in the 2235 case of dynamically built streams, by deletion from the 2236 global table or by an additional callback). 2238 On the outgoing path, the Sync and Steering layer MUST map 2239 the outgoing stream addresses from iSCSI stream addresses 2240 to TCP stream sequence numbers. 2242 On the incoming path, the Sync and Steering layer extracts 2243 the Sync and Steering information from the TCP stream. It 2244 then helps steer (place) the data stream to its final 2245 location and/or recover iSCSI PDU boundaries when some TCP 2246 packets are lost or received out of order. The data stream 2247 seen by the receiving iSCSI layer is identical to the data 2248 stream that left the sending iSCSI layer. The Sync and 2249 Steering information is kept until the PDUs to which it 2250 refers are completely processed by the iSCSI layer. 2252 On the incoming path, the Sync and Steering layer does not 2253 change the way TCP notifies iSCSI about in-order data 2254 arrival. All data placements, in-order or out-of-order, 2255 performed by the Sync and Steering layer are hidden from 2256 iSCSI while conventional, in order, data arrival notifi- 2257 cations generated by TCP are passed through to iSCSI 2259 1.2.9.3 Sync and Steering and Other Encapsulation Layers 2261 We recognize that in many environments the following is a 2262 more appropriate layering model: 2264 Julian Satran Expires August 2002 22 2266 iSCSI 20-January-02 2268 +----------------------------------+ 2269 | SCSI | 2270 +----------------------------------+ 2271 | iSCSI | 2272 +----------------------------------+ 2273 | Upper Functional Layers (UFL) | 2274 +----------------------------------+ 2275 | Sync and Steering | 2276 | +-----------------------------+ | 2277 | | TCP | | 2278 | +-----------------------------+ | 2279 +----------------------------------+ 2280 | Lower Functional Layers (LFL) | 2281 +----------------------------------+ 2282 | IP | 2283 +----------------------------------+ 2284 | Link | 2285 +----------------------------------+ 2287 In this model, UFL can be TLS (see[RFC2246]) or some other 2288 transport conversion mechanism (a mechanism that changes 2289 the TCP stream, but that is transparent to iSCSI). 2291 To be effective and act on reception of TCP packets out of 2292 order, Sync and Steering has to be underneath UFL, and 2293 Sync and Steering data must be left out of any UFL trans- 2294 formation (encryption, compression, padding etc.). How- 2295 ever, Sync and Steering MUST take into account the 2296 additional data inserted in the stream by UFL. Sync and 2297 Steering MAY also restrict the type of transformations UFL 2298 may perform on the stream. 2300 This makes implementation of Sync and Steering in the 2301 presence of otherwise opaque UFLs less attractive. 2303 1.2.9.4 Sync/Steering and iSCSI PDU Size 2305 When a large iSCSI message is sent, the TCP segment(s) 2306 that contain the iSCSI header may be lost. The remaining 2307 TCP segment(s) up to the next iSCSI message must be buff- 2308 ered (in temporary buffers) since the iSCSI header that 2309 indicates to which SCSI buffers the data is to be steered 2310 was lost. To minimize the amount of buffering, it is rec- 2312 Julian Satran Expires August 2002 23 2314 iSCSI 20-January-02 2316 ommended that the iSCSI PDU size be restricted to a small 2317 value (perhaps a few TCP segments in length). During 2318 login, each end of the iSCSI session specifies the maximum 2319 iSCSI PDU size it will accept. 2321 1.3 iSCSI Session Types 2323 iSCSI defines two types of sessions: 2325 a) Normal operational session - an unrestricted ses- 2326 sion. 2327 b) Discovery-session - a session opened only for tar- 2328 get discovery; the target MAY accept only text requests 2329 with the SendTargets key and a logout request with rea- 2330 son "close the session". 2332 The session type is defined during login with key=value 2333 parameter in the login command. 2335 1.4 SCSI to iSCSI Concepts Mapping Model 2337 The following diagram shows an example of how multiple 2338 iSCSI Nodes (targets in this case) can coexist within 2339 the same Network Entity and can share Network Portals 2340 (IP addresses and TCP ports). Other more complex configu- 2341 rations are also possible. See Section 1.4.1 iSCSI Archi- 2342 tecture Model for detailed descriptions of the components 2343 of these diagrams. 2345 Julian Satran Expires August 2002 24 2347 iSCSI 20-January-02 2349 +-----------------------------------+ 2350 | Network Entity (iSCSI Client) | 2351 | | 2352 | +-------------+ | 2353 | | iSCSI Node | | 2354 | | (Initiator) | | 2355 | +-------------+ | 2356 | | | | 2357 | +--------------+ +--------------+ | 2358 | |Network Portal| |Network Portal| | 2359 | | 10.1.30.4 | | 10.1.40.6 | | 2360 +-+--------------+-+--------------+-+ 2361 | | 2362 | IP Networks | 2363 | | 2364 +-+--------------+-+--------------+-+ 2365 | |Network Portal| |Network Portal| | 2366 | | 10.1.30.21 | | 10.1.40.3 | | 2367 | | TCP Port 4 | | TCP Port 4 | | 2368 | +--------------+ +--------------+ | 2369 | | | | 2370 | ----------------- | 2371 | | | | 2372 | +-------------+ +--------------+ | 2373 | | iSCSI Node | | iSCSI Node | | 2374 | | (Target) | | (Target) | | 2375 | +-------------+ +--------------+ | 2376 | | 2377 | Network Entity (iSCSI Server) | 2378 +-----------------------------------+ 2380 1.4.1 iSCSI Architecture Model 2382 This section describes the part of the iSCSI architecture 2383 model that has the most bearing on the relationship 2384 between iSCSI and the SCSI Architecture Model. 2386 a) Network Entity - represents a device or gateway 2387 that is accessible from the IP network. A Network 2388 Entity must have one or more Network Portals (see item 2389 d), each of which can be used by some iSCSI Nodes (see 2390 item (b)) contained in that Network Entity to gain 2392 Julian Satran Expires August 2002 25 2394 iSCSI 20-January-02 2396 access to the IP network. 2398 b) iSCSI Node - represents a single iSCSI initiator or 2399 iSCSI target. There are one or more iSCSI Nodes within 2400 a Network Entity. The iSCSI Node is accessible via one 2401 or more Network Portals (see item d). An iSCSI Node is 2402 identified by its iSCSI Name (see Section 1.2.7 Naming 2403 and Addressing and Chapter 12). The separation of the 2404 iSCSI Name from the addresses used by and for the iSCSI 2405 node allows multiple iSCSI nodes to use the same 2406 addresses, and the same iSCSI node to use multiple 2407 addresses. 2409 c) An alias string could also be associated with an 2410 iSCSI Node. The alias allows an organization to associ- 2411 ate a user friendly string with the iSCSI Name. How- 2412 ever, the alias string is not a substitute for the 2413 iSCSI Name. 2415 d) Network Portal - a component of a Network Entity 2416 that has a TCP/IP network address and that may be used 2417 by an iSCSI Node within that Network Entity for the 2418 connection(s) within one of its iSCSI sessions. In an 2419 initiator, it is identified by its IP address. In a 2420 target, it is identified by its IP address and its lis- 2421 tening TCP port. 2423 e) Portal Groups - iSCSI supports multiple connections 2424 within the same session; some implementations will have 2425 the ability to combine connections in a session across 2426 multiple Network Portals. A Portal Group defines a set 2427 of Network Portals within an iSCSI Node that collec- 2428 tively supports the capability of coordinating a ses- 2429 sion with connections that span these portals. Not all 2430 Network Portals within a Portal Group need to partici- 2431 pate in every session connected through that Portal 2432 Group. One or more Portal Groups may provide access to 2433 an iSCSI Node. Each Network Portal, as utilized by a 2434 given iSCSI Node, belongs to exactly one portal group 2435 within that node. Portal Groups are identified within 2436 an iSCSI Node by a portal group tag, a simple integer 2437 value between 1 and 65535 (see Section 12.3 SendTar- 2438 gets). All Network Portals with the same portal group 2440 Julian Satran Expires August 2002 26 2442 iSCSI 20-January-02 2444 tag in the context of a given iSCSI Node are in the 2445 same Portal Group. 2447 Both iSCSI Initiators and iSCSI Targets have portal 2448 groups, though only the iSCSI Target Portal Groups are 2449 used directly in the iSCSI protocol (e.g., in SendTar- 2450 gets). See Section Section 9.1.1 Conservative Reuse of 2451 ISIDs for references to the Initiator Portal Groups. 2453 f) Portals within a Portal Group are expected to have 2454 similar hardware characteristics, as SCSI port specific 2455 mode pages may affect all portals within 2456 a portal group. (See Section 1.4.3.2 SCSI Mode Pages). 2458 The following diagram shows an example of one such config- 2459 uration on a target and how a session that shares Network 2460 Portals within a Portal Group may be established. 2462 Julian Satran Expires August 2002 27 2464 iSCSI 20-January-02 2466 ----------------------------IP Network---------------- 2467 ----- 2468 | | | 2469 +--------|---------------|--------------------|---------- 2470 -----------+ 2471 | +----|---------------|-----+ +----|---------+ 2472 | 2473 | | +---------+ +---------+ | | +---------+ | 2474 | 2475 | | | Network | | Network | | | | Network | | 2476 | 2477 | | | Portal | | Portal | | | | Portal | | 2478 | 2479 | | +--|------+ +---------+ | | +---------+ | 2480 | 2481 | | | | | | | | 2482 | 2483 | | | Portal | | | | Portal | 2484 | 2485 | | | Group 1 | | | | Group 2 | 2486 | 2487 | +--------------------------+ +--------------+ 2488 | 2489 | | | | 2490 | 2491 | +----------------------------+ +-------------------- 2492 ---------+ | 2493 | | iSCSI Session (Target side)| | iSCSI Session (Tar- 2494 get side) | | 2495 | | | | 2496 | | 2497 | | (iSCSI Name + TSID=2) | | (iSCSI Name + TSID=1) 2498 | | 2499 | +----------------------------+ +-------------------- 2500 ---------+ | 2501 | 2502 | 2503 | iSCSI Target Node 2504 | 2505 | (within Network Entity, not shown) 2506 | 2507 +-------------------------------------------------------- 2508 -----------+ 2510 Julian Satran Expires August 2002 28 2512 iSCSI 20-January-02 2514 1.4.2 SCSI Architecture Model 2516 This section describes the relationship between the SCSI 2517 Architecture Model [SAM2] and constructs of the SCSI 2518 device, SCSI port and I_T nexus, and the iSCSI constructs, 2519 described above. 2521 This relationship implies implementation requirements in 2522 order to conform to the SAM2 model and other SCSI opera- 2523 tional functions. These requirements are detailed in Sec- 2524 tion 1.4.3 Consequences of the Model. 2526 a) SCSI Device - the SAM2 term for an entity that 2527 contains other SCSI entities. For example, a SCSI 2528 Initiator Device contains one or more SCSI Initia- 2529 tor Ports and zero or more application clients. A 2530 SCSI Target Device contains one or more SCSI Target 2531 Ports and one or more logical units. For iSCSI, the 2532 SCSI Device is the component within an iSCSI Node 2533 that provides the SCSI functionality. As such, 2534 there can be one SCSI Device, at most, within a 2535 given iSCSI Node. Access to the SCSI Device can 2536 only be achieved in an iSCSI normal operational 2537 session (see Section 1.3 iSCSI Session Types). The 2538 SCSI Device Name is defined to be the iSCSI Name of 2539 the node and its use is mandatory in the iSCSI pro- 2540 tocol. 2542 b) SCSI Port - the SAM2 term for an entity in a SCSI 2543 Device that provides the SCSI functionality to 2544 interface with a service delivery subsystem or 2545 transport. For iSCSI, the definition of SCSI Initi- 2546 ator Port and SCSI Target Port are different. 2548 SCSI Initiator Port: This maps to the endpoint of an 2549 iSCSI normal operational session (see Section 1.3 2550 iSCSI Session Types). An iSCSI normal operational 2551 session is negotiated through the login process 2552 between an iSCSI initiator node and an iSCSI target 2553 node. At successful completion of this process, a 2554 SCSI Initiator Port is created within the SCSI Ini- 2555 tiator Device. The SCSI Initiator Port Name and 2556 SCSI Initiator Port Identifier are both defined to 2557 be the iSCSI Initiator Name together with (a) a 2558 label that identifies it as an initiator port name/ 2559 identifier and (b) the ISID portion of the session 2560 identifier. 2562 Julian Satran Expires August 2002 29 2564 iSCSI 20-January-02 2566 SCSI Target Port: This maps to an iSCSI target Por- 2567 tal Group. The SCSI Target Port Name and the SCSI 2568 Target Port Identifier are both defined to be the 2569 iSCSI Target Name together with (a) a label that 2570 identifies it as a target port name/identifier and 2571 (b) the portal group tag. 2573 The SCSI Port Name is mandatory in iSCSI. When used 2574 in SCSI 2575 parameter data, the SCSI port name should be format- 2576 ted as: 2577 - The iSCSI Name in UTF-8 format, followed by 2578 - a null terminator (1byte), followed by 2579 - the ASCII character 'i' (for SCSI Initiator Port) 2580 or the ASCII character 't' (for SCSI Target Port), 2581 followed by 2582 - a null terminator (1byte), followed by 2583 - zero to 3 null pad bytes so that the complete for- 2584 mat is a multiple of four bytes long, followed by 2585 - the 6byte value of the ISID (for SCSI initiator 2586 port) or the 2byte value of the portal group tag 2587 (for SCSI target port) in network byte order (Big- 2588 Endian). 2589 SCSI port names have a maximum length of 264 bytes 2590 for initiator ports, 260 bytes for target ports, 2591 and must be a multiple of four bytes long. The 2592 ASCII character 'i' or 't' is the label that iden- 2593 tifies this port as either a SCSI Initiator Port or 2594 a SCSI Target Port. This ASCII character also pro- 2595 vides the interpretation and size of the remaining 2596 six bytes (initiator) or two bytes (target). 2598 c) I_T nexus - a relationship between a SCSI Initia- 2599 tor Port and a SCSI Target Port, according to 2600 [SAM2]. For iSCSI, this relationship is a session, 2601 defined as a relationship between an iSCSI Initia- 2602 tor's end of the session (SCSI Initiator Port) and 2603 the iSCSI Target's Portal Group. The I_T nexus can 2604 be identified by the conjunction of the SCSI port 2605 names. That is, the I_T nexus identifier is the 2606 tuple (iSCSI Initiator Name + 'i' + ISID, iSCSI 2607 Target Name + 't' + Portal Group Tag). 2609 NOTE: The I_T nexus identifier is not equal to the 2610 session identifier (SSID). 2612 Julian Satran Expires August 2002 30 2614 iSCSI 20-January-02 2616 1.4.3 Consequences of the Model 2618 This section describes implementation and behavioral 2619 requirements that result from the mapping of SCSI con- 2620 structs to the iSCSI constructs defined above. The follow- 2621 ing are the two assumptions that are the basis of these 2622 requirements: 2624 a) Between a given iSCSI Initiator and iSCSI Target, 2625 at any given time, only one session can exist with a 2626 given session identifier (SSID). 2628 b) Between a given SCSI initiator port and SCSI target 2629 port, only one I_T nexus (session) can exist. That 2630 is, no more than one nexus relationship (parallel 2631 nexus) is allowed. 2633 These assumptions lead to the following conclusions and 2634 requirements. 2636 ISID RULE: Between a given iSCSI Initiator and iSCSI Tar- 2637 get Portal Group (SCSI target port), there can be only one 2638 session with a given value for ISID that identifies the 2639 SCSI initiator port. See Section 10.12.6 ISID. 2641 The structure of the ISID that contains a naming authority 2642 component (see Section 10.12.6 ISID and [NDT]) provides a 2643 mechanism to facilitate compliance with the ISID rule (See 2644 also Section 9.1.1 Conservative Reuse of ISIDs). 2646 The iSCSI Initiator Node is expected to manage the assign- 2647 ment of ISIDs prior to session initiation. The "ISID RULE" 2648 does not preclude the use of the same ISID from the same 2649 iSCSI Initiator with different Target Portal Groups on the 2650 same iSCSI target or on other iSCSI targets (see Section 2651 9.1.1 Conservative Reuse of ISIDs). Allowing this would be 2652 analogous to a single SCSI Initiator Port having relation- 2653 ships (nexus) with multiple SCSI target ports on the same 2654 SCSI target device or SCSI target ports on other SCSI tar- 2655 get devices. It is also possible to have multiple sessions 2656 with different ISIDs to the same Target Portal Group. Each 2657 such session would be considered to be with a different 2658 initiator even when the sessions originate from the same 2660 Julian Satran Expires August 2002 31 2662 iSCSI 20-January-02 2664 initiator device. The same ISID may be used by a different 2665 iSCSI initiator because it is the iSCSI Name together with 2666 the ISID that identifies the SCSI Initiator Port. 2668 NOTE: A consequence of the ISID RULE and the specification 2669 for the I_T nexus identifier is that two nexus with the 2670 same identifier should never exist at the same time. 2672 TSID RULE: The iSCSI Target SHOULD NOT select a TSID for a 2673 given login request if the resulting SSID is already in 2674 use by an existing session between the target and the 2675 requesting iSCSI Initiator. See Section 9.1.1 Conserva- 2676 tive Reuse of ISIDs. 2678 1.4.3.1 I_T Nexus State 2680 Certain nexus relationships contain an explicit state 2681 (e.g., initiator-specific mode pages or reservation 2682 state) that may need to be preserved by the target (or 2683 more correctly stated, the device server in a logical 2684 unit) through changes or failures in the iSCSI layer 2685 (e.g., session failures). In order for that state to be 2686 restored, the iSCSI initiator should re-establish its 2687 session (re-login) to the same Target Portal Group using 2688 the previous ISID. That is, it should perform session 2689 recovery as described in Chapter 7. This is because the 2690 SCSI initiator port identifier and the SCSI target port 2691 identifier (or relative target port) form the datum that 2692 the SCSI logical unit device server uses to identify the 2693 I_T nexus. 2695 1.4.3.2 SCSI Mode Pages 2697 If the SCSI logical unit device server does not maintain 2698 initiator-specific mode pages, and an initiator makes 2699 changes to port-specific mode pages, the changes may 2700 affect all other initiators logged in to that iSCSI Target 2701 through the same Target Portal Group. 2703 Changes via mode pages to the behavior of a portal group 2704 via one iSCSI node should not affect the behavior of this 2705 portal group with respect to other iSCSI Target Nodes, 2706 even if the underlying implementation of a portal group 2708 Julian Satran Expires August 2002 32 2710 iSCSI 20-January-02 2712 serves multiple iSCSI Target Nodes in the same Network 2713 Entity. 2715 1.5 Request/Response Summary 2717 This section lists and briefly describes all the iSCSI PDU 2718 types (request and responses). 2720 All iSCSI PDUs are built as a set of one or more header 2721 segments (basic and auxiliary) and zero or one data seg- 2722 ments. The header group and the data segment may be fol- 2723 lowed by a CRC (digest). 2725 The basic header segment has a fixed length of 48 bytes. 2727 1.5.1 Request/Response types carrying SCSI payload 2729 1.5.1.1 SCSI-Command 2731 This request carries the SCSI CDB and all the other SCSI 2732 execute command procedure call output parameters such as 2733 task attributes, Command Reference Number, Expected Data 2734 Transfer Length for one or both transfer directions (the 2735 later for bidirectional commands), and Task Tag. The I_T_L 2736 nexus is derived by the initiator and target from the LUN 2737 field in the request and the I_T nexus implicit in the 2738 session identification. 2740 In addition, the SCSI-command PDU carries information 2741 required for the proper operation of the iSCSI protocol - 2742 the command sequence number (CmdSN) and the expected sta- 2743 tus number on the connection it is issued (ExpStatSN). 2745 Part or all of the SCSI output (write) data associated 2746 with the SCSI command may be sent as part of the SCSI-Com- 2747 mand PDU as a data segment. 2749 1.5.1.2 SCSI-Response 2751 The SCSI-Response carries all the SCSI execute command 2752 procedure call input parameters and the SCSI execute com- 2753 mand procedure call return value. 2754 It contains the residual counts from the operation if any, 2755 and an indication of whether the counts represent an over- 2757 Julian Satran Expires August 2002 33 2759 iSCSI 20-January-02 2761 flow or an underflow, and the SCSI status if the status is 2762 valid or a response code (a non-zero return value for the 2763 execute-command procedure call) if the status is not 2764 valid. 2766 For a valid status that indicates that the command is exe- 2767 cuted but resulted in a exception (e.g., a SCSI CHECK CON- 2768 DITION), the PDU data segment contains the associated 2769 sense data. 2771 Some data segment content may also be associated (in the 2772 data segment) with a non-zero response code. 2774 In addition, the SCSI-Response PDU carries information 2775 required for the proper operation of the iSCSI protocol - 2776 the number of Data-In PDU that a target has sent (to 2777 enable the initiator to check that all arrived) - Exp- 2778 DataSN, the Status Sequence Number on this connection - 2779 StatSN and the next Expected Command Sequence Number at 2780 target - ExpCmdSN, the Maximum CmdSN acceptable at target 2781 from this initiator. 2783 1.5.1.3 Task Management Function Request 2785 The task management function request provides an initia- 2786 tor with a way to explicitly control the execution of one 2787 or more SCSI Tasks or iSCSI functions. The PDU carries a 2788 function identifier (which task management function to 2789 perform) and enough information to unequivocally identify 2790 the task or task-set on which to perform the action even 2791 if the task(s) to act upon has not yet arrived or has been 2792 discarded due to an error. 2794 The referenced tag identifies an individual task if the 2795 function refers to an individual task. 2797 The I_T_L nexus identifies task sets and is carried by the 2798 LUN (and implied by the session identification). 2800 For task sets, the CmdSN of the task management function 2801 request helps identify the tasks upon which to act, 2802 namely all tasks associated with a LUN and having a CmdSN 2803 preceding the task management function request CmdSN. 2805 Julian Satran Expires August 2002 34 2807 iSCSI 20-January-02 2809 The task management function request execution is com- 2810 pletely performed at the target, (i.e., any coordination 2811 between responses to the tasks affected and the task man- 2812 agement function request response is done by the target). 2814 1.5.1.4 Task Management Function Response 2816 The Task Management Function Response carries an indica- 2817 tion of function completion for a Task Management Function 2818 Request including how it completed (response and quali- 2819 fier) and additional information for failure responses 2820 (Referenced Task Tag - if an abort task failed). 2822 After the task management response indicating task man- 2823 agement function completion, the initiator will not 2824 receive any additional responses from the affected tasks. 2826 1.5.1.5 SCSI Data-out and SCSI Data-in 2828 The SCSI Data-out and SCS Data-in are the main vehicles by 2829 which SCSI data payload is carried between initiator and 2830 target. Data payload is associated with a specific SCSI 2831 command through the Initiator Task Tag. For the target, 2832 convenience, outgoing solicited data also carries a Tar- 2833 get Transfer Tag (copied from R2T) and the LUN. 2834 Each PDU contains the payload length and the data offset 2835 relative to the buffer address contained in the SCSI exec 2836 command procedure call. 2838 In each direction, the data transfer is split into 2839 "sequences". An end-of-sequence is indicated by the F bit. 2841 An outgoing sequence is either unsolicited (only the first 2842 sequence can be unsolicited) or is a complete payload sent 2843 in response to an R2T "prompt". 2845 Input sequences are built to enable the direction switch- 2846 ing for bidirectional commands. 2848 For input the target may request positive acknowledgement 2849 of input data. This is limited to sessions that support 2850 error recovery and is implemented through the A bit in the 2851 SCSI Data-in PDU header. 2853 Julian Satran Expires August 2002 35 2855 iSCSI 20-January-02 2857 Data-in and Data-out PDUs also carry the DataSN to enable 2858 the initiator and target to detect missing PDUs (discarded 2859 due to an error). 2861 StatSN is also carried by the Data-In PDUs. 2863 To enable a SCSI command to be executed involving a mini- 2864 mum number of messages, the last SCSI Data-in PDU passed 2865 for a command may also contain the status if the status 2866 indicated termination with no exceptions (no sense or 2867 response involved). 2869 1.5.1.6 Ready To Transfer (R2T) 2871 R2T is the mechanism by which the SCSI target "prompts" 2872 the initiator for output data. R2T passes the offset of 2873 the requested data relative of the buffer address from the 2874 execute command procedure call and the length of the 2875 solicited data to the initiator. 2877 To help the SCSI target to associate resulting Data-out 2878 with an R2T, the R2T carries the Target Transfer Tag cop- 2879 ied by the initiator in the solicited SCSI Data-out PDUs. 2880 There are no protocol specific requirements with regard to 2881 the value of these tags, but it is assumed that together 2882 with the LUN, they will enable the target to associate 2883 data with an R2T. 2885 R2T also carries information required for proper opera- 2886 tion of the iSCSI protocol, such as an R2TSN (to enable an 2887 initiator to detect a missing R2T), StatSN, ExpCmdSN and 2888 MaxCmdSN. 2890 1.5.1.7 Asynchronous Message 2892 Asynchronous Messages are used to carry SCSI asynchronous 2893 events (AEN) and iSCSI asynchronous messages. 2895 When carrying an AEN, the event details are reported as 2896 sense data in the data segment. 2898 Julian Satran Expires August 2002 36 2900 iSCSI 20-January-02 2902 1.5.2 Requests/Responses carrying iSCSI Only Payload 2904 1.5.2.1 Text Request and Text Response 2906 Text requests and responses are designed as a parameter 2907 negotiation vehicle and as a vehicle for future extension. 2909 In the data segment key=value, Text Requests/Responses 2910 carry text information with a simple syntax. 2912 Text Request/Responses may form extended sequences using 2913 the same Initiator Task Tag. The initiator uses the F 2914 (Final) flag bit in the text request header to indicate 2915 its readiness to terminate a sequence. The target uses the 2916 F (Final) flag bit in the text response header to indicate 2917 its consent to sequence termination. 2919 Text Request/Responses also use the Target Transfer Tag to 2920 indicate continuation of an operation or a new beginning. 2921 A target that wishes to continue an operation will set the 2922 Target Transfer Tag in a Text Response to a value differ- 2923 ent from the default 0xffffffff. An initiator willing to 2924 continue will copy this value into the Target Transfer Tag 2925 of the next Text Request. If the initiator wants to reset 2926 the target (start fresh) it will set the Target Transfer 2927 Tag to 0xffffffff. 2929 Although a complete exchange is always started by the ini- 2930 tiator, specific parameter negotiations may be initiated 2931 by the initiator or target. 2933 1.5.2.2 Login Request and Login Response 2935 Login Requests and Responses are used exclusively during 2936 the login phase of each connection to set up the session 2937 and connection parameters (the login phase consists of a 2938 sequence of login requests and responses carrying the same 2939 Initiator Task Tag). 2941 A connection is identified by an arbitrarily selected con- 2942 nection-ID (CID) that is unique within a session. 2944 Julian Satran Expires August 2002 37 2946 iSCSI 20-January-02 2948 Similar to the Text Requests and Responses, Login 2949 Requests/Responses carry key=value text information with 2950 a simple syntax in the data segment. 2952 The Login phase proceeds through several stages (security 2953 negotiation, operational parameter negotiation) that are 2954 selected with two binary coded fields in the header - the 2955 "current stage" (CSG) and the "next stage" (NSG) with the 2956 appearance of the later being signaled by the "transit" 2957 flag (T). 2959 The first login phase of a session plays a special role 2960 (it is called the leading login) and some header fields 2961 are determined by the leading login (e.g., the version 2962 number, the maximum number of connections, the session 2963 identification etc.). 2965 The command counting initial value is also set by the 2966 leading login. 2968 Status counting for each connection is initiated by the 2969 connection login. 2971 Login Requests are always immediate. 2973 A login request may indicate an implied logout (cleanup) 2974 of the connection to be logged in (we call this a connec- 2975 tion restart) through the X flag in the first login 2976 request header. 2978 1.5.2.3 Logout Request and Response 2980 Logout Requests and Responses are used for the orderly 2981 closing of connections for recovery or maintenance. The 2982 logout request may be issued following a target prompt 2983 (through an asynchronous message) or at an initiators ini- 2984 tiative. When issued on the connection to be logged out no 2985 other request may follow it. 2987 The Logout response indicates that the connection or ses- 2988 sion cleanup is completed and no other responses will 2989 arrive on the connection (if received on the logging-out 2990 connection). The Logout Response indicates also how long 2992 Julian Satran Expires August 2002 38 2994 iSCSI 20-January-02 2996 the target will keep on holding resources for recovery 2997 (e.g., command execution that continues on a new connec- 2998 tion) in Time2Retain and how long the initiator must wait 2999 before proceeding with recovery in Time2Wait. 3001 1.5.2.4 SNACK Request 3003 With the SNACK Request, the initiator requests retrans- 3004 mission of numbered-responses or data from the target. A 3005 single SNACK request covers a contiguous set of missing 3006 items called a run of a given type of items (the type is 3007 indicate in a type field in the PDU header). The run is 3008 composed of an initial item (StatSN, DataSN, R2TSN) and 3009 the number of additional missed Status, Data, or R2T PDUs 3010 (0 means only the initial). For long data-in sequences, 3011 the target may request (at predefined minimum intervals) a 3012 positive acknowledgement for the data sent. A SNACK 3013 request with a type field that indicates ACK and the num- 3014 ber of Data-In PDUs acknowledged conveys this positive 3015 acknowledgement. 3017 1.5.2.5 Reject 3019 Reject enables the target to report an iSCSI error condi- 3020 tion (protocol, unsupported option etc.) that uses a Rea- 3021 son field in the PDU header and includes the complete 3022 header of the bad PDU in the Reject PDU data segment. 3024 1.5.2.6 NOP-Out Request and NOP-In Response 3026 This request/response pair may be used by an initiator and 3027 target as a "ping" mechanism to verify that a connection/ 3028 session is still active and all its components are opera- 3029 tional. Such a ping may be triggered by the initiator or 3030 target. The triggering party indicates that it wants a 3031 reply by setting a value different from the default 3032 0xffffffff in the corresponding Initiator/Target Transfer 3033 Tag. 3035 NOP-In/NOP-Out may also be used "unidirectional" to con- 3036 vey to the initiator/target command, status or data 3037 counter values when there is no other "carrier" and there 3038 is a need to update the initiator/target. 3040 Julian Satran Expires August 2002 39 3042 iSCSI 20-January-02 3044 Julian Satran Expires August 2002 40 3046 iSCSI 20-January-02 3048 1. SCSI Mode Parameters for iSCSI 3050 There are no iSCSI specific mode pages. 3052 Julian Satran Expires August 2002 1 3054 iSCSI 20-January-02 3056 1. Login Phase 3058 The login phase establishes an iSCSI session between an 3059 initiator and a target. It sets the iSCSI protocol param- 3060 eters, security parameters, and authenticates the initia- 3061 tor and target to each other. 3063 The login phase is implemented via login request and 3064 responses only. The whole login phase is considered as a 3065 single task and has a single Initiator Task Tag (similar 3066 to the linked SCSI commands). 3068 The default MaxRecvPDULength is used during Login. 3070 The login phase sequence of commands and responses pro- 3071 ceeds as follows: 3073 - Login initial request 3074 - Login partial response (optional) 3075 - More Login requests and responses (optional) 3076 - Login Final-Response (mandatory) 3078 The initial login request of any connection MUST include 3079 the InitiatorName key=value pair. The initial login 3080 request of the first connection of a session MAY also 3081 include the SessionType key=value pair. For any connec- 3082 tion within a session whose type is not "Discovery", the 3083 first login request MUST also include the key=value pair 3084 TargetName. 3086 The Login Final-response accepts or rejects the Login Com- 3087 mand. 3089 The Login Phase MAY include a SecurityNegotiation stage 3090 and a LoginOperationalNegotiation stage and MUST include 3091 at least one of them, but the included stage MAY be empty 3092 except for the mandatory names. 3094 The login requests and responses contain a field that 3095 indicates the negotiation stage (SecurityNegotiation or 3096 LoginOperationalNegotiation). If both stages are used, 3097 the SecurityNegotiation MUST precede the LoginOperation- 3098 alNegotiation. 3100 Julian Satran Expires August 2002 1 3102 iSCSI 20-January-02 3104 Some operational parameters can be negotiated outside 3105 login through text request/response. 3107 Security MUST be completely negotiated within the Login 3108 Phase (using underlying IPsec security is specified in 3109 Chapter 8) and in [SEC-IPS]). 3111 In some environments, a target or an initiator is not 3112 interested in authenticating its counterpart. It is pos- 3113 sible to bypass authentication through the Login request 3114 and response. 3116 The initiator and target MAY want to negotiate authentica- 3117 tion parameters. Once this negotiation is completed, the 3118 channel is considered secure. 3120 Most of the negotiation keys are only allowed in a spe- 3121 cific stage. The SecurityNegotiation keys appear in Chap- 3122 ter 12 and the LoginOperationalNegotiation keys appear in 3123 Chapter 12. 3124 Only a limited set of keys (marked as Declarative in Chap- 3125 ter 12) may be used in any of the two stages. 3127 Neither the initiator nor the target should attempt to 3128 negotiate a parameter more than once during any login 3129 stage. Attempting to do so will result in the termination 3130 of the login and connection. 3132 Any given Login request or response belongs to a specific 3133 stage; this determines the negotiation keys allowed with 3134 the command or response. 3136 Stage transition is performed through a command exchange 3137 (request/response) that carries the T bit and the same 3138 current stage code. During this exchange, the next stage 3139 is selected by the target and MUST NOT exceed the value 3140 stated by the initiator. The initiator can request a tran- 3141 sition whenever it is ready, but a target can respond with 3142 a transition only after one is offered by the initiator. 3144 In a negotiation sequence, the T bit settings in one pair 3145 of login request-responses have no bearing on the T bit 3147 Julian Satran Expires August 2002 2 3149 iSCSI 20-January-02 3151 settings of the next pair. An initiator that has a T bit 3152 set to 1 in one pair and is answered with a T bit setting 3153 of 0 may issue the next request with T bit set to 0. 3155 Targets MUST NOT submit parameters that require an addi- 3156 tional initiator login request in a login response with 3157 the T bit set to 1. 3159 Stage transitions during login (including entering and 3160 exit) are possible only as outlined in the following 3161 table: 3163 +-------------------------------------------------------- 3164 ---+ 3165 |From To -> | Security | Operational | FullFea- 3166 ture | 3167 | | | | | | 3168 | V | | | | 3169 +-------------------------------------------------------- 3170 ---+ 3171 | (start) | yes | yes | no | 3172 +-------------------------------------------------------- 3173 ---+ 3174 | Security | no | yes | yes | 3175 +-------------------------------------------------------- 3176 ---+ 3177 | Operational | no | no | yes | 3178 +-------------------------------------------------------- 3179 ---+ 3181 The Login Final-Response that accepts a Login Command can 3182 come only as a response to a Login command with the T bit 3183 set to 1, and both the command and response MUST have 3184 FullFeaturePhase in the NSG field. 3186 1.1 Login Phase Start 3188 The login phase starts with a login request from the ini- 3189 tiator to the target. The initial login request includes: 3191 -Protocol version supported by the initiator. 3192 -Session and connection Ids. 3193 -The negotiation stage that the initiator is ready to 3194 enter. 3196 Julian Satran Expires August 2002 3 3198 iSCSI 20-January-02 3200 Optionally, the login request may include: 3202 -Security parameters OR 3203 -iSCSI operational parameters AND/OR 3204 -The next negotiation stage that the initiator is 3205 ready to enter. 3207 The target can answer the login in the following ways: 3209 -Login Response with Login Reject. This is an immedi- 3210 ate rejection from the target that causes the con- 3211 nection to terminate and the session to terminate 3212 if this is the first (or only) connection of a new 3213 session. The T bit of the response MUST be set to 1 3214 and the CSG and NSG are reserved. 3215 -Login Response with Login Accept as a final response 3216 (T bit set to 1 and the NSG in both command and 3217 response are set to FullFeaturePhase). The response 3218 includes the protocol version supported by the tar- 3219 get and the session ID, and may include iSCSI oper- 3220 ational or security parameters (that depend on the 3221 current stage). 3222 -Login Response with Login Accept as a partial 3223 response (NSG not set to FullFeaturePhase in both 3224 request and response) that indicates the start of a 3225 negotiation sequence. The response includes the 3226 protocol version supported by the target and either 3227 security or iSCSI parameters (when no security 3228 mechanism is chosen) supported by the target. 3230 If the initiator decides to forego the SecurityNegotia- 3231 tion stage, it issues the Login with the CSG set to Logi- 3232 nOperationalNegotiation and the target may reply with a 3233 Login Response that indicates that it is unwilling to 3234 accept the connection without SecurityNegotiation and 3235 will terminate the connection. 3237 If the initiator is willing to negotiate security, but is 3238 unwilling to make the initial parameter offer and may 3239 accept a connection without security, it issues the Login 3240 with the T bit set to 1, the CSG set to SecurityNegotia- 3241 tion, and NSG set to LoginOperationalNegotiation. If the 3242 target is also ready to forego security, the Login 3243 response is empty and has T bit set to 1, the CSG set to 3245 Julian Satran Expires August 2002 4 3247 iSCSI 20-January-02 3249 SecurityNegotiation, and NSG set to LoginOperationalNego- 3250 tiation. 3252 An initiator that can operate without security and with 3253 all the operational parameters taking the default values 3254 issues the Login with the T bit set to 1, the CSG set to 3255 LoginOperationalNegotiation, and NSG set to FullFea- 3256 turePhase. If the target is also ready to forego security 3257 and can finish its LoginOperationalNegotiation, the Login 3258 response has T bit set to 1, the CSG set to LoginOpera- 3259 tionalNegotiation, and NSG set to FullFeaturePhase in the 3260 next stage. 3262 1.2 iSCSI Security Negotiation 3264 The security exchange sets the security mechanism and 3265 authenticates 3266 the initiator user and the target to each other. The 3267 exchange proceeds according authentication method chosen 3268 in the negotiation phase and is conducted using the login 3269 requests and responses key=value parameters. 3271 An initiator directed negotiation proceeds as follows: 3273 -The initiator sends a login request with an ordered 3274 list of the options it supports (authentication 3275 algorithm). The options are listed in the initia- 3276 tor's order of preference. The initiator MAY also 3277 send proprietary options. 3278 -The target MUST reply with the first option in the 3279 list it supports and is allowed to use for the spe- 3280 cific initiator unless it does not support any in 3281 which case it MUST answer with "Reject" (see also 3282 Section 2.2.4 Text Mode Negotiation). The parame- 3283 ters are encoded in UTF8 as key=value. For security 3284 parameters, see Chapter 11. 3286 -The initiator must be aware of the imminent comple- 3287 tion of the SecurityNegotiation stage and MUST set 3288 the T bit to 1 and the NSG to what it would like the 3289 next stage to be. The target will answer with a 3290 Login response with the T bit set to 1 and the NSG 3291 to what it would like the next stage to be. The next 3292 stage selected will be the one the target selected. 3293 If the next stage is FullFeaturePhase, the target 3295 Julian Satran Expires August 2002 5 3297 iSCSI 20-January-02 3299 MUST respond with a Login Response with the Session 3300 ID and the protocol version. 3302 If the security negotiation fails at the target, then the 3303 target MUST send the appropriate Login Response PDU. If 3304 the security negotiation fails at the initiator, the ini- 3305 tiator SHOULD close the connection. 3307 It should be noted that the negotiation might also be 3308 directed by the target if the initiator does support secu- 3309 rity, but is not ready to direct the negotiation (offer 3310 options). 3312 1.3 Operational Parameter Negotiation During the Login 3313 Phase 3315 Operational parameter negotiation during the login MAY be 3316 done: 3318 - Starting with the first Login request if the initi- 3319 ator does not offer any security/ integrity option. 3320 - Starting immediately after the security negotiation 3321 if the initiator and target perform such a negotia- 3322 tion. 3324 Operational parameter negotiation MAY involve several 3325 Login request-response exchanges started and terminated 3326 by the initiator. The initiator MUST indicate its intent 3327 to terminate the negotiation by setting the T bit to 1; 3328 the target sets the T bit to 1 on the last response. 3330 If the target responds to a Login request with the T bit 3331 set to 1 with a Login response with the T bit set to 0, 3332 the initiator should keep sending the Login request (even 3333 empty) with the T bit set to 1, while it still wants to 3334 switch stage, until it receives the Login Response with 3335 the T bit set to 1. 3337 Whenever parameter action or acceptance are dependent on 3338 other parameters, the dependent parameters MUST be sent 3339 after the parameters on which they depend. If they are 3340 sent within the same command, a response for a parameter 3341 might imply responses for others. 3343 Julian Satran Expires August 2002 6 3345 iSCSI 20-January-02 3347 Some session specific parameters can be specified only 3348 during the login phase begun by a login command that con- 3349 tains a null TSID - the leading login phase (e.g., the 3350 maximum number of connections that can be used for this 3351 session). 3353 A session is operational once it has at least one connec- 3354 tion in FullFeaturePhase. New or replacement connections 3355 can be added to a session only after the session is oper- 3356 ational. 3358 For operational parameters, see Chapter 12. 3360 Julian Satran Expires August 2002 7 3362 iSCSI 20-January-02 3364 1. Operational Parameter Negotiation Outside the Login Phase 3366 Some operational parameters MAY be negotiated outside 3367 (after) the login phase. 3369 Parameter negotiation in full feature phase is done 3370 through Text requests and responses. Operational parame- 3371 ter negotiation MAY involve several text request-response 3372 exchanges, which the indicator always starts and termi- 3373 nates and uses the same Initiator Task Tag. The initiator 3374 MUST indicate its intent to terminate the negotiation by 3375 setting the F bit to 1; the target sets the F bit to 1 on 3376 the last response. 3378 If to a text request with the F bit set to 1 the target 3379 responds with a text response with the F bit set to 0, the 3380 initiator should keep sending the text request (even 3381 empty) with the F bit set to 1, while it still wants to 3382 finish the negotiation, until it receives the text 3383 response with the F bit set to 1. Responding to a text 3384 request with the F bit set to 1 with an empty (no 3385 key=value pairs) response with the F bit set to 0 is not 3386 an error but is discouraged. 3388 Targets MUST NOT submit parameters that require an addi- 3389 tional initiator text request in a text response with the 3390 F bit set to 1. 3392 In a negotiation sequence, the F bit settings in one pair 3393 of text request-responses have no bearing on the F bit 3394 settings of the next pair. An initiator that has the F bit 3395 set to 1 in a request and being answered with an F bit 3396 setting of 0 may have the next request issued with the F 3397 bit set to 0. 3399 Whenever parameter action or acceptance is dependent on 3400 other parameters, the dependent parameters MUST be sent 3401 after the parameters on which they depend; if sent within 3402 the same command, a response for a parameter might imply 3403 responses for others. 3405 Julian Satran Expires August 2002 1 3407 iSCSI 20-January-02 3409 Whenever the target responds with the F bit set to 0, it 3410 MUST set the Target Transfer Tag to a value other than the 3411 default 0xffffffff. 3413 An initiator MAY reset an operational parameter negotia- 3414 tion by issuing a Text request with the Target Transfer 3415 Tag set to the value 0xffffffff after receiving a response 3416 with the Target Transfer Tag set to a value other than 3417 0xffffffff. A target may reset an operational parameter 3418 negotiation by answering a Text request with a Reject. 3420 Neither the initiator nor the target should attempt to 3421 negotiate a parameter more than once during any negotia- 3422 tion sequence without an intervening reset. If detected by 3423 the target this MUST result in a Reject with a reason of 3424 "protocol error". The initiator MUST reset the negotia- 3425 tion as outlined above. 3427 Julian Satran Expires August 2002 2 3429 iSCSI 20-January-02 3431 1. State Transitions 3433 iSCSI connections and iSCSI sessions go through several 3434 well-defined states from connection creation and session 3435 creation to the time they are cleared. 3437 An iSCSI connection is a transport connection used for 3438 carrying out iSCSI activity. The connection state transi- 3439 tions are described in two separate, but dependent state 3440 diagrams for ease in understanding. The first diagram, 3441 "standard connection state diagram", describes the con- 3442 nection state transitions when the iSCSI connection is not 3443 waiting for or undergoing a cleanup by way of an explicit 3444 or implicit Logout. The second diagram, "connection 3445 cleanup state diagram", describes the connection state 3446 transitions while performing the iSCSI connection 3447 cleanup. 3449 The "session state diagram" describes the state transi- 3450 tions an iSCSI session would go through during its life- 3451 time, and it depends on the states of possibly multiple 3452 iSCSI connections that participate in the session. 3454 1.1 Standard Connection State Diagrams 3456 1.1.1 Standard Connection State Diagram for an Initiator 3458 Symbolic names for States: 3460 S1: FREE 3461 S2: XPT_WAIT 3462 S4: IN_LOGIN 3463 S5: LOGGED_IN (full-feature phase) 3464 S6: IN_LOGOUT 3465 S7: LOGOUT_REQUESTED 3466 S8: CLEANUP_WAIT 3468 The state diagram is as follows: 3470 Julian Satran Expires August 2002 1 3472 iSCSI 20-January-02 3474 -------<-------------+ 3475 +--------->/ S1 \<----+ | 3476 T13| +->\ /<-+ \ | 3477 | / ---+--- \ \ | 3478 | / | T2 \ | | 3479 | T8 | |T1 | | | 3480 | | | / |T7 | 3481 | | | / | | 3482 | | | / | | 3483 | | V / / | 3484 | | ------- / / | 3485 | | / S2 \ / | 3486 | | \ / / | 3487 | | ---+--- / | 3488 | | |T4 / | 3489 | | V / | T18 3490 | | ------- / | 3491 | | / S4 \ | 3492 | | \ / | 3493 | | ---+--- | T15 3494 | | |T5 +--------+---------+ 3495 | | | /T16+-----+------+ | 3496 | | | / -+-----+--+ | | 3497 | | | / / S7 \ |T12| | 3498 | | | / +->\ /<-+ V V 3499 | | | / / -+----- ------- 3500 | | | / /T11 |T10 / S8 \ 3501 | | V / / V +----+ \ / 3502 | | ---+-+- ----+-- | ------- 3503 | | / S5 \T9 / S6 \<+ ^ 3504 | +-----\ /--->\ / T14 | 3505 | ------- --+----+------+T17 3506 +---------------------------+ 3508 The following state transition table represents the above 3509 diagram. Each row represents the starting state for a 3510 given transition, which after taking a transition marked 3511 in a table cell would end in the state represented by the 3512 column of the cell. For example, from state S1, the con- 3513 nection takes the T1 transition to arrive at state S2. The 3514 fields marked "-" correspond to undefined transitions. 3516 Julian Satran Expires August 2002 2 3518 iSCSI 20-January-02 3520 +-----+---+---+---+---+----+---+ 3521 |S1 |S2 |S4 |S5 |S6 |S7 |S8 | 3522 ---+-----+---+---+---+---+----+---+ 3523 S1| - |T1 | - | - | - | - | - | 3524 ---+-----+---+---+---+---+----+---+ 3525 S2|T2 |- |T4 | - | - | - | - | 3526 ---+-----+---+---+---+---+----+---+ 3527 S4|T7 |- |- |T5 | - | - | - | 3528 ---+-----+---+---+---+---+----+---+ 3529 S5|T8 |- |- | - |T9 |T11 |T15| 3530 ---+-----+---+---+---+---+----+---+ 3531 S6|T13 |- |- | - |T14|- |T17| 3532 ---+-----+---+---+---+---+----+---+ 3533 S7|T18 |- |- | - |T10|T12 |T16| 3534 ---+-----+---+---+---+---+----+---+ 3535 S8| - |- |- | - | - | - | - | 3536 ---+-----+---+---+---+---+----+---+ 3538 1.1.2 Standard Connection State Diagram for a Target 3540 Symbolic names for States: 3541 S1: FREE 3542 S3: XPT_UP 3543 S4: IN_LOGIN 3544 S5: LOGGED_IN (full-feature phase) 3545 S6: IN_LOGOUT 3546 S7: LOGOUT_REQUESTED 3547 S8: CLEANUP_WAIT 3549 The state diagram is as follows: 3551 Julian Satran Expires August 2002 3 3553 iSCSI 20-January-02 3555 -------<-------------+ 3556 +--------->/ S1 \<----+ | 3557 T13| +->\ /<-+ \ | 3558 | / ---+--- \ \ | 3559 | / | T6 \ | | 3560 | T8 | |T3 | | | 3561 | | | / |T7 | 3562 | | | / | | 3563 | | | / | | 3564 | | V / / | 3565 | | ------- / / | 3566 | | / S3 \ / | 3567 | | \ / / | T18 3568 | | ---+--- / | 3569 | | |T4 / | 3570 | | V / | 3571 | | ------- / | 3572 | | / S4 \ | 3573 | | \ / | 3574 | | ---+--- T15 | 3575 | | |T5 +--------+---------+ 3576 | | | /T16+-----+------+ | 3577 | | | / -+-----+---+ | | 3578 | | | / / S7 \ |T12| | 3579 | | | / +->\ /<-+ V V 3580 | | | / / -+----- ------- 3581 | | | / /T11 |T10 / S8 \ 3582 | | V / / V \ / 3583 | | ---+-+- ------- ------- 3584 | | / S5 \T9 / S6 \ ^ 3585 | +-----\ /--->\ / | 3586 | ------- --+----+--------+T17 3587 +---------------------------+ 3589 The following state transition table represents the above 3590 diagram, and follows the conventions described for the 3591 initiator diagram. 3593 Julian Satran Expires August 2002 4 3595 iSCSI 20-January-02 3597 +-----+---+---+---+---+----+---+ 3598 |S1 |S3 |S4 |S5 |S6 |S7 |S8 | 3599 ---+-----+---+---+---+---+----+---+ 3600 S1| - |T3 | - | - | - | - | - | 3601 ---+-----+---+---+---+---+----+---+ 3602 S3|T6 |- |T4 | - | - | - | - | 3603 ---+-----+---+---+---+---+----+---+ 3604 S4|T7 |- |- |T5 | - | - | - | 3605 ---+-----+---+---+---+---+----+---+ 3606 S5|T8 |- |- | - |T9 |T11 |T15| 3607 ---+-----+---+---+---+---+----+---+ 3608 S6|T13 |- |- | - |- |- |T17| 3609 ---+-----+---+---+---+---+----+---+ 3610 S7|T18 |- |- | - |T10|T12 |T16| 3611 ---+-----+---+---+---+---+----+---+ 3612 S8| - |- |- | - | - | - | - | 3613 ---+-----+---+---+---+---+----+---+ 3615 1.1.3 State Descriptions for Initiators and Targets 3617 State descriptions for the standard connection state dia- 3618 gram are as follows: 3619 -S1: FREE 3620 -initiator: State on instantiation, or after suc- 3621 cessful connection closure. 3622 -target: State on instantiation, or after success- 3623 ful connection closure. 3624 -S2: XPT_WAIT 3625 -initiator: Waiting for a response to its transport 3626 connection establishment request. 3627 -target: Illegal 3628 -S3: XPT_UP 3629 -initiator: Illegal 3630 -target: Waiting for the Login process to commence. 3631 -S4: IN_LOGIN 3632 -initiator: Waiting for the Login process to con- 3633 clude, possibly involving several PDU exchanges. 3634 -target: Waiting for the Login process to conclude, 3635 possibly involving several PDU exchanges. 3636 -S5: LOGGED_IN 3637 -initiator: In full-feature phase, waiting for all 3638 internal, iSCSI, and transport events. 3640 Julian Satran Expires August 2002 5 3642 iSCSI 20-January-02 3644 -target: In full-feature phase, waiting for all 3645 internal, iSCSI, and transport events. 3646 -S6: IN_LOGOUT 3647 -initiator: Waiting for a Logout response. 3648 -target: Waiting for an internal event signaling 3649 completion of logout processing. 3650 -S7: LOGOUT_REQUESTED 3651 -initiator: Waiting for an internal event signaling 3652 readiness to proceed with Logout. 3653 -target: Waiting for the Logout process to start 3654 after having requested a Logout via an Async Mes- 3655 sage. 3656 -S8: CLEANUP_WAIT 3657 -initiator: Waiting for the context and/or 3658 resources to initiate the cleanup processing for 3659 this CSM. 3660 -target: Waiting for the cleanup process to start 3661 for this CSM. 3662 1.1.4 State Transition Descriptions for Initiators and Tar- 3663 gets 3665 -T1: 3666 -initiator: Transport connect request was made (ex: 3667 TCP SYN sent). 3668 -target: Illegal 3669 -T2: 3670 -initiator: Transport connection request timed 3671 out, or a transport reset was received, or an 3672 internal event of receiving a Logout response 3673 (success) on another connection for a close the 3674 session Logout command was received. 3675 -target:Illegal 3676 -T3: 3677 -initiator: Illegal 3678 -target: Received a valid transport connection 3679 request that establishes the transport connection. 3680 -T4: 3681 -initiator: Transport connection established, thus 3682 prompting the initiator to start the iSCSI Login. 3683 -target: Initial iSCSI Login command was received. 3684 -T5: 3685 -initiator: The final iSCSI Login response with a 3686 status class of zero was received. 3688 Julian Satran Expires August 2002 6 3690 iSCSI 20-January-02 3692 -target: The final iSCSI Login command to conclude 3693 the Login phase was received, thus prompting the 3694 target to send the final iSCSI Login response with 3695 a status class of zero. 3696 -T6: 3697 -initiator: Illegal 3698 -target: Timed out waiting for an iSCSI Login, or 3699 transport disconnect indication was received, or 3700 transport reset was received, or an internal event 3701 indicating a transport timeout was received, or an 3702 internal event of sending a Logout response (suc- 3703 cess) on another connection for a close the ses- 3704 sion Logout command was received. In all these 3705 cases, the connection is to be closed. 3706 -T7: 3707 -initiator: The final iSCSI Login response was 3708 received with a non-zero status class, or Login 3709 timed out, or transport disconnect indication was 3710 received, or transport reset was received, or an 3711 internal event indicating a transport timeout was 3712 received, or an internal event of receiving a 3713 Logout response (success) on another connection 3714 for a close the session Logout command was 3715 received. In all these cases, the transport con- 3716 nection is closed. 3717 -target: The final iSCSI Login command to conclude 3718 the Login phase was received, prompting the target 3719 to send the final iSCSI Login response with a non- 3720 zero status class, or Login timed out, or trans- 3721 port disconnect indication was received, or trans- 3722 port reset was received, or an internal event 3723 indicating a transport timeout was received, or an 3724 internal event of sending a Logout response (suc- 3725 cess) on another connection for a close the ses- 3726 sion Logout command was received. In all these 3727 cases, the connection is to be closed. 3728 -T8: 3729 -initiator: An internal event of receiving a Logout 3730 response (success) on a another connection for a 3731 close the session Logout command was received, 3732 thus closing this connection requiring no further 3733 cleanup. 3735 Julian Satran Expires August 2002 7 3737 iSCSI 20-January-02 3739 -target: An internal event of sending a Logout 3740 response (success) on another connection for a 3741 "close the session" Logout command was received, 3742 thus prompting the target to close this connection 3743 cleanly. 3744 -T9, T10: 3745 -initiator: An internal event that indicates the 3746 readiness to start the Logout process was 3747 received, thus prompting an iSCSI Logout to be 3748 sent by the initiator. 3749 -target: An iSCSI Logout command was received. 3750 -T11, T12: 3751 -initiator: Async PDU with AsyncEvent "Request 3752 Logout" was received. 3753 -target: An internal event that requires the decom- 3754 missioning of the connection is received, thus 3755 causing an Async PDU with an AsyncEvent "Request 3756 Logout" to be sent. 3757 -T13: 3758 -initiator: An iSCSI Logout response (success) was 3759 received, or an internal event of receiving a 3760 Logout response (success) on another connection 3761 for a close the session Logout command was 3762 received. 3763 -target: An internal event was received that indi- 3764 cates successful processing of the Logout, which 3765 prompts an iSCSI Logout response (success) to be 3766 sent, or an internal event of sending a Logout 3767 response (success) on another connection for a 3768 "close the session" Logout command was received. 3769 In both these cases, the transport connection is 3770 closed. 3772 -T14: 3773 -initiator: Async PDU with AsyncEvent "Request 3774 Logout" was received again. 3775 -target: Illegal 3776 -T15, T16: 3777 -initiator: One or more of the following events 3778 caused this transition: 3779 -Internal event that indicates a transport con- 3780 nection timeout was received thus prompting trans- 3781 port RESET or transport connection closure. 3783 Julian Satran Expires August 2002 8 3785 iSCSI 20-January-02 3787 -A transport RESET. 3788 -A transport disconnect indication. 3789 -Async PDU with AsyncEvent "Drop connection" 3790 (for this CID). 3791 -Async PDU with AsyncEvent "Drop all connec- 3792 tions". 3793 -target: One or more of the following events caused 3794 this transition: 3795 -Internal event that indicates a transport con- 3796 nection timeout was received, thus prompting 3797 transport RESET or transport connection closure. 3798 -A transport RESET. 3799 -A transport disconnect indication. 3800 -Internal emergency cleanup event was received 3801 which prompts an Async PDU with AsyncEvent "Drop 3802 connection" (for this CID), or event "Drop all 3803 connections". 3805 -T17: 3806 -initiator: One or more of the following events 3807 caused this transition: 3808 -Logout response (failure, i.e. a non-zero sta- 3809 tus) was received. 3810 -Any of the events specified for T15 and T16. 3811 -target: One or more of the following events 3812 caused this transition: 3813 -Internal event that indicates a failure of the 3814 Logout processing was received, which prompts a 3815 Logout response (failure, i.e. a non-zero status) 3816 to be sent. 3817 -Any of the events specified for T15 and T16. 3818 -T18: 3819 -initiator: An internal event of receiving a Logout 3820 response (success) on another connection for a 3821 "close the session" Logout command was received. 3823 -target: An internal event of sending a Logout 3824 response (success) on another connection for a 3825 "close the session" Logout command was received. 3827 Julian Satran Expires August 2002 9 3829 iSCSI 20-January-02 3831 The CLEANUP_WAIT state (S8) implies that there are possi- 3832 ble iSCSI tasks that have not reached conclusion and are 3833 still considered busy. 3835 1.2 Connection Cleanup State Diagram for Initiators and 3836 Targets 3838 Symbolic names for states: 3840 R1: CLEANUP_WAIT (same as S8) 3841 R2: IN_CLEANUP 3842 R3: FREE (same as S1) 3844 Whenever a connection state machine (e.g., CSM-C) enters 3845 the CLEANUP_WAIT state (S8), it must go through the state 3846 transitions additionally described in the connection 3847 cleanup state diagram either a) using a separate full-fea- 3848 ture phase connection (let�s call it CSM-E) in the 3849 LOGGED_IN state in the same session, or b) using a new 3850 transport connection (let�s call it CSM-I) in the FREE 3851 state that is to be added to the same session. In the CSM- 3852 E case, an explicit logout for the CID that corresponds to 3853 CSM-C (either as a connection or session logout) needs to 3854 be performed to complete the cleanup. In the CSM-I case, 3855 an implicit logout for the CID that corresponds to CSM-C 3856 needs to be performed by way of connection reinstatement 3857 (see Section 10.12.2 X - Restart Connection) for that CID. 3858 In either case, the protocol exchanges on CSM-E or CSM-I 3859 to determine the state transitions for CSM-C. Therefore, 3860 this cleanup state diagram is applicable only to the 3861 instance of the connection in cleanup (i.e., CSM-C). In 3862 the case of an implicit logout for example, CSM-C reaches 3863 FREE (R3) at the time CSM-I reaches LOGGED_IN. In the case 3864 of an explicit logout, CSM-C reaches FREE (R3) when CSM-E 3865 receives a successful logout response while continuing to 3866 be in the LOGGED_IN state. 3868 The following state diagram applies to both initiators and 3869 targets. 3871 Julian Satran Expires August 2002 10 3873 iSCSI 20-January-02 3875 ------- 3876 / R1 \ 3877 +--\ /<-+ 3878 / ---+--- \ 3879 / | \ M3 3880 M1 | |M2 | 3881 | | / 3882 | | / 3883 | | / 3884 | V / 3885 | ------- / 3886 | / R2 \ 3887 | \ / 3888 | ------- 3889 | | 3890 | |M4 3891 | | 3892 | | 3893 | | 3894 | V 3895 | ------- 3896 | / R3 \ 3897 +---->\ / 3898 ------- 3900 The following state transition table represents the above 3901 diagram, and follows the same conventions as in earlier 3902 sections. 3904 +----+----+----+ 3905 |R1 |R2 |R3 | 3906 -----+----+----+----+ 3907 R1 | - |M2 |M1 | 3908 -----+----+----+----+ 3909 R2 |M3 | - |M4 | 3910 -----+----+----+----+ 3911 R3 | - | - | - | 3912 -----+----+----+----+ 3914 1.2.1 State Descriptions for Initiators and Targets 3916 -R1: CLEANUP_WAIT (Same as S8) 3918 Julian Satran Expires August 2002 11 3920 iSCSI 20-January-02 3922 -initiator: Waiting for the internal event to ini- 3923 tiate the cleanup processing for CSM-C. 3924 -target: Waiting for the cleanup process to start 3925 for CSM-C. 3926 -R2: IN_CLEANUP 3927 -initiator: Waiting for the connection cleanup pro- 3928 cess to conclude for CSM-C. 3929 -target: Waiting for the connection cleanup process 3930 to conclude for CSM-C. 3931 -R3: FREE (Same as S1) 3932 -initiator: End state for CSM-C. 3933 -target: End state for CSM-C. 3935 1.2.2 State Transition Descriptions for Initiators and Tar- 3936 gets 3938 -M1: One or more of the following events was received: 3939 -initiator: 3940 -An internal event that indicates connection 3941 state timeout. 3942 -An internal event of receiving a successful 3943 Logout response on a different connection for a 3944 "close the session" Logout. 3945 -target: 3946 -An internal event that indicates connection 3947 state timeout. 3948 -An internal event of sending a Logout response 3949 (success) on a different connection for a "close 3950 the session" Logout command. 3951 -M2: An implicit/explicit logout process was initiated by 3952 the initiator. 3953 -In CSM-I usage: 3954 -initiator: An internal event requesting the 3955 CID reinstatement was received, thus prompting a 3956 connection reinstatement Login to be sent transi- 3957 tioning to state IN_LOGIN. 3958 -target: A connection reinstatement Login was 3959 received while in state XPT_UP. 3960 -In CSM-E usage: 3961 -initiator: An internal event that indicates 3962 that an explicit logout was sent for this CID in 3963 state LOGGED_IN. 3965 Julian Satran Expires August 2002 12 3967 iSCSI 20-January-02 3969 -target: An explicit logout was received for 3970 this CID in state LOGGED_IN. 3971 -M3: Logout failure detected 3972 -In CSM-I usage: 3973 -initiator: CSM-I failed to reach LOGGED_IN and 3974 arrived into FREE instead. 3975 -target: CSM-I failed to reach LOGGED_IN and 3976 arrived into FREE instead. 3977 -In CSM-E usage: 3978 -initiator: CSM-E either moved out of 3979 LOGGED_IN, or Logout timed out and/or aborted, or 3980 Logout response (failure) was received. 3981 -target: CSM-E either moved out of LOGGED_IN, 3982 or Logout timed out and/or aborted, or an internal 3983 event that indicates a failed Logout processing 3984 was received. A Logout response (failure) was 3985 sent in the last case. 3987 -M4: Successful implicit/explicit logout was performed. 3988 - In CSM-I usage: 3989 -initiator: CSM-I reached state LOGGED_IN, or 3990 an internal event of receiving a Logout response 3991 (success) on another connection for a "close the 3992 session" Logout command was received. 3993 -target: CSM-I reached state LOGGED_IN, or an 3994 internal event of sending a Logout response (suc- 3995 cess) on a different connection for a "close the 3996 session" Logout command was received. 3997 - In CSM-E usage: 3998 -initiator: CSM-E stayed in LOGGED_IN and 3999 received a Logout response (success), or an inter- 4000 nal event of receiving a Logout response (success) 4001 on another connection for a "close the session" 4002 Logout command was received. 4003 -target: CSM-E stayed in LOGGED_IN and an 4004 internal event indicating a successful Logout pro- 4005 cessing was received, or an internal event of 4006 sending a Logout response (success) on a different 4007 connection for a "close the session" Logout com- 4008 mand was received. 4010 Julian Satran Expires August 2002 13 4012 iSCSI 20-January-02 4014 1.3 Session State Diagram 4016 Session continuation is the process by which the state of 4017 a pre-existing session continues to be in use by either 4018 connection reinstatement (see Section 10.12.2 X - Restart 4019 Connection), or by adding a connection with a new CID. 4020 Either of these actions associates the new transport con- 4021 nection with the pre-existing session state. 4023 1.3.1 Session State Diagram for an Initiator 4025 Symbolic Names for States: 4027 Q1: FREE 4028 Q3: LOGGED_IN 4029 Q4: FAILED 4031 The state diagram is as follows: 4033 ------- 4034 / Q1 \ 4035 +------>\ /<-+ 4036 / ---+--- | 4037 / | |N3 4038 N6 | |N1 | 4039 | | | 4040 | N4 | | 4041 | +--------+ | / 4042 | | | | / 4043 | | | | / 4044 | | V V / 4045 -+--+-- -----+- 4046 / Q4 \ N5 / Q3 \ 4047 \ /<---\ / 4048 ------- ------- 4050 State transition table: 4052 Julian Satran Expires August 2002 14 4054 iSCSI 20-January-02 4056 +----+----+----+ 4057 |Q1 |Q3 |Q4 | 4058 -----+----+----+----+ 4059 Q1 | - |N1 | - | 4060 -----+----+----+----+ 4061 Q3 |N3 | - |N5 | 4062 -----+----+----+----+ 4063 Q4 |N6 |N4 | - | 4064 -----+----+----+----+ 4066 1.3.2 Session State Diagram for a Target 4068 Symbolic Names for States: 4070 Q1: FREE 4071 Q2: ACTIVE 4072 Q3: LOGGED_IN 4073 Q4: FAILED 4074 Q5: IN_CONTINUE 4076 The state diagram is as follows: 4078 ------- 4079 / Q1 \ 4080 +---------------->\ /<-+ 4081 / ---+--- | 4082 / ^ | |N3 4083 N6 | N9| V N1 | 4084 | +------ | 4085 | / Q2 \ | 4086 | \ / | 4087 | ------- +--+--- | 4088 | / Q5 \ | | 4089 | \ / N10 | | 4090 | +-+---+------------+ |N2 / 4091 | ^ | | | / 4092 |N7| |N8 | | / 4093 | | | | V / 4094 -+--+-V V----+- 4095 / Q4 \ N5 / Q3 \ 4096 \ /<-------------\ / 4097 ------- ------- 4099 State transition table: 4101 Julian Satran Expires August 2002 15 4103 iSCSI 20-January-02 4105 +----+----+----+----+----+ 4106 |Q1 |Q2 |Q3 |Q4 |Q5 | 4107 -----+----+----+----+----+----+ 4108 Q1 | - |N1 | - | - | - | 4109 -----+----+----+----+----+----+ 4110 Q2 |N9 | - |N2 | - | - | 4111 -----+----+----+----+----+----+ 4112 Q3 |N3 | - | - |N5 | - | 4113 -----+----+----+----+----+----+ 4114 Q4 |N6 | - | - | - |N7 | 4115 -----+----+----+----+----+----+ 4116 Q5 | - | - |N10 |N8 | - | 4117 -----+----+----+----+----+----+ 4119 1.3.3 State Descriptions for Initiators and Targets 4121 -Q1: FREE 4122 -initiator: State on instantiation or after 4123 cleanup. 4124 -target: State on instantiation or after cleanup. 4125 -Q2: ACTIVE 4126 -initiator: Illegal 4127 -target: The first iSCSI connection in the session 4128 transitioned to IN_LOGIN, waiting for it to com- 4129 plete the login process. 4130 -Q3: LOGGED_IN 4131 -initiator: Waiting for all session events. 4132 -target: Waiting for all session events. 4133 -Q4: FAILED 4134 -initiator: Waiting for session recovery or session 4135 continuation. 4136 -target: Waiting for session recovery or session 4137 continuation. 4138 -Q5: IN_CONTINUE 4139 -initiator: Illegal 4140 -target: Waiting for session continuation attempt 4141 to reach a conclusion. 4143 Julian Satran Expires August 2002 16 4145 iSCSI 20-January-02 4147 1.3.4 State Transition Descriptions for Initiators and Tar- 4148 gets 4150 -N1: 4151 -initiator: At least one transport connection 4152 reached the LOGGED_IN state. 4153 -target: The first iSCSI connection in the session 4154 had reached the IN_LOGIN state. 4155 -N2: 4156 -initiator: Illegal 4157 -target: At least one transport connection reached 4158 the LOGGED_IN state. 4159 -N3: 4160 -initiator: Graceful closing of the session was 4161 completed either via a "close the session" 4162 Logout, or last successful "close the connection" 4163 Logout. 4164 -target: Graceful closing of the session was com- 4165 pleted either via a "close the session" Logout, 4166 or last successful "close the connection" Logout. 4167 -N4: 4168 -initiator: A session continuation attempt suc- 4169 ceeded. 4170 -target: Illegal 4171 -N5: 4172 -initiator: Session failure occurred (all connec- 4173 tions reported CLEANUP_WAIT). 4174 -target: Session failure occurred (all connections 4175 reported CLEANUP_WAIT). 4176 -N6: 4177 -initiator: Session state timeout occurred, or an 4178 implicit session logout (by reuse of ISID with 4179 TSID=0) cleared this session instance. This 4180 results in the freeing of all associated resources 4181 and the session state is discarded. 4182 -target: Session state timeout occurred, or an 4183 implicit session logout (by reuse of ISID with 4184 TSID=0) cleared this session instance. This 4185 results in the freeing of all associated resources 4186 and the session state is discarded. 4187 -N7: 4188 -initiator: Illegal 4190 Julian Satran Expires August 2002 17 4192 iSCSI 20-January-02 4194 -target: A session continuation attempt is initi- 4195 ated. 4196 -N8: 4197 -initiator: Illegal 4198 -target: The last session continuation attempt 4199 failed. 4200 -N9: 4201 -initiator: Illegal 4202 -target: Login attempt on the leading connection 4203 failed. 4204 -N10: 4205 -initiator: Illegal 4206 -target: A session continuation attempt succeeded. 4208 Julian Satran Expires August 2002 18 4210 iSCSI 20-January-02 4212 1. iSCSI Error Handling and Recovery 4214 For any outstanding SCSI command, it is assumed that 4215 iSCSI, in conjunction with SCSI at the initiator, is able 4216 to keep enough information to be able to rebuild the com- 4217 mand PDU, and that outgoing data is available (in host 4218 memory) for retransmission while the command is outstand- 4219 ing. It is also assumed that at target, incoming data 4220 (read data) MAY be kept for recovery or it can be re-read 4221 from a device server. 4223 It is further assumed that a target will keep the "status 4224 & sense" for a command it has executed if it supports sta- 4225 tus retransmission. 4227 Many of the recovery details in an iSCSI implementation 4228 are a local matter, beyond the scope of protocol standard- 4229 ization. However, some external aspects of the processing 4230 must be standardized to ensure interoperability. This 4231 section describes a general model for recovery in support 4232 of interoperability. See Appendix F. - Algorithmic Pre- 4233 sentation of Error Recovery Classes - for further detail. 4234 Compliant implementations do not have to match the imple- 4235 mentation details of this model as presented, but the 4236 external behavior of such implementations must correspond 4237 to the externally observable characteristics of the pre- 4238 sented model. 4240 1.1 Retry and Reassign in Recovery 4242 This section summarizes two important and somewhat 4243 related iSCSI protocol features used in error recovery. 4245 1.1.1 Usage of Retry 4247 By resending the same iSCSI command PDU ("retry") in the 4248 absence of a command acknowledgement or response, an ini- 4249 tiator attempts to "plug" (what it thinks are) the discon- 4250 tinuities in CmdSN ordering on the target end. Discarded 4251 command PDUs, due to digest errors, may have created these 4252 discontinuities. 4254 Julian Satran Expires August 2002 1 4256 iSCSI 20-January-02 4258 Retry MUST NOT be used for reasons other than plugging 4259 command sequence gaps. In particular, all PDU retransmis- 4260 sion (for data, or status) requests for a currently alle- 4261 giant command in progress must be conveyed to the target 4262 using only the SNACK mechanism already described. This, 4263 however, does not constitute a requirement on initiators 4264 to use SNACK. 4266 If initiators, as part of plugging command sequence gaps 4267 as described above, inadvertently issue retries for alle- 4268 giant commands already in progress (i.e., targets did not 4269 see the discontinuities in CmdSN ordering), targets MUST 4270 silently discard the duplicate requests if the CmdSN win- 4271 dow had not advanced by then. Targets MUST support the 4272 retry functionality described above. 4274 When an iSCSI command is retried, the command PDU MUST 4275 carry the original Initiator Task Tag and the original 4276 operational attributes (e.g., flags, function names, LUN, 4277 CDB etc.) as well as the original CmdSN. The command being 4278 retried MUST be sent on the same connection as the origi- 4279 nal command unless the original connection was already 4280 successfully logged out. 4282 1.1.2 Allegiance Reassignment 4284 By issuing a "task reassign" task management command (Sec- 4285 tion 10.5.1 Function), the initiator signals its intent to 4286 continue an already active command (but with no current 4287 connection allegiance) as part of connection recovery. 4288 This means that a new connection allegiance is established 4289 for the command, that associates it to the connection on 4290 which the task management command is being issued. 4292 In reassigning connection allegiance for a command, the 4293 targets SHOULD continue the command from its current 4294 state, for example taking advantage of ExpDataSN in the 4295 command PDU for read commands (which must be set to zero 4296 if there was no data transfer). However, targets MAY 4297 choose to send/receive the entire data on a reassignment 4298 of connection allegiance, and it is not considered an 4299 error. 4301 Julian Satran Expires August 2002 2 4303 iSCSI 20-January-02 4305 It is optional for targets to support the allegiance reas- 4306 signment. This capability is negotiated via the ErrorRe- 4307 coveryLevel text key at the login time. When a target 4308 does not support allegiance reassignment, it MUST respond 4309 with a task management response code of "Task failover not 4310 supported". If allegiance reassignment is supported by 4311 the target, but the task is still allegiant to a different 4312 connection, the target MUST respond with a task management 4313 response code of "Task still allegiant". 4315 1.2 Usage Of Reject PDU in Recovery 4317 Targets MUST NOT implicitly terminate an active task by 4318 sending a Reject PDU for any PDU exchanged during the 4319 life of the task. If the target decides to terminate 4320 the task, a Response PDU (SCSI, Text, Task etc.) must be 4321 returned by the target to conclude the task. If the task 4322 had never been active before the Reject (i.e., the Reject 4323 is on the command PDU), targets should not send any fur- 4324 ther responses since the command itself is being dis- 4325 carded. 4327 The above rule means that the initiators can eventually 4328 expect a response even on Rejects, if the Reject is not 4329 for the command itself. The non-command Rejects only have 4330 diagnostic value in logging the errors, and they can be 4331 used for retransmission decisions by the initiators. 4333 The CmdSN of the rejected PDU (if it carried one) MUST NOT 4334 be considered received by the target (i.e., a command 4335 sequence gap must be assumed for the CmdSN). This is true 4336 even when the CmdSN can be reliably ascertained, as in the 4337 case of a data digest error on immediate data. However, 4338 when the DataSN of a rejected data PDU can be ascertained, 4339 a target MUST advance ExpDataSN for the current burst if a 4340 recovery R2T is being generated. The target MAY advance 4341 its ExpDataSN if it does not attempt to recover the lost 4342 data PDU. 4344 1.3 Format Errors 4346 Explicit violations of the PDU layout rules stated in this 4347 document are format errors. Violations, when detected, 4349 Julian Satran Expires August 2002 3 4351 iSCSI 20-January-02 4353 usually indicate a major implementation flaw in one of the 4354 parties. 4356 When a target or an initiator receives an iSCSI PDU with a 4357 format error, it MUST immediately terminate all transport 4358 connections in the session either with a connection close 4359 or with a connection reset and escalate the format error 4360 to session recovery (see Section 1.11.4 Session Recov- 4361 ery). 4363 1.4 Digest Errors 4365 The discussion of the legal choices in handling digest 4366 errors below excludes session recovery as an explicit 4367 option, but either party detecting a digest error may 4368 choose to escalate the error to session recovery. 4370 When a target receives any iSCSI PDU with a header digest 4371 error, it MUST silently discard the PDU. 4373 When a target receives any iSCSI PDU with a payload digest 4374 error, it MUST answer with a Reject iSCSI PDU with a Rea- 4375 son-code of Data-Digest-Error and discard the PDU. 4377 - If the discarded PDU is a solicited or unsolicited 4378 iSCSI data PDU (for immediate data in a command 4379 PDU, non-data PDU rule below applies), the target 4380 MUST do one of the following: 4381 a) Request retransmission with a recovery R2T. [OR] 4382 b) Terminate the task with a response PDU with the 4383 reason "protocol service CRC error" (Section 10.4.3 4384 Response). If the target chooses to implement this 4385 option, it MUST wait to receive all the data (signaled 4386 by a Data PDU with the final bit set for all outstand- 4387 ing R2Ts) before sending the response PDU. A task man- 4388 agement command (similar to an abort task) from the 4389 initiator during this wait may also conclude the task. 4390 - No further action is necessary for targets if the 4391 discarded PDU is a non-data PDU. 4393 When an initiator receives any iSCSI PDU with a header 4394 digest error, it MUST discard the PDU. 4396 Julian Satran Expires August 2002 4 4398 iSCSI 20-January-02 4400 LS:When an initiator receives any iSCSI PDU with a payload 4401 digest error, it MUST discard the PDU. 4403 - If the discarded PDU is an iSCSI data PDU, the ini- 4404 tiator MUST do one of the following: 4405 a) Request the desired data PDU through SNACK. In its 4406 turn, the target MUST either resend the data PDU or, 4407 reject the SNACK with a Reject PDU with a reason-code 4408 of "Data-SNACK Reject" in which case - 4409 i) if the status had not already been sent 4410 for the command, the target MUST terminate the 4411 command with an iSCSI response reason(Section 4412 10.4.3 Response) of "SNACK rejected". 4413 ii) if the status was already sent, no fur- 4414 ther action is necessary for the target. Ini- 4415 tiator in this case MUST internally signal the 4416 completion with the "SNACK rejected" reason 4417 (Section 10.4.3 Response) disregarding any 4418 received status PDU, but must wait for the sta- 4419 tus to be received before doing so. [OR] 4420 b) Abort the task and terminate the command with an 4421 error. 4423 - If the discarded PDU is a response PDU, the initi- 4424 ator MUST do one of the following: 4425 a) Request PDU retransmission with a status SNACK. 4426 [OR] 4427 b) Logout the connection for recovery and continue the 4428 tasks on a different connection instance as described 4429 in Section 1.1 Retry and Reassign in Recovery. [OR] 4430 c) Logout to close the connection (abort all the com- 4431 mands associated with the connection). 4433 - No further action is necessary for initiators if 4434 the discarded PDU is an unsolicited PDU (e.g., 4435 Async, Reject). 4437 1.5 Sequence Errors 4439 When an initiator receives an iSCSI R2T/data PDU with an 4440 out-of-order R2TSN/DataSN or a SCSI response PDU with an 4441 ExpDataSN that implies missing data PDU(s), it means that 4442 the initiator must have hit a header or payload digest 4443 error on one or more earlier R2T/data PDUs. The initiator 4445 Julian Satran Expires August 2002 5 4447 iSCSI 20-January-02 4449 MUST address these implied digest errors as described in 4450 Section 1.4 Digest Errors. When a target receives a data 4451 PDU with an out-of-order DataSN, it means that the target 4452 must have hit a header or payload digest error on at least 4453 one of the earlier data PDUs. Target MUST address these 4454 implied digest errors as described in Section 1.4 Digest 4455 Errors. 4457 When an initiator receives an iSCSI status PDU with an 4458 out-of-order StatSN that implies missing responses, it 4459 MUST address the one or more missing status PDUs as 4460 described in Section 1.4 Digest Errors. As a side effect 4461 of receiving the missing responses, the initiator may dis- 4462 cover missing data PDUs. If the initiator wants to recover 4463 the missing data for a command, it MUST NOT acknowledge 4464 the received responses that start from the StatSN of the 4465 interested command, until it has completed receiving all 4466 the data PDUs of the command. 4468 When an initiator receives duplicate R2TSNs (due to proac- 4469 tive retransmission of R2Ts by the target) or duplicate 4470 DataSNs (due to proactive SNACKs by the initiator), it 4471 MUST discard the duplicates. 4473 1.6 SCSI Timeouts 4475 An iSCSI initiator MAY attempt to plug a command sequence 4476 gap on the target end (in the absence of an acknowledge- 4477 ment of the command by way of ExpCmdSN) before the ULP 4478 timeout by retrying the unacknowledged command, as 4479 described in Section 1.1 Retry and Reassign in Recovery. 4481 On a ULP timeout for a command (that carried a CmdSN of 4482 n), the iSCSI initiator MUST abort the command by either 4483 using the Abort Task task management function request, or 4484 a "close the connection" Logout if it intends to continue 4485 the session. In using an explicit Abort, if the ExpCmdSN 4486 is still less than (n+1), the target may see the abort 4487 request while missing the original command itself due to 4488 one of the following reasons: 4490 - The original command was dropped due to digest 4491 error. 4493 Julian Satran Expires August 2002 6 4495 iSCSI 20-January-02 4497 - The connection on which the original command was 4498 sent was successfully logged out (on logout, the 4499 unacknowledged commands issued on the connection 4500 being logged out are discarded). 4502 If the abort request is received and the original command 4503 is missing, targets MUST consider the original command 4504 with that RefCmdSN to be received and issue a task manage- 4505 ment response with the response code: "Task does not 4506 exist". This response concludes the task on both ends. 4508 1.7 Negotiation Failures 4510 Text request and response sequences, when used to set/ 4511 negotiate operational parameters, constitute the negotia- 4512 tion/parameter setting. A negotiation failure is consid- 4513 ered one or more of the following: 4515 - None of the choices or the stated value is accept- 4516 able to one negotiating side. 4517 - The text request timed out, and possibly aborted. 4518 - The text request was answered with a reject. 4520 The following two rules are to be used to address negoti- 4521 ation failures: 4523 - During Login, any failure in negotiation MUST be 4524 considered a login process failure and the login 4525 phase must be terminated, and with it the connec- 4526 tion. If the target detects the failure, it must 4527 terminate the login with the appropriate login 4528 response code. 4530 - A failure in negotiation, while in the full-feature 4531 phase, will terminate the entire negotiation 4532 sequence that may consist of a series of text 4533 requests that use the same Initiator Task Tag. The 4534 operational parameters of the session or the con- 4535 nection MUST continue to be the values agreed upon 4536 during an earlier successful negotiation (i.e., any 4537 partial results of this unsuccessful negotiation 4538 must be undone). 4540 Julian Satran Expires August 2002 7 4542 iSCSI 20-January-02 4544 1.8 Protocol Errors 4546 The authors recognize that mapping framed messages over a 4547 "stream" connection, such as TCP, make the proposed mech- 4548 anisms vulnerable to simple software framing errors. On 4549 the other hand, the introduction of framing mechanisms to 4550 limit the effects of these errors may be onerous on per- 4551 formance for simple implementations. Command Sequence 4552 Numbers and the above mechanisms for connection drop and 4553 re-establishment help handle this type of mapping errors. 4555 All violations of iSCSI PDU exchange sequences specified 4556 in this draft are also protocol errors. This category of 4557 errors can be only be 4558 addressed by fixing the implementations; iSCSI defines 4559 Reject and response codes to enable this. 4561 1.9 Connection Failures 4563 iSCSI can keep a session in operation if it is able to 4564 keep/establish at least one TCP connection between the 4565 initiator and the target in a timely fashion. It is 4566 assumed that targets and/or initiators recognize a fail- 4567 ing connection by either transport level means (TCP), a 4568 gap in the command, a response stream that is not filled 4569 for a long time, or by a failing iSCSI NOP (ping). The 4570 latter MAY be used periodically by highly reliable imple- 4571 mentations. Initiators and targets MAY also use the keep- 4572 alive option on the TCP connection to enable early link 4573 failure detection on otherwise idle links. 4575 On connection failure, the initiator and target MUST do 4576 one of the following: 4578 - Attempt connection recovery within the session 4579 (Section 1.11.3 Connection Recovery). 4580 - Logout the connection with the reason code "closes 4581 the connection" (Section 10.14.3 Reason Code), re- 4582 issue missing commands, and implicitly terminate 4583 all active commands. This option requires support 4584 for the within-connection recovery class (Section 4585 1.11.2 Recovery Within-connection). 4586 - Perform session recovery (Section 1.11.4 Session 4587 Recovery). 4589 Julian Satran Expires August 2002 8 4591 iSCSI 20-January-02 4593 Either side may choose to escalate to session recovery, 4594 and the other side MUST give it precedence. On a connec- 4595 tion failure, a target MUST terminate and/or discard all 4596 the active immediate commands regardless of which of the 4597 above options is used (i.e., immediate commands are not 4598 recoverable across connection failures). 4600 1.10 Session Errors 4602 If all the connections of a session fail and cannot be re- 4603 established in a short time, or if initiators detect pro- 4604 tocol errors repeatedly, an initiator may choose to termi- 4605 nate a session and establish a new session. 4606 The initiator takes the following actions: 4608 - It resets or closes all the transport connections. 4609 - It terminates all outstanding requests with an 4610 appropriate response before initiating a new ses- 4611 sion. 4613 When the session timeout (the connection state timeout for 4614 the last failed connection) happens on the target, it 4615 takes the following actions: 4617 - Resets or closes the TCP connections (closes the 4618 session). 4619 - Aborts all Tasks in the task set for the corre- 4620 sponding initiator. 4622 1.11 Recovery Classes 4624 iSCSI enables the following classes of recovery (in the 4625 order of increasing scope of affected iSCSI tasks): 4627 - Within a command (i.e., without requiring command 4628 restart). 4629 - Within a connection (i.e., without requiring the 4630 connection to be rebuilt, but perhaps requiring 4631 command restart). 4632 - Connection recovery (i.e., perhaps requiring con- 4633 nections to be rebuilt and commands to be reis- 4634 sued). 4635 - Session recovery. 4637 The recovery scenarios detailed in the rest of this sec- 4638 tion are representative rather than exclusive. In every 4640 Julian Satran Expires August 2002 9 4642 iSCSI 20-January-02 4644 case, they detail the lowest class recovery that MAY be 4645 attempted. The implementer is left to decide under which 4646 circumstances to escalate to the next recovery class and/ 4647 or what recovery classes to implement. Both the iSCSI 4648 target and initiator MAY escalate the error handling to an 4649 error recovery class, which impacts a larger number of 4650 iSCSI tasks in any of the cases identified in the follow- 4651 ing discussion. 4653 In all classes, the implementer has the choice of defer- 4654 ring errors to the SCSI initiator (with an appropriate 4655 response code), in which case the task, if any, has to be 4656 removed from the target and all the side-effects, such as 4657 ACA, must be considered. 4659 Use of within-connection and within-command recovery 4660 classes MUST NOT be attempted before the connection is in 4661 full feature phase. 4663 1.11.1 Recovery Within-command 4665 At the target, the following cases lend themselves to 4666 within-command recovery: 4668 - Lost data PDU - realized through one of the follow- 4669 ing: 4670 a) Data digest error - dealt with as specified in Sec- 4671 tion 1.4 Digest Errors, using the option of a recovery 4672 R2T. 4673 b) Sequence reception timeout (no data or partial- 4674 data-and-no-F-bit) - considered an implicit sequence 4675 error and dealt with as specified in Section 1.5 4676 Sequence Errors, using the option of a recovery R2T. 4677 c) Header digest error, which manifests as a sequence 4678 reception timeout, or a sequence error - dealt with as 4679 specified in Section 1.5 Sequence Errors, using the 4680 option of a recovery R2T. 4682 At the initiator, the following cases lend themselves to 4683 within-command recovery: 4685 Lost data PDU or lost R2T - realized through one of 4686 the following: 4688 Julian Satran Expires August 2002 10 4690 iSCSI 20-January-02 4692 a) Data digest error - dealt with as specified in Sec- 4693 tion 1.4 Digest Errors, using the option of a SNACK. 4694 b) Sequence reception timeout (no status) - dealt with 4695 as specified in Section 1.5 Sequence Errors, using the 4696 option of a SNACK. 4697 c) Header digest error, which manifests as a sequence 4698 reception timeout, or a sequence error - dealt with as 4699 specified in Section 1.5 Sequence Errors, using the 4700 option of a SNACK. 4702 To avoid a race with the target, which may already have a 4703 recovery R2T or a termination response on its way, an ini- 4704 tiator SHOULD NOT originate a SNACK for an R2T based on 4705 its internal timeouts (if any). Recovery in this case is 4706 better left to the target. 4708 The timeout values used by the initiator and target are 4709 outside the scope of this document. Sequence reception 4710 timeout is generally a large enough value to allow the 4711 data sequence transfer to be complete. 4713 1.11.2 Recovery Within-connection 4715 At the initiator, the following cases lend themselves to 4716 within-connection recovery: 4718 - Requests not acknowledged for a long time. Requests 4719 are acknowledged explicitly through ExpCmdSN or 4720 implicitly by receiving data and/or status. The 4721 initiator MAY retry non-acknowledged commands as 4722 specified in Section 1.1 Retry and Reassign in 4723 Recovery. 4725 - Lost iSCSI numbered Response. It is recognized by 4726 either identifying a data digest error on a 4727 Response PDU or a Data-In PDU carrying the status, 4728 or by receiving a Response PDU with a higher StatSN 4729 than expected. In the first case, digest error han- 4730 dling is done as specified in Section 1.4 Digest 4731 Errors using the option of a SNACK. In the second 4732 case, sequence error handling is done as specified 4733 in Section 1.5 Sequence Errors, using the option of 4734 a SNACK. 4736 At the target, the following cases lend themselves to 4737 within-connection recovery: 4739 Julian Satran Expires August 2002 11 4741 iSCSI 20-January-02 4743 - Status/Response not acknowledged for a long time. 4744 The target MAY issue a NOP-IN (with a valid Target 4745 Transfer Tag or otherwise) that carries the next 4746 status sequence number it is going to use in the 4747 StatSN field. This helps the initiator detect any 4748 missing StatSN(s) and issue a SNACK for the status. 4750 The timeout values used by the initiator and the target 4751 are outside the scope of this document. 4753 1.11.3 Connection Recovery 4755 At an iSCSI initiator, the following cases lend themselves 4756 to connection recovery: 4758 - TCP connection failure. The initiator MUST close 4759 the connection. It then MUST either Logout the 4760 failed connection, or Login with an implied Logout, 4761 and reassign connection allegiance for all commands 4762 associated with the failed connection on another 4763 connection (that MAY be a newly established connec- 4764 tion) using the "Task reassign" task management 4765 function (see Section 10.5.1 Function). 4767 - N.B. The logout function is mandatory, while a new 4768 connection establishment is mandatory only if the 4769 failed connection was the last or only connection 4770 in the session. 4772 - Receiving an Asynchronous Message that indicates 4773 one or all connections in a session has been 4774 dropped. The initiator MUST handle it as a TCP 4775 connection failure for the connection(s) referred 4776 to in the Message. 4778 At an iSCSI target, the following cases lend themselves to 4779 connection recovery: 4781 - TCP connection failure. The target MUST close the 4782 connection and if more than one connection is 4783 available, the target SHOULD send an Asynchronous 4784 Message that indicates it has dropped the connec- 4785 tion. Then, the target will wait for the initiator 4786 to continue recovery. 4788 Julian Satran Expires August 2002 12 4790 iSCSI 20-January-02 4792 1.11.4 Session Recovery 4794 Session recovery should be performed when all other recov- 4795 ery attempts have failed. Very simple initiators and tar- 4796 gets MAY perform session recovery on all iSCSI errors and 4797 therefore, place the burden of recovery on the SCSI layer 4798 and above. 4800 Session recovery implies the closing of all TCP connec- 4801 tions, internally aborting all executing and queued tasks 4802 for the given initiator at the target, terminating all 4803 outstanding SCSI commands with an appropriate SCSI ser- 4804 vice response at the initiator, and restarting a session 4805 on a new set of connection(s) (TCP connection establish- 4806 ment and login on all new connections). 4808 Reserve-Release managed SCSI reservations ("Regular" res- 4809 ervations) that are secured during a given iSCSI session 4810 persist until they are cleared using regular SCSI means or 4811 (in the absence of such,) until the session object is 4812 cleared - i.e. when the FREE state is reached. Only the 4813 session continuation (section 6.3) therefore preserves 4814 the Regular reservations. 4816 Persistent SCSI reservations are not affected by iSCSI 4817 session failures, and only the regular SCSI means can be 4818 used to handle these reservations when the session is 4819 reconstructed (necessarily between the same SCSI ports 4820 and so with the same nexus identifier). 4822 1.12 Error Recovery Hierarchy 4824 The error recovery classes and features described are 4825 organized into a hierarchy for ease in understanding and 4826 to limit the myriad of implementation possibilities, with 4827 hopes that this significantly contributes to highly 4828 interoperable implementations. The attributes of this 4829 hierarchy are as follows: 4831 a) Each level is a superset of the capabilities of the 4832 previous level. For example, Level 1 support implies 4833 supporting all capabilities of Level 0 and more. 4835 Julian Satran Expires August 2002 13 4837 iSCSI 20-January-02 4839 b) As a corollary, supporting a higher error recovery 4840 level means increased sophistication and possibly an 4841 increase in resource requirement. 4842 c) Supporting error recovery level "n" is advertised 4843 and negotiated by each iSCSI entity by exchanging the 4844 text key "ErrorRecoveryLevel=n". The lower of the two 4845 exchanged values is the operational ErrorRecoveryLevel 4846 for the session. 4848 The following diagram represents the error recovery hier- 4849 archy. 4851 + 4852 / \ 4853 / 2 \ <-- Connection recovery 4854 +-----+ 4855 / 1 \ <-- Digest failure 4856 recovery 4857 +---------+ 4858 / 0 \ <-- Session failure 4859 recovery 4860 +-------------+ 4862 The following table lists the error recovery capabilities 4863 expected from the implementations that support each error 4864 recovery level. 4866 Julian Satran Expires August 2002 14 4868 iSCSI 20-January-02 4870 +-------------------+------------------------------------ 4871 --------+ 4872 |ErrorRecoveryLevel | Associated Error recovery capabil- 4873 ities | 4874 +-------------------+------------------------------------ 4875 --------+ 4876 | 0 | Session recovery class 4877 | 4878 | | (Section 1.11.4 Session Recovery) 4879 | 4880 +-------------------+------------------------------------ 4881 --------+ 4882 | 1 | Digest failure recovery (See Note 4883 below.) | 4884 +-------------------+------------------------------------ 4885 --------+ 4886 | 2 | Connection recovery class 4887 | 4888 | | (Section 1.11.3 Connection Recovery) 4889 | 4890 +-------------------+------------------------------------ 4891 --------+ 4893 Note: Digest failure recovery is comprised of two recovery 4894 classes: Within-Connection recovery class (Section 1.11.2 4895 Recovery Within-connection) and Within-Command recovery 4896 class (Section 1.11.1 Recovery Within-command). 4898 Supporting error recovery level "0" is mandatory, while 4899 the rest are optional to implement. In implementation 4900 terms, the above striation means that the following incre- 4901 mental sophistication with each level is required. 4903 Julian Satran Expires August 2002 15 4905 iSCSI 20-January-02 4907 +-------------------+------------------------------------ 4908 ---------+ 4909 |Level transition | Incremental require- 4910 ment | 4911 +-------------------+------------------------------------ 4912 ---------+ 4913 | 0->1 | PDU retransmissions on the same con- 4914 nection | 4915 +-------------------+------------------------------------ 4916 ---------+ 4917 | 1->2 | Retransmission across connections 4918 and | 4919 | | allegiance reassign- 4920 ment | 4921 +-------------------+------------------------------------ 4922 ---------+ 4924 Julian Satran Expires August 2002 16 4926 iSCSI 20-January-02 4928 1. Security Considerations 4930 Historically, native storage systems have not had to con- 4931 sider security because their environments offered minimal 4932 security risks. That is, these environments consisted of 4933 storage devices either directly attached to hosts or con- 4934 nected via a subnet distinctly separate from the communi- 4935 cations network. The use of storage protocols, such as 4936 SCSI, over IP networks requires that security concerns be 4937 addressed. iSCSI implementations MUST provide means of 4938 protection against active attacks (e.g., pretending to be 4939 another identity, message insertion, deletion, modifica- 4940 tion, and replaying) and passive attacks (e.g.,eavesdrop- 4941 ping, gaining advantage by analyzing the data sent over 4942 the line). 4944 Although technically possible, iSCSI SHOULD NOT be con- 4945 figured without security. iSCSI without security should 4946 be confined, in extreme cases, to closed environments 4947 without any security risk. 4949 The following section describes the security mechanisms 4950 provided by an iSCSI implementation. 4952 1.1 iSCSI Security Mechanisms 4954 The entities involved in iSCSI security are the initiator, 4955 target, and the IP communication end points. iSCSI scenar- 4956 ios where multiple initiators or targets share a single 4957 communication end point are expected. To accommodate such 4958 scenarios, iSCSI uses two separate security mechanisms: 4959 In-band authentication between the initiator and the tar- 4960 get at the iSCSI connection level (carried out by exchange 4961 of iSCSI Login PDUs), and packet protection (integrity, 4962 authentication, and confidentiality) by IPsec at the IP 4963 level. The two security mechanisms complement each other: 4964 The in-band authentication provides end-to-end trust (at 4965 login time) between the iSCSI initiator and the target, 4966 while IPsec provides a secure channel between the IP com- 4967 munication end points. 4969 Julian Satran Expires August 2002 1 4971 iSCSI 20-January-02 4973 Further details on typical iSCSI scenarios and the rela- 4974 tion between the initiators, targets, and the communica- 4975 tion end points can be found in [SEC-IPS]. 4977 1.2 In-band Initiator-Target Authentication 4979 With this mechanism, the target authenticates the initia- 4980 tor and the initiator optionally authenticates the tar- 4981 get. The authentication is performed on every new iSCSI 4982 connection by an exchange of iSCSI Login PDUs using a 4983 negotiated authentication method. 4985 The authentication method cannot assume an underlying 4986 IPsec protection, since IPsec is optional to use. An 4987 attacker should gain as little advantage as possible by 4988 inspecting the authentication phase PDUs. Therefore, a 4989 method using clear text (or equivalent) passwords is not 4990 acceptable; on the other hand, identity protection is not 4991 strictly required. 4993 This mechanism protects against an unauthorized login to 4994 storage resources by using a false identity (spoofing). 4995 Once the authentication phase is completed, if the under- 4996 lying IPsec is not used, all PDUs are sent and received in 4997 clear. This mechanism alone (without underlying IPsec) 4998 should only be used when there is no risk of eavesdrop- 4999 ping, message insertion, deletion, modification, and 5000 replaying. 5002 The CHAP authentication method (see Chapter 13) is vulner- 5003 able to an off-line dictionary attack. In environments 5004 where this attack is a concern, CHAP SHOULD NOT be used 5005 without additional protection. Underlying IPsec encryp- 5006 tion provides protection against this attack. 5008 The strength of the SRP authentication method (specified 5009 in Chapter 13) is dependent on the characteristics of the 5010 group being used (i.e., the prime modulus N and generator 5011 g). As described in [RFC2945], N is required to be a 5012 Sophie-German prime (of the form N = 2q + 1, where q is 5013 also prime) and the generator g is a primitive root of 5015 Julian Satran Expires August 2002 2 5017 iSCSI 20-January-02 5019 GF(n). In iSCSI authentication, the prime modulus N MUST 5020 be at least 768 bits. 5022 Upon receiving N and g from the Target, the Initiator MUST 5023 verify that they satisfy the above requirements (and oth- 5024 erwise, abort the connection). This verification MAY 5025 start by trying to match N and g with a well-known group 5026 that satisfies the above requirements. 5027 Well-known SRP groups are provided in [SEC-IPS]. 5029 Compliant iSCSI initiators and targets MUST at least 5030 implement the SRP authentication method [RFC2945] (see 5031 Chapter 11). 5033 1.3 IPsec 5035 The IPsec mechanism is used by iSCSI for packet protection 5036 (cryptographic integrity, authentication, and confidenti- 5037 ality) at the IP level between the iSCSI communicating end 5038 points. The following sections describe the IPsec proto- 5039 cols that must be implemented for data integrity and 5040 authentication, confidentiality, and key management. 5042 Detailed considerations and recommendations for using 5043 IPsec for iSCSI are provided in [SEC-IPS]. 5045 1.3.1 Data Integrity and Authentication 5047 Data authentication and integrity is provided by a keyed 5048 Message Authentication Code in every sent packet. This 5049 code protects against message insertion, deletion, and 5050 modification. Protection against message replay is real- 5051 ized by using a sequence counter. 5053 An iSCSI compliant initiator or target MUST provide data 5054 integrity and authentication by implementing IPsec 5055 [RFC2401] with ESP in tunnel mode [RFC2406] with the fol- 5056 lowing iSCSI specific requirements: 5058 - HMAC-SHA1 MUST be implemented [RFC2404]. 5059 - AES CBC MAC with XCBC extensions SHOULD be imple- 5060 mented [AES], [XCBC] (NOTE: Still subject to the 5061 IETF-IPsec WG's standardization plans). 5063 Julian Satran Expires August 2002 3 5065 iSCSI 20-January-02 5067 The ESP anti-replay service MUST also be implemented. 5069 At the high speeds iSCSI is expected to operate, a single 5070 IPsec SA could rapidly cycle through the 32-bit IPsec 5071 sequence number space. 5072 In view of this, an iSCSI implementation that operates at 5073 speeds of 1 Gbps or less MAY implement the IPsec sequence 5074 number extension [SEQ-EXT]. 5075 Implementation operation at speeds of 10 Gbps or faster 5076 SHOULD implement the sequence number extension. 5078 1.3.2 Confidentiality 5080 Confidentiality is provided by encrypting the data in 5081 every packet. Confidentiality SHOULD always be used 5082 together with data integrity and authentication to pro- 5083 vide comprehensive protection against eavesdropping, mes- 5084 sage insertion, deletion, modification, and replaying. 5086 An iSCSI compliant initiator or target MUST provide confi- 5087 dentiality by implementing IPsec [RFC2401] with ESP in 5088 tunnel mode [RFC2406] with the following iSCSI specific 5089 requirements: 5091 - 3DES in CBC mode MUST be implemented [RFC2451]. 5092 - AES in Counter mode SHOULD be implemented [AESCTR] 5093 (NOTE: This is still subject to the IPsec WG's 5094 standardization plans). 5096 DES in CBC mode SHOULD NOT be used due to its inherent 5097 weakness. 5098 The NULL encryption algorithm MUST also be implemented. 5100 1.3.3 Security Associations and Key Management 5102 A compliant iSCSI implementation MUST meet the key manage- 5103 ment requirements of the IPsec protocol suite. Authenti- 5104 cation, security association negotiation, and key 5105 management MUST be provided by implementing IKE [RFC2409] 5106 using the IPsec DOI [RFC2407] with the following iSCSI 5107 specific requirements: 5109 Julian Satran Expires August 2002 4 5111 iSCSI 20-January-02 5113 - Peer authentication using a pre-shared key MUST be 5114 supported. Certificate-based peer authentication 5115 using digital signatures MAY be supported. Peer 5116 authentication using the public key encryption 5117 methods outlined in IKE sections 5.2 and 5.3[7] 5118 SHOULD NOT be used. 5120 - When digital signatures are used to achieve authen- 5121 tication, an IKE negotiator SHOULD use IKE Certifi- 5122 cate Request Payload(s) to specify the certificate 5123 authority. IKE negotiators SHOULD check the perti- 5124 nent Certificate Revocation List (CRL) before 5125 accepting a PKI certificate for use in IKE authen- 5126 tication procedures. 5128 - Both IKE Main Mode and Aggressive Mode MUST be sup- 5129 ported. IKE main mode with pre-shared key authenti- 5130 cation method SHOULD NOT be used when either the 5131 initiator or the target uses dynamically assigned 5132 IP addresses. While pre-shared keys in many cases 5133 offer good security, situations where dynamically 5134 assigned addresses are used force the use of a 5135 group pre-shared key, which creates vulnerability 5136 to a man-in-the-middle attack. 5138 - In the IKE Phase 2 Quick Mode exchanges for creat- 5139 ing the Phase 2 SA, the Identity Payload fields 5140 MUST be present, and MUST carry individual 5141 addresses and MUST NOT use the IP Subnet or IP 5142 Address Range formats. 5144 Manual keying MUST NOT be used since it does not provide 5145 the necessary re-keying support. 5147 When IPsec is used, each iSCSI TCP connection within an 5148 iSCSI session MUST be protected by a separate IKE Phase 2 5149 SA. The receipt of an IKE Phase 2 delete message SHOULD 5150 NOT be interpreted as a reason for tearing down the con- 5151 nection. If additional traffic is sent on it, a new IKE 5152 Phase 2 SA will be created to protect it. 5154 Julian Satran Expires August 2002 5 5156 iSCSI 20-January-02 5158 1. Notes to Implementers 5160 This section notes some of the performance and reliability 5161 considerations of the iSCSI protocol. This protocol was 5162 designed to allow efficient silicon and software imple- 5163 mentations. The iSCSI tag mechanism was designed to enable 5164 RDMA at the iSCSI level or lower. 5166 The guiding assumption made throughout the design of this 5167 protocol is that targets are resource constrained rela- 5168 tive to initiators. 5170 Implementers are also advised to consider the implementa- 5171 tion consequences of the iSCSI to SCSI mapping model as 5172 outlined in Section 2.4.3 Consequences of the Model. 5174 1.1 Multiple Network Adapters 5176 The iSCSI protocol allows multiple connections, not all of 5177 which need to go over the same network adapter. If multi- 5178 ple network connections are to be utilized with hardware 5179 support, the iSCSI protocol command-data-status alle- 5180 giance to one TCP connection ensures that there is no need 5181 to replicate information across network adapters or oth- 5182 erwise require them to cooperate. 5184 However, some task management commands may require some 5185 loose form of cooperation or replication at least on the 5186 target. 5188 1.1.1 Conservative Reuse of ISIDs 5190 Historically, the SCSI model (and implementations and 5191 applications based on that model) has assumed that SCSI 5192 ports are static, physical entities. Recent extensions to 5193 the SCSI model have taken advantage of persistent world- 5194 wide unique names for these ports. In iSCSI however, the 5195 SCSI initiator ports are the endpoints of dynamically cre- 5196 ated sessions, so the presumption of "static and physical" 5197 does not apply. In any case, the model clauses (particu- 5198 larly, Section 2.4.2 SCSI Architecture Model) provide for 5199 persistent, reusable names for the iSCSI-type SCSI initi- 5201 Julian Satran Expires August 2002 1 5203 iSCSI 20-January-02 5205 ator ports even though there does not need to be any phys- 5206 ical entity bound to these names. 5208 To both minimize the disruption of legacy applications and 5209 to better facilitate the SCSI features that rely on per- 5210 sistent names for SCSI ports, iSCSI implementations 5211 should attempt to provide a stable presentation of SCSI 5212 Initiator Ports (both to the upper OS-layers and to the 5213 targets to which they connect). This can be achieved in an 5214 initiator implementation by conservatively reusing ISIDs. 5215 In other words, the same ISID should be used in the Login 5216 process to multiple target portal groups (of the same 5217 iSCSI Target or different iSCSI Targets). The ISID RULE 5218 (Section 2.4.3 Consequences of the Model) only prohibits 5219 reuse to the same target portal group. It does not "pre- 5220 clude" reuse to other target portal groups. 5221 The principle of conservative reuse "encourages" reuse to 5222 other target portal groups. When a SCSI target device 5223 sees the same (InitiatorName, ISID) pair in different ses- 5224 sions to different target portal groups, it can identify 5225 the underlying SCSI Initiator Port on each session as the 5226 same SCSI port. In effect, it can recognize multiple paths 5227 from the same source. 5229 1.1.2 iSCSI Name and ISID/TSID Use 5231 The designers of the iSCSI protocol envisioned there being 5232 one 5233 iSCSI Initiator Node Name per operating system image on a 5234 machine. This enables SAN resource configuration and 5235 authentication schemes based on a system's identity. It 5236 supports the notion that it should be possible to assign 5237 access to storage resources based on "initiator device" 5238 identity. 5240 When there are multiple hardware or software components 5241 coordinated as a single iSCSI Node, there must be some 5242 (logical) entity that represents the iSCSI Node that makes 5243 the iSCSI Node Name available to all components involved 5244 in session creation and login. Similarly, this entity that 5245 represents the iSCSI Node must be able to coordinate ses- 5246 sion identifier resources (ISID for initiators and TSID 5248 Julian Satran Expires August 2002 2 5250 iSCSI 20-January-02 5252 for targets) to enforce both the ISID and TSID RULES (see 5253 Section Section 2.4.3 Consequences of the Model). 5255 For targets, because of the closed environment, implemen- 5256 tation of this entity should be straightforward. However, 5257 vendors of iSCSI hardware (e.g., NICs or HBAs) intended 5258 for targets to provide mechanisms for configuration of the 5259 iSCSI Node Name and for configuration and/or coordination 5260 of TSIDs across the portal groups instantiated by multiple 5261 instances of these components within a target. One mecha- 5262 nism is to allow for static or dynamic partitioning of the 5263 TSID namespace among the portal groups. Such a partition- 5264 ing allows each portal group to act independently of other 5265 portal groups when assigning TSIDs, and facilitates 5266 enforcement of the TSID RULE (Section 2.4.3 Consequences 5267 of the Model). 5269 For initiators, in the long term, it is expected that 5270 operating system vendors will take on the role of this 5271 entity and provide standard APIs that can inform compo- 5272 nents of their iSCSI Node Name and can configure and/or 5273 coordinate ISID allocation, use and reuse. 5275 Recognizing that such initiator APIs are not available 5276 today, other implementations of the role of this entity 5277 are possible. 5278 For example, a human may instantiate the (common) Node 5279 name as part of the installation process of each iSCSI 5280 component involved in session creation and login. This may 5281 be done either by pointing the component to a vendor-spe- 5282 cific location for this datum or to a system-wide loca- 5283 tion. The structure of the ISID namespace (see Section 5284 10.12.6 ISID and [NDT]) facilitates implementation of the 5285 ISID coordination by allowing each component vendor to 5286 independently (of other vendor's components) coordinate 5287 allocation and use and reuse its own partition of the ISID 5288 namespace in a vendor-specific manner. Partitioning of 5289 the ISID namespace within initiator portal groups managed 5290 by that vendor allows each such initiator portal group to 5291 act independently of all other portal groups when select- 5292 ing an ISID for a login; this facilitates enforcement of 5293 the ISID RULE (see Section 2.4.3 Consequences of the 5294 Model) at the initiator. 5296 Julian Satran Expires August 2002 3 5298 iSCSI 20-January-02 5300 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended 5301 for use in the initiators must allow, in addition to a 5302 mechanism for configuring the iSCSI Node Name, for a mech- 5303 anism to configure and/or coordinate ISIDs for all ses- 5304 sions managed by multiple instances of that hardware 5305 within a given iSCSI Node. Such configuration might be 5306 either permanently pre-assigned at the factory (in a nec- 5307 essarily globally unique way), statically assigned (e.g., 5308 partitioned across all the NICs at initialization in a 5309 locally unique way), or dynamically assigned (e.g., on- 5310 line allocator, also in a locally unique way). In the 5311 latter two cases, the configuration may be via public APIs 5312 (perhaps driven by an independent vendor's SW, such as the 5313 OS vendor) or via private APIs driven by the vendor's own 5314 SW. 5316 1.2 Autosense and Auto Contingent Allegiance (ACA) 5318 Autosense refers to the automatic return of sense data to 5319 the initiator in case a command did not complete success- 5320 fully. iSCSI mandates support for autosense. 5322 ACA helps preserve ordered command execution in the pres- 5323 ence of errors. 5324 As iSCSI can have many commands in-flight between initia- 5325 tor and target, iSCSI mandates support for ACA. 5327 1.3 Command Retry and Cleaning Old Command Instances 5329 To avoid having old, retried command instances appear in a 5330 valid command window after a command sequence number wrap 5331 around, the protocol requires (see Section 2.2.2.1 Com- 5332 mand Numbering and Acknowledging) that on every connec- 5333 tion on which a retry has been issued, a non-immediate 5334 command be issued and acknowledged within a 2**31-1 com- 5335 mands interval since the retry was issued. This require- 5336 ment can be fulfilled by an implementation in several 5337 ways. 5339 The simplest technique to use is to send a (non-retry) 5340 non-immediate SCSI command (or a NOP if no SCSI command is 5341 available for a while) after every command retry on the 5342 connection on which the retry was attempted. As errors 5344 Julian Satran Expires August 2002 4 5346 iSCSI 20-January-02 5348 are deemed rare events, this technique is probably the 5349 most effective, as it does not involve additional checks 5350 at the initiator when issuing commands. 5352 1.4 Synch and Steering Layer and Performance 5354 While a synch and steering layer is optional, an initia- 5355 tor/target that does not have it working against a target/ 5356 initiator that demands synch and steering may experience 5357 performance degradation caused by packet reordering and 5358 loss. Providing a synch and steering mechanism is recom- 5359 mended for all high-speed implementations. 5361 1.5 Unsolicited Data and Performance 5363 Unsolicited data on write are meant to reduce the effect 5364 of latency on throughput (no R2T is needed to start send- 5365 ing data). In addition, immediate data are meant to 5366 reduce the protocol overhead (both bandwidth and execu- 5367 tion time). 5369 However, negotiating an amount of unsolicited data for 5370 writes and sending less than the negotiated amount when 5371 the total data amount to be sent by a command is larger 5372 than the negotiated amount may negatively impact perfor- 5373 mance and may not be supported by all the targets. 5375 Julian Satran Expires August 2002 5 5377 iSCSI 20-January-02 5379 1. iSCSI PDU Formats 5381 All multi-byte integers that are specified in formats 5382 defined in this document are to be represented in network 5383 byte order (i.e., big endian). Any field that appears in 5384 this document assumes that the most significant byte is 5385 the lowest numbered byte and the most significant bit 5386 (within byte or field) is the highest numbered bit unless 5387 specified otherwise. 5389 Any compliant sender MUST set all bits not defined and all 5390 reserved fields to zero unless specified otherwise. Any 5391 compliant receiver MUST ignore any bit not defined and all 5392 reserved fields unless specified otherwise. 5394 Reserved fields are marked by the word "reserved", some 5395 abbreviation of "reserved" or by "." for individual bits 5396 when no other form of marking is technically feasible. 5398 1.1 iSCSI PDU Length and Padding 5400 iSCSI PDUs are padded to the closest integer number of 5401 four byte words. The padding bytes SHOULD be 0. 5403 1.2 PDU Template, Header, and Opcodes 5405 All iSCSI PDUs have one or more header segments and, 5406 optionally, a data segment. After the entire header seg- 5407 ment group a header-digest may follow. The data segment 5408 MAY also be followed by a data-digest. 5410 The Basic Header Segment (BHS) is the first segment in all 5411 of the iSCSI PDUs. The BHS is a fixed-length 48-byte 5412 header segment. It may be followed by Additional Header 5413 Segments (AHS), a Header-Digest, a Data Segment, and/or a 5414 Data-Digest. 5416 The overall structure of a PDU is as follows: 5418 Julian Satran Expires August 2002 1 5420 iSCSI 20-January-02 5422 Byte / 0 | 1 | 2 | 3 5423 | 5424 / | | | 5425 | 5426 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 5427 3 2 1 0| 5428 +---------------+---------------+---------------+------ 5429 ---------+ 5430 0/ Basic Header Segment (BHS) 5431 / 5432 +/ 5433 / 5434 +---------------+---------------+---------------+------ 5435 ---------+ 5436 48/ Additional Header Segment (AHS) (optional) 5437 / 5438 +/ 5439 / 5440 +---------------+---------------+---------------+------ 5441 ---------+ 5442 ---- 5443 +---------------+---------------+---------------+------ 5444 ---------+ 5445 k/ Header-Digest (optional) 5446 / 5447 +/ 5448 / 5449 +---------------+---------------+---------------+------ 5450 ---------+ 5451 l/ Data Seg- 5452 ment(optional) / 5453 +/ 5454 / 5455 +---------------+---------------+---------------+------ 5456 ---------+ 5457 m/ Data-Digest (optional) 5458 / 5459 +/ 5460 / 5461 +---------------+---------------+---------------+------ 5462 ---------+ 5464 Julian Satran Expires August 2002 2 5466 iSCSI 20-January-02 5468 All PDU segments and digests are padded to an integer num- 5469 ber of four byte words. The padding bytes SHOULD be sent 5470 as 0. 5472 1.2.1 Basic Header Segment (BHS) 5474 The BHS is 48 bytes long. The Opcode, TotalAHSLength, and 5475 DataSegmentLength fields appear in all iSCSI PDUs. In 5476 addition, when used, the Initiator Task Tag and Logical 5477 Unit Number always appear in the same location in the 5478 header. 5480 The format of the BHS is: 5482 Julian Satran Expires August 2002 3 5484 iSCSI 20-January-02 5486 Byte / 0 | 1 | 2 | 3 5487 | 5488 / | | | 5489 | 5490 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 5491 3 2 1 0| 5492 +---------------+---------------+---------------+------ 5493 ---------+ 5494 0|.|I| Opcode | Opcode-specific fields 5495 | 5496 +---------------+---------------+---------------+------ 5497 ---------+ 5498 4|TotalAHSLength | DataSeg- 5499 mentLength | 5500 +---------------+---------------+---------------+------ 5501 ---------+ 5502 8| LUN or Opcode-specific fields 5503 | 5504 + 5505 + 5506 12| 5507 | 5508 +---------------+---------------+---------------+------ 5509 ---------+ 5510 16| Initiator Task Tag or Opcode-specific fields 5511 | 5512 +---------------+---------------+---------------+------ 5513 ---------+ 5514 20/ Opcode-specific fields 5515 / 5516 +/ 5517 / 5518 +---------------+---------------+---------------+------ 5519 ---------+ 5520 48 5522 1.2.1.1 I 5524 For request PDUs, the I bit set to 1 is an immediate 5525 delivery marker. This bit is always 1 for response PDUs 5526 (PDUs from target to initiator). 5528 Julian Satran Expires August 2002 4 5530 iSCSI 20-January-02 5532 1.2.1.2 Opcode 5534 The Opcode indicates the type of iSCSI PDU the header 5535 encapsulates. 5537 The Opcodes are divided into two categories: initiator 5538 opcodes and target opcodes. Initiator opcodes are in PDUs 5539 sent by the initiators (request PDUs). Target opcodes are 5540 in PDUs sent by the target (response PDUs). 5542 Initiators MUST NOT use target opcodes and targets MUST 5543 NOT use initiator opcodes. 5545 Initiator opcodes defined in this specification are: 5547 0x00 NOP-Out 5548 0x01 SCSI Command (encapsulates a SCSI Command 5549 Descriptor Block) 5550 0x02 SCSI Task Management Function Request 5551 0x03 Login Command 5552 0x04 Text request 5553 0x05 SCSI Data-out (for WRITE operations) 5554 0x06 Logout Command 5555 0x10 SNACK Request 5556 0x1c-0x1e Vendor specific codes 5558 Target opcodes are: 5560 0x20 NOP-In 5561 0x21 SCSI Response -contains SCSI status and possibly 5562 sense information or other response information. 5563 0x22 SCSI Task Management Function Response 5564 0x23 Login Response 5565 0x24 Text Response 5566 0x25 SCSI Data-in -for READ operations. 5567 0x26 Logout Response 5568 0x31 Ready To Transfer (R2T) - sent by target when it 5569 is ready to receive data. 5570 0x32 Asynchronous Message -sent by target to indicate 5571 certain special conditions. 5572 0x3c-0x3e Vendor specific codes 5573 0x3f Reject 5575 All other opcodes are reserved. 5577 Julian Satran Expires August 2002 5 5579 iSCSI 20-January-02 5581 1.2.1.3 Opcode-specific Fields 5583 These fields have different meanings for different opcode 5584 types. 5586 1.2.1.4 TotalAHSLength 5588 Total length of all AHS header segments in four byte words 5589 including padding, if any. 5591 1.2.1.5 DataSegmentLength 5593 This is the data segment payload length in bytes (exclud- 5594 ing padding). 5596 1.2.1.6 LUN 5598 Some opcodes operate on a specific Logical Unit. The Log- 5599 ical Unit Number (LUN) field identifies which Logical 5600 Unit. If the opcode does not relate to a Logical Unit, 5601 this field is either ignored or may be used in an opcode 5602 specific way. The LUN field is 64-bits and should be for- 5603 matted in accordance with [SAM2] i.e., LUN[0] from [SAM2] 5604 is BHS byte 8 and so on up to LUN[8] from [SAM2] that is 5605 BHS byte 15.. 5607 1.2.1.7 Initiator Task Tag 5609 The initiator assigns a Task Tag to each iSCSI task it 5610 issues. While a task exists, this tag MUST uniquely iden- 5611 tify it session-wide. 5612 SCSI may also use the initiator task tag as part of the 5613 SCSI task identifier when the time span during which an 5614 iSCSI initiator task tag must be unique extends over the 5615 time span during which a SCSI task tag must be unique. 5616 However, the iSCSI Initiator Task Tag has to exist and be 5617 unique even for untagged SCSI commands. 5619 1.2.2 Additional Header Segment (AHS) 5621 The general format of an AHS is: 5623 Julian Satran Expires August 2002 6 5625 iSCSI 20-January-02 5627 Byte / 0 | 1 | 2 | 3 5628 | 5629 / | | | 5630 | 5631 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 5632 3 2 1 0| 5633 +---------------+---------------+---------------+------ 5634 ---------+ 5635 0| AHSLength | AHSType | AHS- 5636 Specific | 5637 +---------------+---------------+---------------+------ 5638 ---------+ 5639 4/ AHS-Spe- 5640 cific / 5641 +/ 5642 / 5643 +---------------+---------------+---------------+------ 5644 ---------+ 5645 x 5647 1.2.2.1 AHSType 5649 The AHSType field is coded as follows: 5651 bit 7-6 - Reserved 5653 bit 5-0 - AHS code 5655 0 - Reserved 5656 1 - Extended CDB 5657 2 - Expected Bidirectional Read Data Length 5658 3 - 59 Reserved 5659 60- 63 Non-iSCSI extensions 5661 1.2.2.2 AHSLength 5663 This field contains the effective length in bytes of the 5664 AHS excluding AHSType and AHSLength (not including pad- 5665 ding). The AHS is padded to the smallest integer number of 5666 4 byte words (i.e., from 0 up to 3 padding bytes). 5668 1.2.2.3 Extended CDB AHS 5670 The format of the Extended CDB AHS is: 5672 Julian Satran Expires August 2002 7 5674 iSCSI 20-January-02 5676 Byte / 0 | 1 | 2 | 3 5677 | 5678 / | | | 5679 | 5680 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 5681 3 2 1 0| 5682 +---------------+---------------+---------------+------ 5683 ---------+ 5684 0| AHSLength (CDBLength-15) | 0x01 | 5685 Reserved | 5686 +---------------+---------------+---------------+------ 5687 ---------+ 5688 4/ ExtendedCDB...+pad- 5689 ding / 5690 +/ 5691 / 5692 +---------------+---------------+---------------+------ 5693 ---------+ 5694 x 5696 1.2.2.4 Bidirectional Expected Read-Data Length AHS 5698 The format of the Bidirectional Read Expected Data Trans- 5699 fer Length AHS is: 5701 Julian Satran Expires August 2002 8 5703 iSCSI 20-January-02 5705 Byte / 0 | 1 | 2 | 3 5706 | 5707 / | | | 5708 | 5709 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 5710 3 2 1 0| 5711 +---------------+---------------+---------------+------ 5712 ---------+ 5713 0| AHSLength (0x0005) | 0x02 | 5714 Reserved | 5715 +---------------+---------------+---------------+------ 5716 ---------+ 5717 4| Expected Read-Data Length 5718 | 5719 +---------------+---------------+---------------+------ 5720 ---------+ 5721 8 5723 1.2.3 Header Digest and Data Digest 5725 Optional header and data digests protect the integrity of 5726 the header and data, respectively. The digests, if 5727 present, are located, respectively, after the header and 5728 PDU-specific data and include the padding bytes. 5730 The digest types are negotiated during the login phase. 5732 The separation of the header and data digests is useful in 5733 iSCSI routing applications, where only the header changes 5734 when a message is forwarded. In this case, only the header 5735 digest should be re-calculated. 5737 Digests are not included in data or header length fields. 5739 A zero-length Data Segment also implies a zero-length 5740 data-digest. 5742 1.2.4 Data Segment 5744 The (optional) Data Segment contains PDU associated data. 5745 Its payload effective length is provided in the BHS field 5746 - DataSegmentLength. The Data Segment is also padded to an 5747 integer number of 4 byte words. 5749 Julian Satran Expires August 2002 9 5751 iSCSI 20-January-02 5753 1.3 SCSI Command 5755 The format of the SCSI Command PDU is: 5757 Julian Satran Expires August 2002 10 5759 iSCSI 20-January-02 5761 Byte / 0 | 1 | 2 | 3 5762 | 5763 / | | | 5764 | 5765 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 5766 3 2 1 0| 5767 +---------------+---------------+---------------+------ 5768 ---------+ 5769 0|.|I| 0x01 |F|R|W|0 0|ATTR | Reserved | CRN or 5770 Rsvd | 5771 +---------------+---------------+---------------+------ 5772 ---------+ 5773 4|TotalAHSLength | DataSeg- 5774 mentLength | 5775 +---------------+---------------+---------------+------ 5776 ---------+ 5777 8| Logical Unit Number (LUN) 5778 | 5779 + 5780 + 5781 12| 5782 | 5783 +---------------+---------------+---------------+------ 5784 ---------+ 5785 16| Initiator Task Tag 5786 | 5787 +---------------+---------------+---------------+------ 5788 ---------+ 5789 20| Expected Data Transfer Length 5790 | 5791 +---------------+---------------+---------------+------ 5792 ---------+ 5793 24| CmdSN 5794 | 5795 +---------------+---------------+---------------+------ 5796 ---------+ 5797 28| Exp- 5798 StatSN | 5799 +---------------+---------------+---------------+------ 5800 ---------+ 5801 32/ SCSI Command Descriptor Block (CDB) 5802 / 5803 +/ 5805 Julian Satran Expires August 2002 11 5807 iSCSI 20-January-02 5809 / 5810 +---------------+---------------+---------------+------ 5811 ---------+ 5812 48| AHS (if any), Header Digest (if any) 5813 | 5814 +---------------+---------------+---------------+------ 5815 ---------+ 5816 / DataSegment - Command Data (optional) 5817 / 5818 +/ 5819 / 5820 +---------------+---------------+---------------+------ 5821 ---------+ 5823 1.3.1 Flags and Task Attributes (byte 1) 5825 The flags for a SCSI Command are: 5827 bit 7 (F) set to 1 when no unsolicited SCSI Data- 5828 Out PDUs follow this PDU. For a write, if Expected 5829 Data Transfer Length is larger than the DataSeg- 5830 mentLength the target may solicit additional data 5831 through R2T. 5833 bit 6 (R) set to 1 when input data is expected. 5835 bit 5 (W) set to 1 when output data is expected. 5837 bit 4-3 Reserved 5839 bit 2-0 contains Task Attributes. 5841 Task Attributes (ATTR) have one of the following integer 5842 values (see [SAM2] for details): 5844 0 - Untagged 5845 1 - Simple 5846 2 - Ordered 5847 3 - Head of Queue 5848 4 - ACA 5849 5-7 - Reserved 5851 Setting both the W and the F bit to 0 is an error. 5852 The R and W MAY both be 1 when the corresponding Expected 5853 Data Transfer Lengths are 0, but they CANNOT both be 0 5855 Julian Satran Expires August 2002 12 5857 iSCSI 20-January-02 5859 when the corresponding Expected Data Transfer Lengths are 5860 not 0. 5862 1.3.2 CRN 5864 SCSI command reference number - if present in the SCSI 5865 execute command arguments (according to [SAM2]). 5867 1.3.3 CmdSN - Command Sequence Number 5869 Enables ordered delivery across multiple connections in a 5870 single session. 5872 1.3.4 ExpStatSN 5874 Command responses up to ExpStatSN-1 (mod 2**32) have been 5875 received (acknowledges status) on the connection. 5877 1.3.5 Expected Data Transfer Length 5879 For unidirectional operations, the Expected Data Transfer 5880 Length field contains the number of bytes of data involved 5881 in this SCSI operation. For a unidirectional write oper- 5882 ation (W flag set to 1 and R flag set to 0), the initiator 5883 uses this field to specify the number of bytes of data it 5884 expects to transfer for this operation. For a unidirec- 5885 tional read operation (W flag set to 0 and R flag set to 5886 1), the initiator uses this field to specify the number of 5887 bytes of data it expects the target to transfer to the 5888 initiator. It corresponds to the SAM2 byte count. 5890 For bidirectional operations (both R and W flags are set 5891 to 1), this field contains the number of data bytes 5892 involved in the write transfer. For bidirectional opera- 5893 tions, an additional header segment MUST be present in the 5894 header sequence that indicates the Bidirectional Read 5895 Expected Data Transfer Length. The Expected Data Transfer 5896 Length field and the Bidirectional Read Expected Data 5897 Transfer Length field correspond to the SAM2 byte count 5899 If the Expected Data Transfer Length for a write and the 5900 length of the immediate data part that follows the command 5902 Julian Satran Expires August 2002 13 5904 iSCSI 20-January-02 5906 (if any) are the same, than no more data PDUs are expected 5907 to follow. In this case, the F bit MUST be set to 1. 5909 If the Expected Data Transfer Length is higher than the 5910 FirstBurstSize (the negotiated maximum amount of unsolic- 5911 ited data the target will accept), the initiator SHOULD 5912 send the maximum size of unsolicited data. The target MAY 5913 terminate a command in error for which the Expected Data 5914 Transfer Length is higher than the FirstBurstSize and for 5915 which the initiator sent less than the FirstBurstSize 5916 unsolicited data. 5918 Upon completion of a data transfer, the target informs the 5919 initiator (through residual counts) of how many bytes were 5920 actually processed (sent and/or received) by the target. 5922 1.3.6 CDB - SCSI Command Descriptor Block 5924 There are 16 bytes in the CDB field to accommodate the 5925 commonly used CDBs. Whenever the CDB is larger than 16 5926 bytes, an Extended CDB AHS MUST be used to contain the CDB 5927 spillover. 5929 1.3.7 Data Segment - Command Data 5931 Some SCSI commands require additional parameter data to 5932 accompany the SCSI command. This data may be placed beyond 5933 the boundary of the iSCSI header in a data segment. 5934 Alternatively, user data (for example, from a WRITE oper- 5935 ation) can be placed in the same PDU (both cases are 5936 referred to as immediate data). These data are governed by 5937 the general rules for solicited vs. unsolicited data. 5939 Julian Satran Expires August 2002 14 5941 iSCSI 20-January-02 5943 1.4 SCSI Response 5945 The format of the SCSI Response PDU is: 5947 Julian Satran Expires August 2002 15 5949 iSCSI 20-January-02 5951 Byte / 0 | 1 | 2 | 3 5952 | 5953 / | | | 5954 | 5955 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 5956 3 2 1 0| 5957 +---------------+---------------+---------------+------ 5958 ---------+ 5959 0|.|.| 0x21 |1 . .|o|u|O|U|.| Response | Status 5960 | 5961 +---------------+---------------+---------------+------ 5962 ---------+ 5963 4| Reserved | DataSeg- 5964 mentLength | 5965 +---------------+---------------+---------------+------ 5966 ---------+ 5967 8| Reserved 5968 | 5969 + 5970 + 5971 12| 5972 | 5973 +---------------+---------------+---------------+------ 5974 ---------+ 5975 16| Initiator Task Tag 5976 | 5977 +---------------+---------------+---------------+------ 5978 ---------+ 5979 20| Residual Count 5980 | 5981 +---------------+---------------+---------------+------ 5982 ---------+ 5983 24| StatSN 5984 | 5985 +---------------+---------------+---------------+------ 5986 ---------+ 5987 28| ExpC- 5988 mdSN | 5989 +---------------+---------------+---------------+------ 5990 ---------+ 5991 32| MaxC- 5992 mdSN | 5993 +---------------+---------------+---------------+------ 5995 Julian Satran Expires August 2002 16 5997 iSCSI 20-January-02 5999 ---------+ 6000 36| ExpDataSN or Reserved 6001 | 6002 +---------------+---------------+---------------+------ 6003 ---------+ 6004 40| Reserved 6005 | 6006 +---------------+---------------+---------------+------ 6007 ---------+ 6008 44| Bidirectional Read Residual Count 6009 | 6010 +---------------+---------------+---------------+------ 6011 ---------+ 6012 48| Digests if any... 6013 | 6014 +---------------+---------------+---------------+------ 6015 ---------+ 6016 / Data Segment (Optional) 6017 / 6018 +/ 6019 / 6020 +---------------+---------------+---------------+------ 6021 ---------+ 6023 1.4.1 Flags (byte 1) 6025 bit 6-5 Reserved 6027 bit 4 - (o) set for Bidirectional Read Residual Over- 6028 flow. In this case, the b Bidirectional Read Resid- 6029 ual Count indicates the number of bytes that were 6030 not transferred to the initiator because the initi- 6031 ator's Expected Bidirectional Read Data Transfer 6032 Length was not sufficient. 6034 bit 3 - (u) set for Bidirectional Read Residual 6035 Underflow. In this case, the Bidirectional Read 6036 Residual Count indicates the number of bytes that 6037 were not transferred to the initiator out of the 6038 number of bytes expected to be transferred. 6040 bit 2 - (O) set for Residual Overflow. In this case, 6041 the Residual Count indicates the number of bytes 6042 that were not transferred because the initiator's 6043 Expected Data Transfer length was not sufficient. 6045 Julian Satran Expires August 2002 17 6047 iSCSI 20-January-02 6049 For a bidirectional operation, the Residual Count 6050 contains the residual for the write operation. 6052 bit 1 - (U) set for Residual Underflow. In this case, 6053 the Residual Count indicates the number of bytes 6054 that were not transferred out of the number of 6055 bytes that expected to be transferred. For a bidi- 6056 rectional operation, the Residual Count contains 6057 the residual for the write operation. 6059 bit 0 - (0) Reserved 6061 Bits O and U and bits o and u are mutually exclusive. 6062 For a response other than "Command Completed at Target" 6063 bit 4-1 MUST be 0. 6065 1.4.2 Status 6067 The Status field is used to report the SCSI status of the 6068 command (as specified in [SAM2]) and is valid only if the 6069 Response Code is Command Completed at target. 6071 Some of the status codes defined in [SAM2] are: 6073 0x00 GOOD 6074 0x02 CHECK CONDITION 6075 0x08 BUSY 6076 0x18 RESERVATION CONFLICT 6077 0x28 TASK SET FULL 6078 0x30 ACA ACTIVE 6079 0x40 TASK ABORTED 6081 See [SAM2] for the complete list and definitions. 6083 If a SCSI device error is detected while data from the 6084 initiator is still expected (the command PDU did not con- 6085 tain all the data and the target has not received a Data 6086 PDU with the final bit Set), the target MUST wait until it 6087 receives a Data PDU with the F bit set in the last 6088 expected sequence, before sending the Response PDU. 6090 1.4.3 Response 6092 This field contains the iSCSI service response. 6094 Julian Satran Expires August 2002 18 6096 iSCSI 20-January-02 6098 iSCSI service response codes defined in this specifica- 6099 tion are: 6101 0x00 - Command Completed at Target 6102 0x01 - Target Failure 6103 0x80-0xff - Vendor specific 6105 The Response is used to report a Service Response. The 6106 exact mapping of the iSCSI response codes to SAM service 6107 response symbols is outside the scope of this document. 6109 Certain iSCSI conditions result in the command being ter- 6110 minated at the target (response Command Completed at Tar- 6111 get) with a SCSI Check Condition Status as outlined in the 6112 next table: 6114 Julian Satran Expires August 2002 19 6116 iSCSI 20-January-02 6118 +--------------------------+----------+------------------ 6119 ---------+ 6120 | Reason |Sense | Additional Sense 6121 Code & | 6122 | |Key | Quali- 6123 fier | 6124 +--------------------------+----------+------------------ 6125 ---------+ 6126 | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 6127 0x0c | 6128 | data |Command-0B| Write Error 6129 | 6130 +--------------------------+----------+------------------ 6131 ---------+ 6132 | Not enough unsolicited |Aborted | ASC = 0x0c ASCQ = 6133 0x0d | 6134 | data |Command-0B| Write Error 6135 | 6136 +--------------------------+----------+------------------ 6137 ---------+ 6138 | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 6139 0x05 | 6140 | error |Command-0B| CRC Error Detected 6141 | 6142 +--------------------------+----------+------------------ 6143 ---------+ 6144 | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 6145 0x13 | 6146 | |Command-0B| Read Error 6147 | 6148 +--------------------------+----------+------------------ 6149 ---------+ 6151 The target reports the "Not enough unsolicited data" con- 6152 dition only if it does not support output (write) opera- 6153 tions in which the total data length is higher than 6154 FirstBurstSize, but the initiator sent less than First- 6155 BurstSize amount of unsolicited data, and out-of-order 6156 R2Ts cannot be used. 6158 Julian Satran Expires August 2002 20 6160 iSCSI 20-January-02 6162 1.4.4 Residual Count 6164 The Residual Count field is only valid in the case where 6165 either the U bit or the O bit is set. If neither bit is 6166 set, the Residual Count field SHOULD be zero. If the O bit 6167 is set, the Residual Count indicates the number of bytes 6168 that were not transferred because the initiator's 6169 Expected Data Transfer Length was not sufficient. If the U 6170 bit is set, the Residual Count indicates the number of 6171 bytes that were not transferred out of the number of bytes 6172 expected to be transferred. 6174 1.4.5 Bidirectional Read Residual Count 6176 The Bidirectional Read Residual Count field is only valid 6177 in the case where either the u bit or the o bit is set. If 6178 neither bit is set, the Bidirectional Read Residual Count 6179 field SHOULD be zero. If the o bit is set, the Bidirec- 6180 tional Read Residual Count indicates the number of bytes 6181 that were not transferred to the initiator because the 6182 initiator's Expected Bidirectional Read Transfer Length 6183 was not sufficient. If the u bit is set, the Bidirectional 6184 Read Residual Count indicates the number of bytes that 6185 were not transferred to the initiator out of the number of 6186 bytes expected to be transferred. 6188 1.4.6 Data Segment - Sense and Response Data Segment 6190 iSCSI targets MUST support and enable autosense. If Sta- 6191 tus is CHECK CONDITION (0x02), then the Data Segment con- 6192 tains sense data for the failed command. 6194 For some iSCSI responses, the response data segment MAY 6195 contain some response related information, (e.g., for a 6196 target failure, it may contain a vendor specific detailed 6197 description of the failure). 6199 If the DataSegmentLength is not 0, the format of the Data 6200 Segment is as follows: 6202 Julian Satran Expires August 2002 21 6204 iSCSI 20-January-02 6206 Byte / 0 | 1 | 2 | 3 6207 | 6208 / | | | 6209 | 6210 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 6211 3 2 1 0| 6212 +---------------+---------------+---------------+------ 6213 ---------+ 6214 0|SenseLength | Sense Data 6215 | 6216 +---------------+---------------+---------------+------ 6217 ---------+ 6218 x/ Sense Data 6219 / 6220 +---------------+---------------+---------------+------ 6221 ---------+ 6222 y/ Response Data 6223 / 6224 / 6225 / 6226 +---------------+---------------+---------------+------ 6227 ---------+ 6228 z| 6230 1.4.6.1 SenseLength 6232 Length of Sense Data. 6234 1.4.7 ExpDataSN 6236 The number of Data-In (read) PDUs the target has sent for 6237 the command. 6239 This field is reserved if the response code is not Command 6240 Completed at Target or the command is a write command. 6242 1.4.8 StatSN - Status Sequence Number 6244 StatSN is a Sequence Number that the target iSCSI layer 6245 generates per connection and that in turn, enables the 6246 initiator to acknowledge status reception. StatSN is 6247 incremented by 1 for every response/status sent on a con- 6248 nection except for responses sent as a result of a retry 6249 or SNACK. In the case of responses sent due to a retrans- 6251 Julian Satran Expires August 2002 22 6253 iSCSI 20-January-02 6255 mission request, the StatSN MUST be the same as the first 6256 time the PDU was sent unless the connection has since been 6257 restarted. 6259 1.4.9 ExpCmdSN - Next Expected CmdSN from this Initiator 6261 ExpCmdSN is a Sequence Number that the target iSCSI 6262 returns to the initiator to acknowledge command recep- 6263 tion. It is used to update a local register with the same 6264 name. An ExpCmdSN equal to MaxCmdSN+1 indicates that the 6265 target cannot accept new commands. 6267 1.4.10 MaxCmdSN - Maximum CmdSN Acceptable from this Initi- 6268 ator 6270 MaxCmdSN is a Sequence Number that the target iSCSI 6271 returns to the initiator to indicate the maximum CmdSN the 6272 initiator can send. It is used to update a local register 6273 with the same name. If MaxCmdSN is equal to ExpCmdSN-1, 6274 this indicates to the initiator that the target cannot 6275 receive any additional commands. When MaxCmdSN changes at 6276 the target while the target has no pending PDUs to convey 6277 this information to the initiator, it MUST generate a NOP- 6278 IN to carry the new MaxCmdSN. 6280 Julian Satran Expires August 2002 23 6282 iSCSI 20-January-02 6284 1.5 Task Management Function Request 6286 Byte / 0 | 1 | 2 | 3 6287 | 6288 / | | | 6289 | 6290 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 6291 3 2 1 0| 6292 +---------------+---------------+---------------+------ 6293 ---------+ 6294 0|.|I| x02 |1| Function | Reserved 6295 | 6296 +---------------+---------------+---------------+------ 6297 ---------+ 6298 4| Reserved 6299 | 6300 +---------------+---------------+---------------+------ 6301 ---------+ 6302 8| Logical Unit Number (LUN) or Reserved 6303 | 6304 + 6305 + 6306 12| 6307 | 6308 +---------------+---------------+---------------+------ 6309 ---------+ 6310 16| Initiator Task Tag 6311 | 6312 +---------------+---------------+---------------+------ 6313 ---------+ 6314 20| Referenced Task Tag or 0xffffffff 6315 | 6316 +---------------+---------------+---------------+------ 6317 ---------+ 6318 24| CmdSN 6319 | 6320 +---------------+---------------+---------------+------ 6321 ---------+ 6322 28| Exp- 6323 StatSN | 6324 +---------------+---------------+---------------+------ 6325 ---------+ 6326 32| RefCmdSN or Exp- 6328 Julian Satran Expires August 2002 24 6330 iSCSI 20-January-02 6332 DataSN | 6333 +---------------+---------------+---------------+------ 6334 ---------+ 6335 36/ Reserved 6336 / 6337 +/ 6338 / 6339 +---------------+---------------+---------------+------ 6340 ---------+ 6341 48 6343 1.5.1 Function 6345 The Task Management functions provide an initiator with a 6346 way to explicitly control the execution of one or more 6347 Tasks (SCSI and iSCSI tasks). The Task Management func- 6348 tions are listed below. For a more detailed description of 6349 SCSI task management, see [SAM2]. 6351 1 ABORT TASK - aborts the task identified by the 6352 Referenced Task Tag field. 6354 2 ABORT TASK SET - aborts all Tasks issued via 6355 this session on the logical unit. 6357 3 CLEAR ACA - clears the Auto Contingent Alle- 6358 giance condition. 6360 4 CLEAR TASK SET - aborts all Tasks for the Logi- 6361 cal Unit. 6363 5 LOGICAL UNIT RESET 6365 6 TARGET WARM RESET 6367 7 TARGET COLD RESET 6369 8 TASK REASSIGN - reassigns connection allegiance 6370 for the task identified by the Initiator Task Tag 6371 field to this connection, thus resuming the iSCSI 6372 exchanges for the task. 6374 For all these functions, the Task Management Function 6375 Response MUST be returned as detailed in Section 1.6 Task 6376 Management Function Response. All these functions apply 6377 to the referenced tasks regardless of whether they are 6379 Julian Satran Expires August 2002 25 6381 iSCSI 20-January-02 6383 proper SCSI tasks or tagged iSCSI operations. Task man- 6384 agement requests must act on all the commands having a 6385 CmdSN lower than the task management CmdSN. If the task 6386 management request is marked for immediate delivery it 6387 must be considered immediately for execution but the oper- 6388 ations involved (all or part of them) may be postponed to 6389 allow the target to receive all relevant tasks. According 6390 to [SAM2] for all the tasks covered by the task management 6391 response (i.e., with CmdSN not higher than the task man- 6392 agement command CmdSN), additional responses MUST NOT be 6393 delivered to the SCSI layer after the task management 6394 response. The iSCSI initiator MAY deliver to the SCSI 6395 layer all responses received before the task management 6396 response (i.e., it is a matter of implementation if the 6397 SCSI responses - received before the task management 6398 response but after the task management requests - are 6399 delivered to the SCSI layer by the iSCSI layer in the ini- 6400 tiator). The iSCSI target MUST ensure that no responses 6401 for the tasks covered by a task management function are 6402 delivered to the iSCSI initiator after the task management 6403 response. 6405 If the connection is still active (it is not undergoing an 6406 implicit or explicit logout), ABORT TASK MUST be issued on 6407 the same connection to which the task to be aborted is 6408 allegiant at the time the Task Management Request is 6409 issued. If the connection is being implicitly or explic- 6410 itly logged out (i.e., no other request will be issued on 6411 the failing connection and no other response will be 6412 received on the failing connection), then an ABORT TASK 6413 function request may be issued on another connection. This 6414 Task Management request will then establish a new alle- 6415 giance for the command to be aborted as well as abort it 6416 (i.e., the task to be aborted will not have to be retried 6417 or reassigned, and its status, if issued but not acknowl- 6418 edged, will be reissued followed by the task management 6419 response). 6421 For the LOGICAL UNIT RESET function, the target MUST 6422 behave as dictated by the Logical Unit Reset function in 6423 [SAM2]. 6425 Julian Satran Expires August 2002 26 6427 iSCSI 20-January-02 6429 The TARGET RESET function (WARM and COLD) implementation 6430 is OPTIONAL and when implemented, should act as described 6431 below. Target Reset MAY also be subject to SCSI access 6432 controls for the requesting initiator. When authorization 6433 fails at the target, the appropriate response as described 6434 in Section 1.6 Task Management Function Response must be 6435 returned by the target. 6437 For the TARGET WARM RESET and TARGET COLD RESET functions, 6438 the target cancels all pending operations. Both functions 6439 are equivalent to the Target Reset function specified by 6440 [SAM2]. They can affect many other initiators. 6442 In addition, for the TARGET COLD RESET, the target MUST 6443 then terminate all of its TCP connections to all initia- 6444 tors (all sessions are terminated). 6446 For the TASK REASSIGN function, the target should reassign 6447 the connection allegiance to this new connection (and thus 6448 resume iSCSI exchanges for the task). TASK REASSIGN MUST 6449 be received by the target ONLY after the connection on 6450 which the command was previously executing has been suc- 6451 cessfully logged-out. For additional usage semantics see 6452 Section 7.1 Retry and Reassign in Recovery. 6454 TASK REASSIGN MUST be issued as an immediate command. 6456 1.5.2 LUN 6458 This field is required for functions that address a spe- 6459 cific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, 6460 CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all oth- 6461 ers. 6463 1.5.3 Referenced Task Tag 6465 The Initiator Task Tag of the task to be aborted for the 6466 TASK ABORT function or reassigned for the TASK REASSIGN 6467 function. 6468 For all the other functions this field is reserved. 6470 Julian Satran Expires August 2002 27 6472 iSCSI 20-January-02 6474 1.5.4 RefCmdSN or ExpDataSN 6476 For ABORT TASK, this is the task CmdSN of the task to be 6477 aborted. If RefCmdSN does not match the CmdSN of the com- 6478 mand to be aborted at the target, the abort action MUST 6479 NOT be performed and the response MUST be �function 6480 rejected�. 6482 If the function is TASK REASSIGN, which establishes a new 6483 connection allegiance for a previously issued Read or 6484 Bidirectional command, this field will contain the next 6485 consecutive input DataSN number expected by the initiator 6486 (no gaps) for the referenced command in a previous execu- 6487 tion. The target MUST retransmit all data previously 6488 transmitted in DataIN PDUs (if any) starting with Exp- 6489 DataSN. The number of retransmitted PDUs, may or may not 6490 be the same as the original transmission, depending on if 6491 there was a change in MaxRecvPDULength in the reassign- 6492 ment. 6494 Otherwise, this field is reserved. 6496 Julian Satran Expires August 2002 28 6498 iSCSI 20-January-02 6500 1.6 Task Management Function Response 6502 Julian Satran Expires August 2002 29 6504 iSCSI 20-January-02 6506 Byte / 0 | 1 | 2 | 3 6507 | 6508 / | | | 6509 | 6510 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 6511 3 2 1 0| 6512 +---------------+---------------+---------------+------ 6513 ---------+ 6514 0|.|.| 0x22 |1| Reserved | Response | 6515 Reserved | 6516 +---------------+---------------+---------------+------ 6517 ---------+ 6518 4/ Reserved 6519 / 6520 / 6521 / 6522 +---------------+---------------+---------------+------ 6523 ---------+ 6524 16| Initiator Task Tag 6525 | 6526 +---------------+---------------+---------------+------ 6527 ---------+ 6528 20| Referenced Task Tag or 0xffffffff 6529 | 6530 +---------------+---------------+---------------+------ 6531 ---------+ 6532 24| StatSN 6533 | 6534 +---------------+---------------+---------------+------ 6535 ---------+ 6536 28| ExpC- 6537 mdSN | 6538 +---------------+---------------+---------------+------ 6539 ---------+ 6540 32| MaxC- 6541 mdSN | 6542 +---------------+---------------+---------------+------ 6543 ---------+ 6544 36/ Reserved 6545 / 6546 +/ 6547 / 6548 +---------------+---------------+---------------+------ 6550 Julian Satran Expires August 2002 30 6552 iSCSI 20-January-02 6554 ---------+ 6555 48| Digest (if any) 6556 | 6557 +------------------------------------------------------ 6558 ---------+ 6560 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, 6561 CLEAR TASK SET, LOGICAL UNIT RESET, and TARGET WARM RESET, 6562 the target performs the requested Task Management func- 6563 tion and sends a Task Management Response back to the ini- 6564 tiator. 6566 1.6.1 Response 6568 The target provides a Response, which may take on the fol- 6569 lowing values: 6571 a) 0 - Function Complete 6572 b) 1 - Task does not exist 6573 c) 2 - LUN does not exist. 6574 d) 3 - Task still allegiant. 6575 e) 4 - Task failover not supported. 6576 f) 5 - Task management function not supported. 6577 g) 6 - Function authorization failed. 6578 h) 255 - Function Rejected. 6580 All other values are reserved. 6582 For a discussion on usage of response codes 3 and 4, see 6583 Section 7.1.2 Allegiance Reassignment. 6585 For the TARGET COLD RESET and TARGET WARM RESET functions, 6586 the target cancels all pending operations. For the TARGET 6587 COLD RESET function, the target MUST then close all of its 6588 TCP connections to all initiators (terminates all ses- 6589 sions). 6591 The mapping of the response code into a SCSI service 6592 response code, if needed, is outside the scope of this 6593 document. 6595 The response to ABORT TASK SET and CLEAR TASK SET MUST be 6596 issued by the target only after all the commands affected 6598 Julian Satran Expires August 2002 31 6600 iSCSI 20-January-02 6602 have been received by the target, the corresponding task 6603 management functions have been executed by the SCSI target 6604 and the delivery of all previous responses has been con- 6605 firmed (acknowledged through ExpStatSN) by the initiator 6606 on all connections of this session. 6608 1.6.2 Referenced Task Tag 6610 If the Request was ABORT TASK and the Response is "task 6611 not found", the Referenced Task Tag contains the Initiator 6612 Task Tag of the task that was to be aborted. In other 6613 cases, it MUST be set to 0xffffffff. 6615 Julian Satran Expires August 2002 32 6617 iSCSI 20-January-02 6619 1.7 SCSI Data-out & SCSI Data-in 6621 The SCSI Data-out PDU for WRITE operations has the follow- 6622 ing format: 6624 Julian Satran Expires August 2002 33 6626 iSCSI 20-January-02 6628 Byte / 0 | 1 | 2 | 3 6629 | 6630 / | | | 6631 | 6632 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 6633 3 2 1 0| 6634 +---------------+---------------+---------------+------ 6635 ---------+ 6636 0|.|.| 0x05 |F| Reserved 6637 | 6638 +---------------+---------------+---------------+------ 6639 ---------+ 6640 4| Reserved | DataSeg- 6641 mentLength | 6642 +---------------+---------------+---------------+------ 6643 ---------+ 6644 8| LUN or Reserved 6645 | 6646 + 6647 + 6648 12| 6649 | 6650 +---------------+---------------+---------------+------ 6651 ---------+ 6652 16| Initiator Task Tag 6653 | 6654 +---------------+---------------+---------------+------ 6655 ---------+ 6656 20| Target Transfer Tag or 0xffffffff 6657 | 6658 +---------------+---------------+---------------+------ 6659 ---------+ 6660 24| Reserved 6661 | 6662 +---------------+---------------+---------------+------ 6663 ---------+ 6664 28| Exp- 6665 StatSN | 6666 +---------------+---------------+---------------+------ 6667 ---------+ 6668 32| Reserved 6669 | 6670 +---------------+---------------+---------------+------ 6672 Julian Satran Expires August 2002 34 6674 iSCSI 20-January-02 6676 ---------+ 6677 36| DataSN 6678 | 6679 +---------------+---------------+---------------+------ 6680 ---------+ 6681 40| Buffer Off- 6682 set | 6683 +---------------+---------------+---------------+------ 6684 ---------+ 6685 44| Reserved 6686 | 6687 +---------------+---------------+---------------+------ 6688 ---------+ 6689 48| Digests if any... 6690 | 6691 +---------------+---------------+---------------+------ 6692 ---------+ 6693 / DataSeg- 6694 ment / 6695 +/ 6696 / 6697 +---------------+---------------+---------------+------ 6698 ---------+ 6700 The SCSI Data-in PDU for READ operations has the following 6701 format: 6703 Julian Satran Expires August 2002 35 6705 iSCSI 20-January-02 6707 Byte / 0 | 1 | 2 | 3 6708 | 6709 / | | | 6710 | 6711 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 6712 3 2 1 0| 6713 +---------------+---------------+---------------+------ 6714 ---------+ 6715 0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status 6716 or Rsvd | 6717 +---------------+---------------+---------------+------ 6718 ---------+ 6719 4| Reserved | DataSeg- 6720 mentLength | 6721 +---------------+---------------+---------------+------ 6722 ---------+ 6723 8| Reserved 6724 | 6725 + 6726 + 6727 12| 6728 | 6729 +---------------+---------------+---------------+------ 6730 ---------+ 6731 16| Initiator Task Tag 6732 | 6733 +---------------+---------------+---------------+------ 6734 ---------+ 6735 20| Residual Count 6736 | 6737 +---------------+---------------+---------------+------ 6738 ---------+ 6739 24| StatSN or Reserved 6740 | 6741 +---------------+---------------+---------------+------ 6742 ---------+ 6743 28| ExpC- 6744 mdSN | 6745 +---------------+---------------+---------------+------ 6746 ---------+ 6747 32| MaxC- 6748 mdSN | 6749 +---------------+---------------+---------------+------ 6751 Julian Satran Expires August 2002 36 6753 iSCSI 20-January-02 6755 ---------+ 6756 36| DataSN 6757 | 6758 +---------------+---------------+---------------+------ 6759 ---------+ 6760 40| Buffer Off- 6761 set | 6762 +---------------+---------------+---------------+------ 6763 ---------+ 6764 44| Reserved 6765 | 6766 +---------------+---------------+---------------+------ 6767 ---------+ 6768 48| Header Digest (if any) 6769 | 6770 +---------------+---------------+---------------+------ 6771 ---------+ 6772 / DataSegment (and digest if any) 6773 / 6774 +/ 6775 / 6776 +---------------+---------------+---------------+------ 6777 ---------+ 6779 Status can accompany the last Data-in PDU if the command 6780 did not end with an exception (i.e., the status is "good 6781 status" - GOOD, CONDITION MET or INTERMEDIATE CONDITION 6782 MET). The presence of status (and of a residual count) is 6783 signaled though the S flag bit. Although targets MAY 6784 choose to send even non-exception status in separate 6785 responses, initiators MUST support non-exception status 6786 in Data-In PDUs. 6788 1.7.1 F (Final) Bit 6790 For outgoing data, this bit is 1 for the last PDU of unso- 6791 licited data or the last PDU of a sequence that answers an 6792 R2T. 6794 For incoming data, this bit is 1 for the last input (read) 6795 data PDU of a sequence. Input can be split into several 6796 sequences, each having its own F bit. Splitting the data 6798 Julian Satran Expires August 2002 37 6800 iSCSI 20-January-02 6802 stream into sequences does not affect DataSN counting on 6803 Data-In PDUs. It MAY be used as a "change direction" indi- 6804 cation for Bidirectional operations that need such a 6805 change. 6807 For Bidirectional operations, the F bit is 1 for both the 6808 end of the input sequences as well as the end of the out- 6809 put sequences. 6811 1.7.2 A (Acknowledge) bit 6813 For sessions with ErrorRecoveryLevel 1 or higher, the tar- 6814 get sets this bit to 1 to indicate that it requests a pos- 6815 itive acknowledgement from the initiator for the data 6816 received. The target should use the A bit moderately; it 6817 MAY set the A bit to 1 only once every MaxBurstSize bytes 6818 and MUST NOT do so more frequently than this. 6820 On receiving a Data-In PDU with the A bit set to 1, the 6821 initiator MUST issue a SNACK of type DataACK. If the ini- 6822 tiator has detected holes in the input sequence, it MUST 6823 postpone issuing the SNACK of type DataACK until the holes 6824 are filled. 6826 1.7.3 Target Transfer Tag 6828 On outgoing data, the Target Transfer Tag is provided to 6829 the target if the transfer is honoring an R2T. In this 6830 case, the Target Transfer Tag field is a replica of the 6831 Target Transfer Tag provided with the R2T. 6833 The Target Transfer Tag values are not specified by this 6834 protocol except that the value 0xffffffff is reserved and 6835 means that the Target Transfer Tag is not supplied. If 6836 the Target Transfer Tag is provided, then the LUN field 6837 MUST hold a valid value and be consistent with whatever 6838 was specified with the command; otherwise, the LUN field 6839 is reserved. 6841 1.7.4 StatSN 6843 This field MUST ONLY be set if the S bit is set to 1. 6845 Julian Satran Expires August 2002 38 6847 iSCSI 20-January-02 6849 1.7.5 DataSN 6851 For input (read) data PDUs, the DataSN is the data PDU 6852 number (starting with 0) within the data transfer for the 6853 command identified by the Initiator Task Tag. 6855 For output (write) data PDUs, the DataSN is the data PDU 6856 number (starting with 0) within the current output 6857 sequence. The current output sequence is either identi- 6858 fied by the Initiator Task Tag (for unsolicited data) or 6859 is a data sequence generated for one R2T (for data solic- 6860 ited through R2T). 6862 Any input or output data sequence MUST contain less than 6863 2**32 numbered PDUs. 6865 1.7.6 Buffer Offset 6867 The Buffer Offset field contains the offset of this PDU 6868 payload data within the complete data transfer. The sum of 6869 the buffer offset and length should not exceed the 6870 expected transfer length for the command. 6872 The order of data PDUs within a sequence is determined by 6873 DataPDUInOrder. When set to yes, it means that PDUs have 6874 to be in increasing Buffer Offset order and overlays are 6875 forbidden. 6877 The ordering between sequences is determined by DataSe- 6878 quenceInOrder. When set to yes, it means that sequences 6879 have to be in increasing Buffer Offset order and overlays 6880 are forbidden. 6882 1.7.7 DataSegmentLength 6884 This is the data payload length of a SCSI Data-In or SCSI 6885 Data-Out PDU. The sending of 0 length data segments should 6886 be avoided, but initiators and targets MUST be able to 6887 properly receive 0 length data segments. 6889 The Data Segments of Data-in and Data-out PDUs SHOULD be 6890 filled to the integer number of 4 byte words (real pay- 6891 load) unless the F bit is set to 1. 6893 Julian Satran Expires August 2002 39 6895 iSCSI 20-January-02 6897 1.7.8 Flags (byte 1) 6899 The last SCSI Data packet sent from a target to an initi- 6900 ator for a SCSI command that completed successfully (with 6901 a status of GOOD, CONDITION MET, INTERMEDIATE or INTERME- 6902 DIATE CONDITION MET) may also optionally contain the Sta- 6903 tus for the data transfer. In this case, Sense Data 6904 cannot be sent together with the Command Status. If the 6905 command is completed with an error, then the response and 6906 sense data MUST be sent in a SCSI Response PDU (i.e., MUST 6907 NOT be sent in a SCSI Data packet). For Bidirectional com- 6908 mands, the status MUST be sent in a SCSI Response PDU. 6910 bit 3-5 - not used (should be set to 0). 6912 bit 1-2 - used the same as in a SCSI Response. 6914 bit 0 S (status)- set to indicate that the Command 6915 Status field contains status. If this bit is set to 6916 1 the F bit MUST also be set to 1. 6918 The fields StatSN, Status and Residual Count have meaning- 6919 ful content only if the S bit is set to 1 and they values 6920 are as define in Section 1.4 SCSI Response. 6922 Julian Satran Expires August 2002 40 6924 iSCSI 20-January-02 6926 1.8 Ready To Transfer (R2T) 6928 Byte / 0 | 1 | 2 | 3 6929 | 6930 / | | | 6931 | 6932 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 6933 3 2 1 0| 6934 +---------------+---------------+---------------+------ 6935 ---------+ 6936 0|.|.| 0x31 |1| Reserved 6937 | 6938 +---------------+---------------+---------------+------ 6939 ---------+ 6940 4/ Reserved 6941 / 6942 +/ 6943 / 6944 +---------------+---------------+---------------+------ 6945 ---------+ 6946 16| Initiator Task Tag 6947 | 6948 +---------------+---------------+---------------+------ 6949 ---------+ 6950 20| Target Transfer Tag 6951 | 6952 +---------------+---------------+---------------+------ 6953 ---------+ 6954 24| StatSN 6955 | 6956 +---------------+---------------+---------------+------ 6957 ---------+ 6958 28| ExpC- 6959 mdSN | 6960 +---------------+---------------+---------------+------ 6961 ---------+ 6962 32| MaxC- 6963 mdSN | 6964 +---------------+---------------+---------------+------ 6965 ---------+ 6966 36| R2TSN 6967 | 6968 +---------------+---------------+---------------+------ 6970 Julian Satran Expires August 2002 41 6972 iSCSI 20-January-02 6974 ---------+ 6975 40| Buffer Off- 6976 set | 6977 +---------------+---------------+---------------+------ 6978 ---------+ 6979 44| Desired Data Transfer Length 6980 | 6981 +------------------------------------------------------ 6982 ---------+ 6983 48| Digest (if any) 6984 | 6985 +------------------------------------------------------ 6986 ---------+ 6988 When an initiator has submitted a SCSI Command with data 6989 that passes from the initiator to the target (WRITE), the 6990 target may specify which blocks of data it is ready to 6991 receive. The target may request that the data blocks be 6992 delivered in whichever order is convenient for the target 6993 at that particular instant. This information is passed 6994 from the target to the initiator in the Ready To Transfer 6995 (R2T) PDU. 6997 In order to allow write operations without an explicit 6998 initial R2T, the initiator and target MUST have agreed by 6999 sending the InitialR2T=no key-pair to each other, which 7000 occurs either during Login or through the Text request/ 7001 Response mechanism. 7003 An R2T MAY be answered with one or more SCSI Data-out PDUs 7004 with a matching Target Transfer Tag. If an R2T is answered 7005 with a single Data-out PDU, the Buffer Offset in the Data 7006 PDU MUST be the same as the one specified by the R2T. The 7007 data length of the Data PDU MUST not exceed the Desired 7008 Data Transfer Length specified in the R2T. If the R2T is 7009 answered with a sequence of Data PDUs, the Buffer Offset 7010 and Length MUST be within the range of those specified by 7011 R2T, and the last PDU SHOULD have the F bit set to 1. If 7012 the last PDU (marked with the F bit) is received before 7013 the Desired Data Transfer Length is transferred, a target 7014 MAY choose to Reject that PDU with "Protocol error" reason 7015 code. DataPDUInOrder governs the Data-Out PDU ordering. 7017 Julian Satran Expires August 2002 42 7019 iSCSI 20-January-02 7021 If DataPDUInOrder is set to yes, the Buffer Offsets and 7022 Lengths for consecutive PDUs MUST form a continuous non- 7023 overlapping range and the PDUs MUST be sent in increasing 7024 offset order. 7026 The target may send several R2T PDUs (up to a negotiated 7027 number). It, therefore, can have a number of pending data 7028 transfers. Within a connection, outstanding R2Ts MUST be 7029 fulfilled by the initiator in the order in which they were 7030 received. 7032 DataSequenceInOrder governs the buffer offset ordering in 7033 consecutive R2Ts. If DataSequenceInOrder is yes, then 7034 consecutive R2Ts SHOULD refer to continuous non-overlap- 7035 ping ranges. 7037 1.8.1 R2TSN 7039 R2TSN is the R2T PDU number (starting with 0) within the 7040 command identified by the Initiator Task Tag. 7042 The number of R2Ts in a command MUST be less than 7043 0xffffffff. 7045 1.8.2 StatSN 7047 The StatSN field will contain the next StatSN. The StatSN 7048 for this connection is not advanced. 7050 1.8.3 Desired Data Transfer Length and Buffer Offset 7052 The target specifies how many bytes it wants the initiator 7053 to send because of this R2T PDU. The target may request 7054 the data from the initiator in several chunks, not neces- 7055 sarily in the original order of the data. The target, 7056 therefore, also specifies a Buffer Offset that indicates 7057 the point at which the data transfer should begin, rela- 7058 tive to the beginning of the total data transfer. The 7059 Desired Data Transfer Length SHOULD not be 0 and MUST not 7060 exceed MaxBurstSize. 7062 Julian Satran Expires August 2002 43 7064 iSCSI 20-January-02 7066 1.8.4 Target Transfer Tag 7068 The target assigns its own tag to each R2T request that it 7069 sends to the initiator. This tag can be used by the target 7070 to easily identify the data it receives. The Target 7071 Transfer Tag is copied in the outgoing data PDUs and is 7072 used by the target only. There is no protocol rule about 7073 the Target Transfer Tag, but it is assumed that it is used 7074 to tag the response data to the target (alone or in combi- 7075 nation with the LUN). 7077 Julian Satran Expires August 2002 44 7079 iSCSI 20-January-02 7081 1.9 Asynchronous Message 7083 An Asynchronous Message may be sent from the target to the 7084 initiator without corresponding to a particular command. 7085 The target specifies the reason for the event and sense 7086 data. 7088 Julian Satran Expires August 2002 45 7090 iSCSI 20-January-02 7092 Byte / 0 | 1 | 2 | 3 7093 | 7094 / | | | 7095 | 7096 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 7097 3 2 1 0| 7098 +---------------+---------------+---------------+------ 7099 ---------+ 7100 0|.|.| 0x32 |1| Reserved 7101 | 7102 +---------------+---------------+---------------+------ 7103 ---------+ 7104 4| Reserved | DataSeg- 7105 mentLength | 7106 +---------------+---------------+---------------+------ 7107 ---------+ 7108 8| LUN 7109 | 7110 + 7111 + 7112 12| 7113 | 7114 +---------------+---------------+---------------+------ 7115 ---------+ 7116 16/ Reserved 7117 / 7118 +/ 7119 / 7120 +---------------+---------------+---------------+------ 7121 ---------+ 7122 24| StatSN 7123 | 7124 +---------------+---------------+---------------+------ 7125 ---------+ 7126 28| ExpC- 7127 mdSN | 7128 +---------------+---------------+---------------+------ 7129 ---------+ 7130 32| MaxC- 7131 mdSN | 7132 +---------------+---------------+---------------+------ 7133 ---------+ 7134 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved 7136 Julian Satran Expires August 2002 46 7138 iSCSI 20-January-02 7140 | 7141 +---------------+---------------+---------------+------ 7142 ---------+ 7143 40| Parameter2 or Reserved | Parameter3 or Reserved 7144 | 7145 +---------------+---------------+---------------+------ 7146 ---------+ 7147 44| Reserved 7148 | 7149 +---------------+---------------+---------------+------ 7150 ---------+ 7151 48| Digests if any... 7152 | 7153 +---------------+---------------+---------------+------ 7154 ---------+ 7155 / DataSegment - Sense Data or iSCSI Event Data 7156 / 7157 +/ 7158 / 7159 +---------------+---------------+---------------+------ 7160 ---------+ 7162 Some Asynchronous Messages are strictly related to iSCSI 7163 while others are related to SCSI [SAM2]. 7165 StatSN counts this PDU as an acknowledgeable event (StatSN 7166 is advanced), which allows for initiator and target state 7167 synchronization. 7169 1.9.1 AsyncEvent 7171 The codes used for iSCSI Asynchronous Messages (Events) 7172 are: 7174 0 - a SCSI Asynchronous Event is reported in the 7175 sense data. Sense Data that accompanies the report, 7176 in the data segment, identifies the condition. The 7177 sending of a SCSI Event (Asynchronous Event Notifi- 7178 cation in SCSI terminology) is controlled by a SCSI 7179 Control Mode Page bit. 7181 1 - target requests Logout. This Async Message MUST 7182 be sent on the same connection as the one request- 7183 ing to be logged out. The initiator MUST honor 7185 Julian Satran Expires August 2002 47 7187 iSCSI 20-January-02 7189 this request by issuing a Logout as early as possi- 7190 ble, but no later than Parameter3 seconds. Initi- 7191 ator MUST send a Logout with a reason code of 7192 "Close the 7193 connection" (if not the only connection) OR "Close 7194 the session" 7195 (if using multiple connections). Once this message 7196 is received, the initiator SHOULD NOT issue new 7197 iSCSI commands. The target MAY reject any new I/O 7198 requests that it receives after this Message with 7199 the reason code "Waiting for Logout". If the ini- 7200 tiator does not Logout in Parameter3 seconds, the 7201 target should send an Async PDU with iSCSI event 7202 code "Dropped the connection" if possible, or sim- 7203 ply terminate the transport connection. Parameter1 7204 and Parameter2 are reserved. 7206 2 - target indicates it will drop the connection. 7207 The Parameter1 field indicates the CID of the con- 7208 nection going to be dropped. 7209 The Parameter2 field (Time2Wait) indicates, in sec- 7210 onds, the minimum time to wait before attempting to 7211 reconnect. 7212 The Parameter3 field (Time2Retain) indicates the 7213 maximum time to reconnect and/or restart commands 7214 after the initial wait (Time2Wait). 7215 If the initiator does not attempt to reconnect and/ 7216 or restart the outstanding commands within the time 7217 specified by Parameter3, or if Parameter3 is 0, the 7218 target will terminate all outstanding commands on 7219 this connection; no other responses should be 7220 expected from the target for the outstanding com- 7221 mands on this connection (Time2Retain). 7222 A value of 0 for Parameter2 indicates that recon- 7223 nect can be attempted immediately. 7225 3 - target indicates it will drop all the connections 7226 of this session. 7227 The Parameter1 field indicates the CID of the con- 7228 nection going to be dropped. 7229 The Parameter2 field (Time2Wait) indicates, in sec- 7230 onds, the minimum time to wait before attempting to 7231 reconnect. 7232 The Parameter3 field (Time2Retain) indicates the 7233 maximum time to reconnect and/or restart commands 7234 after the initial wait (Time2Wait). 7235 If the initiator does not attempt to reconnect and/ 7236 or restart the outstanding commands within the time 7237 specified by Parameter3, or if Parameter3 is 0, the 7238 session is terminated. In this case, the target 7240 Julian Satran Expires August 2002 48 7242 iSCSI 20-January-02 7244 will terminate all outstanding commands in this 7245 session; no other responses should be expected from 7246 the target for the outstanding commands in this 7247 session. A value of 0 for Parameter2 indicates 7248 that reconnect can be attempted immediately. 7250 255 - vendor specific iSCSI Event. The AsyncVCode 7251 details the vendor code, and data MAY accompany the 7252 report. 7254 All other event codes are reserved. 7256 1.9.2 AsyncVCode 7258 AsyncVCode is a vendor specific detail code that is valid 7259 only if the AsyncEvent field indicates a vendor specific 7260 event. Otherwise, it is reserved. 7262 1.9.3 Sense Data or iSCSI Event Data 7264 For a SCSI Event, this data accompanies the report in the 7265 data segment and identifies the condition. 7267 For an iSCSI Event, additional vendor-unique data MAY 7268 accompany the Async event. Initiators MAY ignore the data 7269 when not understood while processing the rest of the PDU. 7271 Julian Satran Expires August 2002 49 7273 iSCSI 20-January-02 7275 1.10 Text Request 7277 The Text Request is provided to allow for the exchange of 7278 information and for future extensions. It permits the ini- 7279 tiator to inform a target of its capabilities or to 7280 request some special operations. 7282 An initiator MUST have only one outstanding Text Request 7283 on a connection at any given time. 7285 Julian Satran Expires August 2002 50 7287 iSCSI 20-January-02 7289 Byte / 0 | 1 | 2 | 3 7290 | 7291 / | | | 7292 | 7293 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 7294 3 2 1 0| 7295 +---------------+---------------+---------------+------ 7296 ---------+ 7297 0|.|I| 0x04 |F| Reserved 7298 | 7299 +---------------+---------------+---------------+------ 7300 ---------+ 7301 4| Reserved | DataSeg- 7302 mentLength | 7303 +---------------+---------------+---------------+------ 7304 ---------+ 7305 8| Reserved 7306 | 7307 + 7308 + 7309 12| 7310 | 7311 +---------------+---------------+---------------+------ 7312 ---------+ 7313 16| Initiator Task Tag 7314 | 7315 +---------------+---------------+---------------+------ 7316 ---------+ 7317 20| Target Transfer Tag or 0xffffffff 7318 | 7319 +---------------+---------------+---------------+------ 7320 ---------+ 7321 24| CmdSN 7322 | 7323 +---------------+---------------+---------------+------ 7324 ---------+ 7325 28| Exp- 7326 StatSN | 7327 +---------------+---------------+---------------+------ 7328 ---------+ 7329 32/ Reserved 7330 / 7331 +/ 7333 Julian Satran Expires August 2002 51 7335 iSCSI 20-January-02 7337 / 7338 +---------------+---------------+---------------+------ 7339 ---------+ 7340 48| Digests if any 7341 | 7342 +---------------+---------------+---------------+------ 7343 ---------+ 7344 / DataSegment (Text) 7345 / 7346 +/ 7347 / 7348 +---------------+---------------+---------------+------ 7349 ---------+ 7351 1.10.1 F (Final) Bit 7353 When set to 1, indicates that this is the last or only 7354 text request in a sequence of commands; otherwise, it 7355 indicates that more commands will follow. 7357 1.10.2 Initiator Task Tag 7359 The initiator assigned identifier for this Text Request. 7360 If the command is sent as part of a sequence of text 7361 requests and responses, the Initiator Task Tag MUST be the 7362 same for all the requests within the sequence (similar to 7363 linked SCSI commands). 7365 1.10.3 Target Transfer Tag 7367 When the Target Transfer Tag is set to the reserved value 7368 0xffffffff, it tells the target that this is a new request 7369 and the target should reset any internal state associated 7370 with the Initiator Task Tag. 7372 The target sets the Target Transfer Tag in a text response 7373 to a value other than the reserved value 0xffffffff when- 7374 ever it indicates that it has more data to send or more 7375 operations to perform that are associated with the speci- 7376 fied Initiator Task Tag. It MUST do so whenever it sets 7377 the F bit to 0 in the response. By copying the Target 7378 Transfer Tag from the response to the next Text Request, 7379 the initiator tells the target to continue the operation 7381 Julian Satran Expires August 2002 52 7383 iSCSI 20-January-02 7385 for the specific Initiator Task Tag. The initiator MUST 7386 ignore the Target Transfer Tag in the Text Response when 7387 the F bit is set to 1. 7389 This mechanism allows the initiator and target to transfer 7390 a large amount of textual data over a sequence of text- 7391 command/text-response exchanges or to perform extended 7392 negotiation sequences. 7394 A target MAY reset its internal state if an exchange is 7395 stalled by the initiator for a long time or if it is run- 7396 ning out of resources. 7398 Long text responses are handled as in the following exam- 7399 ple: 7401 I->T Text SendTargets=all (F=1,TTT=0xffffffff) 7402 T->I Text (F=0,TTT=0x12345678) 7403 I->T Text (F=1, TTT=0x12345678) 7404 T->I Text (F=0, TTT=0x12345678) 7405 I->T Text (F=1, TTT=0x12345678) 7406 ... 7407 T->I Text (F=1, TTT=0xffffffff) 7409 1.10.4 Text 7411 The initiator sends the target a set of key=value or 7412 key=list pairs encoded in UTF-8 Unicode. All the text keys 7413 and text values specified in this document are to be pre- 7414 sented and interpreted in the case they appear in this 7415 document. They are case sensitive. Text keys and values 7416 MUST ONLY contain letters (a-z, A-Z), digits (0-9), space 7417 (0x20), point (.), minus (-), plus (+), and underscore 7418 (_). The key and value are separated by a '=' (0x3d) 7419 delimiter. Every key=value pair (including the last or 7420 only pair) MUST be followed by one null (0x00) delimiter. 7421 A list is a set of values separated by comma (0x2c). Text 7422 values may also contain colon (:) and brackets ([ and ]). 7424 Character strings are represented as plain text. Binary 7425 items can be encoded using their decimal representation 7426 (with or without leading zeros) or hexadecimal represen- 7427 tation (e.g., 8190 is 0x1ffe). Upper and lower case let- 7428 ters may be used interchangeably in hexadecimal notation 7430 Julian Satran Expires August 2002 53 7432 iSCSI 20-January-02 7434 (i.e., 0x1aBc, 0x1AbC, 0X1aBc, and 0x1ABC are equiva- 7435 lent). Binary items can also be encoded using the more 7436 compact Base64 encoding as specified by [RFC2045] pre- 7437 ceded by the 0b. Key names MUST NOT exceed 63 bytes. 7439 If not otherwise specified, the maximum length of an indi- 7440 vidual value (not its encoded representation) is 255 bytes 7441 not including the delimiter (comma or null). 7443 The data lengths of a text request or response MUST NOT 7444 exceed MaxRecvPDULength (a per connection negotiated 7445 parameter). 7447 A Key=value pair can span Text request or response bound- 7448 aries (i.e., a key=value pair can start in one PDU and 7449 continue on the next). 7451 The target responds by sending its response back to the 7452 initiator. The response text format is similar to the 7453 request text format. 7455 As text for text requests and responses can span several 7456 PDUs (e.g., if the PDU length does not allow the whole 7457 text to be contained in a single PDU), the text response 7458 MAY refer to key=value pairs presented in an earlier text 7459 request and the text in the request may refer to earlier 7460 responses. 7462 Text operations are usually meant for parameter setting/ 7463 negotiations, but can also be used to perform some long 7464 lasting operations. 7466 Text operations that take a long time should be placed in 7467 their own Text request. 7469 Julian Satran Expires August 2002 54 7471 iSCSI 20-January-02 7473 1.11 Text Response 7475 The Text Response PDU contains the target's responses to 7476 the initiator's Text request. The format of the Text field 7477 matches that of the Text request. 7479 Julian Satran Expires August 2002 55 7481 iSCSI 20-January-02 7483 Byte / 0 | 1 | 2 | 3 7484 | 7485 / | | | 7486 | 7487 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 7488 3 2 1 0| 7489 +---------------+---------------+---------------+------ 7490 ---------+ 7491 0|.|.| 0x24 |F| Reserved 7492 | 7493 +---------------+---------------+---------------+------ 7494 ---------+ 7495 4| Reserved | DataSeg- 7496 mentLength | 7497 +---------------+---------------+---------------+------ 7498 ---------+ 7499 8| Reserved 7500 | 7501 + 7502 + 7503 12| 7504 | 7505 +---------------+---------------+---------------+------ 7506 ---------+ 7507 16| Initiator Task Tag 7508 | 7509 +---------------+---------------+---------------+------ 7510 ---------+ 7511 20| Target Transfer Tag or 0xffffffff 7512 | 7513 +---------------+---------------+---------------+------ 7514 ---------+ 7515 24| StatSN 7516 | 7517 +---------------+---------------+---------------+------ 7518 ---------+ 7519 28| ExpC- 7520 mdSN | 7521 +---------------+---------------+---------------+------ 7522 ---------+ 7523 32| MaxC- 7524 mdSN | 7525 +---------------+---------------+---------------+------ 7527 Julian Satran Expires August 2002 56 7529 iSCSI 20-January-02 7531 ---------+ 7532 36/ Reserved 7533 / 7534 +/ 7535 / 7536 +---------------+---------------+---------------+------ 7537 ---------+ 7538 48| Digests if any... 7539 | 7540 +---------------+---------------+---------------+------ 7541 ---------+ 7542 / DataSegment (Text) 7543 / 7544 +/ 7545 / 7546 +---------------+---------------+---------------+------ 7547 ---------+ 7549 1.11.1 F (Final) Bit 7551 When set to 1, in response to a text request with the 7552 Final bit set to 1, the F bit indicates that the target 7553 has finished the whole operation. Otherwise, if set to 0 7554 in response to a text request with the Final Bit set to 1, 7555 it indicates that the target has more work to do (invites 7556 a follow-on text request). A text response with the F bit 7557 set to 1 in response to a text request with the F bit set 7558 to 0 is a protocol error. 7560 A text response with the F bit set to 1 MUST NOT contain 7561 key=value pairs that may require additional answers from 7562 the initiator. 7564 A text response with the F bit set to 1 MUST have a Target 7565 Transfer Tag field set to the reserved value of 7566 0xffffffff. 7568 A text response with the F bit set to 0 MUST have a Target 7569 Transfer Tag field set to a value other than the reserved 7570 0xffffffff. 7572 Julian Satran Expires August 2002 57 7574 iSCSI 20-January-02 7576 1.11.2 Initiator Task Tag 7578 The Initiator Task Tag matches the tag used in the initial 7579 Text request. 7581 1.11.3 Target Transfer Tag 7583 When a target has more work to do (e.g., cannot transfer 7584 all the remaining text data in a single Text response or 7585 has to continue the negotiation) and has enough resources 7586 to proceed, it MUST set the Target Transfer Tag to a value 7587 other than the reserved value of 0xffffffff. 7589 The initiator MUST copy this Target Transfer Tag in its 7590 next request to indicate that it wants the rest of the 7591 data. 7593 If the target receives a Text Request with the Target 7594 Transfer Tag set to the reserved value of 0xffffffff, it 7595 discards its internal information (resets state) associ- 7596 ated with the given Initiator Task Tag. 7598 When a target cannot finish the operation in a single text 7599 response, and does not have enough resources to continue 7600 it rejects the Text request with the appropriate Reject 7601 code. A target may reset its internal state associated 7602 with an Initiator Task Tag, state expressed through the 7603 Target Transfer Tag if the initiator fails to continue the 7604 exchange for some time. The target may reject subsequent 7605 Text requests with the Target Transfer Tag set to the 7606 "stale" value. 7608 1.11.4 Text Response Data 7610 The Text Response Data Segment contains responses in the 7611 same key=value format as the Text request and with the 7612 same length and coding constraints. Chapter 11 and Chapter 7613 12 list some basic Text key=value pairs, some of which can 7614 be used in Login Request/Response and some in Text 7615 Request/Response. 7617 As text for text requests and responses can span several 7618 PDUs (e.g., if the PDU length does not allow the whole 7619 text to be contained in a single PDU) the text response 7621 Julian Satran Expires August 2002 58 7623 iSCSI 20-January-02 7625 MAY refer to key=value pairs presented in an earlier text 7626 request. 7628 Although the initiator is the requesting party and con- 7629 trols the request-response initiation and termination, 7630 the target can offer key=value pairs of its own as part of 7631 a sequence and not only in response to the initiator. 7633 Julian Satran Expires August 2002 59 7635 iSCSI 20-January-02 7637 1.12 Login Request 7639 After establishing a TCP connection between an initiator 7640 and a target, the initiator MUST start a Login phase to 7641 gain further access to the target's resources. 7643 The Login Phase (see Chapter 4) consists of a sequence of 7644 Login requests and responses that carry the same Initiator 7645 Task Tag. 7647 Julian Satran Expires August 2002 60 7649 iSCSI 20-January-02 7651 Byte / 0 | 1 | 2 | 3 7652 | 7653 / | | | 7654 | 7655 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 7656 3 2 1 0| 7657 +---------------+---------------+---------------+------ 7658 ---------+ 7659 0|.|.| 0x03 |T|X|0 0|CSG|NSG| Version-max | Ver- 7660 sion-min | 7661 +---------------+---------------+---------------+------ 7662 ---------+ 7663 4| Reserved | DataSeg- 7664 mentLength | 7665 +---------------+---------------+---------------+------ 7666 ---------+ 7667 8| ISID 7668 | 7669 + +---------------+------ 7670 ---------+ 7671 12| |TSID 7672 | 7673 +---------------+---------------+---------------+------ 7674 ---------+ 7675 16| Initiator Task Tag 7676 | 7677 +---------------+---------------+---------------+------ 7678 ---------+ 7679 20| CID | Reserved 7680 | 7681 +---------------+---------------+---------------+------ 7682 ---------+ 7683 24| CmdSN 7684 | 7685 +---------------+---------------+---------------+------ 7686 ---------+ 7687 28| ExpStatSN or Reserved 7688 | 7689 +---------------+---------------+---------------+------ 7690 ---------+ 7691 32| Reserved 7692 | 7693 +---------------+---------------+---------------+------ 7695 Julian Satran Expires August 2002 61 7697 iSCSI 20-January-02 7699 ---------+ 7700 36| Reserved 7701 | 7702 +---------------+---------------+---------------+------ 7703 ---------+ 7704 40/ Reserved 7705 / 7706 +/ 7707 / 7708 +---------------+---------------+---------------+------ 7709 ---------+ 7710 48/ DataSegment - Login Parameters in Text request Format 7711 / 7712 +/ 7713 / 7714 +---------------+---------------+---------------+------ 7715 ---------+ 7717 1.12.1 T (Transit) Bit 7719 If set to 1, indicates that the initiator is ready to 7720 transit to the next stage. 7722 If the T bit is set to 1 and NSG is FullFeaturePhase, then 7723 this also indicates that the initiator is ready for the 7724 Final Login Response (see Chapter 4). 7726 If the response class is 0 the target MAY answer with a 7727 Login response with the T bit set to 1 ONLY if the T bit 7728 is set to 1 in the request. 7730 If the response class is not 0 the T bit value MUST be 7731 ignored by the initiator. 7733 1.12.2 X - Restart Connection 7735 If this bit is set to 1, then this command is an attempt 7736 to reinstate a failed connection or a failed session. 7738 The TSID MUST be non-zero if the X bit is 1. CID does not 7739 change and this command performs first the logout func- 7740 tion of the old connection if an explicit logout was not 7741 performed earlier. In sessions with a single connection, 7742 this may imply the opening of a second connection with the 7744 Julian Satran Expires August 2002 62 7746 iSCSI 20-January-02 7748 sole purpose of cleaning up the first. Targets should sup- 7749 port opening a second connection even when they do not 7750 support multiple connections in full feature phase. 7752 If TSID is 0 then the X bit MUST be 0. 7754 The X bit MAY be set to 1 ONLY on the first request of the 7755 Login phase. 7757 If the operational ErrorRecoveryLevel is 2, connection 7758 reinstatement is a complete connection recovery, which 7759 enables future task reassignment. If the operational 7760 ErrorRecoveryLevel is less than 2, connection reinstate- 7761 ment refers to the replacement of the old CID without 7762 enabling task reassignment. 7764 1.12.3 CSG and NSG 7766 Through these fields, Current Stage (CSG) and Next Stage 7767 (NSG), the Login negotiation commands and responses are 7768 associated with a specific stage in the session (Security- 7769 Negotiation, LoginOperationalNegotiation, FullFea- 7770 turePhase) and may indicate the next stage they want to 7771 move to (see Chapter 4). 7772 The next stage value is valid only when the T bit is 1; 7773 otherwise, it is reserved. 7775 The stage codes are: 7777 - 0 - SecurityNegotiation 7778 - 1 - LoginOperationalNegotiation 7779 - 3 - FullFeaturePhase 7781 1.12.4 Version-max 7783 Maximum Version number supported. 7785 All Login requests within the Login phase MUST carry the 7786 same Version-max. 7788 The target MUST use the value presented with the first 7789 login request. 7791 Julian Satran Expires August 2002 63 7793 iSCSI 20-January-02 7795 1.12.5 Version-min 7797 Minimum Version supported. The version number of the cur- 7798 rent draft is 0x3. 7800 All Login requests within the Login phase MUST carry the 7801 same Version-min. The target MUST use the value presented 7802 with the first login request. 7804 1.12.6 ISID 7806 This is an initiator-defined component of the session 7807 identifier (SSID). The ISID is structured as follows. See 7808 [NDT] and Section 9.1.1 Conservative Reuse of ISIDs for 7809 details. 7811 Byte / 0 | 1 | 2 | 3 7812 | 7813 / | | | 7814 | 7815 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 7816 3 2 1 0| 7817 +---------------+---------------+---------------+------ 7818 ---------+ 7819 0| Type | Naming Author- 7820 ity | 7821 +---------------+---------------+---------------+------ 7822 ---------+ 7823 4| Qualifier | 7824 +---------------+---------------+ 7826 The Type field identifies the format of the Naming Author- 7827 ity field and takes on three defined values with all other 7828 possible values reserved as indicated bellow: 7830 Type naming authority format 7831 0x00 IEEE OUI 7832 0x01 IANA Enterprise Number (EN) 7833 0x02 "Random" 7834 0x03-0xFF Reserved 7836 The Naming Authority field identifies the vendor or orga- 7837 nization whose component (SW or HW) generates this ISID. 7839 Julian Satran Expires August 2002 64 7841 iSCSI 20-January-02 7843 A vendor or organization with one or more OUIs, and/or one 7844 or more Enterprise Numbers, MUST use at least one of these 7845 numbers and select the appropriate value for the Type 7846 field when its components generate ISIDs. An OUI or EN 7847 MUST be set in the Naming Authority field in network byte 7848 order (BigEndian). 7850 If the Type field is 02h, the Naming Authority field 7851 SHOULD be set to a random or pseudo-random 24bit unsigned 7852 integer value in network byte order (BigEndian). See 7853 [NDT] for how this affects the principle of "conservative 7854 reuse". 7856 The Qualifier field is a 16 bit unsigned integer value 7857 that provides a range of possible values for the ISID 7858 within the Type and Naming Authority namespace. It may be 7859 set to any value, within the constraints specified in the 7860 iSCSI protocol (see Section 2.4.3 Consequences of the 7861 Model and Section 9.1.1 Conservative Reuse of ISIDs). 7863 1.12.7 TSID 7865 The TSID is the target assigned component of the session 7866 identifier (SSID). Together with the ISID, provided by 7867 the initiator, TSID uniquely identifies the session from 7868 that specific target with that initiator. 7870 On a Login request, a TSID value of 0 indicates a request 7871 to open a new session. 7873 A non-zero TSID indicates a request to add a connection to 7874 an existing session. 7876 1.12.8 Connection ID - CID 7878 A unique ID for this connection within the session. 7880 All Login requests within the Login phase MUST carry the 7881 same CID. 7883 The target MUST use the value presented with the first 7884 login request. 7886 Julian Satran Expires August 2002 65 7888 iSCSI 20-January-02 7890 1.12.9 CmdSN 7892 CmdSN is either the initial command sequence number of a 7893 session (for the first Login request of a session - the 7894 "leading" login) or the command sequence number in the 7895 command stream (e.g., if the leading login carries the 7896 CmdSN 123 all other Login requests carry the CmdSN 123 and 7897 the first non-immediate command also carries the CmdSN 7898 123). 7900 The target MUST use the value presented with the first 7901 login request. 7903 1.12.10 ExpStatSN 7905 This is ExpStatSN for the old connection. 7907 This field is valid only if the Login request restarts a 7908 connection (i.e., X bit is 1 and TSID is not zero). 7910 1.12.11 Login Parameters 7912 The initiator MAY provide some basic parameters in order 7913 to enable the target to determine if the initiator may use 7914 the target's resources and the initial text parameters for 7915 the security exchange. 7916 All the rules specified in Section 1.10.4 Text for text 7917 requests/responses also hold for login requests/ 7918 responses. Keys and their explanations are listed in 7919 Chapter 11 (security negotiation keys) and Chapter 12 7920 (operational parameter negotiation keys). All keys in 7921 Chapter 12, except for the X- extension format, MUST be 7922 supported by iSCSI initiators and targets. Keys in Chapter 7923 12, only need to be supported when the function to which 7924 they refer is mandatory to implement. 7926 Julian Satran Expires August 2002 66 7928 iSCSI 20-January-02 7930 1.13 Login Response 7932 The Login Response indicates the progress and/or end of 7933 the login phase. 7935 Julian Satran Expires August 2002 67 7937 iSCSI 20-January-02 7939 Byte / 0 | 1 | 2 | 3 7940 | 7941 / | | | 7942 | 7943 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 7944 3 2 1 0| 7945 +---------------+---------------+---------------+------ 7946 ---------+ 7947 0|.|.| 0x23 |T|0 0 0|CSG|NSG| Version-max | Ver- 7948 sion-active| 7949 +---------------+---------------+---------------+------ 7950 ---------+ 7951 4| Reserved | DataSeg- 7952 mentLength | 7953 +---------------+---------------+---------------+------ 7954 ---------+ 7955 8| ISID 7956 | 7957 + +---------------+------ 7958 ---------+ 7959 12| |TSID 7960 | 7961 +---------------+---------------+---------------+------ 7962 ---------+ 7963 16| Initiator Task Tag 7964 | 7965 +---------------+---------------+---------------+------ 7966 ---------+ 7967 20| Reserved 7968 | 7969 +---------------+---------------+---------------+------ 7970 ---------+ 7971 24| StatSN 7972 | 7973 +---------------+---------------+---------------+------ 7974 ---------+ 7975 28| ExpC- 7976 mdSN | 7977 +---------------+---------------+---------------+------ 7978 ---------+ 7979 32| MaxC- 7980 mdSN | 7981 +---------------+---------------+---------------+------ 7983 Julian Satran Expires August 2002 68 7985 iSCSI 20-January-02 7987 ---------+ 7988 36| Status-Class | Status-Detail | Reserved 7989 | 7990 +---------------+---------------+---------------+------ 7991 ---------+ 7992 40/ Reserved 7993 / 7994 +/ 7995 / 7996 +---------------+---------------+---------------+------ 7997 ---------+ 7998 48/ DataSegment - Login Parameters in Text request Format 7999 / 8000 +/ 8001 / 8002 +---------------+---------------+---------------+------ 8003 ---------+ 8005 1.13.1 Version-max 8007 This is the highest version number supported by the tar- 8008 get. 8010 All Login responses within the Login phase MUST carry the 8011 same Version-max. 8013 The initiator MUST use the value presented as a response 8014 to the first login request. 8016 1.13.2 Version-active 8018 Indicates the highest version supported by the target and 8019 initiator. If the target does not support a version within 8020 the range specified by the initiator, the target rejects 8021 the login and this field indicates the lowest version sup- 8022 ported by the target. 8024 All Login responses within the Login phase MUST carry the 8025 same Version-active. 8027 The initiator MUST use the value presented as a response 8028 to the first login request. 8030 Julian Satran Expires August 2002 69 8032 iSCSI 20-January-02 8034 1.13.3 TSID 8036 The TSID is the target assigned component of the session 8037 identifier (SSID). TSID and the ISID provided by the ini- 8038 tiator uniquely identify the session with that initiator. 8039 TSID MUST be valid only in the final response. 8041 1.13.4 StatSN 8043 For the first Login Response (the response to the first 8044 Login Request), this is the starting status Sequence Num- 8045 ber for the connection. The next response of any kind, 8046 including the next login response, if any, in the same 8047 login phase, will carry this number + 1. This field is 8048 valid only if the Status Class is 0. 8050 1.13.5 Status-Class and Status-Detail 8052 The Status returned in a Login Response indicates the exe- 8053 cution status of the login phase. The status includes: 8055 Status-Class 8056 Status-Detail 8058 0 Status-Class indicates success. 8060 A non-zero Status-Class indicates an exception. In this 8061 case, Status-Class is sufficient for a simple initiator to 8062 use when handling errors, without having to look at the 8063 Status-Detail. The Status-Detail allows finer-grained 8064 error recovery for more sophisticated initiators, as well 8065 as better information for error logging. 8067 The status classes are as follows: 8069 0 - Success - indicates that the iSCSI target suc- 8070 cessfully received, understood, and accepted the 8071 request. The numbering fields (StatSN, ExpCmdSN, 8072 MaxCmdSN) are valid only if Status-Class is 0. 8074 1 - Redirection - indicates that the initiator must 8075 take further action to complete the request. This 8076 is usually due to the target moving to a different 8077 address. All of the redirection status class 8078 responses MUST return one or more text key parame- 8080 Julian Satran Expires August 2002 70 8082 iSCSI 20-January-02 8084 ters of the type "TargetAddress", which indicates 8085 the target's new address. 8087 2 - Initiator Error (not a format error) - indicates 8088 that the initiator most likely caused the error. 8089 This MAY be due to a request for a resource for 8090 which the initiator does not have permission. The 8091 request should not be tried again. 8093 3 - Target Error - indicates that the target sees no 8094 errors in the initiator's login request, but is 8095 currently incapable of fulfilling the request. The 8096 client may re-try the same login request later. 8098 The table below shows all of the currently allocated sta- 8099 tus codes. The codes are in hexadecimal; the first byte 8100 is the status class and the second byte is the status 8101 detail. 8103 --------------------------------------------------------- 8104 -------- 8105 Status | Code | Description 8106 |(hex) | 8107 --------------------------------------------------------- 8108 -------- 8109 Success | 0000 | Login is proceeding OK (*1). 8110 --------------------------------------------------------- 8111 -------- 8112 Target Moved | 0101 | The requested iSCSI Target Name 8113 (ITN) Temporarily | | has temporarily moved 8114 | | to the address provided. 8115 --------------------------------------------------------- 8116 -------- 8117 Target Moved | 0102 | The requested ITN has permanently 8118 moved 8119 Permanently | | to the address provided. 8120 --------------------------------------------------------- 8121 -------- 8122 Initiator | 0200 | Miscellaneous iSCSI initiator 8123 Error | | errors. 8124 --------------------------------------------------------- 8125 ------- 8126 Authentication| 0201 | The initiator could not be 8127 Failure | | successfully authenticated. 8129 Julian Satran Expires August 2002 71 8131 iSCSI 20-January-02 8133 --------------------------------------------------------- 8134 -------- 8135 Authorization | 0202 | The initiator is not allowed access 8136 Failure | | to the given target. 8137 --------------------------------------------------------- 8138 -------- 8139 Not Found | 0203 | The requested ITN does not 8140 | | exist at this address. 8141 --------------------------------------------------------- 8142 -------- 8143 Target Removed| 0204 | The requested ITN has been removed 8144 and 8145 | |no forwarding address is provided. 8146 --------------------------------------------------------- 8147 -------- 8148 Unsupported | 0205 | The requested iSCSI version range 8149 is 8150 Version | | not supported by the target. 8151 --------------------------------------------------------- 8152 -------- 8153 Too many | 0206 | No more connections are accepted on 8154 this SID. 8155 connections | | 8156 --------------------------------------------------------- 8157 -------- 8158 Missing | 0207 | Missing parameters (e.g., iSCSI 8159 parameter | | Initiator and/or Target Name). 8160 --------------------------------------------------------- 8161 -------- 8162 Can't include | 0208 | Target does not support session 8163 in session | | spanning to this connection 8164 (address) 8165 --------------------------------------------------------- 8166 -------- 8167 Session type | 0209 | Target does not support this type 8168 of 8169 Not supported | | of session or not from this Initi- 8170 ator. 8171 --------------------------------------------------------- 8172 -------- 8173 Target Error | 0300 | Target hardware or software error. 8174 --------------------------------------------------------- 8175 -------- 8177 Julian Satran Expires August 2002 72 8179 iSCSI 20-January-02 8181 Service | 0301 | The iSCSI service or target is not 8182 Unavailable | | currently operational. 8183 --------------------------------------------------------- 8184 -------- 8185 Out of | 0302 | The target has insufficient ses- 8186 sion, 8187 Resources | | connection, or other resources. 8188 --------------------------------------------------------- 8189 -------- 8191 (*1)If the response T bit is 1 and the NSG is FullFea- 8192 turePhase in both the request and the response the login 8193 phase is finished and the initiator may proceed to issue 8194 SCSI commands. 8196 If the Status Class is not 0, the initiator and target 8197 MUST close the TCP connection. 8199 If the target wishes to reject the login request for more 8200 than one reason, it should return the primary reason for 8201 the rejection. 8203 1.13.6 T (Transit) bit 8205 The T bit is set to 1 as an indicator of the end of the 8206 stage. If the T bit is set to 1 and NSG is FullFea- 8207 turePhase, then this is also the Final Login Response (see 8208 Chapter 4). A T bit of 0 indicates a "partial" response, 8209 which means "more negotiation needed". 8211 A login response with a T bit set to 1 MUST NOT contain 8212 key=value pairs that may require additional answers from 8213 the initiator within the same stage. 8215 If the status class is 0, the T bit MUST NOT be set to 1 8216 if the T bit in the request was set to 0. 8218 If the status class is not 0 the T bit value MUST be set 8219 to 1 by the target and ignored by the initiator. 8221 Julian Satran Expires August 2002 73 8223 iSCSI 20-January-02 8225 1.14 Logout Request 8227 The Logout request is used to perform a controlled closing 8228 of a connection. 8230 An initiator MAY use a logout command to remove a connec- 8231 tion from a session or to close an entire session. 8233 After sending the Logout PDU, an initiator MUST NOT send 8234 any new iSCSI commands on the closing connection. If the 8235 Logout is intended to close the session, new iSCSI com- 8236 mands MUST NOT be sent on any of the connections partici- 8237 pating in the session. 8239 When receiving a Logout request with the reason code of 8240 "close the connection" or "close the session", the target 8241 MUST abort all pending commands, whether acknowledged or 8242 not, on that connection or session respectively. When 8243 receiving a Logout request with the reason code "remove 8244 connection for recovery", the target MUST discard all 8245 requests not yet acknowledged that were issued on the 8246 specified connection and suspend all data/status/R2T 8247 transfers on behalf of pending commands on the specified 8248 connection. The target then issues the Logout response 8249 and half-closes the TCP connection (sends FIN). After 8250 receiving the Logout response and attempting to receive 8251 the FIN (if still possible), the initiator MUST completely 8252 close the logging-out connection. For the aborted com- 8253 mands, no additional responses should be expected. 8255 A Logout for a CID may be performed on a different trans- 8256 port connection when the TCP connection for the CID has 8257 already been terminated. In such a case, only a logical 8258 "closing" of the iSCSI connection for the CID is implied 8259 with a Logout. 8261 All commands that were not aborted or not completed (with 8262 status) and acknowledged when the connection is closed 8263 completely can be reassigned to a new connection if the 8264 target supports connection recovery. 8266 If an initiator intends to start recovery for a failing 8267 connection, it MUST use either the Logout command to 8269 Julian Satran Expires August 2002 74 8271 iSCSI 20-January-02 8273 "clean-up" the target end of a failing connection and 8274 enable recovery to start, or use the restart option of the 8275 Login command for the same effect. In sessions with a 8276 single connection, this may imply the opening of a second 8277 connection with the sole purpose of cleaning-up the first. 8278 In this case, the restart option of the Login should be 8279 used. 8281 Sending a logout request with the reason code of "close 8282 the connection" or "remove the connection for recovery" 8283 may result in the discarding of some unacknowledged com- 8284 mands. Those holes in command sequence numbers will have 8285 to be handled by appropriate recovery (see Chapter 7) 8286 unless the session is also closed. 8288 Julian Satran Expires August 2002 75 8290 iSCSI 20-January-02 8292 Byte / 0 | 1 | 2 | 3 8293 | 8294 / | | | 8295 | 8296 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 8297 3 2 1 0| 8298 +---------------+---------------+---------------+------ 8299 ---------+ 8300 0|.|I| 0x06 |1| Reserved 8301 | 8302 +---------------+---------------+---------------+------ 8303 ---------+ 8304 4| Reserved 8305 | 8306 +---------------+---------------+---------------+------ 8307 ---------+ 8308 8| Reserved 8309 | 8310 +---------------+---------------+---------------+------ 8311 ---------+ 8312 12| Reserved 8313 | 8314 +---------------+---------------+---------------+------ 8315 ---------+ 8316 16| Initiator Task Tag 8317 | 8318 +---------------+---------------+---------------+------ 8319 ---------+ 8320 20| CID or Reserved | Reserved |Reason 8321 Code | 8322 +---------------+---------------+---------------+------ 8323 ---------+ 8324 24| CmdSN 8325 | 8326 +---------------+---------------+---------------+------ 8327 ---------+ 8328 28| Exp- 8329 StatSN | 8330 +---------------+---------------+---------------+------ 8331 ---------+ 8332 32/ Reserved 8333 / 8334 +/ 8336 Julian Satran Expires August 2002 76 8338 iSCSI 20-January-02 8340 / 8341 +---------------+---------------+---------------+------ 8342 ---------+ 8343 48| Digest (if any) 8344 | 8345 +------------------------------------------------------ 8346 ---------+ 8348 1.14.1 CID 8350 This is the connection ID of the connection to be closed 8351 (including closing the TCP stream). This field is valid 8352 only if the reason code is not "close the session". 8354 1.14.2 ExpStatSN 8356 This is the last ExpStatSN value for the connection to be 8357 closed. 8359 1.14.3 Reason Code 8361 Indicates the reason for Logout: 8363 0 - closes the session. All commands associated with 8364 the session (if any) are aborted. 8366 1 - closes the connection. All commands associated 8367 with connection (if any) are aborted. 8369 2 - removes the connection for recovery. Connection 8370 is closed and all commands associated with it, if 8371 any, are to be prepared for a new allegiance. 8373 Julian Satran Expires August 2002 77 8375 iSCSI 20-January-02 8377 1.15 Logout Response 8379 The logout response is used by the target to indicate if 8380 the cleanup operation for the connection(s) has com- 8381 pleted. 8383 After Logout, the TCP connection referred by the CID MUST 8384 be closed at both ends (or all connections must be closed 8385 if the logout reason was session close). 8387 Julian Satran Expires August 2002 78 8389 iSCSI 20-January-02 8391 Byte / 0 | 1 | 2 | 3 8392 | 8393 / | | | 8394 | 8395 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 8396 3 2 1 0| 8397 +---------------+---------------+---------------+------ 8398 ---------+ 8399 0|.|.| 0x26 |1| Reserved | Response | 8400 Reserved | 8401 +---------------+---------------+---------------+------ 8402 ---------+ 8403 4/ Reserved 8404 / 8405 +/ 8406 / 8407 +---------------+---------------+---------------+------ 8408 ---------+ 8409 16| Initiator Task Tag 8410 | 8411 +---------------+---------------+---------------+------ 8412 ---------+ 8413 20| Reserved 8414 | 8415 +---------------+---------------+---------------+------ 8416 ---------+ 8417 24| StatSN 8418 | 8419 +---------------+---------------+---------------+------ 8420 ---------+ 8421 28| ExpC- 8422 mdSN | 8423 +---------------+---------------+---------------+------ 8424 ---------+ 8425 32| MaxC- 8426 mdSN | 8427 +---------------+---------------+---------------+------ 8428 ---------+ 8429 36| Reserved 8430 | 8431 +------------------------------------------------------ 8432 ---------+ 8433 40| Time2Wait | Time2Retain 8435 Julian Satran Expires August 2002 79 8437 iSCSI 20-January-02 8439 | 8440 +---------------+---------------+---------------+------ 8441 ---------+ 8442 44| Reserved 8443 | 8444 +---------------+---------------+---------------+------ 8445 ---------+ 8446 48| Digest (if any) 8447 | 8448 +------------------------------------------------------ 8449 ---------+ 8451 1.15.1 Response 8453 Logout response: 8455 0 - connection or session closed successfully. 8457 1 - CID not found. 8459 2 - connection recovery not supported (if Logout rea- 8460 son code was recovery and target does not support 8461 it- as indicated by the ErrorRecoveryLevel. 8463 3 - cleanup failed for various reasons. 8465 1.15.2 Time2Wait 8467 The minimum amount of time, in seconds, to wait before 8468 Login to add or reinstate a new connection to this session 8469 on this target. If Time2Wait is 0 a new Login may be 8470 attempted immediately. 8472 1.15.3 Time2Retain 8474 If ErrorRecoveryLevel is less than 2, the maximum time, in 8475 seconds, that the target waits for a connection reinstate- 8476 ment Login, after the initial wait (Time2Wait), after 8477 which the connection state is discarded. If it is the last 8478 connection of a session, the whole session state is dis- 8479 carded after Time2Retain. If ErrorRecoveryLevel is 2, 8480 this is the maximum time, in seconds, after the initial 8481 wait (Time2Wait), the target waits for the allegiance 8482 reassignment for any active task after which the task 8483 state is discarded. 8485 Julian Satran Expires August 2002 80 8487 iSCSI 20-January-02 8489 If Time2Retain is 0 the connection (or session state) is 8490 discarded by the target. 8492 Julian Satran Expires August 2002 81 8494 iSCSI 20-January-02 8496 1.16 SNACK Request 8498 Byte / 0 | 1 | 2 | 3 8499 | 8500 / | | | 8501 | 8502 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 8503 3 2 1 0| 8504 +---------------+---------------+---------------+------ 8505 ---------+ 8506 0|.|.| 0x10 |1|Rsrvd| Type | Reserved 8507 | 8508 +---------------+---------------+---------------+------ 8509 ---------+ 8510 4/ Reserved 8511 / 8512 +/ 8513 / 8514 +---------------+---------------+---------------+------ 8515 ---------+ 8516 16| Initiator Task Tag or 0xffffffff 8517 | 8518 +---------------+---------------+---------------+------ 8519 ---------+ 8520 20| BegRun 8521 | 8522 +---------------+---------------+---------------+------ 8523 ---------+ 8524 24| Run- 8525 Length | 8526 +---------------+---------------+---------------+------ 8527 ---------+ 8528 28| Exp- 8529 StatSN | 8530 +---------------+---------------+---------------+------ 8531 ---------+ 8532 32/ Reserved 8533 / 8534 +/ 8535 / 8536 +---------------+---------------+---------------+------ 8537 ---------+ 8538 48| Digest (if any) 8540 Julian Satran Expires August 2002 82 8542 iSCSI 20-January-02 8544 | 8545 +------------------------------------------------------ 8546 ---------+ 8548 Support for SNACK is optional. 8550 The SNACK request is used to request the retransmission of 8551 numbered-responses, data, or R2T PDUs from the target. 8552 The SNACK request indicates the missed numbered-response 8553 or data "run" to the target, where the run starts with the 8554 first missed StatSN, DataSN, or R2TSN and indicates also 8555 the number of missed Status, Data, or R2T PDUs (0 has the 8556 special meaning of "all after the initial"). 8558 The numbered-response(s) or R2T(s), requested by a SNACK, 8559 MUST be delivered as exact replicas of the ones the initi- 8560 ator missed and MUST include all its flags. However, the 8561 fields ExpCmdSN, MaxCmdSN and ExpDataSN MUST carry the 8562 current values. 8564 The numbered Data-In PDUs, requested by a SNACK with a 8565 RunLength different from 0, have to be delivered as exact 8566 replicas of the ones the initiator missed and MUST include 8567 all its flags. However, the fields ExpCmdSN and MaxCmdSN 8568 MUST carry the current values. Data-In PDUs requested 8569 with RunLength 0 (meaning all PDUs after this number) may 8570 be different from the ones originally sent, in order to 8571 reflect changes in MaxRecvPDULength. 8573 Any SNACK that requests a numbered-response, Data, or R2T 8574 that was not sent by the target MUST be rejected with a 8575 reason code of "Protocol error". 8577 1.16.1 Type 8579 This field encodes the SNACK function as follows: 8581 0-Data/R2T SNACK - requesting retransmission of a 8582 Data-In or R2T PDU. 8584 1-Status SNACK - requesting retransmission of a num- 8585 bered response. 8587 2-DataACK - positively acknowledges Data-In PDUs. 8589 Julian Satran Expires August 2002 83 8591 iSCSI 20-January-02 8593 All other values are reserved. 8595 Data/R2T SNACK for a command MUST precede status acknowl- 8596 edgement for the given command. 8598 For a Data/R2T SNACK, the Initiator Task Tag MUST be set 8599 to the Initiator Task Tag of the referenced Command. Oth- 8600 erwise, it is reserved. 8602 An iSCSI target that does not support recovery within con- 8603 nection MAY discard the status SNACK. If the target sup- 8604 ports recovery within connection, it MAY discard the SNACK 8605 after which it MUST issue an Asynchronous Message PDU with 8606 an iSCSI event that indicates "Request Logout". 8608 If an initiator operates at ErrorRecoveryLevel 1 or 8609 higher, it MUST issue a SNACK of type DataACK after 8610 receiving a Data-In PDU with the A bit set to 1. However, 8611 if the initiator has detected holes in the input sequence, 8612 it MUST postpone issuing the SNACK of type DataACK until 8613 the holes are filled. An initiator MAY ignore the A bit if 8614 it deems that the bit is being set aggressively by the 8615 target (i.e., before the MaxBurstSize limit is 8616 reached). 8618 The DataACK is used to free resources at the target and 8619 not to request or imply data retransmission. 8621 1.16.2 BegRun 8623 The first missed DataSN, R2TSN, or StatSN or the next 8624 expected DataSN for a DataACK type SNACK request. 8626 1.16.3 RunLength 8628 The number of sequential missed DataSN, R2TSN or StatSN. 8629 RunLength of "0" signals that all Data-In, R2T or Response 8630 PDUs carrying the numbers equal to or greater to BegRun 8631 have to be resent. 8633 The first data SNACK, issued after initiator�s MaxRecvPD- 8634 ULength decreased, for a command issued on the same con- 8635 nection before the change in MaxRecvPDULength, MUST use 8637 Julian Satran Expires August 2002 84 8639 iSCSI 20-January-02 8641 RunLength "0" to request retransmission of any number of 8642 PDUs (including one). The number of retransmitted PDUs in 8643 this case, may or may not be the same as the original 8644 transmission, depending on whether loss was before or 8645 after the MaxRecvPDULength was changed at the target. 8647 Julian Satran Expires August 2002 85 8649 iSCSI 20-January-02 8651 1.17 Reject 8653 Byte / 0 | 1 | 2 | 3 8654 | 8655 / | | | 8656 | 8657 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 8658 3 2 1 0| 8659 +---------------+---------------+---------------+------ 8660 ---------+ 8661 0|.|.| 0x3f |1| Reserved | Reason | 8662 Reserved | 8663 +---------------+---------------+---------------+------ 8664 ---------+ 8665 4| Reserved | DataSeg- 8666 mentLength | 8667 +---------------+---------------+---------------+------ 8668 ---------+ 8669 8/ Reserved 8670 / 8671 +/ 8672 / 8673 +---------------+---------------+---------------+------ 8674 ---------+ 8675 24| StatSN 8676 | 8677 +---------------+---------------+---------------+------ 8678 ---------+ 8679 28| ExpC- 8680 mdSN | 8681 +---------------+---------------+---------------+------ 8682 ---------+ 8683 32| MaxC- 8684 mdSN | 8685 +---------------+---------------+---------------+------ 8686 ---------+ 8687 36| DataSN or Reserved 8688 | 8689 +---------------+---------------+---------------+------ 8690 ---------+ 8691 40| Reserved 8692 | 8693 +---------------+---------------+---------------+------ 8695 Julian Satran Expires August 2002 86 8697 iSCSI 20-January-02 8699 ---------+ 8700 44| Reserved 8701 | 8702 +---------------+---------------+---------------+------ 8703 ---------+ 8704 48| Digest (if any) 8705 | 8706 +---------------+---------------+---------------+------ 8707 ---------+ 8708 xx/ Complete Header of Bad PDU 8709 / 8710 +/ 8711 / 8712 +---------------+---------------+---------------+------ 8713 ---------+ 8714 yy/Vendor specific data (if any) 8715 / 8716 / 8717 / 8718 +---------------+---------------+---------------+------ 8719 ---------+ 8720 zz 8722 Reject is used to indicate an iSCSI error condition (pro- 8723 tocol, unsupported option etc.). 8725 1.17.1 Reason 8727 The reject Reason is coded as follows: 8729 Julian Satran Expires August 2002 87 8731 iSCSI 20-January-02 8733 +------+-----------------------------------------+------- 8734 -----------+ 8735 | Code | Explanation | Can the 8736 original | 8737 | (hex)| | PDU be 8738 re-sent? | 8739 +------+-----------------------------------------+------- 8740 -----------+ 8741 | 0x01 | Full Feature Phase Command before login | no 8742 | 8743 | | | 8744 | 8745 | 0x02 | Data (payload) Digest Error | yes 8746 (Note 1) | 8747 | | | 8748 | 8749 | 0x03 | Data-SNACK Reject | yes 8750 | 8751 | | | 8752 | 8753 | 0x04 | Protocol Error (e.g., SNACK request for | no 8754 | 8755 | | a status that was already acknowledged | 8756 | 8757 | | | 8758 | 8759 | 0x05 | Command not supported in this session | no 8760 | 8761 | | type | 8762 | 8763 | | | 8764 | 8765 | 0x06 | Immediate Command Reject - too many | yes 8766 | 8767 | | immediate commands | 8768 | 8769 | | | 8770 | 8771 | 0x07 | Task in progress | no 8772 | 8773 | | | 8774 | 8775 | 0x08 | Invalid Data ACK | no 8777 Julian Satran Expires August 2002 88 8779 iSCSI 20-January-02 8781 | 8782 | | | 8783 | 8784 | 0x09 | Invalid PDU field | no 8785 (Note 2) | 8786 | | | 8787 | 8788 | 0x0a | Long Operation Reject - Can't generate | yes 8789 | 8790 | | Target Transfer Tag - out of resources | 8791 | 8792 | | | 8793 | 8794 | 0x0b | Negotiation Reset | no 8795 | 8796 | | | 8797 | 8798 | 0x0c | Waiting for Logout | no 8799 | 8800 +------+-----------------------------------------+------- 8801 -----------+ 8803 Note 1: For iSCSI Data-Out PDU retransmission is done only 8804 if the target requests retransmission with a recovery R2T. 8805 However, if this is the data digest error on immediate 8806 data, the initiator may choose to retransmit the whole PDU 8807 including the immediate data. 8809 Note 2: A target should use this reason code for all 8810 invalid values of PDU fields that are meant to describe a 8811 task or a data transfer. Some examples are invalid TTT/ 8812 ITT, buffer offset, LUN qualifying a TTT. 8814 All other values for Reason are reserved. 8816 In all the cases in which a pre-instantiated SCSI task is 8817 terminated because of the reject, the target must issue a 8818 proper SCSI command response with CHECK CONDITION as 8819 described in Section 1.4.3 Response. In those cases in 8820 which a status for the SCSI task was already sent before 8821 the reject no additional status is required. If the error 8822 is detected while data from the initiator is still 8823 expected (the command PDU did not contain all the data and 8825 Julian Satran Expires August 2002 89 8827 iSCSI 20-January-02 8829 the target has not received a Data-out PDU with the Final 8830 bit 1), the target MUST wait until it receives the Data- 8831 out PDU with the F bit set to 1 before sending the 8832 Response PDU. 8834 For additional usage semantics of Reject PDU, see Section 8835 7.2 Usage Of Reject PDU in Recovery. 8837 1.17.2 DataSN 8839 This field is valid only if the Reason code is "Protocol 8840 error" and the SNACK was a Data/R2T SNACK. The DataSN/ 8841 R2TSN is the last valid sequence number that the target 8842 sent for the task. 8844 1.17.3 Complete Header of Bad PDU 8846 The target returns the header (not including digest) of 8847 the PDU in error as the data of the response. 8849 Julian Satran Expires August 2002 90 8851 iSCSI 20-January-02 8853 1.18 NOP-Out 8855 Byte / 0 | 1 | 2 | 3 8856 | 8857 / | | | 8858 | 8859 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 8860 3 2 1 0| 8861 +---------------+---------------+---------------+------ 8862 ---------+ 8863 0|.|I| 0x00 |1| Reserved 8864 | 8865 +---------------+---------------+---------------+------ 8866 ---------+ 8867 4| Reserved | DataSeg- 8868 mentLength | 8869 +---------------+---------------+---------------+------ 8870 ---------+ 8871 8| LUN or Reserved 8872 | 8873 + 8874 + 8875 12| 8876 | 8877 +---------------+---------------+---------------+------ 8878 ---------+ 8879 16| Initiator Task Tag or 0xffffffff 8880 | 8881 +---------------+---------------+---------------+------ 8882 ---------+ 8883 20| Target Transfer Tag or 0xffffffff 8884 | 8885 +---------------+---------------+---------------+------ 8886 ---------+ 8887 24| CmdSN 8888 | 8889 +---------------+---------------+---------------+------ 8890 ---------+ 8891 28| Exp- 8892 StatSN | 8893 +---------------+---------------+---------------+------ 8894 ---------+ 8895 32/ Reserved 8897 Julian Satran Expires August 2002 91 8899 iSCSI 20-January-02 8901 / 8902 +/ 8903 / 8904 +---------------+---------------+---------------+------ 8905 ---------+ 8906 48| Digests if any... 8907 | 8908 +---------------+---------------+---------------+------ 8909 ---------+ 8910 / DataSegment - Ping Data (optional) 8911 / 8912 +/ 8913 / 8914 +---------------+---------------+---------------+------ 8915 ---------+ 8917 A NOP-Out may be used by an initiator as a "ping command" 8918 to verify that a connection/session is still active and 8919 all its components are operational. The NOP-In 8920 response is the "ping echo". 8922 A NOP-Out is also sent by an initiator in response to a 8923 NOP-In. 8925 A NOP-Out may also be used to confirm a changed ExpStatSN 8926 if another PDU will not be available for a long time. 8928 When used as a ping command, the Initiator Task Tag MUST 8929 be set to a valid value (not the reserved 0xffffffff). 8931 Upon receipt of a NOP-In with the Target Transfer Tag set 8932 to a valid value (not the reserved 0xffffffff), the initi- 8933 ator MUST respond with a NOP-Out. In this case, the NOP- 8934 Out Target Transfer Tag MUST contain a copy of the NOP-In 8935 Target Transfer Tag. 8937 When a target receives the NOP-Out with a valid Initiator 8938 Task Tag, it MUST respond with a Nop-In Response (see NOP- 8939 In). 8941 1.18.1 Initiator Task Tag 8943 An initiator assigned identifier for the operation. 8945 Julian Satran Expires August 2002 92 8947 iSCSI 20-January-02 8949 The NOP-Out must have the Initiator Task Tag set to a 8950 valid value only if a response in the form of NOP-In is 8951 requested. 8953 If the Initiator Task Tag contains 0xffffffff, the CmdSN 8954 field contains the next CmdSN. However, CmdSN is not 8955 advanced and the I bit must be set to 1. 8957 1.18.2 Target Transfer Tag 8959 A target assigned identifier for the operation. 8961 The NOP-Out MUST have the Target Transfer Tag set only if 8962 it is issued in response to a NOP-In with a valid Target 8963 Transfer Tag. In this case, it copies the Target Transfer 8964 Tag from the NOP-In PDU. 8966 When the Target Transfer Tag is set, the LUN field MUST 8967 also be copied from the NOP-In. 8969 1.18.3 Ping Data 8971 Ping data is reflected in the NOP-In Response. The length 8972 of the reflected data is limited to MaxRecvPDULength. The 8973 length of ping data is indicated by the Data Segment 8974 Length. 0 is a valid value for the Data Segment Length 8975 and indicates the absence of ping data. 8977 Julian Satran Expires August 2002 93 8979 iSCSI 20-January-02 8981 1.19 NOP-In 8983 Byte / 0 | 1 | 2 | 3 8984 | 8985 / | | | 8986 | 8987 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 8988 3 2 1 0| 8989 +---------------+---------------+---------------+------ 8990 ---------+ 8991 0|.|.| 0x20 |1| Reserved 8992 | 8993 +---------------+---------------+---------------+------ 8994 ---------+ 8995 4| Reserved | DataSeg- 8996 mentLength | 8997 +---------------+---------------+---------------+------ 8998 ---------+ 8999 8| LUN or Reserved 9000 | 9001 + 9002 + 9003 12| 9004 | 9005 +---------------+---------------+---------------+------ 9006 ---------+ 9007 16| Initiator Task Tag or 0xffffffff 9008 | 9009 +---------------+---------------+---------------+------ 9010 ---------+ 9011 20| Target Transfer Tag or 0xffffffff 9012 | 9013 +---------------+---------------+---------------+------ 9014 ---------+ 9015 24| StatSN 9016 | 9017 +---------------+---------------+---------------+------ 9018 ---------+ 9019 28| ExpC- 9020 mdSN | 9021 +---------------+---------------+---------------+------ 9022 ---------+ 9023 32| MaxC- 9025 Julian Satran Expires August 2002 94 9027 iSCSI 20-January-02 9029 mdSN | 9030 +---------------+---------------+---------------+------ 9031 ---------+ 9032 36/ Reserved 9033 / 9034 +/ 9035 / 9036 +---------------+---------------+---------------+------ 9037 ---------+ 9038 48| Digests if any... 9039 | 9040 +---------------+---------------+---------------+------ 9041 ---------+ 9042 / DataSegment - Return Ping Data 9043 / 9044 +/ 9045 / 9046 +---------------+---------------+---------------+------ 9047 ---------+ 9049 NOP-In is either sent by a target as a response to a NOP- 9050 Out, as a "ping" to an initiator or as a means to carry a 9051 changed ExpCmdSN and/or MaxCmdSN if another PDU will not 9052 be available for a long time (as determined by the tar- 9053 get). 9055 When a target receives the NOP-Out with a valid Initiator 9056 Task Tag (not the reserved value 0xffffffff), it MUST 9057 respond with a NOP-In with the same Initiator Task Tag 9058 that was provided in the NOP-Out Command. It MUST also 9059 duplicate up to the first MaxRecvPDULength bytes of the 9060 initiator provided Ping Data. For such a response, the 9061 Target Transfer Tag MUST be 0xffffffff. 9063 When a target send a NOP-In as a "ping" (the Initiator 9064 Task Tag is 0xffffffff) it MUST NOT send any data in the 9065 data segment (DataSegmentLength MUST be 0). 9067 1.19.1 Target Transfer Tag 9069 A target assigned identifier for the operation. 9071 Julian Satran Expires August 2002 95 9073 iSCSI 20-January-02 9075 If the target is responding to a NOP-Out, this is set to 9076 the reserved value 0xffffffff. 9078 If the target is sending a NOP-In as a Ping (intending to 9079 receive a corresponding NOP-Out), this field is set to a 9080 valid value (not the reserved 0xffffffff). 9082 If the target is initiating a NOP-In without wanting to 9083 receive a corresponding NOP-Out, this field MUST hold the 9084 reserved value of 0xffffffff. 9086 Whenever the NOP-In is sent as a "ping" to an initiator 9087 (not as a response to a NOP-Out), the StatSN field will 9088 contain the next StatSN. However, StatSN for this connec- 9089 tion is not advanced. 9091 1.19.2 LUN 9093 A LUN MUST be set to a correct value when the Target 9094 Transfer Tag is valid (not the reserved value 0xffffffff). 9096 Julian Satran Expires August 2002 96 9098 iSCSI 20-January-02 9100 1. iSCSI Security Keys and Values 9102 The following keys can only be used during the SecurityNe- 9103 gotiatian stage of the Login Phase. 9105 All security keys have connection-wide applicability. 9107 1.1 AuthMethod 9109 Senders: Initiator and Target 9111 AuthMethod = 9113 The main item of security negotiation is the authentica- 9114 tion method (AuthMethod). 9116 The authentication methods that can be used (appear in the 9117 list-of-options) are either those listed in the following 9118 table or are vendor-unique methods: 9120 Julian Satran Expires August 2002 1 9122 iSCSI 20-January-02 9124 +-------------------------------------------------------- 9125 ----+ 9126 | Name | Description 9127 | 9128 +-------------------------------------------------------- 9129 ----+ 9130 | KRB5 | Kerberos V5 9131 | 9132 +-------------------------------------------------------- 9133 ----+ 9134 | SPKM1 | Simple Public-Key GSS-API Mecha- 9135 nism | 9136 +-------------------------------------------------------- 9137 ----+ 9138 | SPKM2 | Simple Public-Key GSS-API Mecha- 9139 nism | 9140 +-------------------------------------------------------- 9141 ----+ 9142 | SRP | Secure Remote Pass- 9143 word | 9144 +-------------------------------------------------------- 9145 ----+ 9146 | CHAP | Challenge Handshake Authentication Pro- 9147 tocol| 9148 +-------------------------------------------------------- 9149 ----+ 9150 | none | No authentication 9151 | 9152 +-------------------------------------------------------- 9153 ----+ 9155 KRB5 is defined in [RFC1510]. 9156 SPKM1 and SPKM2 are defined in [RFC2025]. 9157 SRP is defined in [RFC2945] and CHAP is defined in 9158 [RFC1994]. 9160 The AuthMethod selection is followed by an "authentica- 9161 tion exchange" specific to the authentication method 9162 selected. 9164 The authentication exchange authenticates the initiator 9165 to the target, and optionally, the target to the initia- 9167 Julian Satran Expires August 2002 2 9169 iSCSI 20-January-02 9171 tor. Authentication is not mandatory to use but must be 9172 supported by the target and initiator. 9174 The initiator and target MUST implement SRP. 9176 1.2 Kerberos 9178 For KRB5 (Kerberos V5) [RFC1510], the initiator MUST use: 9180 KRB_AP_REQ= 9182 where KRB_AP_REQ is the client message as defined in 9183 [RFC1510]. 9185 If the initiator authentication fails, the target MUST 9186 answer with a Login reject with "Authentication Failure" 9187 status. Otherwise, if the initiator has selected the 9188 mutual authentication option (by setting MUTUAL-REQUIRED 9189 in the ap-options field of the KRB_AP_REQ), the target 9190 MUST reply with: 9192 KRB_AP_REP= 9194 where KRB_AP_REP is the server's response message as 9195 defined in 9196 [RFC1510]. 9198 If mutual authentication was selected and target authen- 9199 tication fails, the initiator MUST close the connection. 9201 KRB_AP_REQ and KRB_AP_REP are large binary items and their 9202 binary length (not the length of the character string that 9203 represents them in encoded form) MUST not exceed 65536 9204 bytes. 9206 1.3 Simple Public-Key Mechanism (SPKM) 9208 For SPKM1 and SPKM2 [RFC2025], the initiator MUST use: 9210 SPKM_REQ= 9212 where SPKM-REQ is the first initiator token as defined in 9213 [RFC2025]. 9215 Julian Satran Expires August 2002 3 9217 iSCSI 20-January-02 9219 [RFC2025] defines situations where each side may send an 9220 error token 9221 that may cause the peer to re-generate and resend its last 9222 token. This scheme is followed in iSCSI, and the error 9223 token syntax is: 9225 SPKM_ERROR= 9227 However, SPKM-DEL tokens that are defined by [RFC2025] for 9228 fatal errors will not be used by iSCSI. If the target 9229 needs to send a SPKM-DEL token(by[RFC2025], it will, 9230 instead, send a Login "login reject" message with the 9231 "Authentication Failure" status and terminate the connec- 9232 tion. If the initiator needs to send a SPKM-DEL token, it 9233 will close the connection. 9235 In the following sections, we assume that no SPKM-ERROR 9236 tokens are required. 9238 If the initiator authentication fails, the target MUST 9239 return an error. Otherwise, if the AuthMethod is SPKM1 or 9240 if the initiator has selected the mutual authentication 9241 option (by setting mutual-state bit in the options field 9242 of the REQ-TOKEN in the SPKM-REQ), the target MUST reply 9243 with: 9245 SPKM_REP_TI= 9247 where SPKM-REP-TI is the target token as defined in 9248 [RFC2025]. 9250 If mutual authentication was selected and target authen- 9251 tication fails, the initiator MUST close the connection. 9252 Otherwise, if the AuthMethod is SPKM1, the initiator MUST 9253 continue with: 9255 SPKM_REP_IT= 9257 where SPKM-REP-IT is the second initiator token as defined 9258 in [RFC2025]. If the initiator authentication fails, the 9259 target MUST answer with a Login reject with "Authentica- 9260 tion Failure" status. 9262 Julian Satran Expires August 2002 4 9264 iSCSI 20-January-02 9266 All the SPKM-* tokens are large binary items and their 9267 binary length (not the length of the character string that 9268 represents them in encoded form) MUST not exceed 65536 9269 bytes. 9271 1.4 Secure Remote Password (SRP) 9273 For SRP [RFC2945], the initiator MUST use: 9275 SRP_U= TargetAuth=yes /* or TargetAuth=no */ 9277 The target MUST answer with a Login reject with the 9278 "Authorization Failure" status or reply with: 9280 SRP_N= SRP_g= SRP_s= 9282 The initiator MUST either close the connection or continue 9283 with: 9285 SRP_A= 9287 The target MUST answer with a Login reject with the 9288 "Authentication Failure" status or reply with: 9290 SRP_B= 9292 The initiator MUST close the connection or continue with: 9294 SRP_M= 9296 If the initiator authentication fails, the target MUST 9297 answer with a Login reject with "Authentication Failure" 9298 status. Otherwise, if the initiator sent TargetAuth=yes 9299 in the first message (requiring target authentication), 9300 the target MUST reply with: 9302 SRP_HM= 9304 If the target authentication fails, the initiator MUST 9305 close the connection. 9307 Julian Satran Expires August 2002 5 9309 iSCSI 20-January-02 9311 Where U, N, g, s, A, B, M, and H(A | M | K) are defined in 9312 [RFC2945] (using the SHA1 hash function, i.e., SRP-SHA1), 9313 U is a text string, N,g,s,A,B,M, and H(A | M | K) are 9314 binary items, and their binary length (not the length of 9315 the character string that represents them in encoded form) 9316 MUST not exceed 1024 bytes. Further restrictions on 9317 allowed N,g values are specified in Section 8.2 In-band 9318 Initiator-Target Authentication. 9320 1.5 Challenge Handshake Authentication Protocol (CHAP) 9322 For CHAP [RFC1994], the initiator MUST use: 9324 CHAP_A= 9326 Where A1,A2... are proposed algorithms, in order of pref- 9327 erence. 9329 The target MUST answer with a Login reject with the 9330 "Authentication Failure" status or reply with: 9332 CHAP_A= CHAP_I= CHAP_C= 9334 Where A is one of A1,A2... that were proposed by the ini- 9335 tiator. 9337 The initiator MUST continue with: 9339 CHAP_N= CHAP_R= 9341 or, if it requires target authentication, with: 9343 CHAP_N= CHAP_R= CHAP_I= CHAP_C= 9345 If the initiator authentication fails, the target MUST 9346 answer with a Login reject with "Authentication Failure" 9347 status. Otherwise, if the initiator required target 9348 authentication, the target MUST reply with 9350 CHAP_N= CHAP_R= 9352 If target authentication fails, the initiator MUST close 9353 the connection. 9355 Julian Satran Expires August 2002 6 9357 iSCSI 20-January-02 9359 Where N, (A,A1,A2), I, C, and R are (correspondingly) the 9360 Name, Algorithm, Identifier, Challenge, and Response as 9361 defined in [RFC1994], N is a text string, A,A1,A2, and I 9362 are numbers, and C and R are binary items and their binary 9363 length (not the length of the character string that repre- 9364 sents them in encoded form) MUST not exceed 1024 bytes. 9366 For the Algorithm, as stated in [RFC1994], one value is 9367 required 9368 to be implemented: 9370 5 (CHAP with MD5) 9372 To guarantee interoperability, initiators SHOULD always 9373 offer it as one of the proposed algorithms. 9375 Julian Satran Expires August 2002 7 9377 iSCSI 20-January-02 9379 1. Login/Text Operational Keys 9381 The ISID and TSID collectively form the SSID (session id). 9382 A TSID of zero indicates a leading connection. Some ses- 9383 sion specific parameters MUST only be carried on the lead- 9384 ing connection and cannot be changed after the leading 9385 connection login (e.g., MaxConnections, the maximum num- 9386 ber of connections). This holds for a single connection 9387 session with regard to connection restart. The keys that 9388 fall into this category have the use LO (Leading Only). 9390 Keys that can be used only during login have the use IO 9391 (initialize only) while those that can be used in both the 9392 login phase and full feature phase have the use ALL. 9394 Keys that can only be used during full feature phase use 9395 FFPO (full feature phase only). 9397 Keys marked as "declarative" may appear also in the Secu- 9398 rityNegotiation stage while all other keys described in 9399 this chapter are operational keys. 9401 Key scope is indicated as session-wide (SW) or connection- 9402 only (CO). 9404 1.1 HeaderDigest and DataDigest 9406 Use: IO 9407 Senders: Initiator and Target 9408 Scope: CO 9410 HeaderDigest = 9411 DataDigest = 9413 Digests enable the checking of end-to-end non-crypto- 9414 graphic data integrity beyond the integrity checks pro- 9415 vided by the link layers and the covering of the whole 9416 communication path including all elements that may change 9417 the network level PDUs such as routers, switches, and 9418 proxies. 9420 The following table lists cyclic integrity checksums that 9421 can be negotiated for the digests and that MUST be imple- 9423 Julian Satran Expires August 2002 1 9425 iSCSI 20-January-02 9427 mented by every iSCSI initiator and target. These digest 9428 options only have error detection significance. 9430 +---------------------------------------------+ 9431 | Name | Description | Generator | 9432 +---------------------------------------------+ 9433 | CRC32C | 32 bit CRC |0x11edc6f41| 9434 +---------------------------------------------+ 9435 | none | no digest | 9436 +---------------------------------------------+ 9438 The generator polynomial for this digest is given in hex- 9439 notation, for example 0x3b stands for 0011 1011. The poly- 9440 nomial x**5+X**4+x**3+x+1. 9442 When the Initiator and Target agree on a digest, this 9443 digest MUST be used for every PDU in Full Feature Phase. 9445 Padding bytes, when present, in a segment covered by a 9446 CRC, should be set to 0 and are included in the CRC. The 9447 CRC should be calculated as follows: 9449 - Data are assumed to be in the numbering order that 9450 appears in the draft and starts with byte 0 bit 0 to 9451 7 continues with byte 1 bit 0 etc. (Big Endian on 9452 bytes / Little Endian on bits). 9454 - The first 32 bits of the message are complemented. 9456 - The n PDU bits are considered coefficients of a 9457 polynomial M(x) of order n-1, with bit 0 of byte 0 9458 being x^(n-1). 9460 - The polynomial is multiplied by x^32 then divided 9461 by G(x). The generator polynomial produces a 9462 remainder R(x) of degree <= 31. 9464 - The coefficients of R(x) are considered a 32 bit 9465 sequence. 9467 - The bit sequence is complemented and the result is 9468 the CRC. 9470 - After the last bit of the original segment, the CRC 9471 bits are transmitted with x^31 first followed by 9472 x^30 etc. 9473 (when examples are provided, the value to be speci- 9475 Julian Satran Expires August 2002 2 9477 iSCSI 20-January-02 9479 fied in the examples follows the same rules of rep- 9480 resentation as the rest of this document). 9482 - A receiver of a "good" segment (data or header) 9483 including the CRC built using the generator 9484 0x11edc6f41 will get the value 0x1c2d19ed as its 9485 CRC (this is a polynomial value and not a word as 9486 outlined in this draft). 9488 Proprietary algorithms MAY also be negotiated for 9489 digests. Whenever a proprietary algorithm is negotiated, 9490 "none" or "CRC32C" should be listed as an option in order 9491 to guarantee interoperability. 9493 1.2 MaxConnections 9495 Use: LO 9496 Senders: Initiator and Target 9497 Scope: SW 9499 MaxConnections= 9501 Default is 1. 9503 Initiator and target negotiate the maximum number of con- 9504 nections requested/acceptable. The lower of the two num- 9505 bers is selected. 9507 1.3 SendTargets 9509 Use: FFPO 9510 Senders: Initiator 9511 Scope: SW 9513 For a complete description, see Appendix E. - SendTargets 9514 Operation -. 9516 1.4 TargetName 9518 Use: IO by initiator ALL by target, Declarative 9519 Senders: Initiator and Target 9520 Scope: SW 9522 TargetName= 9524 Julian Satran Expires August 2002 3 9526 iSCSI 20-January-02 9528 Examples: 9530 TargetName=iqn.1993-11.com.disk-vendor.diskar- 9531 rays.sn.45678 9532 TargetName=eui.020000023B040506 9534 The initiator of the TCP connection must provide this key 9535 to the remote endpoint in the first login request if the 9536 initiator is not establishing a discovery session. The 9537 iSCSI Target Name specifies the worldwide unique name of 9538 the target. 9539 The TargetName key may also be returned by the "SendTar- 9540 gets" text request (which is its only use when issued by a 9541 target). 9543 1.5 InitiatorName 9545 Use: IO, Declarative 9546 Senders: Initiator 9547 Scope: SW 9549 InitiatorName= 9551 Examples: 9553 InitiatorName=iqn.1992-04.com.os-ven- 9554 dor.plan9.cdrom.12345 9555 InitiatorName=iqn.2001- 9556 02.com.ssp.users.customer235.host90 9557 InitiatorName=iSCSI 9559 The initiator of the TCP connection must provide this key 9560 to the remote endpoint at the first Login of the login 9561 phase for every connection. The Initiator key enables the 9562 initiator to identify itself to the remote endpoint. 9564 1.6 TargetAlias 9566 Use: ALL, Declarative 9567 Senders: Target 9568 Scope: SW 9570 TargetAlias= 9572 Examples: 9574 Julian Satran Expires August 2002 4 9576 iSCSI 20-January-02 9578 TargetAlias=Bob's Disk 9579 TargetAlias=Database Server 1 Log Disk 9580 TargetAlias=Web Server 3 Disk 20 9582 If a target has been configured with a human-readable name 9583 or description, this name MUST be communicated to the ini- 9584 tiator during a Login Response PDU. This string is not 9585 used as an identifier, but can be displayed by the initi- 9586 ator's user interface in a list of targets to which it is 9587 connected. 9589 1.7 InitiatorAlias 9591 Use: ALL, Declarative 9592 Senders: Initiator 9593 Scope: SW 9595 InitiatorAlias= 9597 Examples: 9599 InitiatorAlias=Web Server 4 9600 InitiatorAlias=spyalley.nsa.gov 9601 InitiatorAlias=Exchange Server 9603 If an initiator has been configured with a human-readable 9604 name or description, it may be communicated to the target 9605 during a Login Request PDU. If not, the host name can be 9606 used instead. 9607 This string is not used as an identifier, but can be dis- 9608 played by the target's user interface in a list of initi- 9609 ators to which it is connected. 9611 This key SHOULD be sent by an initiator within the Login 9612 phase, if available. 9614 1.8 TargetAddress 9616 Use: ALL, Declarative 9617 Senders: Target 9618 Scope: SW 9620 TargetAddress=domainname[:port][,portal-group-tag] 9622 Julian Satran Expires August 2002 5 9624 iSCSI 20-January-02 9626 If the TCP port is not specified, it is assumed to be the 9627 IANA-assigned default port for iSCSI. 9629 If the TargetAddress is returned as the result of a redi- 9630 rect status in a login response, the comma and portal 9631 group tag are omitted. 9633 If the TargetAddress is returned within a SendTargets 9634 response, the portal group tag is required. 9636 Examples: 9638 TargetAddress=10.0.0.1:5003,1 9639 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 9640 TargetAddress=[1080::8:800:200C:417A]:5003,1 9641 TargetAddress=computingcenter.acme.com,23 9643 The TargetAddress key is further described in Appendix E. 9644 - SendTargets Operation -. 9646 1.9 InitialR2T 9648 Use: LO 9649 Senders: Initiator and Target 9650 Scope: SW 9652 InitialR2T= 9654 Examples: 9656 I->InitialR2T=no 9657 T->InitialR2T=no 9659 Default is yes. 9660 Result function is OR. 9662 The InitialR2T key is used to turn off the default use of 9663 R2T, thus allowing an initiator to start sending data to a 9664 target as if it has received an initial R2T with Buffer 9665 Offset=0 and Desired Data Transfer Length=min (First- 9666 BurstSize, Expected Data Transfer Length). The default 9667 action is that R2T is required, unless both the initiator 9668 and the target send this key-pair attribute specifying 9670 Julian Satran Expires August 2002 6 9672 iSCSI 20-January-02 9674 InitialR2T=no. Only the first outgoing data burst 9675 (immediate data and/or separate PDUs) can be sent unsolic- 9676 ited (i.e., not requiring an explicit R2T). 9678 1.10 BidiInitialR2T 9680 Use: LO 9681 Senders: Initiator and Target 9682 Scope: SW 9684 BidiInitialR2T= 9686 Examples: 9688 I->BidiInitialR2T=no 9689 T->BidiInitialR2T=no 9691 Default is yes. 9692 Result function is OR. 9694 The BidiInitialR2T key is used to turn off the default use 9695 of BiDiR2T, thus allowing an initiator to send data to a 9696 target without the target having sent an R2T to the initi- 9697 ator for the output data (write part) of a Bidirectional 9698 command (having both the R and the W bits set). The 9699 default action is that R2T is required, unless both the 9700 initiator and the target send this key-pair attribute 9701 specifying BidiInitialR2T=no. Once BidiInitialR2T has 9702 been set to 'no', it cannot be set back to 'yes'. Only 9703 the first outgoing data burst (immediate data and/or sep- 9704 arate PDUs) can be sent unsolicited by an R2T. 9706 1.11 ImmediateData 9708 Use: LO 9709 Senders: Initiator and Target 9710 Scope: SW 9712 ImmediateData= 9714 Default is yes. 9715 Result function is AND. 9717 Julian Satran Expires August 2002 7 9719 iSCSI 20-January-02 9721 The initiator and target negotiate support for immediate 9722 data. To turn immediate data off, the initiator or target 9723 must state its desire to do so. ImmediateData can be 9724 turned on if both the initiator and target have Immediate- 9725 Data=yes. 9727 If ImmediateData is set to yes and InitialR2T is set to 9728 yes (default), then only immediate data are accepted in 9729 the first burst. 9731 If ImmediateData is set to no and InitialR2T is set to 9732 yes, then the initiator MUST NOT send unsolicited data and 9733 the target MUST reject them with the corresponding 9734 response code. 9736 If ImmediateData is set to no and InitialR2T is set to no, 9737 then the initiator MUST NOT send unsolicited immediate 9738 data, but MAY send one unsolicited burst of Data-OUT PDUs. 9740 If ImmediateData is set to yes and InitialR2T is set to 9741 no, then the initiator MAY send unsolicited immediate data 9742 and/or one unsolicited burst of Data-OUT PDUs. 9744 The following table is a summary of unsolicited data 9745 options: 9747 Julian Satran Expires August 2002 8 9749 iSCSI 20-January-02 9751 +----------+-------------+------------------------------- 9752 --------+ 9753 |InitialR2T|ImmediateData| Result (up to FirstBurst- 9754 Size) | 9755 +----------+-------------+------------------------------- 9756 --------+ 9757 | no | no | Unsolicited data in data PDUs 9758 only. | 9759 +----------+-------------+------------------------------- 9760 --------+ 9761 | no | yes | Immediate & separate unsolicited 9762 data.| 9763 +----------+-------------+------------------------------- 9764 --------+ 9765 | yes | no | Unsolicited data disal- 9766 lowed. | 9767 +----------+-------------+------------------------------- 9768 --------+ 9769 | yes | yes | Immediate unsolicited data only. 9770 | 9771 +----------+-------------+------------------------------- 9772 --------+ 9774 1.12 MaxRecvPDULength 9776 Use: ALL 9777 Senders: Initiator and Target 9778 Scope: CO 9780 MaxRecvPDULength= 9782 Default is 8191 bytes. 9784 This is a connection specific parameter. 9785 The initiator or target declares the maximum data segment 9786 length in bytes they can receive in an iSCSI PDU. 9788 For a target the value limiting the size of the receive 9789 PDUs is the lower of the declared MaxRecvPDULength and the 9790 negotiated MaxBurstSize for solicited data or FirstBurst- 9791 Size for unsolicited data. 9793 Julian Satran Expires August 2002 9 9795 iSCSI 20-January-02 9797 1.13 MaxBurstSize 9799 Use: LO 9800 Senders: Initiator and Target 9801 Scope: SW 9803 MaxBurstSize= 9805 Default is 262144 (256 Kbytes). 9807 The initiator and target negotiate maximum SCSI data pay- 9808 load in bytes in an Data-In or a solicited Data-Out iSCSI 9809 sequence. A sequence of Data-In or Data-Out PDUs ending 9810 with a Data-In or Data-Out PDU with the F bit set to one. 9812 The minimum of the two numbers is selected. 9814 1.14 FirstBurstSize 9816 Use: LO 9817 Senders: Initiator and Target 9818 Scope: SW 9820 FirstBurstSize= 9822 Default is 65536 (64 Kbytes). 9824 The initiator and target negotiate the maximum amount in 9825 bytes of unsolicited data an iSCSI initiator may send to 9826 the target, during the execution of a single SCSI command. 9827 This covers the immediate data (if any) and the sequence 9828 of unsolicited Data-Out PDUs (if any) that follow the com- 9829 mand. 9831 The minimum of the two numbers is selected. 9833 FirstBurstSize MUST NOT exceed MaximumBurstSize. 9835 1.15 LogoutLoginMaxTime 9837 Use: LO 9838 Senders: Initiator and Target 9839 Scope: SW 9841 Julian Satran Expires August 2002 10 9843 iSCSI 20-January-02 9845 LogoutLoginMaxTime= 9847 Default is 3. 9849 The initiator and target negotiate the maximum time, in 9850 seconds after an initial wait (Time2Wait), before which 9851 the connection reinstatement is still possible after a 9852 connection termination or a connection reset. 9854 This value is also the session state timeout if the con- 9855 nection in question is the last LOGGED_IN connection in 9856 the session. 9858 The lesser of the two values is selected and will be used 9859 anywhere a explicit value is not otherwise provided 9860 (Time2Retain). 9862 A value of 0 indicates that connection state is immedi- 9863 ately discarded by the target. 9865 1.16 LogoutLoginMinTime 9867 Use: LO 9868 Senders: Initiator and Target 9869 Scope: SW 9871 LogoutLoginMinTime= 9873 Default is 3. 9875 The initiator and target negotiate the minimum time, in 9876 seconds, to wait before attempting connection reinstate- 9877 ment after a connection termination or a connection reset. 9879 The maximum of the two values is selected and will be used 9880 anywhere an explicit value is not otherwise pro- 9881 vided(Time2Wait). 9883 A value of 0 indicates that connection reinstatement can 9884 be attempted immediately. 9886 1.17 MaxOutstandingR2T 9888 Use: LO 9890 Julian Satran Expires August 2002 11 9892 iSCSI 20-January-02 9894 Senders: Initiator and Target 9895 Scope: SW 9897 MaxOutstandingR2T= 9899 Default is 1. 9901 Initiator and target negotiate the maximum number of out- 9902 standing R2Ts per task, excluding any implied initial R2T 9903 that might be part of that task. An R2T is considered 9904 outstanding until the last data PDU (with the F bit set to 9905 1) is transferred, or a sequence reception timeout (sec- 9906 tion 7.11.1) is encountered for that data sequence. 9908 1.18 DataPDUInOrder 9910 Use: LO 9911 Senders: Initiator and Target 9912 Scope: SW 9914 DataPDUInOrder= 9916 Default is yes. 9917 Result function is OR. 9919 No is used by iSCSI to indicate that the data PDUs within 9920 sequences can be in any order. Yes is used to indicate 9921 that data PDUs within sequences have to be at continuously 9922 increasing addresses and overlays are forbidden. 9924 1.19 DataSequenceInOrder 9926 Use: LO 9927 Senders: Initiator and Target 9928 Scope: SW 9930 DataSequenceInOrder= 9932 Default is yes. 9933 Result function is OR. 9935 A Data Sequence is a sequence of Data-In or Data-Out PDUs 9936 ending with a Data-In or Data-Out PDU with the F bit set 9938 Julian Satran Expires August 2002 12 9940 iSCSI 20-January-02 9942 to one. A Data-out sequence is sent either unsolicited or 9943 in response to an R2T. Sequences cover an offset-range. 9945 If DataSequenceInOrder is set to no, Data PDU sequences 9946 may be transferred in any order. 9948 If DataSequenceInOrder is set to yes, Data Sequences MUST 9949 be transferred using continuously non-decreasing sequence 9950 offsets (R2T buffer offset for writes, or the smallest 9951 SCSI Data-In buffer offset within a read data sequence). 9953 If ErrorRecoveryLevel is not 0 and if DataSequenceInOrder 9954 is set to yes, a target may retry at most the last R2T, 9955 and an initiator may at most request retransmission for 9956 the last read data sequence. MaxOustandingR2T MUST be set 9957 to 1 in this case. 9959 1.20 ErrorRecoveryLevel 9961 Use: LO 9962 Senders: Initiator and Target 9963 Scope: SW 9965 ErrorRecoveryLevel=<0 to 2> 9967 Default is 0. 9969 The initiator and target negotiate the recovery level sup- 9970 ported. 9971 The minimum of the two values is selected. 9973 Recovery levels represent a combination of recovery capa- 9974 bilities. 9975 Each recovery level includes all the capabilities of the 9976 lower recovery levels and adds some new ones to them. 9978 In the description of recovery mechanisms, certain recov- 9979 ery classes are specified. Section 7.12 Error Recovery 9980 Hierarchy describes the mapping between the classes and 9981 the levels. 9983 1.21 SessionType 9985 Use: LO, Declarative 9987 Julian Satran Expires August 2002 13 9989 iSCSI 20-January-02 9991 Senders: Initiator 9992 Scope: SW 9994 SessionType= 9996 Default is Normal. 9998 The Initiator indicates the type of session it wants to 9999 create. The target can either accept it or reject it. 10001 A discovery session indicates to the Target that the only 10002 purpose of this Session is discovery. The only requests a 10003 target accepts in this type of session are a text request 10004 with a SendTargets key and a logout request with reason 10005 "close the session". 10007 The discovery session implies MaxConnections = 1 and over- 10008 rides both the default and an explicit setting. 10010 1.22 The Vendor Specific Key Format 10012 Use: ALL 10013 Senders: Initiator and Target 10014 Scope: specific key dependent 10016 X-reversed.vendor.dns_name.do_something= 10018 Keys with this format are used for vendor-specific pur- 10019 poses. These keys always start with X-. 10021 To identify the vendor, we suggest you use the reversed 10022 DNS-name as a prefix to the key-proper. 10024 Julian Satran Expires August 2002 14 10026 iSCSI 20-January-02 10028 1. IANA Considerations 10030 The temporary (user) well-known port number for iSCSI con- 10031 nections assigned by IANA is 3260. 10033 Julian Satran Expires August 2002 1 10035 iSCSI 20-January-02 10037 References and Bibliography 10039 [AC] A Detailed Proposal for Access Control, Jim 10040 Hafner, T10/99-245 10041 [AES] J. Daemen, V. Rijman, "AES Proposal: Rijndael" 10042 NIST 10043 AES proposal, http://csrc.nist.gov/encryption/aes/ 10044 rijndael/Rijndael.pdf, September 1999. 10045 [XCBC] J. Black, P. Rogaway "Comments to NIST Concern- 10046 ing AES Modes of Operations: A Suggestion for Handling 10047 Arbitrary-Length Messages with the CBC MAC", http:// 10048 csrc.nist.gov/encryption/modes/proposedmodes/xcbc-mac/ 10049 xcbc-mac-spec.pdf, NIST proposed modes of operations, 10050 August 2001. 10051 [AESCTR] J. Etienne, "The counter-mode and its use 10052 with ESP", Internet draft (work in progress), 10053 draft-etienne-ipsec-esp-ctr-mode-00.txt, May 2001. 10054 [BOOT] P. Sarkar & team draft-ietf-ips-iscsi-boot- 10055 01.txt 10056 [CAM] ANSI X3.232-199X, Common Access Method-3. 10057 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Her- 10058 rman "Optimization of Cyclic Redundancy-Check Codes 10059 with 24 and 32 Parity Bits", IEEE Transact. on Com- 10060 munications, Vol. 41, No. 6, June 1993. 10061 [COBS] S. Cheshire and M. Baker, Consistent Overhead 10062 Byte Stuffing, IEEE Transactions on Networking, 10063 April 1999. 10064 [CRC] ISO 3309, High-Level Data Link Control (CRC 10065 32). 10066 [NDT] M. Bakke & team, draft-ietf-ips-iscsi-name- 10067 disc-03.txt 10068 [RFC790] J. Postel, ASSIGNED NUMBERS, September 1981. 10069 [RFC791] INTERNET PROTOCOL, DARPA INTERNET PROGRAM 10070 PROTOCOL SPECIFICATION, September 1981. 10071 [RFC793] TRANSMISSION CONTROL PROTOCOL, DARPA INTER- 10072 NET PROGRAM PROTOCOL SPECIFICATION, September 1981. 10073 [RFC1035] P. Mockapetris, DOMAIN NAMES - IMPLEMENTA- 10074 TION AND SPECIFICATION, November 1987. 10075 [RFC1122] Requirements for Internet Hosts-Communica- 10076 tion Layer RFC1122, R. Braden (editor). 10077 [RFC1510] J. Kohl, C. Neuman, "The Kerberos Network 10078 Authentication Service (V5)", September 1993. 10079 [RFC1766] H. Alvestrand, "Tags for the Identification 10080 of Languages", March 1995. 10081 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API 10082 Mechanism", June 1996. 10083 [RFC1982] Elz, R., Bush, R., "Serial Number Arith- 10084 metic", RFC 1982, August 1996. 10086 Julian Satran Expires August 2002 1 10088 iSCSI 20-January-02 10090 [RFC1994] "W. Simpson, PPP Challenge Handshake 10091 Authentication Protocol (CHAP)", RFC 1994, August 10092 1996. 10093 [RFC2025] C. Adams, "The Simple Public-Key GSS-API 10094 Mechanism (SPKM)", October 1996. 10095 [RFC2026] Bradner, S., "The Internet Standards Pro- 10096 cess -- Revision 3", RFC 2026, October 1996. 10097 [RFC2044] Yergeau, F., "UTF-8, a Transformation For- 10098 mat of Unicode and ISO 10646", October 1996. 10099 [RFC2045] N. Borenstein, N. Freed, "MIME (Multipur- 10100 pose Internet Mail Extensions) Part One: Mechanisms 10101 for Specifying and Describing the Format of Inter- 10102 net Message Bodies", November 1996. 10103 [RFC2119] Bradner, S. "Key Words for use in RFCs to 10104 Indicate Requirement Levels", BCP 14, RFC 2119, 10105 March 1997. 10106 [RFC2234] D. Crocker, P. Overell Augmented BNF for 10107 Syntax Specifications: ABNF. 10108 [RFC2246] T. Dierks, C. Allen, " The TLS Protocol 10109 Version 1.0. 10110 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 10111 Addressing Architecture", RFC 2373, July 1998. 10112 [RFC2434] T. Narten, and H. Avestrand, "Guidelines 10113 for Writing an IANA Considerations Section in 10114 RFCs.", RFC2434, October 1998. 10115 [RFC2401] S. Kent, R. Atkinson, "Security Architec- 10116 ture for the Internet Protocol", RFC 2401, November 10117 1998. 10118 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1- 10119 96 within ESP and AH", RFC 2404, November 1998. 10120 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Secu- 10121 rity Payload (ESP)", RFC 2406, November 1998. 10122 [RFC2407] D. Piper, "The Internet IP Security Domain of 10123 Interpretation of ISAKMP", RFC 2407, November 1998. 10124 [RFC2409] D. Harkins, D. Carrel, "The Internet Key 10125 Exchange (IKE)", RFC 2409, November 1998. 10126 [RFC2451] R. Pereira, R. Adams " The ESP CBC-Mode 10127 Cipher Algorithms". 10128 [RFC2732] R. Hinden, B. Carpenter, L. Masinter, "For- 10129 mat for Literal IPv6 Addresses in URL's", RFC 2732, 10130 December 1999. [RFC2945], Wu, T., "The SRP Authen- 10131 tication and Key Exchange System", September 2000. 10132 [SAM] ANSI X3.270-1998, SCSI-3 Architecture Model 10133 (SAM). 10134 [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM- 10135 2). 10136 [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC). 10138 Julian Satran Expires August 2002 2 10140 iSCSI 20-January-02 10142 [Schneier] B. Schneier, "Applied Cryptography: Pro- 10143 tocols, Algorithms, and Source Code in C", 2nd edi- 10144 tion, John Wiley & Sons, New York, NY, 1996. 10145 [SEC-IPS] B. Aboba & team "Securing iSCSI, iFCP and 10146 FCIP" -draft-ietf-ips-security-03.txt. 10147 [SEQ-EXT] Steve Kent, IPsec sequence number extension 10148 proposal, IETF 50. 10149 [SPC] NCITS.351:200, SCSI-3 Primary Commands (SPC). 10150 [SPC3]T10/1416-D, SCSI-3 Primary Commands (SPC). 10151 [XCBC] J. Black, P. Rogaway "Comments to NIST Concern- 10152 ing AES Modes of Operations: A Suggestion for Handling 10153 Arbitrary-Length Messages with the CBC MAC", http:// 10154 csrc.nist.gov/encryption/modes/proposedmodes/xcbc-mac/ 10155 xcbc-mac-spec.pdf, NIST proposed modes of operations, 10156 August 2001. 10158 Authors' Addresses 10160 Julian Satran 10161 IBM, Haifa Research Lab 10162 MATAM - Advanced Technology Center 10163 Haifa 31905, Israel 10164 Phone +972.4.829.6264 10165 E-mail: Julian_Satran@vnet.ibm.com 10167 Kalman Meth 10168 IBM, Haifa Research Lab 10169 MATAM - Advanced Technology Center 10170 Haifa 31905, Israel 10171 Phone +972.4.829.6341 10172 E-mail: meth@il.ibm.com 10174 Ofer Biran 10175 IBM, Haifa Research Lab 10176 MATAM - Advanced Technology Center 10177 Haifa 31905, Israel 10178 Phone +972.4.829.6253 10179 E-mail: biran@il.ibm.com 10181 Daniel F. Smith 10182 IBM Almaden Research Center 10183 650 Harry Road 10184 San Jose, CA 95120-6099, USA 10186 Julian Satran Expires August 2002 3 10188 iSCSI 20-January-02 10190 Phone: +1.408.927.2072 10191 E-mail: dfsmith@almaden.ibm.com 10193 Jim Hafner 10194 IBM Almaden Research Center 10195 650 Harry Road 10196 San Jose, CA 95120 10197 Phone: +1.408.927.1892 10198 E-mail: hafner@almaden.ibm.com 10200 Costa Sapuntzakis 10201 Cisco Systems, Inc. 10202 170 W. Tasman Drive 10203 San Jose, CA 95134, USA 10204 Phone: +1.408.525.5497 10205 E-mail: csapuntz@cisco.com 10207 Mark Bakke 10208 Cisco Systems, Inc. 10209 6450 Wedgwood Road 10210 Maple Grove, MN 10211 USA 55311 10212 Phone: +1.763.398.1000 10213 E-Mail: mbakke@cisco.com 10215 Randy Haagens 10216 Hewlett-Packard Company 10217 8000 Foothills Blvd. 10218 Roseville, CA 95747-5668, USA 10219 Phone: +1.916.785.4578 10220 E-mail: Randy_Haagens@hp.com 10222 Matt Wakeley (current address) 10223 Sierra Logic, Inc. 10224 Phone: +1.916.772.1234 ext 116 10225 E-mail: matt_wakeley@sierralogic.com 10227 Efri Zeidner 10228 SANgate Systems, Inc. 10229 41 Hameyasdim Street 10230 P.O.B. 1486 10231 Even-Yehuda, Israel 40500 10232 Phone: +972.9.891.9555 10234 Julian Satran Expires August 2002 4 10236 iSCSI 20-January-02 10238 E-mail: efri@sangate.com 10240 Paul von Stamwitz (current address) 10241 TrueSAN Networks, Inc. 10242 Phone: +1.408.869.4219 10243 E-mail: pvonstamwitz@truesan.com 10245 Luciano Dalle Ore 10246 Quantum Corp. 10247 Phone: +1.408.232.6524 10248 E-mail: ldalleore@snapserver.com 10250 Mallikarjun Chadalapaka 10251 Hewlett-Packard Company 10252 8000 Foothills Blvd. 10253 Roseville, CA 95747-5668, USA 10254 Phone: +1.916.785.5621 10255 E-mail: cbm@rose.hp.com 10257 Yaron Klein 10258 SANRAD 10259 24 Raul Valenberg St. 10260 Tel-Aviv, 69719 Israel 10261 Phone: +972.3.765.9998 10262 E-mail: klein@sanrad.com 10264 Comments may be sent to Julian Satran 10266 Julian Satran Expires August 2002 5 10268 iSCSI 20-January-02 10270 Appendix A. Sync and Steering with Fixed Interval Markers 10272 This appendix presents a simple scheme for synchroniza- 10273 tion (PDU boundary retrieval). It uses markers that 10274 include synchronization information placed at fixed 10275 intervals in the TCP stream. 10277 A Marker consists of: 10279 Byte / 0 | 1 | 2 | 3 10280 | 10281 / | | | 10282 | 10283 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 10284 3 2 1 0| 10285 +---------------+---------------+---------------+------ 10286 ---------+ 10287 0| Next-iSCSI-PDU-start pointer - copy #1 10288 | 10289 +---------------+---------------+---------------+------ 10290 ---------+ 10291 4| Next-iSCSI-PDU-start pointer - copy #2 10292 | 10293 +---------------+---------------+---------------+------ 10294 ---------+ 10296 The Marker schemes uses payload byte stream counting that 10297 includes every byte placed by iSCSI in the TCP stream 10298 except for the markers themselves. It also excludes any 10299 bytes that TCP counts but are not originated by iSCSI. 10301 The Marker indicates the offset to the next iSCSI PDU 10302 header. The Marker is eight bytes in length and contains 10303 two 32-bit offset fields that indicate how many bytes to 10304 skip in the TCP stream in order to find the next iSCSI PDU 10305 header. The marker uses two copies of the pointer so that 10306 a marker that spans a TCP packet boundary should leave at 10307 least one valid copy in one of the packets. 10309 The inserted value is independent of the marker interval. 10311 The use of markers is negotiable. The initiator and target 10312 MAY indicate their readiness to receive and/or send mark- 10314 Julian Satran Expires August 2002 1 10316 iSCSI 20-January-02 10318 ers during login separately for each connection. The 10319 default is NO. In certain environments, a sender not will- 10320 ing to supply markers to a receiver willing to accept 10321 markers MAY suffer from a considerable performance degra- 10322 dation. 10324 A.1 Markers At Fixed Intervals 10326 A marker is inserted at fixed intervals in the TCP byte 10327 stream. During login, each end of the iSCSI session spec- 10328 ifies the interval at which it is willing to receive the 10329 marker, or it disables the marker altogether. If a 10330 receiver indicates that it desires a marker, the sender 10331 SHOULD agree (during negotiation) and provide the marker 10332 at the desired interval. 10334 The marker interval and the initial marker-less interval 10335 are counted in terms of the bytes placed in the TCP stream 10336 data by iSCSI. 10338 When reduced to iSCSI terms, markers MUST indicate the 10339 offset to a 4-byte word boundary in the stream. The last 10340 two bits of each marker word are reserved and are consid- 10341 ered 0 for offset computation. 10343 Padding iSCSI PDU payloads to 4-byte word boundaries sim- 10344 plifies marker manipulation. 10346 A.2 Initial Marker-less Interval 10348 To enable the connection setup including the login phase 10349 negotiation, marking (if any) is started only at the first 10350 marker interval after the end of the login phase. However, 10351 in order to enable the marker inclusion and exclusion 10352 mechanism to work without knowledge of the length of the 10353 login phase, the first marker will be placed in the TCP 10354 stream as if the Marker-less interval had included mark- 10355 ers. 10357 As an example if the marker interval is 512 and the login 10358 ended at byte 1003 (first iSCSI placed byte is 0) the 10359 first marker will be inserted after byte 1031 in the 10360 stream. 10362 Julian Satran Expires August 2002 2 10364 iSCSI 20-January-02 10366 A.3 Negotiation 10368 The following operational key=value pairs are used to 10369 negotiate the fixed interval markers. 10371 A.3.1 FMarker 10373 Use: IO 10374 Senders: Initiator and Target 10376 FMarker= 10378 Default is no. 10380 This is a connection specific parameter. 10382 Examples: 10384 I->FMarker=send-receive 10385 T->FMarker=send-receive 10387 Results in the Marker being used in both directions while 10389 I->FMarker=send-receive 10390 T->FMarker=receive 10392 Results in Marker being used from the initiator to the 10393 target, but not from the target to initiator. 10395 A.3.2 RFMarkInt, SFMarkInt - offering 10397 Use: IO 10398 Senders: Initiator and Target 10400 RFMarkInt=[,] 10402 SFMarkInt=[,] 10405 This is a connection specific parameter. 10407 The receiver or sender indicates the minimum to maximum 10408 interval (in 4-byte words) it wants the markers. In case 10409 the receiver or sender only wants a specific value, only a 10410 single value has to be specified. The responding sender or 10412 Julian Satran Expires August 2002 3 10414 iSCSI 20-January-02 10416 receiver selects a value within the minimum and maximum 10417 offered or the only value offered or indicates through the 10418 FMarker key=value its inability to set and/or receive 10419 markers. The interval is measured from the end of a marker 10420 to the beginning of the next marker. For example, a value 10421 of 1024 means 1024 words (4096 bytes of iSCSI payload 10422 between markers). Whenever FMarker and RFMarkInt are both 10423 sent, they MUST appear on the same Login Request/Response. 10425 The default is 2048. 10427 A.3.3 SFMarkInt, RFMarkInt - responding 10429 Use: IO 10430 Senders: Initiator and Target 10432 SFMarkInt= 10433 RFMarkInt= 10435 This is a connection specific parameter. 10437 Indicates at what interval (in 4-byte words) the sender 10438 agrees to send or the receiver wants to receive the mark- 10439 ers. The number MUST be within the range required offering 10440 party. The interval is measured from the end of a marker 10441 to the beginning of the next marker. For example, a value 10442 of 1024 means 1024 words (4096 bytes of iSCSI payload 10443 between markers). 10445 Default is 2048. 10447 Julian Satran Expires August 2002 4 10449 iSCSI 20-January-02 10451 Appendix A. Sync and Steering with Constant Overhead Word 10452 Stuffing 10453 (COWS) 10455 This appendix presents a simple scheme for synchroniza- 10456 tion (PDU boundary retrieval). The basic mechanism 10457 described is inspired by [COBS]. However, unlike the mech- 10458 anism outlined in [COBS], here the PDU is extended by 2 or 10459 3 4 byte words regardless of the PDU length. With COWS: 10461 - The iSCSI PDU is "prefixed" by an 8 byte COWS 10462 header (CH), including a 4 byte word aligned COWS 10463 framing pattern (CFP) and a 4 byte COWS link chain 10464 element (CLCE). 10465 - Any appearance of the pattern within the PDU is 10466 replaced either by a forward or (for long payloads) 10467 a backward link to the next appearance of the pat- 10468 tern, or to the end (for forward links) or an end of 10469 chain in indicator formatted as a CLCE. 10470 - The iSCSI PDU may be followed by a trailer that 10471 consists of a single CLCE. 10473 All of these elements form a COWS Extended PDU (CEPDU). 10475 COWS uses a framing pattern defined by the sender. A spe- 10476 cial version of COWS that does not require pattern 10477 replacement, but requires the sender to guarantee that a 10478 CH will always appear at the beginning of a TCP segment, 10479 may be used by specialized software stacks and/or hardware 10480 adapters and its use may be negotiated (PDU Alignment 10481 Option - PAO). 10483 The CH format is: 10485 Byte/ 0 | 1 | 2 | 3 10486 | 10487 / | | | 10488 | 10489 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 10490 4 3 2 1 0| 10491 +---------------+---------------+---------------+---- 10492 -----------+ 10493 CFP| CFP (COWS Framing Pat- 10494 tern) | 10496 Julian Satran Expires August 2002 1 10498 iSCSI 20-January-02 10500 +---------------+---------------+---------------+---- 10501 -----------+ 10502 CLCE|N| Res. | Link 10503 |LT| 10504 +---------------+---------------+---------------+---- 10505 -----------+ 10507 CFP is a pattern selected by the sender and communicated 10508 to the receiver during the login phase. A CFP has to be 10509 specified by the sender for each direction. 10511 Except for the PAO, every occurrence of CFP within the 10512 payload is replaced by a CLCE. 10514 The CLCE is composed of: 10516 - N - a bit is selected to be the complement of the 10517 corresponding bit in the Framing pattern. 10518 - Link - number of non-link 4 byte words to the next/ 10519 previous link. 10520 - LT - link type coded as follows: 10521 - 00 - Forward Last Link - no more links follow. 10522 The Link field is the number of words to the end 10523 of PDU. 10524 - 01 - Forward More Links - the link field is 10525 the number of words to the next link. 10526 - 10 - Backward Last Link - the link field is 0. 10527 - 11 - Backward More Links - the link field is 10528 the number of words from the preceding field. 10530 The LT field in the CH MUST be 00 or 01, and all CLCE 10531 within the iSCSI header (if any) MUST have an LT field of 10532 00 or 01 (the iSCSI header is encoded ONLY with forward 10533 links). 10535 The sender can use the backward linking mechanism to avoid 10536 storing very long data payloads before sending them and 10537 MUST be processed by the receiver. 10539 If using backward linking, the sender MUST include a tail- 10540 ing CLCE in the ECPDU. The tailing CLCE is the first CLCE 10541 in the "back-tracking chain" and MUST be linked to by the 10542 last CLCE in the "forward-tracking chain". 10544 Julian Satran Expires August 2002 2 10546 iSCSI 20-January-02 10548 COWS ECPDU can follow one of the following outlines: 10550 a) Only Forward Pointing 10552 CH (mandatory) 10553 . 10554 . 10555 Forward Pointing CLCE (optional) 10556 . 10557 . 10558 . 10559 Forward Pointing CLCE (optional) 10560 . 10561 . 10562 Last Payload Word 10564 b) Forward-and-Backward Pointing 10566 CH (mandatory) 10567 . 10568 . 10569 Forward Pointing CLCE (optional - may point to 10570 trailer if last forward) 10571 . 10572 . 10573 . 10574 Backward Pointing CLCE (optional - may have link 10575 of 0) 10576 . 10577 . 10578 Last Payload Word 10579 Backward Pointing CLCE (mandatory - may have a 10580 link of 0) 10582 c) PDU alignment option 10584 CH (mandatory) 10585 . 10586 . 10587 . 10588 Last Payload Word (also end of TCP segment) 10590 Julian Satran Expires August 2002 3 10592 iSCSI 20-January-02 10594 For cases a) and b), the payload on the wire is guaranteed 10595 not to contain a CFP or a word aligned pattern anywhere 10596 but in CH. For case c), the CFP is supposed the appear 10597 only aligned to TCP segment boundaries and be implement 10598 with specialized software stacks and hardware. For this 10599 case the Link value, LT and the Reserved bits may is used 10600 as a further validity checks (TBD???). 10602 if all cases of the iSCSI PDUs are not constrained to a 10603 one or a limited number of TCP segments. 10605 A.1 Negotiation 10607 A.2 Sent PDU processing 10609 pseudo-language description... 10611 A.3 Received PDU processing 10613 pseudo-language description 10615 A.4 Search for framing processing 10617 Julian Satran Expires August 2002 4 10619 iSCSI 20-January-02 10621 Appendix A. Examples 10623 A.1 Read Operation Example 10625 +------------------+-----------------------+------------- 10626 ---------+ 10627 |Initiator Function| PDU Type | Target Func- 10628 tion | 10629 +------------------+-----------------------+------------- 10630 ---------+ 10631 | Command request |SCSI Command (READ)>>> | 10632 | 10633 | (read) | | 10634 | 10635 +------------------+-----------------------+------------- 10636 ---------+ 10637 | | | Prepare Data 10638 Transfer| 10639 +------------------+-----------------------+------------- 10640 ---------+ 10641 | Receive Data | <<< SCSI Data-in | Send Data 10642 | 10643 +------------------+-----------------------+------------- 10644 ---------+ 10645 | Receive Data | <<< SCSI Data-in | Send Data 10646 | 10647 +------------------+-----------------------+------------- 10648 ---------+ 10649 | Receive Data | <<< SCSI Data-in | Send Data 10650 | 10651 +------------------+-----------------------+------------- 10652 ---------+ 10653 | | <<< SCSI Response |Send Status and 10654 Sense | 10655 +------------------+-----------------------+------------- 10656 ---------+ 10657 | Command Complete | | 10658 | 10659 +------------------+-----------------------+------------- 10660 ---------+ 10662 Julian Satran Expires August 2002 1 10664 iSCSI 20-January-02 10666 A.2 Write Operation Example 10668 +------------------+-----------------------+------------- 10669 --------+ 10670 |Initiator Function| PDU Type | Target Func- 10671 tion | 10672 +------------------+-----------------------+------------- 10673 --------+ 10674 | Command request |SCSI Command (WRITE)>>>| Receive com- 10675 mand | 10676 | (write) | | and queue it 10677 | 10678 +------------------+-----------------------+------------- 10679 --------+ 10680 | | | Process old 10681 commands| 10682 +------------------+-----------------------+------------- 10683 --------+ 10684 | | | Ready to process 10685 | 10686 | | <<< R2T | WRITE command 10687 | 10688 +------------------+-----------------------+------------- 10689 --------+ 10690 | Send Data | SCSI Data-out >>> | Receive Data 10691 | 10692 +------------------+-----------------------+------------- 10693 --------+ 10694 | | <<< R2T | Ready for data 10695 | 10696 +------------------+-----------------------+------------- 10697 --------+ 10698 | | <<< R2T | Ready for data 10699 | 10700 +------------------+-----------------------+------------- 10701 --------+ 10702 | Send Data | SCSI Data-out >>> | Receive Data 10703 | 10704 +------------------+-----------------------+------------- 10705 --------+ 10706 | Send Data | SCSI Data-out >>> | Receive Data 10707 | 10709 Julian Satran Expires August 2002 2 10711 iSCSI 20-January-02 10713 +------------------+-----------------------+------------- 10714 --------+ 10715 | | <<< SCSI Response |Send Status and 10716 Sense| 10717 +------------------+-----------------------+------------- 10718 --------+ 10719 | Command Complete | | 10720 | 10721 +------------------+-----------------------+------------- 10722 --------+ 10724 A.3 R2TSN/DataSN use Examples 10726 Output (write) data DataSN/R2TSN Example 10728 +------------------+-----------------------+------------- 10729 ---------+ 10730 |Initiator Function| PDU Type & Content | Target Func- 10731 tion | 10732 +------------------+-----------------------+------------- 10733 ---------+ 10734 | Command request |SCSI Command (WRITE)>>>| Receive com- 10735 mand | 10736 | (write) | | and queue it 10737 | 10738 +------------------+-----------------------+------------- 10739 ---------+ 10740 | | | Process old 10741 commands | 10742 +------------------+-----------------------+------------- 10743 ---------+ 10744 | | <<< R2T | Ready for data 10745 | 10746 | | R2TSN = 0 | 10747 | 10748 +------------------+-----------------------+------------- 10749 ---------+ 10750 | | <<< R2T | Ready for more 10751 data | 10752 | | R2TSN = 1 | 10753 | 10754 +------------------+-----------------------+------------- 10755 ---------+ 10757 Julian Satran Expires August 2002 3 10759 iSCSI 20-January-02 10761 | Send Data | SCSI Data-out >>> | Receive Data 10762 | 10763 | for R2TSN 0 | DataSN = 0, F=0 | 10764 | 10765 +------------------+-----------------------+------------- 10766 ---------+ 10767 | Send Data | SCSI Data-out >>> | Receive Data 10768 | 10769 | for R2TSN 0 | DataSN = 1, F=1 | 10770 | 10771 +------------------+-----------------------+------------- 10772 ---------+ 10773 | Send Data | SCSI Data >>> | Receive Data 10774 | 10775 | for R2TSN 1 | DataSN = 0, F=1 | 10776 | 10777 +------------------+-----------------------+------------- 10778 ---------+ 10779 | | <<< SCSI Response |Send Status and 10780 Sense | 10781 | | ExpDataSN = 0 | 10782 | 10783 +------------------+-----------------------+------------- 10784 ---------+ 10785 | Command Complete | | 10786 | 10787 +------------------+-----------------------+------------- 10788 ---------+ 10790 Input (read) data DataSN Example 10792 +------------------+-----------------------+------------- 10793 ---------+ 10794 |Initiator Function| PDU Type | Target Func- 10795 tion | 10796 +------------------+-----------------------+------------- 10797 ---------+ 10798 | Command request |SCSI Command (READ)>>> | 10799 | 10800 | (read) | | 10801 | 10803 Julian Satran Expires August 2002 4 10805 iSCSI 20-January-02 10807 +------------------+-----------------------+------------- 10808 ---------+ 10809 | | | Prepare Data 10810 Transfer| 10811 +------------------+-----------------------+------------- 10812 ---------+ 10813 | Receive Data | <<< SCSI Data-in | Send Data 10814 | 10815 | | DataSN = 0, F=0 | 10816 | 10817 +------------------+-----------------------+------------- 10818 ---------+ 10819 | Receive Data | <<< SCSI Data-in | Send Data 10820 | 10821 | | DataSN = 1, F=0 | 10822 | 10823 +------------------+-----------------------+------------- 10824 ---------+ 10825 | Receive Data | <<< SCSI Data-in | Send Data 10826 | 10827 | | DataSN = 2, F=1 | 10828 | 10829 +------------------+-----------------------+------------- 10830 ---------+ 10831 | | <<< SCSI Response |Send Status and 10832 Sense | 10833 | | ExpDataSN = 3 | 10834 | 10835 +------------------+-----------------------+------------- 10836 ---------+ 10837 | Command Complete | | 10838 | 10839 +------------------+-----------------------+------------- 10840 ---------+ 10842 Bidirectional DataSN Example 10844 +------------------+-----------------------+------------- 10845 ---------+ 10846 |Initiator Function| PDU Type | Target Func- 10847 tion | 10849 Julian Satran Expires August 2002 5 10851 iSCSI 20-January-02 10853 +------------------+-----------------------+------------- 10854 ---------+ 10855 | Command request |SCSI Command >>> | 10856 | 10857 | (Read-Write) | Read-Write | 10858 | 10859 +------------------+-----------------------+------------- 10860 ---------+ 10861 | | | Process old 10862 commands | 10863 +------------------+-----------------------+------------- 10864 ---------+ 10865 | | <<< R2T | Ready to process 10866 | 10867 | | R2TSN = 0 | WRITE command 10868 | 10869 +------------------+-----------------------+------------- 10870 ---------+ 10871 | * Receive Data | <<< SCSI Data-in | Send Data 10872 | 10873 | | DataSN = 0, F=0 | 10874 | 10875 +------------------+-----------------------+------------- 10876 ---------+ 10877 | * Receive Data | <<< SCSI Data-in | Send Data 10878 | 10879 | | DataSN = 1, F=1 | 10880 | 10881 +------------------+-----------------------+------------- 10882 ---------+ 10883 | * Send Data | SCSI Data-out >>> | Receive Data 10884 | 10885 | for R2TSN 0 | DataSN = 0, F=1 | 10886 | 10887 +------------------+-----------------------+------------- 10888 ---------+ 10889 | | <<< SCSI Response |Send Status and 10890 Sense | 10891 | | ExpDataSN = 2 | 10892 | 10893 +------------------+-----------------------+------------- 10894 ---------+ 10896 Julian Satran Expires August 2002 6 10898 iSCSI 20-January-02 10900 | Command Complete | | 10901 | 10902 +------------------+-----------------------+------------- 10903 ---------+ 10905 *) Send data and Receive Data may be transferred simulta- 10906 neously as in an atomic Read-Old-Write-New or sequential 10907 as in an atomic Read-Update-Write (in the alter case the 10908 R2T may follow the received data). 10910 Unsolicited and immediate output (write) data with DataSN 10911 Example 10913 +------------------+-----------------------+------------- 10914 ---------+ 10915 |Initiator Function| PDU Type & Content | Target Func- 10916 tion | 10917 +------------------+-----------------------+------------- 10918 ---------+ 10919 | Command request |SCSI Command (WRITE)>>>| Receive com- 10920 mand | 10921 | (write) |F=0 | and data 10922 | 10923 |+ immediate data | | and queue it 10924 | 10925 +------------------+-----------------------+------------- 10926 ---------+ 10927 | Send Unsolicited | SCSI Write Data >>> | Receive more 10928 Data | 10929 | Data | DataSN = 0, F=1 | 10930 | 10931 +------------------+-----------------------+------------- 10932 ---------+ 10933 | | | Process old 10934 commands | 10935 +------------------+-----------------------+------------- 10936 ---------+ 10937 | | <<< R2T | Ready for more 10938 data | 10939 | | R2TSN = 0 | 10940 | 10941 +------------------+-----------------------+------------- 10942 ---------+ 10944 Julian Satran Expires August 2002 7 10946 iSCSI 20-January-02 10948 | Send Data | SCSI Write Data >>> | Receive Data 10949 | 10950 | for R2TSN 0 | DataSN = 0, F=1 | 10951 | 10952 +------------------+-----------------------+------------- 10953 ---------+ 10954 | | <<< SCSI Response |Send Status and 10955 Sense | 10956 | | | 10957 | 10958 +------------------+-----------------------+------------- 10959 ---------+ 10960 | Command Complete | | 10961 | 10962 +------------------+-----------------------+------------- 10963 ---------+ 10965 A.4 CRC Examples 10967 N.B. all Values are Hexadecimal 10969 32 bytes of zeroes: 10971 Byte: 0 1 2 3 10973 0: 00 00 00 00 10974 ... 10975 28: 00 00 00 00 10977 CRC: aa 36 91 8a 10979 32 bytes of ones: 10981 Byte: 0 1 2 3 10983 0: ff ff ff ff 10984 ... 10985 28: ff ff ff ff 10987 CRC: 43 ab a8 62 10989 32 bytes of incrementing 00..1f: 10991 Julian Satran Expires August 2002 8 10993 iSCSI 20-January-02 10995 Byte: 0 1 2 3 10997 0: 00 01 02 03 10998 ... 10999 28: 1c 1d 1e 1f 11001 CRC: 4e 79 dd 46 11003 32 bytes of decrementing 1f..00: 11005 Byte: 0 1 2 3 11007 0: 1f 1e 1d 1c 11008 ... 11009 28: 03 02 01 00 11011 CRC: 5c db 3f 11 11013 Julian Satran Expires August 2002 9 11015 iSCSI 20-January-02 11017 Appendix A. Login Phase Examples 11019 In the first example, the initiator and target authenti- 11020 cate each other via Kerberos: 11022 I-> Login (CSG,NSG=0,1 T=1) 11023 InitiatorName=iqn.1999-07.com.os.hostid.77 11024 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11025 AuthMethod=KRB5,SRP,none 11027 T-> Login (CSG,NSG=0,0 T=0) 11028 AuthMethod=KRB5 11030 I-> Login (CSG,NSG=0,1 T=1) 11031 KRB_AP_REQ= 11033 (krb_ap_req contains the Kerberos V5 ticket and 11034 authenticator with MUTUAL-REQUIRED set in the ap- 11035 options field) 11037 If the authentication is successful, the target pro- 11038 ceeds with: 11040 T-> Login (CSG,NSG=0,1 T=1) 11041 KRB_AP_REP= 11043 (krb_ap_rep is the Kerberos V5 mutual authentication 11044 reply) 11046 If the authentication is successful, the initiator 11047 may proceed with: 11049 I-> Login (CSG,NSG=1,0 T=0) FirstBurstSize=0 11050 T-> Login (CSG,NSG=1,0 T=0) FirstBurstSize=8192 Max- 11051 BurstSize=8192 11052 I-> Login (CSG,NSG=1,0 T=0) MaxBurstSize=8192 11053 ... more iSCSI Operational Parameters 11055 T-> Login (CSG,NSG=1,0 T=0) 11056 ... more iSCSI Operational Parameters 11058 And at the end: 11060 I-> Login (CSG,NSG=1,3 T=1) 11061 optional iSCSI parameters 11063 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11065 Julian Satran Expires August 2002 1 11067 iSCSI 20-January-02 11069 If the initiator�s authentication by the target is 11070 not successful, the target responds with: 11072 T-> Login "login reject" 11074 instead of the Login KRB_AP_REP message, and termi- 11075 nates the connection. 11077 If the target�s authentication by the initiator is 11078 not successful, the initiator terminates the con- 11079 nection (without responding to the Login KRB_AP_REP 11080 message). 11082 In the next example only the initiator is authenticated by 11083 the target via Kerberos: 11085 I-> Login (CSG,NSG=0,1 T=1) 11086 InitiatorName=iqn.1999-07.com.os.hostid.77 11087 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11088 AuthMethod=SRP,KRB5,none 11090 T-> Login-PR (CSG,NSG=0,0 T=0) 11091 AuthMethod=KRB5 11093 I-> Login (CSG,NSG=0,1 T=1) 11094 KRB_AP_REQ=krb_ap_req 11096 (MUTUAL-REQUIRED not set in the ap-options field of 11097 krb_ap_req) 11099 If the authentication is successful, the target pro- 11100 ceeds with: 11102 T-> Login (CSG,NSG=0,1 T=1) 11104 I-> Login (CSG,NSG=1,0 T=0) 11105 ... iSCSI parameters 11107 T-> Login (CSG,NSG=1,0 T=0) 11108 ... iSCSI parameters 11110 . . . 11112 T-> Login (CSG,NSG=1,3 T=1)"login accept" 11114 In the next example, the initiator and target authenticate 11115 each other via SPKM1: 11117 Julian Satran Expires August 2002 2 11119 iSCSI 20-January-02 11121 I-> Login (CSG,NSG=0,1 T=1) 11122 InitiatorName=iqn.1999-07.com.os.hostid.77 11123 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11124 AuthMethod=SPKM1,KRB5,none 11126 T-> Login (CSG,NSG=0,0 T=0) 11127 AuthMethod=SPKM1 11129 I-> Login (CSG,NSG=0,0 T=0) 11130 SPKM_REQ= 11132 (spkm-req is the SPKM-REQ token with the mutual-state 11133 bit in the options field of the REQ-TOKEN set) 11135 T-> Login (CSG,NSG=0,0 T=0) 11136 SPKM_REP_TI= 11138 If the authentication is successful, the initiator 11139 proceeds: 11141 I-> Login (CSG,NSG=0,1 T=1) 11142 SPKM_REP_IT= 11144 If the authentication is successful, the target pro- 11145 ceeds with: 11147 T-> Login (CSG,NSG=0,1 T=1) 11149 The initiator may proceed: 11151 I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters 11152 T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters 11154 And at the end: 11156 I-> Login (CSG,NSG=1,3 T=1) 11157 optional iSCSI parameters 11159 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11161 If the target�s authentication by the initiator is 11162 not successful, the initiator terminates the con- 11163 nection (without responding to the Login 11164 SPKM_REP_TI message). 11166 If the initiator�s authentication by the target is 11167 not successful, the target responds with: 11169 T-> Login "login reject" 11171 Julian Satran Expires August 2002 3 11173 iSCSI 20-January-02 11175 instead of the Login "proceed and change stage" mes- 11176 sage, and terminates the connection. 11178 In the next example, the initiator and target authenticate 11179 each other via SPKM2: 11181 I-> Login (CSG,NSG=0,0 T=0) 11182 InitiatorName=iqn.1999-07.com.os.hostid.77 11183 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11184 AuthMethod=SPKM1,SPKM2 11186 T-> Login-PR (CSG,NSG=0,0 T=0) 11187 AuthMethod=SPKM2 11189 I-> Login (CSG,NSG=0,1 T=1) 11190 SPKM_REQ= 11192 (spkm-req is the SPKM-REQ token with the mutual-state 11193 bit in the options field of the REQ-TOKEN not set) 11195 If the authentication is successful, the target pro- 11196 ceeds with: 11198 T-> Login (CSG,NSG=0,1 T=1) 11200 The initiator may proceed: 11202 I-> Login (CSG,NSG=1,0 T=0) 11203 ... iSCSI parameters 11205 T-> Login (CSG,NSG=1,0 T=0) 11206 ... iSCSI parameters 11208 And at the end: 11210 I-> Login (CSG,NSG=1,3 T=1) 11211 optional iSCSI parameters 11213 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11215 In the next example, the initiator and target authenticate 11216 each other via SRP: 11218 I-> Login (CSG,NSG=0,1 T=1) 11219 InitiatorName=iqn.1999-07.com.os.hostid.77 11220 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11222 Julian Satran Expires August 2002 4 11224 iSCSI 20-January-02 11226 AuthMethod=KRB5,SRP,none 11228 T-> Login-PR (CSG,NSG=0,0 T=0) 11229 AuthMethod=SRP 11231 I-> Login (CSG,NSG=0,0 T=0) 11232 SRP_U= 11233 TargetAuth=yes 11235 T-> Login (CSG,NSG=0,0 T=0) 11236 SRP_N= 11237 SRP_g= 11238 SRP_s= 11240 I-> Login (CSG,NSG=0,0 T=0) 11241 SRP_A= 11243 T-> Login (CSG,NSG=0,0 T=0) 11244 SRP_B= 11246 I-> Login (CSG,NSG=0,1 T=1) 11247 SRP_M= 11249 If the initiator authentication is successful, the 11250 target proceeds: 11252 T-> Login (CSG,NSG=0,1 T=1) 11253 SRP_HM= 11255 Where N, g, s, A, B, M, and H(A | M | K) are defined in 11256 [RFC2945]. 11258 If the target authentication is not successful, the 11259 initiator terminates the connection; otherwise, it 11260 proceeds. 11262 I-> Login (CSG,NSG=1,0 T=0) 11263 ... iSCSI parameters 11265 T-> Login (CSG,NSG=1,0 T=0) 11266 ... iSCSI parameters 11268 And at the end: 11270 I-> Login (CSG,NSG=1,3 T=1) 11271 optional iSCSI parameters 11273 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11275 Julian Satran Expires August 2002 5 11277 iSCSI 20-January-02 11279 If the initiator authentication is not successful, 11280 the target responds with: 11282 T-> Login "login reject" 11284 Instead of the T-> Login SRP_HM= mes- 11285 sage and terminates the connection. 11287 In the next example, only the initiator is authenticated 11288 by the target via SRP: 11290 I-> Login (CSG,NSG=0,1 T=1) 11291 InitiatorName=iqn.1999-07.com.os.hostid.77 11292 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11293 AuthMethod=KRB5,SRP,none 11295 T-> Login-PR (CSG,NSG=0,0 T=0) 11296 AuthMethod=SRP 11298 I-> Login (CSG,NSG=0,0 T=0) 11299 SRP_U= 11300 TargetAuth=no 11302 T-> Login (CSG,NSG=0,0 T=0) 11303 SRP_N= 11304 SRP_g= 11305 SRP_s= 11307 I-> Login (CSG,NSG=0,0 T=0) 11308 SRP_A= 11310 T-> Login (CSG,NSG=0,0 T=0) 11311 SRP_B= 11313 I-> Login (CSG,NSG=0,1 T=1) 11314 SRP_M= 11316 If the initiator authentication is successful, the 11317 target proceeds: 11319 T-> Login (CSG,NSG=0,1 T=1) 11321 I-> Login (CSG,NSG=1,0 T=0) 11322 ... iSCSI parameters 11324 T-> Login (CSG,NSG=1,0 T=0) 11325 ... iSCSI parameters 11327 And at the end: 11329 Julian Satran Expires August 2002 6 11331 iSCSI 20-January-02 11333 I-> Login (CSG,NSG=1,3 T=1) 11334 optional iSCSI parameters 11336 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11338 In the next example the initiator and target authenticate 11339 each other via CHAP: 11341 I-> Login (CSG,NSG=0,0 T=0) 11342 InitiatorName=iqn.1999-07.com.os.hostid.77 11343 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11344 AuthMethod=KRB5,CHAP,none 11346 T-> Login-PR (CSG,NSG=0,0 T=0) 11347 AuthMethod=CHAP 11349 I-> Login (CSG,NSG=0,0 T=0) 11350 CHAP_A= 11352 T-> Login (CSG,NSG=0,0 T=0) 11353 CHAP_A= 11354 CHAP_I= 11355 CHAP_C= 11357 I-> Login (CSG,NSG=0,1 T=1) 11358 CHAP_N= 11359 CHAP_R= 11360 CHAP_I= 11361 CHAP_C= 11363 If the initiator authentication is successful, the 11364 target proceeds: 11366 T-> Login (CSG,NSG=0,1 T=1) 11367 CHAP_N= 11368 CHAP_R= 11370 If the target authentication is not successful, the 11371 initiator aborts the connection; otherwise, it pro- 11372 ceeds. 11374 I-> Login (CSG,NSG=1,0 T=0) 11375 ... iSCSI parameters 11376 T-> Login (CSG,NSG=1,0 T=0) 11377 ... iSCSI parameters 11379 And at the end: 11381 Julian Satran Expires August 2002 7 11383 iSCSI 20-January-02 11385 I-> Login (CSG,NSG=1,3 T=1) 11386 optional iSCSI parameters 11388 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11390 If the initiator authentication is not successful, 11391 the target responds with: 11393 T-> Login "login reject" 11395 Instead of the Login CHAP_R= "proceed and 11396 change stage" 11397 message and terminates the connection. 11399 In the next example, only the initiator is authenticated 11400 by the target via CHAP: 11402 I-> Login (CSG,NSG=0,1 T=0) 11403 InitiatorName=iqn.1999-07.com.os.hostid.77 11404 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11405 AuthMethod=KRB5,CHAP,none 11407 T-> Login-PR (CSG,NSG=0,0 T=0) 11408 AuthMethod=CHAP 11410 I-> Login (CSG,NSG=0,0 T=0) 11411 CHAP_A= 11413 T-> Login (CSG,NSG=0,0 T=0) 11414 CHAP_A= 11415 CHAP_I= 11416 CHAP_C= 11418 I-> Login (CSG,NSG=0,1 T=1) 11419 CHAP_N= 11420 CHAP_R= 11422 If the initiator authentication is successful, the 11423 target proceeds: 11425 T-> Login (CSG,NSG=0,1 T=1) 11427 I-> Login (CSG,NSG=1,0 T=0) 11428 ... iSCSI parameters 11430 T-> Login (CSG,NSG=1,0 T=0) 11432 Julian Satran Expires August 2002 8 11434 iSCSI 20-January-02 11436 ... iSCSI parameters 11438 And at the end: 11440 I-> Login (CSG,NSG=1,3 T=1) 11441 optional iSCSI parameters 11443 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11445 In the next example, the initiator does not offer any 11446 security parameters. It therefore, may offer iSCSI param- 11447 eters on the Login PDU with the T bit set to 1, and the 11448 target may respond with a final Login Response PDU immedi- 11449 ately: 11451 I-> Login (CSG,NSG=1,3 T=1) 11452 InitiatorName=iqn.1999-07.com.os.hostid.77 11453 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11454 ... iSCSI parameters 11456 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11457 ... ISCSI parameters 11459 In the next example, the initiator does offer secu- 11460 rity parameters on the Login PDU, but the target 11461 does not choose any (i.e., chooses the "none" val- 11462 ues): 11464 I-> Login (CSG,NSG=0,1 T=1) 11465 InitiatorName=iqn.1999-07.com.os.hostid.77 11466 TargetName=iqn.1999-07.com.acme.diskarray.sn.88 11467 AuthMethod:KRB5,SRP,none 11469 T-> Login-PR (CSG,NSG=0,1 T=1) 11470 AuthMethod=none 11472 I-> Login (CSG,NSG=1,0 T=0) 11473 ... iSCSI parameters 11475 T-> Login (CSG,NSG=1,0 T=0) 11476 ... iSCSI parameters 11478 And at the end: 11480 I-> Login (CSG,NSG=1,3 T=1) 11481 optional iSCSI parameters 11483 Julian Satran Expires August 2002 9 11485 iSCSI 20-January-02 11487 T-> Login (CSG,NSG=1,3 T=1) "login accept" 11489 Julian Satran Expires August 2002 10 11491 iSCSI 20-January-02 11493 Appendix A. SendTargets Operation 11495 To reduce the amount of configuration required on an ini- 11496 tiator, iSCSI provides the SendTargets text request. This 11497 initiator sends this command to request a list of targets 11498 to which it may have access, as well as the list of 11499 addresses (IP address and TCP port) on which these targets 11500 may be accessed. 11502 To make use of SendTargets, an initiator must first estab- 11503 lish one of two types of sessions. If the initi- 11504 ator establishes the session using the key 11505 "SessionType=discovery", the session is a discovery ses- 11506 sion, and a target name does not need to be specified. 11507 Otherwise, the session is a normal, operational session. 11508 The SendTargets command MUST only be sent during the full 11509 feature phase of a normal or discovery session. 11511 A system that contains targets MUST support discovery ses- 11512 sions on each of its IP addresses, and MUST support the 11513 SendTargets command on the discovery session. A target 11514 MUST support the SendTargets command on operational ses- 11515 sions; these will only return address information about 11516 the target to which the session is connected, and do not 11517 return information about other targets. 11519 An initiator MAY make use of the SendTargets as it sees 11520 fit. 11522 A SendTargets command consists of a single Text request 11523 PDU. 11524 This PDU contains exactly one text key and value. The 11525 text key MUST be SendTargets. The expected response 11526 depends upon the value, as well as whether the session is 11527 a discovery or operational session. 11529 The value must be one of: 11531 all 11533 The initiator is requesting that information on all 11534 relevant targets known to the implementation be 11535 returned. This value MUST be supported on a dis- 11537 Julian Satran Expires August 2002 1 11539 iSCSI 20-January-02 11541 covery session, and MAY NOT be supported on an 11542 operational session. 11544 11546 If an iSCSI target name is specified, the session 11547 should respond with addresses for only the named 11548 target, if possible. This value MUST be supported 11549 on discovery sessions. A discovery session MUST be 11550 capable of returning addresses for those targets 11551 that would have been returned had value=all been 11552 designated. 11554 11556 The session should respond only with addresses for 11557 the target to which the session is logged in. This 11558 MUST be supported on operational sessions, and MAY 11559 NOT return targets other than the one to which the 11560 session is logged in. 11562 The response to this command is a text response that con- 11563 tains a list of zero or more targets and, optionally, 11564 their addresses. Each target is returned as a target 11565 record. A target record begins with the TargetName text 11566 key, followed by a list of TargetAddress text keys, and 11567 bounded by the end of the text response or the next Tar- 11568 getName key, which begins a new record. No text keys 11569 other than TargetName and TargetAddress are permitted 11570 within a SendTargets response. 11572 For the format of the TargetName, see Section 12.4 Target- 11573 Name. 11575 A discovery session MAY respond to a SendTargets request 11576 with its complete list of targets, or with a list of tar- 11577 gets that is based on the name of the initiator logged in 11578 to the session. 11580 A SendTargets response MAY not contain target names if 11581 there are no targets for the requesting initiator to 11582 access. 11584 Each target record returned includes zero or more Tar- 11585 getAddress fields. 11587 Julian Satran Expires August 2002 2 11589 iSCSI 20-January-02 11591 A SendTargets response MUST NOT contain iSCSI default tar- 11592 get names. 11594 Each target record starts with one text key of the form: 11596 TargetName= 11598 Followed by zero or more address keys of the form: 11600 TargetAddress=[:], 11603 The hostname-or-ipaddress and tcp port are as specified in 11604 the Section 2.2.7 Naming and Addressing. 11606 Each TargetAddress belongs to a portal group, identified 11607 by its numeric, decimal portal group tag. The iSCSI tar- 11608 get name, together with this tag, constitutes the SCSI 11609 port identifier; the tag need be unique only within a 11610 given target name's list of addresses. 11612 Multiple-connection sessions can span iSCSI addresses 11613 that belong to the same portal group. 11615 Multiple-connection sessions cannot span iSCSI addresses 11616 that belong to different portal groups. 11618 If a SendTargets response reports an iSCSI address for a 11619 target, it SHOULD also report all other addresses in its 11620 portal group in the same response. 11622 A SendTargets text response can be longer than a single 11623 Text Response 11624 PDU, and makes use of the long text responses as speci- 11625 fied. 11627 After obtaining a list of targets from the discovery tar- 11628 get session, an iSCSI initiator may initiate new sessions 11629 to log in to the discovered targets for full operation. 11630 The initiator MAY keep the session to a default target 11631 open, and MAY send subsequently SendTargets commands to 11632 discover new targets. 11634 Julian Satran Expires August 2002 3 11636 iSCSI 20-January-02 11638 Examples: 11640 This example is the SendTargets response from a single 11641 target that has no other interface ports. 11643 Initiator sends text request that contains: 11645 SendTargets=all 11647 Target sends a text response that contains: 11649 TargetName=iqn.1993-11.com.acme.diskarray.sn.8675309 11651 All the target had to return in the simple case was the 11652 target name. It is assumed by the initiator that the IP 11653 address and TCP port for this target are the same as used 11654 on the current connection to the default iSCSI target. 11656 The next example has two internal iSCSI targets, each 11657 accessible via two different ports with different IP 11658 addresses. The following is the text response: 11660 TargetName=iqn.1993-11.com.acme.diskarray.sn.8675309 11661 TargetAddress=10.1.0.45:3000,1 11662 TargetAddress=10.1.1.45:3000,2 11663 TargetName=iqn.1993-11.com.acme.diskarray.sn.1234567 11664 TargetAddress=10.1.0.45:3000,1 11665 TargetAddress=10.1.1.45:3000,2 11667 Both targets share both addresses; the multiple addresses 11668 are likely used to provide multi-path support. The initi- 11669 ator may connect to either target name on either address. 11670 Each of the addresses has its own portal group tag; they 11671 do not support spanning multiple-connection sessions with 11672 each other. Keep in mind also that the portal group tags 11673 for the two named targets are independent of one another; 11674 portal group "1" on the first target is not necessarily 11675 the same as portal group "1" on the second. 11677 In the above example, a DNS host name could have been 11678 returned instead of an IP address, and that an IPv6 11679 addresses (5 to 16 dotted-decimal numbers) could have also 11680 been returned. 11682 Julian Satran Expires August 2002 4 11684 iSCSI 20-January-02 11686 The next text response shows a target that supports span- 11687 ning sessions across multiple addresses, which indicates 11688 the use of the portal group tags: 11690 TargetName=iqn.1993-11.com.acme.diskarray.sn.8675309 11691 TargetAddress=10.1.0.45:3000,1 11692 TargetAddress=10.1.1.46:3000,1 11693 TargetAddress=10.1.0.47:3000,2 11694 TargetAddress=10.1.1.48:3000,2 11695 TargetAddress=10.1.1.49:3000,3 11697 In this example, any of the target addresses can be used 11698 to reach the same target. A single-connection session can 11699 be established to any of these TCP addresses. A multiple- 11700 connection session could span addresses .45 and .46 or .47 11701 and .48, but cannot span any other combination. A Tar- 11702 getAddress with its own tag (.49), cannot be combined with 11703 any other address within the same session. 11705 This SendTargets response does not indicate whether .49 11706 supports multiple connections per session; it communi- 11707 cated via the MaxConnections text key upon login to the 11708 target. 11710 Julian Satran Expires August 2002 5 11712 iSCSI 20-January-02 11714 Appendix A. Algorithmic Presentation of Error Recovery 11715 Classes 11717 This appendix illustrates the error recovery classes 11718 using a pseudo-programming-language. The procedure names 11719 are chosen to be obvious to most implementers. Each of the 11720 recovery classes described has initiator procedures as 11721 well as target procedures. These algorithms focus on 11722 outlining the mechanics of error recovery classes, and 11723 ignore all other aspects/cases. Examples of this approach 11724 are: 11726 - Handling for only certain Opcode types is shown. 11728 - Only certain reason codes (for example, Recovery in 11729 Logout command) are outlined. 11731 - Resultant cases, such as recovery of Synchroniza- 11732 tion on a header digest error are considered out- 11733 of-scope in these algorithms. In this particular 11734 example a header digest error may lead to connec- 11735 tion recovery if some type of sync and steering 11736 layer is not implemented. 11738 These algorithms strive to convey the iSCSI error recovery 11739 concepts in the simplest terms, and are not designed to be 11740 optimal. 11742 A.1 General Data Structure and Procedure Description 11744 This section defines the procedures and data structures 11745 that are commonly used by all the error recovery algo- 11746 rithms. The structures may not be the exhaustive represen- 11747 tations of what is required for a typical implementation. 11749 Data structure definitions - 11750 struct TransferContext { 11751 int TargetTransferTag; 11752 int ExpectedDataSN; 11753 }; 11755 struct TCB { /* task control block */ 11756 Boolean SoFarInOrder; 11757 int ExpectedDataSN; /* used for both R2Ts, and 11758 Data */ 11760 Julian Satran Expires August 2002 1 11762 iSCSI 20-January-02 11764 int MissingDataSNList[MaxMissingDPDU]; 11765 Boolean FbitReceived; 11766 Boolean StatusXferd; 11767 Boolean CurrentlyAllegiant; 11768 int ActiveR2Ts; 11769 int Response; 11770 char *Reason; 11771 struct TransferContext 11772 TransferContextList[MaxOutStandingR2T]; 11773 int InitiatorTaskTag; 11774 int CmdSN; 11775 }; 11777 struct Connection { 11778 struct Session SessionReference; 11779 Boolean SoFarInOrder; 11780 int CID; 11781 int State; 11782 int ExpectedStatSN; 11783 int MissingStatSNList[MaxMissingSPDU]; 11784 Boolean PerformConnectionCleanup; 11785 }; 11787 struct Session { 11788 int NumConnections; 11789 int NextCmdSN; 11790 int Maxconnections; 11791 int ErrorRecoveryLevel; 11792 struct iSCSIEndpoint OtherEndInfo; 11793 struct Connection ConnectionList[MaxSupported- 11794 Conns]; 11795 }; 11797 Procedure descriptions - 11798 Receive-a-In-PDU(transport connection, inbound PDU); 11799 check-basic-validity(inbound PDU); 11800 Start-Timer(timeout handler, argument, timeout value); 11801 Build-And-Send-Reject(transport connection, bad PDU, rea- 11802 son code); 11804 Julian Satran Expires August 2002 2 11806 iSCSI 20-January-02 11808 A.2 Within-command Error Recovery Algorithms 11810 A.2.1 Procedure Descriptions 11812 Recover-Data-if-Possible(last required DataSN, task con- 11813 trol block); 11814 Build-And-Send-DSnack(task control block); 11815 Build-And-Send-Abort(task control block); 11816 SCSI-Task-Completion(task control block); 11817 Build-And-Send-a-Data-Burst(transport connection, R2T 11818 PDU, 11819 task control 11820 block); 11821 Build-And-Send-R2T(transport connection, description of 11822 data, 11823 task control 11824 block); 11825 Build-And-Send-Status(transport connection, task control 11826 block); 11827 Transfer-Context-Timeout-Handler(transfer context); 11829 Implementation-specific tunables - 11830 InitiatorDataSNACKEnabled, TargetDataSNACKSupported, 11831 TargetRecoveryR2TEnabled. 11833 Notes: 11835 - Some procedures used in this section, including: 11836 Recover-Status-if-Possible, Handle-Status-SNACK- 11837 request, Evaluate-a-StatSN are defined in Within- 11838 connection recovery algorithms. 11840 - The Response processing pseudo-code, shown in the 11841 target algorithms, applies to all solicited PDUs 11842 that carry StatSN - SCSI Response, Text Response 11843 etc. 11845 A.2.2 Initiator Algorithms 11847 Recover-Data-if-Possible(LastRequiredDataSN, TCB) 11848 { 11849 if (InitiatorDataSNACKEnabled) { 11850 if (# of missing PDUs is trackable) { 11851 Note the missing DataSNs in TCB. 11852 Build-And-Send-DSnack(TCB); 11854 Julian Satran Expires August 2002 3 11856 iSCSI 20-January-02 11858 } else { 11859 TCB.Reason = "Protocol service CRC error"; 11860 } 11861 } else { 11862 TCB.Reason = "Protocol service CRC error"; 11863 } 11864 if (TCB.Reason = "Protocol service CRC error") { 11865 Clear the missing PDU list in the TCB. 11866 if (TCB.StatusXferd is not TRUE) 11867 Build-And-Send-Abort(TCB); 11868 } 11869 } 11871 Receive-a-In-PDU(Connection, CurrentPDU) 11872 { 11873 check-basic-validity(CurrentPDU); 11874 if (Header-Digest-Bad) discard, return; 11875 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11876 if ((CurrentPDU.type = Data) 11877 or (CurrentPDU.type = R2T)) { 11878 if (Data-Digest-Bad) { 11879 send-data-SNACK = TRUE; 11880 LastRequiredDataSN = CurrentPDU.DataSN; 11881 } else { 11882 if (TCB.SoFarInOrder = TRUE) { 11883 if (current DataSN is expected) { 11884 Increment TCB.ExpectedDataSN. 11885 } else { 11886 TCB.SoFarInOrder = FALSE; 11887 send-data-SNACK = TRUE; 11888 } 11889 } else { 11890 if (current DataSN was considered missing) 11891 { 11892 remove current DataSN from missing PDU 11893 list. 11894 } else if (current DataSN is higher than 11895 expected) { 11896 send-data-SNACK = TRUE; 11897 } else { 11898 discard, return; 11899 } 11900 Adjust TCB.ExpectedDataSN if appropriate. 11902 Julian Satran Expires August 2002 4 11904 iSCSI 20-January-02 11906 } 11907 LastRequiredDataSN = CurrentPDU.DataSN - 1; 11908 } 11909 if (send-data-SNACK is TRUE and 11910 task is not already considered failed) { 11911 Recover-Data-if-Possible(LastRequiredDataSN, 11912 TCB); 11913 } 11914 if (missing data PDU list is empty) { 11915 TCB.SoFarInOrder = TRUE; 11916 } 11917 if (CurrentPDU.type = R2T) { 11918 Increment ActiveR2Ts for this task. 11919 Build-And-Send-A-Data-Burst(Connection, Current- 11920 PDU, TCB); 11921 } 11922 } else if (CurrentPDU.type = Response) { 11923 if (Data-Digest-Bad) { 11924 send-status-SNACK = TRUE; 11925 } else { 11926 TCB.StatusXferd = TRUE; 11927 Store the status information in TCB. 11928 if (ExpDataSN does not match) { 11929 TCB.SoFarInOrder = FALSE; 11930 Recover-Data-if-Possible(current DataSN, 11931 TCB); 11932 } 11933 if (missing data PDU list is empty) { 11934 TCB.SoFarInOrder = TRUE; 11935 } 11936 send-status-SNACK = Evaluate-a-StatSN(Connection, 11937 CurrentPDU.StatSN); 11938 } 11939 if (send-status-SNACK is TRUE) 11940 Recover-Status-if-Possible(Connection, Current- 11941 PDU); 11942 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, 11943 NOT SHOWN */ 11944 } 11945 if ((TCB.SoFarInOrder is TRUE) and 11946 (TCB.StatusXferd is TRUE)) { 11947 SCSI-Task-Completion(TCB); 11948 } 11950 Julian Satran Expires August 2002 5 11952 iSCSI 20-January-02 11954 } 11956 A.2.3 Target Algorithms 11958 Receive-a-In-PDU(Connection, CurrentPDU) 11959 { 11960 check-basic-validity(CurrentPDU); 11961 if (Header-Digest-Bad) discard, return; 11962 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11963 if (CurrentPDU.type = Data) { 11964 Retrieve TContext from CurrentPDU.TargetTransferTag; 11965 if (Data-Digest-Bad) { 11966 Build-And-Send-Reject(Connection, CurrentPDU, 11967 Payload-Digest-Error); 11968 Note the missing data PDUs in MissingDataRange[]. 11969 send-recovery-R2T = TRUE; 11970 } else { 11971 if (current DataSN is not expected) { 11972 Note the missing data PDUs in MissingDat- 11973 aRange[]. 11974 send-recovery-R2T = TRUE; 11975 } 11976 if (CurrentPDU.Fbit = TRUE) { 11977 if (current PDU is solicited) { 11978 Decrement TCB.ActiveR2Ts. 11979 } 11980 if ((current PDU is unsolicited and 11981 data received is less than I/O size and 11982 data received is less than First- 11983 BurstSize) 11984 or {current PDU is solicited and the size 11985 of 11986 this burst is less than expected)) { 11987 send-recovery-R2T = TRUE; 11988 Note the missing data in MissingDat- 11989 aRange[]. 11990 } 11991 } 11992 } 11993 Increment TContext.ExpectedDataSN. 11994 if (send-recovery-R2T is TRUE and 11995 task is not already considered failed) { 11996 if (TargetRecoveryR2TEnabled is TRUE) { 11998 Julian Satran Expires August 2002 6 12000 iSCSI 20-January-02 12002 Increment TCB.ActiveR2Ts. 12003 Build-And-Send-R2T(Connection, MissingDat- 12004 aRange, TCB); 12005 } else { 12006 if (current PDU is the last unsolicited) 12007 TCB.Reason = "Not enough unsolicited 12008 data"; 12009 else 12010 TCB.Reason = "Protocol service CRC 12011 error"; 12012 } 12013 } 12014 if (TCB.ActiveR2Ts = 0) { 12015 Build-And-Send-Status(Connection, TCB); 12016 } 12017 } else if (CurrentPDU.type = SNACK) { 12018 snack-failure = FALSE; 12019 if (this is data retransmission request) { 12020 if (TargetDataSNACKSupported) { 12021 if (the request is satisfiable) { 12022 Build-And-Send-A-Data-Burst(CurrentPDU, 12023 TCB); 12024 } else { 12025 snack-failure = TRUE; 12026 } 12027 } else { 12028 snack-failure = TRUE; 12029 } 12030 if (snack-failure is TRUE) { 12031 Build-And-Send-Reject(Connection, Current- 12032 PDU, 12033 Data- 12034 SNACK-Reject); 12035 if (TCB.StatusXferd is not TRUE) { 12036 TCB.Reason = "SNACK Rejected"; 12037 Build-And-Send-Status(Connection, TCB); 12038 } 12039 } 12040 } else { 12041 Handle-Status-SNACK-request(Connection, Current- 12042 PDU); 12043 } 12045 Julian Satran Expires August 2002 7 12047 iSCSI 20-January-02 12049 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, 12050 NOT SHOWN */ 12051 } 12052 } 12054 Transfer-Context-Timeout-Handler(TContext) 12055 { 12056 Retrieve TCB and Connection from TContext. 12057 Decrement TCB.ActiveR2Ts. 12058 if (TargetRecoveryR2TEnabled is TRUE and 12059 task is not already considered failed) { 12060 Note the missing data PDUs in MissingDataRange[]. 12061 Build-And-Send-R2T(Connection, MissingDataRange, 12062 TCB); 12063 } else { 12064 TCB.Reason = "Protocol service CRC error"; 12065 if (TCB.ActiveR2Ts = 0) { 12066 Build-And-Send-Status(Connection, TCB); 12067 } 12068 } 12069 } 12071 A.3 Within-connection Recovery Algorithms 12073 A.3.1 Procedure Descriptions 12075 Procedure descriptions: 12076 Recover-Status-if-Possible(transport connection, 12077 currently received PDU); 12078 Evaluate-a-StatSN(transport connection, current StatSN); 12079 Retransmit-Command-if-Possible(transport connection, 12080 CmdSN); 12081 Build-And-Send-SSnack(transport connection); 12082 Build-And-Send-Command(transport connection, task control 12083 block); 12084 Command-Acknowledge-Timeout-Handler(task control block); 12085 Status-Expect-Timeout-Handler(transport connection); 12086 Build-And-Send-Nop-Out(transport connection); 12087 Handle-Status-SNACK-request(transport connection, status 12088 SNACK PDU); 12089 Retransmit-Status-Burst(status SNACK, task control 12090 block); 12091 Is-Acknowledged(beginning StatSN, run size); 12093 Julian Satran Expires August 2002 8 12095 iSCSI 20-January-02 12097 Implementation-specific tunables: 12098 InitiatorCommandRetryEnabled, InitiatorStatusExpectNopEn- 12099 abled, InitiatorProactiveSNACKEnabled, InitiatorStatusS- 12100 NACKEnabled, TargetStatusSNACKSupported. 12102 Notes: 12103 - The initiator algorithms only deal with unsolicited 12104 Nop-In PDUs for generating status SNACKs. Solic- 12105 ited Nop-In PDU has an assigned StatSN, which, when 12106 out-of-order, could trigger the out-of-order StatSN 12107 handling in Within-command algorithms, again lead- 12108 ing to Recover-Status-if-Possible. 12110 - The pseudo-code shown may result in the retransmis- 12111 sion of unacknowledged commands in more cases than 12112 necessary. This will not however affect the cor- 12113 rectness of the operation since the target is 12114 required to discard the duplicate CmdSNs. 12116 - The procedure Build-And-Send-Async is defined in 12117 the Connection recovery algorithms. 12119 - The procedure Status-Expect-Timeout-Handler 12120 describes how initiators may proactively attempt to 12121 retrieve the Status if they so choose. This proce- 12122 dure is assumed to be triggered much before the 12123 standard ULP timeout. 12125 A.3.1.1 Initiator Algorithms 12127 Recover-Status-if-Possible(Connection, CurrentPDU) 12128 { 12129 if ((Connection.state = LOGGED_IN) and 12130 connection is not already considered failed) { 12131 if (InitiatorStatusSNACKEnabled) { 12132 if (# of missing PDUs is trackable) { 12133 Note the missing StatSNs in Connection; 12134 Build-And-Send-SSnack(Connection); 12135 } else { 12136 Connection.PerformConnectionCleanup = TRUE; 12137 } 12138 } else { 12139 Connection.PerformConnectionCleanup = TRUE; 12140 } 12141 if (Connection.PerformConnectionCleanup is TRUE) { 12143 Julian Satran Expires August 2002 9 12145 iSCSI 20-January-02 12147 Start-Timer(Connection-Cleanup-Handler, Connec- 12148 tion, 0); 12149 } 12150 } 12151 } 12153 Retransmit-Command-if-Possible(Connection, CmdSN) 12154 { 12155 if (InitiatorCommandRetryEnabled) { 12156 Retrieve the InitiatorTaskTag, and thus TCB for the 12157 CmdSN. 12158 Build-And-Send-Command(Connection, TCB); 12159 } 12160 } 12162 Evaluate-a-StatSN(Connection, StatSN) 12163 { 12164 send-status-SNACK = FALSE; 12165 if (Connection.SoFarInOrder is TRUE) { 12166 if (current StatSN is the expected) { 12167 Increment Connection.ExpectedStatSN. 12168 } else { 12169 Connection.SoFarInOrder = FALSE; 12170 send-status-SNACK = TRUE; 12171 } 12172 } else { 12173 if (current StatSN was considered missing) { 12174 remove current StatSN from the missing list. 12175 } else { 12176 if (current StatSN is higher than expected){ 12177 send-status-SNACK = TRUE; 12178 } else { 12179 discard, return; 12180 } 12181 } 12182 Adjust Connection.ExpectedStatSN if appropriate. 12183 if (missing StatSN list is empty) { 12184 Connection.SoFarInOrder = TRUE; 12185 } 12186 } 12187 return send-status-SNACK; 12188 } 12190 Julian Satran Expires August 2002 10 12192 iSCSI 20-January-02 12194 Receive-a-In-PDU(Connection, CurrentPDU) 12195 { 12196 check-basic-validity(CurrentPDU); 12197 if (Header-Digest-Bad) discard, return; 12198 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 12199 if (CurrentPDU.type = Nop-In) { 12200 if (the PDU is unsolicited) { 12201 if (current StatSN is not expected) { 12202 Recover-Status-if-Possible(Connection, 12203 CurrentPDU); 12204 } 12205 if (current ExpCmdSN is not our NextCmdSN) 12206 { 12207 Retransmit-Command-if-Possible(Connec- 12208 tion, 12209 CurrentPDU.ExpCmdSN); 12210 } 12211 } 12212 } else if (CurrentPDU.type = Reject) { 12213 if (it is a data digest error on immediate data) 12214 { 12215 Retransmit-Command-if-Possible(Connection, 12216 CurrentPDU.BadPDU- 12217 Header.CmdSN); 12218 } 12219 } else if (CurrentPDU.type = Response) { 12220 send-status-SNACK = Evaluate-a-StatSN(Connection, 12221 CurrentPDU.StatSN); 12222 if (send-status-SNACK is TRUE) 12223 Recover-Status-if-Possible(Connection, Cur- 12224 rentPDU); 12225 } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOV- 12226 ERY, 12227 * NOT SHOWN */ 12228 } 12229 } 12231 Command-Acknowledge-Timeout-Handler(TCB) 12232 { 12233 Retrieve the Connection for TCB. 12234 Retransmit-Command-if-Possible(Connection, 12235 TCB.CmdSN); 12236 } 12238 Julian Satran Expires August 2002 11 12240 iSCSI 20-January-02 12242 Status-Expect-Timeout-Handler(Connection) 12243 { 12244 if (InitiatorStatusExpectNopEnabled) { 12245 Build-And-Send-Nop-Out(Connection); 12246 } else if (InitiatorProactiveSNACKEnabled){ 12247 if ((Connection.state = LOGGED_IN) and 12248 connection is not already considered failed) { 12249 Build-And-Send-SSnack(Connection); 12250 } 12251 } 12252 } 12254 A.3.1.2 Target Algorithms 12256 Handle-Status-SNACK-request(Connection, CurrentPDU) 12257 { 12258 if (TargetStatusSNACKSupported) { 12259 if (request for an acknowledged run) { 12260 Build-And-Send-Reject(Connection, CurrentPDU, 12261 Protocol-Error); 12262 } else if (request for an untransmitted run) { 12263 discard, return; 12264 } else { 12265 Retransmit-Status-Burst(CurrentPDU, TCB); 12266 } 12267 } else { 12268 Build-And-Send-Async(Connection, DroppedConnection, 12269 LogoutLoginMinTime, Logout- 12270 LoginMaxTime); 12271 } 12272 } 12274 A.3.2 Connection Recovery Algorithms 12276 A.3.2.1 Procedure Descriptions 12278 Build-And-Send-Async(transport connection, reason code, 12279 minimum time, maximum 12280 time); 12281 Pick-A-Logged-In-Connection(session); 12282 Build-And-Send-Logout(transport connection, logout con- 12283 nection 12284 identifier, reason code); 12286 Julian Satran Expires August 2002 12 12288 iSCSI 20-January-02 12290 PerformImplicitLogout(transport connection, logout con- 12291 nection 12292 identifier, target information); 12293 PerformLogin(transport connection, target information); 12294 CreateNewTransportConnection(target information); 12295 Build-And-Send-Command(transport connection, task control 12296 block); 12297 Connection-Cleanup-Handler(transport connection); 12298 Connection-Resource-Timeout-Handler(transport connec- 12299 tion); 12300 Quiesce-And-Prepare-for-New-Allegiance(session, task con- 12301 trol block); 12302 Build-And-Send-Logout-Response(transport connection, 12303 CID of connection in recovery, 12304 reason code); 12305 Build-And-Send-TaskMgmt-Response(transport connection, 12306 task mgmt command PDU, response 12307 code); 12308 Establish-New-Allegiance(task control block, transport 12309 connection); 12310 Schedule-Command-To-Continue(task control block); 12312 Notes: 12313 - Transport exception conditions, such as unexpected 12314 connection termination, connection reset, and hung 12315 connection while the connection is in the full-fea- 12316 ture phase, are all assumed to be asynchronously 12317 signaled to the iSCSI layer using the 12318 Transport_Exception_Handler procedure. 12320 A.3.2.2 Initiator Algorithms 12322 Receive-a-In-PDU(Connection, CurrentPDU) 12323 { 12324 check-basic-validity(CurrentPDU); 12325 if (Header-Digest-Bad) discard, return; 12326 Retrieve TCB from CurrentPDU.InitiatorTaskTag. 12327 if (CurrentPDU.type = Async) { 12328 if (CurrentPDU.AsyncEvent = ConnectionDropped) { 12329 Retrieve the AffectedConnection for Current- 12330 PDU.Parameter1. 12331 AffectedConnection.State = CLEANUP_WAIT; 12333 Julian Satran Expires August 2002 13 12335 iSCSI 20-January-02 12337 } else if (CurrentPDU.AsyncEvent = LogoutRequest)) 12338 { 12339 Retrieve the AffectedConnection for Current- 12340 PDU.Parameter1. 12341 AffectedConnection.State = LOGOUT_REQUESTED; 12342 AffectedConnection.PerformConnectionCleanup = 12343 TRUE; 12344 Start-Timer(Connection-Cleanup-Handler, 12345 AffectedConnection, Current- 12346 PDU.Parameter2); 12347 } else if (CurrentPDU.AsyncEvent = Session- 12348 Dropped)) { 12349 for (each Connection) { 12350 Connection.state = CLEANUP_WAIT; 12351 } 12352 Session.state = FAILED; 12353 Start-Timer(Session-Continuation-Handler, 12354 Session, CurrentPDU.Parameter2); 12355 } 12357 } else if (CurrentPDU.type = LogoutResponse) { 12358 Retrieve the CleanupConnection for CurrentPDU.CID. 12359 if (CurrentPDU.Response = failure) { 12360 CleanupConnection.State = CLEANUP_WAIT; 12361 } else { 12362 CleanupConnection.State = FREE; 12363 } 12364 } else if (CurrentPDU.type = LoginResponse) { 12365 if (this is a response to an implicit Logout) { 12366 Retrieve the CleanupConnection. 12367 if (successful) { 12368 CleanupConnection.State = FREE; 12369 Connection.State = LOGGED_IN; 12370 } else { 12371 CleanupConnection.State = CLEANUP_WAIT; 12372 DestroyTransportConnection(Connection); 12373 } 12374 } 12375 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12376 * NOT SHOWN */ 12377 } 12378 if (CleanupConnection.State = FREE) { 12380 Julian Satran Expires August 2002 14 12382 iSCSI 20-January-02 12384 for (each command that was active on CleanupConnec- 12385 tion) { 12386 /* Establish new connection allegiance */ 12387 NewConnection = Pick-A-Logged-In-Connec- 12388 tion(Session); 12389 Build-And-Send-Command(NewConnection, TCB); 12390 } 12391 } 12392 } 12394 Connection-Cleanup-Handler(Connection) 12395 { 12396 Retrieve Session from Connection. 12397 Start-Timer(Connection-Resource-Timeout-Handler, 12398 Connection, LogoutLoginMaxTime); 12399 if (Connection can still exchange iSCSI PDUs) { 12400 NewConnection = Connection; 12401 } else { 12402 if (there are other logged-in connections) { 12403 NewConnection = Pick-A-Logged-In-Connec- 12404 tion(Session); 12405 } else { 12406 NewConnection = 12407 CreateTransportConnection(Session.Other- 12408 EndInfo); 12409 Initiate an implicit Logout on NewConnection 12410 for 12411 Connec- 12412 tion.CID. 12413 return; 12414 } 12415 } 12416 Build-And-Send-Logout(NewConnection, Connection.CID, 12417 RecoveryRemove); 12418 } 12420 Transport_Exception_Handler(Connection) 12421 { 12422 Connection.PerformConnectionCleanup = TRUE; 12423 if (the event is an unexpected transport disconnect) { 12424 Connection.State = CLEANUP_WAIT; 12425 Start-Timer(Connection-Cleanup-Handler, Connec- 12426 tion, 12428 Julian Satran Expires August 2002 15 12430 iSCSI 20-January-02 12432 LogooutLogin- 12433 MinTime); 12435 } else { 12436 Connection.State = FREE; 12437 } 12438 } 12440 A.3.2.3 Target Algorithms 12442 Receive-a-In-PDU(Connection, CurrentPDU) 12443 { 12444 check-basic-validity(CurrentPDU); 12445 if (Header-Digest-Bad) discard, return; 12446 else if (Data-Digest-Bad) { 12447 Build-And-Send-Reject(Connection, CurrentPDU, 12448 Payload-Digest-Error); 12449 discard, return; 12450 } 12451 Retrieve TCB and Session. 12452 if (CurrentPDU.type = Logout) { 12453 if (CurrentPDU.ReasonCode = RecoveryRemove) { 12454 Retrieve the CleanupConnection from Current- 12455 PDU.CID). 12456 for (each command active on CleanupConnection) 12457 { 12458 Quiesce-And-Prepare-for-New-Alle- 12459 giance(Session, TCB); 12460 TCB.CurrentlyAllegiant = FALSE; 12461 } 12462 Cleanup-Connection-State(CleanupConnection); 12463 if ((quiescing successful) and (cleanup suc- 12464 cessful)) { 12465 Build-And-Send-Logout-Response(Connection, 12466 CleanupConnection.CID, 12467 Sucess); 12468 } else { 12469 Build-And-Send-Logout-Response(Connection, 12470 CleanupConnection.CID, 12471 Failure); 12472 } 12473 } 12474 } else if (CurrentPDU.type = TaskManagement) { 12476 Julian Satran Expires August 2002 16 12478 iSCSI 20-January-02 12480 if (CurrentPDU.function = "TaskReassign") { 12481 if (Session.ErrorRecoveryLevel < 2) { 12482 Build-And-Send-TaskMgmt-Response(Connec- 12483 tion, 12484 CurrentPDU, "Task failover not sup- 12485 ported"); 12486 } else if (task is not found) { 12487 Build-And-Send-TaskMgmt-Response(Connec- 12488 tion, 12489 CurrentPDU, "Task not in task set"); 12490 } else if (task is currently allegiant) { 12491 Build-And-Send-TaskMgmt-Response(Connec- 12492 tion, 12493 CurrentPDU, "Task still alle- 12494 giant"); 12495 } else { 12496 Establish-New-Allegiance(TCB, Connec- 12497 tion); 12498 TCB.CurrentlyAllegiant = TRUE; 12499 Schedule-Command-To-Continue(TCB); 12500 } 12501 } 12502 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 12503 * NOT SHOWN */ 12504 } 12505 } 12507 Transport_Exception_Handler(Connection) 12508 { 12509 Connection.PerformConnectionCleanup = TRUE; 12510 if (the event is an unexpected transport disconnect) { 12511 Connection.State = CLEANUP_WAIT; 12512 Start-Timer(Connection-Resource-Timeout-Handler, 12513 Connection, 12514 (LogoutLoginMinTime+Logout- 12515 LoginMinTime)); 12516 if (this Session has full-feature phase connec- 12517 tions left) { 12518 DifferentConnection = 12519 Pick-A-Logged-In-Connection(Session); 12520 Build-And-Send-Async(DifferentConnection, 12521 DroppedConnection, LogoutLoginMinTime, 12522 LogoutLoginMaxTime); 12524 Julian Satran Expires August 2002 17 12526 iSCSI 20-January-02 12528 } 12529 } else { 12530 Connection.State = FREE; 12531 } 12532 } 12534 Julian Satran Expires August 2002 18 12536 iSCSI 20-January-02 12538 Full Copyright Statement 12540 "Copyright (C) The Internet Society (date). All Rights 12541 Reserved. This document and translations of it may be cop- 12542 ied and furnished to others, and derivative works that 12543 comment on or otherwise explain it or assist in its imple- 12544 mentation may be prepared, copied, published and distrib- 12545 uted, in whole or in part, without restriction of any 12546 kind, provided that the above copyright notice and this 12547 paragraph are included on all such copies and derivative 12548 works. However, this document itself may not be modified 12549 in any way, such as by removing the copyright notice or 12550 references to the Internet Society or other Internet orga- 12551 nizations, except as needed for the purpose of developing 12552 Internet standards in which case the procedures for copy- 12553 rights defined in the Internet Standards process must be 12554 followed, or as required to translate it into languages 12555 other than English. 12557 The limited permissions granted above are perpetual and 12558 will not be revoked by the Internet Society or its suc- 12559 cessors or assigns. 12561 This document and the information contained herein is pro- 12562 vided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 12563 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 12564 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 12565 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 12566 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 12567 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12569 Julian Satran Expires August 2002 1