Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3720

Internet Small Computer Systems Interface (iSCSI)

Pages: 257
Obsoleted by:  7143
Updated by:  3980485050487146
Part 3 of 9 – Pages 42 to 67
First   Prev   Next

ToP   noToC   RFC3720 - Page 42   prevText

3.5. Request/Response Summary

This section lists and briefly describes all the iSCSI PDU types (request and responses). All iSCSI PDUs are built as a set of one or more header segments (basic and auxiliary) and zero or one data segments. The header group and the data segment may each be followed by a CRC (digest). The basic header segment has a fixed length of 48 bytes.
ToP   noToC   RFC3720 - Page 43

3.5.1. Request/Response Types Carrying SCSI Payload

3.5.1.1. SCSI-Command
This request carries the SCSI CDB and all the other SCSI execute command procedure call (see [SAM2]) IN arguments such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and Task Tag (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the initiator and target from the LUN field in the request and the I_T nexus is implicit in the session identification. In addition, the SCSI-command PDU carries information required for the proper operation of the iSCSI protocol - the command sequence number (CmdSN) for the session and the expected status number (ExpStatSN) for the connection. All or part of the SCSI output (write) data associated with the SCSI command may be sent as part of the SCSI-Command PDU as a data segment.
3.5.1.2. SCSI-Response
The SCSI-Response carries all the SCSI execute-command procedure call (see [SAM2]) OUT arguments and the SCSI execute-command procedure call return value. The SCSI-Response contains the residual counts from the operation, if any, an indication of whether the counts represent an overflow or an underflow, and the SCSI status if the status is valid or a response code (a non-zero return value for the execute-command procedure call) if the status is not valid. For a valid status that indicates that the command has been processed, but resulted in an exception (e.g., a SCSI CHECK CONDITION), the PDU data segment contains the associated sense data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI. Some data segment content may also be associated (in the data segment) with a non-zero response code. In addition, the SCSI-Response PDU carries information required for the proper operation of the iSCSI protocol: - The number of Data-In PDUs that a target has sent (to enable the initiator to check that all have arrived). - StatSN - the Status Sequence Number on this connection.
ToP   noToC   RFC3720 - Page 44
     - ExpCmdSN - the next Expected Command Sequence Number at the
       target.
     - MaxCmdSN - the maximum CmdSN acceptable at the target from
       this initiator.

3.5.1.3 Task Management Function Request
The Task Management function request provides an initiator with a way to explicitly control the execution of one or more SCSI Tasks or iSCSI functions. The PDU carries a function identifier (which task management function to perform) and enough information to unequivocally identify the task or task-set on which to perform the action, even if the task(s) to act upon has not yet arrived or has been discarded due to an error. The referenced tag identifies an individual task if the function refers to an individual task. The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is identified by the LUN and the session identification (the session identifies an I_T nexus). For task sets, the CmdSN of the Task Management function request helps identify the tasks upon which to act, namely all tasks associated with a LUN and having a CmdSN preceding the Task Management function request CmdSN. For a Task Management function, the coordination between responses to the tasks affected and the Task Management function response is done by the target.
3.5.1.4. Task Management Function Response
The Task Management function response carries an indication of function completion for a Task Management function request including how it was completed (response and qualifier) and additional information for failure responses. After the Task Management response indicates Task Management function completion, the initiator will not receive any additional responses from the affected tasks.
3.5.1.5. SCSI Data-Out and SCSI Data-In
SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI data payload is carried between initiator and target. Data payload is associated with a specific SCSI command through the Initiator Task Tag. For target convenience, outgoing solicited data also carries a
ToP   noToC   RFC3720 - Page 45
   Target Transfer Tag (copied from R2T) and the LUN.  Each PDU contains
   the payload length and the data offset relative to the buffer address
   contained in the SCSI execute command procedure call.

   In each direction, the data transfer is split into "sequences".  An
   end-of-sequence is indicated by the F bit.

   An outgoing sequence is either unsolicited (only the first sequence
   can be unsolicited) or consists of all the Data-Out PDUs sent in
   response to an R2T.

   Input sequences are built to enable the direction switching for
   bidirectional commands.

   For input, the target may request positive acknowledgement of input
   data.  This is limited to sessions that support error recovery and is
   implemented through the A bit in the SCSI Data-In PDU header.

   Data-In and Data-Out PDUs also carry the DataSN to enable the
   initiator and target to detect missing PDUs (discarded due to an
   error).

   In addition, StatSN is carried by the Data-In PDUs.

   To enable a SCSI command to be processed while involving a minimum
   number of messages, the last SCSI Data-In PDU passed for a command
   may also contain the status if the status indicates termination with
   no exceptions (no sense or response involved).

3.5.1.6. Ready To Transfer (R2T)
R2T is the mechanism by which the SCSI target "requests" the initiator for output data. R2T specifies to the initiator the offset of the requested data relative to the buffer address from the execute command procedure call and the length of the solicited data. To help the SCSI target associate the resulting Data-Out with an R2T, the R2T carries a Target Transfer Tag that will be copied by the initiator in the solicited SCSI Data-Out PDUs. There are no protocol specific requirements with regard to the value of these tags, but it is assumed that together with the LUN, they will enable the target to associate data with an R2T.
ToP   noToC   RFC3720 - Page 46
   R2T also carries information required for proper operation of the
   iSCSI protocol, such as:

     - R2TSN (to enable an initiator to detect a missing R2T)
     - StatSN
     - ExpCmdSN
     - MaxCmdSN

3.5.2. Requests/Responses carrying SCSI and iSCSI Payload

3.5.2.1. Asynchronous Message
Asynchronous Messages are used to carry SCSI asynchronous events (AEN) and iSCSI asynchronous messages. When carrying an AEN, the event details are reported as sense data in the data segment.

3.5.3. Requests/Responses Carrying iSCSI Only Payload

3.5.3.1. Text Request and Text Response
Text requests and responses are designed as a parameter negotiation vehicle and as a vehicle for future extension. In the data segment, Text Requests/Responses carry text information using a simple "key=value" syntax. Text Request/Responses may form extended sequences using the same Initiator Task Tag. The initiator uses the F (Final) flag bit in the text request header to indicate its readiness to terminate a sequence. The target uses the F (Final) flag bit in the text response header to indicate its consent to sequence termination. Text Request and Responses also use the Target Transfer Tag to indicate continuation of an operation or a new beginning. A target that wishes to continue an operation will set the Target Transfer Tag in a Text Response to a value different from the default 0xffffffff. An initiator willing to continue will copy this value into the Target Transfer Tag of the next Text Request. If the initiator wants to restart the current target negotiation (start fresh) will set the Target Transfer Tag to 0xffffffff. Although a complete exchange is always started by the initiator, specific parameter negotiations may be initiated by the initiator or target.
ToP   noToC   RFC3720 - Page 47
3.5.3.2. Login Request and Login Response
Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters. (The Login Phase consists of a sequence of login requests and responses carrying the same Initiator Task Tag.) A connection is identified by an arbitrarily selected connection-ID (CID) that is unique within a session. Similar to the Text Requests and Responses, Login Requests/Responses carry key=value text information with a simple syntax in the data segment. The Login Phase proceeds through several stages (security negotiation, operational parameter negotiation) that are selected with two binary coded fields in the header -- the "current stage" (CSG) and the "next stage" (NSG) with the appearance of the latter being signaled by the "transit" flag (T). The first Login Phase of a session plays a special role, called the leading login, which determines some header fields (e.g., the version number, the maximum number of connections, and the session identification). The CmdSN initial value is also set by the leading login. StatSN for each connection is initiated by the connection login. A login request may indicate an implied logout (cleanup) of the connection to be logged in (a connection restart) by using the same Connection ID (CID) as an existing connection, as well as the same session identifying elements of the session to which the old connection was associated.
3.5.3.3. Logout Request and Response
Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance. The logout request may be issued following a target prompt (through an asynchronous message) or at an initiators initiative. When issued on the connection to be logged out, no other request may follow it. The Logout Response indicates that the connection or session cleanup is completed and no other responses will arrive on the connection (if received on the logging out connection). In addition, the Logout Response indicates how long the target will continue to hold resources for recovery (e.g., command execution that continues on a
ToP   noToC   RFC3720 - Page 48
   new connection) in the text key Time2Retain and how long the
   initiator must wait before proceeding with recovery in the text key
   Time2Wait.

3.5.3.4. SNACK Request
With the SNACK Request, the initiator requests retransmission of numbered-responses or data from the target. A single SNACK request covers a contiguous set of missing items, called a run, of a given type of items. The type is indicated in a type field in the PDU header. The run is composed of an initial item (StatSN, DataSN, R2TSN) and the number of missed Status, Data, or R2T PDUs. For long Data-In sequences, the target may request (at predefined minimum intervals) a positive acknowledgement for the data sent. A SNACK request with a type field that indicates ACK and the number of Data-In PDUs acknowledged conveys this positive acknowledgement.
3.5.3.5. Reject
Reject enables the target to report an iSCSI error condition (e.g., protocol, unsupported option) that uses a Reason field in the PDU header and includes the complete header of the bad PDU in the Reject PDU data segment.
3.5.3.6. NOP-Out Request and NOP-In Response
This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational. Such a ping may be triggered by the initiator or target. The triggering party indicates that it wants a reply by setting a value different from the default 0xffffffff in the corresponding Initiator/Target Transfer Tag. NOP-In/NOP-Out may also be used "unidirectional" to convey to the initiator/target command, status or data counter values when there is no other "carrier" and there is a need to update the initiator/ target.

4. SCSI Mode Parameters for iSCSI

There are no iSCSI specific mode pages.

5. Login and Full Feature Phase Negotiation

iSCSI parameters are negotiated at session or connection establishment by using Login Requests and Responses (see Section 3.2.3 iSCSI Login) and during the Full Feature Phase (Section 3.2.4 iSCSI Full Feature Phase) by using Text Requests and Responses. In
ToP   noToC   RFC3720 - Page 49
   both cases the mechanism used is an exchange of iSCSI-text-key=value
   pairs.  For brevity iSCSI-text-keys are called just keys in the rest
   of this document.

   Keys are either declarative or require negotiation and the key
   description indicates if the key is declarative or requires
   negotiation.

   For the declarative keys, the declaring party sets a value for the
   key.  The key specification indicates if the key can be declared by
   the initiator, target or both.

   For the keys that require negotiation one of the parties (the
   proposing party) proposes a value or set of values by including the
   key=value in the data part of a Login or Text Request or Response
   PDUs.  The other party (the accepting party) makes a selection based
   on the value or list of values proposed and includes the selected
   value in a key=value in the data part of one of the following Login
   or Text Response or Request PDUs.  For most of the keys both the
   initiator and target can be proposing parties.

   The login process proceeds in two stages - the security negotiation
   stage and the operational parameter negotiation stage.  Both stages
   are optional but at least one of them has to be present to enable the
   setting of some mandatory parameters.

   If present, the security negotiation stage precedes the operational
   parameter negotiation stage.

   Progression from stage to stage is controlled by the T (Transition)
   bit in the Login Request/Response PDU header.  Through the T bit set
   to 1, the initiator indicates that it would like to transition.  The
   target agrees to the transition (and selects the next stage) when
   ready.  A field in the Login PDU header indicates the current stage
   (CSG) and during transition, another field indicates the next stage
   (NSG) proposed (initiator) and selected (target).

   The text negotiation process is used to negotiate or declare
   operational parameters.  The negotiation process is controlled by the
   F (final) bit in the PDU header.  During text negotiations, the F bit
   is used by the initiator to indicate that it is ready to finish the
   negotiation and by the Target to acquiesce the end of negotiation.

   Since some key=value pairs may not fit entirely in a single PDU, the
   C (continuation) bit is used (both in Login and Text) to indicate
   that "more follows".
ToP   noToC   RFC3720 - Page 50
   The text negotiation uses an additional mechanism by which a target
   may deliver larger amounts of data to an enquiring initiator.  The
   target sets a Target Task Tag to be used as a bookmark that when
   returned by the initiator, means "go on".  If reset to a "neutral
   value", it means "forget about the rest".

   This chapter details types of keys and values used, the syntax rules
   for parameter formation, and the negotiation schemes to be used with
   different types of parameters.

5.1. Text Format

The initiator and target send a set of key=value pairs encoded in UTF-8 Unicode. All the text keys and text values specified in this document are to be presented and interpreted in the case in which they appear in this document. They are case sensitive. The following character symbols are used in this document for text items (the hexadecimal values represent Unicode code points): (a-z, A-Z) - letters (0-9) - digits " " (0x20) - space "." (0x2e) - dot "-" (0x2d) - minus "+" (0x2b) - plus "@" (0x40) - commercial at "_" (0x5f) - underscore "=" (0x3d) - equal ":" (0x3a) - colon "/" (0x2f) - solidus or slash "[" (0x5b) - left bracket "]" (0x5d) - right bracket null (0x00) - null separator "," (0x2c) - comma "~" (0x7e) - tilde Key=value pairs may span PDU boundaries. An initiator or target that sends partial key=value text within a PDU indicates that more text follows by setting the C bit in the Text or Login Request or Text or Login Response to 1. Data segments in a series of PDUs that have the C bit set to 1 and end with a PDU that have the C bit set to 0, or include a single PDU that has the C bit set to 0, have to be considered as forming a single logical-text-data-segment (LTDS). Every key=value pair, including the last or only pair in a LTDS, MUST be followed by one null (0x00) delimiter.
ToP   noToC   RFC3720 - Page 51
   A key-name is whatever precedes the first "=" in the key=value pair.
   The term key is used frequently in this document in place of
   key-name.

   A value is whatever follows the first "=" in the key=value pair up to
   the end of the key=value pair, but not including the null delimiter.

   The following definitions will be used in the rest of this document:

     standard-label: A string of one or more characters that consist of
       letters, digits, dot, minus, plus, commercial at, or underscore.
       A standard-label MUST begin with a capital letter and must not
       exceed 63 characters.

     key-name: A standard-label.

     text-value: A string of zero or more characters that consist of
       letters, digits, dot, minus, plus, commercial at, underscore,
       slash, left bracket, right bracket, or colon.

     iSCSI-name-value: A string of one or more characters that consist
       of minus, dot, colon, or any character allowed by the output of
       the iSCSI string-prep template as specified in [RFC3722] (see
       also Section 3.2.6.2 iSCSI Name Encoding).

     iSCSI-local-name-value: A UTF-8 string; no null characters are
       allowed in the string.  This encoding is to be used for localized
       (internationalized) aliases.

     boolean-value: The string "Yes" or "No".

     hex-constant: A hexadecimal constant encoded as a string that
       starts with "0x" or "0X" followed by one or more digits or the
       letters a, b, c, d, e, f, A, B, C, D, E, or F.  Hex-constants are
       used to encode numerical values or binary strings.  When used to
       encode numerical values, the excessive use of leading 0 digits is
       discouraged.  The string following 0X (or 0x) represents a base16
       number that starts with the most significant base16 digit,
       followed by all other digits in decreasing order of significance
       and ending with the least-significant base16 digit.  When used to
       encode binary strings, hexadecimal constants have an implicit
       byte-length that includes four bits for every hexadecimal digit
       of the constant, including leading zeroes.  For example, a
       hex-constant of n hexadecimal digits has a byte-length of (the
       integer part of) (n+1)/2.
ToP   noToC   RFC3720 - Page 52
     decimal-constant: An unsigned decimal number with the digit 0 or a
       string of one or more digits that start with a non-zero digit.
       Decimal-constants are used to encode numerical values or binary
       strings.  Decimal constants can only be used to encode binary
       strings if the string length is explicitly specified.  There is
       no implicit length for decimal strings.  Decimal-constant MUST
       NOT be used for parameter values if the values can be equal or
       greater than 2**64 (numerical) or for binary strings that can be
       longer than 64 bits.

     base64-constant: base64 constant encoded as a string that starts
       with "0b" or "0B" followed by 1 or more digits or letters or plus
       or slash or equal.  The encoding is done according to [RFC2045]
       and each character, except equal, represents a base64 digit or a
       6-bit binary string.  Base64-constants are used to encode
       numerical-values or binary strings.  When used to encode
       numerical values, the excessive use of leading 0 digits (encoded
       as A) is discouraged.  The string following 0B (or 0b) represents
       a base64 number that starts with the most significant base64
       digit, followed by all other digits in decreasing order of
       significance and ending with the least-significant base64 digit;
       the least significant base64 digit may be optionally followed by
       pad digits (encoded as equal) that are not considered as part of
       the number.  When used to encode binary strings, base64-constants
       have an implicit
       byte-length that includes six bits for every character of the
       constant, excluding trailing equals (i.e., a base64-constant of n
       base64 characters excluding the trailing equals has a byte-length
       of ((the integer part of) (n*3/4)).  Correctly encoded base64
       strings cannot have n values of 1, 5 ... k*4+1.

     numerical-value: An unsigned integer always less than 2**64 encoded
       as a decimal-constant or a hex-constant.  Unsigned integer
       arithmetic applies to numerical-values.

     large-numerical-value: An unsigned integer that can be larger than
       or equal to 2**64 encoded as a hex constant, or
       base64-constant.  Unsigned integer arithmetic applies to
       large-numeric-values.

     numeric-range: Two numerical-values separated by a tilde where the
       value to the right of tilde must not be lower than the value to
       the left.

     regular-binary-value: A binary string not longer than 64 bits
       encoded as a decimal constant, hex constant, or base64-constant.
       The length of the string is either specified by the key
       definition or is the implicit byte-length of the encoded string.
ToP   noToC   RFC3720 - Page 53
     large-binary-value: A binary string longer than 64 bits encoded as
       a hex-constant or base64-constant.  The length of the string is
       either specified by the key definition or is the implicit
       byte-length of the encoded string.

     binary-value: A regular-binary-value or a large-binary-value.
       Operations on binary values are key specific.

     simple-value: Text-value, iSCSI-name-value, boolean-value,
       numeric-value, a numeric-range, or a binary-value.

     list-of-values: A sequence of text-values separated by a comma.

   If not otherwise specified, the maximum length of a simple-value (not
   its encoded representation) is 255 bytes, not including the delimiter
   (comma or zero byte).

   Any iSCSI target or initiator MUST support receiving at least 8192
   bytes of key=value data in a negotiation sequence.  When proposing or
   accepting authentication methods that explicitly require support for
   very long authentication items, the initiator and target MUST support
   receiving of at least 64 kilobytes of key=value data (see Appendix
   11.1.2 - Simple Public-Key Mechanism (SPKM) - that require support
   for public key certificates).

5.2. Text Mode Negotiation

During login, and thereafter, some session or connection parameters are either declared or negotiated through an exchange of textual information. The initiator starts the negotiation and/or declaration through a Text or Login Request and indicates when it is ready for completion (by setting the F bit to 1 and keeping it to 1 in a Text Request or the T bit in the Login Request). As negotiation text may span PDU boundaries, a Text or Login Request or Text or Login Response PDU that has the C bit set to 1 MUST NOT have the F/T bit set to 1. A target receiving a Text or Login Request with the C bit set to 1 MUST answer with a Text or Login Response with no data segment (DataSegmentLength 0). An initiator receiving a Text or Login Response with the C bit set to 1 MUST answer with a Text or Login Request with no data segment (DataSegmentLength 0). A target or initiator SHOULD NOT use a Text or Login Response or Text or Login Request with no data segment (DataSegmentLength 0) unless explicitly required by a general or a key-specific negotiation rule.
ToP   noToC   RFC3720 - Page 54
   The format of a declaration is:

     Declarer-> <key>=<valuex>

   The general format of text negotiation is:

     Proposer-> <key>=<valuex>
     Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}

   Thus a declaration is a one-way textual exchange while a negotiation
   is a two-way exchange.

   The proposer or declarer can either be the initiator or the target,
   and the acceptor can either be the target or initiator, respectively.
   Targets are not limited to respond to key=value pairs as proposed by
   the initiator.  The target may propose key=value pairs of its own.

   All negotiations are explicit (i.e., the result MUST only be based on
   newly exchanged or declared values).  There are no implicit
   proposals.  If a proposal is not made, then a reply cannot be
   expected.  Conservative design also requires that default values
   should not be relied upon when use of some other value has serious
   consequences.

   The value proposed or declared can be a numerical-value, a
   numerical-range defined by lower and upper values with both integers
   separated by a tilde, a binary value, a text-value, an
   iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or
   No), or a list of comma separated text-values.  A range, a
   large-numerical-value, an iSCSI-name-value and an
   iSCSI-local-name-value MAY ONLY be used if it is explicitly allowed.
   An accepted value can be a numerical-value, a large-numerical-value,
   a text-value, or a boolean-value.

   If a specific key is not relevant for the current negotiation, the
   acceptor may answer with the constant "Irrelevant" for all types of
   negotiation.  However the negotiation is not considered as failed if
   the answer is "Irrelevant".  The "Irrelevant" answer is meant for
   those cases in which several keys are presented by a proposing party
   but the selection made by the acceptor for one of the keys makes
   other keys irrelevant.  The following example illustrates the use of
   "Irrelevant":

   I->T OFMarker=Yes,OFMarkInt=2048~8192
   T->I OFMarker=No,OFMarkInt=Irrelevant

   I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb)
   T->I X#vkey1=None,X#vkey2=Irrelevant
