idnits 2.17.1 draft-ietf-ips-iscsi-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 349 instances of too long lines in the document, the longest one being 20 characters in excess of 72. ** The abstract seems to contain references ([SPC3], [ISCSI-REQ], [SEC-IPS], [NDT], [SAM2], [BOOT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == 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 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3143 has weird spacing: '...ameters not s...' == Line 3811 has weird spacing: '...itiator recei...' == Line 4439 has weird spacing: '...nection a "c...' == Line 5565 has weird spacing: '...e-class devic...' == Line 5633 has weird spacing: '...t group a hea...' == (7 more instances...) == 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: a) iSCSI names MUST have a single encoding method when transmit-ted over various protocols. b) iSCSI names MUST be relatively simple to compare. The algo-rithm for comparing two iSCSI names for equivalence MUST not rely on any external server. c) iSCSI names MUST be composed of displayable characters only. iSCSI names should be kept as simple as possible. They MUST pro-vide for the use of international character sets, and MUST not be case sensitive. Whitespace characters MUST NOT be used. d) iSCSI names MUST be transport-friendly. They MUST be trans-ported using both binary and ASCII-based protocols. == 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: In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state. For example, when reassigning read commands, the target SHOULD take advantage of Exp-DataSN field provided by the Task Management function request (which must be set to zero if there was no data transfer) and bring the read command to completion by sending the remaining data and sending (or resending) the status. ExpDataSN acknowledges all data sent up to -but not including the Data-In PDU and or R2T with DataSN (or R2TSN) equal to ExpDataSN. However, targets may choose to send/receive the entire data on a reassignment of connection allegiance if unable to recover or maintain accurate state. Initiators MUST not subse-quently request data retransmission trough Data SNACK for PDUs num-bered less than ExpDataSN (i.e., prior to the acknowledged sequence number). For all types of commands, a reassignment request implies that the task is still considered in progress by the initiator and the target must conclude the task appropriately if the target returns the "Function Complete" response to the reassignment request. This might possibly involve retransmission of data/R2T/status PDUs as nec-essary, but MUST involve the (re)transmission of the status PDU. == 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: DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the direction it is sent and the total of all the DataSegmentLength of all PDUs in a sequence MUST not exceed MaxBurstLength (or FirstBurst-Length for unsolicited data). However the number of individual PDUs in a sequence (or in total) may be higher than the MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength ratio (as PDUs may be limited in length by the sender capabilities). Using DataSeg-mentLength of 0 may increase beyond what is reasonable the number of PDUs and should therefore be avoided. == 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: 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 necessarily 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 MUST NOT be 0 and MUST not exceed MaxBurstLength. == 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 binary-values 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 binary-values 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, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, i.e., SRP-SHA1) and G,Gn (Gn stands for G1,G2...) are identifiers of SRP groups specified in [SEC-IPS]. G,Gn and U are text strings, s,A,B,M, and H(A | M | K) are binary-values. The length of s,A,B,M and H(A | M | K) in binary form (not the length of the character string that represents them in encoded form) MUST not exceed 1024 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 N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algo-rithm, 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-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 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: TargetName MUST not be redeclared within the login phase. == 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: InitiatorName MUST not be redeclared within the login phase. == Unrecognized Status in ' Category: standards-track', 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: 'ISCSI-REQ' is mentioned on line 98, but not defined == Missing Reference: 'SPC3' is mentioned on line 12101, but not defined -- Looks like a reference, but probably isn't: '7' on line 5799 -- Looks like a reference, but probably isn't: '0' on line 5798 == Missing Reference: 'SPC' is mentioned on line 7132, but not defined == Missing Reference: 'RFC1944' is mentioned on line 8844, but not defined ** Obsolete undefined reference: RFC 1944 (Obsoleted by RFC 2544) == Missing Reference: 'MaxMissingDPDU' is mentioned on line 11172, but not defined == Missing Reference: 'MaxOutStandingR2T' is mentioned on line 11184, but not defined == Missing Reference: 'MaxMissingSPDU' is mentioned on line 11197, but not defined == Missing Reference: 'MaxSupportedConns' is mentioned on line 11207, but not defined == Unused Reference: 'CAM' is defined on line 9933, but no explicit reference was found in the text == Unused Reference: 'OUI' is defined on line 9936, but no explicit reference was found in the text == Unused Reference: 'RFC790' is defined on line 9938, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 9939, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 9941, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 9943, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 9945, but no explicit reference was found in the text == Unused Reference: 'RFC1766' is defined on line 9951, but no explicit reference was found in the text == Unused Reference: 'RFC1964' is defined on line 9953, but no explicit reference was found in the text == Unused Reference: 'RFC2044' is defined on line 9963, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 9969, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 9971, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 9977, but no explicit reference was found in the text == Unused Reference: 'RFC2373' is defined on line 9978, but no explicit reference was found in the text == Unused Reference: 'RFC2396' is defined on line 9980, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 9992, but no explicit reference was found in the text == Unused Reference: 'SAM' is defined on line 10001, but no explicit reference was found in the text == Unused Reference: 'CRC' is defined on line 10032, but no explicit reference was found in the text == Unused Reference: 'RFC1602' is defined on line 10040, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 10042, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-ciph-aes-cbc-03 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-ciph-aes-ctr-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'CAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI' -- Possible downref: Non-RFC (?) normative reference: ref. 'OUI' ** Obsolete normative reference: RFC 790 (Obsoleted by RFC 820) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1737 ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SBC' == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-01 == Outdated reference: A later version (-19) exists of draft-ietf-ips-security-09 == Outdated reference: A later version (-07) exists of draft-hoffman-stringprep-00 == Outdated reference: A later version (-06) exists of draft-ietf-ips-iscsi-string-prep-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: A later version (-12) exists of draft-ietf-ips-iscsi-boot-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'Castagnoli93' -- No information found for draft-sheinwald-icsci-crc - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CRC' == Outdated reference: A later version (-10) exists of draft-ietf-ips-iscsi-name-disc-05 ** Downref: Normative reference to an Informational draft: draft-ietf-ips-iscsi-name-disc (ref. 'NDT') ** Obsolete normative reference: RFC 1602 (Obsoleted by RFC 2026) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 25 errors (**), 0 flaws (~~), 56 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 iSCSI 5-August-02 3 IPS Julian Satran 4 Internet Draft Kalman Meth 5 draft-ietf-ips-iscsi-15.txt IBM 6 Category: standards-track 7 Costa Sapuntzakis 8 Cisco Systems 10 Mallikarjun Chadalapaka 11 Hewlett-Packard Co. 13 Efri Zeidner 14 SANGate 16 iSCSI 18 Julian Satran Expires February 2003 1 19 iSCSI 5-August-02 21 Status of this Memo 23 This document is an Internet-Draft and fully conforms to all provi- 24 sions of Section 10 of [RFC2026]. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for at most six months and 30 may be updated, replaced, or made obsolete by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference mate- 32 rial or to cite them except as "work in progress." 33 The list of Internet-Drafts can be accessed at http://www.ietf.org/ 34 ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The Small Computer Systems Interface (SCSI) is a popular family of 41 protocols for communicating with I/O devices, especially storage 42 devices. This document describes a transport protocol for SCSI that 43 works on top of TCP. The iSCSI protocol aims to be fully compliant 44 with the rules laid out in the SCSI Architecture Model - 2 [SAM2] 45 document. The current version of iSCSI is 0. 47 Acknowledgements 49 This protocol was developed by a design team that, beside the 50 authors, included Daniel Smith, Ofer Biran, Jim Hafner and John 51 Hufferd (IBM), Mark Bakke (Cisco), Randy Haagens (HP), Matt Wakeley 52 (Agilent, now Sierra Logic), Luciano Dalle Ore (Quantum), Paul Von 53 Stamwitz (Adaptec, now TrueSAN Networks). 55 Also, a large group of people contributed to this work through their 56 review, comments and valuable insights. We are grateful to all them. 57 We are especially grateful to those who found the time and patience 58 to take part in our weekly phone conferences and intermediate meet- 59 ings in Almaden and Haifa, so helping to shape this document: Prasen- 60 jit Sarkar, Meir Toledano, John Dowdy, Steve Legg, Alain Azagury 61 (IBM), Dave Nagle (CMU), David Black (EMC), John Matze (Veritas - now 62 Okapi Software), Steve DeGroote, Mark Schrandt (Cisco), Gabi Hecht 63 (Gadzoox), Robert Snively and Brian Forbes (Brocade), Nelson Nachum 65 Julian Satran Expires February 2003 2 66 iSCSI 5-August-02 68 (StorAge), Uri Elzur (Broadcom). Many more helped clean and improve 69 this document within the IPS working group. We are especially grate- 70 ful to David Robinson and Raghavendra Rao (Sun), Charles Monia, 71 Joshua Tseng (Nishan), Somesh Gupta (Silverback), Michael Krause, 72 Pierre Labat, Santosh Rao, Matthew Burbridge, Bob Barry, Robert 73 Elliott, Nick Martin (HP), Stephen Bailey (Sandburst), Steve Senum, 74 Ayman Ghanem, Dave Peterson (Cisco), Barry Reinhold (Trebia Net- 75 works), Bob Russell (UNH), Eddy Quicksall (iVivity, Inc.), Bill Lynn 76 and Michael Fischer (Adaptec), Vince Cavanna, Pat Thaler (Agilent), 77 Jonathan Stone (Stanford), Luben Tuikov (Splentec), Paul Koning 78 (EqualLogic)), Michael Krueger (Windriver), Martins Krikis (Intel), 79 Doug Otis (Sanlight), John Marberg (IBM), Robert Griswold and Bill 80 Moody (Crossroads), Yaron Klein (Sanrad). The recovery chapter was 81 enhanced with help from Stephen Bailey (Sandburst), Somesh Gupta 82 (Silverback) and Venkat Rangan (Rhapsody Networks). Eddy Quicksall 83 contributed some examples and began the Definitions Section. Michael 84 Fischer and Bob Barry started the Acronyms Section. Last, but not 85 least, thanks to Ralph Weber for keeping us in line with T10 (SCSI) 86 standardization. 88 We would like to thank Steve Hetzler for his unwavering support and 89 for coming up with such a good name for the protocol, Micky Rodeh, 90 Jai Menon, Clod Barrera and Andy Bechtolsheim for helping this work 91 happen. 93 In addition to this document, the following must be considered in 94 order to get a full understanding of the iSCSI specification "iSCSI 95 Naming & Discovery"[NDT], "Bootstrapping Clients using the iSCSI Pro- 96 tocol" [BOOT], "Securing Block Storage Protocols over IP"[SEC-IPS] 97 documents as well as "iSCSI Requirements and Design Considerations" 98 [ISCSI-REQ]. 100 The "iSCSI Naming & Discovery" document is authored by: 102 Mark Bakke (Cisco), Jim Hafner, John Hufferd, Kaladhar Voru- 103 ganti (IBM), Marjorie Krueger (Hewlett-Packard). 104 . 106 The "Bootstrapping Clients using the iSCSI Protocol" document is 107 authored by: 109 Prasenjit Sarkar (IBM), Duncan Missimer (HP) and Costa Sapuntz- 110 akis (Cisco). 112 Julian Satran Expires February 2003 3 113 iSCSI 5-August-02 115 The "Bootstrapping Clients using the iSCSI Protocol" document is 116 authored by: 118 Bernard Aboba (Microsoft), Joshua Tseng (Nishan), Jesse Walker 119 (Intel), Venkat Rangan (Rhapsody Networks), Franco Travos- 120 tino (Nortel Networks). 122 The "iSCSI Requirements and Design Considerations" document is 123 authored by: 125 Marjorie Krueger, Randy Haagens (HP), Costa Sapuntzakis and 126 Mark Bakke (Cisco). 128 We are grateful to all of them for their good work and for helping us 129 correlate this document with the ones they produced. 131 Change Log 133 The following changes were made from draft-ietf-ips-iSCSI-14 to 134 draft-ietf-ips-iSCSI-15: 136 - Text cleanup 137 - TargetPortalGroup is a binary string (not a numerical value) 138 - Decimal encoding restricted 139 - Removed BidiInitialR2T 140 - Total text space requirement reduced to 8k 141 - Proposed IANA registry for keys and options 142 - New SNACK code 143 - Added vendor specific digests, authentication methods and 144 keys as well as a way to register them with IANA 145 - changed the words vendor-specific into "private or public 146 extensions" 148 The following changes were made from draft-ietf-ips-iSCSI-13 to 149 draft-ietf-ips-iSCSI-14: 151 - Text cleanup 152 - Clarification on COLD RESET - required by SAM 153 - fixed in 9.5 recommendation on empty data (was inconsistent 154 with R2T) 155 - 9.4.6.2 text refers only to firstburstsize changed error code 156 to "incorrect amount of data" 157 - changed size to length everywhere 158 - Reinstated I bit in text request (typo) 159 - StatSN is retransmitted R2T should be the new value 161 Julian Satran Expires February 2003 4 162 iSCSI 5-August-02 164 - Fixed DefaultTime2Wait and changed selection function format 165 in Section 11 167 The following changes were made from draft-ietf-ips-iSCSI-12 to 168 draft-ietf-ips-iSCSI-13: 170 - Text cleanup 171 - Limited decimal encoding to 64 bit integers 172 - Logout Request reason code moved to byte 1 173 - Renamed MaxRecvPDULength to MaxRecvDataSegmentLength 174 - Large Numbers allowed only if explicitly stated 175 - CHAP is the mandatory to implement in-band authentication and 176 SRP is optional 177 - A negotiation answer is permitted only if all key=value pairs 178 are complete. A flag indicates completion. 179 - Clearing effects appendix simplified - SCSI effects are now 180 part of [SPC3] 181 - Made explicit a rule a bout checking when committing a nego- 182 tiation 183 - Added code 4 for Async Message - request negotiation 185 The following changes were made from draft-ietf-ips-iSCSI-11 to 186 draft-ietf-ips-iSCSI-12: 188 - Clarify the use of A bit and DataACK at the end of data 189 - Clarified checking to be done for abort task and removed Ref- 190 erenced task tag from task management response 191 - Range separator is tilde. 192 - Fixed the paragraph numbering in the appendices. 193 - Clarified the expected target behavior in a lost F-bit sce- 194 nario when responding to Abort Task Set/Clear Task Set. 195 - Added the TargetPortalGroupTag key as a Login/operational 196 key, and its usage semantics were added to Section 4.3 Login 197 Phase. 198 - Clarified the language in Section 5.2.2 Allegiance Reassign- 199 ment and Section 5.3 Usage Of Reject PDU in Recovery. 200 - Clarified the states corresponding to full-feature phase 201 operation in connection and session state diagrams in Chap- 202 ter 6. 203 - Delivering all negotiated unsolicited data are mandatory 204 - Delivering all the data for an R2T is mandatory 205 - Added a timeout guidance section to Chapter 8 206 - Added normative naming text (previously in NDT) 207 - Clarified no duplicate parameter for login 208 - Added a minimum required to support to text length (16k/64k) 209 - Changed the name of TSID to TSIH to better reflect its mean- 210 ing 211 - Security - IPsec transport mode is MAY and authentication 212 MUST be used when encryption is used 214 Julian Satran Expires February 2003 5 215 iSCSI 5-August-02 217 - Added to logout a section clarifying the actions to be taken 218 on task termination by the target 219 - Removed CRN 220 - Changed default time2wait & retain to better express typical 221 ratio 222 - Changes SCSI port element separator to comma 223 - Async Event data format same as for SCSI response 225 The following changes were made from draft-ietf-ips-iSCSI-10 to 226 draft-ietf-ips-iSCSI-11: 228 - ACA is SHOULD 229 - New format for ISID that allows factory presets 230 - New wording in section 9.5.5 that makes it clear that initia- 231 tor must discard discontiguous data PDUs during reassignment. 232 - Removed Parameter1 field definition for "drop the session" 233 Async Message. 234 - In state transitions chapter, added Logout timeout to the 235 event set causing T17, and removed the "session close" event 236 from the event set for T6. Changed "status class" to Status- 237 Class. 238 - Clarified that for ErrorRecoveryLevel < 2, a restart Login 239 PDU terminates all the tasks. 240 - Clarified the various subcases of interpretation for 241 Time2Retain and Time2Wait in the Logout Response section. 242 - Added a new section in the recovery chapter on connection 243 timeout management. 244 - The LogoutLoginMinTime and LogoutLoginMaxTime keys are 245 respectively renamed to DefaultTime2Wait and 246 DefaultTime2Retain, because they are used only on non-Logout 247 events and also to better align with the notion of Time2Wait 248 and Time2Retain that the draft already defines. 249 - Added the new Appendix on clearing effects. 250 - Retired the X-bit in Login PDU to make the bit position 251 reserved. Moved the content under X-bit description to a new 252 section 4.3.4 that describes "connection reinstatement". 253 - Added text to section 5.2.2 that clarifies the expectations 254 on targets during allegiance reassignment. 255 - Minor changes in error recovery algorithms to change NextC- 256 mdSN to CmdSN in the Session data structure. 257 - Added a new section 4.3.5 defining the term "session rein- 258 statement". 259 - Added a new transition N11 to target session state diagram, 260 to address the session reinstatement event. Enhancing the 261 event set for N3(T) and N6(I & T) for the same event. Adding 262 the same event to the event sets for target transitions T8, 263 T13, T15, T16, T17, T18, and M2 (I & T). 264 - Addressed the case of active TTTs when ABORT TASK SET/CLEAR 265 TASK SET is in progress in section 9.5 and section 9.6. 267 Julian Satran Expires February 2003 6 268 iSCSI 5-August-02 270 - Added a new Section 9.6.2 Task Management actions on task 271 sets that describes the exact timeline of events on a task 272 set task management function. 273 - Clarified the usage of ITT for DataACK type of SNACK. 274 - Added error code for inexistent session to login response 275 - Changed the FIM SHOULD to should(!) 276 - Added a TTT field for Data-In when A bit is 1 and to the cor- 277 responding SNACK. To make it consistent changed slightly the 278 layout of Data-IN, SCSI Response and SNACK. 279 - Clarified the use of LUN with all PDUs holding TTT 280 - Removed the? value from negotiations 281 - Unified text negotiations (login, ffp and formats) in one 282 chapter 283 - Clarified AHSLength and DataLength for all PDUs 284 - Clarified use of Reject 285 - Replaced Protocol Error with Negotiation Failure in negotia- 286 tions 287 - Removed FFP command before login from Reject Causes 288 - Added Invalid Request During Login to Login Errors 289 - Added tape text 290 - Clarified Security Text 291 - Aligned marker negotiations with the overall negotiations and 292 added numeric range to the negotiation forms 293 - Changed target network architecture example in Overview 294 - Clarified T bit use in Login Reject 295 - Version back to 00 297 Julian Satran Expires February 2003 7 298 iSCSI 5-August-02 300 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . . 2 301 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 302 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . 2 303 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 304 1. Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . .16 305 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . .16 306 1.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . .21 307 1.3 Conventions used in this document . . . . . . . . . . . . . . .23 308 1.3.1 Word Rule . . . . . . . . . . . . . . . . . . . . . . . .23 309 1.3.2 Half-Word Rule . . . . . . . . . . . . . . . . . . . . . .24 310 1.3.3 Byte Rule . . . . . . . . . . . . . . . . . . . . . . . .24 311 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 312 2.1 SCSI Concepts . . . . . . . . . . . . . . . . . . . . . . . . .25 313 2.2 iSCSI Concepts and Functional Overview . . . . . . . . . . . .26 314 2.2.1 Layers and Sessions . . . . . . . . . . . . . . . . . . .26 315 2.2.2 Ordering and iSCSI Numbering . . . . . . . . . . . . . . .27 316 2.2.2.1 Command Numbering and Acknowledging . . . . . . . . .28 317 2.2.2.2 Response/Status Numbering and Acknowledging . . . . .31 318 2.2.2.3 Data Sequencing . . . . . . . . . . . . . . . . . . .32 319 2.2.3 iSCSI Login . . . . . . . . . . . . . . . . . . . . . . .32 320 2.2.4 iSCSI Full Feature Phase . . . . . . . . . . . . . . . . .34 321 2.2.4.1 Command Connection Allegiance . . . . . . . . . . . .34 322 2.2.4.2 Data Transfer Overview . . . . . . . . . . . . . . .35 323 2.2.4.3 Tags and integrity checks . . . . . . . . . . . . . .36 324 2.2.5 iSCSI Connection Termination . . . . . . . . . . . . . . .37 325 2.2.6 iSCSI Names . . . . . . . . . . . . . . . . . . . . . . .37 326 2.2.6.1 iSCSI Name Requirements . . . . . . . . . . . . . . .38 327 2.2.6.2 iSCSI Name Encoding . . . . . . . . . . . . . . . . .40 328 2.2.6.3 iSCSI Name Structure . . . . . . . . . . . . . . . .40 329 2.2.6.3.1 Type "iqn." (iSCSI Qualified Name) . . . . . . .41 330 2.2.6.3.2 Type "eui." (IEEE EUI-64 format) . . . . . . . .42 331 2.2.7 Persistent State . . . . . . . . . . . . . . . . . . . . .43 332 2.2.8 Message Synchronization and Steering . . . . . . . . . . .43 333 2.2.8.1 Sync/Steering and iSCSI PDU Length . . . . . . . . .45 334 2.3 iSCSI Session Types . . . . . . . . . . . . . . . . . . . . . .45 335 2.4 SCSI to iSCSI Concepts Mapping Model . . . . . . . . . . . . .45 336 2.4.1 iSCSI Architecture Model . . . . . . . . . . . . . . . . .46 337 2.4.2 SCSI Architecture Model . . . . . . . . . . . . . . . . .48 338 2.4.3 Consequences of the Model . . . . . . . . . . . . . . . .50 339 2.4.3.1 I_T Nexus State . . . . . . . . . . . . . . . . . . .51 340 2.5 Request/Response Summary . . . . . . . . . . . . . . . . . . .52 341 2.5.1 Request/Response types carrying SCSI payload . . . . . . .52 342 2.5.1.1 SCSI-Command . . . . . . . . . . . . . . . . . . . .52 344 Julian Satran Expires February 2003 8 345 iSCSI 5-August-02 347 2.5.1.2 SCSI-Response . . . . . . . . . . . . . . . . . . . .52 348 2.5.1.3 Task Management Function Request . . . . . . . . . .53 349 2.5.1.4 Task Management Function Response . . . . . . . . . .54 350 2.5.1.5 SCSI Data-out and SCSI Data-in . . . . . . . . . . .54 351 2.5.1.6 Ready To Transfer (R2T) . . . . . . . . . . . . . . .55 352 2.5.2 Requests/Responses carrying SCSI and iSCSI Payload . . . .55 353 2.5.2.1 Asynchronous Message . . . . . . . . . . . . . . . .55 354 2.5.3 Requests/Responses carrying iSCSI Only Payload . . . . . .55 355 2.5.3.1 Text Request and Text Response . . . . . . . . . . .55 356 2.5.3.2 Login Request and Login Response . . . . . . . . . .56 357 2.5.3.3 Logout Request and Response . . . . . . . . . . . . .57 358 2.5.3.4 SNACK Request . . . . . . . . . . . . . . . . . . .57 359 2.5.3.5 Reject . . . . . . . . . . . . . . . . . . . . . . .58 360 2.5.3.6 NOP-Out Request and NOP-In Response . . . . . . . . .58 361 3. SCSI Mode Parameters for iSCSI . . . . . . . . . . . . . . . . . .59 362 4. Login and Full Feature Phase Negotiation . . . . . . . . . . . . .60 363 4.1 Text Format . . . . . . . . . . . . . . . . . . . . . . . . . .61 364 4.2 Text Mode Negotiation . . . . . . . . . . . . . . . . . . . . .64 365 4.2.1 List negotiations . . . . . . . . . . . . . . . . . . . .67 366 4.2.2 Simple-value negotiations . . . . . . . . . . . . . . . .68 367 4.3 Login Phase . . . . . . . . . . . . . . . . . . . . . . . . . .69 368 4.3.1 Login Phase Start . . . . . . . . . . . . . . . . . . . .71 369 4.3.2 iSCSI Security Negotiation . . . . . . . . . . . . . . . .74 370 4.3.3 Operational Parameter Negotiation During the Login Phase .74 371 4.3.4 Connection reinstatement . . . . . . . . . . . . . . . . .75 372 4.3.5 Session reinstatement, closure and timeout . . . . . . . .76 373 4.3.5.1 Loss of Nexus notification . . . . . . . . . . . . .77 374 4.3.6 Session continuation and failure . . . . . . . . . . . . .77 375 4.4 Operational Parameter Negotiation Outside the Login Phase . . .77 376 5. iSCSI Error Handling and Recovery . . . . . . . . . . . . . . . .79 377 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .79 378 5.1.1 Background . . . . . . . . . . . . . . . . . . . . . . . .79 379 5.1.2 Goals and the resulting features . . . . . . . . . . . . .79 380 5.1.3 State expectations . . . . . . . . . . . . . . . . . . . .80 381 5.2 Retry and Reassign in Recovery . . . . . . . . . . . . . . . .81 382 5.2.1 Usage of Retry . . . . . . . . . . . . . . . . . . . . . .81 383 5.2.2 Allegiance Reassignment . . . . . . . . . . . . . . . . .82 384 5.3 Usage Of Reject PDU in Recovery . . . . . . . . . . . . . . . .83 385 5.4 Connection timeout management . . . . . . . . . . . . . . . . .83 386 5.4.1 Timeouts on transport exception events . . . . . . . . . .84 387 5.4.2 Timeouts on planned decommissioning . . . . . . . . . . .84 388 5.5 Implicit termination of tasks . . . . . . . . . . . . . . . . .84 389 5.6 Format Errors . . . . . . . . . . . . . . . . . . . . . . . . .85 391 Julian Satran Expires February 2003 9 392 iSCSI 5-August-02 394 5.7 Digest Errors . . . . . . . . . . . . . . . . . . . . . . . . .85 395 5.8 Sequence Errors . . . . . . . . . . . . . . . . . . . . . . . .87 396 5.9 SCSI Timeouts . . . . . . . . . . . . . . . . . . . . . . . . .88 397 5.10 Negotiation Failures . . . . . . . . . . . . . . . . . . . . .88 398 5.11 Protocol Errors . . . . . . . . . . . . . . . . . . . . . . .89 399 5.12 Connection Failures . . . . . . . . . . . . . . . . . . . . .89 400 5.13 Session Errors . . . . . . . . . . . . . . . . . . . . . . . .90 401 5.14 Recovery Classes . . . . . . . . . . . . . . . . . . . . . . .91 402 5.14.1 Recovery Within-command . . . . . . . . . . . . . . . . .91 403 5.14.2 Recovery Within-connection . . . . . . . . . . . . . . .92 404 5.14.3 Connection Recovery . . . . . . . . . . . . . . . . . . .93 405 5.14.4 Session Recovery . . . . . . . . . . . . . . . . . . . .94 406 5.15 Error Recovery Hierarchy . . . . . . . . . . . . . . . . . . .94 407 6. State Transitions . . . . . . . . . . . . . . . . . . . . . . . .97 408 6.1 Standard Connection State Diagrams . . . . . . . . . . . . . .97 409 6.1.1 State Descriptions for Initiators and Targets . . . . . .97 410 6.1.2 State Transition Descriptions for Initiators and Targets .98 411 6.1.3 Standard Connection State Diagram for an Initiator . . . 102 412 6.1.4 Standard Connection State Diagram for a Target . . . . . 104 413 6.2 Connection Cleanup State Diagram for Initiators and Targets . 106 414 6.2.1 State Descriptions for Initiators and Targets . . . . . 108 415 6.2.2 State Transition Descriptions for Initiators and Targets 108 416 6.3 Session State Diagrams . . . . . . . . . . . . . . . . . . . 110 417 6.3.1 Session State Diagram for a Target . . . . . . . . . . . 111 418 6.3.2 State Descriptions for Initiators and Targets . . . . . 112 419 6.3.3 State Transition Descriptions for Initiators and Targets 113 420 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 115 421 7.1 iSCSI Security Mechanisms . . . . . . . . . . . . . . . . . . 115 422 7.2 In-band Initiator-Target Authentication . . . . . . . . . . . 116 423 7.2.1 CHAP Considerations . . . . . . . . . . . . . . . . . . 117 424 7.2.2 SRP Considerations . . . . . . . . . . . . . . . . . . . 117 425 7.3 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 426 7.3.1 Data Integrity and Authentication . . . . . . . . . . . 118 427 7.3.2 Confidentiality . . . . . . . . . . . . . . . . . . . . 119 428 7.3.3 Policy, Security Associations and Key Management . . . . 119 429 8. Notes to Implementers . . . . . . . . . . . . . . . . . . . . . 121 430 8.1 Multiple Network Adapters . . . . . . . . . . . . . . . . . . 121 431 8.1.1 Conservative Reuse of ISIDs . . . . . . . . . . . . . . 121 432 8.1.2 iSCSI Name, ISID and TPGT Use . . . . . . . . . . . . . 122 433 8.2 Autosense and Auto Contingent Allegiance (ACA) . . . . . . . 124 434 8.3 iSCSI timeouts . . . . . . . . . . . . . . . . . . . . . . . 124 435 8.4 Command Retry and Cleaning Old Command Instances . . . . . . 125 436 8.5 Synch and Steering Layer and Performance . . . . . . . . . . 125 438 Julian Satran Expires February 2003 10 439 iSCSI 5-August-02 441 8.6 Considerations for State-dependent devices and long lasting SCSI 442 operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 443 8.6.1 Determining the proper ErrorRecoveryLevel . . . . . . . 126 444 9. iSCSI PDU Formats . . . . . . . . . . . . . . . . . . . . . . . 128 445 9.1 iSCSI PDU Length and Padding . . . . . . . . . . . . . . . . 128 446 9.2 PDU Template, Header, and Opcodes . . . . . . . . . . . . . . 128 447 9.2.1 Basic Header Segment (BHS) . . . . . . . . . . . . . . . 129 448 9.2.1.1 I . . . . . . . . . . . . . . . . . . . . . . . . . 130 449 9.2.1.2 Opcode . . . . . . . . . . . . . . . . . . . . . . 130 450 9.2.1.3 Final (F) bit . . . . . . . . . . . . . . . . . . . 131 451 9.2.1.4 Opcode-specific Fields . . . . . . . . . . . . . . 131 452 9.2.1.5 TotalAHSLength . . . . . . . . . . . . . . . . . . 131 453 9.2.1.6 DataSegmentLength . . . . . . . . . . . . . . . . . 132 454 9.2.1.7 LUN . . . . . . . . . . . . . . . . . . . . . . . . 132 455 9.2.1.8 Initiator Task Tag . . . . . . . . . . . . . . . . 132 456 9.2.2 Additional Header Segment (AHS) . . . . . . . . . . . . 132 457 9.2.2.1 AHSType . . . . . . . . . . . . . . . . . . . . . . 132 458 9.2.2.2 AHSLength . . . . . . . . . . . . . . . . . . . . . 133 459 9.2.2.3 Extended CDB AHS . . . . . . . . . . . . . . . . . 133 460 9.2.2.4 Bidirectional Expected Read-Data Length AHS . . . . 133 461 9.2.3 Header Digest and Data Digest . . . . . . . . . . . . . 134 462 9.2.4 Data Segment . . . . . . . . . . . . . . . . . . . . . . 134 463 9.3 SCSI Command . . . . . . . . . . . . . . . . . . . . . . . . . 135 464 9.3.1 Flags and Task Attributes (byte 1) . . . . . . . . . . . 135 465 9.3.2 CmdSN - Command Sequence Number . . . . . . . . . . . . 136 466 9.3.3 ExpStatSN . . . . . . . . . . . . . . . . . . . . . . . 136 467 9.3.4 Expected Data Transfer Length . . . . . . . . . . . . . 136 468 9.3.5 CDB - SCSI Command Descriptor Block . . . . . . . . . . 137 469 9.3.6 Data Segment - Command Data . . . . . . . . . . . . . . 137 470 9.4 SCSI Response . . . . . . . . . . . . . . . . . . . . . . . . 138 471 9.4.1 Flags (byte 1) . . . . . . . . . . . . . . . . . . . . . 138 472 9.4.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . 139 473 9.4.3 Response . . . . . . . . . . . . . . . . . . . . . . . . 140 474 9.4.4 SNACK Tag . . . . . . . . . . . . . . . . . . . . . . . 140 475 9.4.5 Residual Count . . . . . . . . . . . . . . . . . . . . . 141 476 9.4.6 Bidirectional Read Residual Count . . . . . . . . . . . 141 477 9.4.7 Data Segment - Sense and Response Data Segment . . . . . 141 478 9.4.7.1 SenseLength . . . . . . . . . . . . . . . . . . . . 142 479 9.4.7.2 Sense Data . . . . . . . . . . . . . . . . . . . . 142 480 9.4.8 ExpDataSN . . . . . . . . . . . . . . . . . . . . . . . 143 481 9.4.9 StatSN - Status Sequence Number . . . . . . . . . . . . 143 482 9.4.10 ExpCmdSN - Next Expected CmdSN from this Initiator . . 143 483 9.4.11 MaxCmdSN - Maximum CmdSN from this Initiator . . . . . 143 485 Julian Satran Expires February 2003 11 486 iSCSI 5-August-02 488 9.5 Task Management Function Request . . . . . . . . . . . . . . . 145 489 9.5.1 Function . . . . . . . . . . . . . . . . . . . . . . . . 145 490 9.5.2 TotalAHSLength and DataSegmentLength . . . . . . . . . . 148 491 9.5.3 LUN . . . . . . . . . . . . . . . . . . . . . . . . . . 148 492 9.5.4 Referenced Task Tag . . . . . . . . . . . . . . . . . . 148 493 9.5.5 RefCmdSN . . . . . . . . . . . . . . . . . . . . . . . . 148 494 9.5.6 ExpDataSN . . . . . . . . . . . . . . . . . . . . . . . 149 495 9.6 Task Management Function Response . . . . . . . . . . . . . . 150 496 9.6.1 Response . . . . . . . . . . . . . . . . . . . . . . . . 150 497 9.6.2 Task Management actions on task sets . . . . . . . . . . 152 498 9.6.3 TotalAHSLength and DataSegmentLength . . . . . . . . . . 152 499 9.7 SCSI Data-out & SCSI Data-in . . . . . . . . . . . . . . . . . 153 500 9.7.1 F (Final) Bit . . . . . . . . . . . . . . . . . . . . . 155 501 9.7.2 A (Acknowledge) bit . . . . . . . . . . . . . . . . . . 155 502 9.7.3 Flags (byte 1) . . . . . . . . . . . . . . . . . . . . . 156 503 9.7.4 Target Transfer Tag . . . . . . . . . . . . . . . . . . 156 504 9.7.5 DataSN . . . . . . . . . . . . . . . . . . . . . . . . . 157 505 9.7.6 Buffer Offset . . . . . . . . . . . . . . . . . . . . . 157 506 9.7.7 DataSegmentLength . . . . . . . . . . . . . . . . . . . 158 507 9.8 Ready To Transfer (R2T) . . . . . . . . . . . . . . . . . . . 159 508 9.8.1 TotalAHSLength and DataSegmentLength . . . . . . . . . . 160 509 9.8.2 R2TSN . . . . . . . . . . . . . . . . . . . . . . . . . 161 510 9.8.3 StatSN . . . . . . . . . . . . . . . . . . . . . . . . . 161 511 9.8.4 Desired Data Transfer Length and Buffer Offset . . . . . 161 512 9.8.5 Target Transfer Tag . . . . . . . . . . . . . . . . . . 161 513 9.9 Asynchronous Message . . . . . . . . . . . . . . . . . . . . . 162 514 9.9.1 AsyncEvent . . . . . . . . . . . . . . . . . . . . . . . 163 515 9.9.2 AsyncVCode . . . . . . . . . . . . . . . . . . . . . . . 164 516 9.9.3 LUN . . . . . . . . . . . . . . . . . . . . . . . . . . 164 517 9.9.4 Sense Data and iSCSI Event Data . . . . . . . . . . . . 165 518 9.9.4.1 SenseLength . . . . . . . . . . . . . . . . . . . . 165 519 9.10 Text Request . . . . . . . . . . . . . . . . . . . . . . . . 166 520 9.10.1 F (Final) Bit . . . . . . . . . . . . . . . . . . . . . 167 521 9.10.2 C (Continue) Bit . . . . . . . . . . . . . . . . . . . 167 522 9.10.3 Initiator Task Tag . . . . . . . . . . . . . . . . . . 167 523 9.10.4 Target Transfer Tag . . . . . . . . . . . . . . . . . . 167 524 9.10.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . 168 525 9.11 Text Response . . . . . . . . . . . . . . . . . . . . . . . . 170 526 9.11.1 F (Final) Bit . . . . . . . . . . . . . . . . . . . . . 170 527 9.11.2 C (Continue) Bit . . . . . . . . . . . . . . . . . . . 171 528 9.11.3 Initiator Task Tag . . . . . . . . . . . . . . . . . . 171 529 9.11.4 Target Transfer Tag . . . . . . . . . . . . . . . . . . 171 530 9.11.5 StatSN . . . . . . . . . . . . . . . . . . . . . . . . 172 532 Julian Satran Expires February 2003 12 533 iSCSI 5-August-02 535 9.11.6 Text Response Data . . . . . . . . . . . . . . . . . . 172 536 9.12 Login Request . . . . . . . . . . . . . . . . . . . . . . . . 173 537 9.12.1 T (Transit) Bit . . . . . . . . . . . . . . . . . . . . 174 538 9.12.2 C (Continue) Bit . . . . . . . . . . . . . . . . . . . 174 539 9.12.3 CSG and NSG . . . . . . . . . . . . . . . . . . . . . . 174 540 9.12.4 Version . . . . . . . . . . . . . . . . . . . . . . . . 174 541 9.12.4.1 Version-max . . . . . . . . . . . . . . . . . . . 174 542 9.12.4.2 Version-min . . . . . . . . . . . . . . . . . . . 175 543 9.12.5 ISID . . . . . . . . . . . . . . . . . . . . . . . . . 175 544 9.12.6 TSIH . . . . . . . . . . . . . . . . . . . . . . . . . 176 545 9.12.7 Connection ID - CID . . . . . . . . . . . . . . . . . . 176 546 9.12.8 CmdSN . . . . . . . . . . . . . . . . . . . . . . . . . 177 547 9.12.9 ExpStatSN . . . . . . . . . . . . . . . . . . . . . . . 177 548 9.12.10 Login Parameters . . . . . . . . . . . . . . . . . . . 178 549 9.13 Login Response . . . . . . . . . . . . . . . . . . . . . . . 179 550 9.13.1 Version-max . . . . . . . . . . . . . . . . . . . . . . 179 551 9.13.2 Version-active . . . . . . . . . . . . . . . . . . . . 180 552 9.13.3 TSIH . . . . . . . . . . . . . . . . . . . . . . . . . 180 553 9.13.4 StatSN . . . . . . . . . . . . . . . . . . . . . . . . 180 554 9.13.5 Status-Class and Status-Detail . . . . . . . . . . . . 180 555 9.13.6 T (Transit) bit . . . . . . . . . . . . . . . . . . . . 183 556 9.13.7 C (Continue) Bit . . . . . . . . . . . . . . . . . . . 183 557 9.13.8 Login Parameters . . . . . . . . . . . . . . . . . . . 184 558 9.14 Logout Request . . . . . . . . . . . . . . . . . . . . . . . 185 559 9.14.1 Reason Code . . . . . . . . . . . . . . . . . . . . . . 187 560 9.14.2 TotalAHSLength and DataSegmentLength . . . . . . . . . 187 561 9.14.3 CID . . . . . . . . . . . . . . . . . . . . . . . . . . 188 562 9.14.4 ExpStatSN . . . . . . . . . . . . . . . . . . . . . . . 188 563 9.14.5 Implicit termination of tasks . . . . . . . . . . . . . 188 564 9.15 Logout Response . . . . . . . . . . . . . . . . . . . . . . . 189 565 9.15.1 Response . . . . . . . . . . . . . . . . . . . . . . . 189 566 9.15.2 TotalAHSLength and DataSegmentLength . . . . . . . . . 190 567 9.15.3 Time2Wait . . . . . . . . . . . . . . . . . . . . . . . 190 568 9.15.4 Time2Retain . . . . . . . . . . . . . . . . . . . . . . 190 569 9.16 SNACK Request . . . . . . . . . . . . . . . . . . . . . . . 192 570 9.16.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . 193 571 9.16.2 Data Acknowledgement . . . . . . . . . . . . . . . . . 193 572 9.16.3 Resegmentation . . . . . . . . . . . . . . . . . . . . 194 573 9.16.4 Initiator Task Tag . . . . . . . . . . . . . . . . . . 195 574 9.16.5 Target Transfer Tag or SNACK Tag . . . . . . . . . . . 195 575 9.16.6 BegRun . . . . . . . . . . . . . . . . . . . . . . . . 195 576 9.16.7 RunLength . . . . . . . . . . . . . . . . . . . . . . . 195 577 9.17 Reject . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 579 Julian Satran Expires February 2003 13 580 iSCSI 5-August-02 582 9.17.1 Reason . . . . . . . . . . . . . . . . . . . . . . . . 197 583 9.17.2 DataSN . . . . . . . . . . . . . . . . . . . . . . . . 198 584 9.17.3 StatSN, ExpCmdSN and MaxCmdSN . . . . . . . . . . . . . 198 585 9.17.4 Complete Header of Bad PDU . . . . . . . . . . . . . . 198 586 9.18 NOP-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 587 9.18.1 Initiator Task Tag . . . . . . . . . . . . . . . . . . 200 588 9.18.2 Target Transfer Tag . . . . . . . . . . . . . . . . . . 200 589 9.18.3 Ping Data . . . . . . . . . . . . . . . . . . . . . . . 200 590 9.19 NOP-In . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 591 9.19.1 Target Transfer Tag . . . . . . . . . . . . . . . . . . 202 592 9.19.2 StatSN . . . . . . . . . . . . . . . . . . . . . . . . 202 593 9.19.3 LUN . . . . . . . . . . . . . . . . . . . . . . . . . . 202 594 10. iSCSI Security Keys and Authentication Methods . . . . . . . . 203 595 10.1 AuthMethod . . . . . . . . . . . . . . . . . . . . . . . . . 203 596 10.1.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . 205 597 10.1.2 Simple Public-Key Mechanism (SPKM) . . . . . . . . . . 206 598 10.1.3 Secure Remote Password (SRP) . . . . . . . . . . . . . 207 599 10.1.4 Challenge Handshake Authentication Protocol (CHAP) . . 208 600 11. Login/Text Operational Keys . . . . . . . . . . . . . . . . . . 210 601 11.1 HeaderDigest and DataDigest . . . . . . . . . . . . . . . . 210 602 11.2 MaxConnections . . . . . . . . . . . . . . . . . . . . . . . 213 603 11.3 SendTargets . . . . . . . . . . . . . . . . . . . . . . . . 213 604 11.4 TargetName . . . . . . . . . . . . . . . . . . . . . . . . . 213 605 11.5 InitiatorName . . . . . . . . . . . . . . . . . . . . . . . 214 606 11.6 TargetAlias . . . . . . . . . . . . . . . . . . . . . . . . 214 607 11.7 InitiatorAlias . . . . . . . . . . . . . . . . . . . . . . . 215 608 11.8 TargetAddress . . . . . . . . . . . . . . . . . . . . . . . 215 609 11.9 TargetPortalGroupTag . . . . . . . . . . . . . . . . . . . . 216 610 11.10 InitialR2T . . . . . . . . . . . . . . . . . . . . . . . . 216 611 11.11 ImmediateData . . . . . . . . . . . . . . . . . . . . . . . 217 612 11.12 MaxRecvDataSegmentLength . . . . . . . . . . . . . . . . . 218 613 11.13 MaxBurstLength . . . . . . . . . . . . . . . . . . . . . . 219 614 11.14 FirstBurstLength . . . . . . . . . . . . . . . . . . . . . 219 615 11.15 DefaultTime2Wait . . . . . . . . . . . . . . . . . . . . . 219 616 11.16 DefaultTime2Retain . . . . . . . . . . . . . . . . . . . . 220 617 11.17 MaxOutstandingR2T . . . . . . . . . . . . . . . . . . . . . 220 618 11.18 DataPDUInOrder . . . . . . . . . . . . . . . . . . . . . . 221 619 11.19 DataSequenceInOrder . . . . . . . . . . . . . . . . . . . . 221 620 11.20 ErrorRecoveryLevel . . . . . . . . . . . . . . . . . . . . 222 621 11.21 SessionType . . . . . . . . . . . . . . . . . . . . . . . . 222 622 11.22 The Private or Public Extension Key Format . . . . . . . . 223 623 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 225 624 12.1 Naming Requirements . . . . . . . . . . . . . . . . . . . . 226 626 Julian Satran Expires February 2003 14 627 iSCSI 5-August-02 629 12.2 Mechanism Specification Requirements . . . . . . . . . . . . 226 630 12.3 Publication Requirements . . . . . . . . . . . . . . . . . . 227 631 12.4 Security Requirements . . . . . . . . . . . . . . . . . . . 227 632 12.5 Registration Procedure . . . . . . . . . . . . . . . . . . . 227 633 12.5.1 Present the KAD to the Community . . . . . . . . . . . 227 634 12.5.2 KAD review and IESG approval . . . . . . . . . . . . . 227 635 12.5.3 IANA Registration . . . . . . . . . . . . . . . . . . . 228 636 12.5.4 Location of Registered KAD List . . . . . . . . . . . . 228 637 12.6 IANA Procedures for Registering KADs . . . . . . . . . . . . 228 638 References and Bibliography . . . . . . . . . . . . . . . . . . . . 229 639 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 231 640 Appendix A. Sync and Steering with Fixed Interval Markers . . . . . 233 641 A.1 Markers At Fixed Intervals . . . . . . . . . . . . . . . . . 233 642 A.2 Initial Marker-less Interval . . . . . . . . . . . . . . . . 234 643 A.3 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . 234 644 OFMarker, IFMarker 234 645 OFMarkInt, IFMarkInt 235 646 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . 237 647 B.2 Write Operation Example . . . . . . . . . . . . . . . . . . 238 648 B.3 R2TSN/DataSN use Examples . . . . . . . . . . . . . . . . . 238 649 B.4 CRC Examples . . . . . . . . . . . . . . . . . . . . . . . . 242 650 Appendix C. Login Phase Examples . . . . . . . . . . . . . . . . . 244 651 Appendix D. SendTargets Operation . . . . . . . . . . . . . . . . . 253 652 Appendix E. Algorithmic Presentation of Error Recovery Classes . . 258 653 E.2 Within-command Error Recovery Algorithms . . . . . . . . . . 259 654 Procedure Descriptions 259 655 Initiator Algorithms 260 656 Target Algorithms 262 657 E.3 Within-connection Recovery Algorithms . . . . . . . . . . . 265 658 Procedure Descriptions 265 659 Initiator Algorithms 266 660 Target Algorithms 268 661 E.4 Connection Recovery Algorithms . . . . . . . . . . . . . . . 269 662 Procedure Descriptions 269 663 Initiator Algorithms 269 664 Target Algorithms 272 665 Appendix F. Clearing effects of various events on targets . . . . . 275 666 F.1 Clearing effects on iSCSI objects . . . . . . . . . . . . . 275 667 F.2 Clearing effects on SCSI objects . . . . . . . . . . . . . . 280 668 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 282 670 Julian Satran Expires February 2003 15 671 iSCSI 5-August-02 673 1. Definitions and Acronyms 675 1.1 Definitions 677 - Alias: An alias string can also be associated with an iSCSI Node. 678 The alias allows an organization to associate a user-friendly string 679 with the iSCSI Name. However, the alias string is not a substitute 680 for the iSCSI Name. 682 - CID (Connection ID): Connections within a session are identified by 683 a connection ID. It is a unique ID for this connection within the 684 session for the initiator. It is generated by the initiator and pre- 685 sented to the target during login requests and during logouts that 686 close connections. 688 - Connection: A connection is a TCP connection. Communication between 689 the initiator and target occurs over one or more TCP connections. The 690 TCP connections carry control messages, SCSI commands, parameters, 691 and data within iSCSI Protocol Data Units (iSCSI PDUs). 693 - iSCSI Device: A SCSI Device using an iSCSI service delivery sub- 694 system. Service Delivery Subsystem is define by [SAM2] as transport 695 mechanism for SCSI commands and responses. 697 - iSCSI Initiator Name: The iSCSI Initiator Name specifies the world- 698 wide unique name of the initiator. 700 - iSCSI Initiator Node: The "initiator". 702 - iSCSI Layer: This layer builds/receives iSCSI PDUs and relays/ 703 receives them to/from one or more TCP connections that form an initi- 704 ator-target "session". 706 - iSCSI Name: The name of an iSCSI initiator or iSCSI target. 708 - iSCSI Node: The iSCSI Node represents a single iSCSI initiator or 709 iSCSI target. There are one or more iSCSI Nodes within a Network 710 Entity. The iSCSI Node is accessible via one or more Network Por- 711 tals. An iSCSI Node is identified by its iSCSI Name. The separation 712 of the iSCSI Name from the addresses used by and for the iSCSI node 713 allows multiple iSCSI nodes to use the same addresses, and the same 714 iSCSI node to use multiple addresses. 716 Julian Satran Expires February 2003 16 717 iSCSI 5-August-02 719 - iSCSI Target Name: The iSCSI Target Name specifies the worldwide 720 unique name of the target. 722 - iSCSI Target Node: The "target". 724 - iSCSI Task: An iSCSI task is an iSCSI request for which a response 725 is expected. 727 - iSCSI Transfer Direction: The iSCSI transfer direction is defined 728 with regard to the initiator. Outbound or outgoing transfers are 729 transfers from the initiator to the target, while inbound or incoming 730 transfers are from the target to the initiator. 732 - ISID: The initiator part of the Session Identifier. It is explic- 733 itly specified by initiator during Login. 735 - I_T nexus: According to [SAM2], the I_T nexus is a relationship 736 between a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this 737 relationship is a session, defined as a relationship between an iSCSI 738 Initiator's end of the session (SCSI Initiator Port) and the iSCSI 739 Target's Portal Group. The I_T nexus can be identified by the con- 740 junction of the SCSI port names; that is, the I_T nexus identifier is 741 the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name + 742 ',t,'+ Portal Group Tag). 744 - Network Entity: The Network Entity represents a device or gateway 745 that is accessible from the IP network. A Network Entity must have 746 one or more Network Portals, each of which can be used to gain access 747 to the IP network by some iSCSI Nodes contained in that Network 748 Entity. 750 - Network Portal: The Network Portal is a component of a Network 751 Entity that has a TCP/IP network address and that may be used by an 752 iSCSI Node within that Network Entity for the connection(s) within 753 one of its iSCSI sessions. A Network Portal in an initiator is iden- 754 tified by its IP address. A Network Portal in a target is identified 755 by its IP address and its listening TCP port. 757 - Originator - in a negotiation or exchange the party that initiates 758 the negotiation or exchange. 760 Julian Satran Expires February 2003 17 761 iSCSI 5-August-02 763 - PDU (Protocol Data Unit): The initiator and target divide their 764 communications into messages. The term "iSCSI protocol data unit" 765 (iSCSI PDU) is used for these messages. 767 - Portal Groups: iSCSI supports multiple connections within the same 768 session; some implementations will have the ability to combine con- 769 nections in a session across multiple Network Portals. A Portal Group 770 defines a set of Network Portals within an iSCSI Node that collec- 771 tively supports the capability of coordinating a session with connec- 772 tions spanning these portals. Not all Network Portals within a Portal 773 Group need participate in every session connected through that Por- 774 tal Group. One or more Portal Groups may provide access to an iSCSI 775 Node. Each Network Portal as utilized by a given iSCSI Node belongs 776 to exactly one portal group within that node. 778 - Portal Group Tag: This 16 bit bitstring identifies the Portal Group 779 within an iSCSI Node. All Network Portals with the same portal group 780 tag in the context of a given iSCSI Node are in the same Portal 781 Group. 783 - Recovery R2T: An R2T generated by a target upon detecting the loss 784 of one or more Data-Out PDUs through one of the following means - a 785 digest error, a sequence error, or a sequence timeout. A recovery 786 R2T carries the next unused R2TSN, but requests part of or the entire 787 data burst that an earlier R2T (with a lower R2TSN) had already 788 requested 790 - Responder: In a negotiation or exchange, the party that responds to 791 the originator of the negotiation or exchange. 793 - SCSI Device: This is the SAM2 term for an entity that contains one 794 or more SCSI ports that are connected to a service delivery sub- 795 system and supports a SCSI application protocol. For example, a SCSI 796 Initiator Device contains one or more SCSI Initiator Ports and zero 797 or more application clients; a Target Device contains one or more 798 SCSI Target Ports and one or more device servers and associated logi- 799 cal units. For iSCSI, the SCSI Device is the component within an 800 iSCSI Node that provides the SCSI functionality. As such, there can 801 be at most one SCSI Device within a given iSCSI Node. Access to the 802 SCSI Device can only be achieved in an iSCSI normal operational ses- 803 sion. The SCSI Device Name is defined to be the iSCSI Name of the 804 node. 806 Julian Satran Expires February 2003 18 807 iSCSI 5-August-02 809 - SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor 810 Blocks) and relays/receives them with the remaining command execute 811 [SAM2] parameters to/from the iSCSI Layer. 813 - Session: The group of TCP connections that link an initiator with a 814 target form a session (loosely equivalent to a SCSI I-T nexus). TCP 815 connections can be added and removed from a session. Across all con- 816 nections within a session, an initiator sees one and the same target. 818 - SSID (Session ID): A session between an iSCSI initiator and an 819 iSCSI target is defined by a session ID that is a tuple composed of 820 an initiator part (ISID) and a target part (Target Portal Group Tag). 821 The ISID is explicitly specified by the initiator at session estab- 822 lishment. The Target Portal Group Tag is implied by the initiator 823 through the selection of the TCP endpoint at connection establish- 824 ment. The TargetPortalGroupTag key may also be returned by the tar- 825 get as a confirmation during session establishment. 827 - SCSI Initiator Port: This maps to the endpoint of an iSCSI normal 828 operational session. An iSCSI normal operational session is negoti- 829 ated through the login process between an iSCSI initiator node and an 830 iSCSI target node. At successful completion of this process, a SCSI 831 Initiator Port is created within the SCSI Initiator Device. The SCSI 832 Initiator Port Name and SCSI Initiator Port Identifier are both 833 defined to be the iSCSI Initiator Name together with (a) a label that 834 identifies it as an initiator port name/identifier and (b) the ISID 835 portion of the session identifier. 837 - SCSI Port: This is the SAM2 term for an entity in a SCSI Device 838 that provides the SCSI functionality to interface with a service 839 delivery subsystem. For iSCSI, the definition of the SCSI Initiator 840 Port and the SCSI Target Port are different. 842 - SCSI Port Name: A name made up as UTF-8 characters and includes the 843 iSCSI Name + 'i' or 't' + ISID or Portal Group Tag. 845 - SCSI Target Port: This maps to an iSCSI Target Portal Group. 847 - SCSI Target Port Name and SCSI Target Port Identifier: These are 848 both defined to be the iSCSI Target Name together with (a) a label 849 that identifies it as a target port name/identifier and (b) the por- 850 tal group tag. 852 Julian Satran Expires February 2003 19 853 iSCSI 5-August-02 855 - Target Portal Group Tag: a numerical identifier (16 bit) for an 856 iSCSI Target Portal Group 858 - TSIH (Target Session Identifying Handle) is a target assigned tag 859 for a session with a specific named initiator. The target generates 860 it during session establishment and its internal format and content 861 are not defined by this protocol except for the value 0 that is 862 reserved and used by the initiator to indicate a new session. It is 863 given to the target during additional connection establishment for 864 the same session. 866 Julian Satran Expires February 2003 20 867 iSCSI 5-August-02 869 1.2 Acronyms 871 Acronym Definition 872 -------------------------------------------------------------- 873 3DES Triple Data Encryption Standard 874 ACA Auto Contingent Allegiance 875 AEN Asynchronous Event Notification 876 AES Advanced Encryption Standard 877 AH Additional Header (not the IPsec AH!) 878 AHS Additional Header Segment 879 API Application Programming Interface 880 ASC Additional Sense Code 881 ASCII American Standard Code for Information Interchange 882 ASCQ Additional Sense Code Qualifier 883 BHS Basic Header Segment 884 CBC Cipher Block Chaining 885 CDB Command Descriptor Block 886 CHAP Challenge Handshake Authentication Protocol 887 CID Connection ID 888 CO Connection Only 889 CRC Cyclic Redundancy Check 890 CRL Certificate Revocation List 891 CSG Current Stage 892 CSM Connection State Machine 893 DES Data Encryption Standard 894 DNS Domain Name Server 895 DOI Domain of Interpretation 896 ESP Encapsulating Security Payload 897 EUI Extended Unique Identifier 898 FFP Full Feature Phase 899 FFPO Full Feature Phase Only 900 Gbps Gigabits per Second 901 HBA Host Bus Adapter 902 HMAC Hashed Message Authentication Code 903 IANA Internet Assigned Numbers Authority 904 ID Identifier 905 IDN Internationalized Domain Name 906 IEEE Institute of Electrical & Electronics Engineers 907 IETF Internet Engineering Task Force 908 IKE Internet Key Exchange 909 I/O Input - Output 910 IO Initialize Only 911 IP Internet Protocol 913 Julian Satran Expires February 2003 21 914 iSCSI 5-August-02 916 IPsec Internet Protocol Security 917 IPv4 Internet Protocol Version 4 918 IPv6 Internet Protocol Version 6 919 IQN iSCSI Qualified Name 920 ISID Initiator Session ID 921 ITN Initiator Task Name 922 ITT Initiator Task Tag 923 KRB5 Kerberos V5 924 LFL Lower Functional Layer 925 LTDS Logical-Text-Data-Segment 926 LO Leading Only 927 LU Logical Unit 928 LUN Logical Unit Number 929 MAC Message Authentication Codes 930 NA Not Applicable 931 NIC Network Interface Card 932 NOP No Operation 933 NSG Next Stage 934 OS Operating System 935 PDU Protocol Data Unit 936 PKI Public Key Infrastructure 937 R2T Ready To Transfer 938 R2TSN Ready To Transfer Sequence Number 939 RDMA Remote Direct Memory Access 940 SAM SCSI Architecture Model 941 SAM2 SCSI Architecture Model - 2 942 SAN Storage Area Network 943 SCSI Small Computer Systems Interface 944 SN Sequence Number 945 SNACK Selective Negative Acknowledgment - also 946 Sequence Number Acknowledgement for data 947 SPKM Simple Public-Key Mechanism 948 SRP Secure Remote Password 949 SSID Session ID 950 SW Session Wide 951 TCB Task Control Block 952 TCP Transmission Control Protocol 953 TPGT Target Portal Group Tag 954 TSIH Target Session Identifying Handle 955 TTT Target Transfer Tag 956 UFL Upper Functional Layer 957 ULP Upper Level Protocol 958 URN Uniform Resource Names 960 Julian Satran Expires February 2003 22 961 iSCSI 5-August-02 963 UTF Universal Transformation Format 964 WG Working Group 966 1.3 Conventions used in this document 968 In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator 969 and target respectively. 971 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 972 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 973 document are to be interpreted as described in RFC2119. 975 iSCSI messages - PDUs - are represented by diagrams as in the follow- 976 ing example: 978 Byte/ 0 | 1 | 2 | 3 | 979 / | | | | 980 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 981 +---------------+---------------+---------------+---------------+ 982 0| Basic Header Segment (BHS) | 983 +---------------+---------------+---------------+---------------+ 984 ---------- 985 +| | 986 +---------------+---------------+---------------+---------------+ 988 The diagrams include byte and bit numbering. 990 The following representation and ordering rules are observed in this 991 document: 993 - Word Rule 994 - Half-word Rule 995 - Byte Rule 997 1.3.1 Word Rule 999 A word holds 4 consecutive bytes. Whenever a word is having a numeric 1000 content it is considered an unsigned number in base 2 positional rep- 1001 resentation with the lowest numbered byte (e.g., byte 0) bit 0 repre- 1002 senting 2**31, bit 1 representing 2**30 and through Lowest numbered 1003 byte + 3 (e.g., byte 3) bit 7 representing 2**0. 1005 Julian Satran Expires February 2003 23 1006 iSCSI 5-August-02 1008 Decimal and hexadecimal representation of word values map this repre- 1009 sentation to decimal or hexadecimal positional notation. 1011 1.3.2 Half-Word Rule 1013 A half-word holds 2 consecutive bytes. Whenever a half-word is hav- 1014 ing a numeric content it is considered an unsigned number in base 2 1015 positional representation with the lowest numbered byte (e.g., byte 1016 0) bit 0 representing 2**16, bit 1 representing 2**15 and through 1017 Lowest numbered byte + 1 (e.g., byte 1) bit 7 representing 2**0. 1019 Decimal and hexadecimal representation of half-word values map this 1020 representation to decimal or hexadecimal positional notation. 1022 1.3.3 Byte Rule 1024 For every PDU, bytes are sent and received in increasing numbered 1025 order (network order). 1027 Whenever a byte has a numerical content it is considered an unsigned 1028 number in base 2 positional representation with bit 0 representing 1029 2**7, bit 1 representing 2**6 and through bit 7 representing 2**0. 1031 Julian Satran Expires February 2003 24 1032 iSCSI 5-August-02 1034 2. Overview 1036 2.1 SCSI Concepts 1038 The SCSI Architecture Model-2 [SAM2] describes in detail the archi- 1039 tecture of the SCSI family of I/O protocols. This section provides a 1040 brief background of the SCSI architecture and is intended to famil- 1041 iarize readers with its terminology. 1043 At the highest level, SCSI is a family of interfaces for requesting 1044 services from I/O devices, including hard drives, tape drives, CD and 1045 DVD drives, printers, and scanners. In SCSI terminology, an individ- 1046 ual I/O device is called a "logical unit" (LU). 1048 SCSI is a client-server architecture. Clients of a SCSI interface are 1049 called "initiators". Initiators issue SCSI "commands" to request ser- 1050 vice from components, logical units, of a server known as a "tar- 1051 get". The "device server" on the logical unit accepts SCSI commands 1052 and processes them. 1054 A "SCSI transport" maps the client-server SCSI protocol to a spe- 1055 cific interconnect. Initiators are one endpoint of a SCSI transport. 1056 The "target" is the other endpoint. A target can contain multiple 1057 Logical Units (LUs). Each Logical Unit has an address within a tar- 1058 get called a Logical Unit Number (LUN). 1060 A SCSI task is a SCSI command or possibly a linked set of SCSI com- 1061 mands. Some LUs support multiple pending (queued) tasks, but the 1062 queue of tasks is managed by the logical unit. The target uses an 1063 initiator provided "task tag" to distinguish between tasks. Only one 1064 command in a task can be outstanding at any given time. 1066 Each SCSI command results in an optional data phase and a required 1067 response phase. In the data phase, information can travel from the 1068 initiator to target (e.g., WRITE), target to initiator (e.g., READ), 1069 or in both directions. In the response phase, the target returns the 1070 final status of the operation, including any errors. 1072 Command Descriptor Blocks (CDB) are the data structures used to con- 1073 tain the command parameters that an initiator sends to a target. The 1074 CDB content and structure is defined by [SAM2] and device-type spe- 1075 cific SCSI standards. 1077 Julian Satran Expires February 2003 25 1078 iSCSI 5-August-02 1080 2.2 iSCSI Concepts and Functional Overview 1082 The iSCSI protocol is a mapping of the SCSI remote procedure invoca- 1083 tion model (see [SAM2]) over the TCP protocol. SCSI commands are car- 1084 ried by iSCSI requests and SCSI responses and status are carried by 1085 iSCSI responses. iSCSI also uses the request response mechanism for 1086 iSCSI protocol mechanisms. 1088 For the remainder of this document, the terms "initiator" and "tar- 1089 get" refer to "iSCSI initiator node" and "iSCSI target node", respec- 1090 tively (see Section 2.4.1 iSCSI Architecture Model) unless otherwise 1091 qualified. 1093 In keeping with similar protocols, the initiator and target divide 1094 their communications into messages. This document uses the term 1095 "iSCSI protocol data unit" (iSCSI PDU) for these messages. 1097 For performance reasons, iSCSI allows a "phase-collapse". A command 1098 and its associated data may be shipped together from initiator to 1099 target, and data and responses may be shipped together from targets. 1101 The iSCSI transfer direction is defined with respect to the initia- 1102 tor. Outbound or outgoing transfers are transfers from an initiator 1103 to a target, while inbound or incoming transfers are from a target to 1104 an initiator. 1106 An iSCSI task is an iSCSI request for which a response is expected. 1108 In this document "iSCSI request", "iSCSI command", request, or 1109 (unqualified) command have the same meaning. Also, unless otherwise 1110 specified, status, response, or numbered response have the same mean- 1111 ing. 1113 2.2.1 Layers and Sessions 1115 The following conceptual layering model is used to specify initiator 1116 and target actions and how they relate to transmitted and received 1117 Protocol Data Units: 1119 a) the SCSI layer builds/receives SCSI CDBs (Command Descriptor 1120 Blocks) and passes/receives them with the remaining command exe- 1121 cute parameters ([SAM2]) to/from 1123 Julian Satran Expires February 2003 26 1124 iSCSI 5-August-02 1126 b) the iSCSI layer that builds/receives iSCSI PDUs and relays/ 1127 receives them to/from one or more TCP connections; the group of 1128 connections form an initiator-target "session". 1130 Communication between the initiator and target occurs over one or 1131 more TCP connections. The TCP connections carry control messages, 1132 SCSI commands, parameters, and data within iSCSI Protocol Data Units 1133 (iSCSI PDUs). The group of TCP connections that link an initiator 1134 with a target, form a session (loosely equivalent to a SCSI I-T nexus 1135 - see Section 2.4.2 SCSI Architecture Model). A session is defined by 1136 a session ID that is composed of an initiator part and a target part. 1137 TCP connections can be added and removed from a session. Connections 1138 within a session are identified by a connection ID (CID). 1140 Across all connections within a session, an initiator sees one "tar- 1141 get image". All target identifying elements, such as LUN, are the 1142 same. A target also sees one "initiator image" across all connec- 1143 tions within a session. Initiator identifying elements, such as the 1144 Initiator Task Tag, are global across the session regardless of the 1145 connection on which they are sent or received. 1147 iSCSI targets and initiators MUST support at least one TCP connec- 1148 tion and MAY support several connections in a session. For error 1149 recovery purposes, targets and initiators that support a single 1150 active connection in a session SHOULD support two connections during 1151 recovery. 1153 2.2.2 Ordering and iSCSI Numbering 1155 iSCSI uses Command and Status numbering schemes and a Data sequenc- 1156 ing scheme. 1158 Command numbering is session-wide and is used for ordered command 1159 delivery over multiple connections. It can also be used as a mecha- 1160 nism for command flow control over a session. 1162 Status numbering is per connection and is used to enable missing sta- 1163 tus detection and recovery in the presence of transient or permanent 1164 communication errors. 1166 Data sequencing is per command or part of a command (R2T triggered 1167 sequence) and is used to detect missing data and/or R2T PDUs due to 1168 header digest errors. 1170 Julian Satran Expires February 2003 27 1171 iSCSI 5-August-02 1173 Typically, fields in the iSCSI PDUs communicate the Sequence Numbers 1174 between the initiator and target. During periods when traffic on a 1175 connection is unidirectional, iSCSI NOP-Out/In PDUs may be utilized 1176 to synchronize the command and status ordering counters of the tar- 1177 get and initiator. 1179 2.2.2.1 Command Numbering and Acknowledging 1181 iSCSI performs ordered command delivery within a session. All com- 1182 mands (initiator-to-target PDUs) in transit from the initiator to the 1183 target are numbered. 1185 iSCSI considers a task to be instantiated on the target in response 1186 to every request issued by the initiator. An set of task management 1187 operations including abort and reassign (see Section 9.5 Task Manage- 1188 ment Function Request) may be performed on any iSCSI task. Some iSCSI 1189 tasks are SCSI tasks, and many SCSI activities are related to a SCSI 1190 task ([SAM2]). In all cases, the task is identified by the Initiator 1191 Task Tag for the life of the task. 1193 The command number is carried by the iSCSI PDU as CmdSN (Command- 1194 Sequence-Number). The numbering is session-wide. Outgoing iSCSI PDUs 1195 carry this number. The iSCSI initiator allocates CmdSNs with a 32-bit 1196 unsigned counter (modulo 2**32). Comparisons and arithmetic on CmdSN 1197 use Serial Number Arithmetic as defined in [RFC1982] where 1198 SERIAL_BITS = 32. 1200 Commands meant for immediate delivery are marked with an immediate 1201 delivery flag; they MUST also carry the current CmdSN. CmdSN does not 1202 advance after the commands marked for immediate delivery are sent. 1204 Command numbering starts with the first login request on the first 1205 connection of a session (the leading login on the leading connec- 1206 tion) and command numbers are incremented by 1 for every non-immedi- 1207 ate command issued afterwards. 1209 If immediate delivery is used with task management commands, these 1210 commands may reach the target before the tasks on which they are sup- 1211 posed to act. However their CmdSN is as a marker of their position in 1212 the stream of commands. The initiator and target must ensure that the 1213 task management commands act as specified by [SAM2]. For example, 1214 both commands and responses appear as if delivered in order. When- 1216 Julian Satran Expires February 2003 28 1217 iSCSI 5-August-02 1219 ever CmdSN for an outgoing PDU is not specified by an explicit rule, 1220 CmdSN will carry the current value of the local CmdSN variable (see 1221 later in this section). 1223 The means by which an implementation decides to mark a PDU for imme- 1224 diate delivery or by which iSCSI decides by itself to mark a PDU for 1225 immediate delivery are beyond the scope of this document. 1227 The number of commands used for immediate delivery is not limited and 1228 their delivery to execution is not acknowledged through the number- 1229 ing scheme. Immediate commands MAY be rejected by the iSCSI target 1230 layer due to lack of resources. An iSCSI target MUST be able to han- 1231 dle at least one immediate task management command and one immediate 1232 non-task-management iSCSI command per connection at any time. 1234 In this document delivery for execution means delivery to the SCSI 1235 execution engine or an iSCSI protocol specific execution engine 1236 (e.g., for text requests with public or private extension keys 1237 involving an execution component). With the exception of the com- 1238 mands marked for immediate delivery, the iSCSI target layer MUST 1239 deliver the commands for execution in the order specified by CmdSN. 1240 Commands marked for immediate delivery may be delivered by the iSCSI 1241 target layer for execution as soon as detected. iSCSI may avoid 1242 delivering some commands to the SCSI target layer if required by a 1243 prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task Management 1244 request received before all the commands on which it was supposed to 1245 act). 1247 On any connection, the iSCSI initiator MUST send the commands in 1248 increasing order of CmdSN, except for commands that are retransmit- 1249 ted due to digest error recovery and connection recovery. 1251 For the numbering mechanism the initiator and target maintain the 1252 following three variables for each session: 1254 - CmdSN - the current command Sequence Number, advanced by 1 1255 on each command shipped except for commands marked for imme- 1256 diate delivery. CmdSN always contains the number to be 1257 assigned to the next Command PDU. 1258 - ExpCmdSN - the next expected command by the target. The tar- 1259 get acknowledges all commands up to, but not including, this 1260 number. The initiator treats all commands with CmdSN less 1261 than ExpCmdSN as acknowledged. The target iSCSI layer sets 1262 the ExpCmdSN to the largest non-immediate CmdSN that it can 1264 Julian Satran Expires February 2003 29 1265 iSCSI 5-August-02 1267 deliver for execution plus 1 (no holes in the CmdSN 1268 sequence). 1269 - MaxCmdSN - the maximum number to be shipped. The queuing 1270 capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN 1271 + 1. 1273 The initiator's ExpCmdSN and MaxCmdSN are derived from target-to-ini- 1274 tiator PDU fields. Comparisons and arithmetic on ExpCmdSN and MaxC- 1275 mdSN MUST use Serial Number Arithmetic as defined in [RFC1982] where 1276 SERIAL_BITS = 32. 1278 The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1. 1279 For non-immediate commands, the CmdSN field can take any value from 1280 ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any 1281 non-immediate command outside of this range or non-immediate dupli- 1282 cates within the range. Note that the CmdSN carried by immediate com- 1283 mands may lie outside the ExpCmdSN to MaxCmdSN range (e.g., if the 1284 initiator has previously sent a non-immediate command carrying the 1285 CmdSN equal to MaxCmdSN - i.e., target window is closed). For group 1286 task management commands issued as immediate commands CmdSN indi- 1287 cates the scope of the group action (e.g., on ABORT TASK SET - what 1288 commands get aborted). 1290 MaxCmdSN and ExpCmdSN fields are processed by the initiator as fol- 1291 lows: 1293 -If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial 1294 Arithmetic Sense), they are both ignored. 1295 -If the PDU MaxCmdSN is greater than the local MaxCmdSN (in 1296 Serial Arithmetic Sense) it updates the local MaxCmdSN; oth- 1297 erwise, it is ignored. 1298 -If the PDU ExpCmdSN is greater than the local ExpCmdSN (in 1299 Serial Arithmetic Sense) it updates the local ExpCmdSN; oth- 1300 erwise, it is ignored. 1302 This sequence is required because updates may arrive out of order 1303 (e.g., the updates are sent on different TCP connections). 1305 iSCSI initiators and targets MUST support the command numbering 1306 scheme. 1308 A numbered iSCSI request will not change its allocated CmdSN, regard- 1309 less of the number of times and circumstances in which it is reis- 1310 sued (see Section 5.2.1 Usage of Retry). At the target CmdSN is 1311 relevant only while the command has not created any state related to 1313 Julian Satran Expires February 2003 30 1314 iSCSI 5-August-02 1316 its execution (execution state); afterwards, CmdSN becomes irrele- 1317 vant. Testing for the execution state (represented by identifying the 1318 Initiator Task Tag) MUST precede any other action at the target, and 1319 is followed by ordering and delivery if no execution state is found, 1320 or delivery if an execution state is found. 1322 If an initiator issues a command retry for a command with CmdSN R on 1323 a connection when the session CmdSN value is Q, it MUST NOT advance 1324 the CmdSN past R + 2**31 -1 unless the connection is no longer opera- 1325 tional (has returned to the FREE state - see Section 6.1.3 Standard 1326 Connection State Diagram for an Initiator), or the connection has 1327 been reinstated (see Section 4.3.4 Connection reinstatement), or a 1328 non-immediate command with CmdSN equal or greater than Q was issued 1329 subsequent to the command retry on the same connection and the recep- 1330 tion of that command is acknowledged by the target (see Section 8.4 1331 Command Retry and Cleaning Old Command Instances). 1333 A target MUST NOT issue a command response or DATA-In PDU with sta- 1334 tus before acknowledging the command. However, the acknowledgement 1335 can be included in the response or Data-in PDU itself. 1337 2.2.2.2 Response/Status Numbering and Acknowledging 1339 Responses in transit from the target to the initiator are numbered. 1340 The StatSN (Status Sequence Number) is used for this purpose. StatSN 1341 is a counter maintained per connection. ExpStatSN is used by the ini- 1342 tiator to acknowledge status. The status sequence number space is 32- 1343 bit unsigned-integers and the arithmetic operations are the regular 1344 mod(2**32) arithmetic. 1346 Status numbering starts with the Login response to the first Login 1347 request of the connection. The Login response includes an initial 1348 value for status numbering (any initial value is valid). 1350 To enable command recovery, the target MAY maintain enough state 1351 information for data and status recovery after a connection failure. 1352 A target doing so can safely discard all the state information main- 1353 tained for recovery of a command after the delivery of the status for 1354 the command (numbered StatSN) is acknowledged through ExpStatSN. 1356 A large absolute difference between StatSN and ExpStatSN may indi- 1357 cate a failed connection. Initiators MUST undertake recovery actions 1359 Julian Satran Expires February 2003 31 1360 iSCSI 5-August-02 1362 if the difference is greater than an implementation defined constant 1363 that MUST NOT exceed 2**31-1. 1365 Initiators and Targets MUST support the response-numbering scheme. 1367 2.2.2.3 Data Sequencing 1369 Data and R2T PDUs, transferred as part of some command execution, 1370 MUST be sequenced. The DataSN field is used for data sequencing. For 1371 input (read) data PDUs, DataSN starts with 0 for the first data PDU 1372 of an input command and advances by 1 for each subsequent data PDU. 1373 For output data PDUs, DataSN starts with 0 for the first data PDU of 1374 a sequence (the initial unsolicited sequence or any data PDU sequence 1375 issued to satisfy an R2T) and advances by 1 for each subsequent data 1376 PDU. R2Ts are also sequenced per command. For example, the first R2T 1377 has an R2TSN of 0 and advances by 1 for each subsequent R2T. For 1378 bidirectional commands, the target uses the DataSN/R2TSN to sequence 1379 Data-In and R2T PDUs in one continuous sequence (undifferentiated). 1380 Unlike command and status, data PDUs and R2Ts are not acknowledged by 1381 a field in regular outgoing PDUs. Data-In PDUs can be acknowledged on 1382 demand by a special form of the SNACK PDU. Data and R2T PDUs are 1383 implicitly acknowledged by status for the command. The DataSN/R2TSN 1384 field enables the initiator to detect missing data or R2T PDUs. 1386 For any read or bidirectional command, a target MUST issue less than 1387 2**32 combined R2T and Data-In PDUs. Any output data sequence MUST 1388 contain less than 2**32 Data-Out PDUs. 1390 2.2.3 iSCSI Login 1392 The purpose of the iSCSI login is to enable a TCP connection for 1393 iSCSI use, authenticate the parties, negotiate the session's parame- 1394 ters and mark the connection as belonging to an iSCSI session. 1396 A session is used to identify all the connections with a given initi- 1397 ator that belong to the same I_T nexus to a target. (See Section 1398 2.4.2 SCSI Architecture Model for more details on how a session 1399 relates to an I_T nexus). 1401 The targets listen on a well-known TCP port or other TCP port for 1402 incoming connections. The initiator begins the login process by con- 1403 necting to one of these TCP ports. 1405 Julian Satran Expires February 2003 32 1406 iSCSI 5-August-02 1408 As part of the login process, the initiator and target MAY wish to 1409 authenticate each other and set a security association protocol for 1410 the session. This can occur in many different ways and is subject to 1411 negotiation. 1413 In order to protect the TCP connection, an IPsec security associa- 1414 tion MAY be established before the Login request. Using IPsec secu- 1415 rity for iSCSI is specified in Chapter 7 and in [SEC-IPS]. 1417 The iSCSI Login Phase is carried through Login requests and 1418 responses. Once suitable authentication has occurred and operational 1419 parameters have been set, the initiator may start to send SCSI com- 1420 mands. Security policy for whether and by what means a target chooses 1421 to authorize an initiator is beyond the scope of this document. A 1422 more detailed description of the Login Phase can be found in Chapter 1423 4. 1425 The login PDU includes the ISID part of the session ID (SSID). The 1426 target portal group servicing the login is implied by the selection 1427 of the connection endpoint. For a new session, the TSIH is zero. As 1428 part of the response, the target generates a TSIH. 1430 During session establishment, the target identifies the SCSI initia- 1431 tor port (the "I" in the "I_T nexus") through the value pair (Initia- 1432 torName, ISID) (InitiatorName is described later in this section). 1433 Any persistent state (e.g., persistent reservations) on the target 1434 that is associated with a SCSI initiator port is identified based on 1435 this value pair. Any state associated with the SCSI target port (the 1436 "T" in the "I_T nexus") is identified externally by the TargetName 1437 and portal group tag (see Section 2.4.1 iSCSI Architecture Model). As 1438 ISID is used to identify a persistent state, it is subject to reuse 1439 restrictions (see Section 2.4.3 Consequences of the Model). 1441 Before the Full Feature Phase is established, only Login Request and 1442 Login Response PDUs are allowed. Login requests and responses MUST be 1443 used exclusively during Login. On any connection the login phase MUST 1444 immediately follow TCP connection establishment and a subsequent 1445 Login Phase MUST NOT occur before tearing down a connection. 1447 A target receiving any PDU except a Login request before the Login 1448 phase is started MUST immediately terminate the connection on which 1449 the PDU was received. Once the Login phase has started, if the tar- 1450 get receives any PDU except a Login request, it MUST send a Login 1452 Julian Satran Expires February 2003 33 1453 iSCSI 5-August-02 1455 reject (with Status "invalid during login") and then disconnect; if 1456 the initiator receives any PDU except a Login response, it MUST imme- 1457 diately terminate the connection. 1459 2.2.4 iSCSI Full Feature Phase 1461 Once the initiator is authorized to do so, the iSCSI session is in 1462 the iSCSI Full Feature Phase. A session is in Full Feature Phase 1463 after successfully finishing the Login Phase on the first (leading) 1464 connection of a session. A connection is in Full Feature Phase if the 1465 session is in Full Feature Phase and the connection login has com- 1466 pleted successfully. An iSCSI connection is not in Full Feature Phase 1468 a) when it does not have an established transport connection, 1469 OR 1470 b) when it has a valid transport connection, but a successful 1471 login was not performed or the connection is currently 1472 logged out. 1474 In a normal Full Feature Phase, the initiator may send SCSI commands 1475 and data to the various LUs on the target by encapsulating them in 1476 iSCSI PDUs that go over the established iSCSI session. 1478 2.2.4.1 Command Connection Allegiance 1480 For any iSCSI request issued over a TCP connection, the correspond- 1481 ing response and/or other related PDU(s) MUST be sent over the same 1482 connection. We call this "connection allegiance". If the original 1483 connection fails before the command is completed, the connection 1484 allegiance of the command may be explicitly reassigned to a differ- 1485 ent transport connection as described in detail in Section 5.2 Retry 1486 and Reassign in Recovery. 1488 Thus, if an initiator issues a READ command, the target MUST send the 1489 requested data, if any, followed by the status to the initiator over 1490 the same TCP connection that was used to deliver the SCSI command. If 1491 an initiator issues a WRITE command, the initiator MUST send the 1492 data, if any, for that command over the same TCP connection that was 1493 used to deliver the SCSI command. The target MUST return Ready To 1494 Transfer (R2T), if any, and the status over the same TCP connection 1495 that was used to deliver the SCSI command. Retransmission requests 1496 (SNACK PDUs) and the data and status that they generate MUST also use 1497 the same connection. 1499 Julian Satran Expires February 2003 34 1500 iSCSI 5-August-02 1502 However, consecutive commands that are part of a SCSI linked command- 1503 chain task (see [SAM2]) MAY use different connections. Connection 1504 allegiance is strictly per-command and not per-task. During the iSCSI 1505 Full Feature Phase, the initiator and target MAY interleave unre- 1506 lated SCSI commands, their SCSI Data, and responses over the session. 1508 2.2.4.2 Data Transfer Overview 1510 Outgoing SCSI data (initiator to target user data or command parame- 1511 ters) is sent as either solicited data or unsolicited data. Solic- 1512 ited data are sent in response to R2T PDUs. Unsolicited data can be 1513 sent as part of an iSCSI command PDU ("immediate data") or in sepa- 1514 rate iSCSI data PDUs. 1516 Immediate data are assumed to originate at offset 0 in the initiator 1517 SCSI write-buffer (outgoing data buffer). All other Data PDUs have 1518 the buffer offset set explicitly in the PDU header. 1520 An initiator may send unsolicited data up to FirstBurstLength as 1521 immediate (up to the negotiated maximum PDU length), in a separate 1522 PDU sequence or both. All subsequent data MUST be solicited. The max- 1523 imum length of an individual data PDU or the immediate-part of the 1524 first unsolicited burst MAY be negotiated at login. 1526 Targets receive data in either solicited (R2T) data mode or unsolic- 1527 ited (non-R2T) data mode. The maximum amount of unsolicited data that 1528 can be sent with a command is negotiated at login through the First- 1529 BurstLength key. A target MAY separately enable immediate data 1530 (through the ImmediateData key) without enabling the more general 1531 (separate data PDUs) form of unsolicited data (through the InitialR2T 1532 key). 1534 Unsolicited data on write are meant to reduce the effect of latency 1535 on throughput (no R2T is needed to start sending data). In addition, 1536 immediate data is meant to reduce the protocol overhead (both band- 1537 width and execution time). 1539 An iSCSI initiator MAY choose to send no unsolicited data, only imme- 1540 diate data or FirstBurstLength bytes of unsolicited data with a com- 1541 mand. If any non-immediate unsolicited data is sent, the total 1542 unsolicited data MUST be either FirstBurstLength or all the data if 1543 the total amount is less than the FirstBurstLength. 1545 Julian Satran Expires February 2003 35 1546 iSCSI 5-August-02 1548 It is considered an error for an initiator to send unsolicited data 1549 PDUs to a target that operates in R2T mode (only solicited data are 1550 allowed). It is also an error for an initiator to send more data, 1551 whether immediate or as separate PDUs, than FirstBurstLength. 1553 An initiator MUST honor an R2T data request for a valid outstanding 1554 command (i.e., carrying a valid Initiator Task Tag) and deliver all 1555 the requested data provided the command is supposed to deliver outgo- 1556 ing data and the R2T specifies data within the command bounds. The 1557 initiator actions on receiving an R2T request that specifies data all 1558 or part outside the command bounds is unspecified. 1560 A target SHOULD NOT silently discard data and then request retrans- 1561 mission through R2T. Initiators SHOULD NOT keep track of the data 1562 transferred to or from the target (scoreboarding). SCSI targets per- 1563 form residual count calculation to tell how much data was actually 1564 transferred to or from the device by a command; this may differ from 1565 the amount the initiator sent and/or received for reasons such as 1566 retransmissions and errors. Read or bidirectional command implicitly 1567 solicit the transmission of the entire amount of data covered by the 1568 command. SCSI data packets are matched to their corresponding SCSI 1569 commands by using tags specified in the protocol. 1571 iSCSI initiators and targets MUST also enforce some ordering rules. 1572 When unsolicited data is used the order of the unsolicited data on 1573 each connection MUST match the order in which the commands on that 1574 connection are sent. Command and unsolicited data PDUs may be inter- 1575 leaved on a single connection as long as the ordering requirements of 1576 each are maintained (e.g., command N+1 MAY be sent before the unso- 1577 licited Data-Out PDUs for command N, but the unsolicited Data-Out 1578 PDUs for command N MUST precede the unsolicited Data-Out PDUs of com- 1579 mand N+1). A target that receives data out of order MAY terminate the 1580 session. 1582 2.2.4.3 Tags and integrity checks 1584 Initiator tags for pending commands are unique initiator-wide for a 1585 session. Target tags are not strictly specified by the protocol. It 1586 is assumed that target tags are used by the target to tag (alone or 1587 in combination with the LUN) the solicited data. Target tags are gen- 1588 erated by the target and "echoed" by the initiator. These mechanisms 1589 are designed to accomplish efficient data delivery along a large 1590 degree of control over the data flow. 1592 Julian Satran Expires February 2003 36 1593 iSCSI 5-August-02 1595 As the Initiator Task Tag is used to identify a task during its exe- 1596 cution the iSCSI initiator and target MUST verify that all other 1597 fields used in task related PDUs have values are consistent with the 1598 values used at task instantiation based on Initiator Task Tag (e.g., 1599 the LUN used in an R2T PDU MUST be the same as the one used in the 1600 SCSI command PDU used to instantiate the task). Using inconsistent 1601 field values is considered a protocol error. 1603 2.2.5 iSCSI Connection Termination 1605 An iSCSI connection may be terminated by use of a transport connec- 1606 tion shutdown, or a transport reset. Transport reset is assumed to be 1607 an exceptional event. 1609 Graceful TCP connection shutdowns are done by sending TCP FINs. A 1610 graceful transport connection shutdown SHOULD be initiated by either 1611 party only when the connection is not in iSCSI Full Feature Phase. A 1612 target MAY terminate a Full Feature Phase connection on internal 1613 exception events, but it SHOULD announce the fact through an Asyn- 1614 chronous Message PDU. Connection termination with outstanding com- 1615 mands may require recovery actions. 1617 If a connection is terminated while in Full Feature Phase, connec- 1618 tion cleanup (section 6) is required prior to recovery. By doing con- 1619 nection cleanup before starting recovery, the initiator and target 1620 will avoid receiving stale PDUs after recovery. 1622 2.2.6 iSCSI Names 1624 Both targets and initiators require names for the purpose of identi- 1625 fication. In addition names enable iSCSI storage resources to be man- 1626 aged regardless of location (address). An iSCSI node name is also the 1627 SCSI device name of an iSCSI device. The iSCSI name of a SCSI device 1628 is the principal object used in authentication of targets to initia- 1629 tors and initiators to targets. This name is also used to identify 1630 and manage iSCSI storage resources. 1632 iSCSI names must be unique within the operation domain of the end 1633 user. However, because the operation domain of an IP network is 1634 potentially worldwide, the iSCSI name formats are architected to be 1635 worldwide unique. To assist naming authorities in the construction of 1636 worldwide unique names, iSCSI provides two name formats for differ- 1637 ent types of naming authorities. 1639 Julian Satran Expires February 2003 37 1640 iSCSI 5-August-02 1642 iSCSI names are associated with iSCSI nodes, not iSCSI network 1643 adapter cards, to ensure the replacement of network adapter cards 1644 does not require reconfiguration of all SCSI and iSCSI resource allo- 1645 cation information. 1647 Some SCSI commands require that protocol-specific identifiers be com- 1648 municated within SCSI CDBs. See Section 2.4.2 SCSI Architecture Model 1649 for the definition of the SCSI port name/identifier for iSCSI ports. 1651 An initiator may discover the iSCSI Target Names to which it has 1652 access, along with their addresses, using the SendTargets text 1653 request, or other techniques discussed in [NDT]. 1655 2.2.6.1 iSCSI Name Requirements 1657 Each iSCSI node, whether an initiator or target, MUST have an iSCSI 1658 name. 1660 Initiators and targets MUST support the receipt of iSCSI names of up 1661 to the maximum length of 223 bytes. 1663 The initiator MUST present both its iSCSI Initiator Name and the 1664 iSCSI Target Name to which it wishes to connect in the first login 1665 request of a new session or connection. The only exception is if a 1666 discovery session (see Section 2.3 iSCSI Session Types) is to be 1667 established; the iSCSI Initiator Name is still required, but the 1668 iSCSI Target Name MAY be omitted. 1670 iSCSI names MUST adhere to the following requirements: 1672 a) iSCSI names must be globally unique. No two initiators or tar- 1673 gets should have the same name. 1674 b) iSCSI names must be permanent. An iSCSI initiator node or tar- 1675 get node has the same name for its lifetime. 1676 c) iSCSI names do not imply a location or address. An iSCSI ini- 1677 tiator or target can move, or have multiple addresses. A change of 1678 address does not imply a change of name. 1679 d) iSCSI names must not rely on a central name broker; the nam- 1680 ing authority must be distributed. 1681 e) iSCSI names must support integration with existing unique nam- 1682 ing schemes. 1684 Julian Satran Expires February 2003 38 1685 iSCSI 5-August-02 1687 f) iSCSI names must rely on existing naming authorities. iSCSI 1688 does not have to create its own naming authority. 1690 The encoding of an iSCSI name also has some requirements: 1692 a) iSCSI names MUST have a single encoding method when transmit- 1693 ted over various protocols. 1694 b) iSCSI names MUST be relatively simple to compare. The algo- 1695 rithm for comparing two iSCSI names for equivalence MUST not rely 1696 on any external server. 1697 c) iSCSI names MUST be composed of displayable characters only. 1698 iSCSI names should be kept as simple as possible. They MUST pro- 1699 vide for the use of international character sets, and MUST not be 1700 case sensitive. Whitespace characters MUST NOT be used. 1701 d) iSCSI names MUST be transport-friendly. They MUST be trans- 1702 ported using both binary and ASCII-based protocols. 1704 An iSCSI name really names a logical software entity, and is not tied 1705 to a port or other hardware that can be changed. For instance, an 1706 initiator name should name the iSCSI initiator node, not a particu- 1707 lar NIC or HBA. When multiple NICs are used, they should generally 1708 all present the same iSCSI initiator name to the targets, because 1709 they are just paths to the same SCSI layer. In most operating sys- 1710 tems, the named entity is the operating system image. 1712 A target name should similarly not be tied to hardware interfaces 1713 that can be changed. A target name should identify the logical tar- 1714 get, and must be the same for the target regardless of the physical 1715 portion being addressed. This assists iSCSI initiators in determin- 1716 ing that two targets it has discovered are really two paths to the 1717 same target. 1719 The iSCSI name is designed to fulfill the functional requirements for 1720 Uniform Resource Names (URN) [RFC1737]. For example, it is required 1721 that the name have a global scope, independent of address or loca- 1722 tion, and that it be persistent and globally unique. Names must be 1723 extensible, and scale with the use of naming authorities. The encod- 1724 ing of the name should be readable by a human, as well as be machine- 1725 readable. See [RFC1737] for further requirements. 1727 Julian Satran Expires February 2003 39 1728 iSCSI 5-August-02 1730 2.2.6.2 iSCSI Name Encoding 1732 An iSCSI name MUST be a UTF-8 encoding of a string of Unicode charac- 1733 ters, with the following properties: 1735 - it is in Normalization Form C (see "Unicode Normalization 1736 Forms" [UNICODE]) 1737 - it contains only the following characters: 1739 - dash ('-'=U+002d) 1740 - dot ('.'=U+002e) 1741 - colon (':'=U+003a) 1742 - Any character allowed by the output of the iSCSI 1743 stringprep template (described in [STPREP-iSCSI]) 1745 - when encoded in UTF-8, it is no larger than 223 bytes 1747 The stringprep process is described in [STPREP]; iSCSI's use of the 1748 stringprep process is described in [STPREP-iSCSI]. Stringprep is a 1749 method designed by the Internationalized Domain Name (IDN) working 1750 group to translate human-typed strings into a format that can be com- 1751 pared as opaque strings. Strings must not include punctuation, spac- 1752 ing, diacritical marks, or other characters that could get in the way 1753 of readability. The stringprep process also converts strings into 1754 equivalent strings of lower-case characters. 1756 Note that in most cases, the stringprep process does not need to be 1757 implemented if the names are generated using only lower-case (any 1758 character set) alpha-numeric characters. 1760 Once iSCSI names encoded in UTF-8 are "normalized" (there is one and 1761 only one representation for each possible name), they may be safely 1762 compared byte-for-byte. 1764 2.2.6.3 iSCSI Name Structure 1766 An iSCSI name consists of two parts - a type designator followed by a 1767 unique name string. 1769 The iSCSI name does not define any new naming authorities. Instead, 1770 it supports two existing ways of designating naming authorities: an 1771 iSCSI-Qualified Name, using domain names to identify a naming author- 1772 ity, and the EUI format, where the IEEE Registration Authority 1773 assists in the formation of worldwide unique names (EUI-64 format). 1775 Julian Satran Expires February 2003 40 1776 iSCSI 5-August-02 1778 The type designator strings currently defined are: 1780 iqn. - iSCSI Qualified name 1781 eui. - Remainder of the string is an IEEE EUI-64 1782 identifier, in ASCII-encoded hexadecimal. 1784 As these two naming authority designators will suffice in nearly 1785 every case for both software and hardware-based entities, the cre- 1786 ation of additional type designators is prohibited. One of these two 1787 type strings MUST be used when constructing an iSCSI name; any type 1788 string not listed here is not allowed, as they cannot be guaranteed 1789 to be unique. 1791 2.2.6.3.1 Type "iqn." (iSCSI Qualified Name) 1793 This iSCSI name type can be used by any organization which owns a 1794 domain name. This naming format is useful when an end user or ser- 1795 vice provider wishes to assign iSCSI names for targets and/or initia- 1796 tors. 1798 To generate names of this type, the person or organization generat- 1799 ing the name must own a registered domain name. This domain name does 1800 not have to be active, and does not have to resolve to an address; it 1801 just needs to be reserved to prevent others from generating iSCSI 1802 names using the same domain name. 1804 Because a domain name can expire, be acquired by another entity, and 1805 might be used to generate iSCSI names by both owners, the domain name 1806 must be additionally qualified by a date during which the naming 1807 authority owned the domain name. A date code is provided as part of 1808 the "iqn." format for this reason. 1810 The iSCSI qualified name string consists of: 1812 - The string "iqn.", used to distinguish these names from 1813 "eui." formatted names. 1814 - A date code, in yyyy-mm format. This date MUST be a date dur- 1815 ing which the naming authority owned the domain name used in 1816 this format, and SHOULD be the first month in which the 1817 domain name was owned by this naming authority at 00:01 GMT 1818 of the first day of the month. This date code uses the Grego- 1819 rian calendar. All four digits in the year must be present. 1820 Both digits of the month must be present, with January == 1821 "01" and December == "12". The dash must be included. 1823 Julian Satran Expires February 2003 41 1824 iSCSI 5-August-02 1826 - A dot "." 1827 - The reversed domain name of the naming authority (person or 1828 organization) creating this iSCSI name. 1829 - An optional, colon (:) prefixed string, within the character 1830 set and length boundaries, that the owner of the domain name 1831 deems appropriate. This may contain product types, serial 1832 numbers, host identifiers, software keys (e.g, it may include 1833 colons to separate organization boundaries). Except for the 1834 colon prefix everything after the reversed domain name can be 1835 assigned as desired by the owner of the domain name. It is 1836 the responsibility of the entity that is the naming author- 1837 ity to ensure that the iSCSI names it assigns are worldwide 1838 unique. For example, "ACME Storage Arrays, Inc.", might own 1839 the domain name "acme.com". 1841 The following are examples of iSCSI qualified names that might be 1842 generated by "ACME Storage Arrays, Inc." 1844 Naming String defined by 1845 Type Date Auth "acme.com" naming authority 1846 +--++-----+ +------+ +--------------------------------+ 1847 | || | | | | | 1849 iqn.2001-04.com.acme:storage:diskarrays-sn-a8675309 1850 iqn.2001-04.com.acme 1851 iqn.2001-04.com.acme:storage.tape.sys1.xyz 1852 iqn.2001-04.com.acme:storage.tape.sys1.xyz 1854 2.2.6.3.2 Type "eui." (IEEE EUI-64 format) 1856 The IEEE Registration Authority provides a service for assigning glo- 1857 bally unique identifiers [EUI]. The EUI-64 format is used to build a 1858 global identifier in other network protocols - e.g, Fibre Channel 1859 defines a method of encoding it into a WorldWideName. See http:// 1860 standards.ieee.org/regauth/oui/index.shtml - for more information on 1861 registering for EUI identifiers. 1863 The format is "eui." followed by an EUI-64 identifier (16 ASCII- 1864 encoded hexadecimal digits). 1866 Example iSCSI name: 1868 Type EUI-64 identifier (ASCII-encoded hexadecimal) 1869 +--++--------------+ 1870 | || | 1872 Julian Satran Expires February 2003 42 1873 iSCSI 5-August-02 1875 eui.02004567A425678D 1877 The IEEE EUI-64 iSCSI name format might be used when a manufacturer 1878 is already registered with the IEEE Registration Authority and uses 1879 EUI-64 formatted worldwide unique names for its products. 1881 More examples of name construction are discussed in [NDT]. 1883 2.2.7 Persistent State 1885 iSCSI does not require any persistent state maintenance across ses- 1886 sions. However, in some cases, SCSI requires persistent identifica- 1887 tion of the SCSI initiator port name (See Section 2.4.2 SCSI 1888 Architecture Model and Section 2.4.3 Consequences of the Model). 1890 iSCSI sessions do not persist through power cycles and boot opera- 1891 tions. 1893 All iSCSI session and connection parameters are re-initialized on 1894 session and connection creation. 1896 Commands persist beyond connection termination if the session per- 1897 sists and command recovery within the session is supported. However, 1898 when a connection is dropped, command execution, as perceived by 1899 iSCSI (i.e., involving iSCSI protocol exchanges for the affected 1900 task), is suspended until a new allegiance is established by the 1901 'task reassign' task management function. (See Section 9.5 Task Man- 1902 agement Function Request.) 1904 2.2.8 Message Synchronization and Steering 1906 iSCSI presents a mapping of the SCSI protocol onto TCP. This encapsu- 1907 lation is accomplished by sending iSCSI PDUs of varying lengths. 1908 Unfortunately, TCP does not have a built-in mechanism for signaling 1909 message boundaries at the TCP layer. iSCSI overcomes this obstacle by 1910 placing the message length in the iSCSI message header. This serves 1911 to delineate the end of the current message as well as the beginning 1912 of the next message. 1914 In situations where IP packets are delivered in order from the net- 1915 work, iSCSI message framing is not an issue and messages are pro- 1916 cessed one after the other. In the presence of IP packet reordering, 1917 (i.e., frames being dropped) legacy TCP implementations store the 1919 Julian Satran Expires February 2003 43 1920 iSCSI 5-August-02 1922 "out of order" TCP segments in temporary buffers until the missing 1923 TCP segments arrive, upon which the data must be copied to the appli- 1924 cation buffers. In iSCSI, it is desirable to steer the SCSI data 1925 within these out of order TCP segments into the pre-allocated SCSI 1926 buffers rather than store them in temporary buffers. This decreases 1927 the need for dedicated reassembly buffers as well as the latency and 1928 bandwidth related to extra copies. 1930 Relying solely on the "message length" information from the iSCSI 1931 message header may make it impossible to find iSCSI message bound- 1932 aries in subsequent TCP segments due to the loss of a TCP segment 1933 that contains the iSCSI message length. The missing TCP segment(s) 1934 must be received before any of the following segments can be steered 1935 to the correct SCSI buffers (due to the inability to determine the 1936 iSCSI message boundaries). Because these segments cannot be steered 1937 to the correct location, they must be saved in temporary buffers that 1938 must then be copied to the SCSI buffers. 1940 Different schemes can be used to recover synchronization. To make 1941 these schemes work, iSCSI implementations have to make sure that the 1942 appropriate protocol layers are provided with enough information to 1943 implement a synchronization and/or data steering mechanism. One of 1944 these schemes is detailed in Appendix A. - Sync and Steering with 1945 Fixed Interval Markers -. 1947 The Fixed Interval Markers (FIM) scheme works by inserting in the 1948 payload stream at fixed intervals markers that contain the offset to 1949 the start of the next iSCSI PDU. 1951 Under normal circumstances (no PDU loss or data reception out of 1952 order), iSCSI data steering can be accomplished by using the identi- 1953 fying tag and the data offset fields in the iSCSI header as well as 1954 the TCP sequence number from the TCP header. The identifying tag 1955 helps associate the PDU with a SCSI buffer address while the data 1956 offset and TCP sequence number are used to determine the offset 1957 within the buffer. 1959 When the part of the TCP data stream containing an iSCSI PDU header 1960 is delayed or lost markers may be used to minimize the damage as fol- 1961 lows: 1963 - markers indicate where the next iSCSI PDU starts and enable 1964 continued processing when iSCSI headers have to be dropped 1966 Julian Satran Expires February 2003 44 1967 iSCSI 5-August-02 1969 due to data errors discovered at iSCSI level (e.g., iSCSI 1970 header CRC errors) 1971 - markers help minimize the amount of data that has to be kept 1972 by the TCP/iSCSI layer while waiting for a late TCP packet 1973 arrival or recovery as they may help find later iSCSI PDU 1974 headers and use the information contained in those to steer 1975 data to SCSI buffers 1977 2.2.8.1 Sync/Steering and iSCSI PDU Length 1979 When a large iSCSI message is sent, the TCP segment(s) that contain 1980 the iSCSI header may be lost. The remaining TCP segment(s) up to the 1981 next iSCSI message must be buffered (in temporary buffers) because 1982 the iSCSI header that indicates to which SCSI buffers the data are to 1983 be steered was lost. To minimize the amount of buffering, it is rec- 1984 ommended that the iSCSI PDU length be restricted to a small value 1985 (perhaps a few TCP segments in length). During login, each end of the 1986 iSCSI session specifies the maximum iSCSI PDU length it will accept. 1988 2.3 iSCSI Session Types 1990 iSCSI defines two types of sessions: 1992 a) Normal operational session - an unrestricted session. 1993 b) Discovery-session - a session opened only for target discov- 1994 ery; the target MUST ONLY accept text requests with the SendTar- 1995 gets key and a logout request with reason "close the session". All 1996 other requests MUST be rejected. 1998 The session type is defined during login with key=value parameter in 1999 the login command. 2001 2.4 SCSI to iSCSI Concepts Mapping Model 2003 The following diagram shows an example of how multiple iSCSI Nodes 2004 (targets in this case) can coexist within the same Network Entity 2005 and can share Network Portals (IP addresses and TCP ports). Other 2006 more complex configurations are also possible. See Section 2.4.1 2007 iSCSI Architecture Model for detailed descriptions of the components 2008 of these diagrams. 2010 Julian Satran Expires February 2003 45 2011 iSCSI 5-August-02 2013 +-----------------------------------+ 2014 | Network Entity (iSCSI Client) | 2015 | | 2016 | +-------------+ | 2017 | | iSCSI Node | | 2018 | | (Initiator) | | 2019 | +-------------+ | 2020 | | | | 2021 | +--------------+ +--------------+ | 2022 | |Network Portal| |Network Portal| | 2023 | | 10.1.30.4 | | 10.1.40.6 | | 2024 +-+--------------+-+--------------+-+ 2025 | | 2026 | IP Networks | 2027 | | 2028 +-+--------------+-+--------------+-+ 2029 | |Network Portal| |Network Portal| | 2030 | | 10.1.30.21 | | 10.1.40.3 | | 2031 | | TCP Port 3260| | TCP Port 3260| | 2032 | +--------------+ +--------------+ | 2033 | | | | 2034 | ----------------- | 2035 | | | | 2036 | +-------------+ +--------------+ | 2037 | | iSCSI Node | | iSCSI Node | | 2038 | | (Target) | | (Target) | | 2039 | +-------------+ +--------------+ | 2040 | | 2041 | Network Entity (iSCSI Server) | 2042 +-----------------------------------+ 2044 2.4.1 iSCSI Architecture Model 2046 This section describes the part of the iSCSI architecture model that 2047 has the most bearing on the relationship between iSCSI and the SCSI 2048 Architecture Model. 2050 a) Network Entity - represents a device or gateway that is acces- 2051 sible from the IP network. A Network Entity must have one or more 2052 Network Portals (see item d), each of which can be used by some 2053 iSCSI Nodes (see item (b)) contained in that Network Entity to 2054 gain access to the IP network. 2056 Julian Satran Expires February 2003 46 2057 iSCSI 5-August-02 2059 b) iSCSI Node - represents a single iSCSI initiator or iSCSI tar- 2060 get. There are one or more iSCSI Nodes within a Network Entity. 2061 The iSCSI Node is accessible via one or more Network Portals (see 2062 item d). An iSCSI Node is identified by its iSCSI Name (see Sec- 2063 tion 2.2.6 iSCSI Names and Chapter 11). The separation of the 2064 iSCSI Name from the addresses used by and for the iSCSI node 2065 allows multiple iSCSI nodes to use the same addresses, and the 2066 same iSCSI node to use multiple addresses. 2068 c) An alias string may also be associated with an iSCSI Node. The 2069 alias allows an organization to associate a user friendly string 2070 with the iSCSI Name. However, the alias string is not a substi- 2071 tute for the iSCSI Name. 2073 d) Network Portal - a component of a Network Entity that has a 2074 TCP/IP network address and that may be used by an iSCSI Node 2075 within that Network Entity for the connection(s) within one of its 2076 iSCSI sessions. In an initiator, it is identified by its IP 2077 address. In a target, it is identified by its IP address and its 2078 listening TCP port. 2080 e) Portal Groups - iSCSI supports multiple connections within the 2081 same session; some implementations will have the ability to com- 2082 bine connections in a session across multiple Network Portals. A 2083 Portal Group defines a set of Network Portals within an iSCSI Node 2084 that collectively supports the capability of coordinating a ses- 2085 sion with connections that span these portals. Not all Network 2086 Portals within a Portal Group need to participate in every ses- 2087 sion connected through that Portal Group. One or more Portal 2088 Groups may provide access to an iSCSI Node. Each Network Portal, 2089 as utilized by a given iSCSI Node, belongs to exactly one portal 2090 group within that node. Portal Groups are identified within an 2091 iSCSI Node by a portal group tag, a simple unsigned-integer 2092 between 1 and 65535 (see Section 11.3 SendTargets). All Network 2093 Portals with the same portal group tag in the context of a given 2094 iSCSI Node are in the same Portal Group. 2096 Both iSCSI Initiators and iSCSI Targets have portal groups, though 2097 only the iSCSI Target Portal Groups are used directly in the iSCSI 2098 protocol (e.g., in SendTargets). See Section Section 8.1.1 Conser- 2099 vative Reuse of ISIDs for references to the Initiator Portal 2100 Groups. 2102 Julian Satran Expires February 2003 47 2103 iSCSI 5-August-02 2105 f) Portals within a Portal Group should support similar session 2106 parameters - as they may participate in a common session 2108 The following diagram shows an example of one such configuration on a 2109 target and how a session that shares Network Portals within a Portal 2110 Group may be established. 2112 ----------------------------IP Network--------------------- 2113 | | | 2114 +----|---------------|-----+ +----|---------+ 2115 | +---------+ +---------+ | | +---------+ | 2116 | | Network | | Network | | | | Network | | 2117 | | Portal | | Portal | | | | Portal | | 2118 | +--|------+ +---------+ | | +---------+ | 2119 | | | | | | | 2120 | | Portal | | | | Portal | 2121 | | Group 1 | | | | Group 2 | 2122 +--------------------------+ +--------------+ 2123 | | | 2124 +--------|---------------|--------------------|---------------------+ 2125 | | | | | 2126 | +----------------------------+ +-----------------------------+ | 2127 | | iSCSI Session (Target side)| | iSCSI Session (Target side) | | 2128 | | | | | | 2129 | | (TSIH = 56) | | (TSIH = 48) | | 2130 | +----------------------------+ +-----------------------------+ | 2131 | | 2132 | iSCSI Target Node | 2133 | (within Network Entity, not shown) | 2134 +-------------------------------------------------------------------+ 2136 2.4.2 SCSI Architecture Model 2138 This section describes the relationship between the SCSI Architec- 2139 ture Model [SAM2] and constructs of the SCSI device, SCSI port and 2140 I_T nexus, and the iSCSI constructs described in Section 2.4.1 iSCSI 2141 Architecture Model. 2143 This relationship implies implementation requirements in order to 2144 conform to the SAM2 model and other SCSI operational functions. These 2145 requirements are detailed in Section 2.4.3 Consequences of the Model. 2147 Julian Satran Expires February 2003 48 2148 iSCSI 5-August-02 2150 The following list outlines mappings of SCSI architectural elements 2151 to iSCSI. 2153 a) SCSI Device - the SAM2 term for an entity that contains one or 2154 more SCSI ports that are connected to a service delivery sub- 2155 system and supports a SCSI application protocol. For example, a 2156 SCSI Initiator Device contains one or more SCSI Initiator Ports 2157 and zero or more application clients. A SCSI Target Device con- 2158 tains one or more SCSI Target Ports and one or more logical units. 2159 For iSCSI, the SCSI Device is the component within an iSCSI Node 2160 that provides the SCSI functionality. As such, there can be one 2161 SCSI Device, at most, within a iSCSI Node. Access to the SCSI 2162 Device can only be achieved in an iSCSI normal operational ses- 2163 sion (see Section 2.3 iSCSI Session Types). The SCSI Device Name 2164 is defined to be the iSCSI Name of the node and its use is manda- 2165 tory in the iSCSI protocol. 2167 b) SCSI Port - the SAM2 term for an entity in a SCSI Device that 2168 provides the SCSI functionality to interface with a service deliv- 2169 ery subsystem or transport. For iSCSI, the definition of SCSI Ini- 2170 tiator Port and SCSI Target Port are different. 2172 SCSI Initiator Port: This maps to one endpoint of an iSCSI normal 2173 operational session (see Section 2.3 iSCSI Session Types). An 2174 iSCSI normal operational session is negotiated through the login 2175 process between an iSCSI initiator node and an iSCSI target node. 2176 At successful completion of this process, a SCSI Initiator Port is 2177 created within the SCSI Initiator Device. The SCSI Initiator Port 2178 Name and SCSI Initiator Port Identifier are both defined to be the 2179 iSCSI Initiator Name together with (a) a label that identifies it 2180 as an initiator port name/identifier and (b) the ISID portion of 2181 the session identifier. 2183 SCSI Target Port: This maps to an iSCSI Target Portal Group. The 2184 SCSI Target Port Name and the SCSI Target Port Identifier are both 2185 defined to be the iSCSI Target Name together with (a) a label that 2186 identifies it as a target port name/identifier and (b) the portal 2187 group tag. 2189 The SCSI Port Name is mandatory in iSCSI. When used in SCSI param- 2190 eter data, the SCSI port name MUST be encoded as: 2191 - The iSCSI Name in UTF-8 format, followed by 2192 - a comma separator (1 byte), followed by 2194 Julian Satran Expires February 2003 49 2195 iSCSI 5-August-02 2197 - the ASCII character 'i' (for SCSI Initiator Port) or 2198 the ASCII character 't' (for SCSI Target Port), followed 2199 by 2200 - a comma separator (1 byte), followed by 2201 - A hexadecimal representation (see Section 4.1 Text For- 2202 mat) of the ISID (for SCSI initiator port) or the portal 2203 group tag (for SCSI target port) including the initial 0X 2204 and the terminating null. 2206 SCSI port names have a maximum length of 255 bytes. 2208 The ASCII character 'i' or 't' is the label that identi- 2209 fies this port as either a SCSI Initiator Port or a SCSI 2210 Target Port. 2212 c) I_T nexus - a relationship between a SCSI Initiator Port and a 2213 SCSI Target Port, according to [SAM2]. For iSCSI, this relation- 2214 ship is a session, defined as a relationship between an iSCSI Ini- 2215 tiator's end of the session (SCSI Initiator Port) and the iSCSI 2216 Target's Portal Group. The I_T nexus can be identified by the con- 2217 junction of the SCSI port names or by the iSCSI session identi- 2218 fier SSID. iSCSI defines the I_T nexus identifier to be the tuple 2219 (iSCSI Initiator Name + 'i' + ISID, iSCSI Target Name + 't' + Por- 2220 tal Group Tag). 2222 NOTE: The I_T nexus identifier is not equal to the session identi- 2223 fier (SSID). 2225 2.4.3 Consequences of the Model 2227 This section describes implementation and behavioral requirements 2228 that result from the mapping of SCSI constructs to the iSCSI con- 2229 structs defined above. Between a given SCSI initiator port and a 2230 given SCSI target port, only one I_T nexus (session) can exist. No 2231 more than one nexus relationship (parallel nexus) is allowed by 2232 [SAM2}. Therefore, between a given iSCSI initiator node and an iSCSI 2233 target node, at any given time, only one session can exist with the 2234 same session identifier (SSID). 2236 These assumptions lead to the following conclusions and requirements: 2238 ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal 2239 Group (SCSI target port), there can be only one session with a given 2241 Julian Satran Expires February 2003 50 2242 iSCSI 5-August-02 2244 value for ISID that identifies the SCSI initiator port. See Section 2245 9.12.5 ISID. 2247 The structure of the ISID that contains a naming authority component 2248 (see Section 9.12.5 ISID and [NDT]) provides a mechanism to facili- 2249 tate compliance with the ISID rule (See also Section 8.1.1 Conserva- 2250 tive Reuse of ISIDs). 2252 The iSCSI Initiator Node should manage the assignment of ISIDs prior 2253 to session initiation. The "ISID RULE" does not preclude the use of 2254 the same ISID from the same iSCSI Initiator with different Target 2255 Portal Groups on the same iSCSI target or on other iSCSI targets (see 2256 Section 8.1.1 Conservative Reuse of ISIDs). Allowing this would be 2257 analogous to a single SCSI Initiator Port having relationships 2258 (nexus) with multiple SCSI target ports on the same SCSI target 2259 device or SCSI target ports on other SCSI target devices. It is also 2260 possible to have multiple sessions with different ISIDs to the same 2261 Target Portal Group. Each such session would be considered to be with 2262 a different initiator even when the sessions originate from the same 2263 initiator device. The same ISID may be used by a different iSCSI ini- 2264 tiator because it is the iSCSI Name together with the ISID that iden- 2265 tifies the SCSI Initiator Port. 2267 NOTE: A consequence of the ISID RULE and the specification for the 2268 I_T nexus identifier is that two nexus with the same identifier 2269 should never exist at the same time. 2271 TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH at 2272 session creation (when an initiator presents a 0 value at Login). 2273 After being selected, the same TSIH value MUST be used whenever ini- 2274 tiator or target refer to the session and a TSIH is required. 2276 2.4.3.1 I_T Nexus State 2278 Certain nexus relationships contain an explicit state (e.g., initia- 2279 tor-specific mode pages) that may need to be preserved by the device 2280 server [SAM2] in a logical unit through changes or failures in the 2281 iSCSI layer (e.g., session failures). In order for that state to be 2282 restored, the iSCSI initiator should re-establish its session (re- 2283 login) to the same Target Portal Group using the previous ISID. That 2284 is, it should perform session recovery as described in Chapter 5. 2285 This is because the SCSI initiator port identifier and the SCSI tar- 2287 Julian Satran Expires February 2003 51 2288 iSCSI 5-August-02 2290 get port identifier (or relative target port) form the datum that the 2291 SCSI logical unit device server uses to identify the I_T nexus. 2293 2.5 Request/Response Summary 2295 This section lists and briefly describes all the iSCSI PDU types 2296 (request and responses). 2298 All iSCSI PDUs are built as a set of one or more header segments 2299 (basic and auxiliary) and zero or one data segments. The header group 2300 and the data segment may be followed by a CRC (digest). 2302 The basic header segment has a fixed length of 48 bytes. 2304 2.5.1 Request/Response types carrying SCSI payload 2306 2.5.1.1 SCSI-Command 2308 This request carries the SCSI CDB and all the other SCSI execute com- 2309 mand procedure call (see [SAM2]) IN arguments such as task 2310 attributes, Expected Data Transfer Length for one or both transfer 2311 directions (the latter for bidirectional commands), and Task Tag (as 2312 part of the I_T_L_x nexus). The I_T_L nexus is derived by the initia- 2313 tor and target from the LUN field in the request and the I_T nexus 2314 implicit in the session identification. 2316 In addition, the SCSI-command PDU carries information required for 2317 the proper operation of the iSCSI protocol - the command sequence 2318 number (CmdSN) and the expected status number (ExpStatSN) on the con- 2319 nection it is issued. 2321 All or part of the SCSI output (write) data associated with the SCSI 2322 command may be sent as part of the SCSI-Command PDU as a data seg- 2323 ment. 2325 2.5.1.2 SCSI-Response 2327 The SCSI-Response carries all the SCSI execute-command procedure call 2328 (see [SAM2]) OUT arguments and the SCSI execute-command procedure 2329 call return value. 2331 The SCSI-Response contains the residual counts from the operation if 2332 any, and an indication of whether the counts represent an overflow or 2333 an underflow, and the SCSI status if the status is valid or a 2335 Julian Satran Expires February 2003 52 2336 iSCSI 5-August-02 2338 response code (a non-zero return value for the execute-command proce- 2339 dure call) if the status is not valid. 2341 For a valid status that indicates that the command has been pro- 2342 cessed but resulted in a exception (e.g., a SCSI CHECK CONDITION), 2343 the PDU data segment contains the associated sense data. The use of 2344 Autosense ([SAM2]) is REQUIRED by iSCSI. 2346 Some data segment content may also be associated (in the data seg- 2347 ment) with a non-zero response code. 2349 In addition, the SCSI-Response PDU carries information required for 2350 the proper operation of the iSCSI protocol: 2352 - the number of Data-In PDUs that a target has sent (to enable 2353 the initiator to check that all have arrived) 2354 - StatSN, the Status Sequence Number on this connection 2355 - ExpCmdSN the next Expected Command Sequence Number at the 2356 target 2357 - MaxCmdSN, the maximum CmdSN acceptable at the target from 2358 this initiator. 2360 2.5.1.3 Task Management Function Request 2362 The Task Management function request provides an initiator a way to 2363 explicitly control the execution of one or more SCSI Tasks or iSCSI 2364 functions. The PDU carries a function identifier (which task manage- 2365 ment function to perform) and enough information to unequivocally 2366 identify the task or task-set on which to perform the action, even if 2367 the task(s) to act upon has not yet arrived or has been discarded due 2368 to an error. 2370 The referenced tag identifies an individual task if the function 2371 refers to an individual task. 2373 The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is 2374 identified by the LUN and the session identification (the session 2375 identifies an I_T nexus). 2377 For task sets, the CmdSN of the Task Management function request 2378 helps identify the tasks upon which to act, namely all tasks associ- 2379 ated with a LUN and having a CmdSN preceding the Task Management 2380 function request CmdSN. 2382 Julian Satran Expires February 2003 53 2383 iSCSI 5-August-02 2385 The processing of a Task Management function request performed at the 2386 target, (i.e., any coordination between responses to the tasks 2387 affected and the Task Management function request response is done by 2388 the target). 2390 2.5.1.4 Task Management Function Response 2392 The Task Management function response carries an indication of func- 2393 tion completion for a Task Management function request including how 2394 it completed (response and qualifier) and additional information for 2395 failure responses. 2397 After the Task Management response indicating Task Management func- 2398 tion completion, the initiator will not receive any additional 2399 responses from the affected tasks. 2401 2.5.1.5 SCSI Data-out and SCSI Data-in 2403 SCSI Data-out and SCSI Data-in are the main vehicles by which SCSI 2404 data payload is carried between initiator and target. Data payload is 2405 associated with a specific SCSI command through the Initiator Task 2406 Tag. For target convenience, outgoing solicited data also carries a 2407 Target Transfer Tag (copied from R2T) and the LUN. Each PDU contains 2408 the payload length and the data offset relative to the buffer address 2409 contained in the SCSI execute command procedure call. 2411 In each direction, the data transfer is split into "sequences". An 2412 end-of-sequence is indicated by the F bit. 2414 An outgoing sequence is either unsolicited (only the first sequence 2415 can be unsolicited) or is a complete payload sent in response to an 2416 R2T "prompt". 2418 Input sequences are built to enable the direction switching for bidi- 2419 rectional commands. 2421 For input, the target may request positive acknowledgement of input 2422 data. This is limited to sessions that support error recovery and is 2423 implemented through the A bit in the SCSI Data-in PDU header. 2425 Data-in and Data-out PDUs also carry the DataSN to enable the initia- 2426 tor and target to detect missing PDUs (discarded due to an error). 2428 StatSN is also carried by the Data-In PDUs. 2430 Julian Satran Expires February 2003 54 2431 iSCSI 5-August-02 2433 To enable a SCSI command to be processed involving a minimum number 2434 of messages, the last SCSI Data-in PDU passed for a command may also 2435 contain the status if the status indicates termination with no excep- 2436 tions (no sense or response involved). 2438 2.5.1.6 Ready To Transfer (R2T) 2440 R2T is the mechanism by which the SCSI target "requests" the initia- 2441 tor for output data. R2T specifies to the initiator the offset of the 2442 requested data relative to the buffer address from the execute com- 2443 mand procedure call and the length of the solicited data. 2445 To help the SCSI target to associate resulting Data-out with an R2T, 2446 the R2T carries the Target Transfer Tag copied by the initiator in 2447 the solicited SCSI Data-out PDUs. There are no protocol specific 2448 requirements with regard to the value of these tags, but it is 2449 assumed that together with the LUN, they will enable the target to 2450 associate data with an R2T. 2452 R2T also carries information required for proper operation of the 2453 iSCSI protocol, such as: 2455 - R2TSN (to enable an initiator to detect a missing R2T) 2456 - StatSN 2457 - ExpCmdSN 2458 - MaxCmdSN 2460 2.5.2 Requests/Responses carrying SCSI and iSCSI Payload 2462 2.5.2.1 Asynchronous Message 2464 Asynchronous Messages are used to carry SCSI asynchronous events 2465 (AEN) and iSCSI asynchronous messages. 2467 When carrying an AEN, the event details are reported as sense data in 2468 the data segment. 2470 2.5.3 Requests/Responses carrying iSCSI Only Payload 2472 2.5.3.1 Text Request and Text Response 2474 Text requests and responses are designed as a parameter negotiation 2475 vehicle and as a vehicle for future extension. 2477 Julian Satran Expires February 2003 55 2478 iSCSI 5-August-02 2480 In the data segment key=value, Text Requests/Responses carry text 2481 information with a simple syntax. 2483 Text Request/Responses may form extended sequences using the same 2484 Initiator Task Tag. The initiator uses the F (Final) flag bit in the 2485 text request header to indicate its readiness to terminate a 2486 sequence. The target uses the F (Final) flag bit in the text response 2487 header to indicate its consent to sequence termination. 2489 Text Request and Responses also use the Target Transfer Tag to indi- 2490 cate continuation of an operation or a new beginning. A target that 2491 wishes to continue an operation will set the Target Transfer Tag in a 2492 Text Response to a value different from the default 0xffffffff. An 2493 initiator willing to continue will copy this value into the Target 2494 Transfer Tag of the next Text Request. If the initiator wants to 2495 reset the target (start fresh) it will set the Target Transfer Tag to 2496 0xffffffff. 2498 Although a complete exchange is always started by the initiator, spe- 2499 cific parameter negotiations may be initiated by the initiator or 2500 target. 2502 2.5.3.2 Login Request and Login Response 2504 Login Requests and Responses are used exclusively during the Login 2505 Phase of each connection to set up the session and connection parame- 2506 ters (the Login Phase consists of a sequence of login requests and 2507 responses carrying the same Initiator Task Tag). 2509 A connection is identified by an arbitrarily selected connection-ID 2510 (CID) that is unique within a session. 2512 Similar to the Text Requests and Responses, Login Requests/Responses 2513 carry key=value text information with a simple syntax in the data 2514 segment. 2516 The Login Phase proceeds through several stages (security negotia- 2517 tion, operational parameter negotiation) that are selected with two 2518 binary coded fields in the header - the "current stage" (CSG) and the 2519 "next stage" (NSG) with the appearance of the latter being signaled 2520 by the "transit" flag (T). 2522 Julian Satran Expires February 2003 56 2523 iSCSI 5-August-02 2525 The first Login Phase of a session plays a special role (it is called 2526 the leading login) and some header fields are determined by the lead- 2527 ing login (e.g., the version number, the maximum number of connec- 2528 tions, the session identification). 2530 The CmdSN initial value is also set by the leading login. 2532 Status counting for each connection is initiated by the connection 2533 login. 2535 A login request may indicate an implied logout (cleanup) of the con- 2536 nection to be logged in (we call this a connection restart) by using 2537 the same Connection ID (CID) as an existing connection, in the login 2538 request header, as well as the same session identifying elements of 2539 the session to which the old connection was associated. 2541 2.5.3.3 Logout Request and Response 2543 Logout Requests and Responses are used for the orderly closing of 2544 connections for recovery or maintenance. The logout request may be 2545 issued following a target prompt (through an asynchronous message) or 2546 at an initiators initiative. When issued on the connection to be 2547 logged out no other request may follow it. 2549 The Logout response indicates that the connection or session cleanup 2550 is completed and no other responses will arrive on the connection (if 2551 received on the logging-out connection). The Logout Response indi- 2552 cates also how long the target will keep on holding resources for 2553 recovery (e.g., command execution that continues on a new connec- 2554 tion) in the text key Time2Retain and how long the initiator must 2555 wait before proceeding with recovery in the text key Time2Wait. 2557 2.5.3.4 SNACK Request 2559 With the SNACK Request, the initiator requests retransmission of num- 2560 bered-responses or data from the target. A single SNACK request cov- 2561 ers a contiguous set of missing items, called a run, of a given type 2562 of items (the type is indicated in a type field in the PDU header). 2563 The run is composed of an initial item (StatSN, DataSN, R2TSN) and 2564 the number of missed Status, Data, or R2T PDUs. For long data-in 2565 sequences, the target may request (at predefined minimum intervals) a 2566 positive acknowledgement for the data sent. A SNACK request with a 2567 type field that indicates ACK and the number of Data-In PDUs acknowl- 2568 edged conveys this positive acknowledgement. 2570 Julian Satran Expires February 2003 57 2571 iSCSI 5-August-02 2573 2.5.3.5 Reject 2575 Reject enables the target to report an iSCSI error condition (e.g., 2576 protocol, unsupported option) that uses a Reason field in the PDU 2577 header and includes the complete header of the bad PDU in the Reject 2578 PDU data segment. 2580 2.5.3.6 NOP-Out Request and NOP-In Response 2582 This request/response pair may be used by an initiator and target as 2583 a "ping" mechanism to verify that a connection/session is still 2584 active and all its components are operational. Such a ping may be 2585 triggered by the initiator or target. The triggering party indicates 2586 that it wants a reply by setting a value different from the default 2587 0xffffffff in the corresponding Initiator/Target Transfer Tag. 2589 NOP-In/NOP-Out may also be used "unidirectional" to convey to the 2590 initiator/target command, status or data counter values when there is 2591 no other "carrier" and there is a need to update the initiator/tar- 2592 get. 2594 Julian Satran Expires February 2003 58 2595 iSCSI 5-August-02 2597 3. SCSI Mode Parameters for iSCSI 2599 There are no iSCSI specific mode pages. 2601 Julian Satran Expires February 2003 59 2602 iSCSI 5-August-02 2604 4. Login and Full Feature Phase Negotiation 2606 iSCSI parameters are negotiated at session or connection establish- 2607 ment by using Login Requests and Responses (see Section 2.2.3 iSCSI 2608 Login) and during Full Feature Phase (Section 2.2.4 iSCSI Full Fea- 2609 ture Phase) by using Text Requests and Responses. In both cases the 2610 mechanism used is an exchange of key=value pairs by which the par- 2611 ties either declare the value of a parameter that they expect the 2612 other party to use (a declaration) or one of the parties (the propos- 2613 ing party) proposes a value or set of values based on which the other 2614 party (the accepting party) makes a selection. For most of the param- 2615 eters both the initiator and target can be proposing parties. 2617 During the Login process one proceeds in two stages - the security 2618 negotiation stage and the operational parameter negotiation stage. 2619 Both stages are optional but at least one of them has to be present 2620 to enable setting some mandatory parameters. 2622 If present the security negotiation stage precedes the operational 2623 parameter negotiation stage. 2625 Progression from stage to stage is controlled by the T (Transition) 2626 bit in the Login Request/Response PDU header. Through the T bit set 2627 to 1 the initiator indicates that it would like to transition and the 2628 target agrees to the transition (and selects the next stage) when 2629 ready. A field in the Login PDU header indicates the current stage 2630 (CSG) and during transition another field indicates the next stage 2631 (NSG) proposed (initiator) and selected (target). 2633 The Text negotiation process is used to negotiate or just declare 2634 operational parameters. The negotiation process is controlled by the 2635 F (final) bit in the PDU header. During text negotiations the F bit 2636 is used by the initiator to indicate that it is ready to finish the 2637 negotiation and by the Target to acquiesce the end of negotiation. 2639 Since some key=value pairs may not fit entirely in a single PDU the C 2640 (continuation) bit is used (both in Login and Text) to indicate that 2641 "more follows". 2643 The text negotiation uses an additional mechanism by which a target 2644 may deliver larger amounts of data to an enquiring initiator - the 2645 target sets a Target Task Tag to be used as a bookmark; when returned 2647 Julian Satran Expires February 2003 60 2648 iSCSI 5-August-02 2650 by the initiator it means "go on", if reset to a "neutral value" it 2651 means "forget about the rest". 2653 This chapter details types of keys and values used, the syntax rules 2654 for parameter formation and the negotiation schemes to be used with 2655 different types of parameters. 2657 4.1 Text Format 2659 The initiator and target send a set of key=value pairs encoded in 2660 UTF-8 Unicode. All the text keys and text values specified in this 2661 document are to be presented and interpreted in the case they appear 2662 in this document. They are case sensitive. 2664 The following character symbols are used in this document for text 2665 items (the hexadecimal values represent Unicode code points): 2667 (a-z, A-Z) - letters 2668 (0-9) - digits 2669 " " (0x20) - space 2670 "." (0x2e) - dot 2671 "-" (0x2d) - minus 2672 "+" (0x2b) - plus 2673 "@" (0x40) - commercial at 2674 "_" (0x5f) - underscore 2675 "=" (0x3d) - equal 2676 ":" (0x3a) - colon 2677 "/" (0x2f) - solidus or slash 2678 "[" (0x5b) - left bracket 2679 "]" (0x5d) - right bracket 2680 null (0x00) - null separator 2681 "," (0x2c) - comma 2682 "~" (0x7e) - tilde 2684 Key=value pairs may span PDU boundaries. An initiator or target that 2685 sends partial key=value text within a PDU indicates that more text 2686 follows by setting the C bit in the Text or Login Request or Text or 2687 Login Response to 1. Data segments in a series of PDUs having the C 2688 bit set to 1 and ending with a PDU having the C bit set to 0 or 2689 including a single PDU having the C bit set to 0 have to be consid- 2690 ered as forming a single logical-text-data-segment (LTDS). 2692 Julian Satran Expires February 2003 61 2693 iSCSI 5-August-02 2695 Every key=value pair, including the last or only pair in a LTDS, MUST 2696 be followed by one null (0x00) delimiter. 2698 A key-name is whatever precedes the first = in the key=value pair. 2699 The term key is used frequently in this document with the meaning of 2700 key-name. 2702 A value is whatever follows the first = in the key=value pair up to 2703 the end of the key=value pair but not including the null delimiter. 2705 The following definitions will be used in the rest of this document: 2707 standard-label: a string of one or more characters consisting 2708 of letters, digits, dot, minus, plus, commercial at, and 2709 underscore. A standard-label MUST begin with a capital let- 2710 ter and must not exceed 63 characters. 2712 key-name: a standard-label. 2714 text-value: a string of 0 or more characters consisting of let- 2715 ters, digits, dot, minus, plus, commercial at, underscore, 2716 slash, left bracket, right bracket and colon. 2718 iSCSI-name-value: a string of one or more characters consist- 2719 ing of minus, dot, colon and any character allowed by the 2720 output of the iSCSI string-prep template as specified in 2721 [STPREP-iSCSI] (see also Section 2.2.6.2 iSCSI Name Encod- 2722 ing). 2724 iSCSI-local-name-value: a UTF-8 string; no null characters are 2725 allowed in the string. This encoding is to be used for local- 2726 ized (internationalized) aliases. 2728 boolean-value: the string "Yes" or "No". 2730 hex-constant: hexadecimal constant encoded as a string start- 2731 ing with "0x" or "0X" followed by 1 or more digits or the 2732 letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants 2733 are used to encode numerical values or binary strings. When 2734 used to encode numerical values the excessive use of leading 2735 0 digits is discouraged. The string following 0X (or 0x) rep- 2736 resents a base16 number starting with the most significant 2737 base16 digit, followed by all other digits in decreasing sig- 2738 nificance order and ending with the least-significant base16 2739 digit. When used to encode binary strings hexadecimal con- 2740 stants have an implicit byte-length that includes 4 bits for 2741 every hexadecimal digit of the constant, including leading 2743 Julian Satran Expires February 2003 62 2744 iSCSI 5-August-02 2746 zeroes (i.e., a hex-constant of n hexadecimal digits has a 2747 byte-length of (the integer part of) (n+1)/2). 2749 decimal-constant: an unsigned decimal number - the digit 0 or a 2750 string of 1 or more digits starting with a non-zero digit. 2751 Decimal-constants are used to encode numerical values or 2752 binary strings. Decimal constants can be used to encode 2753 binary strings only if the stringlength is explicitly speci- 2754 fied. There is no implicit length for decimal strings. Deci- 2755 mal-constant MUST NOT used to for parameter values if those 2756 values are allowed to be equal or greater than 2**64 (numeri- 2757 cal) or for binary strings that allowed be longer than 64 2758 bits. 2760 base64-constant: base64 constant encoded as a string starting 2761 with "0b" or "0B" followed by 1 or more digits or letters or 2762 plus or slash or equal. The encoding is done according to 2763 [RFC2045] and each character, except equal, represents a 2764 base64 digit or a 6-bit binary string. Base64-constants are 2765 used to encode numerical-values or binary strings. When used 2766 to encode numerical values the excessive use of leading 0 2767 digits (encoded a A) is discouraged. The string following 0B 2768 (or 0b) represents a base64 number starting with the most 2769 significant base64 digit, followed by all other digits in 2770 decreasing significance order and ending with the least-sig- 2771 nificant base64 digit; the least significant base64 digit may 2772 be optionally followed by pad digits (encoded as equal) that 2773 are not considered as part of the number. When used to encode 2774 binary strings base64-constants have an implicit byte-length 2775 that includes 6 bits for every character of the constant 2776 excluding trailing equals (i.e., a base64-constant of n 2777 base64 characters excluding the trailing equals has a byte- 2778 length of ((the integer part of) (n*3/4)). Correctly encoded 2779 base64 strings cannot have n values of 1, 5 ... k*4+1. 2781 numerical-value: an unsigned integer always less than 2**64 2782 encoded as a decimal-constant or a hex-constant. Unsigned 2783 integer arithmetic applies to numerical-values. 2785 large-numerical-value: an unsigned integer that can be larger 2786 than or equal to 2**64 encoded as a hex constant, or base64- 2787 constant. Unsigned integer arithmetic applies to large- 2788 numeric-values. 2790 numeric-range: two numerical-values separated by a tilde where 2791 the value to the right of tilde must not be lower that the 2792 value to the left. 2794 Julian Satran Expires February 2003 63 2795 iSCSI 5-August-02 2797 regular-binary-value: a binary string less than 64 bits encoded 2798 as a decimal constant, hex constant or base64-constant. The 2799 length of the string is either specified by the key defini- 2800 tion or is implicit byte-length of the encoded string. 2802 large-binary-value: a binary string longer than 64 bits encoded 2803 as a hex-constant or base64-constant. The length of the 2804 string is either specified by the key definition or is 2805 implicit byte-length of the encoded string. 2807 binary-value: a regular-binary-value or a large-binary-value. 2808 Operations on binary values are key specific. 2810 simple-value: text-value, iSCSI-name-value, boolean-value, 2811 numeric-value, a numeric-range or a binary-value. 2813 list-of-values: a sequence of text-values separated by comma. 2815 If not otherwise specified, the maximum length of a simple-value (not 2816 its encoded representation) is 255 bytes not including the delimiter 2817 (comma or zero byte). 2819 Any iSCSI target or initiator MUST support receiving at least 8192 2820 bytes of key=value data in a negotiation sequence. When proposing or 2821 accepting authentication methods that explicitly require support for 2822 very long authentication items initiator and target MUST support 2823 receiving at least 64 kilobytes of key=value data (e.g, see Appendix 2824 10.1.2 - Simple Public-Key Mechanism (SPKM) - that require support 2825 for public key certificates). 2827 4.2 Text Mode Negotiation 2829 During login, and thereafter, some session or connection parameters 2830 are either declared or negotiated through an exchange of textual 2831 information. 2833 The initiator starts the negotiation and/or declaration through a 2834 Text or Login request and indicates when it is ready for completion 2835 (by setting to 1 and keeping to 1 the F bit in a Text Request or the 2836 T bit in the Login Request). As negotiation text may span PDU bound- 2837 aries a Text or Login Request or Text or Login Response PDU having 2838 the C bit set to 1 MUST NOT have the F/T bit set to 1. 2840 A target receiving a Text or Login Request or an initiator receiving 2841 a Text or Login Response with the C bit set to 1 MUST answer with a 2843 Julian Satran Expires February 2003 64 2844 iSCSI 5-August-02 2846 Text or Login Response respectively Text or Login Request with no 2847 data segment (DataSegmentLength 0). 2849 A target or initiator SHOULD NOT use a Text or Login Response or Text 2850 or Login Request with no data segment (DataSegmentLength 0) unless 2851 explicitly required by a general or a key-specific negotiation rule. 2853 The format of a declaration is: 2855 Declarer-> = 2857 The general format of text negotiation is: 2859 Proposer-> = 2860 Acceptor-> =|NotUnderstood|Irrelevant|Reject 2862 Thus a declaration is a one-way textual exchange while a negotiation 2863 is a two-way exchange. 2865 The proposer or declarer can either be the initiator or the target 2866 and the acceptor can either be the target or initiator, respec- 2867 tively. Targets are not limited to respond to key=value pairs as pro- 2868 posed by the initiator. The target may propose key=value pairs of its 2869 own. 2871 All negotiations are explicit (i.e., the result MUST be based only on 2872 newly exchanged or declared values). There are no implicit propos- 2873 als. If an proposal is not made then a reply cannot be expected. Con- 2874 servative design requires also that default values should not be 2875 relied upon when use of some other value has serious consequences. 2877 The value proposed or declared can be a numerical-value, a numerical- 2878 range defined by lower and upper value with both integers separated 2879 by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSI- 2880 local-name-value, a boolean-value (Yes or No), or a list of comma 2881 separated text-values. A range, a large-numerical-value, an iSCSI- 2882 name-value and an iSCSI-local-name-value MAY ONLY be used if it is 2883 explicitly allowed. An accepted value can be a numerical-value, a 2884 large-numerical-value, a text-value or a boolean-value. 2886 If a specific key is not relevant for the current negotiation, the 2887 acceptor may answer with the constant "Irrelevant" for all types of 2888 negotiation. However the negotiation is not considered as failed if 2890 Julian Satran Expires February 2003 65 2891 iSCSI 5-August-02 2893 the answer is "Irrelevant". The "Irrelevant" answer is meant for 2894 those cases in which several keys are presented by an proposing party 2895 but the selection made by the acceptor for one of the keys makes 2896 other keys irrelevant. The following examples illustrates the use 2897 "Irrelevant": 2899 I->T OFMarker=Yes,OFMarkInt=2048~8192 2900 T->I OFMarker=No,OFMarkInt=Irrelevant 2902 I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb) 2903 T->I X#vkey2=None,X#vkey2=Irrelevant 2905 Any key not understood by the acceptor may be ignored by the accep- 2906 tor without affecting the basic function. However, the answer for a 2907 key not understood MUST be key=NotUnderstood. 2909 The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are 2910 reserved and must only be used as described here. 2912 Reject or Irrelevant are legitimate negotiation options where allowed 2913 but their excessive use is discouraged. A negotiation is considered 2914 complete when the acceptor has sent the key value pair even if the 2915 value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key 2916 again would be a re-negotiation and is forbidden for many keys. 2918 If the acceptor sends "Reject" as an answer the negotiated key is 2919 left at its current value (or default if no value was set). If the 2920 current value is not acceptable to the proposer on the connection or 2921 session it is sent the proposer MAY choose to terminate the connec- 2922 tion or session. 2924 All keys in this document except for the X extension formats, MUST be 2925 supported by iSCSI initiators and targets when used as specified 2926 here. If used as specified those keys MUST NOT be answered with 2927 NotUnderstood. 2929 Implementers may introduce new keys by prefixing them with X- fol- 2930 lowed by their (reversed) domain name, or with new keys registered 2931 with IANA prefixing them with X#. For example the entity owning the 2932 domain acme.com can issue: 2934 Julian Satran Expires February 2003 66 2935 iSCSI 5-August-02 2937 X-com.acme.bar.foo.do_something=3 2939 or a new registered key may be used as in: 2941 X#SuperCalyPhraGilistic=Yes 2943 Implementers MAY introduce also new values but ONLY for new keys or 2944 authentication methods (see Section 10 iSCSI Security Keys and 2945 Authentication Methods) or digests (see Section 11.1 HeaderDigest and 2946 DataDigest) 2948 Whenever parameter action or acceptance are dependent on other param- 2949 eters, the dependency rules and parameter sequence must be specified 2950 with the parameters. 2952 In the Login Phase (see Section 4.3 Login Phase) every stage is a 2953 separate negotiation. In FullFeaturePhase a Text Request Response 2954 sequence is a negotiation. Negotiations MUST be handled as atomic 2955 operations - i.e., all negotiated values go into effect after the 2956 negotiation concludes in agreement or are ignored if the negotiation 2957 fails. 2959 Some parameters may be subject to integrity rules (e.g., parameter-x 2960 must not exceed parameter-y or parameter-u not 1 implies parameter-v 2961 to be Yes). Whenever required, integrity rules are specified with the 2962 keys. Checking for compliance with the integrity rule MUST NOT be 2963 performed before all the negotiation parameters are available (the 2964 existent and newly negotiated). An iSCSI target MUST perform integ- 2965 rity checking before the new for parameters take effect. An initia- 2966 tor MAY perform integrity checking. 2968 4.2.1 List negotiations 2970 In list negotiation, the originator sends a list of values (which may 2971 include "None") in its order of preference. 2973 The responding party MUST respond with the same key and the first 2974 value that it supports (and is allowed to use for the specific origi- 2975 nator) selected from the originator list. 2977 Julian Satran Expires February 2003 67 2978 iSCSI 5-August-02 2980 The constant "None" MUST always be used to indicate a missing func- 2981 tion. However, "None" is a valid selection only if it is explicitly 2982 proposed. 2984 If an acceptor does not understand any particular value in a list it 2985 MUST ignore it. If an acceptor does not support, does not understand 2986 or is not allowed to use any of the proposed options with a specific 2987 originator, it may use the constant "Reject" or terminate the negoti- 2988 ation. The selection of a value not proposed MUST be handled as a 2989 protocol error. 2991 4.2.2 Simple-value negotiations 2993 For simple-value negotiations, the accepting party MUST answer with 2994 the same key. The value it selects becomes the negotiation result. 2996 Proposing a value not admissible (e.g., not within the specified 2997 bounds) MAY be answered with the constant "Reject" or the acceptor 2998 MAY select an admissible value. 3000 The selection, by the acceptor, of a value not admissible under the 3001 selection rules is considered a protocol error. The selection rules 3002 are key-specific. 3004 For a numerical range the value selected must be an integer within 3005 the proposed range or "Reject" (if the range is unacceptable). 3007 For boolean negotiations (i.e., keys taking the values Yes or No), 3008 the accepting party MUST answer with the same key and the result of 3009 the negotiation when the received value does not determine that 3010 result by itself. The last value transmitted becomes the negotiation 3011 result. The rules for selecting the value to answer with are 3012 expressed as Boolean functions of the value received, and the value 3013 that the accepting party would have selected if given a choice. 3015 Specifically, the two cases in which answers are OPTIONAL are: 3017 - The boolean function is "AND" and the value "No" is received. 3018 The outcome of the negotiation is "No". 3019 - The boolean function is "OR" and the value "Yes" is received. 3020 The outcome of the negotiation is "Yes". 3022 Responses are REQUIRED in all other cases, and the value chosen and 3023 sent by the acceptor becomes the outcome of the negotiation. 3025 Julian Satran Expires February 2003 68 3026 iSCSI 5-August-02 3028 4.3 Login Phase 3030 The Login Phase establishes an iSCSI session between an initiator and 3031 a target. It sets the iSCSI protocol parameters, security parame- 3032 ters, and authenticates the initiator and target to each other. 3034 The Login Phase is implemented via Login request and responses only. 3035 The whole Login Phase is considered as a single task and has a sin- 3036 gle Initiator Task Tag (similar to the linked SCSI commands). 3038 The default MaxRecvDataSegmentLength is used during Login. 3040 The Login Phase sequence of requests and responses proceeds as fol- 3041 lows: 3043 - Login initial request 3044 - Login partial response (optional) 3045 - More Login requests and responses (optional) 3046 - Login Final-Response (mandatory) 3048 The initial login request of any connection MUST include the Initia- 3049 torName key=value pair. The initial login request of the first con- 3050 nection of a session MAY also include the SessionType key=value pair. 3051 For any connection within a session whose type is not "Discovery", 3052 the first login request MUST also include the TargetName key=value 3053 pair. 3055 The Login Final-response accepts or rejects the Login request. 3057 The Login Phase MAY include a SecurityNegotiation stage and a Login- 3058 OperationalNegotiation stage and MUST include at least one of them, 3059 but the included stage MAY be empty except for the mandatory names. 3061 The login requests and responses contain a field that indicates the 3062 negotiation stage (SecurityNegotiation or LoginOperationalNegotia- 3063 tion). If both stages are used, the SecurityNegotiation MUST precede 3064 the LoginOperationalNegotiation. 3066 Some operational parameters can be negotiated outside the login 3067 through Text requests and responses. 3069 Security MUST be completely negotiated within the Login Phase. In 3070 addition the use of underlying IPsec security is specified in Chap- 3072 Julian Satran Expires February 2003 69 3073 iSCSI 5-August-02 3075 ter 7 and in [SEC-IPS]. iSCSI support for security within the proto- 3076 col consists only of authentication in the Login Phase. 3078 In some environments, a target or an initiator is not interested in 3079 authenticating its counterpart. It is possible to bypass authentica- 3080 tion through the Login request and response. 3082 The initiator and target MAY want to negotiate iSCSI authentication 3083 parameters. Once this negotiation is completed, the channel is con- 3084 sidered secure. 3086 Most of the negotiation keys are only allowed in a specific stage. 3087 The SecurityNegotiation keys appear in Chapter 10 and the LoginOpera- 3088 tionalNegotiation keys appear in Chapter 11. Only a limited set of 3089 keys (marked as Any-Stage in Chapter 11) may be used in any of the 3090 two stages. 3092 Any given Login request or response belongs to a specific stage; this 3093 determines the negotiation keys allowed with the request or response. 3094 Sending a key not allowed in the current stage is considered a proto- 3095 col error. 3097 Stage transition is performed through a command exchange (request/ 3098 response) that carries the T bit and the same current stage code. 3099 During this exchange, the next stage is selected by the target and 3100 MUST NOT exceed the value stated by the initiator. The initiator can 3101 request a transition whenever it is ready, but a target can respond 3102 with a transition only after one is proposed by the initiator. 3104 In a negotiation sequence, the T bit settings in one pair of login 3105 request-responses have no bearing on the T bit settings of the next 3106 pair. An initiator that has a T bit set to 1 in one pair and is 3107 answered with a T bit setting of 0 may issue the next request with T 3108 bit set to 0. 3110 When a transition is requested by the initiator and acknowledged by 3111 the target both initiator and target switch to the selected stage. 3113 Targets MUST NOT submit parameters that require an additional initia- 3114 tor login request in a login response with the T bit set to 1. 3116 Stage transitions during login (including entering and exit) are pos- 3117 sible only as outlined in the following table: 3119 Julian Satran Expires February 2003 70 3120 iSCSI 5-August-02 3122 +-----------------------------------------------------------+ 3123 |From To -> | Security | Operational | FullFeature | 3124 | | | | | | 3125 | V | | | | 3126 +-----------------------------------------------------------+ 3127 | (start) | yes | yes | no | 3128 +-----------------------------------------------------------+ 3129 | Security | no | yes | yes | 3130 +-----------------------------------------------------------+ 3131 | Operational | no | no | yes | 3132 +-----------------------------------------------------------+ 3134 The Login Final-Response that accepts a Login Request can come only 3135 as a response to a Login request with the T bit set to 1, and both 3136 the request and response MUST indicate FullFeaturePhase as the next 3137 phase via the NSG field. 3139 Neither the initiator nor the target should attempt to declare or 3140 negotiate a parameter more than once during login except for 3141 responses to specific keys that explicitly allow repeated key decla- 3142 rations (e.g. TargetAddress). If an attempt to re-negotiate/re- 3143 declare parameters not specifically allowed is detected by the tar- 3144 get the target MUST respond with Login reject (initiator error); if 3145 detected by the initiator the initiator MUST drop the connection. 3147 4.3.1 Login Phase Start 3149 The Login Phase starts with a login request from the initiator to the 3150 target. The initial login request includes: 3152 -Protocol version supported by the initiator. 3153 -iSCSI Initiator Name and iSCSI Target Name 3154 -ISID, TSIH and connection Ids. 3155 -The negotiation stage that the initiator is ready to enter. 3157 A login may create a new session or it may add a connection to an 3158 existing session. Between a given iSCSI Initiator Node (selected only 3159 by an InitiatorName) and a given iSCSI target defined by an iSCSI 3160 TargetName and a Target Portal Group Tag, login results are defined 3161 by the following table: 3163 Julian Satran Expires February 2003 71 3164 iSCSI 5-August-02 3166 +-------------------------------------------------------------------+ 3167 |ISID | TSIH | CID | Target action | 3168 +-------------------------------------------------------------------+ 3169 |new | non-zero | any | fail the login | 3170 | | | | ("session does not exist") | 3171 +-------------------------------------------------------------------+ 3172 |new | zero | any | instantiate a new session | 3173 +-------------------------------------------------------------------+ 3174 |existing | zero | any | do session reinstatement | 3175 | | | | (see section 4.3.5) | 3176 +-------------------------------------------------------------------+ 3177 |existing | non-zero | new | add a new connection to | 3178 | | existing | | the session | 3179 +-------------------------------------------------------------------+ 3180 |existing | non-zero |existing| do connection reinstatement| 3181 | | existing | | (see section 4.3.4) | 3182 +-------------------------------------------------------------------+ 3183 |existing | non-zero | any | fail the login | 3184 | | new | | ("session does not exist") | 3185 +-------------------------------------------------------------------+ 3187 Determination of existing or new are made by the target. 3189 Optionally, the login request may include: 3191 -Security parameters OR 3192 -iSCSI operational parameters AND/OR 3193 -The next negotiation stage that the initiator is ready to 3194 enter. 3196 The target can answer the login in the following ways: 3198 -Login Response with Login reject. This is an immediate rejec- 3199 tion from the target that causes the connection to terminate 3200 and the session to terminate if this is the first (or only) 3201 connection of a new session. The T bit and the CSG and NSG 3202 fields are reserved. 3203 -Login Response with Login accept as a final response (T bit 3204 set to 1 and the NSG in both request and response are set to 3205 FullFeaturePhase). The response includes the protocol ver- 3206 sion supported by the target and the session ID, and may 3207 include iSCSI operational or security parameters (that depend 3208 on the current stage). 3210 Julian Satran Expires February 2003 72 3211 iSCSI 5-August-02 3213 -Login Response with Login Accept as a partial response (NSG 3214 not set to FullFeaturePhase in both request and response) 3215 that indicates the start of a negotiation sequence. The 3216 response includes the protocol version supported by the tar- 3217 get and either security or iSCSI parameters (when no secu- 3218 rity mechanism is chosen) supported by the target. 3220 If the initiator decides to forego the SecurityNegotiation stage, it 3221 issues the Login with the CSG set to LoginOperationalNegotiation and 3222 the target may reply with a Login Response that indicates that it is 3223 unwilling to accept the connection (see Section 9.13 Login Response) 3224 without SecurityNegotiation and will terminate the connection with a 3225 response of Authentication failure (see Section 9.13.5 Status-Class 3226 and Status-Detail). 3228 If the initiator is willing to negotiate iSCSI security, but is 3229 unwilling to make the initial parameter proposal and may accept a 3230 connection without iSCSI security, it issues the Login with the T bit 3231 set to 1, the CSG set to SecurityNegotiation, and NSG set to LoginOp- 3232 erationalNegotiation. If the target is also ready to skip security, 3233 the Login response containing only the TargetPrtalGroup key (see Sec- 3234 tion 11.9 TargetPortalGroupTag) and has T bit set to 1, the CSG set 3235 to SecurityNegotiation, and NSG set to LoginOperationalNegotiation. 3237 An initiator that chooses to operate without iSCSI security and with 3238 all the operational parameters taking the default values issues the 3239 Login with the T bit set to 1, the CSG set to LoginOperationalNegoti- 3240 ation, and NSG set to FullFeaturePhase. If the target is also ready 3241 to forego security and can finish its LoginOperationalNegotiation, 3242 the Login response has T bit set to 1, the CSG set to LoginOperation- 3243 alNegotiation, and NSG set to FullFeaturePhase in the next stage. 3245 During the Login Phase from the iSCSI target MUST return the Target- 3246 PortalGroupTag key with the first Login Response PDU it is allowed to 3247 do so (i.e., the firs Login Response issued after the first Login 3248 Request wit C bit set to 0). The TargetPortalGroupTag key value indi- 3249 cates the iSCSI portal group servicing the Login Request PDU. If the 3250 reconfiguration of iSCSI portal groups is a concern in a given envi- 3251 ronment, the iSCSI initiator MUST use this key to ascertain that it 3252 had indeed initiated the Login Phase with the intended target portal 3253 group. 3255 Julian Satran Expires February 2003 73 3256 iSCSI 5-August-02 3258 4.3.2 iSCSI Security Negotiation 3260 The security exchange sets the security mechanism and authenticates 3261 the initiator user and the target to each other. The exchange pro- 3262 ceeds according to the authentication method chosen in the negotia- 3263 tion phase and is conducted using the login requests' and responses' 3264 key=value parameters. 3266 An initiator directed negotiation proceeds as follows: 3268 -The initiator sends a login request with an ordered list of 3269 the options it supports (authentication algorithm). The 3270 options are listed in the initiator's order of preference. 3271 The initiator MAY also send private or public extension 3272 options. 3274 -The target MUST reply with the first option in the list it 3275 supports and is allowed to use for the specific initiator 3276 unless it does not support any in which case it MUST answer 3277 with "Reject" (see also Section 4.2 Text Mode Negotiation). 3278 The parameters are encoded in UTF8 as key=value. For secu- 3279 rity parameters, see Chapter 10. 3281 -When the initiator considers that it is ready to conclude the 3282 SecurityNegotiation stage it sets the T bit to 1 and the NSG 3283 to what it would like the next stage to be. The target will 3284 then set the T bit to 1 and set NSG to the next stage in the 3285 Login response when it finishes sending its security keys. 3286 The next stage selected will be the one the target selected. 3287 If the next stage is FullFeaturePhase, the target MUST 3288 respond with a Login Response with the TSIH value. 3290 If the security negotiation fails at the target, then the target MUST 3291 send the appropriate Login Response PDU. If the security negotiation 3292 fails at the initiator, the initiator SHOULD close the connection. 3294 It should be noted that the negotiation might also be directed by the 3295 target if the initiator does support security, but is not ready to 3296 direct the negotiation (propose options). 3298 4.3.3 Operational Parameter Negotiation During the Login Phase 3300 Operational parameter negotiation during the login MAY be done: 3302 - Starting with the first Login request if the initiator does 3303 not propose any security/ integrity option. 3305 Julian Satran Expires February 2003 74 3306 iSCSI 5-August-02 3308 - Starting immediately after the security negotiation if the 3309 initiator and target perform such a negotiation. 3311 Operational parameter negotiation MAY involve several Login request- 3312 response exchanges started and terminated by the initiator. The ini- 3313 tiator MUST indicate its intent to terminate the negotiation by set- 3314 ting the T bit to 1; the target sets the T bit to 1 on the last 3315 response. 3317 If the target responds to a Login request having the T bit set to 1 3318 with a Login response having the T bit set to 0, the initiator should 3319 keep sending the Login request (even empty) with the T bit set to 1, 3320 while it still wants to switch stage, until it receives the Login 3321 Response having the T bit set to 1 or it receives a key that requires 3322 it to set again the T bit to 0. 3324 Some session specific parameters can be specified only during the 3325 Login Phase of the first connection of a session (i.e., begun by a 3326 login request that contains a zero-valued TSIH) - the leading Login 3327 Phase (e.g., the maximum number of connections that can be used for 3328 this session). 3330 A session is operational once it has at least one connection in Full- 3331 FeaturePhase. New or replacement connections can be added to a ses- 3332 sion only after the session is operational. 3334 For operational parameters, see Chapter 11. 3336 4.3.4 Connection reinstatement 3338 Connection reinstatement is the process of an initiator logging in 3339 with a ISID-TSIH-CID combination that is possibly active from the 3340 target's perspective - causing the implicit logging out of the con- 3341 nection corresponding to the CID and reinstating a new Full Feature 3342 Phase iSCSI connection in its place (with the same CID). Thus, the 3343 TSIH in the Login PDU MUST be non-zero and CID does not change dur- 3344 ing a connection reinstatement. The Login request performs the logout 3345 function of the old connection if an explicit logout was not per- 3346 formed earlier. In sessions with a single connection, this may imply 3347 the opening of a second connection with the sole purpose of cleaning 3348 up the first. Targets MUST support opening a second connection even 3349 when they do not support multiple connections in Full Feature Phase 3350 if ErrorRecoveryLevel is 2 and SHOULD support opening a second con- 3351 nection if ErrorRecoveryLevel is less than 2. 3353 Julian Satran Expires February 2003 75 3354 iSCSI 5-August-02 3356 If the operational ErrorRecoveryLevel is 2, connection reinstatement 3357 enables future task reassignment. If the operational ErrorRecovery- 3358 Level is less than 2, connection reinstatement is the replacement of 3359 the old CID without enabling task reassignment. In this case, all the 3360 tasks that were active on the old CID must be immediately terminated 3361 without further notice to the initiator. 3363 The initiator connection state MUST be CLEANUP_WAIT (section 6.1.3) 3364 when the initiator attempts a connection reinstatement. 3366 In practical terms, beside the implicit logout of the old connec- 3367 tion, reinstatement is equivalent to a new connection login. 3369 4.3.5 Session reinstatement, closure and timeout 3371 Session reinstatement is the process of initiator logging in with an 3372 ISID that is possibly active from the target's perspective - thus 3373 implicitly logging out the session corresponding to the ISID and 3374 reinstating a new iSCSI session in its place (with the same ISID). 3375 Thus, the TSIH in the Login PDU MUST be zero to signal session rein- 3376 statement. Session reinstatement causes all the tasks that were 3377 active on the old session to be immediately terminated by the target 3378 without further notice to the initiator. 3380 The initiator session state MUST be FAILED (Section 6.3 Session State 3381 Diagrams) when the initiator attempts a session reinstatement. 3383 Session closure is an event defined to be either of the following: 3385 - a successful "session close" logout 3386 - a successful "connection close" logout for the last Full Fea- 3387 ture Phase connection when no other connection in the ses- 3388 sion is waiting for cleanup (Section 6.2 Connection Cleanup 3389 State Diagram for Initiators and Targets) and no tasks in the 3390 session are waiting for reassignment. 3392 Session timeout is an event defined to occur when the last connec- 3393 tion state timeout expires and no tasks are waiting for reassign- 3394 ment. This takes the session to the FREE state (N6 transition in the 3395 session state diagram). 3397 Julian Satran Expires February 2003 76 3398 iSCSI 5-August-02 3400 4.3.5.1 Loss of Nexus notification 3402 The iSCSI layer provides the SCSI layer with the "I_T nexus loss" 3403 notification when any one of the following events happens: 3405 a) A successful completion of session reinstatement 3406 b) A session closure event 3407 c) A session timeout event 3409 Certain SCSI object clearing actions may result upon this notifica- 3410 tion in the SCSI end nodes, as documented in Appendix F. - Clearing 3411 effects of various events on targets -. 3413 4.3.6 Session continuation and failure 3415 Session continuation is the process by which the state of a pre- 3416 existing session continues to be used via either connection rein- 3417 statement (Section 4.3.4 Connection reinstatement), or by adding a 3418 connection with a new CID. Either of these actions associates the new 3419 transport connection with the pre-existing session state. 3421 Session failure is an event where the last Full Feature Phase connec- 3422 tion reaches the CLEANUP_WAIT state (Section 6.2 Connection Cleanup 3423 State Diagram for Initiators and Targets), or completes a successful 3424 recovery logout thus causing all active tasks (that are formerly 3425 allegiant to the connection) to start waiting for task reassignment. 3427 4.4 Operational Parameter Negotiation Outside the Login Phase 3429 Some operational parameters MAY be negotiated outside (after) the 3430 Login Phase. 3432 Parameter negotiation in Full Feature Phase is done through Text 3433 requests and responses. Operational parameter negotiation MAY involve 3434 several text request-response exchanges, which the initiator always 3435 starts and terminates and uses the same Initiator Task Tag. The ini- 3436 tiator MUST indicate its intent to terminate the negotiation by set- 3437 ting the F bit to 1; the target sets the F bit to 1 on the last 3438 response. 3440 If the target responds with a text response with the F bit set to 0 3441 to a text request with the F bit set to 1, the initiator should keep 3442 sending the text request (even empty) with the F bit set to 1, while 3444 Julian Satran Expires February 2003 77 3445 iSCSI 5-August-02 3447 it still wants to finish the negotiation, until it receives the text 3448 response with the F bit set to 1. Responding to a text request with 3449 the F bit set to 1 with an empty (no key=value pairs) response with 3450 the F bit set to 0 is discouraged. 3452 Targets MUST NOT submit parameters that require an additional initia- 3453 tor text request in a text response with the F bit set to 1. 3455 In a negotiation sequence, the F bit settings in one pair of text 3456 request-responses have no bearing on the F bit settings of the next 3457 pair. An initiator that has the F bit set to 1 in a request and is 3458 being answered with an F bit setting of 0 may issue the next request 3459 with the F bit set to 0. 3461 Whenever the target responds with the F bit set to 0, it MUST set the 3462 Target Transfer Tag to a value other than the default 0xffffffff. 3464 An initiator MAY reset an operational parameter negotiation by issu- 3465 ing a Text request with the Target Transfer Tag set to the value 3466 0xffffffff after receiving a response with the Target Transfer Tag 3467 set to a value other than 0xffffffff. A target may reset an opera- 3468 tional parameter negotiation by answering a Text request with a 3469 Reject PDU. 3471 Neither the initiator nor the target should attempt to declare or 3472 negotiate a parameter more than once during any negotiation sequence 3473 without an intervening operational parameter negotiation reset except 3474 for responses to specific keys that explicitly allow repeated key 3475 declarations (e.g. TargetAdress). If detected by the target this MUST 3476 result in a Reject PDU with a reason of "protocol error". The initia- 3477 tor MUST reset the negotiation as outlined above. 3479 Parameters negotiated by a text exchange negotiation sequence become 3480 effective only after the negotiation sequence is completed. 3482 Julian Satran Expires February 2003 78 3483 iSCSI 5-August-02 3485 5. iSCSI Error Handling and Recovery 3487 5.1 Overview 3489 5.1.1 Background 3491 The following two considerations prompted the design of much of the 3492 error recovery functionality in iSCSI: 3494 i) An iSCSI PDU may fail the digest check and be 3495 dropped, despite being received by the TCP layer. 3496 iSCSI layer must optionally be allowed to recover 3497 such dropped PDUs. 3498 ii) A TCP connection may fail at any time during the 3499 data transfer. All the active tasks must be option- 3500 ally allowed to be continued on a different TCP 3501 connection within the same session. 3503 Many of the recovery details in an iSCSI implementation are a local 3504 matter and beyond the scope of protocol standardization. However, 3505 some external aspects of the processing must be standardized to 3506 ensure interoperability. This chapter describes a general model for 3507 recovery in support of interoperability. See Appendix E. - Algorith- 3508 mic Presentation of Error Recovery Classes - for further detail on 3509 how the described model may be implemented. Compliant implementa- 3510 tions do not have to match the implementation details of this model 3511 as presented, but the external behavior of such implementations must 3512 correspond to the externally observable characteristics of the pre- 3513 sented model. 3515 5.1.2 Goals and the resulting features 3517 Following are the major design goals of the iSCSI error recovery 3518 scheme: 3520 a) Allow iSCSI product differentiation for different target mar- 3521 kets by defining multiple sets of error recovery capabilities. 3522 b) Ensure interoperability between any two implementations sup- 3523 porting different sets of error recovery capabilities. 3524 c) Define the error recovery mechanisms to ensure command order- 3525 ing even in the face of errors, for initiators that demand order- 3526 ing. 3528 Julian Satran Expires February 2003 79 3529 iSCSI 5-August-02 3531 d) Do not make additions in the fast path, but allow moderate 3532 complexity in the error recovery path. 3533 e) Prevent both initiator and target from attempting to recover 3534 same set of PDUs at the same time - i.e. there must be a clear 3535 "error recovery functionality distribution" between initiator and 3536 target. 3538 The initiator mechanisms defined in connection with error recovery 3539 are: 3541 a) NOP-OUT to probe sequence numbers of the target (section 9.18) 3542 b) Command retry (section 5.2.1) 3543 c) Recovery R2T support (section 5.7) 3544 d) Requesting retransmission of status/data/R2T using the SNACK 3545 facility (section 9.16) 3546 e) Acknowledging the receipt of the data (section 9.16) 3547 f) Reassigning the connection allegiance of a task to a differ- 3548 ent TCP connection (section 5.2.2) 3549 g) Terminating the entire iSCSI session to start afresh (section 3550 5.14.4) 3552 The target mechanisms defined in connection with error recovery are: 3554 a) NOP-IN to probe sequence numbers of the initiator (section 3555 9.19) 3556 b) Requesting retransmission of data using the recovery R2T fea- 3557 ture (section 5.7) 3558 c) SNACK support (section 9.16) 3559 d) Requesting that parts of read data be acknowledged (section 3560 9.7.2) 3561 e) Allegiance reassignment support (section 5.2.2) 3562 f) Terminating the entire iSCSI session to force the initiator to 3563 start over (section 5.14.4) 3565 5.1.3 State expectations 3567 For any outstanding SCSI command, it is assumed that iSCSI, in con- 3568 junction with SCSI at the initiator, is able to keep enough informa- 3569 tion to be able to rebuild the command PDU, and that outgoing data is 3570 available (in host memory) for retransmission while the command is 3571 outstanding. It is also assumed that at the target, incoming data 3572 (read data) MAY be kept for recovery or it can be re-read from a 3573 device server. 3575 Julian Satran Expires February 2003 80 3576 iSCSI 5-August-02 3578 It is further assumed that a target will keep the "status & sense" 3579 for a command it has executed if it supports status retransmission. 3580 A target that agrees to support data retransmission in addition is 3581 also expected to be prepared to retransmit the outgoing data (i.e. 3582 Data-In) on request until either the status for the completed com- 3583 mand is acknowledged, or the data in question had been separately 3584 acknowledged. 3586 5.2 Retry and Reassign in Recovery 3588 This section summarizes two important and somewhat related iSCSI pro- 3589 tocol features used in error recovery. 3591 5.2.1 Usage of Retry 3593 By resending the same iSCSI command PDU ("retry") in the absence of a 3594 command acknowledgement (by way of an ExpCmdSN update) or a response, 3595 an initiator attempts to "plug" (what it thinks are) the discontinui- 3596 ties in CmdSN ordering on the target end. Discarded command PDUs, 3597 due to digest errors, may have created these discontinuities. 3599 Retry MUST NOT be used for reasons other than plugging command 3600 sequence gaps, and in particular cannot be used for requesting PDU 3601 retransmissions from a target. Any such PDU retransmission requests 3602 for a currently allegiant command in progress may be made using the 3603 SNACK mechanism already described in section 9.16, although the usage 3604 of SNACK is OPTIONAL. 3606 If initiators, as part of plugging command sequence gaps as described 3607 above, inadvertently issue retries for allegiant commands already in 3608 progress (i.e., targets did not see the discontinuities in CmdSN 3609 ordering), the duplicate commands are silently ignored by targets as 3610 specified in section 2.2.2.1. 3612 When an iSCSI command is retried, the command PDU MUST carry the 3613 original Initiator Task Tag and the original operational attributes 3614 (e.g., flags, function names, LUN, CDB etc.) as well as the original 3615 CmdSN. The command being retried MUST be sent on the same connection 3616 as the original command unless the original connection was already 3617 successfully logged out. 3619 Julian Satran Expires February 2003 81 3620 iSCSI 5-August-02 3622 5.2.2 Allegiance Reassignment 3624 By issuing a "task reassign" task management request (Section 9.5.1 3625 Function), the initiator signals its intent to continue an already 3626 active command (but with no current connection allegiance) as part of 3627 connection recovery. This means that a new connection allegiance is 3628 requested for the command, that seeks to associate it to the connec- 3629 tion on which the task management request is being issued. Before 3630 the allegiance reassignment is attempted for a task, an implicit or 3631 explicit Logout with the reason code "remove the connection for 3632 recovery" ( see section 9.14) MUST be successfully completed for the 3633 previous connection the task was allegiant to. 3635 In reassigning connection allegiance for a command, the targets 3636 SHOULD continue the command from its current state. For example, when 3637 reassigning read commands, the target SHOULD take advantage of Exp- 3638 DataSN field provided by the Task Management function request (which 3639 must be set to zero if there was no data transfer) and bring the read 3640 command to completion by sending the remaining data and sending (or 3641 resending) the status. ExpDataSN acknowledges all data sent up to - 3642 but not including the Data-In PDU and or R2T with DataSN (or R2TSN) 3643 equal to ExpDataSN. However, targets may choose to send/receive the 3644 entire data on a reassignment of connection allegiance if unable to 3645 recover or maintain accurate state. Initiators MUST not subse- 3646 quently request data retransmission trough Data SNACK for PDUs num- 3647 bered less than ExpDataSN (i.e., prior to the acknowledged sequence 3648 number). For all types of commands, a reassignment request implies 3649 that the task is still considered in progress by the initiator and 3650 the target must conclude the task appropriately if the target returns 3651 the "Function Complete" response to the reassignment request. This 3652 might possibly involve retransmission of data/R2T/status PDUs as nec- 3653 essary, but MUST involve the (re)transmission of the status PDU. 3655 It is OPTIONAL for targets to support the allegiance reassignment. 3656 This capability is negotiated via the ErrorRecoveryLevel text key 3657 during the login time. When a target does not support allegiance 3658 reassignment, it MUST respond with a Task Management response code of 3659 "Allegiance reassignment not supported". If allegiance reassignment 3660 is supported by the target, but the task is still allegiant to a dif- 3661 ferent connection or a successful recovery Logout of the previously 3662 allegiant connection was not performed, the target MUST respond with 3663 a Task Management response code of "Task still allegiant". 3665 Julian Satran Expires February 2003 82 3666 iSCSI 5-August-02 3668 If allegiance reassignment is supported by the target, the Task Man- 3669 agement response to the reassignment request MUST be issued before 3670 the reassignment becomes effective. 3672 If a SCSI Command involving data input is reassigned (see Section 3673 5.2.2 Allegiance Reassignment) any SNACK Tag it holds for a final 3674 response from the original connection is deleted and the default 3675 value of 0 MUST be used instead. 3677 5.3 Usage Of Reject PDU in Recovery 3679 Targets MUST NOT implicitly terminate an active task by sending a 3680 Reject PDU for any PDU exchanged during the life of the task. If the 3681 target decides to terminate the task, a Response PDU (SCSI, Text, 3682 Task etc.) must be returned by the target to conclude the task. If 3683 the task had never been active before the Reject (i.e., the Reject is 3684 on the command PDU), targets should not send any further responses 3685 because the command itself is being discarded. 3687 The above rule means that the initiators can eventually expect a 3688 response even on receiving Reject's, if the received Reject is for a 3689 PDU other than the command PDU itself. The non-command Reject's only 3690 have diagnostic value in logging the errors, and they can be used for 3691 retransmission decisions by the initiators. 3693 The CmdSN of the rejected command PDU (if it is a non-immediate com- 3694 mand) MUST NOT be considered received by the target (i.e., a command 3695 sequence gap must be assumed for the CmdSN), even though the CmdSN of 3696 the rejected command PDU may be reliably ascertained. Upon receiv- 3697 ing the Reject, the initiator MUST plug the CmdSN gap in order to 3698 continue to use the session - the gap may be plugged either by trans- 3699 mitting a command PDU with the same CmdSN, or by aborting the task 3700 (see section 5.9 on how an abort may plug a CmdSN gap). 3702 When a data PDU is rejected and its DataSN can be ascertained, a tar- 3703 get MUST advance ExpDataSN for the current data burst if a recovery 3704 R2T is being generated. The target MAY advance its ExpDataSN if it 3705 does not attempt to recover the lost data PDU. 3707 5.4 Connection timeout management 3709 iSCSI defines two session-global timeout values (in seconds) - 3710 Time2Wait and Time2Retain - that are applicable when an iSCSI Full 3711 Feature Phase connection is taken out of service either intention- 3713 Julian Satran Expires February 2003 83 3714 iSCSI 5-August-02 3716 ally or on an exception. Time2Wait is the initial "respite time" 3717 before attempting an explicit/implicit Logout for the CID in ques- 3718 tion or task reassignment for the affected tasks (if any). 3719 Time2Retain is the maximum time after the initial respite interval 3720 that the task and/or connection state(s) is/are guaranteed to be 3721 maintained on the target to cater to a possible recovery attempt. 3722 Recovery attempts for the connection and/or task(s) SHOULD NOT be 3723 made before Time2Wait seconds, but MUST be completed within 3724 Time2Retain seconds after that initial Time2Wait waiting period. 3726 5.4.1 Timeouts on transport exception events 3728 A transport connection shutdown or a transport reset without any 3729 preceding iSCSI protocol interactions informing of the fact causes a 3730 Full Feature Phase iSCSI connection to be abruptly terminated. The 3731 timeout values to be used in this case are the negotiated values of 3732 DefaultTime2Wait (Section 11.15 DefaultTime2Wait) and 3733 DefaultTime2Retain (Section 11.16 DefaultTime2Retain) text keys for 3734 the session. 3736 5.4.2 Timeouts on planned decommissioning 3738 Any planned decommissioning of a Full Feature Phase iSCSI connection 3739 is preceded by either a Logout Response PDU, or an Async Message PDU. 3740 The Time2Wait and Time2Retain field values (section 9.15) in a Logout 3741 Response PDU, and the Parameter2 and Parameter3 fields of an Async 3742 Message (AsyncEvent types "drop the connection" or "drop all the con- 3743 nections"; section 9.9.1) specify the timeout values to be used in 3744 each of these cases. 3746 These timeout values are applicable only for the affected connec- 3747 tion, and the tasks active on that connection. These timeout values 3748 have no bearing on initiator timers (if any) that are already run- 3749 ning on connections or tasks associated with that session. 3751 5.5 Implicit termination of tasks 3753 A target implicitly terminates the active tasks in three cases due to 3754 iSCSI protocol dynamics: 3756 a) When a connection is implicitly or explicitly logged out with 3757 the Reason code of "Closes the connection" and there are active 3758 tasks allegiant to that connection. 3760 Julian Satran Expires February 2003 84 3761 iSCSI 5-August-02 3763 b) When a connection fails and eventually the connection state 3764 times out (state transition M1 in Section 6.2.2 State Transition 3765 Descriptions for Initiators and Targets) and there are active 3766 tasks allegiant to that connection. 3768 c) When a successful Logout with the reason code of "remove the 3769 connection for recovery" is performed while there are active tasks 3770 allegiant to that connection, and those tasks eventually time out 3771 after the Time2Wait and Time2Retain periods without allegiance 3772 reassignment. 3774 If the tasks terminated in any of the above cases are SCSI tasks, 3775 they must be internally terminated with CHECK CONDITION status with a 3776 sense key of unit attention and ASC/ASCQ values of 0x6E/0x00 (COM- 3777 MAND TO LOGICAL UNIT FAILED). Note that this status is meaningful 3778 only for appropriately handling the internal SCSI state with respect 3779 to ordering aspects such as queued commands because this status is 3780 never communicated back as a terminating status to the initiator. 3782 5.6 Format Errors 3784 The following two explicit violations of PDU layout rules are format 3785 errors: 3787 a) illegal contents of any PDU header field except the Opcode 3788 (legal values are specified in Section 9 iSCSI PDU Formats) 3789 b) inconsistent field contents (consistent field contents are 3790 specified in Section 9 iSCSI PDU Formats) 3792 Format errors indicate a major implementation flaw in one of the par- 3793 ties. 3795 When a target or an initiator receives an iSCSI PDU with a format 3796 error, it MUST immediately terminate all transport connections in the 3797 session either with a connection close or with a connection reset and 3798 escalate the format error to session recovery (see Section 5.14.4 3799 Session Recovery). 3801 5.7 Digest Errors 3803 The discussion of the legal choices in handling digest errors below 3804 excludes session recovery as an explicit option, but either party 3805 detecting a digest error may choose to escalate the error to session 3806 recovery. 3808 Julian Satran Expires February 2003 85 3809 iSCSI 5-August-02 3811 When a target or an initiator receives any iSCSI PDU, with a header 3812 digest error, it MUST either discard the header and all data up to 3813 the beginning of a later PDU or close the connection. Since the 3814 digest error indicates that the length field of the header may have 3815 been corrupted, the location of the beginning of a later PDU needs to 3816 be reliably ascertained by other means (such as the operation of a 3817 sync and steering layer). 3819 When a target receives any iSCSI PDU with a payload digest error, it 3820 MUST answer with a Reject PDU with a Reason-code of Data-Digest-Error 3821 and discard the PDU. 3823 - If the discarded PDU is a solicited or unsolicited iSCSI data 3824 PDU (for immediate data in a command PDU, non-data PDU rule 3825 below applies), the target MUST do one of the following: 3826 a) Request retransmission with a recovery R2T. 3827 b) Terminate the task with a response PDU with a CHECK CONDI- 3828 TION Status and an iSCSI Condition of "protocol service CRC 3829 error" (Section 9.4.7.2 Sense Data). If the target chooses 3830 to implement this option, it MUST wait to receive all the 3831 data (signaled by a Data PDU with the final bit set for all 3832 outstanding R2Ts) before sending the response PDU. A task 3833 management command (such as an abort task) from the initia- 3834 tor during this wait may also conclude the task. 3835 - No further action is necessary for targets if the discarded 3836 PDU is a non-data PDU. In case of immediate data being 3837 present on a discarded command, the immediate data is implic- 3838 itly recovered when the task is retried (see section 5.2.1) 3839 followed by the entire data transfer for the task. 3841 When an initiator receives any iSCSI PDU with a payload digest error, 3842 it MUST discard the PDU. 3844 - If the discarded PDU is an iSCSI data PDU, the initiator MUST 3845 do one of the following: 3847 a) Request the desired data PDU through SNACK. In response to 3848 the SNACK, the target MUST either resend the data PDU or, 3849 reject the SNACK with a Reject PDU with a reason-code of 3850 "SNACK reject" in which case: 3851 i)if the status had not already been sent for the com- 3852 mand, the target MUST terminate the command with an 3853 CHECK CONDITION Status and an iSCSI Condition of "SNACK 3854 rejected" (Section 9.4.7.2 Sense Data). 3856 Julian Satran Expires February 2003 86 3857 iSCSI 5-August-02 3859 ii)if the status was already sent, no further action is 3860 necessary for the target. The initiator in this case 3861 MUST must wait for the status to be received and then 3862 discard it, so as to internally signal the completion 3863 with CHECK CONDITION Status and an iSCSI Condition of 3864 "protocol service CRC error" (Section 9.4.7.2 Sense 3865 Data). 3866 b) Abort the task and terminate the command with an error. 3868 - If the discarded PDU is a response PDU, the initiator MUST do 3869 one of the following: 3871 a) Request PDU retransmission with a status SNACK. 3872 b) Logout the connection for recovery and continue the tasks 3873 on a different connection instance as described in Section 3874 5.2 Retry and Reassign in Recovery. 3875 c) Logout to close the connection (abort all the commands 3876 associated with the connection). 3878 - No further action is necessary for initiators if the dis- 3879 carded PDU is an unsolicited PDU (e.g., Async, Reject). Task 3880 timeouts (as in, the initiator waiting for a command comple- 3881 tion), or process timeouts (as in, the target waiting for a 3882 Logout) will ensure that the correct operational behavior 3883 will result in these cases despite the discarded PDU. 3885 5.8 Sequence Errors 3887 When an initiator receives an iSCSI R2T/data PDU with an out of order 3888 R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that implies 3889 missing data PDU(s), it means that the initiator must have detected a 3890 header or payload digest error on one or more earlier R2T/data PDUs. 3891 The initiator MUST address these implied digest errors as described 3892 in Section 5.7 Digest Errors. When a target receives a data PDU with 3893 an out of order DataSN, it means that the target must had hit a 3894 header or payload digest error on at least one of the earlier data 3895 PDUs. The target MUST address these implied digest errors as 3896 described in Section 5.7 Digest Errors. 3898 When an initiator receives an iSCSI status PDU with an out of order 3899 StatSN that implies missing responses, it MUST address the one or 3900 more missing status PDUs as described in Section 5.7 Digest Errors. 3901 As a side effect of receiving the missing responses, the initiator 3902 may discover missing data PDUs. If the initiator wants to recover the 3903 missing data for a command, it MUST NOT acknowledge the received 3905 Julian Satran Expires February 2003 87 3906 iSCSI 5-August-02 3908 responses that start from the StatSN of the interested command, until 3909 it has completed receiving all the data PDUs of the command. 3911 When an initiator receives duplicate R2TSNs (due to proactive 3912 retransmission of R2Ts by the target) or duplicate DataSNs (due to 3913 proactive SNACKs by the initiator), it MUST discard the duplicates. 3915 5.9 SCSI Timeouts 3917 An iSCSI initiator MAY attempt to plug a command sequence gap on the 3918 target end (in the absence of an acknowledgement of the command by 3919 way of ExpCmdSN) before the ULP timeout by retrying the unacknowl- 3920 edged command, as described in Section 5.2 Retry and Reassign in 3921 Recovery. 3923 On a ULP timeout for a command (that carried a CmdSN of n), if the 3924 iSCSI initiator intends to continue the session it MUST abort the 3925 command by either using an appropriate Task Management function 3926 request for the specific command, or a "close the connection" Logout. 3927 When using an ABORT TASK, if the ExpCmdSN is still less than (n+1), 3928 the target may see the abort request while missing the original com- 3929 mand itself due to one of the following reasons: 3931 - The original command was dropped due to digest error. 3932 - The connection on which the original command was sent was 3933 successfully logged out (on logout, the unacknowledged com- 3934 mands issued on the connection being logged out are dis- 3935 carded). 3937 If the abort request is received and the original command is miss- 3938 ing, targets MUST consider the original command with that RefCmdSN to 3939 be received and issue a Task Management response with the response 3940 code: "Function Complete". This response concludes the task on both 3941 ends. 3943 5.10 Negotiation Failures 3945 Text request and response sequences, when used to set/negotiate oper- 3946 ational parameters, constitute the negotiation/parameter setting. A 3947 negotiation failure is considered one or more of the following: 3949 - None of the choices or the stated value is acceptable to one 3950 negotiating side. 3951 - The text request timed out, and possibly terminated. 3952 - The text request was answered with a Reject PDU. 3954 Julian Satran Expires February 2003 88 3955 iSCSI 5-August-02 3957 The following two rules are to be used to address negotiation fail- 3958 ures: 3960 - During Login, any failure in negotiation MUST be considered a 3961 login process failure and the Login Phase must be termi- 3962 nated, and with it, the connection. If the target detects the 3963 failure, it must terminate the login with the appropriate 3964 login response code. 3966 - A failure in negotiation, while in the Full Feature Phase, 3967 will terminate the entire negotiation sequence that may con- 3968 sist of a series of text requests that use the same Initia- 3969 tor Task Tag. The operational parameters of the session or 3970 the connection MUST continue to be the values agreed upon 3971 during an earlier successful negotiation (i.e., any partial 3972 results of this unsuccessful negotiation MUST NOT take effect 3973 and be discarded). 3975 5.11 Protocol Errors 3977 Mapping framed messages over a "stream" connection, such as TCP, make 3978 the proposed mechanisms vulnerable to simple software framing errors. 3979 On the other hand, the introduction of framing mechanisms to limit 3980 the effects of these errors may be onerous on performance for simple 3981 implementations. Command Sequence Numbers and the above mechanisms 3982 for connection drop and re-establishment help handle this type of 3983 mapping errors. 3985 All violations of iSCSI PDU exchange sequences specified in this 3986 draft are also protocol errors. This category of errors can only be 3987 addressed by fixing the implementations; iSCSI defines Reject and 3988 response codes to enable this. 3990 5.12 Connection Failures 3992 iSCSI can keep a session in operation if it is able to keep/estab- 3993 lish at least one TCP connection between the initiator and the tar- 3994 get in a timely fashion. Targets and/or initiators may recognize a 3995 failing connection by either transport level means (TCP), a gap in 3996 the command sequence number, a response stream that is not filled for 3997 a long time, or by a failing iSCSI NOP (acting as a ping). The lat- 3998 ter MAY be used periodically to increase the speed and likelihood of 3999 detecting connection failures. Initiators and targets MAY also use 4001 Julian Satran Expires February 2003 89 4002 iSCSI 5-August-02 4004 the keep-alive option on the TCP connection to enable early link 4005 failure detection on otherwise idle links. 4007 On connection failure, the initiator and target MUST do one of the 4008 following: 4010 - Attempt connection recovery within the session (Section 4011 5.14.3 Connection Recovery). 4012 - Logout the connection with the reason code "closes the con- 4013 nection" (Section 9.14.5 Implicit termination of tasks), re- 4014 issue missing commands, and implicitly terminate all active 4015 commands. This option requires support for the within-connec- 4016 tion recovery class (Section 5.14.2 Recovery Within-connec- 4017 tion). 4018 - Perform session recovery (Section 5.14.4 Session Recovery). 4020 Either side may choose to escalate to session recovery (via the ini- 4021 tiator dropping all the connections, or via an Async Message that 4022 announces the similar intent from a target), and the other side MUST 4023 give it precedence. On a connection failure, a target MUST termi- 4024 nate and/or discard all the active immediate commands regardless of 4025 which of the above options is used (i.e., immediate commands are not 4026 recoverable across connection failures). 4028 5.13 Session Errors 4030 If all the connections of a session fail and cannot be re-estab- 4031 lished in a short time, or if initiators detect protocol errors 4032 repeatedly, an initiator may choose to terminate a session and estab- 4033 lish a new session. 4035 The initiator takes the following actions in such a case: 4037 - It resets or closes all the transport connections. 4038 - It terminates all outstanding requests with an appropriate 4039 response before initiating a new session. If the same I_T 4040 nexus is intended to be re-established, the initiator MUST 4041 employ session reinstatement (see section 4.3.5). 4043 When the session timeout (the connection state timeout for the last 4044 failed connection) happens on the target, it takes the following 4045 actions: 4047 - Resets or closes the TCP connections (closes the session). 4048 - Terminates all active tasks that were allegiant to the con- 4049 nection(s) that constituted the session. 4051 Julian Satran Expires February 2003 90 4052 iSCSI 5-August-02 4054 A target MUST also be prepared to handle a session reinstatement 4055 request from the initiator, who may be addressing session errors. 4057 5.14 Recovery Classes 4059 iSCSI enables the following classes of recovery (in the order of 4060 increasing scope of affected iSCSI tasks): 4062 - Within a command (i.e., without requiring command restart). 4063 - Within a connection (i.e., without requiring the connection 4064 to be rebuilt, but perhaps requiring command restart). 4065 - Connection recovery (i.e., perhaps requiring connections to 4066 be rebuilt and commands to be reissued). 4067 - Session recovery. 4069 The recovery scenarios detailed in the rest of this section are rep- 4070 resentative rather than exclusive. In every case, they detail the 4071 lowest class recovery that MAY be attempted. The implementer is left 4072 to decide under which circumstances to escalate to the next recovery 4073 class and/or what recovery classes to implement. Both the iSCSI tar- 4074 get and initiator MAY escalate the error handling to an error recov- 4075 ery class, which impacts a larger number of iSCSI tasks in any of the 4076 cases identified in the following discussion. 4078 In all classes, the implementer has the choice of deferring errors to 4079 the SCSI initiator (with an appropriate response code), in which case 4080 the task, if any, has to be removed from the target and all the side- 4081 effects, such as ACA, must be considered. 4083 Use of within-connection and within-command recovery classes MUST NOT 4084 be attempted before the connection is in Full Feature Phase. 4086 In the detailed description of the recover classes the mandating 4087 terms (MUST, SHOULD, MAY, etc.) indicate normative actions to be exe- 4088 cute if the recovery class is supported and used. 4090 5.14.1 Recovery Within-command 4092 At the target, the following cases lend themselves to within-command 4093 recovery: 4095 - Lost data PDU - realized through one of the following: 4096 a) Data digest error - dealt with as specified in Section 5.7 4097 Digest Errors, using the option of a recovery R2T. 4099 Julian Satran Expires February 2003 91 4100 iSCSI 5-August-02 4102 b) Sequence reception timeout (no data or partial-data-and-no-F- 4103 bit) - considered an implicit sequence error and dealt with as 4104 specified in Section 5.8 Sequence Errors, using the option of a 4105 recovery R2T. 4106 c) Header digest error, which manifests as a sequence reception 4107 timeout, or a sequence error - dealt with as specified in Section 4108 5.8 Sequence Errors, using the option of a recovery R2T. 4110 At the initiator, the following cases lend themselves to within-com- 4111 mand recovery: 4113 Lost data PDU or lost R2T - realized through one of the follow- 4114 ing: 4115 a) Data digest error - dealt with as specified in Section 5.7 4116 Digest Errors, using the option of a SNACK. 4117 b) Sequence reception timeout (no status) or response reception 4118 timeout - dealt with as specified in Section 5.8 Sequence Errors, 4119 using the option of a SNACK. 4120 c) Header digest error, which manifests as a sequence reception 4121 timeout, or a sequence error - dealt with as specified in Section 4122 5.8 Sequence Errors, using the option of a SNACK. 4124 To avoid a race with the target, which may already have a recovery 4125 R2T or a termination response on its way, an initiator SHOULD NOT 4126 originate a SNACK for an R2T based on its internal timeouts (if any). 4127 Recovery in this case is better left to the target. 4129 The timeout values used by the initiator and target are outside the 4130 scope of this document. Sequence reception timeout is generally a 4131 large enough value to allow the data sequence transfer to be com- 4132 plete. 4134 5.14.2 Recovery Within-connection 4136 At the initiator, the following cases lend themselves to within-con- 4137 nection recovery: 4139 - Requests not acknowledged for a long time. Requests are 4140 acknowledged explicitly through ExpCmdSN or implicitly by 4141 receiving data and/or status. The initiator MAY retry non- 4142 acknowledged commands as specified in Section 5.2 Retry and 4143 Reassign in Recovery. 4145 - Lost iSCSI numbered Response. It is recognized by either 4146 identifying a data digest error on a Response PDU or a Data- 4148 Julian Satran Expires February 2003 92 4149 iSCSI 5-August-02 4151 In PDU carrying the status, or by receiving a Response PDU 4152 with a higher StatSN than expected. In the first case, digest 4153 error handling is done as specified in Section 5.7 Digest 4154 Errors using the option of a SNACK. In the second case, 4155 sequence error handling is done as specified in Section 5.8 4156 Sequence Errors, using the option of a SNACK. 4158 At the target, the following cases lend themselves to within-connec- 4159 tion recovery: 4161 - Status/Response not acknowledged for a long time. The target 4162 MAY issue a NOP-IN (with a valid Target Transfer Tag or oth- 4163 erwise) that carries the next status sequence number it is 4164 going to use in the StatSN field. This helps the initiator 4165 detects any missing StatSN(s) and issue a SNACK for the sta- 4166 tus. 4168 The timeout values used by the initiator and the target are outside 4169 the scope of this document. 4171 5.14.3 Connection Recovery 4173 At an iSCSI initiator, the following cases lend themselves to connec- 4174 tion recovery: 4176 - TCP connection failure: The initiator MUST close the connec- 4177 tion. It then MUST either implicitly or explicitly Logout the 4178 failed connection with the reason code "remove the connec- 4179 tion for recovery" and reassign connection allegiance for all 4180 commands still in progress associated with the failed connec- 4181 tion on one or more connections (some or all of whom MAY be 4182 newly established connections) using the "Task reassign" task 4183 management function (see Section 9.5.1 Function). Note that 4184 for an initiator a command is in progress as long as it has 4185 not received a response or a Data-In PDU including status. 4187 Note. The logout function is mandatory, while a new connec- 4188 tion establishment is mandatory only if the failed connec- 4189 tion was the last or only connection in the session. 4191 - Receiving an Asynchronous Message that indicates one or all 4192 connections in a session has been dropped. The initiator 4193 MUST handle it as a TCP connection failure for the connec- 4194 tion(s) referred to in the Message. 4196 At an iSCSI target, the following cases lend themselves to connec- 4197 tion recovery: 4199 Julian Satran Expires February 2003 93 4200 iSCSI 5-August-02 4202 - TCP connection failure. The target MUST close the connection 4203 and if more than one connection is available, the target 4204 SHOULD send an Asynchronous Message that indicates it has 4205 dropped the connection. Then, the target will wait for the 4206 initiator to continue recovery. 4208 5.14.4 Session Recovery 4210 Session recovery should be performed when all other recovery attempts 4211 have failed. Very simple initiators and targets MAY perform session 4212 recovery on all iSCSI errors and rely on recovery on the SCSI layer 4213 and above. 4215 Session recovery implies the closing of all TCP connections, inter- 4216 nally aborting all executing and queued tasks for the given initia- 4217 tor at the target, terminating all outstanding SCSI commands with an 4218 appropriate SCSI service response at the initiator, and restarting a 4219 session on a new set of connection(s) (TCP connection establishment 4220 and login on all new connections). 4222 For possible clearing effects of session recovery on SCSI and iSCSI 4223 objects, refer to Appendix F. - Clearing effects of various events on 4224 targets -. 4226 5.15 Error Recovery Hierarchy 4228 The error recovery classes and features described thus far are orga- 4229 nized into a hierarchy for ease in understanding and to limit the 4230 myriad of implementation possibilities, with hopes that this signifi- 4231 cantly contributes to highly interoperable implementations. The 4232 attributes of this hierarchy are as follows: 4234 a) Each level is a superset of the capabilities of the previous 4235 level. For example, Level 1 support implies supporting all capa- 4236 bilities of Level 0 and more. 4237 b) As a corollary, supporting a higher error recovery level means 4238 increased sophistication and possibly an increase in resource 4239 requirements. 4240 c) Supporting error recovery level "n" is advertised and negoti- 4241 ated by each iSCSI entity by exchanging the text key "ErrorRecov- 4242 eryLevel=n". The lower of the two exchanged values is the 4243 operational ErrorRecoveryLevel for the session. 4245 The following diagram represents the error recovery hierarchy. 4247 Julian Satran Expires February 2003 94 4248 iSCSI 5-August-02 4250 + 4251 / \ 4252 / 2 \ <-- Connection recovery 4253 +-----+ 4254 / 1 \ <-- Digest failure recovery 4255 +---------+ 4256 / 0 \ <-- Session failure recovery 4257 +-------------+ 4259 The following table lists the error recovery capabilities expected 4260 from the implementations that support each error recovery level. 4262 +-------------------+--------------------------------------------+ 4263 |ErrorRecoveryLevel | Associated Error recovery capabilities | 4264 +-------------------+--------------------------------------------+ 4265 | 0 | Session recovery class | 4266 | | (Section 5.14.4 Session Recovery) | 4267 +-------------------+--------------------------------------------+ 4268 | 1 | Digest failure recovery (See Note below.) | 4269 +-------------------+--------------------------------------------+ 4270 | 2 | Connection recovery class | 4271 | | (Section 5.14.3 Connection Recovery) | 4272 +-------------------+--------------------------------------------+ 4274 Note: Digest failure recovery is comprised of two recovery classes: 4275 Within-Connection recovery class (Section 5.14.2 Recovery Within-con- 4276 nection) and Within-Command recovery class (Section 5.14.1 Recovery 4277 Within-command). 4279 When a defined value of ErrorRecoveryLevel is proposed by an origina- 4280 tor in a text negotiation, the originator MUST support the function- 4281 ality defined for the proposed value and additionally, functionality 4282 corresponding to any defined value numerically less than the pro- 4283 posed. When a defined value of ErrorRecoveryLevel is returned by a 4284 responder in a text negotiation, the responder MUST support the func- 4285 tionality corresponding to the ErrorRecoveryLevel it is accepting. 4287 When either party attempts to use error recovery functionality beyond 4288 what is negotiated, the recovery attempts MAY fail unless an apriori 4289 agreement outside the scope of this document exists between the two 4290 parties to provide such support. 4292 Julian Satran Expires February 2003 95 4293 iSCSI 5-August-02 4295 Supporting error recovery level "0" is mandatory, while the rest are 4296 optional to implement. In implementation terms, the above striation 4297 means that the following incremental sophistication with each level 4298 is required. 4300 +-------------------+---------------------------------------------+ 4301 |Level transition | Incremental requirement | 4302 +-------------------+---------------------------------------------+ 4303 | 0->1 | PDU retransmissions on the same connection | 4304 +-------------------+---------------------------------------------+ 4305 | 1->2 | Retransmission across connections and | 4306 | | allegiance reassignment | 4307 +-------------------+---------------------------------------------+ 4309 Julian Satran Expires February 2003 96 4310 iSCSI 5-August-02 4312 6. State Transitions 4314 iSCSI connections and iSCSI sessions go through several well-defined 4315 states from the time they are created to the time they are cleared. 4317 The connection state transitions are described in two separate but 4318 dependent state diagrams for ease in understanding. The first dia- 4319 gram, "standard connection state diagram", describes the connection 4320 state transitions when the iSCSI connection is not waiting for or 4321 undergoing a cleanup by way of an explicit or implicit Logout. The 4322 second diagram, "connection cleanup state diagram", describes the 4323 connection state transitions while performing the iSCSI connection 4324 cleanup. 4326 The "session state diagram" describes the state transitions an iSCSI 4327 session would go through during its lifetime, and it depends on the 4328 states of possibly multiple iSCSI connections that participate in the 4329 session. 4331 6.1 Standard Connection State Diagrams 4333 6.1.1 State Descriptions for Initiators and Targets 4335 State descriptions for the standard connection state diagram are as 4336 follows: 4337 -S1: FREE 4338 -initiator: State on instantiation, or after successful con- 4339 nection closure. 4340 -target: State on instantiation, or after successful connec- 4341 tion closure. 4342 -S2: XPT_WAIT 4343 -initiator: Waiting for a response to its transport connec- 4344 tion establishment request. 4345 -target: Illegal 4346 -S3: XPT_UP 4347 -initiator: Illegal 4348 -target: Waiting for the Login process to commence. 4349 -S4: IN_LOGIN 4350 -initiator: Waiting for the Login process to conclude, possi- 4351 bly involving several PDU exchanges. 4352 -target: Waiting for the Login process to conclude, possibly 4353 involving several PDU exchanges. 4354 -S5: LOGGED_IN 4356 Julian Satran Expires February 2003 97 4357 iSCSI 5-August-02 4359 -initiator: In Full Feature Phase, waiting for all internal, 4360 iSCSI, and transport events. 4361 -target: In Full Feature Phase, waiting for all internal, 4362 iSCSI, and transport events. 4363 -S6: IN_LOGOUT 4364 -initiator: Waiting for a Logout response. 4365 -target: Waiting for an internal event signaling completion 4366 of logout processing. 4367 -S7: LOGOUT_REQUESTED 4368 -initiator: Waiting for an internal event signaling readi- 4369 ness to proceed with Logout. 4370 -target: Waiting for the Logout process to start after hav- 4371 ing requested a Logout via an Async Message. 4372 -S8: CLEANUP_WAIT 4373 -initiator: Waiting for the context and/or resources to ini- 4374 tiate the cleanup processing for this CSM. 4375 -target: Waiting for the cleanup process to start for this 4376 CSM. 4377 6.1.2 State Transition Descriptions for Initiators and Targets 4379 -T1: 4380 -initiator: Transport connect request was made (ex: TCP SYN 4381 sent). 4382 -target: Illegal 4383 -T2: 4384 -initiator: Transport connection request timed out, or a 4385 transport reset was received, or an internal event of 4386 receiving a Logout response (success) on another connection 4387 for a "close the session" Logout request was received. 4388 -target:Illegal 4389 -T3: 4390 -initiator: Illegal 4391 -target: Received a valid transport connection request that 4392 establishes the transport connection. 4393 -T4: 4394 -initiator: Transport connection established, thus prompting 4395 the initiator to start the iSCSI Login. 4396 -target: Initial iSCSI Login request was received. 4397 -T5: 4398 -initiator: The final iSCSI Login response with a Status- 4399 Class of zero was received. 4401 Julian Satran Expires February 2003 98 4402 iSCSI 5-August-02 4404 -target: The final iSCSI Login request to conclude the Login 4405 Phase was received, thus prompting the target to send the 4406 final iSCSI Login response with a Status-Class of zero. 4407 -T6: 4408 -initiator: Illegal 4409 -target: Timed out waiting for an iSCSI Login, or transport 4410 disconnect indication was received, or transport reset was 4411 received, or an internal event indicating a transport time- 4412 out was received. In all these cases, the connection is to 4413 be closed. 4414 -T7: 4415 -initiator - one of the following evens caused the transi- 4416 tion: 4417 - The final iSCSI Login response was received with a non- 4418 zero Status-Class 4419 - Login timed out 4420 - A transport disconnect indication was received 4421 - A transport reset was received 4422 - An internal event indicating a transport timeout was 4423 received 4424 - An internal event of receiving a Logout response (suc- 4425 cess) on another connection for a "close the session" 4426 Logout request was received. 4428 In all these cases, the transport connection is closed. 4430 -target - one of the following events caused the transition: 4431 - The final iSCSI Login request to conclude the Login 4432 Phase was received, prompting the target to send the final 4433 iSCSI Login response with a non-zero Status-Class 4434 - Login timed out 4435 - Transport disconnect indication was received 4436 - Transport reset was received 4437 - An internal event indicating a transport timeout was 4438 received 4439 - On another connection a "close the session" Logout 4440 request was received. 4442 In all these cases, the connection is to be closed. 4443 -T8: 4444 -initiator: An internal event of receiving a Logout response 4445 (success) on another connection for a "close the session" 4447 Julian Satran Expires February 2003 99 4448 iSCSI 5-August-02 4450 Logout request was received, thus closing this connection 4451 requiring no further cleanup. 4452 -target: An internal event of sending a Logout response (suc- 4453 cess) on another connection for a "close the session" Logout 4454 request was received, or an internal event of a successful 4455 connection/session reinstatement is received, thus prompt- 4456 ing the target to close this connection cleanly. 4457 -T9, T10: 4458 -initiator: An internal event that indicates the readiness to 4459 start the Logout process was received, thus prompting an 4460 iSCSI Logout to be sent by the initiator. 4461 -target: An iSCSI Logout request was received. 4462 -T11, T12: 4463 -initiator: Async PDU with AsyncEvent "Request Logout" was 4464 received. 4465 -target: An internal event that requires the decommissioning 4466 of the connection is received, thus causing an Async PDU 4467 with an AsyncEvent "Request Logout" to be sent. 4468 -T13: 4469 -initiator: An iSCSI Logout response (success) was received, 4470 or an internal event of receiving a Logout response (suc- 4471 cess) on another connection for a "close the session" 4472 Logout request was received. 4473 -target: An internal event was received that indicates suc- 4474 cessful processing of the Logout, which prompts an iSCSI 4475 Logout response (success) to be sent, or an internal event 4476 of sending a Logout response (success) on another connec- 4477 tion for a "close the session" Logout request was received, 4478 or an internal event of a successful connection/session 4479 reinstatement is received. In all these cases, the trans- 4480 port connection is closed. 4482 -T14: 4483 -initiator: Async PDU with AsyncEvent "Request Logout" was 4484 received again. 4485 -target: Illegal 4486 -T15, T16: 4487 -initiator: One or more of the following events caused this 4488 transition: 4489 -Internal event that indicates a transport connection tim- 4490 eout was received thus prompting transport RESET or trans- 4491 port connection closure. 4492 -A transport RESET. 4494 Julian Satran Expires February 2003 100 4495 iSCSI 5-August-02 4497 -A transport disconnect indication. 4498 -Async PDU with AsyncEvent "Drop connection" (for this 4499 CID). 4500 -Async PDU with AsyncEvent "Drop all connections". 4501 -target: One or more of the following events caused this 4502 transition: 4503 -Internal event that indicates a transport connection tim- 4504 eout was received, thus prompting transport RESET or trans- 4505 port connection closure. 4506 -An internal event of a failed connection/session rein- 4507 statement is received. 4508 -A transport RESET. 4509 -A transport disconnect indication. 4510 -Internal emergency cleanup event was received which 4511 prompts an Async PDU with AsyncEvent "Drop connection" (for 4512 this CID), or event "Drop all connections". 4514 -T17: 4515 -initiator: One or more of the following events caused this 4516 transition: 4517 -Logout response (failure, i.e. a non-zero status) was 4518 received, or Logout timed out. 4519 -Any of the events specified for T15 and T16. 4520 -target: One or more of the following events caused this 4521 transition: 4522 -Internal event that indicates a failure of the Logout 4523 processing was received, which prompts a Logout response 4524 (failure, i.e. a non-zero status) to be sent. 4525 -Any of the events specified for T15 and T16. 4526 -T18: 4527 -initiator: An internal event of receiving a Logout response 4528 (success) on another connection for a "close the session" 4529 Logout request was received. 4531 -target: An internal event of sending a Logout response (suc- 4532 cess) on another connection for a "close the session" 4533 Logout request was received, or an internal event of a suc- 4534 cessful connection/session reinstatement is received. In 4535 both these cases, the connection is closed. 4537 Julian Satran Expires February 2003 101 4538 iSCSI 5-August-02 4540 The CLEANUP_WAIT state (S8) implies that there are possible iSCSI 4541 tasks that have not reached conclusion and are still considered busy. 4543 6.1.3 Standard Connection State Diagram for an Initiator 4545 Symbolic names for States: 4547 S1: FREE 4548 S2: XPT_WAIT 4549 S4: IN_LOGIN 4550 S5: LOGGED_IN 4551 S6: IN_LOGOUT 4552 S7: LOGOUT_REQUESTED 4553 S8: CLEANUP_WAIT 4555 States S5, S6 and S7 constitute the Full Feature Phase operation of 4556 the connection. 4558 The state diagram is as follows: 4560 Julian Satran Expires February 2003 102 4561 iSCSI 5-August-02 4563 -------<-------------+ 4564 +--------->/ S1 \<----+ | 4565 T13| +->\ /<-+ \ | 4566 | / ---+--- \ \ | 4567 | / | T2 \ | | 4568 | T8 | |T1 | | | 4569 | | | / |T7 | 4570 | | | / | | 4571 | | | / | | 4572 | | V / / | 4573 | | ------- / / | 4574 | | / S2 \ / | 4575 | | \ / / | 4576 | | ---+--- / | 4577 | | |T4 / | 4578 | | V / | T18 4579 | | ------- / | 4580 | | / S4 \ | 4581 | | \ / | 4582 | | ---+--- | T15 4583 | | |T5 +--------+---------+ 4584 | | | /T16+-----+------+ | 4585 | | | / -+-----+--+ | | 4586 | | | / / S7 \ |T12| | 4587 | | | / +->\ /<-+ V V 4588 | | | / / -+----- ------- 4589 | | | / /T11 |T10 / S8 \ 4590 | | V / / V +----+ \ / 4591 | | ---+-+- ----+-- | ------- 4592 | | / S5 \T9 / S6 \<+ ^ 4593 | +-----\ /--->\ / T14 | 4594 | ------- --+----+------+T17 4595 +---------------------------+ 4597 The following state transition table represents the above diagram. 4598 Each row represents the starting state for a given transition, which 4599 after taking a transition marked in a table cell would end in the 4600 state represented by the column of the cell. For example, from state 4601 S1, the connection takes the T1 transition to arrive at state S2. The 4602 fields marked "-" correspond to undefined transitions. 4604 Julian Satran Expires February 2003 103 4605 iSCSI 5-August-02 4607 +-----+---+---+---+---+----+---+ 4608 |S1 |S2 |S4 |S5 |S6 |S7 |S8 | 4609 ---+-----+---+---+---+---+----+---+ 4610 S1| - |T1 | - | - | - | - | - | 4611 ---+-----+---+---+---+---+----+---+ 4612 S2|T2 |- |T4 | - | - | - | - | 4613 ---+-----+---+---+---+---+----+---+ 4614 S4|T7 |- |- |T5 | - | - | - | 4615 ---+-----+---+---+---+---+----+---+ 4616 S5|T8 |- |- | - |T9 |T11 |T15| 4617 ---+-----+---+---+---+---+----+---+ 4618 S6|T13 |- |- | - |T14|- |T17| 4619 ---+-----+---+---+---+---+----+---+ 4620 S7|T18 |- |- | - |T10|T12 |T16| 4621 ---+-----+---+---+---+---+----+---+ 4622 S8| - |- |- | - | - | - | - | 4623 ---+-----+---+---+---+---+----+---+ 4625 6.1.4 Standard Connection State Diagram for a Target 4627 Symbolic names for States: 4628 S1: FREE 4629 S3: XPT_UP 4630 S4: IN_LOGIN 4631 S5: LOGGED_IN 4632 S6: IN_LOGOUT 4633 S7: LOGOUT_REQUESTED 4634 S8: CLEANUP_WAIT 4636 States S5, S6 and S7 constitute the Full Feature Phase operation of 4637 the connection. 4639 The state diagram is as follows: 4641 Julian Satran Expires February 2003 104 4642 iSCSI 5-August-02 4644 -------<-------------+ 4645 +--------->/ S1 \<----+ | 4646 T13| +->\ /<-+ \ | 4647 | / ---+--- \ \ | 4648 | / | T6 \ | | 4649 | T8 | |T3 | | | 4650 | | | / |T7 | 4651 | | | / | | 4652 | | | / | | 4653 | | V / / | 4654 | | ------- / / | 4655 | | / S3 \ / | 4656 | | \ / / | T18 4657 | | ---+--- / | 4658 | | |T4 / | 4659 | | V / | 4660 | | ------- / | 4661 | | / S4 \ | 4662 | | \ / | 4663 | | ---+--- T15 | 4664 | | |T5 +--------+---------+ 4665 | | | /T16+-----+------+ | 4666 | | | / -+-----+---+ | | 4667 | | | / / S7 \ |T12| | 4668 | | | / +->\ /<-+ V V 4669 | | | / / -+----- ------- 4670 | | | / /T11 |T10 / S8 \ 4671 | | V / / V \ / 4672 | | ---+-+- ------- ------- 4673 | | / S5 \T9 / S6 \ ^ 4674 | +-----\ /--->\ / | 4675 | ------- --+----+--------+T17 4676 +---------------------------+ 4678 The following state transition table represents the above diagram, 4679 and follows the conventions described for the initiator diagram. 4681 Julian Satran Expires February 2003 105 4682 iSCSI 5-August-02 4684 +-----+---+---+---+---+----+---+ 4685 |S1 |S3 |S4 |S5 |S6 |S7 |S8 | 4686 ---+-----+---+---+---+---+----+---+ 4687 S1| - |T3 | - | - | - | - | - | 4688 ---+-----+---+---+---+---+----+---+ 4689 S3|T6 |- |T4 | - | - | - | - | 4690 ---+-----+---+---+---+---+----+---+ 4691 S4|T7 |- |- |T5 | - | - | - | 4692 ---+-----+---+---+---+---+----+---+ 4693 S5|T8 |- |- | - |T9 |T11 |T15| 4694 ---+-----+---+---+---+---+----+---+ 4695 S6|T13 |- |- | - |- |- |T17| 4696 ---+-----+---+---+---+---+----+---+ 4697 S7|T18 |- |- | - |T10|T12 |T16| 4698 ---+-----+---+---+---+---+----+---+ 4699 S8| - |- |- | - | - | - | - | 4700 ---+-----+---+---+---+---+----+---+ 4702 6.2 Connection Cleanup State Diagram for Initiators and Targets 4704 Symbolic names for states: 4706 R1: CLEANUP_WAIT (same as S8) 4707 R2: IN_CLEANUP 4708 R3: FREE (same as S1) 4710 Whenever a connection state machine (e.g., CSM-C) enters the 4711 CLEANUP_WAIT state (S8), it must go through the state transitions 4712 additionally described in the connection cleanup state diagram either 4713 a) using a separate full-feature phase connection (let's call it CSM- 4714 E) in the LOGGED_IN state in the same session, or b) using a new 4715 transport connection (let's call it CSM-I) in the FREE state that is 4716 to be added to the same session. In the CSM-E case, an explicit 4717 logout for the CID that corresponds to CSM-C (either as a connection 4718 or session logout) needs to be performed to complete the cleanup. In 4719 the CSM-I case, an implicit logout for the CID that corresponds to 4720 CSM-C needs to be performed by way of connection reinstatement (sec- 4721 tion 4.3.4) for that CID. In either case, the protocol exchanges on 4722 CSM-E or CSM-I determine the state transitions for CSM-C. Therefore, 4723 this cleanup state diagram is applicable only to the instance of the 4724 connection in cleanup (i.e., CSM-C). In the case of an implicit 4725 logout for example, CSM-C reaches FREE (R3) at the time CSM-I reaches 4726 LOGGED_IN. In the case of an explicit logout, CSM-C reaches FREE (R3) 4728 Julian Satran Expires February 2003 106 4729 iSCSI 5-August-02 4731 when CSM-E receives a successful logout response while continuing to 4732 be in the LOGGED_IN state. 4734 An initiator must initiate an explicit or implicit connection logout 4735 for a connection in the CLEANUP_WAIT state, if the initiator intends 4736 to continue using the associated iSCSI session. 4738 The following state diagram applies to both initiators and targets. 4740 ------- 4741 / R1 \ 4742 +--\ /<-+ 4743 / ---+--- \ 4744 / | \ M3 4745 M1 | |M2 | 4746 | | / 4747 | | / 4748 | | / 4749 | V / 4750 | ------- / 4751 | / R2 \ 4752 | \ / 4753 | ------- 4754 | | 4755 | |M4 4756 | | 4757 | | 4758 | | 4759 | V 4760 | ------- 4761 | / R3 \ 4762 +---->\ / 4763 ------- 4765 The following state transition table represents the above diagram, 4766 and follows the same conventions as in earlier sections. 4768 Julian Satran Expires February 2003 107 4769 iSCSI 5-August-02 4771 +----+----+----+ 4772 |R1 |R2 |R3 | 4773 -----+----+----+----+ 4774 R1 | - |M2 |M1 | 4775 -----+----+----+----+ 4776 R2 |M3 | - |M4 | 4777 -----+----+----+----+ 4778 R3 | - | - | - | 4779 -----+----+----+----+ 4781 6.2.1 State Descriptions for Initiators and Targets 4783 -R1: CLEANUP_WAIT (Same as S8) 4784 -initiator: Waiting for the internal event to initiate the 4785 cleanup processing for CSM-C. 4786 -target: Waiting for the cleanup process to start for CSM-C. 4787 -R2: IN_CLEANUP 4788 -initiator: Waiting for the connection cleanup process to 4789 conclude for CSM-C. 4790 -target: Waiting for the connection cleanup process to con- 4791 clude for CSM-C. 4792 -R3: FREE (Same as S1) 4793 -initiator: End state for CSM-C. 4794 -target: End state for CSM-C. 4796 6.2.2 State Transition Descriptions for Initiators and Targets 4798 -M1: One or more of the following events was received: 4799 -initiator: 4800 -An internal event that indicates connection state time- 4801 out. 4802 -An internal event of receiving a successful Logout 4803 response on a different connection for a "close the session" 4804 Logout. 4805 -target: 4806 -An internal event that indicates connection state time- 4807 out. 4808 -An internal event of sending a Logout response (success) 4809 on a different connection for a "close the session" Logout 4810 request. 4812 -M2: An implicit/explicit logout process was initiated by the initi- 4813 ator. 4814 -In CSM-I usage: 4816 Julian Satran Expires February 2003 108 4817 iSCSI 5-August-02 4819 -initiator: An internal event requesting the connection 4820 (or session) reinstatement was received, thus prompting a 4821 connection (or session) reinstatement Login to be sent tran- 4822 sitioning CSM-I to state IN_LOGIN. 4823 -target: A connection/session reinstatement Login was 4824 received while in state XPT_UP. 4825 -In CSM-E usage: 4826 -initiator: An internal event that indicates that an 4827 explicit logout was sent for this CID in state LOGGED_IN. 4828 -target: An explicit logout was received for this CID in 4829 state LOGGED_IN. 4830 -M3: Logout failure detected 4831 -In CSM-I usage: 4832 -initiator: CSM-I failed to reach LOGGED_IN and arrived 4833 into FREE instead. 4834 -target: CSM-I failed to reach LOGGED_IN and arrived into 4835 FREE instead. 4836 -In CSM-E usage: 4837 -initiator: CSM-E either moved out of LOGGED_IN, or Logout 4838 timed out and/or aborted, or Logout response (failure) was 4839 received. 4840 -target: CSM-E either moved out of LOGGED_IN, or Logout 4841 timed out and/or aborted, or an internal event that indicates 4842 a failed Logout processing was received. A Logout response 4843 (failure) was sent in the last case. 4845 -M4: Successful implicit/explicit logout was performed. 4846 - In CSM-I usage: 4847 -initiator: CSM-I reached state LOGGED_IN, or an internal 4848 event of receiving a Logout response (success) on another 4849 connection for a "close the session" Logout request was 4850 received. 4851 -target: CSM-I reached state LOGGED_IN, or an internal 4852 event of sending a Logout response (success) on a different 4853 connection for a "close the session" Logout request was 4854 received. 4855 - In CSM-E usage: 4856 -initiator: CSM-E stayed in LOGGED_IN and received a 4857 Logout response (success), or an internal event of receiving 4858 a Logout response (success) on another connection for a 4859 "close the session" Logout request was received. 4861 Julian Satran Expires February 2003 109 4862 iSCSI 5-August-02 4864 -target: CSM-E stayed in LOGGED_IN and an internal event 4865 indicating a successful Logout processing was received, or 4866 an internal event of sending a Logout response (success) on a 4867 different connection for a "close the session" Logout 4868 request was received. 4870 6.3 Session State Diagrams 4872 Session State Diagram for an Initiator 4874 Symbolic Names for States: 4876 Q1: FREE 4877 Q3: LOGGED_IN 4878 Q4: FAILED 4879 State Q3 represents the Full Feature Phase operation of the session. 4881 The state diagram is as follows: 4883 ------- 4884 / Q1 \ 4885 +------>\ /<-+ 4886 / ---+--- | 4887 / | |N3 4888 N6 | |N1 | 4889 | | | 4890 | N4 | | 4891 | +--------+ | / 4892 | | | | / 4893 | | | | / 4894 | | V V / 4895 -+--+-- -----+- 4896 / Q4 \ N5 / Q3 \ 4897 \ /<---\ / 4898 ------- ------- 4900 State transition table: 4902 Julian Satran Expires February 2003 110 4903 iSCSI 5-August-02 4905 +----+----+----+ 4906 |Q1 |Q3 |Q4 | 4907 -----+----+----+----+ 4908 Q1 | - |N1 | - | 4909 -----+----+----+----+ 4910 Q3 |N3 | - |N5 | 4911 -----+----+----+----+ 4912 Q4 |N6 |N4 | - | 4913 -----+----+----+----+ 4915 6.3.1 Session State Diagram for a Target 4917 Symbolic Names for States: 4919 Q1: FREE 4920 Q2: ACTIVE 4921 Q3: LOGGED_IN 4922 Q4: FAILED 4923 Q5: IN_CONTINUE 4925 State Q3 represents the Full Feature Phase operation of the session. 4927 The state diagram is as follows: 4929 Julian Satran Expires February 2003 111 4930 iSCSI 5-August-02 4932 ------- 4933 +------------------>/ Q1 \ 4934 / +-------------->\ /<-+ 4935 | | ---+--- | 4936 | | ^ | |N3 4937 N6 | |N11 N9| V N1 | 4938 | | +------ | 4939 | | / Q2 \ | 4940 | | \ / | 4941 | --+---- +--+--- | 4942 | / Q5 \ | | 4943 | \ / N10 | | 4944 | +-+---+------------+ |N2 / 4945 | ^ | | | / 4946 |N7| |N8 | | / 4947 | | | | V / 4948 -+--+-V V----+- 4949 / Q4 \ N5 / Q3 \ 4950 \ /<-------------\ / 4951 ------- ------- 4953 State transition table: 4955 +----+----+----+----+----+ 4956 |Q1 |Q2 |Q3 |Q4 |Q5 | 4957 -----+----+----+----+----+----+ 4958 Q1 | - |N1 | - | - | - | 4959 -----+----+----+----+----+----+ 4960 Q2 |N9 | - |N2 | - | - | 4961 -----+----+----+----+----+----+ 4962 Q3 |N3 | - | - |N5 | - | 4963 -----+----+----+----+----+----+ 4964 Q4 |N6 | - | - | - |N7 | 4965 -----+----+----+----+----+----+ 4966 Q5 |N11 | - |N10 |N8 | - | 4967 -----+----+----+----+----+----+ 4969 6.3.2 State Descriptions for Initiators and Targets 4971 -Q1: FREE 4972 -initiator: State on instantiation or after cleanup. 4973 -target: State on instantiation or after cleanup. 4975 Julian Satran Expires February 2003 112 4976 iSCSI 5-August-02 4978 -Q2: ACTIVE 4979 -initiator: Illegal 4980 -target: The first iSCSI connection in the session transi- 4981 tioned to IN_LOGIN, waiting for it to complete the login 4982 process. 4983 -Q3: LOGGED_IN 4984 -initiator: Waiting for all session events. 4985 -target: Waiting for all session events. 4986 -Q4: FAILED 4987 -initiator: Waiting for session recovery or session continua- 4988 tion. 4989 -target: Waiting for session recovery or session continua- 4990 tion. 4991 -Q5: IN_CONTINUE 4992 -initiator: Illegal 4993 -target: Waiting for session continuation attempt to reach a 4994 conclusion. 4996 6.3.3 State Transition Descriptions for Initiators and Targets 4998 -N1: 4999 -initiator: At least one transport connection reached the 5000 LOGGED_IN state. 5001 -target: The first iSCSI connection in the session had 5002 reached the IN_LOGIN state. 5003 -N2: 5004 -initiator: Illegal 5005 -target: At least one iSCSI connection reached the LOGGED_IN 5006 state. 5007 -N3: 5008 -initiator: Graceful closing of the session via session clo- 5009 sure (Section 4.3.6 Session continuation and failure). 5010 -target: Graceful closing of the session via session closure 5011 (Section 4.3.6 Session continuation and failure). Or a suc- 5012 cessful session reinstatement cleanly closed the session. 5013 -N4: 5014 -initiator: A session continuation attempt succeeded. 5015 -target: Illegal 5016 -N5: 5017 -initiator: Session failure (Section 4.3.6 Session continua- 5018 tion and failure) occurred. 5020 Julian Satran Expires February 2003 113 5021 iSCSI 5-August-02 5023 -target: Session failure (Section 4.3.6 Session continuation 5024 and failure) occurred. 5025 -N6: 5026 -initiator: Session state timeout occurred, or a session 5027 reinstatement cleared this session instance. This results 5028 in the freeing of all associated resources and the session 5029 state is discarded. 5030 -target: Session state timeout occurred, or a session rein- 5031 statement cleared this session instance. This results in 5032 the freeing of all associated resources and the session 5033 state is discarded. 5034 -N7: 5035 -initiator: Illegal 5036 -target: A session continuation attempt is initiated. 5037 -N8: 5038 -initiator: Illegal 5039 -target: The last session continuation attempt failed. 5040 -N9: 5041 -initiator: Illegal 5042 -target: Login attempt on the leading connection failed. 5043 -N10: 5044 -initiator: Illegal 5045 -target: A session continuation attempt succeeded. 5046 -N11: 5047 -initiator: Illegal 5048 -target: A successful session reinstatement cleanly closed 5049 the session. 5051 Julian Satran Expires February 2003 114 5052 iSCSI 5-August-02 5054 7. Security Considerations 5056 Historically, native storage systems have not had to consider secu- 5057 rity because their environments offered minimal security risks. That 5058 is, these environments consisted of storage devices either directly 5059 attached to hosts or connected via a Storage Area Network (SAN) dis- 5060 tinctly separate from the communications network. The use of storage 5061 protocols, such as SCSI, over IP-networks requires that security con- 5062 cerns be addressed. iSCSI implementations MUST provide means of pro- 5063 tection against active attacks (e.g., pretending to be another 5064 identity, message insertion, deletion, modification, and replaying) 5065 and passive attacks (e.g.,eavesdropping, gaining advantage by analyz- 5066 ing the data sent over the line). 5068 Although technically possible, iSCSI SHOULD NOT be configured with- 5069 out security. iSCSI configured without security should be confined, 5070 in extreme cases, to closed environments without any security risk. 5072 The following section describes the security mechanisms provided by 5073 an iSCSI implementation. 5075 7.1 iSCSI Security Mechanisms 5077 The entities involved in iSCSI security are the initiator, target, 5078 and the IP communication end points. iSCSI scenarios where multiple 5079 initiators or targets share a single communication end point are 5080 expected. To accommodate such scenarios, iSCSI uses two separate 5081 security mechanisms: In-band authentication between the initiator and 5082 the target at the iSCSI connection level (carried out by exchange of 5083 iSCSI Login PDUs), and packet protection (integrity, authentication, 5084 and confidentiality) by IPsec at the IP level. The two security mech- 5085 anisms complement each other: The in-band authentication provides 5086 end-to-end trust (at login time) between the iSCSI initiator and the 5087 target, while IPsec provides a secure channel between the IP communi- 5088 cation end points. 5090 Further details on typical iSCSI scenarios and the relation between 5091 the initiators, targets, and the communication end points can be 5092 found in [SEC-IPS]. 5094 Julian Satran Expires February 2003 115 5095 iSCSI 5-August-02 5097 7.2 In-band Initiator-Target Authentication 5099 During login the target MUST authenticate the initiator and the ini- 5100 tiator MAY authenticate the target. The authentication is performed 5101 on every new iSCSI connection by an exchange of iSCSI Login PDUs 5102 using a negotiated authentication method. 5104 The authentication method cannot assume an underlying IPsec protec- 5105 tion, because IPsec is optional to use. An attacker should gain as 5106 little advantage as possible by inspecting the authentication phase 5107 PDUs. Therefore, a method using clear text (or equivalent) passwords 5108 is not acceptable; on the other hand, identity protection is not 5109 strictly required. 5111 The authentication mechanism protects against an unauthorized login 5112 to storage resources by using a false identity (spoofing). Once the 5113 authentication phase is completed, if the underlying IPsec is not 5114 used, all PDUs are sent and received in clear. The authentication 5115 mechanism alone (without underlying IPsec) should only be used when 5116 there is no risk of eavesdropping, message insertion, deletion, modi- 5117 fication, and replaying. 5119 Section 10 iSCSI Security Keys and Authentication Methods defines 5120 several authentication methods and the exact steps that must be fol- 5121 lowed in each of them, including the keys and their allowed values in 5122 each step. Whenever an iSCSI initiator gets a response whose keys, or 5123 their values, are not according to the step definition, it MUST abort 5124 the connection. Whenever an iSCSI target gets a response whose keys, 5125 or their values, are not according to the step definition, it MUST 5126 answer with a Login reject with the "Initiator Error" or "Missing 5127 Parameter" status (these statuses are not intended for cryptographi- 5128 cally incorrect value, e.g., the CHAP response, for which "Authenti- 5129 cation Failure" status MUST be specified). The importance of this 5130 rule can be illustrated in CHAP with target authentication (Section 5131 10.1.4 Challenge Handshake Authentication Protocol (CHAP)) where the 5132 initiator would have been able to conduct a reflection attack by 5133 omitting his response key (CHAP_R), using the same CHAP challenge as 5134 the target and reflecting the target's response back to the target. 5135 In CHAP this is prevented since the target must answer the missing 5136 CHAP_R key with a Login reject with the "Missing Parameter" status. 5138 Julian Satran Expires February 2003 116 5139 iSCSI 5-August-02 5141 7.2.1 CHAP Considerations 5143 Compliant iSCSI initiators and targets MUST implement the CHAP 5144 authentication method [RFC1994] (according to Section 10.1.4 Chal- 5145 lenge Handshake Authentication Protocol (CHAP) including the target 5146 authentication option). 5148 When CHAP is performed over a non-encrypted channel, it is vulnera- 5149 ble to an off-line dictionary attack. Implementations MUST support 5150 use of up to 128 bits random CHAP secrets, including the means to 5151 generate such secrets and to accept them from an external generation 5152 source. Implementations MUST NOT provide secret generation (or expan- 5153 sion) means other than random generation. 5155 An administrative entity of an environment in which CHAP is used with 5156 a secret that has less than 96 random bits MUST enforce IPsec encryp- 5157 tion (according to the implementation requirements in Section 7.3.2 5158 Confidentiality) to protect the connection. Moreover, in this case 5159 IKE authentication with group pre-shared keys SHOULD NOT be used 5160 unless it is not essential to protect group members against off-line 5161 dictionary attacks by other members. 5163 A compliant implementation SHOULD NOT continue with the login step in 5164 which it should send a CHAP response (CHAP_R - Section 10.1.4 Chal- 5165 lenge Handshake Authentication Protocol (CHAP)) unless it can verify 5166 that either the CHAP secret is at least 96 bits, or that IPsec 5167 encryption is being used to protect the connection. 5169 Originators MUST NOT reuse the CHAP challenge sent by the Responder 5170 for the other direction of a bidirectional authentication. Respond- 5171 ers MUST check for this condition and close the iSCSI TCP connection 5172 if it occurs. 5174 7.2.2 SRP Considerations 5176 The strength of the SRP authentication method (specified in 5177 [RFC2945]) is dependent on the characteristics of the group being 5178 used (i.e., the prime modulus N and generator g). As described in 5179 [RFC2945], N is required to be a Sophie-German prime (of the form N = 5180 2q + 1, where q is also prime) and the generator g is a primitive 5181 root of GF(n). In iSCSI authentication, the prime modulus N MUST be 5182 at least 768 bits. 5184 The list of allowed SRP groups is provided in [SEC-IPS]. 5186 Julian Satran Expires February 2003 117 5187 iSCSI 5-August-02 5189 7.3 IPsec 5191 The IPsec mechanism is used by iSCSI for packet protection (crypto- 5192 graphic integrity, authentication, and confidentiality) at the IP 5193 level between the iSCSI communicating end points. The following sec- 5194 tions describe the IPsec protocols that must be implemented for data 5195 integrity and authentication, confidentiality, and key management. 5197 An iSCSI initiator or target may provide the required IPsec support 5198 either fully integrated or in conjunction with an IPsec front-end 5199 device. In the latter case, the compliance requirements with regard 5200 to IPsec support apply to the "combined device" and only the "com- 5201 bined device" is to be considered an iSCSI device. 5203 Detailed considerations and recommendations for using IPsec for iSCSI 5204 are provided in [SEC-IPS]. 5206 7.3.1 Data Integrity and Authentication 5208 Data authentication and integrity is provided by a keyed Message 5209 Authentication Code in every sent packet. This code protects against 5210 message insertion, deletion, and modification. Protection against 5211 message replay is realized by using a sequence counter. 5213 An iSCSI compliant initiator or target MUST provide data integrity 5214 and authentication by implementing IPsec [RFC2401] with ESP [RFC2406] 5215 in tunnel mode and MAY provide data integrity and authentication by 5216 implementing IPsec with ESP in transport mode. The IPsec implementa- 5217 tion MUST fulfill the following iSCSI specific requirements: 5219 - HMAC-SHA1 MUST be implemented [RFC2404]. 5220 - AES CBC MAC with XCBC extensions SHOULD be implemented 5221 [AESCBC]. 5223 The ESP anti-replay service MUST also be implemented. 5225 At the high speeds iSCSI is expected to operate, a single IPsec SA 5226 could rapidly cycle through the 32-bit IPsec sequence number space. 5227 In view of this, in the future it may be desirable for an iSCSI 5228 implementation that operates at speeds of 1 Gbps or faster to imple- 5229 ment the IPsec sequence number extension [SEQ-EXT]. 5231 Julian Satran Expires February 2003 118 5232 iSCSI 5-August-02 5234 7.3.2 Confidentiality 5236 Confidentiality is provided by encrypting the data in every packet. 5237 When confidentiality is used it MUST be accompanied by data integ- 5238 rity and authentication to provide comprehensive protection against 5239 eavesdropping, message insertion, deletion, modification, and replay- 5240 ing. 5242 An iSCSI compliant initiator or target MUST provide confidentiality 5243 by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and 5244 MAY provide confidentiality by implementing IPsec with ESP in trans- 5245 port mode. with the following iSCSI specific requirements: 5247 - 3DES in CBC mode MUST be implemented [RFC2451]. 5248 - AES in Counter mode SHOULD be implemented [AESCTR]. 5250 DES in CBC mode SHOULD NOT be used due to its inherent weakness. 5251 The NULL encryption algorithm MUST also be implemented. 5253 7.3.3 Policy, Security Associations and Key Management 5255 A compliant iSCSI implementation MUST meet the key management 5256 requirements of the IPsec protocol suite. Authentication, security 5257 association negotiation, and key management MUST be provided by 5258 implementing IKE [RFC2409] using the IPsec DOI [RFC2407] with the 5259 following iSCSI specific requirements: 5261 - Peer authentication using a pre-shared key MUST be sup- 5262 ported. Certificate-based peer authentication using digital 5263 signatures MAY be supported. Peer authentication using the 5264 public key encryption methods outlined in IKE sections 5.2 5265 and 5.3[7] SHOULD NOT be used. 5267 - When digital signatures are used to achieve authentication, 5268 an IKE negotiator SHOULD use IKE Certificate Request Pay- 5269 load(s) to specify the certificate authority. IKE negotia- 5270 tors SHOULD check the pertinent Certificate Revocation List 5271 (CRL) before accepting a PKI certificate for use in IKE 5272 authentication procedures. 5274 - Conformant iSCSI implementations MUST support IKE Main Mode 5275 and SHOULD support Aggressive Mode. IKE main mode with pre- 5276 shared key authentication method SHOULD NOT be used when 5277 either the initiator or the target uses dynamically assigned 5278 IP addresses. While pre-shared keys in many cases offer good 5279 security, situations where dynamically assigned addresses are 5281 Julian Satran Expires February 2003 119 5282 iSCSI 5-August-02 5284 used force the use of a group pre-shared key, which creates 5285 vulnerability to a man-in-the-middle attack. 5287 - In the IKE Phase 2 Quick Mode exchanges for creating the 5288 Phase 2 SA, the Identity Payload fields MUST be present. 5289 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports 5290 IPv6) and ID_FQDN Identity payloads MUST be supported; 5291 ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address 5292 Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN formats SHOULD NOT be 5293 used. The ID_KEY_ID Identity Payload MUST NOT be used. 5295 Manual keying MUST NOT be used because it does not provide the neces- 5296 sary re-keying support. 5298 When IPsec is used the receipt of an IKE Phase 2 delete message 5299 SHOULD NOT be interpreted as a reason for tearing down the iSCSI TCP 5300 connection. If additional traffic is sent on it, a new IKE Phase 2 SA 5301 will be created to protect it. 5303 The method used by the initiator to determine whether the target 5304 should be connected using IPsec is regarded as an issue of IPsec pol- 5305 icy administration, and thus not defined in the iSCSI standard. 5307 If an iSCSI target is discovered via a SendTargets request in a dis- 5308 covery session not using IPsec, the initiator should assume that it 5309 does not need IPsec to establish a session to that target. If an 5310 iSCSI target is discovered using a discovery session that does use 5311 IPsec, the initiator SHOULD use IPsec when establishing a session to 5312 that target. 5314 Julian Satran Expires February 2003 120 5315 iSCSI 5-August-02 5317 8. Notes to Implementers 5319 This section notes some of the performance and reliability consider- 5320 ations of the iSCSI protocol. This protocol was designed to allow 5321 efficient silicon and software implementations. The iSCSI task tag 5322 mechanism was designed to enable Direct Data Placement (DDP - a DMA 5323 form) at the iSCSI level or lower. 5325 The guiding assumption made throughout the design of this protocol is 5326 that targets are resource constrained relative to initiators. 5328 Implementers are also advised to consider the implementation conse- 5329 quences of the iSCSI to SCSI mapping model as outlined in Section 5330 2.4.3 Consequences of the Model. 5332 8.1 Multiple Network Adapters 5334 The iSCSI protocol allows multiple connections, not all of which need 5335 to go over the same network adapter. If multiple network connections 5336 are to be utilized with hardware support, the iSCSI protocol command- 5337 data-status allegiance to one TCP connection ensures that there is no 5338 need to replicate information across network adapters or otherwise 5339 require them to cooperate. 5341 However, some task management commands may require some loose form of 5342 cooperation or replication at least on the target. 5344 8.1.1 Conservative Reuse of ISIDs 5346 Historically, the SCSI model (and implementations and applications 5347 based on that model) has assumed that SCSI ports are static, physi- 5348 cal entities. Recent extensions to the SCSI model have taken advan- 5349 tage of persistent worldwide unique names for these ports. In iSCSI 5350 however, the SCSI initiator ports are the endpoints of dynamically 5351 created sessions, so the presumption of "static and physical" does 5352 not apply. In any case, the model clauses (particularly, Section 5353 2.4.2 SCSI Architecture Model) provide for persistent, reusable names 5354 for the iSCSI-type SCSI initiator ports even though there does not 5355 need to be any physical entity bound to these names. 5357 To both minimize the disruption of legacy applications and to better 5358 facilitate the SCSI features that rely on persistent names for SCSI 5359 ports, iSCSI implementations SHOULD attempt to provide a stable pre- 5361 Julian Satran Expires February 2003 121 5362 iSCSI 5-August-02 5364 sentation of SCSI Initiator Ports (both to the upper OS-layers and to 5365 the targets to which they connect). This can be achieved in an initi- 5366 ator implementation by conservatively reusing ISIDs. In other words, 5367 the same ISID should be used in the Login process to multiple target 5368 portal groups (of the same iSCSI Target or different iSCSI Targets). 5369 The ISID RULE (Section 2.4.3 Consequences of the Model) only prohib- 5370 its reuse to the same target portal group. It does not "preclude" 5371 reuse to other target portal groups. 5372 The principle of conservative reuse "encourages" reuse to other tar- 5373 get portal groups. When a SCSI target device sees the same (Initia- 5374 torName, ISID) pair in different sessions to different target portal 5375 groups, it can identify the underlying SCSI Initiator Port on each 5376 session as the same SCSI port. In effect, it can recognize multiple 5377 paths from the same source. 5379 8.1.2 iSCSI Name, ISID and TPGT Use 5381 The designers of the iSCSI protocol envisioned there being one iSCSI 5382 Initiator Node Name per operating system image on a machine. This 5383 enables SAN resource configuration and authentication schemes based 5384 on a system's identity. It supports the notion that it should be pos- 5385 sible to assign access to storage resources based on "initiator 5386 device" identity. 5388 When there are multiple hardware or software components coordinated 5389 as a single iSCSI Node, there must be some (logical) entity that rep- 5390 resents the iSCSI Node that makes the iSCSI Node Name available to 5391 all components involved in session creation and login. Similarly, 5392 this entity that represents the iSCSI Node must be able to coordi- 5393 nate session identifier resources (ISID for initiators) to enforce 5394 both the ISID and TSIH RULES (see Section Section 2.4.3 Consequences 5395 of the Model). 5397 For targets, because of the closed environment, implementation of 5398 this entity should be straightforward. However, vendors of iSCSI 5399 hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide 5400 mechanisms for configuration of the iSCSI Node Name across the por- 5401 tal groups instantiated by multiple instances of these components 5402 within a target. 5404 However, complex targets making use of multiple Target Portal Group 5405 Tags may reconfigure them to achieve various quality goals. The ini- 5406 tiators have two mechanisms at their disposal to discover and/or 5408 Julian Satran Expires February 2003 122 5409 iSCSI 5-August-02 5411 check reconfiguring targets - the discovery session type and a key 5412 returned by the target during login to confirm the TPGT. An initia- 5413 tor should attempt to "rediscover" the target configuration anytime a 5414 session is terminated unexpectedly. 5416 For initiators, in the long term, it is expected that operating sys- 5417 tem vendors will take on the role of this entity and provide stan- 5418 dard APIs that can inform components of their iSCSI Node Name and can 5419 configure and/or coordinate ISID allocation, use and reuse. 5421 Recognizing that such initiator APIs are not available today, other 5422 implementations of the role of this entity are possible. For exam- 5423 ple, a human may instantiate the (common) Node name as part of the 5424 installation process of each iSCSI component involved in session cre- 5425 ation and login. This may be done either by pointing the component to 5426 a vendor-specific location for this datum or to a system-wide loca- 5427 tion. The structure of the ISID namespace (see Section 9.12.5 ISID 5428 and [NDT]) facilitates implementation of the ISID coordination by 5429 allowing each component vendor to independently (of other vendor's 5430 components) coordinate allocation and use and reuse its own parti- 5431 tion of the ISID namespace in a vendor-specific manner. Partitioning 5432 of the ISID namespace within initiator portal groups managed by that 5433 vendor allows each such initiator portal group to act independently 5434 of all other portal groups when selecting an ISID for a login; this 5435 facilitates enforcement of the ISID RULE (see Section 2.4.3 Conse- 5436 quences of the Model) at the initiator. 5438 A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in 5439 the initiators MUST implement a mechanism for configuring the iSCSI 5440 Node Name. Vendors, and administrators must ensure that iSCSI Node 5441 Names are unique worldwide. It is therefore important that when one 5442 chooses to reuse the iSCSI Node Name of a disabled unit, not to re- 5443 assign that name to the original unit unless its worldwide unique- 5444 ness can be ascertained again. 5446 In addition a vendor of iSCSI hardware must implement a mechanism to 5447 configure and/or coordinate ISIDs for all sessions managed by multi- 5448 ple instances of that hardware within a given iSCSI Node. Such con- 5449 figuration might be either permanently pre-assigned at the factory 5450 (in a necessarily globally unique way), statically assigned (e.g., 5451 partitioned across all the NICs at initialization in a locally unique 5452 way), or dynamically assigned (e.g., on-line allocator, also in a 5453 locally unique way). In the latter two cases, the configuration may 5455 Julian Satran Expires February 2003 123 5456 iSCSI 5-August-02 5458 be via public APIs (perhaps driven by an independent vendor's soft- 5459 ware, such as the OS vendor) or via private APIs driven by the ven- 5460 dor's own software. 5462 8.2 Autosense and Auto Contingent Allegiance (ACA) 5464 Autosense refers to the automatic return of sense data to the initia- 5465 tor in case a command did not complete successfully. iSCSI initia- 5466 tors and targets MUST support and use autosense. 5468 ACA helps preserve ordered command execution in the presence of 5469 errors. As iSCSI can have many commands in-flight between initiator 5470 and target, iSCSI initiators and targets SHOULD support ACA. 5472 8.3 iSCSI timeouts 5474 iSCSI recovery actions are often dependent on iSCSI time-outs being 5475 recognized and acted upon before SCSI time-outs. Determining the 5476 right time-outs to use for various iSCSI actions (command acknowl- 5477 edgements expected, status acknowledgements, etc.) is very much 5478 dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI 5479 driver). As a guidance the implementer may use an average Nop-Out/ 5480 Nop-In turnaround delay multiplied by a "safety factor" (e.g., 4) 5481 with a minimum of several milliseconds as a good estimate for the 5482 basic delay of the iSCSI stack for a given connection. 5484 The relation between iSCSI timeouts and SCSI timeouts should also be 5485 considered. SCSI timeouts should be longer than iSCSI timeouts plus 5486 the time required for iSCSI recovery whenever iSCSI recovery is 5487 planned. Alternatively an implementer may choose to interlock iSCSI 5488 timeouts and recovery with SCSI timeouts so that SCSI will recovery 5489 will become active only where iSCSI is not planned to or failed to 5490 recover. 5492 The implementer may want to consider also the interaction between 5493 various iSCSI exception events - like a digest failure - and subse- 5494 quent timeouts. When iSCSI error recovery is active a digest failure 5495 is likely to result in discovering a missing command or data PDU. In 5496 those cases an implementer may want to lower the timeout values to 5497 enable faster initiation for recovery procedures. 5499 Julian Satran Expires February 2003 124 5500 iSCSI 5-August-02 5502 8.4 Command Retry and Cleaning Old Command Instances 5504 To avoid having old, retried command instances appear in a valid com- 5505 mand window after a command sequence number wrap around, the proto- 5506 col requires (see Section 2.2.2.1 Command Numbering and 5507 Acknowledging) that on every connection on which a retry has been 5508 issued, a non-immediate command be issued and acknowledged within a 5509 2**31-1 commands interval from the CmdSN of the retried command. This 5510 requirement can be fulfilled by an implementation in several ways. 5512 The simplest technique to use is to send a (non-retry) non-immediate 5513 SCSI command (or a NOP if no SCSI command is available for a while) 5514 after every command retry on the connection on which the retry was 5515 attempted. As errors are deemed rare events, this technique is proba- 5516 bly the most effective, as it does not involve additional checks at 5517 the initiator when issuing commands. 5519 8.5 Synch and Steering Layer and Performance 5521 While a synch and steering layer is optional, an initiator/target 5522 that does not have it working against a target/initiator that demands 5523 synch and steering may experience performance degradation caused by 5524 packet reordering and loss. Providing a synch and steering mechanism 5525 is recommended for all high-speed implementations. 5527 8.6 Considerations for State-dependent devices and long lasting SCSI 5528 operations. 5530 Sequential access devices operate on the principle that the position 5531 of the device is based on the last command processed. As such, com- 5532 mand processing order and knowledge of whether or not the previous 5533 command was processed is of the utmost importance to maintain data 5534 integrity. As an example, inadvertent retries of SCSI commands when 5535 it is not known if the previous SCSI command was processed is a 5536 potential data integrity risk. 5538 For a sequential access device, consider the scenario where a SCSI 5539 SPACE command to backspace one filemark is issued and then re-issued 5540 due to no status received for the command. If the first SPACE com- 5541 mand was actually processed, the re-issued SPACE command, if pro- 5542 cessed, will cause the position to change. Thus, a subsequent write 5543 operation will write data to the wrong position and any previous data 5544 at that position will be overwritten. 5546 Julian Satran Expires February 2003 125 5547 iSCSI 5-August-02 5549 For a medium changer device, consider the scenario where an EXCHANGE 5550 MEDIUM command (the SOURCE ADDRESS and DESTINATION ADDRESS are the 5551 same thus performing a swap) is issued and then re-issued due to no 5552 status received for the command. If the first EXCHANGE MEDIUM com- 5553 mand was actually processed, the re-issued EXCHANGE MEDIUM command, 5554 if processed, will perform the swap again. The net effect is no swap 5555 was performed thus leaving a data integrity exposure. 5557 All commands that change the state of the device (as in SPACE com- 5558 mands for sequential access devices, and EXCHANGE MEDIUM for medium 5559 changer device), MUST be issued as non-immediate commands for deter- 5560 ministic and in order delivery to iSCSI targets. 5562 For many of those state changing commands the execution model also 5563 assumes that the command is executed exactly once. Devices implement- 5564 ing READ POSITION and LOCATE provide a means for SCSI level command 5565 recovery and new tape-class devices should support those commands. 5566 In their absence a retry at SCSI level is difficult and error recov- 5567 ery at iSCSI level is advisable. 5569 Devices operating on long latency delivery subsystems and performing 5570 long lasting SCSI operations may need mechanism that enable connec- 5571 tion replacement while commands are running (e.g., during a an 5572 extended copy operation). 5574 8.6.1 Determining the proper ErrorRecoveryLevel 5576 The implementation and usage of a specific ErrorRecoveryLevel should 5577 be determined based on the deployment scenarios of a given iSCSI 5578 implementation. Generally, the following factors must be 5579 considered before deciding on the proper level of recovery: 5581 a) Application resilience to I/O failures. 5582 b) Required level of availability in the face of transport con- 5583 nection failures. 5584 c) Probability of transport layer "checksum escape" frequency. 5585 This in turn decides the iSCSI digest failure frequency, and thus 5586 the criticality of iSCSI-level error recovery. The details of 5587 estimating this probability are outside the scope of this docu- 5588 ment. 5590 Julian Satran Expires February 2003 126 5591 iSCSI 5-August-02 5593 A consideration of the above factors for SCSI tape devices as an 5594 example suggests that implementations SHOULD use ErrorRecovery- 5595 Level=1 when transport connection failure is not a concern and SCSI 5596 level recovery is unavailable, and ErrorRecoveryLevel=2 when the con- 5597 nection failure is also of high likelihood during a backup/retrieval. 5599 For extended copy operations implementations SHOULD use ErrorRecov- 5600 eryLevel=2 whenever connection failure has a relatively high likeli- 5601 hood. 5603 Julian Satran Expires February 2003 127 5604 iSCSI 5-August-02 5606 9. iSCSI PDU Formats 5608 All multi-byte integers that are specified in formats defined in this 5609 document are to be represented in network byte order (i.e., big 5610 endian). Any field that appears in this document assumes that the 5611 most significant byte is the lowest numbered byte and the most sig- 5612 nificant bit (within byte or field) is the lowest numbered bit unless 5613 specified otherwise. 5615 Any compliant sender MUST set all bits not defined and all reserved 5616 fields to zero unless specified otherwise. Any compliant receiver 5617 MUST ignore any bit not defined and all reserved fields unless speci- 5618 fied otherwise. Receipt of reserved code values in defined fields 5619 MUST be reported as a protocol error. 5621 Reserved fields are marked by the word "reserved", some abbreviation 5622 of "reserved" or by "." for individual bits when no other form of 5623 marking is technically feasible. 5625 9.1 iSCSI PDU Length and Padding 5627 iSCSI PDUs are padded to the closest integer number of four byte 5628 words. The padding bytes SHOULD be sent as 0. 5630 9.2 PDU Template, Header, and Opcodes 5632 All iSCSI PDUs have one or more header segments and, optionally, a 5633 data segment. After the entire header segment group a header-digest 5634 MAY follow. The data segment MAY also be followed by a data-digest. 5636 The Basic Header Segment (BHS) is the first segment in all of the 5637 iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It 5638 MAY be followed by Additional Header Segments (AHS), a Header-Digest, 5639 a Data Segment, and/or a Data-Digest. 5641 The overall structure of an iSCSI PDU is as follows: 5643 Julian Satran Expires February 2003 128 5644 iSCSI 5-August-02 5646 Byte/ 0 | 1 | 2 | 3 | 5647 / | | | | 5648 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 5649 +---------------+---------------+---------------+---------------+ 5650 0/ Basic Header Segment (BHS) / 5651 +/ / 5652 +---------------+---------------+---------------+---------------+ 5653 48/ Additional Header Segment 1 (AHS) (optional) / 5654 +/ / 5655 +---------------+---------------+---------------+---------------+ 5656 / Additional Header Segment 2 (AHS) (optional) / 5657 +/ / 5658 +---------------+---------------+---------------+---------------+ 5659 ---- 5660 +---------------+---------------+---------------+---------------+ 5661 / Additional Header Segment n (AHS) (optional) / 5662 +/ / 5663 +---------------+---------------+---------------+---------------+ 5664 ---- 5665 +---------------+---------------+---------------+---------------+ 5666 k/ Header-Digest (optional) / 5667 +/ / 5668 +---------------+---------------+---------------+---------------+ 5669 l/ Data Segment(optional) / 5670 +/ / 5671 +---------------+---------------+---------------+---------------+ 5672 m/ Data-Digest (optional) / 5673 +/ / 5674 +---------------+---------------+---------------+---------------+ 5676 All PDU segments and digests are padded to the closest integer num- 5677 ber of four byte words - i.e., all PDU segments and the digests start 5678 at a four byte word boundary and the padding ranges from 0 to 3 5679 bytes. The padding bytes SHOULD be sent as 0. 5681 iSCSI response PDUs do not have AH Segments. 5683 9.2.1 Basic Header Segment (BHS) 5685 The BHS is 48 bytes long. The Opcode and DataSegmentLength fields 5686 appear in all iSCSI PDUs. In addition, when used, the Initiator Task 5687 Tag and Logical Unit Number always appear in the same location in the 5688 header. 5690 Julian Satran Expires February 2003 129 5691 iSCSI 5-August-02 5693 The format of the BHS is: 5695 Byte/ 0 | 1 | 2 | 3 | 5696 / | | | | 5697 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 5698 +---------------+---------------+---------------+---------------+ 5699 0|.|I| Opcode |F| Opcode-specific fields | 5700 +---------------+---------------+---------------+---------------+ 5701 4|TotalAHSLength | DataSegmentLength | 5702 +---------------+---------------+---------------+---------------+ 5703 8| LUN or Opcode-specific fields | 5704 + + 5705 12| | 5706 +---------------+---------------+---------------+---------------+ 5707 16| Initiator Task Tag | 5708 +---------------+---------------+---------------+---------------+ 5709 20/ Opcode-specific fields / 5710 +/ / 5711 +---------------+---------------+---------------+---------------+ 5712 48 5714 9.2.1.1 I 5716 For request PDUs, the I bit set to 1 is an immediate delivery marker. 5718 9.2.1.2 Opcode 5720 The Opcode indicates the type of iSCSI PDU the header encapsulates. 5722 The Opcodes are divided into two categories: initiator opcodes and 5723 target opcodes. Initiator opcodes are in PDUs sent by the initiators 5724 (request PDUs). Target opcodes are in PDUs sent by the target 5725 (response PDUs). 5727 Initiators MUST NOT use target opcodes and targets MUST NOT use ini- 5728 tiator opcodes. 5730 Initiator opcodes defined in this specification are: 5732 0x00 NOP-Out 5734 Julian Satran Expires February 2003 130 5735 iSCSI 5-August-02 5737 0x01 SCSI Command (encapsulates a SCSI Command Descriptor 5738 Block) 5739 0x02 SCSI Task Management function request 5740 0x03 Login Request 5741 0x04 Text Request 5742 0x05 SCSI Data-out (for WRITE operations) 5743 0x06 Logout Request 5744 0x10 SNACK Request 5745 0x1c-0x1e Vendor specific codes 5747 Target opcodes are: 5749 0x20 NOP-In 5750 0x21 SCSI Response -contains SCSI status and possibly sense 5751 information or other response information. 5752 0x22 SCSI Task Management function response 5753 0x23 Login Response 5754 0x24 Text Response 5755 0x25 SCSI Data-in -for READ operations. 5756 0x26 Logout Response 5757 0x31 Ready To Transfer (R2T) - sent by target when it is ready 5758 to receive data. 5759 0x32 Asynchronous Message -sent by target to indicate certain 5760 special conditions. 5761 0x3c-0x3e Vendor specific codes 5762 0x3f Reject 5764 All other opcodes are reserved. 5766 9.2.1.3 Final (F) bit 5768 When set to 1 it usually indicates the final (or only) PDU of a 5769 sequence. 5771 9.2.1.4 Opcode-specific Fields 5773 These fields have different meanings for different opcode types. 5775 9.2.1.5 TotalAHSLength 5777 Total length of all AHS header segments in four byte words including 5778 padding, if any. 5780 The TotalAHSLength is used only in PDUs that have an AHS and MUST be 5781 0 in all other PDUs. 5783 Julian Satran Expires February 2003 131 5784 iSCSI 5-August-02 5786 9.2.1.6 DataSegmentLength 5788 This is the data segment payload length in bytes (excluding pad- 5789 ding). The DataSegmentLength MUST be 0 whenever the PDU has no data 5790 segment. 5792 9.2.1.7 LUN 5794 Some opcodes operate on a specific Logical Unit. The Logical Unit 5795 Number (LUN) field identifies which Logical Unit. If the opcode does 5796 not relate to a Logical Unit, this field is either ignored or may be 5797 used in an opcode specific way. The LUN field is 64-bits and should 5798 be formatted in accordance with [SAM2] i.e., LUN[0] from [SAM2] is 5799 BHS byte 8 and so on up to LUN[7] from [SAM2] that is BHS byte 15. 5801 9.2.1.8 Initiator Task Tag 5803 The initiator assigns a Task Tag to each iSCSI task it issues. While 5804 a task exists, this tag MUST uniquely identify the task session-wide. 5805 SCSI may also use the initiator task tag as part of the SCSI task 5806 identifier when the timespan during which an iSCSI initiator task tag 5807 must be unique extends over the timespan during which a SCSI task tag 5808 must be unique. However, the iSCSI Initiator Task Tag has to exist 5809 and be unique even for untagged SCSI commands. 5811 9.2.2 Additional Header Segment (AHS) 5813 The general format of an AHS is: 5815 Byte/ 0 | 1 | 2 | 3 | 5816 / | | | | 5817 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 5818 +---------------+---------------+---------------+---------------+ 5819 0| AHSLength | AHSType | AHS-Specific | 5820 +---------------+---------------+---------------+---------------+ 5821 4/ AHS-Specific / 5822 +/ / 5823 +---------------+---------------+---------------+---------------+ 5824 x 5826 9.2.2.1 AHSType 5828 The AHSType field is coded as follows: 5830 Julian Satran Expires February 2003 132 5831 iSCSI 5-August-02 5833 bit 0-1 - Reserved 5835 bit 2-7 - AHS code 5837 0 - Reserved 5838 1 - Extended CDB 5839 2 - Expected Bidirectional Read Data Length 5840 3 - 59 Reserved 5841 60- 63 Non-iSCSI extensions 5843 9.2.2.2 AHSLength 5845 This field contains the effective length in bytes of the AHS exclud- 5846 ing AHSType and AHSLength and padding, if any. The AHS is padded to 5847 the smallest integer number of 4 byte words (i.e., from 0 up to 3 5848 padding bytes). 5850 9.2.2.3 Extended CDB AHS 5852 The format of the Extended CDB AHS is: 5854 Byte/ 0 | 1 | 2 | 3 | 5855 / | | | | 5856 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 5857 +---------------+---------------+---------------+---------------+ 5858 0| AHSLength (CDBLength-15) | 0x01 | Reserved | 5859 +---------------+---------------+---------------+---------------+ 5860 4/ ExtendedCDB...+padding / 5861 +/ / 5862 +---------------+---------------+---------------+---------------+ 5863 x 5865 This type of AHS MUST NOT be used if the CDBLength is less than 17. 5866 The length includes the reserved byte 3. 5868 9.2.2.4 Bidirectional Expected Read-Data Length AHS 5870 The format of the Bidirectional Read Expected Data Transfer Length 5871 AHS is: 5873 Julian Satran Expires February 2003 133 5874 iSCSI 5-August-02 5876 Byte/ 0 | 1 | 2 | 3 | 5877 / | | | | 5878 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 5879 +---------------+---------------+---------------+---------------+ 5880 0| AHSLength (0x0005) | 0x02 | Reserved | 5881 +---------------+---------------+---------------+---------------+ 5882 4| Expected Read-Data Length | 5883 +---------------+---------------+---------------+---------------+ 5884 8 5886 9.2.3 Header Digest and Data Digest 5888 Optional header and data digests protect the integrity of the header 5889 and data, respectively. The digests, if present, are located, respec- 5890 tively, after the header and PDU-specific data and cover both the 5891 proper data as well as the padding bytes. 5893 The existence and type of digests are negotiated during the Login 5894 Phase. 5896 The separation of the header and data digests is useful in iSCSI 5897 routing applications, where only the header changes when a message is 5898 forwarded. In this case, only the header digest should be re-calcu- 5899 lated. 5901 Digests are not included in data or header length fields. 5903 A zero-length Data Segment also implies a zero-length data-digest. 5905 9.2.4 Data Segment 5907 The (optional) Data Segment contains PDU associated data. Its pay- 5908 load effective length is provided in the BHS field - DataSeg- 5909 mentLength. The Data Segment is also padded to an integer number of 4 5910 byte words. 5912 Julian Satran Expires February 2003 134 5913 iSCSI 5-August-02 5915 9.3 SCSI Command 5917 The format of the SCSI Command PDU is: 5919 Byte/ 0 | 1 | 2 | 3 | 5920 / | | | | 5921 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 5922 +---------------+---------------+---------------+---------------+ 5923 0|.|I| 0x01 |F|R|W|0 0|ATTR | Reserved | 5924 +---------------+---------------+---------------+---------------+ 5925 4|TotalAHSLength | DataSegmentLength | 5926 +---------------+---------------+---------------+---------------+ 5927 8| Logical Unit Number (LUN) | 5928 + + 5929 12| | 5930 +---------------+---------------+---------------+---------------+ 5931 16| Initiator Task Tag | 5932 +---------------+---------------+---------------+---------------+ 5933 20| Expected Data Transfer Length | 5934 +---------------+---------------+---------------+---------------+ 5935 24| CmdSN | 5936 +---------------+---------------+---------------+---------------+ 5937 28| ExpStatSN | 5938 +---------------+---------------+---------------+---------------+ 5939 32/ SCSI Command Descriptor Block (CDB) / 5940 +/ / 5941 +---------------+---------------+---------------+---------------+ 5942 48/ AHS (if any) / 5943 +---------------+---------------+---------------+---------------+ 5944 x/ Header Digest (if any) / 5945 +---------------+---------------+---------------+---------------+ 5946 y/ (DataSegment, Command Data) (if any) / 5947 +/ / 5948 +---------------+---------------+---------------+---------------+ 5949 z/ Data Digest (if any) / 5950 +---------------+---------------+---------------+---------------+ 5952 9.3.1 Flags and Task Attributes (byte 1) 5954 The flags for a SCSI Command are: 5956 bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs 5957 follow this PDU. When F=1 for a write and if Expected Data 5959 Julian Satran Expires February 2003 135 5960 iSCSI 5-August-02 5962 Transfer Length is larger than the DataSegmentLength the tar- 5963 get may solicit additional data through R2T. 5965 bit 1 (R) is set to 1 when the command is expected to input 5966 data. 5968 bit 2 (W) is set to 1 when the command is expected to output 5969 data. 5971 bit 3-4 Reserved 5973 bit 5-7 contains Task Attributes. 5975 Task Attributes (ATTR) have one of the following integer values (see 5976 [SAM2] for details): 5978 0 - Untagged 5979 1 - Simple 5980 2 - Ordered 5981 3 - Head of Queue 5982 4 - ACA 5983 5-7 - Reserved 5985 Setting both the W and the F bit to 0 is an error. 5986 Either or both of R and W MAY be 1 when either the corresponding 5987 Expected Data Transfer Lengths are 0, but they MUST NOT both be 0 5988 when the corresponding Expected Data Transfer Length and/or Bidirec- 5989 tional Read Expected Data Transfer Length are not 0. 5991 9.3.2 CmdSN - Command Sequence Number 5993 Enables ordered delivery across multiple connections in a single ses- 5994 sion. 5996 9.3.3 ExpStatSN 5998 Command responses up to ExpStatSN-1 (mod 2**32) have been received 5999 (acknowledges status) on the connection. 6001 9.3.4 Expected Data Transfer Length 6003 For unidirectional operations, the Expected Data Transfer Length 6004 field contains the number of bytes of data involved in this SCSI 6005 operation. For a unidirectional write operation (W flag set to 1 and 6006 R flag set to 0), the initiator uses this field to specify the num- 6008 Julian Satran Expires February 2003 136 6009 iSCSI 5-August-02 6011 ber of bytes of data it expects to transfer for this operation. For 6012 a unidirectional read operation (W flag set to 0 and R flag set to 6013 1), the initiator uses this field to specify the number of bytes of 6014 data it expects the target to transfer to the initiator. It corre- 6015 sponds to the SAM2 byte count. 6017 For bidirectional operations (both R and W flags are set to 1), this 6018 field contains the number of data bytes involved in the write trans- 6019 fer. For bidirectional operations, an additional header segment MUST 6020 be present in the header sequence that indicates the Bidirectional 6021 Read Expected Data Transfer Length. The Expected Data Transfer 6022 Length field and the Bidirectional Read Expected Data Transfer Length 6023 field correspond to the SAM2 byte count 6025 If the Expected Data Transfer Length for a write and the length of 6026 the immediate data part that follows the command (if any) are the 6027 same, then no more data PDUs are expected to follow. In this case, 6028 the F bit MUST be set to 1. 6030 If the Expected Data Transfer Length is higher than the FirstBurst- 6031 Length (the negotiated maximum amount of unsolicited data the target 6032 will accept), the initiator MUST send the maximum length of unsolic- 6033 ited data OR ONLY the immediate data if any. 6035 Upon completion of a data transfer, the target informs the initiator 6036 (through residual counts) of how many bytes were actually processed 6037 (sent and/or received) by the target. 6039 9.3.5 CDB - SCSI Command Descriptor Block 6041 There are 16 bytes in the CDB field to accommodate the commonly used 6042 CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS 6043 MUST be used to contain the CDB spillover. 6045 9.3.6 Data Segment - Command Data 6047 Some SCSI commands require additional parameter data to accompany the 6048 SCSI command. This data may be placed beyond the boundary of the 6049 iSCSI header in a data segment. Alternatively, user data (for exam- 6050 ple, from a WRITE operation) can be placed in the data segment (both 6051 cases are referred to as immediate data). These data are governed by 6052 the general rules for solicited vs. unsolicited data. 6054 Julian Satran Expires February 2003 137 6055 iSCSI 5-August-02 6057 9.4 SCSI Response 6059 The format of the SCSI Response PDU is: 6061 Byte/ 0 | 1 | 2 | 3 | 6062 / | | | | 6063 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6064 +---------------+---------------+---------------+---------------+ 6065 0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status | 6066 +---------------+---------------+---------------+---------------+ 6067 4|TotalAHSLength | DataSegmentLength | 6068 +---------------+---------------+---------------+---------------+ 6069 8| Reserved | 6070 + + 6071 12| | 6072 +---------------+---------------+---------------+---------------+ 6073 16| Initiator Task Tag | 6074 +---------------+---------------+---------------+---------------+ 6075 20| SNACK Tag or Reserved | 6076 +---------------+---------------+---------------+---------------+ 6077 24| StatSN | 6078 +---------------+---------------+---------------+---------------+ 6079 28| ExpCmdSN | 6080 +---------------+---------------+---------------+---------------+ 6081 32| MaxCmdSN | 6082 +---------------+---------------+---------------+---------------+ 6083 36| ExpDataSN or Reserved | 6084 +---------------+---------------+---------------+---------------+ 6085 40| Bidirectional Read Residual Count or Reserved | 6086 +---------------+---------------+---------------+---------------+ 6087 44| Residual Count or Reserved | 6088 +---------------+---------------+---------------+---------------+ 6089 48| Header-Digest (Optional) | 6090 +---------------+---------------+---------------+---------------+ 6091 / Data Segment (Optional) / 6092 +/ / 6093 +---------------+---------------+---------------+---------------+ 6094 | Data-Digest (Optional) | 6095 +---------------+---------------+---------------+---------------+ 6097 9.4.1 Flags (byte 1) 6099 bit 1-2 Reserved 6101 Julian Satran Expires February 2003 138 6102 iSCSI 5-August-02 6104 bit 3 - (o) set for Bidirectional Read Residual Overflow. In 6105 this case, the Bidirectional Read Residual Count indicates 6106 the number of bytes that were not transferred to the initia- 6107 tor because the initiator's Expected Bidirectional Read Data 6108 Transfer Length was not sufficient. 6110 bit 4 - (u) set for Bidirectional Read Residual Underflow. In 6111 this case, the Bidirectional Read Residual Count indicates 6112 the number of bytes that were not transferred to the initia- 6113 tor out of the number of bytes expected to be transferred. 6115 bit 5 - (O) set for Residual Overflow. In this case, the Resid- 6116 ual Count indicates the number of bytes that were not trans- 6117 ferred because the initiator's Expected Data Transfer Length 6118 was not sufficient. For a bidirectional operation, the Resid- 6119 ual Count contains the residual for the write operation. 6121 bit 6 - (U) set for Residual Underflow. In this case, the 6122 Residual Count indicates the number of bytes that were not 6123 transferred out of the number of bytes that were expected to 6124 be transferred. For a bidirectional operation, the Residual 6125 Count contains the residual for the write operation. 6127 bit 7 - (0) Reserved 6129 Bits O and U and bits o and u are mutually exclusive (i.e. having 6130 both o and u or O and U set to 1 is a protocol error). 6131 For a response other than "Command Completed at Target" bits 3-6 MUST 6132 be 0. 6134 9.4.2 Status 6136 The Status field is used to report the SCSI status of the command (as 6137 specified in [SAM2]) and is valid only if the Response Code is Com- 6138 mand Completed at target. 6140 Some of the status codes defined in [SAM2] are: 6142 0x00 GOOD 6143 0x02 CHECK CONDITION 6144 0x08 BUSY 6145 0x18 RESERVATION CONFLICT 6146 0x28 TASK SET FULL 6147 0x30 ACA ACTIVE 6148 0x40 TASK ABORTED 6150 See [SAM2] for the complete list and definitions. 6152 Julian Satran Expires February 2003 139 6153 iSCSI 5-August-02 6155 If a SCSI device error is detected while data from the initiator is 6156 still expected (the command PDU did not contain all the data and the 6157 target has not received a Data PDU with the final bit Set), the tar- 6158 get MUST wait until it receives a Data PDU with the F bit set in the 6159 last expected sequence before sending the Response PDU. 6161 9.4.3 Response 6163 This field contains the iSCSI service response. 6165 iSCSI service response codes defined in this specification are: 6167 0x00 - Command Completed at Target 6168 0x01 - Target Failure 6169 0x80-0xff - Vendor specific 6171 All other response codes are reserved. 6173 The Response is used to report a Service Response. The mapping of the 6174 response code into a SCSI service response code value, if needed, is 6175 outside the scope of this document. However, in symbolic terms 6176 response value 0x00 maps to the SCSI service response (see [SAM2] and 6177 [SPC3]) of TASK COMPLETE or LINKED COMMAND COMPLETE. All other 6178 Response values map to the SCSI service response of SERVICE DELIVERY 6179 OR TARGET FAILURE. 6181 If a SCSI Response PDU does not arrive before the session is termi- 6182 nated, the SCSI service response is SERVICE DELIVERY OR TARGET FAIL- 6183 URE. 6185 A non-zero response field indicates a failure to execute the command 6186 in which case the Status and Sense fields are undefined. 6188 9.4.4 SNACK Tag 6190 This field contains a copy of the SNACK Tag of the last SNACK Tag 6191 accepted by the target on the same connection and for the command for 6192 which the response is issued. Otherwise it is reserved and should be 6193 set to 0. 6195 After issuing a R-Data SNACK the initiator must discard any SCSI sta- 6196 tus unless contained in an SCSI Response PDU carrying the same SNACK 6197 Tag as the last issued R-Data SNACK for the SCSI command on the cur- 6198 rent connection. 6200 Julian Satran Expires February 2003 140 6201 iSCSI 5-August-02 6203 For a detailed discussion on R-Data SNACK see Section 9.16 SNACK 6204 Request. 6206 9.4.5 Residual Count 6208 The Residual Count field MUST be valid in the case where either the U 6209 bit or the O bit is set. If neither bit is set, the Residual Count 6210 field is reserved. Targets may set the residual count and initiators 6211 may use it when the response code is "completed at target" (even if 6212 the status returned is not GOOD). If the O bit is set, the Residual 6213 Count indicates the number of bytes that were not transferred because 6214 the initiator's Expected Data Transfer Length was not sufficient. If 6215 the U bit is set, the Residual Count indicates the number of bytes 6216 that were not transferred out of the number of bytes expected to be 6217 transferred. 6219 9.4.6 Bidirectional Read Residual Count 6221 The Bidirectional Read Residual Count field MUST be valid in the case 6222 where either the u bit or the o bit is set. If neither bit is set, 6223 the Bidirectional Read Residual Count field is reserved. Targets may 6224 set the Bidirectional Read Residual Count and initiators may use it 6225 when the response code is "completed at target". If the o bit is set, 6226 the Bidirectional Read Residual Count indicates the number of bytes 6227 that were not transferred to the initiator because the initiator's 6228 Expected Bidirectional Read Transfer Length was not sufficient. If 6229 the u bit is set, the Bidirectional Read Residual Count indicates the 6230 number of bytes that were not transferred to the initiator out of the 6231 number of bytes expected to be transferred. 6233 9.4.7 Data Segment - Sense and Response Data Segment 6235 iSCSI targets MUST support and enable autosense. If Status is CHECK 6236 CONDITION (0x02), then the Data Segment MUST contain sense data for 6237 the failed command. 6239 For some iSCSI responses, the response data segment MAY contain some 6240 response related information, (e.g., for a target failure, it may 6241 contain a vendor specific detailed description of the failure). 6243 If the DataSegmentLength is not 0, the format of the Data Segment is 6244 as follows: 6246 Julian Satran Expires February 2003 141 6247 iSCSI 5-August-02 6249 Byte/ 0 | 1 | 2 | 3 | 6250 / | | | | 6251 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6252 +---------------+---------------+---------------+---------------+ 6253 0|SenseLength | Sense Data | 6254 +---------------+---------------+---------------+---------------+ 6255 x/ Sense Data / 6256 +---------------+---------------+---------------+---------------+ 6257 y/ Response Data / 6258 / / 6259 +---------------+---------------+---------------+---------------+ 6260 z| 6262 9.4.7.1 SenseLength 6264 Length of Sense Data. 6266 9.4.7.2 Sense Data 6268 The Sense Data contains detailed information about a check condition 6269 and [SPC] specifies the format and content of the Sense Data. 6271 Certain iSCSI conditions result in the command being terminated at 6272 the target (response Command Completed at Target) with a SCSI Check 6273 Condition Status as outlined in the next table: 6275 +--------------------------+----------+---------------------------+ 6276 | iSCSI Condition |Sense | Additional Sense Code & | 6277 | |Key | Qualifier | 6278 +--------------------------+----------+---------------------------+ 6279 | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c | 6280 | data |Command-0B| Write Error | 6281 +--------------------------+----------+---------------------------+ 6282 | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d | 6283 | |Command-0B| Write Error | 6284 +--------------------------+----------+---------------------------+ 6285 | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 | 6286 | error |Command-0B| CRC Error Detected | 6287 +--------------------------+----------+---------------------------+ 6288 | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 | 6289 | |Command-0B| Read Error | 6290 +--------------------------+----------+---------------------------+ 6292 Julian Satran Expires February 2003 142 6293 iSCSI 5-August-02 6295 The target reports the "Incorrect amount of data" condition if dur- 6296 ing data output the total data length to output is greater than 6297 FirstBurstLength and the initiator sent unsolicited non-immediate 6298 data but the total amount of unsolicited data is different than 6299 FirstBurstLength. The target reports the same error when the amount 6300 of data sent as a reply to an R2T does not match the amount 6301 requested. 6303 9.4.8 ExpDataSN 6305 The number of Data-In (read) PDUs the target has sent for the com- 6306 mand. 6308 This field is reserved if the response code is not Command Completed 6309 at Target or the command is a write command. 6311 9.4.9 StatSN - Status Sequence Number 6313 StatSN is a Sequence Number that the target iSCSI layer generates per 6314 connection and that in turn, enables the initiator to acknowledge 6315 status reception. StatSN is incremented by 1 for every response/sta- 6316 tus sent on a connection except for responses sent as a result of a 6317 retry or SNACK. In the case of responses sent due to a retransmis- 6318 sion request, the StatSN MUST be the same as the first time the PDU 6319 was sent unless the connection has since been restarted. 6321 9.4.10 ExpCmdSN - Next Expected CmdSN from this Initiator 6323 ExpCmdSN is a Sequence Number that the target iSCSI returns to the 6324 initiator to acknowledge command reception. It is used to update a 6325 local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1 6326 indicates that the target cannot accept new commands. 6328 9.4.11 MaxCmdSN - Maximum CmdSN from this Initiator 6330 MaxCmdSN is a Sequence Number that the target iSCSI returns to the 6331 initiator to indicate the maximum CmdSN the initiator can send. It is 6332 used to update a local variable with the same name. If MaxCmdSN is 6333 equal to ExpCmdSN-1, this indicates to the initiator that the target 6334 cannot receive any additional commands. When MaxCmdSN changes at the 6335 target while the target has no pending PDUs to convey this informa- 6336 tion to the initiator, it MUST generate a NOP-IN to carry the new 6337 MaxCmdSN. 6339 Julian Satran Expires February 2003 143 6340 iSCSI 5-August-02 6342 Julian Satran Expires February 2003 144 6343 iSCSI 5-August-02 6345 9.5 Task Management Function Request 6347 Byte/ 0 | 1 | 2 | 3 | 6348 / | | | | 6349 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6350 +---------------+---------------+---------------+---------------+ 6351 0|.|I| 0x02 |1| Function | Reserved | 6352 +---------------+---------------+---------------+---------------+ 6353 4|TotalAHSLength | DataSegmentLength | 6354 +---------------+---------------+---------------+---------------+ 6355 8| Logical Unit Number (LUN) or Reserved | 6356 + + 6357 12| | 6358 +---------------+---------------+---------------+---------------+ 6359 16| Initiator Task Tag | 6360 +---------------+---------------+---------------+---------------+ 6361 20| Referenced Task Tag or 0xffffffff | 6362 +---------------+---------------+---------------+---------------+ 6363 24| CmdSN | 6364 +---------------+---------------+---------------+---------------+ 6365 28| ExpStatSN | 6366 +---------------+---------------+---------------+---------------+ 6367 32| RefCmdSN or Reserved | 6368 +---------------+---------------+---------------+---------------+ 6369 36| ExpDataSN or Reserved | 6370 +---------------+---------------+---------------+---------------+ 6371 40/ Reserved / 6372 +/ / 6373 +---------------+---------------+---------------+---------------+ 6374 48| Header-Digest (Optional) | 6375 +---------------+---------------+---------------+---------------+ 6377 9.5.1 Function 6379 The Task Management functions provide an initiator with a way to 6380 explicitly control the execution of one or more Tasks (SCSI and iSCSI 6381 tasks). The Task Management function codes are listed below. For a 6382 more detailed description of SCSI task management, see [SAM2]. 6384 1 - ABORT TASK - aborts the task identified by the Refer- 6385 enced Task Tag field. 6387 2 - ABORT TASK SET - aborts all Tasks issued via this ses- 6388 sion on the logical unit. 6390 Julian Satran Expires February 2003 145 6391 iSCSI 5-August-02 6393 3 - CLEAR ACA - clears the Auto Contingent Allegiance condi- 6394 tion. 6396 4 - CLEAR TASK SET - aborts all Tasks in the appropriate task 6397 set as defined by the TST field in the Control mode page (see 6398 [SPC3]). 6400 5 - LOGICAL UNIT RESET 6402 6 - TARGET WARM RESET 6404 7 - TARGET COLD RESET 6406 8 - TASK REASSIGN - reassigns connection allegiance for the 6407 task identified by the Initiator Task Tag field to this con- 6408 nection, thus resuming the iSCSI exchanges for the task. 6410 For all these functions, the Task Management function response MUST 6411 be returned as detailed in Section 9.6 Task Management Function 6412 Response. All these functions apply to the referenced tasks regard- 6413 less of whether they are proper SCSI tasks or tagged iSCSI opera- 6414 tions. Task management requests must act on all the commands having 6415 a CmdSN lower than the task management CmdSN. If the task management 6416 request is marked for immediate delivery it must be considered imme- 6417 diately for execution but the operations involved (all or part of 6418 them) may be postponed to allow the target to receive all relevant 6419 tasks. According to [SAM2] for all the tasks covered by the Task Man- 6420 agement response (i.e., with CmdSN not higher than the task manage- 6421 ment command CmdSN), additional responses MUST NOT be delivered to 6422 the SCSI layer after the Task Management response. The iSCSI initia- 6423 tor MAY deliver to the SCSI layer all responses received before the 6424 Task Management response (i.e., it is a matter of implementation if 6425 the SCSI responses - received before the Task Management response but 6426 after the task management request was issued - are delivered to the 6427 SCSI layer by the iSCSI layer in the initiator). The iSCSI target 6428 MUST ensure that no responses for the tasks covered by a task manage- 6429 ment function are delivered to the iSCSI initiator after the Task 6430 Management response. 6432 For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST 6433 continue to respond to all valid target transfer tags (received via 6434 R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to the 6435 affected task set, even after issuing the task management request. 6436 The issuing initiator SHOULD however terminate (i.e. by setting the 6438 Julian Satran Expires February 2003 146 6439 iSCSI 5-August-02 6441 F-bit to 1) these response sequences as quickly as possible. The 6442 target on its part MUST wait for responses on all affected target 6443 transfer tags before acting on either of these two task management 6444 requests. In case all or part of the response sequence is not 6445 received (due to digest errors) for a valid TTT, the target MAY treat 6446 it as a case of within-command error recovery class (section 5.14.1) 6447 if it is supporting ErrorRecoveryLevel >= 1, or alternatively may 6448 drop the connection to complete the requested task set function. 6450 If the connection is still active (it is not undergoing an implicit 6451 or explicit logout), ABORT TASK MUST be issued on the same connec- 6452 tion to which the task to be aborted is allegiant at the time the 6453 Task Management Request is issued. If the connection is implicitly or 6454 explicitly logged out (i.e., no other request will be issued on the 6455 failing connection and no other response will be received on the 6456 failing connection), then an ABORT TASK function request may be 6457 issued on another connection. This Task Management request will then 6458 establish a new allegiance for the command to be aborted as well as 6459 abort it (i.e., the task to be aborted will not have to be retried or 6460 reassigned, and its status, if issued but not acknowledged, will be 6461 reissued followed by the Task Management response). 6463 For the LOGICAL UNIT RESET function, the target MUST behave as dic- 6464 tated by the Logical Unit Reset function in [SAM2]. 6466 The implementation of the TARGET WARM RESET function and the TARGET 6467 COLD RESET function is OPTIONAL and when implemented, should act as 6468 described below. The TARGET WARM RESET is also subject to SCSI access 6469 controls on the requesting initiator as defined in [SPC3]. When 6470 authorization fails at the target, the appropriate response as 6471 described in Section 9.6 Task Management Function Response MUST be 6472 returned by the target. The TARGET COLD RESET function is not sub- 6473 ject to SCSI access controls, but its execution privileges may be 6474 managed by iSCSI mechanisms such as login authentication. 6476 When executing the TARGET WARM RESET and TARGET COLD RESET func- 6477 tions, the target cancels all pending operations on all Logical Units 6478 known the issuing initiator. Both functions are equivalent to the 6479 Target Reset function specified by [SAM2]. They can affect many other 6480 initiators logged in with the servicing SCSI target port. 6482 The target MUST treat the TARGET COLD RESET function additionally as 6483 a power on event, thus terminating all of its TCP connections to all 6485 Julian Satran Expires February 2003 147 6486 iSCSI 5-August-02 6488 initiators (all sessions are terminated). For this reason, the Ser- 6489 vice Response (defined by [SAM2]) for this SCSI task management func- 6490 tion may not be reliably delivered to the issuing initiator port. 6492 For the TASK REASSIGN function, the target should reassign the con- 6493 nection allegiance to this new connection (and thus resume iSCSI 6494 exchanges for the task). TASK REASSIGN MUST be received by the tar- 6495 get ONLY after the connection on which the command was previously 6496 executing has been successfully logged-out. The Task Management 6497 response MUST be issued before the reassignment becomes effective. 6498 For additional usage semantics see Section 5.2 Retry and Reassign in 6499 Recovery. 6501 TASK REASSIGN MUST be issued as an immediate command. 6503 9.5.2 TotalAHSLength and DataSegmentLength 6505 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 6507 9.5.3 LUN 6509 This field is required for functions that address a specific LU 6510 (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT 6511 RESET) and is reserved in all others. 6513 9.5.4 Referenced Task Tag 6515 The Initiator Task Tag of the task to be aborted for the ABORT TASK 6516 function or reassigned for the TASK REASSIGN function. 6517 For all the other functions this field MUST be set to the reserved 6518 value 0xffffffff. 6520 9.5.5 RefCmdSN 6522 For the ABORT TASK function, initiators MUST always set this to the 6523 CmdSN of the task identified by the Referenced Task Tag field. Tar- 6524 gets must use this field as described in section 9.6.1 when the task 6525 identified by the Referenced Task Tag field is not with the target. 6527 Otherwise this field is reserved. 6529 Julian Satran Expires February 2003 148 6530 iSCSI 5-August-02 6532 9.5.6 ExpDataSN 6534 If the function is TASK REASSIGN, which establishes a new connection 6535 allegiance for a previously issued Read or Bidirectional command, 6536 this field will contain the next consecutive input DataSN number 6537 expected by the initiator (no gaps) for the referenced command in a 6538 previous execution. The initiator MUST discard any discontiguous data 6539 PDUs from the previous execution and the target MUST retransmit all 6540 data previously transmitted in Data-in PDUs (if any) starting with 6541 ExpDataSN. The number of retransmitted PDUs, may or may not be the 6542 same as the original transmission depending on if there was a change 6543 in MaxRecvDataSegmentLength in the reassignment. The target MAY also 6544 send no more Data-In PDUs if it sent all its data in PDUs with DataSN 6545 less than ExpDataSN. 6547 ExpDataSN MUST be higher than the DataSN of the last acknowledged 6548 Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent 6549 by the target. 6551 Otherwise, this field is reserved. 6553 Julian Satran Expires February 2003 149 6554 iSCSI 5-August-02 6556 9.6 Task Management Function Response 6558 Byte/ 0 | 1 | 2 | 3 | 6559 / | | | | 6560 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6561 +---------------+---------------+---------------+---------------+ 6562 0|.|.| 0x22 |1| Reserved | Response | Reserved | 6563 +---------------+---------------+---------------+---------------+ 6564 4|TotalAHSLength | DataSegmentLength | 6565 +---------------------------------------------------------------+ 6566 8/ Reserved / 6567 / / 6568 +---------------+---------------+---------------+---------------+ 6569 16| Initiator Task Tag | 6570 +---------------+---------------+---------------+---------------+ 6571 20| Reserved | 6572 +---------------+---------------+---------------+---------------+ 6573 24| StatSN | 6574 +---------------+---------------+---------------+---------------+ 6575 28| ExpCmdSN | 6576 +---------------+---------------+---------------+---------------+ 6577 32| MaxCmdSN | 6578 +---------------+---------------+---------------+---------------+ 6579 36/ Reserved / 6580 +/ / 6581 +---------------+---------------+---------------+---------------+ 6582 48| Header-Digest (Optional) | 6583 +---------------+---------------+---------------+---------------+ 6585 For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK 6586 SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET and 6587 TASK REASSIGN, the target performs the requested Task Management 6588 function and sends a Task Management response back to the initiator. 6589 For TASK REASSIGN the new connection allegiance MUST become effec- 6590 tive ONLY at the target only after the target issues the Task Manage- 6591 ment Response. 6593 9.6.1 Response 6595 The target provides a Response, which may take on the following val- 6596 ues: 6598 a) 0 - Function Complete 6600 Julian Satran Expires February 2003 150 6601 iSCSI 5-August-02 6603 b) 1 - Task does not exist 6604 c) 2 - LUN does not exist. 6605 d) 3 - Task still allegiant. 6606 e) 4 - Task allegiance reassignment not supported. 6607 f) 5 - Task management function not supported. 6608 g) 6 - Function authorization failed. 6609 h) 255 - Function rejected. 6611 All other values are reserved. 6613 For a discussion on usage of response codes 3 and 4, see Section 6614 5.2.2 Allegiance Reassignment. 6616 For the TARGET COLD RESET and TARGET WARM RESET functions, the tar- 6617 get cancels all pending operations across all Logical Units known to 6618 the issuing initiator. For the TARGET COLD RESET function, the tar- 6619 get MUST then close all of its TCP connections to all initiators 6620 (terminates all sessions). 6622 The mapping of the response code into a SCSI service response code 6623 value, if needed, is outside the scope of this document. However, in 6624 symbolic terms Response value 0 maps to the SCSI service response 6625 of FUNCTION COMPLETE. All other Response values map to the SCSI ser- 6626 vice response of FUNCTION REJECTED. If a Task Management function 6627 response PDU does not arrive before the session is terminated, the 6628 SCSI service response is SERVICE DELIVERY OR TARGET FAILURE 6630 The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by 6631 the target only after all the commands affected have been received by 6632 the target, the corresponding task management functions have been 6633 executed by the SCSI target and the delivery of all responses deliv- 6634 ered until the task management function completion have been con- 6635 firmed (acknowledged through ExpStatSN) by the initiator on all 6636 connections of this session. For the exact timeline of events, refer 6637 Section 9.6.2 Task Management actions on task sets. 6639 For the ABORT TASK function, 6641 a) if the Referenced Task Tag identifies a valid task leading to 6642 a successful termination, targets must return the "Function com- 6643 plete" response. 6644 b) if the Referenced Task Tag does not identify an existing task 6645 but if the CmdSN indicated by the RefCmdSN field in the Task Man- 6647 Julian Satran Expires February 2003 151 6648 iSCSI 5-August-02 6650 agement function request is within the valid CmdSN window (between 6651 MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received 6652 and return the "Function complete" response. 6653 c) if the Referenced Task Tag does not identify an existing task 6654 and if the CmdSN indicated by the RefCmdSN field in the Task Man- 6655 agement function request is outside the valid CmdSN window, tar- 6656 gets must return the "Task does not exist" response. 6658 9.6.2 Task Management actions on task sets 6660 The execution of ABORT TASK SET and CLEAR TASK SET Task Management 6661 function requests consists of the following sequence of events in the 6662 specified order on each of the entities. 6664 The initiator: 6666 a) issues ABORT TASK SET/CLEAR TASK SET request. 6667 b) continues to respond to each target transfer tag received 6668 for the affected task set. 6669 c) receives any responses for the tasks in the affected task 6670 set (may process them as usual because they are guaranteed 6671 to be valid). 6672 d) receives the task set management response, thus concluding 6673 all the tasks in the affected task set. 6675 The target: 6677 a) receives the ABORT TASK SET/CLEAR TASK SET request. 6678 b) waits for all target transfer tags to be responded and also 6679 for all affected tasks in the task set to be received. 6680 c) propagates the command up to and receives the response from 6681 the target SCSI layer. 6682 d) takes note of last-sent StatSN on each of the connections 6683 in the session, and waits for acknowledgement of each StatSN 6684 (may solicit for acknowledgement by way of a NOP-In). 6685 e) sends the task set management response. 6687 9.6.3 TotalAHSLength and DataSegmentLength 6689 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 6691 Julian Satran Expires February 2003 152 6692 iSCSI 5-August-02 6694 9.7 SCSI Data-out & SCSI Data-in 6696 The SCSI Data-out PDU for WRITE operations has the following format: 6698 Byte/ 0 | 1 | 2 | 3 | 6699 / | | | | 6700 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6701 +---------------+---------------+---------------+---------------+ 6702 0|.|.| 0x05 |F| Reserved | 6703 +---------------+---------------+---------------+---------------+ 6704 4|TotalAHSLength | DataSegmentLength | 6705 +---------------+---------------+---------------+---------------+ 6706 8| LUN or Reserved | 6707 + + 6708 12| | 6709 +---------------+---------------+---------------+---------------+ 6710 16| Initiator Task Tag | 6711 +---------------+---------------+---------------+---------------+ 6712 20| Target Transfer Tag or 0xffffffff | 6713 +---------------+---------------+---------------+---------------+ 6714 24| Reserved | 6715 +---------------+---------------+---------------+---------------+ 6716 28| ExpStatSN | 6717 +---------------+---------------+---------------+---------------+ 6718 32| Reserved | 6719 +---------------+---------------+---------------+---------------+ 6720 36| DataSN | 6721 +---------------+---------------+---------------+---------------+ 6722 40| Buffer Offset | 6723 +---------------+---------------+---------------+---------------+ 6724 44| Reserved | 6725 +---------------+---------------+---------------+---------------+ 6726 48| Header-Digest (Optional) | 6727 +---------------+---------------+---------------+---------------+ 6728 / DataSegment / 6729 +/ / 6730 +---------------+---------------+---------------+---------------+ 6731 | Data-Digest (Optional) | 6732 +---------------+---------------+---------------+---------------+ 6734 The SCSI Data-in PDU for READ operations has the following format: 6736 Julian Satran Expires February 2003 153 6737 iSCSI 5-August-02 6739 Byte/ 0 | 1 | 2 | 3 | 6740 / | | | | 6741 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6742 +---------------+---------------+---------------+---------------+ 6743 0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd | 6744 +---------------+---------------+---------------+---------------+ 6745 4|TotalAHSLength | DataSegmentLength | 6746 +---------------+---------------+---------------+---------------+ 6747 8| LUN or Reserved | 6748 + + 6749 12| | 6750 +---------------+---------------+---------------+---------------+ 6751 16| Initiator Task Tag | 6752 +---------------+---------------+---------------+---------------+ 6753 20| Target Transfer Tag or 0xffffffff | 6754 +---------------+---------------+---------------+---------------+ 6755 24| StatSN or Reserved | 6756 +---------------+---------------+---------------+---------------+ 6757 28| ExpCmdSN | 6758 +---------------+---------------+---------------+---------------+ 6759 32| MaxCmdSN | 6760 +---------------+---------------+---------------+---------------+ 6761 36| DataSN | 6762 +---------------+---------------+---------------+---------------+ 6763 40| Buffer Offset | 6764 +---------------+---------------+---------------+---------------+ 6765 44| Residual Count | 6766 +---------------+---------------+---------------+---------------+ 6767 48| Header-Digest (Optional) | 6768 +---------------+---------------+---------------+---------------+ 6769 / DataSegment / 6770 +/ / 6771 +---------------+---------------+---------------+---------------+ 6772 | Data-Digest (Optional) | 6773 +---------------+---------------+---------------+---------------+ 6775 Status can accompany the last Data-in PDU if the command did not end 6776 with an exception (i.e., the status is "good status" - GOOD, CONDI- 6777 TION MET or INTERMEDIATE CONDITION MET). The presence of status (and 6778 of a residual count) is signaled though the S flag bit. Although 6779 targets MAY choose to send even non-exception status in separate 6781 Julian Satran Expires February 2003 154 6782 iSCSI 5-August-02 6784 responses, initiators MUST support non-exception status in Data-In 6785 PDUs. 6787 9.7.1 F (Final) Bit 6789 For outgoing data, this bit is 1 for the last PDU of unsolicited data 6790 or the last PDU of a sequence that answers an R2T. 6792 For incoming data, this bit is 1 for the last input (read) data PDU 6793 of a sequence. Input can be split into several sequences, each hav- 6794 ing its own F bit. Splitting the data stream into sequences does not 6795 affect DataSN counting on Data-In PDUs. It MAY be used as a "change 6796 direction" indication for Bidirectional operations that need such a 6797 change. 6799 DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the 6800 direction it is sent and the total of all the DataSegmentLength of 6801 all PDUs in a sequence MUST not exceed MaxBurstLength (or FirstBurst- 6802 Length for unsolicited data). However the number of individual PDUs 6803 in a sequence (or in total) may be higher than the MaxBurstLength (or 6804 FirstBurstLength) to MaxRecvDataSegmentLength ratio (as PDUs may be 6805 limited in length by the sender capabilities). Using DataSeg- 6806 mentLength of 0 may increase beyond what is reasonable the number of 6807 PDUs and should therefore be avoided. 6809 For Bidirectional operations, the F bit is 1 for both the end of the 6810 input sequences as well as the end of the output sequences. 6812 9.7.2 A (Acknowledge) bit 6814 For sessions with ErrorRecoveryLevel 1 or higher, the target sets 6815 this bit to 1 to indicate that it requests a positive acknowledge- 6816 ment from the initiator for the data received. The target should use 6817 the A bit moderately; it MAY set the A bit to 1 only once every Max- 6818 BurstLength bytes or on the last Data-In PDU that concludes the 6819 entire requested read data transfer for the task from the target's 6820 perspective, and MUST NOT do so more frequently than this. The tar- 6821 get MUST NOT set to 1 the A bit for sessions with ErrorRecovery- 6822 Level=0. The initiator MUST ignore the A bit set to 1 for sessions 6823 with ErrorRecoveryLevel=0 6825 On receiving a Data-In PDU with the A bit set to 1on a session with 6826 ErrorRecoveryLevel greater than 0, if there are no holes in the read 6827 data until that Data-In PDU, the initiator MUST issue a SNACK of type 6829 Julian Satran Expires February 2003 155 6830 iSCSI 5-August-02 6832 DataACK except when it is able to acknowledge the status for the task 6833 immediately via ExpStatSN on other outbound PDUs if the status for 6834 the task is also received; in this latter case (acknowledgement 6835 through ExpStatSN) sending a SNACK of type DataACK in response to the 6836 A bit is not mandatory but if it is done it must not be sent after 6837 the status acknowledgement through ExpStatSN. If the initiator has 6838 detected holes in the read data prior to that Data-In PDU, it MUST 6839 postpone issuing the SNACK of type DataACK until the holes are 6840 filled. An initiator also MUST NOT acknowledge the status for the 6841 task before those holes are filled. A status acknowledgement for a 6842 task that generated the Data-In PDUs is considered by the target as 6843 an implicit acknowledgement of the Data-In PDUs if such an acknowl- 6844 edgement was requested by the target. 6846 9.7.3 Flags (byte 1) 6848 The last SCSI Data packet sent from a target to an initiator for a 6849 SCSI command that completed successfully (with a status of GOOD, CON- 6850 DITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may also 6851 optionally contain the Status for the data transfer. In this case, 6852 Sense Data cannot be sent together with the Command Status. If the 6853 command is completed with an error, then the response and sense data 6854 MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in a SCSI 6855 Data packet). For Bidirectional commands, the status MUST be sent in 6856 a SCSI Response PDU. 6858 bit 2-3 - Reserved 6860 bit 5-6 - used the same as in a SCSI Response. Those bits are 6861 valid only when S is set to 1.For details see Section 9.4.1 6862 Flags (byte 1). 6864 bit 7 S (status)- set to indicate that the Command Status field 6865 contains status. If this bit is set to 1 the F bit MUST also 6866 be set to 1. 6868 The fields StatSN, Status and Residual Count have meaningful content 6869 only if the S bit is set to 1 and their values are defined in Sec- 6870 tion 9.4 SCSI Response. 6872 9.7.4 Target Transfer Tag 6874 On outgoing data, the Target Transfer Tag is provided to the target 6875 if the transfer is honoring an R2T. In this case, the Target Trans- 6877 Julian Satran Expires February 2003 156 6878 iSCSI 5-August-02 6880 fer Tag field is a replica of the Target Transfer Tag provided with 6881 the R2T. 6883 On incoming data, the Target Transfer Tag and LUN MUST be provided by 6884 the target if the A bit is set to 1; otherwise they are reserved. The 6885 Target Transfer Tag and LUN are copied by the initiator into the 6886 SNACK of type DataACK that it issues as a result of receiving a SCSI 6887 Data-in PDU with the A bit set to 1. 6889 The Target Transfer Tag values are not specified by this protocol 6890 except that the value 0xffffffff is reserved and means that the Tar- 6891 get Transfer Tag is not supplied. If the Target Transfer Tag is pro- 6892 vided, then the LUN field MUST hold a valid value and be consistent 6893 with whatever was specified with the command; otherwise, the LUN 6894 field is reserved. 6896 9.7.5 DataSN 6898 For input (read) or bidirectional Data-In PDUs, the DataSN is the 6899 input PDU number within the data transfer for the command identified 6900 by the Initiator Task Tag. 6902 R2T and Data-In PDUs, in the context of bidirectional commands, share 6903 the numbering sequence (see Section 2.2.2.3 Data Sequencing). 6905 For output (write) data PDUs, the DataSN is the Data-Out PDU number 6906 within the current output sequence. The current output sequence is 6907 either identified by the Initiator Task Tag (for unsolicited data) or 6908 is a data sequence generated for one R2T (for data solicited through 6909 R2T). 6911 9.7.6 Buffer Offset 6913 The Buffer Offset field contains the offset of this PDU payload data 6914 within the complete data transfer. The sum of the buffer offset and 6915 length should not exceed the expected transfer length for the com- 6916 mand. 6918 The order of data PDUs within a sequence is determined by DataPDU- 6919 InOrder. When set to Yes, it means that PDUs have to be in increas- 6920 ing Buffer Offset order and overlays are forbidden. 6922 Julian Satran Expires February 2003 157 6923 iSCSI 5-August-02 6925 The ordering between sequences is determined by DataSequenceInOrder. 6926 When set to Yes, it means that sequences have to be in increasing 6927 Buffer Offset order and overlays are forbidden. 6929 9.7.7 DataSegmentLength 6931 This is the data payload length of a SCSI Data-In or SCSI Data-Out 6932 PDU. The sending of 0 length data segments should be avoided, but 6933 initiators and targets MUST be able to properly receive 0 length data 6934 segments. 6936 The Data Segments of Data-in and Data-out PDUs SHOULD be filled to 6937 the integer number of 4 byte words (real payload) unless the F bit is 6938 set to 1. 6940 Julian Satran Expires February 2003 158 6941 iSCSI 5-August-02 6943 9.8 Ready To Transfer (R2T) 6945 Byte/ 0 | 1 | 2 | 3 | 6946 / | | | | 6947 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 6948 +---------------+---------------+---------------+---------------+ 6949 0|.|.| 0x31 |1| Reserved | 6950 +---------------+---------------+---------------+---------------+ 6951 4|TotalAHSLength | DataSegmentLength | 6952 +---------------+---------------+---------------+---------------+ 6953 8| LUN | 6954 + + 6955 12| | 6956 +---------------+---------------+---------------+---------------+ 6957 16| Initiator Task Tag | 6958 +---------------+---------------+---------------+---------------+ 6959 20| Target Transfer Tag | 6960 +---------------+---------------+---------------+---------------+ 6961 24| StatSN | 6962 +---------------+---------------+---------------+---------------+ 6963 28| ExpCmdSN | 6964 +---------------+---------------+---------------+---------------+ 6965 32| MaxCmdSN | 6966 +---------------+---------------+---------------+---------------+ 6967 36| R2TSN | 6968 +---------------+---------------+---------------+---------------+ 6969 40| Buffer Offset | 6970 +---------------+---------------+---------------+---------------+ 6971 44| Desired Data Transfer Length | 6972 +---------------------------------------------------------------+ 6973 48| Header-Digest (Optional) | 6974 +---------------+---------------+---------------+---------------+ 6976 When an initiator has submitted a SCSI Command with data that passes 6977 from the initiator to the target (WRITE), the target may specify 6978 which blocks of data it is ready to receive. The target may request 6979 that the data blocks be delivered in whichever order is convenient 6980 for the target at that particular instant. This information is passed 6981 from the target to the initiator in the Ready To Transfer (R2T) PDU. 6983 Julian Satran Expires February 2003 159 6984 iSCSI 5-August-02 6986 In order to allow write operations without an explicit initial R2T, 6987 the initiator and target MUST have negotiated the key InitialR2T to 6988 No during Login. 6990 An R2T MAY be answered with one or more SCSI Data-out PDUs with a 6991 matching Target Transfer Tag. If an R2T is answered with a single 6992 Data-out PDU, the Buffer Offset in the Data PDU MUST be the same as 6993 the one specified by the R2T and the data length of the Data PDU MUST 6994 be the same as the Desired Data Transfer Length specified in the R2T. 6995 If the R2T is answered with a sequence of Data PDUs, the Buffer Off- 6996 set and Length MUST be within the range of those specified by R2T, 6997 and the last PDU MUST have the F bit set to 1. If the last PDU 6998 (marked with the F bit) is received before the Desired Data Transfer 6999 Length is transferred, a target MAY choose to Reject that PDU with 7000 "Protocol error" reason code. DataPDUInOrder governs the Data-Out 7001 PDU ordering. If DataPDUInOrder is set to Yes, the Buffer Offsets and 7002 Lengths for consecutive PDUs MUST form a continuous non-overlapping 7003 range and the PDUs MUST be sent in increasing offset order. 7005 The target may send several R2T PDUs. It, therefore, can have a num- 7006 ber of pending data transfers. The number of outstanding R2T PDUs 7007 are limited by the value of the negotiated key MaxOutstandingR2T. 7008 Within a connection, outstanding R2Ts MUST be fulfilled by the initi- 7009 ator in the order in which they were received. 7011 R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T 7012 (Recovery-R2T) is generated by a target upon detecting the loss of 7013 one or more Data-Out PDUs through due to: 7015 - a digest error 7016 - a sequence error 7017 - a sequence timeout 7019 A Recovery-R2T carries the next unused R2TSN, but requests part of or 7020 the entire data burst that an earlier R2T (with a lower R2TSN) had 7021 already requested. 7023 DataSequenceInOrder governs the buffer offset ordering in consecu- 7024 tive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST 7025 refer to continuous non-overlapping ranges except for Recovery-R2Ts. 7027 9.8.1 TotalAHSLength and DataSegmentLength 7029 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 7031 Julian Satran Expires February 2003 160 7032 iSCSI 5-August-02 7034 9.8.2 R2TSN 7036 R2TSN is the R2T PDU input PDU number within the command identified 7037 by the Initiator Task Tag. 7039 For bidirectional commands R2T and Data-In PDUs share the input PDU 7040 numbering sequence (see Section 2.2.2.3 Data Sequencing). 7042 9.8.3 StatSN 7044 The StatSN field will contain the next StatSN. The StatSN for this 7045 connection is not advanced after this PDU is sent. 7047 9.8.4 Desired Data Transfer Length and Buffer Offset 7049 The target specifies how many bytes it wants the initiator to send 7050 because of this R2T PDU. The target may request the data from the 7051 initiator in several chunks, not necessarily in the original order of 7052 the data. The target, therefore, also specifies a Buffer Offset that 7053 indicates the point at which the data transfer should begin, rela- 7054 tive to the beginning of the total data transfer. The Desired Data 7055 Transfer Length MUST NOT be 0 and MUST not exceed MaxBurstLength. 7057 9.8.5 Target Transfer Tag 7059 The target assigns its own tag to each R2T request that it sends to 7060 the initiator. This tag can be used by the target to easily identify 7061 the data it receives. The Target Transfer Tag and LUN are copied in 7062 the outgoing data PDUs and are used by the target only. There is no 7063 protocol rule about the Target Transfer Tag except that the value 7064 0xffffffff is reserved and MUST NOT be sent by a target in an R2T. 7066 Julian Satran Expires February 2003 161 7067 iSCSI 5-August-02 7069 9.9 Asynchronous Message 7071 An Asynchronous Message may be sent from the target to the initiator 7072 without corresponding to a particular command. The target specifies 7073 the reason for the event and sense data. 7075 Byte/ 0 | 1 | 2 | 3 | 7076 / | | | | 7077 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7078 +---------------+---------------+---------------+---------------+ 7079 0|.|.| 0x32 |1| Reserved | 7080 +---------------+---------------+---------------+---------------+ 7081 4|TotalAHSLength | DataSegmentLength | 7082 +---------------+---------------+---------------+---------------+ 7083 8| LUN or Reserved | 7084 + + 7085 12| | 7086 +---------------+---------------+---------------+---------------+ 7087 16| 0xffffffff | 7088 +---------------+---------------+---------------+---------------+ 7089 20| Reserved | 7090 +---------------+---------------+---------------+---------------+ 7091 24| StatSN | 7092 +---------------+---------------+---------------+---------------+ 7093 28| ExpCmdSN | 7094 +---------------+---------------+---------------+---------------+ 7095 32| MaxCmdSN | 7096 +---------------+---------------+---------------+---------------+ 7097 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved | 7098 +---------------+---------------+---------------+---------------+ 7099 40| Parameter2 or Reserved | Parameter3 or Reserved | 7100 +---------------+---------------+---------------+---------------+ 7101 44| Reserved | 7102 +---------------+---------------+---------------+---------------+ 7103 48| Header-Digest (Optional) | 7104 +---------------+---------------+---------------+---------------+ 7105 / DataSegment - Sense Data and iSCSI Event Data / 7106 +/ / 7107 +---------------+---------------+---------------+---------------+ 7108 | Data-Digest (Optional) | 7109 +---------------+---------------+---------------+---------------+ 7111 Julian Satran Expires February 2003 162 7112 iSCSI 5-August-02 7114 Some Asynchronous Messages are strictly related to iSCSI while oth- 7115 ers are related to SCSI [SAM2]. 7117 StatSN counts this PDU as an acknowledgeable event (StatSN is 7118 advanced), which allows for initiator and target state synchroniza- 7119 tion. 7121 9.9.1 AsyncEvent 7123 The codes used for iSCSI Asynchronous Messages (Events) are: 7125 0 - a SCSI Asynchronous Event is reported in the sense data. 7126 Sense Data that accompanies the report, in the data segment, 7127 identifies the condition. The sending of a SCSI Event (Asyn- 7128 chronous Event Reporting in SCSI terminology) is dependent on 7129 the target support for SCSI asynchronous event reporting (see 7130 [SAM2]) as indicated in the standard INQUIRY data (see 7131 [SPC]). Its use may be enabled by parameters in the SCSI Con- 7132 trol mode page (see [SPC]). 7134 1 - target requests Logout. This Async Message MUST be sent on 7135 the same connection as the one requesting to be logged out. 7136 The initiator MUST honor this request by issuing a Logout as 7137 early as possible, but no later than Parameter3 seconds. 7138 Initiator MUST send a Logout with a reason code of "Close the 7139 connection" OR "Close the session" to close all the connec- 7140 tions. Once this message is received, the initiator SHOULD 7141 NOT issue new iSCSI commands on the connection to be logged 7142 out. The target MAY reject any new I/O requests that it 7143 receives after this Message with the reason code "Waiting for 7144 Logout". If the initiator does not Logout in Parameter3 sec- 7145 onds, the target should send an Async PDU with iSCSI event 7146 code "Dropped the connection" if possible, or simply termi- 7147 nate the transport connection. Parameter1 and Parameter2 are 7148 reserved. 7150 2 - target indicates it will drop the connection. 7151 The Parameter1 field indicates the CID of the connection 7152 going to be dropped. 7153 The Parameter2 field (Time2Wait) indicates, in seconds, the 7154 minimum time to wait before attempting to reconnect or reas- 7155 sign. 7156 The Parameter3 field (Time2Retain) indicates the maximum time 7157 allowed to reassign commands after the initial wait (in 7158 Parameter2). 7159 If the initiator does not attempt to reconnect and/or reas- 7160 sign the outstanding commands within the time specified by 7161 Parameter3, or if Parameter3 is 0, the target will terminate 7162 all outstanding commands on this connection; no other 7164 Julian Satran Expires February 2003 163 7165 iSCSI 5-August-02 7167 responses should be expected from the target for the out- 7168 standing commands on this connection in this case. 7169 A value of 0 for Parameter2 indicates that reconnect can be 7170 attempted immediately. 7172 3 - target indicates it will drop all the connections of this 7173 session. 7174 Parameter1 field is reserved. 7175 The Parameter2 field (Time2Wait) indicates, in seconds, the 7176 minimum time to wait before attempting to reconnect. 7177 The Parameter3 field (Time2Retain) indicates the maximum time 7178 allowed to reassign commands after the initial wait (in 7179 Parameter2). 7180 If the initiator does not attempt to reconnect and/or reas- 7181 sign the outstanding commands within the time specified by 7182 Parameter3, or if Parameter3 is 0, the session is termi- 7183 nated. In this case, the target will terminate all outstand- 7184 ing commands in this session; no other responses should be 7185 expected from the target for the outstanding commands in this 7186 session. A value of 0 for Parameter2 indicates that recon- 7187 nect can be attempted immediately. 7189 4 - target requests parameter negotiation on this connection. 7190 The initiator MUST honor this request by issuing a Text 7191 Request (that can be empty) on the same connection as early 7192 as possible, but no later than Parameter3 seconds, unless a 7193 Text Request is already pending on the connection, or by 7194 issuing a Logout Request. If the initiator does not issue a 7195 Text Request the target may reissue the Asynchronous Message 7196 requesting parameter negotiation. 7198 255 - vendor specific iSCSI Event. The AsyncVCode details the 7199 vendor code, and data MAY accompany the report. 7201 All other event codes are reserved. 7203 9.9.2 AsyncVCode 7205 AsyncVCode is a vendor specific detail code that is valid only if the 7206 AsyncEvent field indicates a vendor specific event. Otherwise, it is 7207 reserved. 7209 9.9.3 LUN 7211 The LUN field MUST be valid if AsyncEvent is 0. Otherwise this field 7212 is reserved. 7214 Julian Satran Expires February 2003 164 7215 iSCSI 5-August-02 7217 9.9.4 Sense Data and iSCSI Event Data 7219 For a SCSI Event, this data accompanies the report in the data seg- 7220 ment and identifies the condition. 7222 For an iSCSI Event, additional vendor-unique data MAY accompany the 7223 Async event. Initiators MAY ignore the data when not understood while 7224 processing the rest of the PDU. 7226 If the DataSegmentLength is not 0, the format of the DataSegment is 7227 as follows: 7228 Byte/ 0 | 1 | 2 | 3 | 7229 / | | | | 7230 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7231 +---------------+---------------+---------------+---------------+ 7232 0|SenseLength | Sense Data | 7233 +---------------+---------------+---------------+---------------+ 7234 x/ Sense Data / 7235 +---------------+---------------+---------------+---------------+ 7236 y/ iSCSI Event Data / 7237 / / 7238 +---------------+---------------+---------------+---------------+ 7239 z| 7241 9.9.4.1 SenseLength 7243 Length of Sense Data. 7245 Julian Satran Expires February 2003 165 7246 iSCSI 5-August-02 7248 9.10 Text Request 7250 The Text Request is provided to allow for the exchange of informa- 7251 tion and for future extensions. It permits the initiator to inform a 7252 target of its capabilities or to request some special operations. 7254 Byte/ 0 | 1 | 2 | 3 | 7255 / | | | | 7256 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7257 +---------------+---------------+---------------+---------------+ 7258 0|.|I| 0x04 |F|C| Reserved | 7259 +---------------+---------------+---------------+---------------+ 7260 4|TotalAHSLength | DataSegmentLength | 7261 +---------------+---------------+---------------+---------------+ 7262 8| LUN or Reserved | 7263 + + 7264 12| | 7265 +---------------+---------------+---------------+---------------+ 7266 16| Initiator Task Tag | 7267 +---------------+---------------+---------------+---------------+ 7268 20| Target Transfer Tag or 0xffffffff | 7269 +---------------+---------------+---------------+---------------+ 7270 24| CmdSN | 7271 +---------------+---------------+---------------+---------------+ 7272 28| ExpStatSN | 7273 +---------------+---------------+---------------+---------------+ 7274 32/ Reserved / 7275 +/ / 7276 +---------------+---------------+---------------+---------------+ 7277 48| Header-Digest (Optional) | 7278 +---------------+---------------+---------------+---------------+ 7279 / DataSegment (Text) / 7280 +/ / 7281 +---------------+---------------+---------------+---------------+ 7282 | Data-Digest (Optional) | 7283 +---------------+---------------+---------------+---------------+ 7285 An initiator MUST have at most one outstanding Text Request on a con- 7286 nection at any given time. 7288 Julian Satran Expires February 2003 166 7289 iSCSI 5-August-02 7291 On a connection failure, an initiator must either explicitly abort 7292 any active allegiant text negotiation task or must cause such a task 7293 to be implicitly terminated by the target. 7295 9.10.1 F (Final) Bit 7297 When set to 1, indicates that this is the last or only text request 7298 in a sequence of Text Requests; otherwise, it indicates that more 7299 Text Requests will follow. 7301 9.10.2 C (Continue) Bit 7303 When set to 1, indicates that the text (set of key=value pairs) in 7304 this Text Request is not complete (it will be continued on subse- 7305 quent Text Requests); otherwise, it indicates that this Text Request 7306 ends a set of key=value pairs. A Text Request with the C bit set to 1 7307 MUST have the F bit set to 0. 7309 9.10.3 Initiator Task Tag 7311 The initiator assigned identifier for this Text Request. If the com- 7312 mand is sent as part of a sequence of text requests and responses, 7313 the Initiator Task Tag MUST be the same for all the requests within 7314 the sequence (similar to linked SCSI commands). The I bit for all 7315 requests in a sequence also MUST be the same. 7317 9.10.4 Target Transfer Tag 7319 When the Target Transfer Tag is set to the reserved value 0xffffffff, 7320 it tells the target that this is a new request and the target resets 7321 any internal state associated with the Initiator Task Tag (resets the 7322 current negotiation state). 7324 The target sets the Target Transfer Tag in a text response to a value 7325 other than the reserved value 0xffffffff whenever it indicates that 7326 it has more data to send or more operations to perform that are asso- 7327 ciated with the specified Initiator Task Tag. It MUST do so whenever 7328 it sets the F bit to 0 in the response. By copying the Target Trans- 7329 fer Tag from the response to the next Text Request, the initiator 7330 tells the target to continue the operation for the specific Initia- 7331 tor Task Tag. The initiator MUST ignore the Target Transfer Tag in 7332 the Text Response when the F bit is set to 1. 7334 Julian Satran Expires February 2003 167 7335 iSCSI 5-August-02 7337 This mechanism allows the initiator and target to transfer a large 7338 amount of textual data over a sequence of text-command/text-response 7339 exchanges or to perform extended negotiation sequences. 7341 If the Target Transfer Tag is not 0xffffffff the LUN field MUST be 7342 the one sent by the target in the Text Response. 7344 A target MAY reset its internal negotiation state if an exchange is 7345 stalled by the initiator for a long time or if it is running out of 7346 resources. 7348 Long text responses are handled as in the following example: 7350 I->T Text SendTargets=All (F=1,TTT=0xffffffff) 7351 T->I Text (F=0,TTT=0x12345678) 7352 I->T Text (F=1, TTT=0x12345678) 7353 T->I Text (F=0, TTT=0x12345678) 7354 I->T Text (F=1, TTT=0x12345678) 7355 ... 7356 T->I Text (F=1, TTT=0xffffffff) 7358 9.10.5 Text 7360 The data lengths of a text request MUST NOT exceed the iSCSI target 7361 MaxRecvDataSegmentLength (a per connection and per direction negoti- 7362 ated parameter). The text format is specified in Section 4.2 Text 7363 Mode Negotiation. 7365 Chapter 10 and Chapter 11 list some basic Text key=value pairs, some 7366 of which can be used in Login Request/Response and some in Text 7367 Request/Response. 7369 A key=value pair can span Text request or response boundaries (i.e., 7370 a key=value pair can start in one PDU and continue on the next - in 7371 other words the end of a PDU does not necessarily signal the end of a 7372 key value pair). 7374 The target responds by sending its response back to the initiator. 7375 The response text format is similar to the request text format. 7376 The text response MAY refer to key=value pairs presented in an ear- 7377 lier text request and the text in the request may refer to earlier 7378 responses. 7380 Chapter 4 details the rules for the Text Requests and Responses. 7382 Julian Satran Expires February 2003 168 7383 iSCSI 5-August-02 7385 Text operations are usually meant for parameter setting/negotia- 7386 tions, but can also be used to perform some long lasting operations. 7388 Text operations that take a long time should be placed in their own 7389 Text request. 7391 Julian Satran Expires February 2003 169 7392 iSCSI 5-August-02 7394 9.11 Text Response 7396 The Text Response PDU contains the target's responses to the initia- 7397 tor's Text request. The format of the Text field matches that of the 7398 Text request. 7400 Byte/ 0 | 1 | 2 | 3 | 7401 / | | | | 7402 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7403 +---------------+---------------+---------------+---------------+ 7404 0|.|.| 0x24 |F|C| Reserved | 7405 +---------------+---------------+---------------+---------------+ 7406 4|TotalAHSLength | DataSegmentLength | 7407 +---------------+---------------+---------------+---------------+ 7408 8| LUN or Reserved | 7409 + + 7410 12| | 7411 +---------------+---------------+---------------+---------------+ 7412 16| Initiator Task Tag | 7413 +---------------+---------------+---------------+---------------+ 7414 20| Target Transfer Tag or 0xffffffff | 7415 +---------------+---------------+---------------+---------------+ 7416 24| StatSN | 7417 +---------------+---------------+---------------+---------------+ 7418 28| ExpCmdSN | 7419 +---------------+---------------+---------------+---------------+ 7420 32| MaxCmdSN | 7421 +---------------+---------------+---------------+---------------+ 7422 36/ Reserved / 7423 +/ / 7424 +---------------+---------------+---------------+---------------+ 7425 48| Header-Digest (Optional) | 7426 +---------------+---------------+---------------+---------------+ 7427 / DataSegment (Text) / 7428 +/ / 7429 +---------------+---------------+---------------+---------------+ 7430 | Data-Digest (Optional) | 7431 +---------------+---------------+---------------+---------------+ 7433 9.11.1 F (Final) Bit 7435 When set to 1, in response to a Text Request with the Final bit set 7436 to 1, the F bit indicates that the target has finished the whole 7437 operation. Otherwise, if set to 0 in response to a Text Request with 7439 Julian Satran Expires February 2003 170 7440 iSCSI 5-August-02 7442 the Final Bit set to 1, it indicates that the target has more work to 7443 do (invites a follow-on text request). A Text Response with the F 7444 bit set to 1 in response to a Text Request with the F bit set to 0 is 7445 a protocol error. 7447 A Text Response with the F bit set to 1 MUST NOT contain key=value 7448 pairs that may require additional answers from the initiator. 7450 A Text Response with the F bit set to 1 MUST have a Target Transfer 7451 Tag field set to the reserved value of 0xffffffff. 7453 A Text Response with the F bit set to 0 MUST have a Target Transfer 7454 Tag field set to a value other than the reserved 0xffffffff. 7456 9.11.2 C (Continue) Bit 7458 When set to 1, indicates that the text (set of key=value pairs) in 7459 this Text Response is not complete (it will be continued on subse- 7460 quent Text Responses); otherwise, it indicates that this Text 7461 Response ends a set of key=value pairs. A Text Response with the C 7462 bit set to 1 MUST have the F bit set to 0. 7464 9.11.3 Initiator Task Tag 7466 The Initiator Task Tag matches the tag used in the initial Text 7467 Request. 7469 9.11.4 Target Transfer Tag 7471 When a target has more work to do (e.g., cannot transfer all the 7472 remaining text data in a single Text Response or has to continue the 7473 negotiation) and has enough resources to proceed, it MUST set the 7474 Target Transfer Tag to a value other than the reserved value of 7475 0xffffffff. Otherwise the Target Transfer Tag MUST be set to 7476 0xffffffff. 7478 When the Target Transfer Tag is not 0xffffffff the LUN field may be 7479 significant. 7481 The initiator MUST copy the Target Transfer Tag and LUN in its next 7482 request to indicate that it wants the rest of the data. 7484 When the target receives a Text Request with the Target Transfer Tag 7485 set to the reserved value of 0xffffffff, it resets its internal 7487 Julian Satran Expires February 2003 171 7488 iSCSI 5-August-02 7490 information (resets state) associated with the given Initiator Task 7491 Tag. 7493 When a target cannot finish the operation in a single Text Response, 7494 and does not have enough resources to continue it rejects the Text 7495 Request with the appropriate Reject code. 7497 A target may reset its internal state associated with an Initiator 7498 Task Tag (the current negotiation state), state expressed through the 7499 Target Transfer Tag if the initiator fails to continue the exchange 7500 for some time. The target may reject subsequent Text Requests with 7501 the Target Transfer Tag set to the "stale" value. 7503 9.11.5 StatSN 7505 The target StatSN variable is advanced by each Text Response sent. 7507 9.11.6 Text Response Data 7509 The data lengths of a text response MUST NOT exceed the iSCSI initia- 7510 tor MaxRecvDataSegmentLength (a per connection and per direction 7511 negotiated parameter). 7513 The text in the Text Response Data is governed by the same rules as 7514 the text in the Text Request Data (see Section 9.10.5 Text). 7516 Although the initiator is the requesting party and controls the 7517 request-response initiation and termination, the target can offer 7518 key=value pairs of its own as part of a sequence and not only in 7519 response to the initiator. 7521 Julian Satran Expires February 2003 172 7522 iSCSI 5-August-02 7524 9.12 Login Request 7526 After establishing a TCP connection between an initiator and a tar- 7527 get, the initiator MUST start a Login Phase to gain further access to 7528 the target's resources. 7530 The Login Phase (see Chapter 4) consists of a sequence of Login 7531 requests and responses that carry the same Initiator Task Tag. 7533 Login requests are always considered as immediate. 7535 Byte/ 0 | 1 | 2 | 3 | 7536 / | | | | 7537 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7538 +---------------+---------------+---------------+---------------+ 7539 0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min | 7540 +---------------+---------------+---------------+---------------+ 7541 4|TotalAHSLength | DataSegmentLength | 7542 +---------------+---------------+---------------+---------------+ 7543 8| ISID | 7544 + +---------------+---------------+ 7545 12| | TSIH | 7546 +---------------+---------------+---------------+---------------+ 7547 16| Initiator Task Tag | 7548 +---------------+---------------+---------------+---------------+ 7549 20| CID | Reserved | 7550 +---------------+---------------+---------------+---------------+ 7551 24| CmdSN | 7552 +---------------+---------------+---------------+---------------+ 7553 28| ExpStatSN or Reserved | 7554 +---------------+---------------+---------------+---------------+ 7555 32| Reserved | 7556 +---------------+---------------+---------------+---------------+ 7557 36| Reserved | 7558 +---------------+---------------+---------------+---------------+ 7559 40/ Reserved / 7560 +/ / 7561 +---------------+---------------+---------------+---------------+ 7562 48/ DataSegment - Login Parameters in Text request Format / 7563 +/ / 7564 +---------------+---------------+---------------+---------------+ 7566 Julian Satran Expires February 2003 173 7567 iSCSI 5-August-02 7569 9.12.1 T (Transit) Bit 7571 If set to 1, indicates that the initiator is ready to transit to the 7572 next stage. 7574 If the T bit is set to 1 and NSG is FullFeaturePhase, then this also 7575 indicates that the initiator is ready for the Final Login Response 7576 (see Chapter 4). 7578 9.12.2 C (Continue) Bit 7580 When set to 1, indicates that the text (set of key=value pairs) in 7581 this Login Request is not complete (it will be continued on subse- 7582 quent Login Requests); otherwise, it indicates that this Login 7583 Request ends a set of key=value pairs. A Login Request with the C 7584 bit set to 1 MUST have the T bit set to 0. 7586 9.12.3 CSG and NSG 7588 Through these fields, Current Stage (CSG) and Next Stage (NSG), the 7589 Login negotiation requests and responses are associated with a spe- 7590 cific stage in the session (SecurityNegotiation, LoginOperationalNe- 7591 gotiation, FullFeaturePhase) and may indicate the next stage they 7592 want to move to (see Chapter 4). The next stage value is valid only 7593 when the T bit is 1; otherwise, it is reserved. 7595 The stage codes are: 7597 - 0 - SecurityNegotiation 7598 - 1 - LoginOperationalNegotiation 7599 - 3 - FullFeaturePhase 7601 9.12.4 Version 7603 The version number of the current draft is 0x00. As such, all 7604 devices MUST carry version 0x00 for both Version-min and Version-max. 7606 9.12.4.1 Version-max 7608 Maximum Version number supported. 7610 All Login requests within the Login Phase MUST carry the same Ver- 7611 sion-max. 7613 The target MUST use the value presented with the first login request. 7615 Julian Satran Expires February 2003 174 7616 iSCSI 5-August-02 7618 9.12.4.2 Version-min 7620 All Login requests within the Login Phase MUST carry the same Ver- 7621 sion-min. The target MUST use the value presented with the first 7622 login request. 7624 9.12.5 ISID 7626 This is an initiator-defined component of the session identifier and 7627 is structured as follows (see [NDT] and Section 8.1.1 Conservative 7628 Reuse of ISIDs for details): 7630 Byte/ 0 | 1 | 2 | 3 | 7631 / | | | | 7632 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7633 +---------------+---------------+---------------+---------------+ 7634 8| T | A | B | C | 7635 +---------------+---------------+---------------+---------------+ 7636 12| D | 7637 +---------------+---------------+ 7639 The T field identifies the format and usage of A, B, C & D as indi- 7640 cated bellow: 7642 T 7644 00b OUI-format 7645 A&B are a 22 bit OUI 7646 (the I/G & U/L bits are omitted) 7647 C&D 24 bit qualifier 7648 01b EN - format (IANA Enterprise Number) 7649 A - reserved 7650 B&C EN (IANA Enterprise Number) 7651 D - Qualifier 7652 10b "Random" 7653 A - reserved 7654 B&C Random 7655 D - Qualifier 7656 11b A,B,C&D Reserved 7658 For the T field values 00b and 01b a combination of A and B (for 00b) 7659 or B and C (for 01b) identifies the vendor or organization whose com- 7660 ponent (software or hardware) generates this ISID. A vendor or orga- 7662 Julian Satran Expires February 2003 175 7663 iSCSI 5-August-02 7665 nization with one or more OUIs, or one or more Enterprise Numbers, 7666 MUST use at least one of these numbers and select the appropriate 7667 value for the T field when its components generate ISIDs. An OUI or 7668 EN MUST be set in the corresponding fields in network byte order 7669 (byte big-endian). 7671 If the T field is 10b, B and C are set to a random 24bit unsigned 7672 integer value in network byte order (byte big-endian). See [NDT] for 7673 how this affects the principle of "conservative reuse". 7675 The Qualifier field is a 16 or 24 bit unsigned integer value that 7676 provides a range of possible values for the ISID within the selected 7677 namespace. It may be set to any value, within the constraints speci- 7678 fied in the iSCSI protocol (see Section 2.4.3 Consequences of the 7679 Model and Section 8.1.1 Conservative Reuse of ISIDs). 7681 The T field value of 11b is reserved. 7683 If the ISID is derived from something assigned to a hardware adapter 7684 or interface by a vendor, as a preset default value, it MUST be con- 7685 figurable to a value assigned according to the SCSI port behavior 7686 desired by the system in which it is installed (see Section 8.1.1 7687 Conservative Reuse of ISIDs and Section 8.1.2 iSCSI Name, ISID and 7688 TPGT Use) and the resultant ISID MUST also be persistent over power 7689 cycles, reboot, card swap etc.. 7691 9.12.6 TSIH 7693 TSIH must be set in the first Login Request. The reserved value 0 7694 MUST be used on the first connection for a new session. Otherwise 7695 the TSIH sent by the target at the conclusion of successful login of 7696 the first connection for this session MUST be used. The TSIH identi- 7697 fies to the target the associated existing session for this new con- 7698 nection. 7700 All Login requests within a Login Phase MUST carry the same TSIH. 7702 The target MUST check the value presented with the first login 7703 request and act as specified in Section 4.3.1 Login Phase Start. 7705 9.12.7 Connection ID - CID 7707 A unique ID for this connection within the session. 7709 Julian Satran Expires February 2003 176 7710 iSCSI 5-August-02 7712 All Login requests within the Login Phase MUST carry the same CID. 7714 The target MUST use the value presented with the first login request. 7716 A Login request with a non-zero TSIH and a CID equal to that of an 7717 existing connection implies a logout of the connection followed by a 7718 Login (see Section 4.3.4 Connection reinstatement). For the details 7719 of the implicit Logout Request see also Section 9.14 Logout Request. 7721 9.12.8 CmdSN 7723 CmdSN is either the initial command sequence number of a session (for 7724 the first Login request of a session - the "leading" login) or the 7725 command sequence number in the command stream if the login is for a 7726 new connection in an existing session. 7728 Examples: 7730 - Login on a leading connection - if the leading login carries 7731 the CmdSN 123 all other login requests in the same login 7732 phase carry the CmdSN 123 and the first non-immediate com- 7733 mand in FullFeaturePhase also carries the CmdSN 123. 7735 - Login on other than a leading connection - if the current 7736 CmdSN at the time the first login on the connection is issued 7737 is 500 then that PDU carries CmdSN=500. Subsequent login 7738 requests that are needed to complete this login phase may 7739 carry a CmdSN higher than 500 if non-immediate requests that 7740 were issued on other connections in the same session advance 7741 CmdSN. 7743 If the login request is a leading login request the target MUST use 7744 the value presented in CmdSN as the target value for ExpCmdSN. 7746 9.12.9 ExpStatSN 7748 For the first Login Request on a connection this is ExpStatSN for the 7749 old connection and this field is valid only if the Login request 7750 restarts a connection (see Section 4.3.4 Connection reinstatement). 7752 For subsequent Login Requests it is used to acknowledge the Login 7753 Responses with their increasing StatSN values. 7755 Julian Satran Expires February 2003 177 7756 iSCSI 5-August-02 7758 9.12.10 Login Parameters 7760 The initiator MUST provide some basic parameters in order to enable 7761 the target to determine if the initiator may use the target's 7762 resources and the initial text parameters for the security exchange. 7764 All the rules specified in Section 9.10.5 Text for text requests also 7765 hold for login requests. Keys and their explanations are listed in 7766 Chapter 10 (security negotiation keys) and Chapter 11 (operational 7767 parameter negotiation keys). All keys in Chapter 11, except for the X 7768 extension formats, MUST be supported by iSCSI initiators and tar- 7769 gets. Keys in Chapter 10 only need to be supported when the function 7770 to which they refer is mandatory to implement. 7772 Julian Satran Expires February 2003 178 7773 iSCSI 5-August-02 7775 9.13 Login Response 7777 The Login Response indicates the progress and/or end of the Login 7778 Phase. 7780 Byte/ 0 | 1 | 2 | 3 | 7781 / | | | | 7782 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 7783 +---------------+---------------+---------------+---------------+ 7784 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max | Version-active| 7785 +---------------+---------------+---------------+---------------+ 7786 4|TotalAHSLength | DataSegmentLength | 7787 +---------------+---------------+---------------+---------------+ 7788 8| ISID | 7789 + +---------------+---------------+ 7790 12| | TSIH | 7791 +---------------+---------------+---------------+---------------+ 7792 16| Initiator Task Tag | 7793 +---------------+---------------+---------------+---------------+ 7794 20| Reserved | 7795 +---------------+---------------+---------------+---------------+ 7796 24| StatSN | 7797 +---------------+---------------+---------------+---------------+ 7798 28| ExpCmdSN | 7799 +---------------+---------------+---------------+---------------+ 7800 32| MaxCmdSN | 7801 +---------------+---------------+---------------+---------------+ 7802 36| Status-Class | Status-Detail | Reserved | 7803 +---------------+---------------+---------------+---------------+ 7804 40/ Reserved / 7805 +/ / 7806 +---------------+---------------+---------------+---------------+ 7807 48/ DataSegment - Login Parameters in Text request Format / 7808 +/ / 7809 +---------------+---------------+---------------+---------------+ 7811 9.13.1 Version-max 7813 This is the highest version number supported by the target. 7815 All Login responses within the Login Phase MUST carry the same Ver- 7816 sion-max. 7818 Julian Satran Expires February 2003 179 7819 iSCSI 5-August-02 7821 The initiator MUST use the value presented as a response to the first 7822 login request. 7824 9.13.2 Version-active 7826 Indicates the highest version supported by the target and initiator. 7827 If the target does not support a version within the range specified 7828 by the initiator, the target rejects the login and this field indi- 7829 cates the lowest version supported by the target. 7831 All Login responses within the Login Phase MUST carry the same Ver- 7832 sion-active. 7834 The initiator MUST use the value presented as a response to the first 7835 login request. 7837 9.13.3 TSIH 7839 The TSIH is the target assigned session identifying handle and its 7840 internal format and content are not defined by this protocol except 7841 for the value 0 that is reserved. Except for the Login Final-Response 7842 in a new session, this field should be set to the TSIH provided by 7843 the initiator in the Login Request. For a new session, the target 7844 MUST generate a non-zero TSIH and return it ONLY in the Login Final- 7845 Response (see Section 4.3 Login Phase). 7847 9.13.4 StatSN 7849 For the first Login Response (the response to the first Login 7850 Request), this is the starting status Sequence Number for the connec- 7851 tion. The next response of any kind, including the next login 7852 response, if any, in the same Login Phase, will carry this number + 7853 1. This field is valid only if the Status-Class is 0. 7855 9.13.5 Status-Class and Status-Detail 7857 The Status returned in a Login Response indicates the execution sta- 7858 tus of the Login Phase. The status includes: 7860 Status-Class 7861 Status-Detail 7863 0 Status-Class indicates success. 7865 Julian Satran Expires February 2003 180 7866 iSCSI 5-August-02 7868 A non-zero Status-Class indicates an exception. In this case, Status- 7869 Class is sufficient for a simple initiator to use when handling 7870 exceptions, without having to look at the Status-Detail. The Status- 7871 Detail allows finer-grained exception handling for more sophisti- 7872 cated initiators, as well as better information for logging. 7874 The status classes are as follows: 7876 0 - Success - indicates that the iSCSI target successfully 7877 received, understood, and accepted the request. The number- 7878 ing fields (StatSN, ExpCmdSN, MaxCmdSN) are valid only if 7879 Status-Class is 0. 7881 1 - Redirection - indicates that the initiator must take fur- 7882 ther action to complete the request. This is usually due to 7883 the target moving to a different address. All of the redirec- 7884 tion status class responses MUST return one or more text key 7885 parameters of the type "TargetAddress", which indicates the 7886 target's new address. 7888 2 - Initiator Error (not a format error) - indicates that the 7889 initiator most likely caused the error. This MAY be due to a 7890 request for a resource for which the initiator does not have 7891 permission. The request should not be tried again. 7893 3 - Target Error - indicates that the target sees no errors in 7894 the initiator's login request, but is currently incapable of 7895 fulfilling the request. The initiator may re-try the same 7896 login request later. 7898 The table below shows all of the currently allocated status codes. 7899 The codes are in hexadecimal; the first byte is the status class and 7900 the second byte is the status detail. 7902 Julian Satran Expires February 2003 181 7903 iSCSI 5-August-02 7905 ----------------------------------------------------------------- 7906 Status | Code | Description 7907 |(hex) | 7908 ----------------------------------------------------------------- 7909 Success | 0000 | Login is proceeding OK (*1). 7910 ----------------------------------------------------------------- 7911 Target Moved | 0101 | The requested iSCSI Target Name (ITN) 7912 Temporarily | | has temporarily moved 7913 | | to the address provided. 7914 ----------------------------------------------------------------- 7915 Target Moved | 0102 | The requested ITN has permanently moved 7916 Permanently | | to the address provided. 7917 ----------------------------------------------------------------- 7918 Initiator | 0200 | Miscellaneous iSCSI initiator 7919 Error | | errors. 7920 ---------------------------------------------------------------- 7921 Authentication| 0201 | The initiator could not be 7922 Failure | | successfully authenticated. 7923 ----------------------------------------------------------------- 7924 Authorization | 0202 | The initiator is not allowed access 7925 Failure | | to the given target. 7926 ----------------------------------------------------------------- 7927 Not Found | 0203 | The requested ITN does not 7928 | | exist at this address. 7929 ----------------------------------------------------------------- 7930 Target Removed| 0204 | The requested ITN has been removed and 7931 | |no forwarding address is provided. 7932 ----------------------------------------------------------------- 7933 Unsupported | 0205 | The requested iSCSI version range is 7934 Version | | not supported by the target. 7935 ----------------------------------------------------------------- 7936 Too many | 0206 | Too many connections on this SSID 7937 connections | | 7938 ----------------------------------------------------------------- 7939 Missing | 0207 | Missing parameters (e.g., iSCSI 7940 parameter | | Initiator and/or Target Name). 7941 ----------------------------------------------------------------- 7942 Can't include | 0208 | Target does not support session 7943 in session | | spanning to this connection (address) 7944 ----------------------------------------------------------------- 7945 Session type | 0209 | Target does not support this type of 7946 Not supported | | of session or not from this Initiator. 7947 ----------------------------------------------------------------- 7949 Julian Satran Expires February 2003 182 7950 iSCSI 5-August-02 7952 Session does | 020a | Attempt to add a connection 7953 not exist | | to an non-existent session 7954 ----------------------------------------------------------------- 7955 Invalid during| 020b | Invalid Request type during Login 7956 login | | 7957 ----------------------------------------------------------------- 7958 Target Error | 0300 | Target hardware or software error. 7959 ----------------------------------------------------------------- 7960 Service | 0301 | The iSCSI service or target is not 7961 Unavailable | | currently operational. 7962 ----------------------------------------------------------------- 7963 Out of | 0302 | The target has insufficient session, 7964 Resources | | connection, or other resources. 7965 ----------------------------------------------------------------- 7967 (*1)If the response T bit is 1 in both the request and the matching 7968 response and the NSG is FullFeaturePhase in both the request and the 7969 matching response the Login Phase is finished and the initiator may 7970 proceed to issue SCSI commands. 7972 If the Status Class is not 0, the initiator and target MUST close the 7973 TCP connection. 7975 If the target wishes to reject the login request for more than one 7976 reason, it should return the primary reason for the rejection. 7978 9.13.6 T (Transit) bit 7980 The T bit is set to 1 as an indicator of the end of the stage. If the 7981 T bit is set to 1 and NSG is FullFeaturePhase, then this is also the 7982 Final Login Response (see Chapter 4). A T bit of 0 indicates a "par- 7983 tial" response, which means "more negotiation needed". 7985 A login response with a T bit set to 1 MUST NOT contain key=value 7986 pairs that may require additional answers from the initiator within 7987 the same stage. 7989 If the status class is 0, the T bit MUST NOT be set to 1 if the T bit 7990 in the request was set to 0. 7992 9.13.7 C (Continue) Bit 7994 When set to 1, indicates that the text (set of key=value pairs) in 7995 this Login Response is not complete (it will be continued on subse- 7997 Julian Satran Expires February 2003 183 7998 iSCSI 5-August-02 8000 quent Login Responses); otherwise, it indicates that this Login 8001 Response ends a set of key=value pairs. A Login Response with the C 8002 bit set to 1 MUST have the T bit set to 0. 8004 9.13.8 Login Parameters 8006 The target MUST provide some basic parameters in order to enable the 8007 initiator to determine if is connected to the correct port and the 8008 initial text parameters for the security exchange. 8010 All the rules specified in Section 9.11.6 Text Response Data for text 8011 responses also hold for login responses. Keys and their explana- 8012 tions are listed in Chapter 10 (security negotiation keys) and Chap- 8013 ter 11 (operational parameter negotiation keys). All keys in Chapter 8014 11, except for the X extension formats, MUST be supported by iSCSI 8015 initiators and targets. Keys in Chapter 10, only need to be sup- 8016 ported when the function to which they refer is mandatory to imple- 8017 ment. 8019 Julian Satran Expires February 2003 184 8020 iSCSI 5-August-02 8022 9.14 Logout Request 8024 The Logout request is used to perform a controlled closing of a con- 8025 nection. 8027 An initiator MAY use a logout request to remove a connection from a 8028 session or to close an entire session. 8030 After sending the Logout request PDU, an initiator MUST NOT send any 8031 new iSCSI requests on the closing connection. If the Logout request 8032 is intended to close the session, new iSCSI requests MUST NOT be sent 8033 on any of the connections participating in the session. 8035 When receiving a Logout request with the reason code of "close the 8036 connection" or "close the session", the target MUST terminate all 8037 pending commands, whether acknowledged via ExpCmdSN or not, on that 8038 connection or session respectively. 8040 When receiving a Logout request with the reason code "remove connec- 8041 tion for recovery", the target MUST discard all requests not yet 8042 acknowledged via ExpCmdSN that were issued on the specified connec- 8043 tion and suspend all data/status/R2T transfers on behalf of pending 8044 commands on the specified connection. 8046 The target then issues the Logout response and half-closes the TCP 8047 connection (sends FIN). After receiving the Logout response and 8048 attempting to receive the FIN (if still possible), the initiator MUST 8049 completely close the logging-out connection. For the terminated com- 8050 mands, no additional responses should be expected. 8052 A Logout for a CID may be performed on a different transport connec- 8053 tion when the TCP connection for the CID has already been termi- 8054 nated. In such a case, only a logical "closing" of the iSCSI 8055 connection for the CID is implied with a Logout. 8057 All commands that were not terminated or not completed (with status) 8058 and acknowledged when the connection is closed completely can be 8059 reassigned to a new connection if the target supports connection 8060 recovery. 8062 If an initiator intends to start recovery for a failing connection, 8063 it MUST use either the Logout request to "clean-up" the target end of 8064 a failing connection and enable recovery to start, or use the Login 8066 Julian Satran Expires February 2003 185 8067 iSCSI 5-August-02 8069 request with a non-zero TSIH and the same CID on a new connection for 8070 the same effect (see Section 9.14.3 CID). In sessions with a single 8071 connection, the connection can be closed then a new connection 8072 reopened and a connection reinstatement login can be used for recov- 8073 ery (see Section 4.3.4 Connection reinstatement). 8075 A successful completion of a logout request with the reason code of 8076 "close the connection" or "remove the connection for recovery" 8077 results at the target in the discarding of unacknowledged commands 8078 (commands that have arrived on the connection being logged out but 8079 have not been delivered to SCSI because one or more commands with a 8080 smaller CmdSN have not been received by iSCSI - see Section 2.2.2.1 8081 Command Numbering and Acknowledging) received on the connection being 8082 logged out. The resulting holes in command sequence numbers will 8083 have to be handled by appropriate recovery (see Chapter 5) unless the 8084 session is also closed. 8086 The entire logout discussion in this section is applicable also for 8087 an implicit Logout effected by way of a connection reinstatement or 8088 session reinstatement. When a Login Request performs an implicit 8089 Logout, the implicit Logout is performed as if having the reason 8090 codes specified below: 8092 Reason code Type of implicit Logout 8093 ------------------------------------------- 8094 0 session reinstatement 8095 1 connection reinstatement when 8096 the operational ErrorRecoveryLevel < 2 8097 2 connection reinstatement when 8098 the operational ErrorRecoveryLevel = 2 8100 Julian Satran Expires February 2003 186 8101 iSCSI 5-August-02 8103 Byte/ 0 | 1 | 2 | 3 | 8104 / | | | | 8105 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8106 +---------------+---------------+---------------+---------------+ 8107 0|.|I| 0x06 |1| Reason Code | Reserved | 8108 +---------------+---------------+---------------+---------------+ 8109 4|TotalAHSLength | DataSegmentLength | 8110 +---------------------------------------------------------------+ 8111 8/ Reserved / 8112 +/ / 8113 +---------------+---------------+---------------+---------------+ 8114 16| Initiator Task Tag | 8115 +---------------+---------------+---------------+---------------+ 8116 20| CID or Reserved | Reserved | 8117 +---------------+---------------+---------------+---------------+ 8118 24| CmdSN | 8119 +---------------+---------------+---------------+---------------+ 8120 28| ExpStatSN | 8121 +---------------+---------------+---------------+---------------+ 8122 32/ Reserved / 8123 +/ / 8124 +---------------+---------------+---------------+---------------+ 8125 48| Header-Digest (Optional) | 8126 +---------------+---------------+---------------+---------------+ 8128 9.14.1 Reason Code 8130 Reason Code indicates the reason for Logout as follows: 8132 0 - closes the session. All commands associated with the ses- 8133 sion (if any) are terminated. 8135 1 - closes the connection. All commands associated with connec- 8136 tion (if any) are terminated. 8138 2 - removes the connection for recovery. Connection is closed 8139 and all commands associated with it, if any, are to be pre- 8140 pared for a new allegiance. 8142 All other values are reserved. 8144 9.14.2 TotalAHSLength and DataSegmentLength 8146 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 8148 Julian Satran Expires February 2003 187 8149 iSCSI 5-August-02 8151 9.14.3 CID 8153 This is the connection ID of the connection to be closed (including 8154 closing the TCP stream). This field is valid only if the reason code 8155 is not "close the session". 8157 9.14.4 ExpStatSN 8159 This is the last ExpStatSN value for the connection to be closed. 8161 9.14.5 Implicit termination of tasks 8163 A target implicitly terminates the active tasks in three cases due to 8164 iSCSI protocol: 8166 a) When a connection is implicitly or explicitly logged out with 8167 the Reason code of "Closes the connection" and there are active 8168 tasks allegiant to that connection. 8170 b) When a connection fails and eventually the connection state 8171 times out (state transition M1 in Section 6.2.2 State Transition 8172 Descriptions for Initiators and Targets) and there are active 8173 tasks allegiant to that connection. 8175 c) When a successful recovery Logout is performed while there are 8176 active tasks allegiant to that connection, and those tasks eventu- 8177 ally time out after the Time2Wait and Time2Retain periods without 8178 allegiance reassignment. 8180 If the tasks terminated in any of the above cases are SCSI tasks, 8181 they must be internally terminated with CHECK CONDITION status with a 8182 sense key of unit attention and ASC/ASCQ values of 0x6E/0x00 (COM- 8183 MAND TO LOGICAL UNIT FAILED). Note that this status is meaningful 8184 only for appropriately handling the internal SCSI state with respect 8185 to ordering aspects such as queued commands because this status is 8186 never communicated back as a terminating status to the initiator. 8188 Julian Satran Expires February 2003 188 8189 iSCSI 5-August-02 8191 9.15 Logout Response 8193 The logout response is used by the target to indicate if the cleanup 8194 operation for the connection(s) has completed. 8196 After Logout, the TCP connection referred by the CID MUST be closed 8197 at both ends (or all connections must be closed if the logout reason 8198 was session close). 8200 Byte/ 0 | 1 | 2 | 3 | 8201 / | | | | 8202 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8203 +---------------+---------------+---------------+---------------+ 8204 0|.|.| 0x26 |1| Reserved | Response | Reserved | 8205 +---------------+---------------+---------------+---------------+ 8206 4|TotalAHSLength | DataSegmentLength | 8207 +---------------------------------------------------------------+ 8208 8/ Reserved / 8209 +/ / 8210 +---------------+---------------+---------------+---------------+ 8211 16| Initiator Task Tag | 8212 +---------------+---------------+---------------+---------------+ 8213 20| Reserved | 8214 +---------------+---------------+---------------+---------------+ 8215 24| StatSN | 8216 +---------------+---------------+---------------+---------------+ 8217 28| ExpCmdSN | 8218 +---------------+---------------+---------------+---------------+ 8219 32| MaxCmdSN | 8220 +---------------+---------------+---------------+---------------+ 8221 36| Reserved | 8222 +---------------------------------------------------------------+ 8223 40| Time2Wait | Time2Retain | 8224 +---------------+---------------+---------------+---------------+ 8225 44| Reserved | 8226 +---------------+---------------+---------------+---------------+ 8227 48| Header-Digest (Optional) | 8228 +---------------+---------------+---------------+---------------+ 8230 9.15.1 Response 8232 Logout response: 8234 0 - connection or session closed successfully. 8236 Julian Satran Expires February 2003 189 8237 iSCSI 5-August-02 8239 1 - CID not found. 8241 2 - connection recovery is not supported (if Logout reason code 8242 was recovery and target does not support it - as indicated by 8243 the ErrorRecoveryLevel). 8245 3 - cleanup failed for various reasons. 8247 9.15.2 TotalAHSLength and DataSegmentLength 8249 For this PDU TotalAHSLength and DataSegmentLength MUST be 0. 8251 9.15.3 Time2Wait 8253 If the Logout response code is 0 and if the operational ErrorRecov- 8254 eryLevel is 2, this is the minimum amount of time, in seconds, to 8255 wait before attempting task reassignment. If the Logout response 8256 code is 0 and if the operational ErrorRecoveryLevel is less than 2, 8257 this field is to be ignored. 8259 This field is invalid if the Logout response code is 1. 8261 If the Logout response code is 2 or 3, this field specifies the mini- 8262 mum time to wait before attempting a new implicit or explicit logout. 8264 If Time2Wait is 0, the reassignment or a new Logout may be attempted 8265 immediately. 8267 9.15.4 Time2Retain 8269 If the Logout response code is 0 and if the operational ErrorRecov- 8270 eryLevel is 2, this is the maximum amount of time, in seconds, after 8271 the initial wait (Time2Wait), the target waits for the allegiance 8272 reassignment for any active task after which the task state is dis- 8273 carded. If the Logout response code is 0 and if the operational 8274 ErrorRecoveryLevel is less than 2, this field is to be ignored. 8276 This field is invalid if the Logout response code is 1. 8278 If the Logout response code is 2 or 3, this field specifies the maxi- 8279 mum amount of time, in seconds, after the initial wait (Time2Wait), 8280 the target waits for a new implicit or explicit logout. 8282 Julian Satran Expires February 2003 190 8283 iSCSI 5-August-02 8285 If it is the last connection of a session, the whole session state is 8286 discarded after Time2Retain. 8288 If Time2Retain is 0, the target had already discarded the connection 8289 (and possibly the session) state along with the task states. No 8290 reassignment or Logout is required in this case. 8292 Julian Satran Expires February 2003 191 8293 iSCSI 5-August-02 8295 9.16 SNACK Request 8297 Byte/ 0 | 1 | 2 | 3 | 8298 / | | | | 8299 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8300 +---------------+---------------+---------------+---------------+ 8301 0|.|.| 0x10 |1|.|.|.| Type | Reserved | 8302 +---------------+---------------+---------------+---------------+ 8303 4|TotalAHSLength | DataSegmentLength | 8304 +---------------+---------------+---------------+---------------+ 8305 8| LUN or Reserved | 8306 + + 8307 12| | 8308 +---------------+---------------+---------------+---------------+ 8309 16| Initiator Task Tag or 0xffffffff | 8310 +---------------+---------------+---------------+---------------+ 8311 20| Target Transfer Tag or SNACK Tag or 0xffffffff | 8312 +---------------+---------------+---------------+---------------+ 8313 24| Reserved | 8314 +---------------+---------------+---------------+---------------+ 8315 28| ExpStatSN | 8316 +---------------+---------------+---------------+---------------+ 8317 32/ Reserved / 8318 +/ / 8319 +---------------+---------------+---------------+---------------+ 8320 40| BegRun | 8321 +---------------------------------------------------------------+ 8322 44| RunLength | 8323 +---------------------------------------------------------------+ 8324 48| Header-Digest (Optional) | 8325 +---------------+---------------+---------------+---------------+ 8327 Support for all SNACK types is mandatory if the implementation sup- 8328 ports ErrorRecoveryLevel greater than zero. 8330 The SNACK request is used to request the retransmission of numbered- 8331 responses, data, or R2T PDUs from the target. The SNACK request indi- 8332 cates the numbered-responses or data "runs" whose retransmission is 8333 requested by the target, where the run starts with the first StatSN, 8334 DataSN, or R2TSN whose retransmission is requested and indicates also 8335 the number of Status, Data, or R2T PDUs requested including the 8336 first. 0 has special meaning when used as a starting number and 8337 length: 8339 Julian Satran Expires February 2003 192 8340 iSCSI 5-August-02 8342 - when used in RunLength it means all PDUs starting with the 8343 initial 8344 - when used in both BegRun and RunLength it means all unac- 8345 knowledged PDUs 8347 The numbered-response(s) or R2T(s), requested by a SNACK, MUST be 8348 delivered as exact replicas of the ones the transmitted originally 8349 except for the fields ExpCmdSN, MaxCmdSN and ExpDataSN which MUST 8350 carry the current values. R2T(s)requested by SNACK MUST carry also 8351 the current value of StatSN. 8353 The numbered Data-In PDUs, requested by a Data SNACK MUST be deliv- 8354 ered as exact replicas of the ones the transmitted originally except 8355 the fields ExpCmdSN and MaxCmdSN which MUST carry the current values 8356 and except for resegmentation (see Section 9.16.3 Resegmentation). 8358 Any SNACK that requests a numbered-response, Data, or R2T that was 8359 not sent by the target or was already acknowledged by the initiator 8360 MUST be rejected with a reason code of "Protocol error". 8362 9.16.1 Type 8364 This field encodes the SNACK function as follows: 8366 0-Data/R2T SNACK - requesting retransmission of one or more 8367 Data-In or R2T PDU. 8369 1-Status SNACK - requesting retransmission of one or more num- 8370 bered response. 8372 2-DataACK - positively acknowledges Data-In PDUs. 8374 3-R-Data SNACK - requesting retransmission of Data-In PDUs with 8375 possible resegmentation and status tagging. 8377 All other values are reserved. 8379 Data/R2T SNACK, Status SNACK or R-Data SNACK for a command MUST pre- 8380 cede status acknowledgement for the given command. 8382 9.16.2 Data Acknowledgement 8384 If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST 8385 issue a SNACK of type DataACK after receiving a Data-In PDU with the 8387 Julian Satran Expires February 2003 193 8388 iSCSI 5-August-02 8390 A bit set to 1. However, if the initiator has detected holes in the 8391 input sequence, it MUST postpone issuing the SNACK of type DataACK 8392 until the holes are filled. An initiator MAY ignore the A bit if it 8393 deems that the bit is being set aggressively by the target (i.e., 8394 before the MaxBurstLength limit is reached). 8396 The DataACK is used to free resources at the target and not to 8397 request or imply data retransmission. 8399 An initiator MUST NOT request retransmission for any data it had 8400 already acknowledged. 8402 9.16.3 Resegmentation 8404 If the initiator MaxRecvDataSegmentLength changed between the origi- 8405 nal transmission and the time the initiator requests retransmission 8406 the initiator MUST issue a R-Data SNACK (see Section 9.16.1 Type). 8407 With R-Data SNACK the initiator indicates that it discards all the 8408 unacknowledged data and expects the target to resend it and it 8409 expects also resegmentation. In this case the retransmitted Data-In 8410 PDUs MAY be different from the ones originally sent, in order to 8411 reflect changes in MaxRecvDataSegmentLength. Their DataSN starts with 8412 the BegRun of the last DataACK received by the target if any was 8413 received or 0 otherwise and is increased by 1 for each resent Data-In 8414 PDU. 8416 A target that has received a R-Data SNACK MUST return a SCSI Response 8417 that contains a copy of the R-Data SNACK SNACK Tag in the SCSI 8418 Response SNACK Tag field as its last or only Response (i.e., if it 8419 has already sent a response containing another value in the SNACK Tag 8420 field or had the status included in the last Data-In PDU it must send 8421 a new SCSI Response PDU). If a target sends more than one SCSI 8422 Response PDU due to this rule all SCSI responses must carry the same 8423 StatSN (see also Section 9.4.4 SNACK Tag). If an initiator attempts 8424 to recover a lost SCSI Response (with a Status-SNACK - see Section 8425 9.16.1 Type) when more than one response has been sent, the target 8426 will send the SCSI Response with the latest content known to the tar- 8427 get, including the last SNACK Tag for the command. 8429 For considerations in allegiance reassignment of a task to a connec- 8430 tion with a different MaxRecvDataSegmentLength, refer Section 5.2.2 8431 Allegiance Reassignment. 8433 Julian Satran Expires February 2003 194 8434 iSCSI 5-August-02 8436 9.16.4 Initiator Task Tag 8438 For Status SNACK and DataACK, the Initiator Task Tag MUST be set to 8439 the reserved value 0xffffffff. In all other cases, the Initiator Task 8440 Tag field MUST be set to the Initiator Task Tag of the referenced 8441 command. 8443 9.16.5 Target Transfer Tag or SNACK Tag 8445 For an R-Data SNACK this field MUST contain a value that is differ- 8446 ent from 0 or 0xffffffff and is unique for the task (identified by 8447 the Initiator Task Tag). This value MUST be copied by the iSCSI tar- 8448 get in the last or only SCSI Response PDU it issues for the command. 8450 For DataACK the Target Transfer Tag has to contain a copy of the Tar- 8451 get Transfer Tag and LUN provided with the SCSI Data-In PDU with the 8452 A bit set to 1. 8454 In all other cases, the Target Transfer Tag field MUST be set to the 8455 reserved value of 0xffffffff. 8457 9.16.6 BegRun 8459 The DataSN, R2TSN, or StatSN of the first PDU whose retransmission is 8460 requested (Data/R2T and Status SNACK) or the next expected DataSN 8461 (DataACK SNACK). 8463 BegRun 0 when used in conjunction with RunLength 0 means resend all 8464 unacknowledged Data-In, R2T or Response PDUs. 8466 BegRun MUST be 0 for a R-Data SNACK. 8468 9.16.7 RunLength 8470 The number of PDUs whose retransmission is requested. 8472 RunLength 0 signals that all Data-In, R2T or Response PDUs carrying 8473 the numbers equal to or greater than BegRun have to be resent. 8475 The RunLength MUST also be 0 for a DataACK SNACK as well as for R- 8476 Data SNACK. 8478 Julian Satran Expires February 2003 195 8479 iSCSI 5-August-02 8481 9.17 Reject 8483 Byte/ 0 | 1 | 2 | 3 | 8484 / | | | | 8485 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8486 +---------------+---------------+---------------+---------------+ 8487 0|.|.| 0x3f |1| Reserved | Reason | Reserved | 8488 +---------------+---------------+---------------+---------------+ 8489 4|TotalAHSLength | DataSegmentLength | 8490 +---------------+---------------+---------------+---------------+ 8491 8/ Reserved / 8492 +/ / 8493 +---------------+---------------+---------------+---------------+ 8494 16| 0xffffffff | 8495 +---------------+---------------+---------------+---------------+ 8496 20| Reserved | 8497 +---------------+---------------+---------------+---------------+ 8498 24| StatSN | 8499 +---------------+---------------+---------------+---------------+ 8500 28| ExpCmdSN | 8501 +---------------+---------------+---------------+---------------+ 8502 32| MaxCmdSN | 8503 +---------------+---------------+---------------+---------------+ 8504 36| DataSN or Reserved | 8505 +---------------+---------------+---------------+---------------+ 8506 40| Reserved | 8507 +---------------+---------------+---------------+---------------+ 8508 44| Reserved | 8509 +---------------+---------------+---------------+---------------+ 8510 48| Header-Digest (Optional) | 8511 +---------------+---------------+---------------+---------------+ 8512 xx/ Complete Header of Bad PDU / 8513 +/ / 8514 +---------------+---------------+---------------+---------------+ 8515 yy/Vendor specific data (if any) / 8516 / / 8517 +---------------+---------------+---------------+---------------+ 8518 zz| Data-Digest (Optional) | 8519 +---------------+---------------+---------------+---------------+ 8521 Reject is used to indicate an iSCSI error condition (protocol, unsup- 8522 ported option etc.). 8524 Julian Satran Expires February 2003 196 8525 iSCSI 5-August-02 8527 9.17.1 Reason 8529 The reject Reason is coded as follows: 8531 +------+-----------------------------------------+------------------+ 8532 | Code | Explanation | Can the original | 8533 | (hex)| | PDU be re-sent? | 8534 +------+-----------------------------------------+------------------+ 8535 | 0x01 | Reserved | no | 8536 | | | | 8537 | 0x02 | Data (payload) Digest Error | yes (Note 1) | 8538 | | | | 8539 | 0x03 | SNACK Reject | yes | 8540 | | | | 8541 | 0x04 | Protocol Error (e.g., SNACK request for | no | 8542 | | a status that was already acknowledged) | | 8543 | | | | 8544 | 0x05 | Command not supported | no | 8545 | | | | 8546 | 0x06 | Immediate Command Reject - too many | yes | 8547 | | immediate commands | | 8548 | | | | 8549 | 0x07 | Task in progress | no | 8550 | | | | 8551 | 0x08 | Invalid Data ACK | no | 8552 | | | | 8553 | 0x09 | Invalid PDU field | no (Note 2) | 8554 | | | | 8555 | 0x0a | Long Operation Reject - Can't generate | yes | 8556 | | Target Transfer Tag - out of resources | | 8557 | | | | 8558 | 0x0b | Negotiation Reset | no | 8559 | | | | 8560 | 0x0c | Waiting for Logout | no | 8561 +------+-----------------------------------------+------------------+ 8563 Note 1: For iSCSI Data-Out PDU retransmission is done only if the 8564 target requests retransmission with a recovery R2T. However, if this 8565 is the data digest error on immediate data, the initiator may choose 8566 to retransmit the whole PDU including the immediate data. 8568 Julian Satran Expires February 2003 197 8569 iSCSI 5-August-02 8571 Note 2: A target should use this reason code for all invalid values 8572 of PDU fields that are meant to describe a task, a response or a 8573 data transfer. Some examples are invalid TTT/ITT, buffer offset, LUN 8574 qualifying a TTT, an invalid sequence number in a SNACK. 8576 All other values for Reason are reserved. 8578 In all the cases in which a pre-instantiated SCSI task is terminated 8579 because of the reject, the target MUST issue a proper SCSI command 8580 response with CHECK CONDITION as described in Section 9.4.3 Response. 8581 In those cases in which a status for the SCSI task was already sent 8582 before the reject no additional status is required. If the error is 8583 detected while data from the initiator is still expected (the com- 8584 mand PDU did not contain all the data and the target has not received 8585 a Data-out PDU with the Final bit 1 for the unsolicited data - if any 8586 and all outstanding R2Ts - if any), the target MUST wait until it 8587 receives the last expected Data-out PDUs with the F bit set to 1 8588 before sending the Response PDU. 8590 For additional usage semantics of Reject PDU, see Section 5.3 Usage 8591 Of Reject PDU in Recovery. 8593 9.17.2 DataSN 8595 This field is valid only if the Reason code is "Protocol error" and 8596 the SNACK was a Data/R2T SNACK. The DataSN/R2TSN is the last valid 8597 sequence number that the target sent for the task. 8599 9.17.3 StatSN, ExpCmdSN and MaxCmdSN 8601 Those fields carry their usual values and are not related to the 8602 rejected command 8604 9.17.4 Complete Header of Bad PDU 8606 The target returns the header (not including digest) of the PDU in 8607 error as the data of the response. 8609 Julian Satran Expires February 2003 198 8610 iSCSI 5-August-02 8612 9.18 NOP-Out 8614 Byte/ 0 | 1 | 2 | 3 | 8615 / | | | | 8616 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8617 +---------------+---------------+---------------+---------------+ 8618 0|.|I| 0x00 |1| Reserved | 8619 +---------------+---------------+---------------+---------------+ 8620 4|TotalAHSLength | DataSegmentLength | 8621 +---------------+---------------+---------------+---------------+ 8622 8| LUN or Reserved | 8623 + + 8624 12| | 8625 +---------------+---------------+---------------+---------------+ 8626 16| Initiator Task Tag or 0xffffffff | 8627 +---------------+---------------+---------------+---------------+ 8628 20| Target Transfer Tag or 0xffffffff | 8629 +---------------+---------------+---------------+---------------+ 8630 24| CmdSN | 8631 +---------------+---------------+---------------+---------------+ 8632 28| ExpStatSN | 8633 +---------------+---------------+---------------+---------------+ 8634 32/ Reserved / 8635 +/ / 8636 +---------------+---------------+---------------+---------------+ 8637 48| Header-Digest (Optional) | 8638 +---------------+---------------+---------------+---------------+ 8639 / DataSegment - Ping Data (optional) / 8640 +/ / 8641 +---------------+---------------+---------------+---------------+ 8642 | Data-Digest (Optional) | 8643 +---------------+---------------+---------------+---------------+ 8645 A NOP-Out may be used by an initiator as a "ping request" to verify 8646 that a connection/session is still active and all its components are 8647 operational. The NOP-In response is the "ping echo". 8649 A NOP-Out is also sent by an initiator in response to a NOP-In. 8651 A NOP-Out may also be used to confirm a changed ExpStatSN if another 8652 PDU will not be available for a long time. 8654 Julian Satran Expires February 2003 199 8655 iSCSI 5-August-02 8657 When used as a ping request, the Initiator Task Tag MUST be set to a 8658 valid value (not the reserved 0xffffffff). 8660 Upon receipt of a NOP-In with the Target Transfer Tag set to a valid 8661 value (not the reserved 0xffffffff), the initiator MUST respond with 8662 a NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST con- 8663 tain a copy of the NOP-In Target Transfer Tag. 8665 When a target receives the NOP-Out with a valid Initiator Task Tag, 8666 it MUST respond with a Nop-In Response (see NOP-In). 8668 9.18.1 Initiator Task Tag 8670 An initiator assigned identifier for the operation. 8672 The NOP-Out MUST have the Initiator Task Tag set to a valid value 8673 only if a response in the form of NOP-In is requested. Otherwise the 8674 Initiator Task Tag MUST be set to 0xffffffff. 8676 If the Initiator Task Tag contains 0xffffffff the I bit MUST be set 8677 to 1 and the CmdSN is not advanced after this PDU is sent. 8679 9.18.2 Target Transfer Tag 8681 A target assigned identifier for the operation. 8683 The NOP-Out MUST have the Target Transfer Tag set only if it is 8684 issued in response to a NOP-In with a valid Target Transfer Tag. In 8685 this case, it copies the Target Transfer Tag from the NOP-In PDU. 8686 Otherwise the Target Transfer Tag MUST be set to 0xffffffff. 8688 When the Target Transfer Tag is set to a value other than 0xffffffff, 8689 the LUN field MUST also be copied from the NOP-In. 8691 9.18.3 Ping Data 8693 Ping data are reflected in the NOP-In Response. The length of the 8694 reflected data are limited to MaxRecvDataSegmentLength. The length of 8695 ping data are indicated by the DataSegmentLength. 0 is a valid value 8696 for the Data Segment Length and indicates the absence of ping data. 8698 Julian Satran Expires February 2003 200 8699 iSCSI 5-August-02 8701 9.19 NOP-In 8703 Byte/ 0 | 1 | 2 | 3 | 8704 / | | | | 8705 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 8706 +---------------+---------------+---------------+---------------+ 8707 0|.|.| 0x20 |1| Reserved | 8708 +---------------+---------------+---------------+---------------+ 8709 4|TotalAHSLength | DataSegmentLength | 8710 +---------------+---------------+---------------+---------------+ 8711 8| LUN or Reserved | 8712 + + 8713 12| | 8714 +---------------+---------------+---------------+---------------+ 8715 16| Initiator Task Tag or 0xffffffff | 8716 +---------------+---------------+---------------+---------------+ 8717 20| Target Transfer Tag or 0xffffffff | 8718 +---------------+---------------+---------------+---------------+ 8719 24| StatSN | 8720 +---------------+---------------+---------------+---------------+ 8721 28| ExpCmdSN | 8722 +---------------+---------------+---------------+---------------+ 8723 32| MaxCmdSN | 8724 +---------------+---------------+---------------+---------------+ 8725 36/ Reserved / 8726 +/ / 8727 +---------------+---------------+---------------+---------------+ 8728 48| Header-Digest (Optional) | 8729 +---------------+---------------+---------------+---------------+ 8730 / DataSegment - Return Ping Data / 8731 +/ / 8732 +---------------+---------------+---------------+---------------+ 8733 | Data-Digest (Optional) | 8734 +---------------+---------------+---------------+---------------+ 8736 NOP-In is either sent by a target as a response to a NOP-Out, as a 8737 "ping" to an initiator or as a means to carry a changed ExpCmdSN and/ 8738 or MaxCmdSN if another PDU will not be available for a long time (as 8739 determined by the target). 8741 When a target receives the NOP-Out with a valid Initiator Task Tag 8742 (not the reserved value 0xffffffff), it MUST respond with a NOP-In 8744 Julian Satran Expires February 2003 201 8745 iSCSI 5-August-02 8747 with the same Initiator Task Tag that was provided in the NOP-Out 8748 request. It MUST also duplicate up to the first MaxRecvDataSeg- 8749 mentLength bytes of the initiator provided Ping Data. For such a 8750 response, the Target Transfer Tag MUST be 0xffffffff. 8752 Otherwise, when a target sends a NOP-In that is not a response to a 8753 Nop-Out received from the initiator, the Initiator Task Tag MUST be 8754 set to 0xffffffff and the Data Segment MUST NOT contain any data 8755 (DataSegmentLength MUST be 0). 8757 9.19.1 Target Transfer Tag 8759 A target assigned identifier for the operation. 8761 If the target is responding to a NOP-Out, this is set to the reserved 8762 value 0xffffffff. 8764 If the target is sending a NOP-In as a Ping (intending to receive a 8765 corresponding NOP-Out), this field is set to a valid value (not the 8766 reserved 0xffffffff). 8768 If the target is initiating a NOP-In without wanting to receive a 8769 corresponding NOP-Out, this field MUST hold the reserved value of 8770 0xffffffff. 8772 9.19.2 StatSN 8774 The StatSN field will contain always the next StatSN. However, when 8775 the Initiator Task Tag is set to 0xffffffff StatSN for the connec- 8776 tion is not advanced after this PDU is sent. 8778 9.19.3 LUN 8780 A LUN MUST be set to a correct value when the Target Transfer Tag is 8781 valid (not the reserved value 0xffffffff). 8783 Julian Satran Expires February 2003 202 8784 iSCSI 5-August-02 8786 10. iSCSI Security Keys and Authentication Methods 8788 Only the following keys are used during the SecurityNegotiation stage 8789 of the Login Phase: 8791 SessionType 8792 InitiatorName 8793 TargetName 8794 TargetAddress 8795 InitiatorAlias 8796 TargetAlias 8797 TargetPortalGroupTag 8798 AuthMethod and the keys used by the authentication methods 8799 specified under Section 10.1 AuthMethod along with all of 8800 their associated keys as well as Vendor Specific Authentica- 8801 tion Methods. 8803 All other keys MUST NOT be used. 8805 SessionType, InitiatorName, TargetName, InitiatorAlias, TargetAlias 8806 and TargetPortalGroupTag are described in Chapter 11 as they can be 8807 used also in the OperationalNegotiation stage. 8809 All security keys have connection-wide applicability. 8811 10.1 AuthMethod 8813 Use: During Login - Security Negotiation 8814 Senders: Initiator and Target 8815 Scope: connection 8817 AuthMethod = 8819 The main item of security negotiation is the authentication method 8820 (AuthMethod). 8822 The authentication methods that can be used (appear in the list-of- 8823 values) are either those listed in the following table or are vendor- 8824 unique methods: 8826 Julian Satran Expires February 2003 203 8827 iSCSI 5-August-02 8829 +------------------------------------------------------------+ 8830 | Name | Description | 8831 +------------------------------------------------------------+ 8832 | KRB5 | Kerberos V5 - defined in [RFC1510] | 8833 +------------------------------------------------------------+ 8834 | SPKM1 | Simple Public-Key GSS-API Mechanism | 8835 | | defined in [RFC2025] | 8836 +------------------------------------------------------------+ 8837 | SPKM2 | Simple Public-Key GSS-API Mechanism | 8838 | | defined in [RFC2025] | 8839 +------------------------------------------------------------+ 8840 | SRP | Secure Remote Password | 8841 | | defined in [RFC2945] | 8842 +------------------------------------------------------------+ 8843 | CHAP | Challenge Handshake Authentication Protocol| 8844 | | defined in [RFC1944] | 8845 +------------------------------------------------------------+ 8846 | None | No authentication | 8847 +------------------------------------------------------------+ 8849 The AuthMethod selection is followed by an "authentication exchange" 8850 specific to the authentication method selected. 8852 The authentication method proposal may be made by either the initia- 8853 tor or the target. However the initiator MUST make the first step 8854 specific to the selected authentication method as soon as it is 8855 selected. It follows that if the target makes the authentication 8856 method proposal the initiator sends the first keys(s) of the exchange 8857 together with its authentication method selection. 8859 The authentication exchange authenticates the initiator to the tar- 8860 get, and optionally, the target to the initiator. Authentication is 8861 not mandatory to use but MUST be supported by the target and initia- 8862 tor. 8864 The initiator and target MUST implement CHAP. All other authentica- 8865 tion methods are OPTIONAL to implement. 8867 Private or public extension algorithms MAY also be negotiated for 8868 authentication methods. Whenever a private or public extension algo- 8869 rithm is offered, "None" or "CHAP" MUST be listed as an option in 8870 order to guarantee interoperability. 8872 Julian Satran Expires February 2003 204 8873 iSCSI 5-August-02 8875 Extension authentication methods MUST be named using of the follow- 8876 ing two formats: 8878 a) Z-reversed.vendor.dns_name.do_something= 8879 b) Z<#>= 8881 Authentication methods named using the Z- format a are used as pri- 8882 vate extensions. Authentication methods named using the Z# format are 8883 used as public extensions must be registered with IANA and MUST be 8884 described by an informational RFC. 8886 For all the public or private extension authentication methods the 8887 method specific keys MUST conform to the format specified in Section 8888 4.1 Text Format for standard-label. 8890 For private extension authentication methods, to identify the ven- 8891 dor, we suggest you use the reversed DNS-name as a prefix to the 8892 proper digest names. 8894 The part of digest-name following Z- and Z# MUST conform to the for- 8895 mat for standard-label specified in Section 4.1 Text Format. 8897 Support for public or private extension authentication methods is 8898 OPTIONAL. 8900 The following subsections define the specific exchanges for each of 8901 the standardized authentication methods. As mentioned earlier the 8902 first step is always done by the initiator. 8904 10.1.1 Kerberos 8906 For KRB5 (Kerberos V5) [RFC1510], the initiator MUST use: 8908 KRB_AP_REQ= 8910 where KRB_AP_REQ is the client message as defined in [RFC1510]. 8912 If the initiator authentication fails, the target MUST respond with a 8913 Login reject with "Authentication Failure" status. Otherwise, if the 8914 initiator has selected the mutual authentication option (by setting 8915 MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), the tar- 8916 get MUST reply with: 8918 Julian Satran Expires February 2003 205 8919 iSCSI 5-August-02 8921 KRB_AP_REP= 8923 where KRB_AP_REP is the server's response message as defined in 8924 [RFC1510]. 8926 If mutual authentication was selected and target authentication 8927 fails, the initiator MUST close the connection. 8929 KRB_AP_REQ and KRB_AP_REP are binary-values and their binary length 8930 (not the length of the character string that represents them in 8931 encoded form) MUST not exceed 65536 bytes. 8933 10.1.2 Simple Public-Key Mechanism (SPKM) 8935 For SPKM1 and SPKM2 [RFC2025], the initiator MUST use: 8937 SPKM_REQ= 8939 where SPKM-REQ is the first initiator token as defined in [RFC2025]. 8941 [RFC2025] defines situations where each side may send an error token 8942 that may cause the peer to re-generate and resend its last token. 8943 This scheme is followed in iSCSI, and the error token syntax is: 8945 SPKM_ERROR= 8947 However, SPKM-DEL tokens that are defined by [RFC2025] for fatal 8948 errors will not be used by iSCSI. If the target needs to send a SPKM- 8949 DEL token, it will, instead, send a Login "login reject" message with 8950 the "Authentication Failure" status and terminate the connection. If 8951 the initiator needs to send a SPKM-DEL token, it will close the con- 8952 nection. 8954 In the following sections, we assume that no SPKM-ERROR tokens are 8955 required. 8957 If the initiator authentication fails, the target MUST return an 8958 error. Otherwise, if the AuthMethod is SPKM1 or if the initiator has 8959 selected the mutual authentication option (by setting mutual-state 8960 bit in the options field of the REQ-TOKEN in the SPKM-REQ), the tar- 8961 get MUST reply with: 8963 Julian Satran Expires February 2003 206 8964 iSCSI 5-August-02 8966 SPKM_REP_TI= 8968 where SPKM-REP-TI is the target token as defined in [RFC2025]. 8970 If mutual authentication was selected and target authentication 8971 fails, the initiator MUST close the connection. Otherwise, if the 8972 AuthMethod is SPKM1, the initiator MUST continue with: 8974 SPKM_REP_IT= 8976 where SPKM-REP-IT is the second initiator token as defined in 8977 [RFC2025]. If the initiator authentication fails, the target MUST 8978 answer with a Login reject with "Authentication Failure" status. 8980 SPKM requires support for very long authentication items. 8982 All the SPKM-* tokens are binary-values and their binary length (not 8983 the length of the character string that represents them in encoded 8984 form) MUST not exceed 65536 bytes. 8986 10.1.3 Secure Remote Password (SRP) 8988 For SRP [RFC2945], the initiator MUST use: 8990 SRP_U= TargetAuth=Yes /* or TargetAuth=No */ 8992 The target MUST answer with a Login reject with the "Authorization 8993 Failure" status or reply with: 8995 SRP_GROUP= SRP_s= 8997 Where G1,G2... are proposed groups, in order of preference. 8999 The initiator MUST either close the connection or continue with: 9001 SRP_A= SRP_GROUP= 9003 Where G is one of G1,G2... that were proposed by the target. 9005 The target MUST answer with a Login reject with the "Authentication 9006 Failure" status or reply with: 9008 Julian Satran Expires February 2003 207 9009 iSCSI 5-August-02 9011 SRP_B= 9013 The initiator MUST close the connection or continue with: 9015 SRP_M= 9017 If the initiator authentication fails, the target MUST answer with a 9018 Login reject with "Authentication Failure" status. Otherwise, if the 9019 initiator sent TargetAuth=Yes in the first message (requiring target 9020 authentication), the target MUST reply with: 9022 SRP_HM= 9024 If the target authentication fails, the initiator MUST close the con- 9025 nection. 9027 Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using 9028 the SHA1 hash function, i.e., SRP-SHA1) and G,Gn (Gn stands for 9029 G1,G2...) are identifiers of SRP groups specified in [SEC-IPS]. G,Gn 9030 and U are text strings, s,A,B,M, and H(A | M | K) are binary-values. 9031 The length of s,A,B,M and H(A | M | K) in binary form (not the length 9032 of the character string that represents them in encoded form) MUST 9033 not exceed 1024 bytes. 9035 For the SRP_GROUP, all the groups specified in [SEC-IPS] up to 1536 9036 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be supported 9037 by initiators and targets. To guarantee interoperability, targets 9038 MUST always offer "SRP-1536" as one of the proposed groups. 9040 10.1.4 Challenge Handshake Authentication Protocol (CHAP) 9042 For CHAP [RFC1994], the initiator MUST use: 9044 CHAP_A= 9046 Where A1,A2... are proposed algorithms, in order of preference. 9048 The target MUST answer with a Login reject with the "Authentication 9049 Failure" status or reply with: 9051 CHAP_A= CHAP_I= CHAP_C= 9053 Julian Satran Expires February 2003 208 9054 iSCSI 5-August-02 9056 Where A is one of A1,A2... that were proposed by the initiator. 9058 The initiator MUST continue with: 9060 CHAP_N= CHAP_R= 9062 or, if it requires target authentication, with: 9064 CHAP_N= CHAP_R= CHAP_I= CHAP_C= 9066 If the initiator authentication fails, the target MUST answer with a 9067 Login reject with "Authentication Failure" status. Otherwise, if the 9068 initiator required target authentication, the target MUST reply with 9070 CHAP_N= CHAP_R= 9072 If target authentication fails, the initiator MUST close the connec- 9073 tion. 9075 Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name, Algo- 9076 rithm, Identifier, Challenge, and Response as defined in [RFC1994], N 9077 is a text string, A,A1,A2, and I are numbers, and C and R are binary- 9078 values and their binary length (not the length of the character 9079 string that represents them in encoded form) MUST not exceed 1024 9080 bytes. 9082 For the Algorithm, as stated in [RFC1994], one value is required 9083 to be implemented: 9085 5 (CHAP with MD5) 9087 To guarantee interoperability, initiators MUST always offer it as one 9088 of the proposed algorithms. 9090 Julian Satran Expires February 2003 209 9091 iSCSI 5-August-02 9093 11. Login/Text Operational Keys 9095 Some session specific parameters MUST only be carried on the leading 9096 connection and cannot be changed after the leading connection login 9097 (e.g., MaxConnections, the maximum number of connections). This holds 9098 for a single connection session with regard to connection restart. 9099 The keys that fall into this category have the use LO (Leading Only). 9101 Keys that can be used only during login have the use IO (initialize 9102 only) while those that can be used in both the Login Phase and Full 9103 Feature Phase have the use ALL. 9105 Keys that can only be used during Full Feature Phase use FFPO (Full 9106 Feature Phase only). 9108 Keys marked as Any-Stage may appear also in the SecurityNegotiation 9109 stage while all other keys described in this chapter are operational 9110 keys. 9112 Keys that do not require an answer are marked as Declarative 9114 Key scope is indicated as session-wide (SW) or connection-only (CO). 9116 Result function, wherever mentioned, states the function that can be 9117 applied to check the validity of the responder selection. Minimum 9118 means that the selected value cannot exceed the offered value. Maxi- 9119 mum means that the selected value cannot be lower than the offered 9120 value. AND means that the selected value must be a possible result of 9121 a Boolean "and" function with an arbitrary Boolean value (e.g., if 9122 the offered value is No the selected value must be No). OR means that 9123 the selected value must be a possible result of a Boolean "or" func- 9124 tion with an arbitrary Boolean value (e.g., if the offered value is 9125 Yes the selected value must be Yes). 9127 11.1 HeaderDigest and DataDigest 9129 Use: IO 9130 Senders: Initiator and Target 9131 Scope: CO 9133 HeaderDigest = 9134 DataDigest = 9136 Julian Satran Expires February 2003 210 9137 iSCSI 5-August-02 9139 Default is None for both HeaderDigest and DataDigest. 9141 Digests enable the checking of end-to-end non-cryptographic data 9142 integrity beyond the integrity checks provided by the link layers and 9143 the covering of the whole communication path including all elements 9144 that may change the network level PDUs such as routers, switches, and 9145 proxies. 9147 The following table lists cyclic integrity checksums that can be 9148 negotiated for the digests and that MUST be implemented by every 9149 iSCSI initiator and target. These digest options only have error 9150 detection significance. 9152 +---------------------------------------------+ 9153 | Name | Description | Generator | 9154 +---------------------------------------------+ 9155 | CRC32C | 32 bit CRC |0x11edc6f41| 9156 +---------------------------------------------+ 9157 | None | no digest | 9158 +---------------------------------------------+ 9160 The generator polynomial for this digest is given in hex-nota- 9161 tion(e.g., 0x3b stands for 0011 1011 and the polynomial is 9162 x**5+X**4+x**3+x+1). 9164 When the Initiator and Target agree on a digest, this digest MUST be 9165 used for every PDU in Full Feature Phase. 9167 Padding bytes, when present, in a segment covered by a CRC, SHOULD be 9168 set to 0 and are included in the CRC. 9170 The CRC MUST be calculated by a method that produces the same results 9171 as the following process: 9173 - The PDU bits are considered as the coefficients of a polyno- 9174 mial M(x) of degree n-1; bit 7 of the lowest numbered byte is 9175 considered the most significant bit (x^n-1), followed by bit 9176 6 of the lowest numbered byte and through bit 0 of the high- 9177 est numbered byte (x^0). 9179 - The most significant 32 bits are complemented. 9181 - The polynomial is multiplied by x^32 then divided by G(x). 9182 The generator polynomial produces a remainder R(x) of degree 9183 <= 31. 9185 Julian Satran Expires February 2003 211 9186 iSCSI 5-August-02 9188 - The coefficients of R(x) are considered a 32 bit sequence. 9190 - The bit sequence is complemented and the result is the CRC. 9192 - the CRC bits are mapped into the digest word - the x^31 coef- 9193 ficient in bit 7 of the lowest numbered byte of the digest 9194 continuing to through the byte up to the x^24 coefficient in 9195 bit 0 of the lowest numbered byte, continuing with the x^23 9196 coefficient in bit 7 of next byte through x^0 in bit 0 of the 9197 highest numbered byte. 9199 - Computing the CRC over any segment (data or header) extended 9200 to include the CRC built using the generator 0x11edc6f41 will 9201 get always the value 0x1c2d19ed as its final remainder 9202 (R(x)). This value is given here in its polynomial form - 9203 i.e. not mapped as the digest word 9205 For a discussion about selection criteria for the CRC see [iSCSI- 9206 CRC]. For a detailed analysis of the iSCSI polynomial see 9207 [Castagnoli93]. 9209 Private or public extension algorithms MAY also be negotiated for 9210 digests. Whenever a private or public extension algorithm is offered, 9211 "None" or "CRC32C" MUST be listed as an option in order to guarantee 9212 interoperability. 9214 Extension digest algorithms MUST be named using of the following two 9215 formats: 9217 a) Y-reversed.vendor.dns_name.do_something= 9218 b) Y<#>= 9220 Digests named using the Y- format are used for private purposes 9221 (unregistered). Digests named using the Y# format (public extension) 9222 must be registered with IANA and MUST be described by an informa- 9223 tional RFC. 9225 For private extension digests, to identify the vendor, we suggest you 9226 use the reversed DNS-name as a prefix to the proper digest names. 9228 The part of digest-name following Y- and Y# MUST conform to the for- 9229 mat for standard-label specified in Section 4.1 Text Format. 9231 Support for public or private extension digests is OPTIONAL. 9233 Julian Satran Expires February 2003 212 9234 iSCSI 5-August-02 9236 11.2 MaxConnections 9238 Use: LO 9239 Senders: Initiator and Target 9240 Scope: SW 9241 Irrelevant when: SessionType=Discovery 9243 MaxConnections= 9245 Default is 1. 9246 Result function is Minimum. 9248 Initiator and target negotiate the maximum number of connections 9249 requested/acceptable. 9251 11.3 SendTargets 9253 Use: FFPO 9254 Senders: Initiator 9255 Scope: SW 9257 For a complete description, see Appendix D. - SendTargets Operation. 9259 11.4 TargetName 9261 Use: IO by initiator, FFPO by target - only as response to a Sendtar- 9262 gets, Declarative, Any-Stage 9263 Senders: Initiator and Target 9264 Scope: SW 9266 TargetName= 9268 Examples: 9270 TargetName=iqn.1993-11.com.disk-vendor.diskarrays.sn.45678 9271 TargetName=eui.020000023B040506 9273 The initiator of the TCP connection MUST provide this key to the 9274 remote endpoint in the first login request if the initiator is not 9275 establishing a discovery session. The iSCSI Target Name specifies the 9276 worldwide unique name of the target. 9278 The TargetName key may also be returned by the "SendTargets" text 9279 request (which is its only use when issued by a target). 9281 Julian Satran Expires February 2003 213 9282 iSCSI 5-August-02 9284 TargetName MUST not be redeclared within the login phase. 9286 11.5 InitiatorName 9288 Use: IO, Declarative, Any-Stage 9289 Senders: Initiator 9290 Scope: SW 9292 InitiatorName= 9294 Examples: 9296 InitiatorName=iqn.1992-04.com.os-vendor.plan9.cdrom.12345 9297 InitiatorName=iqn.2001-02.com.ssp.users.customer235.host90 9299 The initiator of the TCP connection MUST provide this key to the 9300 remote endpoint at the first Login of the Login Phase for every con- 9301 nection. The Initiator key enables the initiator to identify itself 9302 to the remote endpoint. 9304 InitiatorName MUST not be redeclared within the login phase. 9306 11.6 TargetAlias 9308 Use: ALL, Declarative, Any-Stage 9309 Senders: Target 9310 Scope: SW 9312 TargetAlias= 9314 Examples: 9316 TargetAlias=Bob-s Disk 9317 TargetAlias=Database Server 1 Log Disk 9318 TargetAlias=Web Server 3 Disk 20 9320 If a target has been configured with a human-readable name or 9321 description, this name SHOULD be communicated to the initiator dur- 9322 ing a Login Response PDU if SessionType=Normal (see Section 11.21 9323 SessionType). This string is not used as an identifier, nor is meant 9324 to be used for authentication or authorization decisions. It can be 9325 displayed by the initiator's user interface in a list of targets to 9326 which it is connected. 9328 Julian Satran Expires February 2003 214 9329 iSCSI 5-August-02 9331 11.7 InitiatorAlias 9333 Use: ALL, Declarative, Any-Stage 9334 Senders: Initiator 9335 Scope: SW 9337 InitiatorAlias= 9339 Examples: 9341 InitiatorAlias=Web Server 4 9342 InitiatorAlias=spyalley.nsa.gov 9343 InitiatorAlias=Exchange Server 9345 If an initiator has been configured with a human-readable name or 9346 description, it SHOULD be communicated to the target during a Login 9347 Request PDU. If not, the host name can be used instead. This string 9348 is not used as an identifier, nor is meant to be used for authentica- 9349 tion or authorization decisions. It can be displayed by the target's 9350 user interface in a list of initiators to which it is connected. 9352 11.8 TargetAddress 9354 Use: ALL, Declarative, Any-Stage 9355 Senders: Target 9356 Scope: SW 9358 TargetAddress=domainname[:port][,portal-group-tag] 9360 The domainname can be specified as either a DNS host name, a dotted- 9361 decimal IPv4 address, or a bracketed IPv6 address as specified in 9362 [RFC2732]. 9364 If the TCP port is not specified, it is assumed to be the IANA- 9365 assigned default port for iSCSI (see Section 12 IANA Considerations). 9367 If the TargetAddress is returned as the result of a redirect status 9368 in a login response, the comma and portal group tag MUST be omitted. 9370 If the TargetAddress is returned within a SendTargets response, the 9371 portal group tag MUST be included. 9373 Examples: 9375 Julian Satran Expires February 2003 215 9376 iSCSI 5-August-02 9378 TargetAddress=10.0.0.1:5003,1 9379 TargetAddress=[1080:0:0:0:8:800:200C:417A],65 9380 TargetAddress=[1080::8:800:200C:417A]:5003,1 9381 TargetAddress=computingcenter.acme.com,23 9383 Use of the portal-group-tag is described in Appendix D. - SendTar- 9384 gets Operation. The formats for the port and portal-group-tag are the 9385 same as the one specified in Section 11.9 TargetPortalGroupTag. 9387 11.9 TargetPortalGroupTag 9389 Use: IO by target, Declarative, Any-Stage 9390 Senders: Target 9391 Scope: SW 9393 TargetPortalGroupTag=<16-bit-binary-value> 9395 Examples: 9396 TargetPortalGroupTag=1 9398 Target portal group tag is a 16-bit binary-value that uniquely iden- 9399 tifies a portal group within an iSCSI target node. This key carries 9400 the value of the tag of the portal group that is servicing the Login 9401 request. The iSCSI target returns this key to the initiator in the 9402 Login Response PDU to the first Login Request PDU that has the C bit 9403 set to 0. 9405 For the complete usage expectations of this key see Section 4.3 Login 9406 Phase. 9408 11.10 InitialR2T 9410 Use: LO 9411 Senders: Initiator and Target 9412 Scope: SW 9413 Irrelevant when: SessionType=Discovery 9415 InitialR2T= 9417 Examples: 9419 I->InitialR2T=No 9421 Julian Satran Expires February 2003 216 9422 iSCSI 5-August-02 9424 T->InitialR2T=No 9426 Default is Yes. 9427 Result function is OR. 9429 The InitialR2T key is used to turn off the default use of R2T for 9430 unidirectional and the output part of bidirectional commands, thus 9431 allowing an initiator to start sending data to a target as if it has 9432 received an initial R2T with Buffer Offset=Immediate Data Length and 9433 Desired Data Transfer Length=(min(FirstBurstLength, Expected 9434 DataTransfer Length) - Received Immediate Data Length). 9436 The default action is that R2T is required, unless both the initia- 9437 tor and the target send this key-pair attribute specifying 9438 InitialR2T=No. Only the first outgoing data burst (immediate data 9439 and/or separate PDUs) can be sent unsolicited (i.e., not requiring an 9440 explicit R2T). 9442 11.11 ImmediateData 9444 Use: LO 9445 Senders: Initiator and Target 9446 Scope: SW 9447 Irrelevant when: SessionType=Discovery 9449 ImmediateData= 9451 Default is Yes. 9452 Result function is AND. 9454 The initiator and target negotiate support for immediate data. To 9455 turn immediate data off, the initiator or target must state its 9456 desire to do so. ImmediateData can be turned on if both the initia- 9457 tor and target have ImmediateData=Yes. 9459 If ImmediateData is set to Yes and InitialR2T is set to Yes 9460 (default), then only immediate data are accepted in the first burst. 9462 If ImmediateData is set to No and InitialR2T is set to Yes, then the 9463 initiator MUST NOT send unsolicited data and the target MUST reject 9464 unsolicited data with the corresponding response code. 9466 Julian Satran Expires February 2003 217 9467 iSCSI 5-August-02 9469 If ImmediateData is set to No and InitialR2T is set to No, then the 9470 initiator MUST NOT send unsolicited immediate data, but MAY send one 9471 unsolicited burst of Data-OUT PDUs. 9473 If ImmediateData is set to Yes and InitialR2T is set to No, then the 9474 initiator MAY send unsolicited immediate data and/or one unsolicited 9475 burst of Data-OUT PDUs. 9477 The following table is a summary of unsolicited data options: 9479 +----------+-------------+------------------+--------------+ 9480 |InitialR2T|ImmediateData| Unsolicited |Immediate Data| 9481 | | | Data Out PDUs | | 9482 +----------+-------------+------------------+--------------+ 9483 | No | No | Yes | No | 9484 +----------+-------------+------------------+--------------+ 9485 | No | Yes | Yes | Yes | 9486 +----------+-------------+------------------+--------------+ 9487 | Yes | No | No | No | 9488 +----------+-------------+------------------+--------------+ 9489 | Yes | Yes | No | Yes | 9490 +----------+-------------+------------------+--------------+ 9492 11.12 MaxRecvDataSegmentLength 9494 Use: ALL, Declarative 9495 Senders: Initiator and Target 9496 Scope: CO 9498 MaxRecvDataSegmentLength= 9500 Default is 8192 bytes. 9502 The initiator or target declares the maximum data segment length in 9503 bytes it can receive in an iSCSI PDU. 9505 The transmitter (initiator or target) is required to send PDUs with a 9506 data segment not exceeding MaxRecvDataSegmentLength of the receiver. 9508 A target receiver is additionally limited by MaxBurstLength for 9509 solicited data and FirstBurstLength for unsolicited data and an ini- 9510 tiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor 9512 Julian Satran Expires February 2003 218 9513 iSCSI 5-August-02 9515 unsolicited PDUs exceeding FirstBurstLength (or FirstBurstLength- 9516 Immediate Data Length if immediate data where sent). 9518 11.13 MaxBurstLength 9520 Use: LO 9521 Senders: Initiator and Target 9522 Scope: SW 9523 Irrelevant when: SessionType=Discovery 9525 MaxBurstLength= 9527 Default is 262144 (256 Kbytes). 9528 Result function is Minimum. 9530 The initiator and target negotiate maximum SCSI data payload in bytes 9531 in a Data-In or a solicited Data-Out iSCSI sequence. A sequence con- 9532 sists of one or more consecutive Data-In or Data-Out PDUs ending with 9533 a Data-In or Data-Out PDU with the F bit set to one. 9535 11.14 FirstBurstLength 9537 Use: LO 9538 Senders: Initiator and Target 9539 Scope: SW 9540 Irrelevant when: SessionType=Discovery 9541 Irrelevant when: ( InitialR2T=Yes and ImmediateData=No ) 9543 FirstBurstLength= 9545 Default is 65536 (64 Kbytes). 9546 Result function is Minimum. 9548 The initiator and target negotiate the maximum amount in bytes of 9549 unsolicited data an iSCSI initiator may send to the target during the 9550 execution of a single SCSI command. This covers the immediate data 9551 (if any) and the sequence of unsolicited Data-Out PDUs (if any) that 9552 follow the command. 9554 FirstBurstLength MUST NOT exceed MaxBurstLength. 9556 11.15 DefaultTime2Wait 9558 Use: LO 9560 Julian Satran Expires February 2003 219 9561 iSCSI 5-August-02 9563 Senders: Initiator and Target 9564 Scope: SW 9566 DefaultTime2Wait= 9568 Default is 2. 9569 Result function is Maximum. 9571 The initiator and target negotiate the minimum time, in seconds, to 9572 wait before attempting an explicit/implicit logout or an active task 9573 reassignment after an unexpected connection termination or a connec- 9574 tion reset. 9576 A value of 0 indicates that logout or active task reassignment can be 9577 attempted immediately. 9579 11.16 DefaultTime2Retain 9581 Use: LO 9582 Senders: Initiator and Target 9583 Scope: SW 9585 DefaultTime2Retain= 9587 Default is 20. 9588 Result function is Minimum. 9590 The initiator and target negotiate the maximum time, in seconds after 9591 an initial wait (Time2Wait), before which an active task reassign- 9592 ment is still possible after an unexpected connection termination or 9593 a connection reset. 9595 This value is also the session state timeout if the connection in 9596 question is the last LOGGED_IN connection in the session. 9598 A value of 0 indicates that connection/task state is immediately dis- 9599 carded by the target. 9601 11.17 MaxOutstandingR2T 9603 Use: LO 9604 Senders: Initiator and Target 9605 Scope: SW 9607 Julian Satran Expires February 2003 220 9608 iSCSI 5-August-02 9610 MaxOutstandingR2T= 9611 Irrelevant when: SessionType=Discovery 9613 Default is 1. 9614 Result function is Minimum. 9616 Initiator and target negotiate the maximum number of outstanding R2Ts 9617 per task, excluding any implied initial R2T that might be part of 9618 that task. An R2T is considered outstanding until the last data PDU 9619 (with the F bit set to 1) is transferred, or a sequence reception 9620 timeout (section 5.14.1) is encountered for that data sequence. 9622 11.18 DataPDUInOrder 9624 Use: LO 9625 Senders: Initiator and Target 9626 Scope: SW 9627 Irrelevant when: SessionType=Discovery 9629 DataPDUInOrder= 9631 Default is Yes. 9632 Result function is OR. 9634 No is used by iSCSI to indicate that the data PDUs within sequences 9635 can be in any order. Yes is used to indicate that data PDUs within 9636 sequences have to be at continuously increasing addresses and over- 9637 lays are forbidden. 9639 11.19 DataSequenceInOrder 9641 Use: LO 9642 Senders: Initiator and Target 9643 Scope: SW 9644 Irrelevant when: SessionType=Discovery 9646 DataSequenceInOrder= 9648 Default is Yes. 9649 Result function is OR. 9651 A Data Sequence is a sequence of Data-In or Data-Out PDUs ending with 9652 a Data-In or Data-Out PDU with the F bit set to one. A Data-out 9654 Julian Satran Expires February 2003 221 9655 iSCSI 5-August-02 9657 sequence is sent either unsolicited or in response to an R2T. 9658 Sequences cover an offset-range. 9660 If DataSequenceInOrder is set to No, Data PDU sequences may be trans- 9661 ferred in any order. 9663 If DataSequenceInOrder is set to Yes, Data Sequences MUST be trans- 9664 ferred using continuously non-decreasing sequence offsets (R2T buffer 9665 offset for writes, or the smallest SCSI Data-In buffer offset within 9666 a read data sequence). 9668 If DataSequenceInOrder is set to Yes, a target may retry at most the 9669 last R2T, and an initiator may at most request retransmission for the 9670 last read data sequence. For this reason if ErrorRecoveryLevel is not 9671 0 and DataSequenceInOrder is set to Yes then MaxOustandingR2T MUST be 9672 set to 1. 9674 11.20 ErrorRecoveryLevel 9676 Use: LO 9677 Senders: Initiator and Target 9678 Scope: SW 9680 ErrorRecoveryLevel= 9682 Default is 0. 9683 Result function is Minimum. 9685 The initiator and target negotiate the recovery level supported. 9687 Recovery levels represent a combination of recovery capabilities. 9688 Each recovery level includes all the capabilities of the lower recov- 9689 ery levels and adds some new ones to them. 9691 In the description of recovery mechanisms, certain recovery classes 9692 are specified. Section 5.15 Error Recovery Hierarchy describes the 9693 mapping between the classes and the levels. 9695 11.21 SessionType 9697 Use: LO, Declarative, Any-Stage 9698 Senders: Initiator 9699 Scope: SW 9701 Julian Satran Expires February 2003 222 9702 iSCSI 5-August-02 9704 SessionType= 9706 Default is Normal. 9708 The Initiator indicates the type of session it wants to create. The 9709 target can either accept it or reject it. 9711 A discovery session indicates to the Target that the only purpose of 9712 this Session is discovery. The only requests a target accepts in this 9713 type of session are a text request with a SendTargets key and a 9714 logout request with reason "close the session". 9716 The discovery session implies MaxConnections = 1 and overrides both 9717 the default and an explicit setting. 9719 11.22 The Private or Public Extension Key Format 9721 Use: ALL 9722 Senders: Initiator and Target 9723 Scope: specific key dependent 9725 X-reversed.vendor.dns_name.do_something= 9727 or 9729 X<#>= 9731 Keys with this format are used for public or private extension pur- 9732 poses. These keys always start with X- if unregistered with IANA 9733 (private) or X# if registered with IANA (public). 9735 For unregistered keys, to identify the vendor, we suggest you use the 9736 reversed DNS-name as a prefix to the key-proper. 9738 The part of key-name following X- and X# MUST conform to the format 9739 for key-name specified in Section 4.1 Text Format. 9741 For IANA registered keys the string following X# must be registered 9742 with IANA and the use of the key MUST be described by an informa- 9743 tional RFC. 9745 Vendor specific keys MUST ONLY be used in normal sessions. 9747 Julian Satran Expires February 2003 223 9748 iSCSI 5-August-02 9750 Support for public or private extension keys is OPTIONAL. 9752 Julian Satran Expires February 2003 224 9753 iSCSI 5-August-02 9755 12. IANA Considerations 9757 The well-known TCP port number for iSCSI connections assigned by IANA 9758 is 3260. A system port must be assigned by IANA when this draft is 9759 approved to become a RFC. 9761 Additional keys, authentication methods or digest types for which a 9762 vendor or group of vendor intend to provide publicly available 9763 descriptions MUST be described by an RFC and MUST be registered with 9764 IANA. 9766 IANA must maintain 3 registries: 9768 a) an iSCSI extended key registry 9769 b) an iSCSI authentication methods registry 9770 c) an iSCSI digests registry 9772 [SEC-IPS] also instructs IANA to maintain a registry for the values 9773 of the SRP_GROUP key. The format of those values must conform to the 9774 one specified for standard-label in Section 4.1 Text Format. 9776 For the iSCSI authentication methods registry and the iSCSI digests 9777 registry IANA MUST also assign a 16 bit unsigned integer number (the 9778 method number for the authentication method and the digest number for 9779 the digest). 9781 The registry for authentication methods will also contain all authen- 9782 tication methods specified in this document as follows: 9784 Authentication Method | Number | 9785 +----------------------------------------+--------+ 9786 | CHAP | 1 | 9787 +----------------------------------------+--------+ 9788 | SRP | 2 | 9789 +----------------------------------------+--------+ 9790 | KRB5 | 3 | 9791 +----------------------------------------+--------+ 9792 | SPKM1 | 4 | 9793 +----------------------------------------+--------+ 9794 | SPKM2 | 5 | 9795 +----------------------------------------+--------+ 9797 Julian Satran Expires February 2003 225 9798 iSCSI 5-August-02 9800 All other record numbers from 0 to 255 are reserved (IANA will regis- 9801 ter numbers above 256. 9803 Authentication methods with numbers above 256 MUST be unique within 9804 the registry and MUST be used with the prefix Y#. 9806 The registry for digest will also contain the digest specified in 9807 this document as follows: 9809 Digest | Number | 9810 +----------------------------------------+--------+ 9811 | CRC32C | 1 | 9812 +----------------------------------------+--------+ 9814 All other record numbers from 0 to 255 are reserved (IANA will regis- 9815 ter numbers above 256. 9817 Digests with numbers above 256 MUST be unique within the registry and 9818 MUST be used with the prefix Z#. 9820 The RFC describing the item to be registered MUST indicate in the 9821 IANA consideration section the string and iSCSI registry it should be 9822 recorded to. 9824 New Keys, Authentication Methods and digests (KADs) must conform to a 9825 number of requirements as described below. 9827 12.1 Naming Requirements 9829 Each KAD must have a unique name in its category. This name will be 9830 used as a standard-label for the key, access method or digest and 9831 must conform to the syntax specified in Section 4.1 Text Format for 9832 standard-labels. 9834 12.2 Mechanism Specification Requirements 9836 For KADs all of the protocols and procedures used by a given KAD must 9837 be described, either in the specification of the KAD itself or in 9838 some other publicly available specification, in sufficient detail for 9839 the KAD to be implemented by any competent implementor. Use of 9840 secret and/or proprietary methods in KADs are expressly prohibited. 9841 The restrictions imposed by RFC 1602 on the standardization of pat- 9842 ented algorithms must be respected as well. 9844 Julian Satran Expires February 2003 226 9845 iSCSI 5-August-02 9847 12.3 Publication Requirements 9849 All KADs must be described by an RFC. The RFC may be informational 9850 rather than standards-track, although standard-track review and 9851 approval are encouraged for all KADs. 9853 12.4 Security Requirements 9855 Any known security issues that arise from the use of the KAD must be 9856 completely and fully described. It is not required that the KAD be 9857 secure or that it be free from risks, but that the known risks be 9858 identified. Publication of a new KAD does not require an exhaustive 9859 security review, and the security considerations section is subject 9860 to continuing evaluation. 9862 Additional security considerations should be addressed by publishing 9863 revised versions of the KAD specification. 9865 For each of those registries IANA must record the registered string. 9866 - which MUST conform to the format rules described in Section 4.1 9867 Text Format for standard-labels and the RFC number that describes it. 9868 The key prefix (X#, Y# or Z#) is not part of the recorded string. 9870 12.5 Registration Procedure 9872 Registration of a new KAD starts with the construction of a draft of 9873 an RFC. 9875 12.5.1 Present the KAD to the Community 9877 Send a proposed access type specification to the IPS WG mailing list 9878 or if the IPS WG is disbanded at the registration time to the TSWG 9879 mailing list for a review period of a month. The intent of the pub- 9880 lic posting is to solicit comments and feedback on the KAD specifica- 9881 tion and a review of any security considerations. 9883 12.5.2 KAD review and IESG approval 9885 When the one month period has passed, the IPS WG chair or a person 9886 nominated by the IETF Transport Area Director (the KAD reviewer) 9887 either forwards the draft to the IESG for publication as an informa- 9888 tional RFC or rejects it. If the specification is a standards track 9889 draft the usual IETF procedures for such documents are followed. 9891 Julian Satran Expires February 2003 227 9892 iSCSI 5-August-02 9894 Decisions made by the KAD reviewer must be published within 2 weeks 9895 after the month-long review period. Decision made by the KAD reviewer 9896 can be appealed through the IESG appeal process. 9898 12.5.3 IANA Registration 9900 Provided that the KAD has either passed review or has been success- 9901 fully appealed to the IESG, and the specification is published as an 9902 RFC then IANA will register the KAD make the registration available 9903 to the community. 9905 12.5.4 Location of Registered KAD List 9907 KAD registrations will be posted in the anonymous FTP directory 9908 "ftp://ftp.isi.edu/in-notes/iana/assignments/ips/kads" and all regis- 9909 tered KADS will be listed in the periodically issued "Assigned Num- 9910 bers" RFC [currently RFC-1700]. 9912 12.6 IANA Procedures for Registering KADs 9914 The identity of the KAD reviewer is communicated to the IANA by the 9915 IESG. The IANA then only acts in response to KAD definitions that 9916 either are approved by the KAD reviewer and forwarded by the reviewer 9917 to the IANA for registration, or in response to a communication from 9918 the IESG that a KAD definition appeal has overturned the KAD 9919 reviewer's ruling. 9921 Julian Satran Expires February 2003 228 9922 iSCSI 5-August-02 9924 References and Bibliography 9926 Normative References 9928 [AESCBC] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher 9929 Algorithm and Its Use with IPsec", draft-ietf-ipsec-ciph-aes- 9930 cbc-03.txt, November 2001 (Work In Progress). 9931 [AESCTR] draft-ietf-ipsec-ciph-aes-ctr-00.txt R. Housley 23- 9932 Jul-02 (Work In Progress). 9933 [CAM] ANSI X3.232-199X, Common Access Method-3. 9934 [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)", 9935 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 9936 [OUI] "IEEE OUI and Company_Id Assignments", http://stan- 9937 dards.ieee.org/regauth/oui/index.shtml 9938 [RFC790] J. Postel, ASSIGNED NUMBERS, September 1981. 9939 [RFC791] INTERNET PROTOCOL, DARPA INTERNET PROGRAM PROTOCOL 9940 SPECIFICATION, September 1981. 9941 [RFC793] TRANSMISSION CONTROL PROTOCOL, DARPA INTERNET PROGRAM 9942 PROTOCOL SPECIFICATION, September 1981. 9943 [RFC1035] P. Mockapetris, DOMAIN NAMES - IMPLEMENTATION AND 9944 SPECIFICATION, November 1987. 9945 [RFC1122] Requirements for Internet Hosts-Communication Layer 9946 RFC1122, R. Braden (editor). 9947 [RFC1510] J. Kohl, C. Neuman, "The Kerberos Network Authentica- 9948 tion Service (V5)", September 1993. 9949 [RFC1737] K. Sollins, L. Masinter "Functional Requirements for 9950 Uniform Resource Names". 9951 [RFC1766] H. Alvestrand, "Tags for the Identification of Lan- 9952 guages", March 1995. 9953 [RFC1964] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", 9954 June 1996. 9955 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", RFC 9956 1982, August 1996. 9957 [RFC1994] "W. Simpson, PPP Challenge Handshake Authentication 9958 Protocol (CHAP)", RFC 1994, August 1996. 9959 [RFC2025] C. Adams, "The Simple Public-Key GSS-API Mechanism 9960 (SPKM)", October 1996. 9961 [RFC2026] Bradner, S., "The Internet Standards Process -- Revi- 9962 sion 3", RFC 2026, October 1996. 9963 [RFC2044] Yergeau, F., "UTF-8, a Transformation Format of Uni- 9964 code and ISO 10646", October 1996. 9965 [RFC2045] N. Borenstein, N. Freed, "MIME (Multipurpose Inter- 9966 net Mail Extensions) Part One: Mechanisms for Specifying and 9967 Describing the Format of Internet Message Bodies", November 9968 1996. 9969 [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 9970 Requirement Levels", BCP 14, RFC 2119, March 1997. 9971 [RFC2234] D. Crocker, P. Overell Augmented BNF for Syntax Spec- 9972 ifications: ABNF. 9974 Julian Satran Expires February 2003 229 9975 iSCSI 5-August-02 9977 [RFC2246] T. Dierks, C. Allen, " The TLS Protocol Version 1.0. 9978 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 9979 Architecture", RFC 2373, July 1998. 9980 [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter "Uniform 9981 Resource Identifiers". 9982 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 9983 Internet Protocol", RFC 2401, November 1998. 9984 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 9985 and AH", RFC 2404, November 1998. 9986 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 9987 (ESP)", RFC 2406, November 1998. 9988 [RFC2407] D. Piper, "The Internet IP Security Domain of Interpre- 9989 tation of ISAKMP", RFC 2407, November 1998. 9990 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange 9991 (IKE)", RFC 2409, November 1998. 9992 [RFC2434] T. Narten, and H. Avestrand, "Guidelines for Writing 9993 an IANA Considerations Section in RFCs.", RFC2434, October 9994 1998. 9995 [RFC2451] R. Pereira, R. Adams " The ESP CBC-Mode Cipher Algo- 9996 rithms". 9997 [RFC2732] R. Hinden, B. Carpenter, L. Masinter, "Format for 9998 Literal IPv6 Addresses in URL's", RFC 2732, December 1999. 9999 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange Sys- 10000 tem", September 2000. 10001 [SAM] ANSI X3.270-1998, SCSI-3 Architecture Model (SAM). 10002 [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2). 10003 [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC). 10004 [SEQ-EXT] Kent, S., "IP Encapsulating Security Payload (ESP)", 10005 Internet draft (work in progress), draft-ietf-ipsec-esp-v3- 10006 01.txt, November 2002. 10007 [SEC-IPS] B. Aboba & team "Securing Block Storage Protocols 10008 over IP", Internet draft (work in progress), draft-ietf-ips- 10009 security-09.txt, February 2002. 10010 [SPC]T10/1416-D, SCSI-3 Primary Commands. 10011 [SPC3]T10/1416-D, SCSI Primary Commands-3. 10012 [STPREP] P. Hoffman, M. Blanchet, "Preparation of Internation- 10013 alized Strings", draft-hoffman-stringprep-00.txt, September, 10014 2001 (Work In Progress). 10015 [STPREP-iSCSI] M. Bakke, "String Profile for iSCSI Names", 10016 draft-ietf-ips-iscsi-string-prep-00.txt, November 2001 (Work 10017 In Progress). 10018 [UNICODE] Unicode Standard Annex #15, "Unicode Normalization 10019 Forms", http://www.unicode.org/unicode/reports/15 10021 Informative References: 10023 Julian Satran Expires February 2003 230 10024 iSCSI 5-August-02 10026 [BOOT] P. Sarkar & team draft-ietf-ips-iscsi-boot-03.txt (Work 10027 In Progress). 10028 [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman "Opti- 10029 mization of Cyclic Redundancy-Check Codes with 24 and 32 Par- 10030 ity Bits", IEEE Transact. on Communications, Vol. 41, No. 6, 10031 June 1993. 10032 [CRC] ISO 3309, High-Level Data Link Control (CRC 32). 10033 [iSCSI-CRC] D. Sheinwald & team, draft-sheinwald-icsci-crc- 10034 02.txt (Work In Progress). 10035 [iSCSI-REQ] M. Krueger & team, RFC3347 Small Computer Systems 10036 Interface protocol over the Internet (iSCSI) Requirements and 10037 Design Considerations 10038 [NDT] M. Bakke & team, draft-ietf-ips-iscsi-name-disc-05.txt 10039 (Work In Progress) 10040 [RFC1602] IAB and IESG, The Internet Standards Process -- Revi- 10041 sion 2 10042 [Schneier] B. Schneier, "Applied Cryptography: Protocols, Algo- 10043 rithms, and Source Code in C", 2nd edition, John Wiley & 10044 Sons, New York, NY, 1996. 10046 Authors' Addresses 10048 Julian Satran 10049 IBM, Haifa Research Lab 10050 Haifa University Campus - Mount Carmel 10051 Haifa 31905, Israel 10052 Phone +972.4.829.6264 10053 E-mail: Julian_Satran@il.ibm.com 10055 Kalman Meth 10056 Haifa University Campus - Mount Carmel 10057 MATAM - Advanced Technology Center 10058 Haifa 31905, Israel 10059 Phone +972.4.829.6341 10060 E-mail: meth@il.ibm.com 10062 Costa Sapuntzakis 10063 Cisco Systems, Inc. 10064 170 W. Tasman Drive 10065 San Jose, CA 95134, USA 10066 Phone: +1.408.525.5497 10067 E-mail: csapuntz@cisco.com 10069 Efri Zeidner 10070 SANgate Systems, Inc. 10071 41 Hameyasdim Street 10072 P.O.B. 1486 10073 Even-Yehuda, Israel 40500 10074 Phone: +972.9.891.9555 10076 Julian Satran Expires February 2003 231 10077 iSCSI 5-August-02 10079 E-mail: efri@sangate.com 10081 Mallikarjun Chadalapaka 10082 Hewlett-Packard Company 10083 8000 Foothills Blvd. 10084 Roseville, CA 95747-5668, USA 10085 Phone: +1.916.785.5621 10086 E-mail: cbm@rose.hp.com 10088 Comments may be sent to Julian Satran 10090 Julian Satran Expires February 2003 232 10091 iSCSI 5-August-02 10093 Appendix A. Sync and Steering with Fixed Interval Markers 10095 This appendix presents a simple scheme for synchronization (PDU 10096 boundary retrieval). It uses markers that include synchronization 10097 information placed at fixed intervals in the TCP stream. 10099 A Marker consists of: 10101 Byte / 0 | 1 | 2 | 3 | 10102 / | | | | 10103 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 10104 +---------------+---------------+---------------+---------------+ 10105 0| Next-iSCSI-PDU-start pointer - copy #1 | 10106 +---------------+---------------+---------------+---------------+ 10107 4| Next-iSCSI-PDU-start pointer - copy #2 | 10108 +---------------+---------------+---------------+---------------+ 10110 The Marker scheme uses payload byte stream counting that includes 10111 every byte placed by iSCSI in the TCP stream except for the markers 10112 themselves. It also excludes any bytes that TCP counts but are not 10113 originated by iSCSI. 10115 The Marker indicates the offset to the next iSCSI PDU header. The 10116 Marker is eight bytes in length and contains two 32-bit offset fields 10117 that indicate how many bytes to skip in the TCP stream in order to 10118 find the next iSCSI PDU header. The marker uses two copies of the 10119 pointer so that a marker that spans a TCP packet boundary should 10120 leave at least one valid copy in one of the packets. 10122 The inserted value is independent of the marker interval. 10124 The use of markers is negotiable. The initiator and target MAY indi- 10125 cate their readiness to receive and/or send markers during login sep- 10126 arately for each connection. The default is No. 10128 A.1 Markers At Fixed Intervals 10130 A marker is inserted at fixed intervals in the TCP byte stream. Dur- 10131 ing login, each end of the iSCSI session specifies the interval at 10132 which it is willing to receive the marker, or it disables the marker 10133 altogether. If a receiver indicates that it desires a marker, the 10134 sender MAY agree (during negotiation) and provide the marker at the 10135 desired interval. However, in certain environments, a sender not pro- 10137 Julian Satran Expires February 2003 233 10138 iSCSI 5-August-02 10140 viding markers to a receiver wanting markers may suffer an apprecia- 10141 ble performance degradation. 10143 The marker interval and the initial marker-less interval are counted 10144 in terms of the bytes placed in the TCP stream data by iSCSI. 10146 When reduced to iSCSI terms, markers MUST indicate the offset to a 4- 10147 byte word boundary in the stream. The least significant two bits of 10148 each marker word are reserved and are considered 0 for offset compu- 10149 tation. 10151 Padding iSCSI PDU payloads to 4-byte word boundaries simplifies 10152 marker manipulation. 10154 A.2 Initial Marker-less Interval 10156 To enable the connection setup including the Login Phase negotia- 10157 tion, marking (if any) is started only at the first marker interval 10158 after the end of the Login Phase. However, in order to enable the 10159 marker inclusion and exclusion mechanism to work without knowledge of 10160 the length of the Login Phase, the first marker will be placed in the 10161 TCP stream as if the Marker-less interval had included markers. 10163 Thus all markers appear in the stream at locations conforming to the 10164 formula: [(MI + 8) * n - 8] where MI = Marker Interval, n = integer 10165 number. 10167 As an example if the marker interval is 512 bytes and the login ended 10168 at byte 1003 (first iSCSI placed byte is 0) the first marker will be 10169 inserted after byte 1031 in the stream. 10171 A.3 Negotiation 10173 The following operational key=value pairs are used to negotiate the 10174 fixed interval markers. The direction (output or input) is relative 10175 to the initiator. 10177 A.3.1 OFMarker, IFMarker 10179 Use: IO 10180 Senders: Initiator and Target 10181 Scope: CO 10183 OFMarker= 10185 Julian Satran Expires February 2003 234 10186 iSCSI 5-August-02 10188 IFMarker= 10190 Default is No. 10192 Result function is AND. 10194 OFMarker is used to turn on or off the initiator to target markers on 10195 the connection. IFMarker is used to turn on or off the target to 10196 initiator markers on the connection. 10198 Examples: 10200 I->OFMarker=Yes,IFMarker=Yes 10201 T->OFMarker=Yes,IFMarker=Yes 10203 Results in the Marker being used in both directions while 10205 I->OFMarker=Yes,IFMarker=Yes 10206 T->OFMarker=Yes,IFMarker=No 10208 Results in Marker being used from the initiator to the target, but 10209 not from the target to initiator. 10211 A.3.2 OFMarkInt, IFMarkInt 10213 Use: IO 10214 Senders: Initiator and Target 10215 Scope: CO 10216 OFMarkInt is Irrelevant when: OFMarker=No 10217 IFMarkInt is Irrelevant when: IFMarker=No 10219 Offering: 10221 OFMarkInt= 10222 IFMarkInt= 10224 Responding: 10226 OFMarkInt=|Reject 10227 IFMarkInt=|Reject 10229 OFMarkInt is used to set the interval for the initiator to target 10230 markers on the connection. IFMarkInt is used to set the interval for 10231 the target to initiator markers on the connection. 10233 Julian Satran Expires February 2003 235 10234 iSCSI 5-August-02 10236 For the offering the initiator or target indicates the minimum to 10237 maximum interval (in 4-byte words) it wants the markers for one or 10238 both directions. In case it only wants a specific value, only a sin- 10239 gle value has to be specified. The responder selects a value within 10240 the minimum and maximum offered or the only value offered or indi- 10241 cates through the xFMarker key=value its inability to set and/or 10242 receive markers. When the interval is unacceptable the responder 10243 answers with "Reject". Reject is resetting the marker function in 10244 the specified direction (Output or Input) to No. 10246 The interval is measured from the end of a marker to the beginning of 10247 the next marker. For example, a value of 1024 means 1024 words (4096 10248 bytes of iSCSI payload between markers). 10250 The default is 2048. 10252 Julian Satran Expires February 2003 236 10253 iSCSI 5-August-02 10255 Appendix B. Examples 10257 B.1 Read Operation Example 10259 +------------------+-----------------------+----------------------+ 10260 |Initiator Function| PDU Type | Target Function | 10261 +------------------+-----------------------+----------------------+ 10262 | Command request |SCSI Command (READ)>>> | | 10263 | (read) | | | 10264 +------------------+-----------------------+----------------------+ 10265 | | |Prepare Data Transfer | 10266 +------------------+-----------------------+----------------------+ 10267 | Receive Data | <<< SCSI Data-in | Send Data | 10268 +------------------+-----------------------+----------------------+ 10269 | Receive Data | <<< SCSI Data-in | Send Data | 10270 +------------------+-----------------------+----------------------+ 10271 | Receive Data | <<< SCSI Data-in | Send Data | 10272 +------------------+-----------------------+----------------------+ 10273 | | <<< SCSI Response |Send Status and Sense | 10274 +------------------+-----------------------+----------------------+ 10275 | Command Complete | | | 10276 +------------------+-----------------------+----------------------+ 10278 Julian Satran Expires February 2003 237 10279 iSCSI 5-August-02 10281 B.2 Write Operation Example 10283 +------------------+-----------------------+---------------------+ 10284 |Initiator Function| PDU Type | Target Function | 10285 +------------------+-----------------------+---------------------+ 10286 | Command request |SCSI Command (WRITE)>>>| Receive command | 10287 | (write) | | and queue it | 10288 +------------------+-----------------------+---------------------+ 10289 | | | Process old commands| 10290 +------------------+-----------------------+---------------------+ 10291 | | | Ready to process | 10292 | | <<< R2T | WRITE command | 10293 +------------------+-----------------------+---------------------+ 10294 | Send Data | SCSI Data-out >>> | Receive Data | 10295 +------------------+-----------------------+---------------------+ 10296 | | <<< R2T | Ready for data | 10297 +------------------+-----------------------+---------------------+ 10298 | | <<< R2T | Ready for data | 10299 +------------------+-----------------------+---------------------+ 10300 | Send Data | SCSI Data-out >>> | Receive Data | 10301 +------------------+-----------------------+---------------------+ 10302 | Send Data | SCSI Data-out >>> | Receive Data | 10303 +------------------+-----------------------+---------------------+ 10304 | | <<< SCSI Response |Send Status and Sense| 10305 +------------------+-----------------------+---------------------+ 10306 | Command Complete | | | 10307 +------------------+-----------------------+---------------------+ 10309 B.3 R2TSN/DataSN use Examples 10311 Output (write) data DataSN/R2TSN Example 10313 Julian Satran Expires February 2003 238 10314 iSCSI 5-August-02 10316 +------------------+-----------------------+----------------------+ 10317 |Initiator Function| PDU Type & Content | Target Function | 10318 +------------------+-----------------------+----------------------+ 10319 | Command request |SCSI Command (WRITE)>>>| Receive command | 10320 | (write) | | and queue it | 10321 +------------------+-----------------------+----------------------+ 10322 | | | Process old commands | 10323 +------------------+-----------------------+----------------------+ 10324 | | <<< R2T | Ready for data | 10325 | | R2TSN = 0 | | 10326 +------------------+-----------------------+----------------------+ 10327 | | <<< R2T | Ready for more data | 10328 | | R2TSN = 1 | | 10329 +------------------+-----------------------+----------------------+ 10330 | Send Data | SCSI Data-out >>> | Receive Data | 10331 | for R2TSN 0 | DataSN = 0, F=0 | | 10332 +------------------+-----------------------+----------------------+ 10333 | Send Data | SCSI Data-out >>> | Receive Data | 10334 | for R2TSN 0 | DataSN = 1, F=1 | | 10335 +------------------+-----------------------+----------------------+ 10336 | Send Data | SCSI Data >>> | Receive Data | 10337 | for R2TSN 1 | DataSN = 0, F=1 | | 10338 +------------------+-----------------------+----------------------+ 10339 | | <<< SCSI Response |Send Status and Sense | 10340 | | ExpDataSN = 0 | | 10341 +------------------+-----------------------+----------------------+ 10342 | Command Complete | | | 10343 +------------------+-----------------------+----------------------+ 10345 Input (read) data DataSN Example 10347 Julian Satran Expires February 2003 239 10348 iSCSI 5-August-02 10350 +------------------+-----------------------+----------------------+ 10351 |Initiator Function| PDU Type | Target Function | 10352 +------------------+-----------------------+----------------------+ 10353 | Command request |SCSI Command (READ)>>> | | 10354 | (read) | | | 10355 +------------------+-----------------------+----------------------+ 10356 | | | Prepare Data Transfer| 10357 +------------------+-----------------------+----------------------+ 10358 | Receive Data | <<< SCSI Data-in | Send Data | 10359 | | DataSN = 0, F=0 | | 10360 +------------------+-----------------------+----------------------+ 10361 | Receive Data | <<< SCSI Data-in | Send Data | 10362 | | DataSN = 1, F=0 | | 10363 +------------------+-----------------------+----------------------+ 10364 | Receive Data | <<< SCSI Data-in | Send Data | 10365 | | DataSN = 2, F=1 | | 10366 +------------------+-----------------------+----------------------+ 10367 | | <<< SCSI Response |Send Status and Sense | 10368 | | ExpDataSN = 3 | | 10369 +------------------+-----------------------+----------------------+ 10370 | Command Complete | | | 10371 +------------------+-----------------------+----------------------+ 10373 Bidirectional DataSN Example 10375 Julian Satran Expires February 2003 240 10376 iSCSI 5-August-02 10378 +------------------+-----------------------+----------------------+ 10379 |Initiator Function| PDU Type | Target Function | 10380 +------------------+-----------------------+----------------------+ 10381 | Command request |SCSI Command >>> | | 10382 | (Read-Write) | Read-Write | | 10383 +------------------+-----------------------+----------------------+ 10384 | | | Process old commands | 10385 +------------------+-----------------------+----------------------+ 10386 | | <<< R2T | Ready to process | 10387 | | R2TSN = 0 | WRITE command | 10388 +------------------+-----------------------+----------------------+ 10389 | * Receive Data | <<< SCSI Data-in | Send Data | 10390 | | DataSN = 0, F=0 | | 10391 +------------------+-----------------------+----------------------+ 10392 | * Receive Data | <<< SCSI Data-in | Send Data | 10393 | | DataSN = 1, F=1 | | 10394 +------------------+-----------------------+----------------------+ 10395 | * Send Data | SCSI Data-out >>> | Receive Data | 10396 | for R2TSN 0 | DataSN = 0, F=1 | | 10397 +------------------+-----------------------+----------------------+ 10398 | | <<< SCSI Response |Send Status and Sense | 10399 | | ExpDataSN = 2 | | 10400 +------------------+-----------------------+----------------------+ 10401 | Command Complete | | | 10402 +------------------+-----------------------+----------------------+ 10404 *) Send data and Receive Data may be transferred simultaneously as in 10405 an atomic Read-Old-Write-New or sequential as in an atomic Read- 10406 Update-Write (in the alter case the R2T may follow the received 10407 data). 10409 Unsolicited and immediate output (write) data with DataSN Example 10411 Julian Satran Expires February 2003 241 10412 iSCSI 5-August-02 10414 +------------------+-----------------------+----------------------+ 10415 |Initiator Function| PDU Type & Content | Target Function | 10416 +------------------+-----------------------+----------------------+ 10417 | Command request |SCSI Command (WRITE)>>>| Receive command | 10418 | (write) |F=0 | and data | 10419 |+ immediate data | | and queue it | 10420 +------------------+-----------------------+----------------------+ 10421 | Send Unsolicited | SCSI Write Data >>> | Receive more Data | 10422 | Data | DataSN = 0, F=1 | | 10423 +------------------+-----------------------+----------------------+ 10424 | | | Process old commands | 10425 +------------------+-----------------------+----------------------+ 10426 | | <<< R2T | Ready for more data | 10427 | | R2TSN = 0 | | 10428 +------------------+-----------------------+----------------------+ 10429 | Send Data | SCSI Write Data >>> | Receive Data | 10430 | for R2TSN 0 | DataSN = 0, F=1 | | 10431 +------------------+-----------------------+----------------------+ 10432 | | <<< SCSI Response |Send Status and Sense | 10433 | | | | 10434 +------------------+-----------------------+----------------------+ 10435 | Command Complete | | | 10436 +------------------+-----------------------+----------------------+ 10438 B.4 CRC Examples 10440 N.B. all Values are Hexadecimal 10442 32 bytes of zeroes: 10444 Byte: 0 1 2 3 10446 0: 00 00 00 00 10447 ... 10448 28: 00 00 00 00 10450 CRC: aa 36 91 8a 10452 32 bytes of ones: 10454 Byte: 0 1 2 3 10456 0: ff ff ff ff 10458 Julian Satran Expires February 2003 242 10459 iSCSI 5-August-02 10461 ... 10462 28: ff ff ff ff 10464 CRC: 43 ab a8 62 10466 32 bytes of incrementing 00..1f: 10468 Byte: 0 1 2 3 10470 0: 00 01 02 03 10471 ... 10472 28: 1c 1d 1e 1f 10474 CRC: 4e 79 dd 46 10476 32 bytes of decrementing 1f..00: 10478 Byte: 0 1 2 3 10480 0: 1f 1e 1d 1c 10481 ... 10482 28: 03 02 01 00 10484 CRC: 5c db 3f 11 10486 Julian Satran Expires February 2003 243 10487 iSCSI 5-August-02 10489 Appendix C. Login Phase Examples 10491 In the first example, the initiator and target authenticate each 10492 other via Kerberos: 10494 I-> Login (CSG,NSG=0,1 T=1) 10495 InitiatorName=iqn.1999-07.com.os:hostid.77 10496 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10497 AuthMethod=KRB5,SRP,None 10499 T-> Login (CSG,NSG=0,0 T=0) 10500 AuthMethod=KRB5 10502 I-> Login (CSG,NSG=0,1 T=1) 10503 KRB_AP_REQ= 10505 (krb_ap_req contains the Kerberos V5 ticket and authenticator 10506 with MUTUAL-REQUIRED set in the ap-options field) 10508 If the authentication is successful, the target proceeds with: 10510 T-> Login (CSG,NSG=0,1 T=1) 10511 KRB_AP_REP= 10513 (krb_ap_rep is the Kerberos V5 mutual authentication reply) 10515 If the authentication is successful, the initiator may proceed 10516 with: 10518 I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192 10519 T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096 MaxBurst- 10520 Length=8192 10521 I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192 10522 ... more iSCSI Operational Parameters 10524 T-> Login (CSG,NSG=1,0 T=0) 10525 ... more iSCSI Operational Parameters 10527 And at the end: 10529 I-> Login (CSG,NSG=1,3 T=1) 10530 optional iSCSI parameters 10532 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10534 If the initiator's authentication by the target is not success- 10535 ful, the target responds with: 10537 Julian Satran Expires February 2003 244 10538 iSCSI 5-August-02 10540 T-> Login "login reject" 10542 instead of the Login KRB_AP_REP message, and terminates the 10543 connection. 10545 If the target's authentication by the initiator is not success- 10546 ful, the initiator terminates the connection (without 10547 responding to the Login KRB_AP_REP message). 10549 In the next example only the initiator is authenticated by the tar- 10550 get via Kerberos: 10552 I-> Login (CSG,NSG=0,1 T=1) 10553 InitiatorName=iqn.1999-07.com.os:hostid.77 10554 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10555 AuthMethod=SRP,KRB5,None 10557 T-> Login-PR (CSG,NSG=0,0 T=0) 10558 AuthMethod=KRB5 10560 I-> Login (CSG,NSG=0,1 T=1) 10561 KRB_AP_REQ=krb_ap_req 10563 (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req) 10565 If the authentication is successful, the target proceeds with: 10567 T-> Login (CSG,NSG=0,1 T=1) 10569 I-> Login (CSG,NSG=1,0 T=0) 10570 ... iSCSI parameters 10572 T-> Login (CSG,NSG=1,0 T=0) 10573 ... iSCSI parameters 10575 . . . 10577 T-> Login (CSG,NSG=1,3 T=1)"login accept" 10579 In the next example, the initiator and target authenticate each other 10580 via SPKM1: 10582 I-> Login (CSG,NSG=0,1 T=1) 10583 InitiatorName=iqn.1999-07.com.os:hostid.77 10584 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10585 AuthMethod=SPKM1,KRB5,None 10587 T-> Login (CSG,NSG=0,0 T=0) 10589 Julian Satran Expires February 2003 245 10590 iSCSI 5-August-02 10592 AuthMethod=SPKM1 10594 I-> Login (CSG,NSG=0,0 T=0) 10595 SPKM_REQ= 10597 (spkm-req is the SPKM-REQ token with the mutual-state bit in 10598 the options field of the REQ-TOKEN set) 10600 T-> Login (CSG,NSG=0,0 T=0) 10601 SPKM_REP_TI= 10603 If the authentication is successful, the initiator proceeds: 10605 I-> Login (CSG,NSG=0,1 T=1) 10606 SPKM_REP_IT= 10608 If the authentication is successful, the target proceeds with: 10610 T-> Login (CSG,NSG=0,1 T=1) 10612 The initiator may proceed: 10614 I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters 10615 T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters 10617 And at the end: 10619 I-> Login (CSG,NSG=1,3 T=1) 10620 optional iSCSI parameters 10622 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10624 If the target's authentication by the initiator is not success- 10625 ful, the initiator terminates the connection (without 10626 responding to the Login SPKM_REP_TI message). 10628 If the initiator's authentication by the target is not success- 10629 ful, the target responds with: 10631 T-> Login "login reject" 10633 instead of the Login "proceed and change stage" message, and 10634 terminates the connection. 10636 In the next example, the initiator and target authenticate each other 10637 via SPKM2: 10639 Julian Satran Expires February 2003 246 10640 iSCSI 5-August-02 10642 I-> Login (CSG,NSG=0,0 T=0) 10643 InitiatorName=iqn.1999-07.com.os:hostid.77 10644 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10645 AuthMethod=SPKM1,SPKM2 10647 T-> Login-PR (CSG,NSG=0,0 T=0) 10648 AuthMethod=SPKM2 10650 I-> Login (CSG,NSG=0,1 T=1) 10651 SPKM_REQ= 10653 (spkm-req is the SPKM-REQ token with the mutual-state bit in 10654 the options field of the REQ-TOKEN not set) 10656 If the authentication is successful, the target proceeds with: 10658 T-> Login (CSG,NSG=0,1 T=1) 10660 The initiator may proceed: 10662 I-> Login (CSG,NSG=1,0 T=0) 10663 ... iSCSI parameters 10665 T-> Login (CSG,NSG=1,0 T=0) 10666 ... iSCSI parameters 10668 And at the end: 10670 I-> Login (CSG,NSG=1,3 T=1) 10671 optional iSCSI parameters 10673 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10675 In the next example, the initiator and target authenticate each other 10676 via SRP: 10678 I-> Login (CSG,NSG=0,1 T=1) 10679 InitiatorName=iqn.1999-07.com.os:hostid.77 10680 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10681 AuthMethod=KRB5,SRP,None 10683 T-> Login-PR (CSG,NSG=0,0 T=0) 10684 AuthMethod=SRP 10686 I-> Login (CSG,NSG=0,0 T=0) 10687 SRP_U= 10688 TargetAuth=Yes 10690 Julian Satran Expires February 2003 247 10691 iSCSI 5-August-02 10693 T-> Login (CSG,NSG=0,0 T=0) 10694 SRP_N= 10695 SRP_g= 10696 SRP_s= 10698 I-> Login (CSG,NSG=0,0 T=0) 10699 SRP_A= 10701 T-> Login (CSG,NSG=0,0 T=0) 10702 SRP_B= 10704 I-> Login (CSG,NSG=0,1 T=1) 10705 SRP_M= 10707 If the initiator authentication is successful, the target pro- 10708 ceeds: 10710 T-> Login (CSG,NSG=0,1 T=1) 10711 SRP_HM= 10713 Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]. 10715 If the target authentication is not successful, the initiator 10716 terminates the connection; otherwise, it proceeds. 10718 I-> Login (CSG,NSG=1,0 T=0) 10719 ... iSCSI parameters 10721 T-> Login (CSG,NSG=1,0 T=0) 10722 ... iSCSI parameters 10724 And at the end: 10726 I-> Login (CSG,NSG=1,3 T=1) 10727 optional iSCSI parameters 10729 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10731 If the initiator authentication is not successful, the target 10732 responds with: 10734 T-> Login "login reject" 10736 Instead of the T-> Login SRP_HM= message and 10737 terminates the connection. 10739 In the next example, only the initiator is authenticated by the tar- 10740 get via SRP: 10742 Julian Satran Expires February 2003 248 10743 iSCSI 5-August-02 10745 I-> Login (CSG,NSG=0,1 T=1) 10746 InitiatorName=iqn.1999-07.com.os:hostid.77 10747 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10748 AuthMethod=KRB5,SRP,None 10750 T-> Login-PR (CSG,NSG=0,0 T=0) 10751 AuthMethod=SRP 10753 I-> Login (CSG,NSG=0,0 T=0) 10754 SRP_U= 10755 TargetAuth=No 10757 T-> Login (CSG,NSG=0,0 T=0) 10758 SRP_N= 10759 SRP_g= 10760 SRP_s= 10762 I-> Login (CSG,NSG=0,0 T=0) 10763 SRP_A= 10765 T-> Login (CSG,NSG=0,0 T=0) 10766 SRP_B= 10768 I-> Login (CSG,NSG=0,1 T=1) 10769 SRP_M= 10771 If the initiator authentication is successful, the target pro- 10772 ceeds: 10774 T-> Login (CSG,NSG=0,1 T=1) 10776 I-> Login (CSG,NSG=1,0 T=0) 10777 ... iSCSI parameters 10779 T-> Login (CSG,NSG=1,0 T=0) 10780 ... iSCSI parameters 10782 And at the end: 10784 I-> Login (CSG,NSG=1,3 T=1) 10785 optional iSCSI parameters 10787 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10789 In the next example the initiator and target authenticate each other 10790 via CHAP: 10792 I-> Login (CSG,NSG=0,0 T=0) 10794 Julian Satran Expires February 2003 249 10795 iSCSI 5-August-02 10797 InitiatorName=iqn.1999-07.com.os:hostid.77 10798 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10799 AuthMethod=KRB5,CHAP,None 10801 T-> Login-PR (CSG,NSG=0,0 T=0) 10802 AuthMethod=CHAP 10804 I-> Login (CSG,NSG=0,0 T=0) 10805 CHAP_A= 10807 T-> Login (CSG,NSG=0,0 T=0) 10808 CHAP_A= 10809 CHAP_I= 10810 CHAP_C= 10812 I-> Login (CSG,NSG=0,1 T=1) 10813 CHAP_N= 10814 CHAP_R= 10815 CHAP_I= 10816 CHAP_C= 10818 If the initiator authentication is successful, the target pro- 10819 ceeds: 10821 T-> Login (CSG,NSG=0,1 T=1) 10822 CHAP_N= 10823 CHAP_R= 10825 If the target authentication is not successful, the initiator 10826 aborts the connection; otherwise, it proceeds. 10828 I-> Login (CSG,NSG=1,0 T=0) 10829 ... iSCSI parameters 10830 T-> Login (CSG,NSG=1,0 T=0) 10831 ... iSCSI parameters 10833 And at the end: 10835 I-> Login (CSG,NSG=1,3 T=1) 10836 optional iSCSI parameters 10838 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10840 If the initiator authentication is not successful, the target 10841 responds with: 10843 T-> Login "login reject" 10845 Julian Satran Expires February 2003 250 10846 iSCSI 5-August-02 10848 Instead of the Login CHAP_R= "proceed and change 10849 stage" 10850 message and terminates the connection. 10852 In the next example, only the initiator is authenticated by the tar- 10853 get via CHAP: 10855 I-> Login (CSG,NSG=0,1 T=0) 10856 InitiatorName=iqn.1999-07.com.os:hostid.77 10857 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10858 AuthMethod=KRB5,CHAP,None 10860 T-> Login-PR (CSG,NSG=0,0 T=0) 10861 AuthMethod=CHAP 10863 I-> Login (CSG,NSG=0,0 T=0) 10864 CHAP_A= 10866 T-> Login (CSG,NSG=0,0 T=0) 10867 CHAP_A= 10868 CHAP_I= 10869 CHAP_C= 10871 I-> Login (CSG,NSG=0,1 T=1) 10872 CHAP_N= 10873 CHAP_R= 10875 If the initiator authentication is successful, the target pro- 10876 ceeds: 10878 T-> Login (CSG,NSG=0,1 T=1) 10880 I-> Login (CSG,NSG=1,0 T=0) 10881 ... iSCSI parameters 10883 T-> Login (CSG,NSG=1,0 T=0) 10884 ... iSCSI parameters 10886 And at the end: 10888 I-> Login (CSG,NSG=1,3 T=1) 10889 optional iSCSI parameters 10891 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10893 Julian Satran Expires February 2003 251 10894 iSCSI 5-August-02 10896 In the next example, the initiator does not offer any security param- 10897 eters. It therefore may offer iSCSI parameters on the Login PDU with 10898 the T bit set to 1, and the target may respond with a final Login 10899 Response PDU immediately: 10901 I-> Login (CSG,NSG=1,3 T=1) 10902 InitiatorName=iqn.1999-07.com.os:hostid.77 10903 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10904 ... iSCSI parameters 10906 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10907 ... ISCSI parameters 10909 In the next example, the initiator does offer security parame- 10910 ters on the Login PDU, but the target does not choose any 10911 (i.e., chooses the "None" values): 10913 I-> Login (CSG,NSG=0,1 T=1) 10914 InitiatorName=iqn.1999-07.com.os:hostid.77 10915 TargetName=iqn.1999-07.com.acme:diskarray.sn.88 10916 AuthMethod=KRB5,SRP,None 10918 T-> Login-PR (CSG,NSG=0,1 T=1) 10919 AuthMethod=None 10921 I-> Login (CSG,NSG=1,0 T=0) 10922 ... iSCSI parameters 10924 T-> Login (CSG,NSG=1,0 T=0) 10925 ... iSCSI parameters 10927 And at the end: 10929 I-> Login (CSG,NSG=1,3 T=1) 10930 optional iSCSI parameters 10932 T-> Login (CSG,NSG=1,3 T=1) "login accept" 10934 Julian Satran Expires February 2003 252 10935 iSCSI 5-August-02 10937 Appendix D. SendTargets Operation 10939 To reduce the amount of configuration required on an initiator, iSCSI 10940 provides the SendTargets text request. The initiator uses the Send- 10941 Targets request to get a list of targets to which it may have access, 10942 as well as the list of addresses (IP address and TCP port) on which 10943 these targets may be accessed. 10945 To make use of SendTargets, an initiator must first establish one of 10946 two types of sessions. If the initiator establishes the session 10947 using the key "SessionType=Discovery", the session is a discovery 10948 session, and a target name does not need to be specified. Other- 10949 wise, the session is a normal, operational session. The SendTargets 10950 command MUST only be sent during the Full Feature Phase of a normal 10951 or discovery session. 10953 A system that contains targets MUST support discovery sessions on 10954 each of its iSCSI IP address-port pairs, and MUST support the Send- 10955 Targets command on the discovery session. A target MUST return all 10956 path information (IP address-port pairs and portal group tags) for 10957 the targets for which the requesting initiator is authorized. 10959 A target MUST support the SendTargets command on operational ses- 10960 sions; these will only return path information about the target to 10961 which the session is connected, and need not return information about 10962 other target names that may be defined in the responding system. 10964 An initiator MAY make use of the SendTargets as it sees fit. 10966 A SendTargets command consists of a single Text request PDU. 10967 This PDU contains exactly one text key and value. The text key MUST 10968 be SendTargets. The expected response depends upon the value, as 10969 well as whether the session is a discovery or operational session. 10971 The value must be one of: 10973 All 10975 The initiator is requesting that information on all relevant 10976 targets known to the implementation be returned. This value 10977 MUST be supported on a discovery session, and MUST NOT be 10978 supported on an operational session. 10980 10982 Julian Satran Expires February 2003 253 10983 iSCSI 5-August-02 10985 If an iSCSI target name is specified, the session should 10986 respond with addresses for only the named target, if possi- 10987 ble. This value MUST be supported on discovery sessions. A 10988 discovery session MUST be capable of returning addresses for 10989 those targets that would have been returned had value=All 10990 been designated. 10992 10994 The session should respond only with addresses for the target 10995 to which the session is logged in. This MUST be supported 10996 on operational sessions, and MUST NOT return targets other 10997 than the one to which the session is logged in. 10999 The response to this command is a text response that contains a list 11000 of zero or more targets and, optionally, their addresses. Each tar- 11001 get is returned as a target record. A target record begins with the 11002 TargetName text key, followed by a list of TargetAddress text keys, 11003 and bounded by the end of the text response or the next TargetName 11004 key, which begins a new record. No text keys other than TargetName 11005 and TargetAddress are permitted within a SendTargets response. 11007 For the format of the TargetName, see Section 11.4 TargetName. 11009 A discovery session MAY respond to a SendTargets request with its 11010 complete list of targets, or with a list of targets that is based on 11011 the name of the initiator logged in to the session. 11013 A SendTargets response MUST NOT not contain target names if there are 11014 no targets for the requesting initiator to access. 11016 Each target record returned includes zero or more TargetAddress 11017 fields. 11019 Each target record starts with one text key of the form: 11021 TargetName= 11023 Followed by zero or more address keys of the form: 11025 TargetAddress=[:], 11028 The hostname-or-ipaddress contains a domain name, IPv4 address, or 11029 IPv6 address, as specified for the TargetAddress key. 11031 Julian Satran Expires February 2003 254 11032 iSCSI 5-August-02 11034 Each TargetAddress belongs to a portal group, identified by its 11035 numeric portal group tag (as in Section 11.9 TargetPortalGroupTag). 11036 The iSCSI target name, together with this tag, constitutes the SCSI 11037 port identifier; the tag need be unique only within a given target 11038 name's list of addresses. 11040 Multiple-connection sessions can span iSCSI addresses that belong to 11041 the same portal group. 11043 Multiple-connection sessions cannot span iSCSI addresses that belong 11044 to different portal groups. 11046 If a SendTargets response reports an iSCSI address for a target, it 11047 SHOULD also report all other addresses in its portal group in the 11048 same response. 11050 A SendTargets text response can be longer than a single Text Response 11051 PDU, and makes use of the long text responses as specified. 11053 After obtaining a list of targets from the discovery target session, 11054 an iSCSI initiator may initiate new sessions to log in to the discov- 11055 ered targets for full operation. The initiator MAY keep the discov- 11056 ery session open, and MAY send subsequent SendTargets commands to 11057 discover new targets. 11059 Examples: 11061 This example is the SendTargets response from a single target that 11062 has no other interface ports. 11064 Initiator sends text request that contains: 11066 SendTargets=All 11068 Target sends a text response that contains: 11070 TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 11072 All the target had to return in the simple case was the target name. 11073 It is assumed by the initiator that the IP address and TCP port for 11075 Julian Satran Expires February 2003 255 11076 iSCSI 5-August-02 11078 this target are the same as used on the current connection to the 11079 default iSCSI target. 11081 The next example has two internal iSCSI targets, each accessible via 11082 two different ports with different IP addresses. The following is 11083 the text response: 11085 TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 11086 TargetAddress=10.1.0.45:3000,1 11087 TargetAddress=10.1.1.45:3000,2 11088 TargetName=iqn.1993-11.com.acme:diskarray.sn.1234567 11089 TargetAddress=10.1.0.45:3000,1 11090 TargetAddress=10.1.1.45:3000,2 11092 Both targets share both addresses; the multiple addresses are likely 11093 used to provide multi-path support. The initiator may connect to 11094 either target name on either address. Each of the addresses has its 11095 own portal group tag; they do not support spanning multiple-connec- 11096 tion sessions with each other. Keep in mind also that the portal 11097 group tags for the two named targets are independent of one another; 11098 portal group "1" on the first target is not necessarily the same as 11099 portal group "1" on the second. 11101 In the above example, a DNS host name or an IPv6 address could have 11102 been returned instead of an IPv4 address. 11104 The next text response shows a target that supports spanning ses- 11105 sions across multiple addresses, and illustrates further the use of 11106 the portal group tags: 11108 TargetName=iqn.1993-11.com.acme:diskarray.sn.8675309 11109 TargetAddress=10.1.0.45:3000,1 11110 TargetAddress=10.1.1.46:3000,1 11111 TargetAddress=10.1.0.47:3000,2 11112 TargetAddress=10.1.1.48:3000,2 11113 TargetAddress=10.1.1.49:3000,3 11115 In this example, any of the target addresses can be used to reach the 11116 same target. A single-connection session can be established to any 11117 of these TCP addresses. A multiple-connection session could span 11118 addresses .45 and .46 or .47 and .48, but cannot span any other com- 11119 bination. A TargetAddress with its own tag (.49) cannot be combined 11120 with any other address within the same session. 11122 Julian Satran Expires February 2003 256 11123 iSCSI 5-August-02 11125 This SendTargets response does not indicate whether .49 supports mul- 11126 tiple connections per session; it communicated via the MaxConnec- 11127 tions text key upon login to the target. 11129 Julian Satran Expires February 2003 257 11130 iSCSI 5-August-02 11132 Appendix E. Algorithmic Presentation of Error Recovery Classes 11134 This appendix illustrates the error recovery classes using a pseudo- 11135 programming-language. The procedure names are chosen to be obvious 11136 to most implementers. Each of the recovery classes described has ini- 11137 tiator procedures as well as target procedures. These algorithms 11138 focus on outlining the mechanics of error recovery classes, and do 11139 not exhaustively describe all other aspects/cases. Examples of this 11140 approach are: 11142 - Handling for only certain Opcode types is shown. 11144 - Only certain reason codes (for example, Recovery in Logout 11145 command) are outlined. 11147 - Resultant cases, such as recovery of Synchronization on a 11148 header digest error are considered out-of-scope in these 11149 algorithms. In this particular example a header digest error 11150 may lead to connection recovery if some type of sync and 11151 steering layer is not implemented. 11153 These algorithms strive to convey the iSCSI error recovery concepts 11154 in the simplest terms, and are not designed to be optimal. 11156 E.1 General Data Structure and Procedure Description 11158 This section defines the procedures and data structures that are com- 11159 monly used by all the error recovery algorithms. The structures may 11160 not be the exhaustive representations of what is required for a typi- 11161 cal implementation. 11163 Data structure definitions - 11164 struct TransferContext { 11165 int TargetTransferTag; 11166 int ExpectedDataSN; 11167 }; 11169 struct TCB { /* task control block */ 11170 Boolean SoFarInOrder; 11171 int ExpectedDataSN; /* used for both R2Ts, and Data */ 11172 int MissingDataSNList[MaxMissingDPDU]; 11173 Boolean FbitReceived; 11174 Boolean StatusXferd; 11175 Boolean CurrentlyAllegiant; 11177 Julian Satran Expires February 2003 258 11178 iSCSI 5-August-02 11180 int ActiveR2Ts; 11181 int Response; 11182 char *Reason; 11183 struct TransferContext 11184 TransferContextList[MaxOutStandingR2T]; 11185 int InitiatorTaskTag; 11186 int CmdSN; 11187 int SNACK_Tag; 11188 }; 11190 struct Connection { 11191 struct Session SessionReference; 11192 Boolean SoFarInOrder; 11193 int CID; 11194 int State; 11195 int CurrentTimeout; 11196 int ExpectedStatSN; 11197 int MissingStatSNList[MaxMissingSPDU]; 11198 Boolean PerformConnectionCleanup; 11199 }; 11201 struct Session { 11202 int NumConnections; 11203 int CmdSN; 11204 int Maxconnections; 11205 int ErrorRecoveryLevel; 11206 struct iSCSIEndpoint OtherEndInfo; 11207 struct Connection ConnectionList[MaxSupportedConns]; 11208 }; 11210 Procedure descriptions - 11211 Receive-a-In-PDU(transport connection, inbound PDU); 11212 check-basic-validity(inbound PDU); 11213 Start-Timer(timeout handler, argument, timeout value); 11214 Build-And-Send-Reject(transport connection, bad PDU, reason code); 11216 E.2 Within-command Error Recovery Algorithms 11218 E.2.1 Procedure Descriptions 11220 Recover-Data-if-Possible(last required DataSN, task control block); 11221 Build-And-Send-DSnack(task control block); 11222 Build-And-Send-RDSnack(task control block); 11223 Build-And-Send-Abort(task control block); 11225 Julian Satran Expires February 2003 259 11226 iSCSI 5-August-02 11228 SCSI-Task-Completion(task control block); 11229 Build-And-Send-A-Data-Burst(transport connection, data-descriptor, 11230 task control block); 11231 Build-And-Send-R2T(transport connection, data-descriptor, 11232 task control block); 11233 Build-And-Send-Status(transport connection, task control block); 11234 Transfer-Context-Timeout-Handler(transfer context); 11236 Notes: 11238 - One procedure used in this section: Handle-Status-SNACK- 11239 request is defined in Within-connection recovery algorithms. 11241 - The Response processing pseudo-code, shown in the target 11242 algorithms, applies to all solicited PDUs that carry StatSN - 11243 SCSI Response, Text Response etc. 11245 E.2.2 Initiator Algorithms 11247 Recover-Data-if-Possible(LastRequiredDataSN, TCB) 11248 { 11249 if (operational ErrorRecoveryLevel > 0) { 11250 if (# of missing PDUs is trackable) { 11251 Note the missing DataSNs in TCB. 11252 if (the task spanned a change in 11253 MaxRecvDataSegmentLength) { 11254 if (TCB.StatusXferd is TRUE) 11255 drop the status PDU; 11256 Build-And-Send-RDSnack(TCB); 11257 } else { 11258 Build-And-Send-DSnack(TCB); 11259 } 11260 } else { 11261 TCB.Reason = "Protocol service CRC error"; 11262 } 11263 } else { 11264 TCB.Reason = "Protocol service CRC error"; 11265 } 11266 if (TCB.Reason == "Protocol service CRC error") { 11267 Clear the missing PDU list in the TCB. 11268 if (TCB.StatusXferd is not TRUE) 11269 Build-And-Send-Abort(TCB); 11270 } 11271 } 11273 Julian Satran Expires February 2003 260 11274 iSCSI 5-August-02 11276 Receive-a-In-PDU(Connection, CurrentPDU) 11277 { 11278 check-basic-validity(CurrentPDU); 11279 if (Header-Digest-Bad) discard, return; 11280 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11281 if ((CurrentPDU.type == Data) 11282 or (CurrentPDU.type = R2T)) { 11283 if (Data-Digest-Bad for Data) { 11284 send-data-SNACK = TRUE; 11285 LastRequiredDataSN = CurrentPDU.DataSN; 11286 } else { 11287 if (TCB.SoFarInOrder = TRUE) { 11288 if (current DataSN is expected) { 11289 Increment TCB.ExpectedDataSN. 11290 } else { 11291 TCB.SoFarInOrder = FALSE; 11292 send-data-SNACK = TRUE; 11293 } 11294 } else { 11295 if (current DataSN was considered missing) { 11296 remove current DataSN from missing PDU list. 11297 } else if (current DataSN is higher than expected) { 11298 send-data-SNACK = TRUE; 11299 } else { 11300 discard, return; 11301 } 11302 Adjust TCB.ExpectedDataSN if appropriate. 11303 } 11304 LastRequiredDataSN = CurrentPDU.DataSN - 1; 11305 } 11306 if (send-data-SNACK is TRUE and 11307 task is not already considered failed) { 11308 Recover-Data-if-Possible(LastRequiredDataSN, TCB); 11309 } 11310 if (missing data PDU list is empty) { 11311 TCB.SoFarInOrder = TRUE; 11312 } 11313 if (CurrentPDU.type == R2T) { 11314 Increment ActiveR2Ts for this task. 11315 Create a data-descriptor for the data burst. 11316 Build-And-Send-A-Data-Burst(Connection, data-descriptor, 11317 TCB); 11319 Julian Satran Expires February 2003 261 11320 iSCSI 5-August-02 11322 } 11323 } else if (CurrentPDU.type == Response) { 11324 if (Data-Digest-Bad) { 11325 send-status-SNACK = TRUE; 11326 } else { 11327 TCB.StatusXferd = TRUE; 11328 Store the status information in TCB. 11329 if (ExpDataSN does not match) { 11330 TCB.SoFarInOrder = FALSE; 11331 Recover-Data-if-Possible(current DataSN, TCB); 11332 } 11333 if (missing data PDU list is empty) { 11334 TCB.SoFarInOrder = TRUE; 11335 } 11336 } 11337 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN 11338 */ 11339 } 11340 if ((TCB.SoFarInOrder == TRUE) and 11341 (TCB.StatusXferd == TRUE)) { 11342 SCSI-Task-Completion(TCB); 11343 } 11344 } 11346 E.2.3 Target Algorithms 11348 Receive-a-In-PDU(Connection, CurrentPDU) 11349 { 11350 check-basic-validity(CurrentPDU); 11351 if (Header-Digest-Bad) discard, return; 11352 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11353 if (CurrentPDU.type == Data) { 11354 Retrieve TContext from CurrentPDU.TargetTransferTag; 11355 if (Data-Digest-Bad) { 11356 Build-And-Send-Reject(Connection, CurrentPDU, 11357 Payload-Digest-Error); 11358 Note the missing data PDUs in MissingDataRange[]. 11359 send-recovery-R2T = TRUE; 11360 } else { 11361 if (current DataSN is not expected) { 11362 Note the missing data PDUs in MissingDataRange[]. 11363 send-recovery-R2T = TRUE; 11364 } 11366 Julian Satran Expires February 2003 262 11367 iSCSI 5-August-02 11369 if (CurrentPDU.Fbit == TRUE) { 11370 if (current PDU is solicited) { 11371 Decrement TCB.ActiveR2Ts. 11372 } 11373 if ((current PDU is unsolicited and 11374 data received is less than I/O length and 11375 data received is less than FirstBurstLength) 11376 or (current PDU is solicited and the length of 11377 this burst is less than expected)) { 11378 send-recovery-R2T = TRUE; 11379 Note the missing data in MissingDataRange[]. 11380 } 11381 } 11382 } 11383 Increment TContext.ExpectedDataSN. 11384 if (send-recovery-R2T is TRUE and 11385 task is not already considered failed) { 11386 if (operational ErrorRecoveryLevel > 0) { 11387 Increment TCB.ActiveR2Ts. 11388 Create a data-descriptor for the data burst 11389 from MissingDataRange. 11390 Build-And-Send-R2T(Connection, data-descriptor, TCB); 11391 } else { 11392 if (current PDU is the last unsolicited) 11393 TCB.Reason = "Not enough unsolicited data"; 11394 else 11395 TCB.Reason = "Protocol service CRC error"; 11396 } 11397 } 11398 if (TCB.ActiveR2Ts == 0) { 11399 Build-And-Send-Status(Connection, TCB); 11400 } 11401 } else if (CurrentPDU.type == SNACK) { 11402 snack-failure = FALSE; 11403 if (operational ErrorRecoveryLevel > 0) { 11404 if (CurrentPDU.type == Data/R2T) { 11405 if (the request is satisfiable) { 11406 if (request for Data) { 11407 Create a data-descriptor for the data burst 11408 from BegRun and RunLength. 11409 Build-And-Send-A-Data-Burst(Connection, 11410 data-descriptor, TCB); 11411 } else { /* R2T */ 11413 Julian Satran Expires February 2003 263 11414 iSCSI 5-August-02 11416 Create a data-descriptor for the data burst 11417 from BegRun and RunLength. 11418 Build-And-Send-R2T(Connection, data-descriptor, 11419 TCB); 11420 } 11421 } else { 11422 snack-failure = TRUE; 11423 } 11424 } else if (CurrentPDU.type == status) { 11425 Handle-Status-SNACK-request(Connection, CurrentPDU); 11426 } else if (CurrentPDU.type == DataACK) { 11427 Consider all data upto CurrentPDU.BegRun as 11428 acknowledged. 11429 Free up the retransmission resources for that data. 11430 } else if (CurrentPDU.type == R-Data SNACK) { 11431 Create a data descriptor for a data burst covering 11432 all unacknowledged data. 11433 Build-And-Send-A-Data-Burst(Connection, 11434 data-descriptor, TCB); 11435 TCB.SNACK_Tag = CurrentPDU.SNACK_Tag; 11436 if (there's no more data to send) { 11437 Build-And-Send-Status(Connection, TCB); 11438 } 11439 } 11440 } else { /* operational ErrorRecoveryLevel = 0 */ 11441 snack-failure = TRUE; 11442 } 11443 if (snack-failure == TRUE) { 11444 Build-And-Send-Reject(Connection, CurrentPDU, 11445 SNACK-Reject); 11446 if (TCB.StatusXferd != TRUE) { 11447 TCB.Reason = "SNACK Rejected"; 11448 Build-And-Send-Status(Connection, TCB); 11449 } 11450 } 11452 } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN */ 11453 } 11454 } 11456 Transfer-Context-Timeout-Handler(TContext) 11457 { 11458 Retrieve TCB and Connection from TContext. 11460 Julian Satran Expires February 2003 264 11461 iSCSI 5-August-02 11463 Decrement TCB.ActiveR2Ts. 11464 if (operational ErrorRecoveryLevel > 0 and 11465 task is not already considered failed) { 11466 Note the missing data PDUs in MissingDataRange[]. 11467 Create a data-descriptor for the data burst 11468 from MissingDataRange[]. 11469 Build-And-Send-R2T(Connection, data-descriptor, TCB); 11470 } else { 11471 TCB.Reason = "Protocol service CRC error"; 11472 if (TCB.ActiveR2Ts = 0) { 11473 Build-And-Send-Status(Connection, TCB); 11474 } 11475 } 11476 } 11478 E.3 Within-connection Recovery Algorithms 11480 E.3.1 Procedure Descriptions 11482 Procedure descriptions: 11483 Recover-Status-if-Possible(transport connection, 11484 currently received PDU); 11485 Evaluate-a-StatSN(transport connection, currently received PDU); 11486 Retransmit-Command-if-Possible(transport connection, CmdSN); 11487 Build-And-Send-SSnack(transport connection); 11488 Build-And-Send-Command(transport connection, task control block); 11489 Command-Acknowledge-Timeout-Handler(task control block); 11490 Status-Expect-Timeout-Handler(transport connection); 11491 Build-And-Send-Nop-Out(transport connection); 11492 Handle-Status-SNACK-request(transport connection, status SNACK PDU); 11493 Retransmit-Status-Burst(status SNACK, task control block); 11494 Is-Acknowledged(beginning StatSN, run length); 11496 Implementation-specific tunables: 11497 InitiatorProactiveSNACKEnabled 11499 Notes: 11500 - The initiator algorithms only deal with unsolicited Nop-In 11501 PDUs for generating status SNACKs. Solicited Nop-In PDU has 11502 an assigned StatSN, which, when out of order, could trigger 11503 the out of order StatSN handling in Within-command algo- 11504 rithms, again leading to Recover-Status-if-Possible. 11506 - The pseudo-code shown may result in the retransmission of 11507 unacknowledged commands in more cases than necessary. This 11509 Julian Satran Expires February 2003 265 11510 iSCSI 5-August-02 11512 will not, however, affect the correctness of the operation 11513 because the target is required to discard the duplicate Cmd- 11514 SNs. 11516 - The procedure Build-And-Send-Async is defined in the Connec- 11517 tion recovery algorithms. 11519 - The procedure Status-Expect-Timeout-Handler describes how 11520 initiators may proactively attempt to retrieve the Status if 11521 they so choose. This procedure is assumed to be triggered 11522 much before the standard ULP timeout. 11524 E.3.2 Initiator Algorithms 11526 Recover-Status-if-Possible(Connection, CurrentPDU) 11527 { 11528 if ((Connection.state == LOGGED_IN) and 11529 connection is not already considered failed) { 11530 if (operational ErrorRecoveryLevel > 0) { 11531 if (# of missing PDUs is trackable) { 11532 Note the missing StatSNs in Connection 11533 that were not already requested with SNACK; 11534 Build-And-Send-SSnack(Connection); 11535 } else { 11536 Connection.PerformConnectionCleanup = TRUE; 11537 } 11538 } else { 11539 Connection.PerformConnectionCleanup = TRUE; 11540 } 11541 if (Connection.PerformConnectionCleanup == TRUE) { 11542 Start-Timer(Connection-Cleanup-Handler, Connection, 0); 11543 } 11544 } 11545 } 11547 Retransmit-Command-if-Possible(Connection, CmdSN) 11548 { 11549 if (operational ErrorRecoveryLevel > 0) { 11550 Retrieve the InitiatorTaskTag, and thus TCB for the CmdSN. 11551 Build-And-Send-Command(Connection, TCB); 11552 } 11553 } 11555 Evaluate-a-StatSN(Connection, CurrentPDU) 11556 { 11558 Julian Satran Expires February 2003 266 11559 iSCSI 5-August-02 11561 send-status-SNACK = FALSE; 11562 if (Connection.SoFarInOrder == TRUE) { 11563 if (current StatSN is the expected) { 11564 Increment Connection.ExpectedStatSN. 11565 } else { 11566 Connection.SoFarInOrder = FALSE; 11567 send-status-SNACK = TRUE; 11568 } 11569 } else { 11570 if (current StatSN was considered missing) { 11571 remove current StatSN from the missing list. 11572 } else { 11573 if (current StatSN is higher than expected){ 11574 send-status-SNACK = TRUE; 11575 } else { 11576 send-status-SNACK = FALSE; 11577 discard the PDU; 11578 } 11579 } 11580 Adjust Connection.ExpectedStatSN if appropriate. 11581 if (missing StatSN list is empty) { 11582 Connection.SoFarInOrder = TRUE; 11583 } 11584 } 11585 return send-status-SNACK; 11586 } 11588 Receive-a-In-PDU(Connection, CurrentPDU) 11589 { 11590 check-basic-validity(CurrentPDU); 11591 if (Header-Digest-Bad) discard, return; 11592 Retrieve TCB for CurrentPDU.InitiatorTaskTag. 11593 if (CurrentPDU.type == Nop-In) { 11594 if (the PDU is unsolicited) { 11595 if (current StatSN is not expected) { 11596 Recover-Status-if-Possible(Connection, CurrentPDU); 11597 } 11598 if (current ExpCmdSN is not Session.CmdSN) { 11599 Retransmit-Command-if-Possible(Connection, 11600 CurrentPDU.ExpCmdSN); 11601 } 11602 } 11603 } else if (CurrentPDU.type == Reject) { 11605 Julian Satran Expires February 2003 267 11606 iSCSI 5-August-02 11608 if (it is a data digest error on immediate data) { 11609 Retransmit-Command-if-Possible(Connection, 11610 CurrentPDU.BadPDUHeader.CmdSN); 11611 } 11612 } else if (CurrentPDU.type == Response) { 11613 send-status-SNACK = Evaluate-a-StatSN(Connection, 11614 CurrentPDU); 11615 if (send-status-SNACK == TRUE) 11616 Recover-Status-if-Possible(Connection, CurrentPDU); 11617 } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY, 11618 * NOT SHOWN */ 11619 } 11620 } 11622 Command-Acknowledge-Timeout-Handler(TCB) 11623 { 11624 Retrieve the Connection for TCB. 11625 Retransmit-Command-if-Possible(Connection, TCB.CmdSN); 11626 } 11628 Status-Expect-Timeout-Handler(Connection) 11629 { 11630 if (operational ErrorRecoveryLevel > 0) { 11631 Build-And-Send-Nop-Out(Connection); 11632 } else if (InitiatorProactiveSNACKEnabled){ 11633 if ((Connection.state == LOGGED_IN) and 11634 connection is not already considered failed) { 11635 Build-And-Send-SSnack(Connection); 11636 } 11637 } 11638 } 11640 E.3.3 Target Algorithms 11642 Handle-Status-SNACK-request(Connection, CurrentPDU) 11643 { 11644 if (operational ErrorRecoveryLevel > 0) { 11645 if (request for an acknowledged run) { 11646 Build-And-Send-Reject(Connection, CurrentPDU, 11647 Protocol-Error); 11648 } else if (request for an untransmitted run) { 11649 discard, return; 11650 } else { 11652 Julian Satran Expires February 2003 268 11653 iSCSI 5-August-02 11655 Retransmit-Status-Burst(CurrentPDU, TCB); 11656 } 11657 } else { 11658 Build-And-Send-Async(Connection, DroppedConnection, 11659 DefaultTime2Wait, DefaultTime2Retain); 11660 } 11661 } 11663 E.4 Connection Recovery Algorithms 11665 E.4.1 Procedure Descriptions 11667 Build-And-Send-Async(transport connection, reason code, 11668 minimum time, maximum time); 11669 Pick-A-Logged-In-Connection(session); 11670 Build-And-Send-Logout(transport connection, logout connection 11671 identifier, reason code); 11672 PerformImplicitLogout(transport connection, logout connection 11673 identifier, target information); 11674 PerformLogin(transport connection, target information); 11675 CreateNewTransportConnection(target information); 11676 Build-And-Send-Command(transport connection, task control block); 11677 Connection-Cleanup-Handler(transport connection); 11678 Connection-Resource-Timeout-Handler(transport connection); 11679 Quiesce-And-Prepare-for-New-Allegiance(session, task control block); 11680 Build-And-Send-Logout-Response(transport connection, 11681 CID of connection in recovery, reason code); 11682 Build-And-Send-TaskMgmt-Response(transport connection, 11683 task mgmt command PDU, response code); 11684 Establish-New-Allegiance(task control block, transport connection); 11685 Schedule-Command-To-Continue(task control block); 11687 Notes: 11688 - Transport exception conditions, such as unexpected connec- 11689 tion termination, connection reset, and hung connection while 11690 the connection is in the full-feature phase, are all assumed 11691 to be asynchronously signaled to the iSCSI layer using the 11692 Transport_Exception_Handler procedure. 11694 E.4.2 Initiator Algorithms 11696 Receive-a-In-PDU(Connection, CurrentPDU) 11697 { 11698 check-basic-validity(CurrentPDU); 11700 Julian Satran Expires February 2003 269 11701 iSCSI 5-August-02 11703 if (Header-Digest-Bad) discard, return; 11704 Retrieve TCB from CurrentPDU.InitiatorTaskTag. 11705 if (CurrentPDU.type == Async) { 11706 if (CurrentPDU.AsyncEvent == ConnectionDropped) { 11707 Retrieve the AffectedConnection for CurrentPDU.Parameter1. 11708 AffectedConnection.CurrentTimeout = CurrentPDU.Parameter3; 11709 AffectedConnection.State = CLEANUP_WAIT; 11710 Start-Timer(Connection-Cleanup-Handler, 11711 AffectedConnection, CurrentPDU.Parameter2); 11712 } else if (CurrentPDU.AsyncEvent == LogoutRequest)) { 11713 AffectedConnection = Connection; 11714 AffectedConnection.State = LOGOUT_REQUESTED; 11715 AffectedConnection.PerformConnectionCleanup = TRUE; 11716 AffectedConnection.CurrentTimeout = CurrentPDU.Parameter3; 11717 Start-Timer(Connection-Cleanup-Handler, 11718 AffectedConnection, 0); 11719 } else if (CurrentPDU.AsyncEvent == SessionDropped)) { 11720 for (each Connection) { 11721 Connection.State = CLEANUP_WAIT; 11722 Connection.CurrentTimeout = CurrentPDU.Parameter3; 11723 Start-Timer(Connection-Cleanup-Handler, 11724 Connection, CurrentPDU.Parameter2); 11725 } 11726 Session.state = FAILED; 11727 } 11729 } else if (CurrentPDU.type == LogoutResponse) { 11730 Retrieve the CleanupConnection for CurrentPDU.CID. 11731 if (CurrentPDU.Response = failure) { 11732 CleanupConnection.State = CLEANUP_WAIT; 11733 } else { 11734 CleanupConnection.State = FREE; 11735 } 11736 } else if (CurrentPDU.type == LoginResponse) { 11737 if (this is a response to an implicit Logout) { 11738 Retrieve the CleanupConnection. 11739 if (successful) { 11740 CleanupConnection.State = FREE; 11741 Connection.State = LOGGED_IN; 11742 } else { 11743 CleanupConnection.State = CLEANUP_WAIT; 11744 DestroyTransportConnection(Connection); 11745 } 11747 Julian Satran Expires February 2003 270 11748 iSCSI 5-August-02 11750 } 11751 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 11752 * NOT SHOWN */ 11753 } 11754 if (CleanupConnection.State == FREE) { 11755 for (each command that was active on CleanupConnection) { 11756 /* Establish new connection allegiance */ 11757 NewConnection = Pick-A-Logged-In-Connection(Session); 11758 Build-And-Send-Command(NewConnection, TCB); 11759 } 11760 } 11761 } 11763 Connection-Cleanup-Handler(Connection) 11764 { 11765 Retrieve Session from Connection. 11766 if (Connection can still exchange iSCSI PDUs) { 11767 NewConnection = Connection; 11768 } else { 11769 Start-Timer(Connection-Resource-Timeout-Handler, 11770 Connection, Connection.CurrentTimeout); 11771 if (there are other logged-in connections) { 11772 NewConnection = Pick-A-Logged-In-Connection(Session); 11773 } else { 11774 NewConnection = 11775 CreateTransportConnection(Session.OtherEndInfo); 11776 Initiate an implicit Logout on NewConnection for 11777 Connection.CID. 11778 return; 11779 } 11780 } 11781 Build-And-Send-Logout(NewConnection, Connection.CID, 11782 RecoveryRemove); 11783 } 11785 Transport_Exception_Handler(Connection) 11786 { 11787 Connection.PerformConnectionCleanup = TRUE; 11788 if (the event is an unexpected transport disconnect) { 11789 Connection.State = CLEANUP_WAIT; 11790 Connection.CurrentTimeout = DefaultTime2Retain; 11791 Start-Timer(Connection-Cleanup-Handler, Connection, 11792 DefaultTime2Wait); 11794 Julian Satran Expires February 2003 271 11795 iSCSI 5-August-02 11797 } else { 11798 Connection.State = FREE; 11799 } 11800 } 11802 E.4.3 Target Algorithms 11804 Receive-a-In-PDU(Connection, CurrentPDU) 11805 { 11806 check-basic-validity(CurrentPDU); 11807 if (Header-Digest-Bad) discard, return; 11808 else if (Data-Digest-Bad) { 11809 Build-And-Send-Reject(Connection, CurrentPDU, 11810 Payload-Digest-Error); 11811 discard, return; 11812 } 11813 Retrieve TCB and Session. 11814 if (CurrentPDU.type == Logout) { 11815 if (CurrentPDU.ReasonCode = RecoveryRemove) { 11816 Retrieve the CleanupConnection from CurrentPDU.CID). 11817 for (each command active on CleanupConnection) { 11818 Quiesce-And-Prepare-for-New-Allegiance(Session, TCB); 11819 TCB.CurrentlyAllegiant = FALSE; 11820 } 11821 Cleanup-Connection-State(CleanupConnection); 11822 if ((quiescing successful) and (cleanup successful)) { 11823 Build-And-Send-Logout-Response(Connection, 11824 CleanupConnection.CID, Success); 11825 } else { 11826 Build-And-Send-Logout-Response(Connection, 11827 CleanupConnection.CID, Failure); 11828 } 11829 } 11830 } else if ((CurrentPDU.type == Login) and 11831 operational ErrorRecoveryLevel == 2) { 11832 Retrieve the CleanupConnection from CurrentPDU.CID). 11833 for (each command active on CleanupConnection) { 11834 Quiesce-And-Prepare-for-New-Allegiance(Session, TCB); 11835 TCB.CurrentlyAllegiant = FALSE; 11836 } 11837 Cleanup-Connection-State(CleanupConnection); 11838 if ((quiescing successful) and (cleanup successful)) { 11840 Julian Satran Expires February 2003 272 11841 iSCSI 5-August-02 11843 Continue with the rest of the Login processing; 11844 } else { 11845 Build-And-Send-Login-Response(Connection, 11846 CleanupConnection.CID, Target Error); 11847 } 11848 } 11849 } else if (CurrentPDU.type == TaskManagement) { 11850 if (CurrentPDU.function == "TaskReassign") { 11851 if (Session.ErrorRecoveryLevel < 2) { 11852 Build-And-Send-TaskMgmt-Response(Connection, 11853 CurrentPDU, "Allegiance reassignment 11854 not supported"); 11855 } else if (task is not found) { 11856 Build-And-Send-TaskMgmt-Response(Connection, 11857 CurrentPDU, "Task not in task set"); 11858 } else if (task is currently allegiant) { 11859 Build-And-Send-TaskMgmt-Response(Connection, 11860 CurrentPDU, "Task still allegiant"); 11861 } else { 11862 Establish-New-Allegiance(TCB, Connection); 11863 TCB.CurrentlyAllegiant = TRUE; 11864 Schedule-Command-To-Continue(TCB); 11865 } 11866 } 11867 } else { /* REST UNRELATED TO CONNECTION-RECOVERY, 11868 * NOT SHOWN */ 11869 } 11870 } 11872 Transport_Exception_Handler(Connection) 11873 { 11874 Connection.PerformConnectionCleanup = TRUE; 11875 if (the event is an unexpected transport disconnect) { 11876 Connection.State = CLEANUP_WAIT; 11877 Start-Timer(Connection-Resource-Timeout-Handler, Connection, 11878 (DefaultTime2Wait+DefaultTime2Retain)); 11879 if (this Session has full-feature phase connections left) { 11880 DifferentConnection = 11881 Pick-A-Logged-In-Connection(Session); 11882 Build-And-Send-Async(DifferentConnection, 11883 DroppedConnection, DefaultTime2Wait, 11884 DefaultTime2Retain); 11885 } 11887 Julian Satran Expires February 2003 273 11888 iSCSI 5-August-02 11890 } else { 11891 Connection.State = FREE; 11892 } 11893 } 11895 Julian Satran Expires February 2003 274 11896 iSCSI 5-August-02 11898 Appendix F. Clearing effects of various events on targets 11900 F.1 Clearing effects on iSCSI objects 11902 The following tables describe the target behavior on receiving the 11903 events specified in the rows of the table. The second table is 11904 merely an extension of the first table and defines clearing actions 11905 for more objects on the same events. The legend is: 11907 Y = Yes (cleared/discarded/reset on the event specified in 11908 the row). Unless noted otherwise, the clearing action is 11909 applicable only for the issuing initiator port. 11910 N = No (not affected on the event specified in the row, i.e. 11911 stays at previous value). 11912 NA = Not Applicable, or Not Defined. 11914 Julian Satran Expires February 2003 275 11915 iSCSI 5-August-02 11917 +-----+-----+-----+-----+-----+ 11918 |IT(1)|IC(2)|CT(5)|ST(6)|PP(7)| 11919 +---------------------+-----+-----+-----+-----+-----+ 11920 |connection failure(8)|Y |Y |N |N |Y | 11921 +---------------------+-----+-----+-----+-----+-----+ 11922 |connection state |NA |NA |Y |N |NA | 11923 |timeout (9) | | | | | | 11924 +---------------------+-----+-----+-----+-----+-----+ 11925 |session timeout/ |Y |Y |Y |Y |Y(14)| 11926 |closure/reinstatement| | | | | | 11927 |(10) | | | | | | 11928 +---------------------+-----+-----+-----+-----+-----+ 11929 |session continuation |NA |NA |N(11)|N |NA | 11930 |(12) | | | | | | 11931 +---------------------+-----+-----+-----+-----+-----+ 11932 |successful connection|Y |Y |Y |N |Y(13)| 11933 |close logout | | | | | | 11934 +---------------------+-----+-----+-----+-----+-----+ 11935 |session failure (18) |Y |Y |N |N |Y | 11936 +---------------------+-----+-----+-----+-----+-----+ 11937 |successful recovery |Y |Y |N |N |Y(13)| 11938 |Logout | | | | | | 11939 +---------------------+-----+-----+-----+-----+-----+ 11940 |failed Logout |Y |Y |N |N |Y | 11941 +---------------------+-----+-----+-----+-----+-----+ 11942 |connection Login |NA |NA |NA |Y(15)|NA | 11943 |(leading) | | | | | | 11944 +---------------------+-----+-----+-----+-----+-----+ 11945 |connection Login |NA |NA |N(11)|N |Y | 11946 |(non-leading) | | | | | | 11947 +---------------------+-----+-----+-----+-----+-----+ 11948 |target cold reset(16)|Y |Y |Y |Y |Y | 11949 +---------------------+-----+-----+-----+-----+-----+ 11950 |target warm reset(16)|Y |Y |Y |Y |Y | 11951 +---------------------+-----+-----+-----+-----+-----+ 11952 |LU reset(19) |Y |Y |Y |Y |Y | 11953 +---------------------+-----+-----+-----+-----+-----+ 11954 |powercycle(16) |Y |Y |Y |Y |Y | 11955 +---------------------+-----+-----+-----+-----+-----+ 11957 1.Incomplete TTTs - Target Transfer Tags on which the target is still 11958 expecting PDUs to be received. Examples include TTTs received via 11959 R2T, NOP-IN etc. 11961 Julian Satran Expires February 2003 276 11962 iSCSI 5-August-02 11964 2.Immediate Commands - immediate commands but waiting for execution 11965 on a target, for ex., Abort Task Set. 11967 5.Connection Tasks - tasks that are active on the iSCSI connection in 11968 question. 11970 6.Session Tasks - tasks that are active on the entire iSCSI session, 11971 so is a union of `connection tasks' on all participating connections. 11973 7.Partial PDUs (if any) - PDUs that are partially sent and waiting 11974 for transport window credit to complete the transmission. 11976 8.Connection failure is a connection exception condition -one of 11977 transport connection shutdown, transport connection reset, or trans- 11978 port connection timeout abruptly terminating the iSCSI full-feature 11979 phase connection. A connection failure always takes the connection 11980 state machine to the CLEANUP_WAIT state. 11982 9.Connection state timeout happens if a connection spends more time 11983 than agreed upon during Login negotiation in the CLEANUP_WAIT state, 11984 and this takes the connection to the FREE state (M1 transition in 11985 connection cleanup state diagram). 11987 10.These are defined in Section 4.3.5 Session reinstatement, closure 11988 and timeout. 11990 11.This clearing effect is however "Y" only if it is a connection 11991 reinstatement and the operational ErrorRecoveryLevel is less than 2. 11993 12.Session continuation is as defined in Section 4.3.6 Session con- 11994 tinuation and failure. 11996 13.This clearing effect is valid only if the connection is being 11997 logged-out on a different connection and when the connection being 11998 logged out on the target may have some partial PDUs pending to be 11999 sent. In all other cases, the effect is "NA". 12001 14.This clearing effect is valid only for a "close the session" 12002 logout in a multi-connection session. In all other cases, the effect 12003 is "NA". 12005 Julian Satran Expires February 2003 277 12006 iSCSI 5-August-02 12008 15.Applicable only if this leading connection login is a session 12009 reinstatement. If that is not the case, this is "NA". 12011 16.This operation affects all logged-in initiators. 12013 18.Session failure is as defined in Section 4.3.6 Session continua- 12014 tion and failure. 12016 19.This operation affects all logged-in initiators and the clearing 12017 effects are only applicable to the LU being reset. 12019 Julian Satran Expires February 2003 278 12020 iSCSI 5-August-02 12022 +-----+-----+-----+-----+-----+ 12023 |DC(1)|DD(2)|SS(3)|CS(4)|DS(5)| 12024 +---------------------+-----+-----+-----+-----+-----+ 12025 |connection failure |N |Y |N |N |N | 12026 +---------------------+-----+-----+-----+-----+-----+ 12027 |connection state |Y |NA |Y |N |NA | 12028 |timeout | | | | | | 12029 +---------------------+-----+-----+-----+-----+-----+ 12030 |session timeout/ |Y |Y |Y(7) |Y |NA | 12031 |closure/reinstatement| | | | | | 12032 +---------------------+-----+-----+-----+-----+-----+ 12033 |session continuation |N(11)|NA*12|NA |N |NA*13| 12034 +---------------------+-----+-----+-----+-----+-----+ 12035 |successful connection|Y |Y |Y |N |NA | 12036 |close Logout | | | | | | 12037 +---------------------+-----+-----+-----+-----+-----+ 12038 |session failure |N |Y |N |N |N | 12039 +---------------------+-----+-----+-----+-----+-----+ 12040 |successful recovery |Y |Y |Y |N |N | 12041 |Logout | | | | | | 12042 +---------------------+-----+-----+-----+-----+-----+ 12043 |failed Logout |N |Y(9) |N |N |N | 12044 +---------------------+-----+-----+-----+-----+-----+ 12045 |connection Login |NA |NA |N(8) |N(8) |NA | 12046 |(leading | | | | | | 12047 +---------------------+-----+-----+-----+-----+-----+ 12048 |connection Login |N(11)|NA*12|N(8) |N |NA*13| 12049 |(non-leading) | | | | | | 12050 +---------------------+-----+-----+-----+-----+-----+ 12051 |target cold reset |Y |Y |Y |Y(10)|NA | 12052 +---------------------+-----+-----+-----+-----+-----+ 12053 |target warm reset |Y |Y |N |N |NA | 12054 +---------------------+-----+-----+-----+-----+-----+ 12055 |LU reset |N |Y |N |N |N | 12056 +---------------------+-----+-----+-----+-----+-----+ 12057 |powercycle |Y |Y |Y |Y(10)|NA | 12058 +---------------------+-----+-----+-----+-----+-----+ 12060 1.Discontiguous Commands - commands allegiant to the connection in 12061 question and waiting to be reordered in the iSCSI layer. All "Y"s in 12062 this column assume that the task causing the event (if indeed the 12063 event is the result of a task) is issued as an immediate command, 12064 because the discontiguities can be ahead of the task. 12066 Julian Satran Expires February 2003 279 12067 iSCSI 5-August-02 12069 2.Discontiguous Data - data PDUs received for the task in question 12070 and waiting to be reordered due to prior discontiguities in DataSN. 12072 3.StatSN 12074 4.CmdSN 12076 5.DataSN 12078 7.It clears the StatSN on all the connections. 12080 8.This sequence number is instantiated on this event. 12082 9.A logout failure drives the connection state machine to the 12083 CLEANUP_WAIT state, similar to the connection failure event. Hence, 12084 it has a similar effect on this and several other protocol aspects. 12086 10.This is cleared by virtue of the fact that all sessions with all 12087 initiators are terminated. 12089 11.This clearing effect is "Y" if it is a connection reinstatement. 12091 12.This clearing effect is "Y" only if it is a connection reinstate- 12092 ment and the operational ErrorRecoveryLevel is 2. 12094 13.This clearing effect is "N" only if it is a connection reinstate- 12095 ment and the operational ErrorRecoveryLevel is 2. 12097 F.2 Clearing effects on SCSI objects 12099 The only iSCSI protocol action that can effect clearing actions on 12100 SCSI objects is the "I_T nexus loss" notification (Section 4.3.5.1 12101 Loss of Nexus notification). [SPC3] describes the clearing effects of 12102 this notification on a variety of SCSI attributes. In addition, SCSI 12103 standards documents (such as [SAM2] and [SBC]) define additional 12104 clearing actions that may take place for several SCSI objects on SCSI 12105 events such as LU resets and power-on resets. 12107 Note that because iSCSI defines target cold reset as protocol-equiva- 12108 lent to a target power-cycle, the iSCSI target cold reset must also 12109 be considered as the power-on reset event in interpreting the actions 12110 defined in the SCSI standards. 12112 Julian Satran Expires February 2003 280 12113 iSCSI 5-August-02 12115 When the iSCSI session is reconstructed (thus between the same SCSI 12116 ports with the same nexus identifier) establishing the same I_T nexus 12117 again, all SCSI objects that are defined to not clear on the "I_T 12118 nexus loss" notification event, such as persistent reservations, are 12119 automatically associated to this new session. 12121 Julian Satran Expires February 2003 281 12122 iSCSI 5-August-02 12124 Full Copyright Statement 12126 "Copyright (C) The Internet Society (date). All Rights Reserved. This 12127 document and translations of it may be copied and furnished to oth- 12128 ers, and derivative works that comment on or otherwise explain it or 12129 assist in its implementation may be prepared, copied, published and 12130 distributed, in whole or in part, without restriction of any kind, 12131 provided that the above copyright notice and this paragraph are 12132 included on all such copies and derivative works. However, this docu- 12133 ment itself may not be modified in any way, such as by removing the 12134 copyright notice or references to the Internet Society or other 12135 Internet organizations, except as needed for the purpose of develop- 12136 ing Internet standards in which case the procedures for copyrights 12137 defined in the Internet Standards process must be followed, or as 12138 required to translate it into languages other than English. 12140 The limited permissions granted above are perpetual and will not be 12141 revoked by the Internet Society or its successors or assigns. 12143 This document and the information contained herein is provided on an 12144 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 12145 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 12146 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 12147 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 12148 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 12150 The IETF has been notified of intellectual property rights claimed in 12151 regard to some or all of the specification contained in this docu- 12152 ment. For more information consult the online list of claimed rights. 12154 Julian Satran Expires February 2003 282