ToP   noToC   RFC3720 - Page 55
   Any key not understood by the acceptor may be ignored by the acceptor
   without affecting the basic function.  However, the answer for a key
   not understood MUST be key=NotUnderstood.

   The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
   reserved and MUST ONLY be used as described here.  Violation of this
   rule is a protocol error (in particular the use of "Reject",
   "Irrelevant", and "NotUnderstood" as proposed values).

   Reject or Irrelevant are legitimate negotiation options where allowed
   but their excessive use is discouraged.  A negotiation is considered
   complete when the acceptor has sent the key value pair even if the
   value is "Reject", "Irrelevant", or "NotUnderstood.  Sending the key
   again would be a re-negotiation and is forbidden for many keys.

   If the acceptor sends "Reject" as an answer the negotiated key is
   left at its current value (or default if no value was set).  If the
   current value is not acceptable to the proposer on the connection or
   to the session it is sent, the proposer MAY choose to terminate the
   connection or session.

   All keys in this document, except for the X extension formats, MUST
   be supported by iSCSI initiators and targets when used as specified
   here.  If used as specified, these keys MUST NOT be answered with
   NotUnderstood.

   Implementers may introduce new keys by prefixing them with
   "X-", followed by their (reversed) domain name, or with new keys
   registered with IANA prefixing them with X#.  For example, the entity
   owning the domain example.com can issue:

         X-com.example.bar.foo.do_something=3

   or a new registered key may be used as in:

         X#SuperCalyPhraGilistic=Yes

   Implementers MAY also introduce new values, but ONLY for new keys or
   authentication methods (see Section 11 iSCSI Security Text Keys and
   Authentication Methods), or digests (see Section 12.1 HeaderDigest
   and DataDigest).

   Whenever parameter action or acceptance is dependent on other
   parameters, the dependency rules and parameter sequence must be
   specified with the parameters.
ToP   noToC   RFC3720 - Page 56
   In the Login Phase (see Section 5.3 Login Phase), every stage is a
   separate negotiation.  In the FullFeaturePhase, a Text Request
   Response sequence is a negotiation.  Negotiations MUST be handled as
   atomic operations.  For example, all negotiated values go into effect
   after the negotiation concludes in agreement or are ignored if the
   negotiation fails.

   Some parameters may be subject to integrity rules (e.g., parameter-x
   must not exceed parameter-y or parameter-u not 1 implies parameter-v
   be Yes).  Whenever required, integrity rules are specified with the
   keys.  Checking for compliance with the integrity rule must only be
   performed after all the parameters are available (the existent and
   the newly negotiated).  An iSCSI target MUST perform integrity
   checking before the new parameters take effect.  An initiator MAY
   perform integrity checking.

   An iSCSI initiator or target MAY terminate a negotiation that does
   not end within a reasonable time or number of exchanges.

5.2.1. List negotiations

In list negotiation, the originator sends a list of values (which may include "None") in its order of preference. The responding party MUST respond with the same key and the first value that it supports (and is allowed to use for the specific originator) selected from the originator list. The constant "None" MUST always be used to indicate a missing function. However, "None" is only a valid selection if it is explicitly proposed. If an acceptor does not understand any particular value in a list, it MUST ignore it. If an acceptor does not support, does not understand, or is not allowed to use any of the proposed options with a specific originator, it may use the constant "Reject" or terminate the negotiation. The selection of a value not proposed MUST be handled as a protocol error.

5.2.2. Simple-value Negotiations

For simple-value negotiations, the accepting party MUST answer with the same key. The value it selects becomes the negotiation result. Proposing a value not admissible (e.g., not within the specified bounds) MAY be answered with the constant "Reject" or the acceptor MAY select an admissible value.
ToP   noToC   RFC3720 - Page 57
   The selection by the acceptor, of a value not admissible under the
   selection rules is considered a protocol error.  The selection rules
   are key-specific.

   For a numerical range, the value selected must be an integer within
   the proposed range or "Reject" (if the range is unacceptable).

   In Boolean negotiations (i.e., those that result in keys taking the
   values Yes or No), the accepting party MUST answer with the same key
   and the result of the negotiation when the received value does not
   determine that result by itself.  The last value transmitted becomes
   the negotiation result.  The rules for selecting the value to answer
   with are expressed as Boolean functions of the value received, and
   the value that the accepting party would have selected if given a
   choice.

   Specifically, the two cases in which answers are OPTIONAL are:

      -  The Boolean function is "AND" and the value "No" is received.
         The outcome of the negotiation is "No".
      -  The Boolean function is "OR" and the value "Yes" is received.
         The outcome of the negotiation is "Yes".

   Responses are REQUIRED in all other cases, and the value chosen and
   sent by the acceptor becomes the outcome of the negotiation.

5.3. Login Phase

The Login Phase establishes an iSCSI connection between an initiator and a target; it also creates a new session or associates the connection to an existing session. The Login Phase sets the iSCSI protocol parameters, security parameters, and authenticates the initiator and target to each other. The Login Phase is only implemented via Login Request and Responses. The whole Login Phase is considered as a single task and has a single Initiator Task Tag (similar to the linked SCSI commands). The default MaxRecvDataSegmentLength is used during Login. The Login Phase sequence of requests and responses proceeds as follows: - Login initial request - Login partial response (optional) - More Login Requests and Responses (optional) - Login Final-Response (mandatory)
ToP   noToC   RFC3720 - Page 58
   The initial Login Request of any connection MUST include the
   InitiatorName key=value pair.  The initial Login Request of the first
   connection of a session MAY also include the SessionType key=value
   pair.  For any connection within a session whose type is not
   "Discovery", the first Login Request MUST also include the TargetName
   key=value pair.

   The Login Final-response accepts or rejects the Login Request.

   The Login Phase MAY include a SecurityNegotiation stage and a
   LoginOperationalNegotiation stage or both, but MUST include at least
   one of them.  The included stage MAY be empty except for the
   mandatory names.

   The Login Requests and Responses contain a field (CSG) that indicates
   the current negotiation stage (SecurityNegotiation or
   LoginOperationalNegotiation).  If both stages are used, the
   SecurityNegotiation MUST precede the LoginOperationalNegotiation.

   Some operational parameters can be negotiated outside the login
   through Text Requests and Responses.

   Security MUST be completely negotiated within the Login Phase.  The
   use of underlying IPsec security is specified in Chapter 8 and in
   [RFC3723].  iSCSI support for security within the protocol only
   consists of authentication in the Login Phase.

   In some environments, a target or an initiator is not interested in
   authenticating its counterpart.  It is possible to bypass
   authentication through the Login Request and Response.

   The initiator and target MAY want to negotiate iSCSI authentication
   parameters.  Once this negotiation is completed, the channel is
   considered secure.

   Most of the negotiation keys are only allowed in a specific stage.
   The SecurityNegotiation keys appear in Chapter 11 and the
   LoginOperationalNegotiation keys appear in Chapter 12.  Only a
   limited set of keys (marked as Any-Stage in Chapter 12) may be used
   in any of the two stages.

   Any given Login Request or Response belongs to a specific stage; this
   determines the negotiation keys allowed with the request or response.
   It is considered to be a protocol error to send a key that is not
   allowed in the current stage.
ToP   noToC   RFC3720 - Page 59
   Stage transition is performed through a command exchange (request/
   response) that carries the T bit and the same CSG code.  During this
   exchange, the next stage is selected by the target through the "next
   stage" code (NSG).  The selected NSG MUST NOT exceed the value stated
   by the initiator.  The initiator can request a transition whenever it
   is ready, but a target can only respond with a transition after one
   is proposed by the initiator.

   In a negotiation sequence, the T bit settings in one pair of Login
   Request-Responses have no bearing on the T bit settings of the next
   pair.  An initiator that has a T bit set to 1 in one pair and is
   answered with a T bit setting of 0, may issue the next request with
   the T bit set to 0.

   When a transition is requested by the initiator and acknowledged by
   the target, both the initiator and target switch to the selected
   stage.

   Targets MUST NOT submit parameters that require an additional
   initiator Login Request in a Login Response with the T bit set to 1.

   Stage transitions during login (including entering and exit) are only
   possible as outlined in the following table:

   +-----------------------------------------------------------+
   |From     To ->   | Security    | Operational | FullFeature |
   | |               |             |             |             |
   | V               |             |             |             |
   +-----------------------------------------------------------+
   | (start)         |  yes        |  yes        |  no         |
   +-----------------------------------------------------------+
   | Security        |  no         |  yes        |  yes        |
   +-----------------------------------------------------------+
   | Operational     |  no         |  no         |  yes        |
   +-----------------------------------------------------------+

   The Login Final-Response that accepts a Login Request can only come
   as a response to a Login Request with the T bit set to 1, and both
   the request and response MUST indicate FullFeaturePhase as the next
   phase via the NSG field.

   Neither the initiator nor the target should attempt to declare or
   negotiate a parameter more than once during login except for
   responses to specific keys that explicitly allow repeated key
   declarations (e.g., TargetAddress).  An attempt to
   renegotiate/redeclare parameters not specifically allowed MUST be
   detected by the initiator and target.  If such an attempt is detected
ToP   noToC   RFC3720 - Page 60
   by the target, the target MUST respond with Login reject (initiator
   error); if detected by the initiator, the initiator MUST drop the
   connection.

5.3.1. Login Phase Start

The Login Phase starts with a Login Request from the initiator to the target. The initial Login Request includes: - Protocol version supported by the initiator. - iSCSI Initiator Name and iSCSI Target Name - ISID, TSIH, and connection Ids - Negotiation stage that the initiator is ready to enter. A login may create a new session or it may add a connection to an existing session. Between a given iSCSI Initiator Node (selected only by an InitiatorName) and a given iSCSI target defined by an iSCSI TargetName and a Target Portal Group Tag, the login results are defined by the following table: +------------------------------------------------------------------+ |ISID | TSIH | CID | Target action | +------------------------------------------------------------------+ |new | non-zero | any | fail the login | | | | | ("session does not exist") | +------------------------------------------------------------------+ |new | zero | any | instantiate a new session | +------------------------------------------------------------------+ |existing | zero | any | do session reinstatement | | | | | (see section 5.3.5) | +------------------------------------------------------------------+ |existing | non-zero | new | add a new connection to | | | existing | | the session | +------------------------------------------------------------------+ |existing | non-zero |existing| do connection reinstatement| | | existing | | (see section 5.3.4) | +------------------------------------------------------------------+ |existing | non-zero | any | fail the login | | | new | | ("session does not exist") | +------------------------------------------------------------------+ Determination of "existing" or "new" are made by the target.
ToP   noToC   RFC3720 - Page 61
   Optionally, the Login Request may include:

      - Security parameters
      OR
      - iSCSI operational parameters
      AND/OR
      - The next negotiation stage that the initiator is ready to
      enter.

   The target can answer the login in the following ways:

     - Login Response with Login reject.  This is an immediate rejection
       from the target that causes the connection to terminate and the
       session to terminate if this is the first (or only) connection of
       a new session.  The T bit and the CSG and NSG fields are
       reserved.
     - Login Response with Login Accept as a final response (T bit set
       to 1 and the NSG in both request and response are set to
       FullFeaturePhase).  The response includes the protocol version
       supported by the target and the session ID, and may include iSCSI
       operational or security parameters (that depend on the current
       stage).
     - Login Response with Login Accept as a partial response (NSG not
       set to FullFeaturePhase in both request and response) that
       indicates the start of a negotiation sequence.  The response
       includes the protocol version supported by the target and either
       security or iSCSI parameters (when no security mechanism is
       chosen) supported by the target.

   If the initiator decides to forego the SecurityNegotiation stage, it
   issues the Login with the CSG set to LoginOperationalNegotiation and
   the target may reply with a Login Response that indicates that it is
   unwilling to accept the connection (see Section 10.13 Login Response)
   without SecurityNegotiation and will terminate the connection with a
   response of Authentication failure (see Section 10.13.5 Status-Class
   and Status-Detail).

   If the initiator is willing to negotiate iSCSI security, but is
   unwilling to make the initial parameter proposal and may accept a
   connection without iSCSI security, it issues the Login with the T bit
   set to 1, the CSG set to SecurityNegotiation, and the NSG set to
   LoginOperationalNegotiation.  If the target is also ready to skip
   security, the Login Response only contains the TargetPortalGroupTag
   key (see Section 12.9 TargetPortalGroupTag), the T bit set to 1, the
   CSG set to SecurityNegotiation, and the NSG set to
   LoginOperationalNegotiation.
ToP   noToC   RFC3720 - Page 62
   An initiator that chooses to operate without iSCSI security, with all
   the operational parameters taking the default values, issues the
   Login with the T bit set to 1, the CSG set to
   LoginOperationalNegotiation, and the NSG set to FullFeaturePhase.  If
   the target is also ready to forego security and can finish its
   LoginOperationalNegotiation, the Login Response has T bit set to 1,
   the CSG set to LoginOperationalNegotiation, and the NSG set to
   FullFeaturePhase in the next stage.

   During the Login Phase the iSCSI target MUST return the
   TargetPortalGroupTag key with the first Login Response PDU with which
   it is allowed to do so (i.e., the first Login Response issued after
   the first Login Request with the C bit set to 0) for all session
   types when TargetName is given and the response is not a redirection.
   The TargetPortalGroupTag key value indicates the iSCSI portal group
   servicing the Login Request PDU.  If the reconfiguration of iSCSI
   portal groups is a concern in a given environment, the iSCSI
   initiator should use this key to ascertain that it had indeed
   initiated the Login Phase with the intended target portal group.

5.3.2. iSCSI Security Negotiation

The security exchange sets the security mechanism and authenticates the initiator user and the target to each other. The exchange proceeds according to the authentication method chosen in the negotiation phase and is conducted using the Login Requests' and responses' key=value parameters. An initiator directed negotiation proceeds as follows: - The initiator sends a Login Request with an ordered list of the options it supports (authentication algorithm). The options are listed in the initiator's order of preference. The initiator MAY also send private or public extension options. - The target MUST reply with the first option in the list it supports and is allowed to use for the specific initiator unless it does not support any, in which case it MUST answer with "Reject" (see Section 5.2 Text Mode Negotiation). The parameters are encoded in UTF8 as key=value. For security parameters, see Chapter 11. - When the initiator considers that it is ready to conclude the SecurityNegotiation stage, it sets the T bit to 1 and the NSG to what it would like the next stage to be. The target will then set the T bit to 1 and set the NSG to the next stage in the Login Response when it finishes sending its security keys. The next
ToP   noToC   RFC3720 - Page 63
       stage selected will be the one the target selected.  If the next
       stage is FullFeaturePhase, the target MUST respond with a Login
       Response with the TSIH value.

   If the security negotiation fails at the target, then the target MUST
   send the appropriate Login Response PDU.  If the security negotiation
   fails at the initiator, the initiator SHOULD close the connection.

   It should be noted that the negotiation might also be directed by the
   target if the initiator does support security, but is not ready to
   direct the negotiation (propose options).

5.3.3. Operational Parameter Negotiation During the Login Phase

Operational parameter negotiation during the login MAY be done: - Starting with the first Login Request if the initiator does not propose any security/integrity option. - Starting immediately after the security negotiation if the initiator and target perform such a negotiation. Operational parameter negotiation MAY involve several Login Request-Response exchanges started and terminated by the initiator. The initiator MUST indicate its intent to terminate the negotiation by setting the T bit to 1; the target sets the T bit to 1 on the last response. If the target responds to a Login Request that has the T bit set to 1 with a Login Response that has the T bit set to 0, the initiator should keep sending the Login Request (even empty) with the T bit set to 1, while it still wants to switch stage, until it receives the Login Response that has the T bit set to 1 or it receives a key that requires it to set the T bit to 0. Some session specific parameters can only be specified during the Login Phase of the first connection of a session (i.e., begun by a Login Request that contains a zero-valued TSIH) - the leading Login Phase (e.g., the maximum number of connections that can be used for this session). A session is operational once it has at least one connection in FullFeaturePhase. New or replacement connections can only be added to a session after the session is operational. For operational parameters, see Chapter 12.
ToP   noToC   RFC3720 - Page 64

5.3.4. Connection Reinstatement

Connection reinstatement is the process of an initiator logging in with an ISID-TSIH-CID combination that is possibly active from the target's perspective, which causes the implicit logging out of the connection corresponding to the CID, and reinstating a new Full Feature Phase iSCSI connection in its place (with the same CID). Thus, the TSIH in the Login PDU MUST be non-zero and the CID does not change during a connection reinstatement. The Login Request performs the logout function of the old connection if an explicit logout was not performed earlier. In sessions with a single connection, this may imply the opening of a second connection with the sole purpose of cleaning up the first. Targets MUST support opening a second connection even when they do not support multiple connections in Full Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a second connection if ErrorRecoveryLevel is less than 2. If the operational ErrorRecoveryLevel is 2, connection reinstatement enables future task reassignment. If the operational ErrorRecoveryLevel is less than 2, connection reinstatement is the replacement of the old CID without enabling task reassignment. In this case, all the tasks that were active on the old CID must be immediately terminated without further notice to the initiator. The initiator connection state MUST be CLEANUP_WAIT (section 7.1.3) when the initiator attempts a connection reinstatement. In practical terms, in addition to the implicit logout of the old connection, reinstatement is equivalent to a new connection login.

5.3.5. Session Reinstatement, Closure, and Timeout

Session reinstatement is the process of the initiator logging in with an ISID that is possibly active from the target's perspective. Thus implicitly logging out the session that corresponds to the ISID and reinstating a new iSCSI session in its place (with the same ISID). Therefore, the TSIH in the Login PDU MUST be zero to signal session reinstatement. Session reinstatement causes all the tasks that were active on the old session to be immediately terminated by the target without further notice to the initiator. The initiator session state MUST be FAILED (Section 7.3 Session State Diagrams) when the initiator attempts a session reinstatement.
ToP   noToC   RFC3720 - Page 65
   Session closure is an event defined to be one of the following:

     - A successful "session close" logout.
     - A successful "connection close" logout for the last Full Feature
       Phase connection when no other connection in the session is
       waiting for cleanup (Section 7.2 Connection Cleanup State Diagram
       for Initiators and Targets) and no tasks in the session are
       waiting for reassignment.

   Session timeout is an event defined to occur when the last connection
   state timeout expires and no tasks are waiting for reassignment.
   This takes the session to the FREE state (N6 transition in the
   session state diagram).

5.3.5.1. Loss of Nexus Notification
The iSCSI layer provides the SCSI layer with the "I_T nexus loss" notification when any one of the following events happens: a) Successful completion of session reinstatement. b) Session closure event. c) Session timeout event. Certain SCSI object clearing actions may result due to the notification in the SCSI end nodes, as documented in Appendix F. - Clearing Effects of Various Events on Targets -.

5.3.6. Session Continuation and Failure

Session continuation is the process by which the state of a preexisting session continues to be used by connection reinstatement (Section 5.3.4 Connection Reinstatement), or by adding a connection with a new CID. Either of these actions associates the new transport connection with the session state. Session failure is an event where the last Full Feature Phase connection reaches the CLEANUP_WAIT state (Section 7.2 Connection Cleanup State Diagram for Initiators and Targets), or completes a successful recovery logout, thus causing all active tasks (that are formerly allegiant to the connection) to start waiting for task reassignment.
ToP   noToC   RFC3720 - Page 66

5.4. Operational Parameter Negotiation Outside the Login Phase

Some operational parameters MAY be negotiated outside (after) the Login Phase. Parameter negotiation in Full Feature Phase is done through Text requests and responses. Operational parameter negotiation MAY involve several Text request-response exchanges, which the initiator always starts and terminates using the same Initiator Task Tag. The initiator MUST indicate its intent to terminate the negotiation by setting the F bit to 1; the target sets the F bit to 1 on the last response. If the target responds to a Text request with the F bit set to 1 and with a Text response with the F bit set to 0, the initiator should keep sending the Text request (even empty) with the F bit set to 1, while it still wants to finish the negotiation, until it receives the Text response with the F bit set to 1. Responding to a Text request with the F bit set to 1 with an empty (no key=value pairs) response with the F bit set to 0 is discouraged. Targets MUST NOT submit parameters that require an additional initiator Text request in a Text response with the F bit set to 1. In a negotiation sequence, the F bit settings in one pair of Text request-responses have no bearing on the F bit settings of the next pair. An initiator that has the F bit set to 1 in a request and is being answered with an F bit setting of 0 may issue the next request with the F bit set to 0. Whenever the target responds with the F bit set to 0, it MUST set the Target Transfer Tag to a value other than the default 0xffffffff. An initiator MAY reset an operational parameter negotiation by issuing a Text request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff. A target may reset an operational parameter negotiation by answering a Text request with a Reject PDU. Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening operational parameter negotiation reset, except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress). If detected by the target, this MUST result in a Reject PDU with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.
ToP   noToC   RFC3720 - Page 67
   Parameters negotiated by a text exchange negotiation sequence only
   become effective after the negotiation sequence is completed.



(page 67 continued on part 4)

Next Section