tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7143

 
 
 

Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)

Part 4 of 10, p. 64 to 91
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 64 
4.5.  iSCSI UML Model

   This section presents the application of the UML modeling concepts
   discussed in Section 3 to the iSCSI and SCSI Architecture Model
   discussed in Section 4.4.

                       +----------------+
                       | Network Entity |
                       +----------------+
                            @ 1     @ 1
                            |       |
     +----------------------+       |
     |                              |
     |                              | 0..*
     |                   +------------------+
     |                   | iSCSI Node       |
     |                   +------------------+
     |                       @       @
     |                       |       |
     |           +-----------+ =(a)= +-----------+
     |           |                               |
     |           | 0..1                          | 0..1
     | +------------------------+       +----------------------+
     | |    iSCSI Target Node   |       | iSCSI Initiator Node |
     | +------------------------+       +----------------------+
     |             @ 1                            @ 1
     |             +---------------+              |
     |                        1..* |              | 1..*
     |                    +-----------------------------+
     |                    |         Portal Group        |
     |                    +-----------------------------+
     |                                     O 1
     |                                     |
     |                                     | 1..*
     |               1..* +------------------------+
     +--------------------|        Network Portal  |
                          +------------------------+

   (a) Each instance of an iSCSI node class MUST contain one iSCSI
       target node instance, one iSCSI initiator node instance, or both.

Top      Up      ToC       Page 65 
                    +----------------+
                    | Network Entity |
                    +----------------+
                         @ 1         @ 1
                         |           |              +------------------+
   +---------------------+           |              |   iSCSI Session  |
   |                                 |              +------------------+
   |                                 | 0..*         |     SSID[1]      |
   |                  +--------------------+        |     ISID[1]      |
   |                  |      iSCSI Node    |        +------------------+
   |                  +--------------------+                   @ 1
   |                  | iSCSI Node Name[1] |                   |
   |                  |    Alias [0..1]    |                   | 0..*
   |                  +--------------------+        +------------------+
   |                  |                    |        | iSCSI Connection |
   |                  +--------------------+        +------------------+
   |                         @ 1         @ 1        |      CID[1]      |
   |                         |           |          +------------------+
   |           +-------------+ ==(b)==   +---------+              0..* |
   |           | 1                                 | 1                 |
   | +------------------------+             +------------------------+ |
   | |   iSCSI Target Node    |             | iSCSI Initiator Node   | |
   | +------------------------+             +------------------------+ |
   | | iSCSI Target Name [1]  |             |iSCSI Initiator Name [1]| |
   | +------------------------+             +------------------------+ |
   |            @ 1                                    @ 1             |
   |            | 1..*                                 | 1..*          |
   | +--------------------------+           +------------------------+ |
   | |   Target Portal Group    |           | Initiator Portal Group | |
   | +--------------------------+           +------------------------+ |
   | |Target Portal Group Tag[1]|           | Portal Group Tag[1]    | |
   | +--------------------------+           +------------------------+ |
   |            o 1                                    o 1             |
   |            +------------+              +----------+               |
   |                    1..* |              | 1..*                     |
   |                +-------------------------+                        |
   |                |          Network Portal |                        |
   |                +-------------------------+                        |
   |          1..*  |         IP Address [1]  | 1                      |
   +----------------|         TCP Port [0..1] |<-----------------------+
                    +-------------------------+

   (b) Each instance of an iSCSI node class MUST contain one iSCSI
       target node instance, one iSCSI initiator node instance, or both.
       However, in all scenarios, note that an iSCSI node MUST only have
       a single iSCSI name.  Note the related requirement in
       Section 4.2.7.1.

Top      Up      ToC       Page 66 
4.6.  Request/Response Summary

   This section lists and briefly describes all the iSCSI PDU types
   (requests 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.

4.6.1.  Request/Response Types Carrying SCSI Payload

4.6.1.1.  SCSI Command

   This request carries the SCSI CDB and all the other SCSI Execute
   Command [SAM2] procedure call IN arguments, such as task attributes,
   Expected Data Transfer Length for one or both transfer directions
   (the latter for bidirectional commands), and a 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) and the expected status sequence number (ExpStatSN) on
   the connection it is issued.

   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.

4.6.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.

Top      Up      ToC       Page 67 
   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:

      - ExpDataSN - 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

      - ExpCmdSN - the next expected command sequence number at the
        target

      - MaxCmdSN - the maximum CmdSN acceptable at the target from this
        initiator

4.6.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 (i.e., 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.

Top      Up      ToC       Page 68 
4.6.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 completed (response and qualifier) and additional information
   for failure responses.

   After the Task Management Function Response indicates task management
   function completion, the initiator will not receive any additional
   responses from the affected tasks.

4.6.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 the 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 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 enable the switching of direction for bidirectional
   commands as required.

   For input, the target may request positive acknowledgment 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, the 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).

Top      Up      ToC       Page 69 
4.6.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.

   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

4.6.2.  Requests/Responses Carrying SCSI and iSCSI Payload

4.6.2.1.  Asynchronous Message

   Asynchronous Message PDUs are used to carry SCSI asynchronous event
   notifications (AENs) and iSCSI asynchronous messages.

   When carrying an AEN, the event details are reported as sense data in
   the data segment.

4.6.3.  Requests/Responses Carrying iSCSI-Only Payload

4.6.3.1.  Text Requests and Text Responses

   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.

Top      Up      ToC       Page 70 
   Text Requests/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 bit in the Text Response header to
   indicate its consent to sequence termination.

   Text Requests 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), it 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.

4.6.3.2.  Login Requests and Login Responses

   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.

   The StatSN for each connection is initiated by the connection login.

Top      Up      ToC       Page 71 
   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.

4.6.3.3.  Logout Requests and Logout Responses

   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 initiator's 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
   new connection) in the Time2Retain field and how long the initiator
   must wait before proceeding with recovery in the Time2Wait field.

4.6.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 acknowledgment 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 acknowledgment.

4.6.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.

4.6.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

Top      Up      ToC       Page 72 
   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 in "unidirectional" fashion 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.

5.  SCSI Mode Parameters for iSCSI

   There are no iSCSI-specific mode pages.

6.  Login and Full Feature Phase Negotiation

   iSCSI parameters are negotiated at session or connection
   establishment by using Login Requests and Responses (see
   Section 4.2.4) and during the Full Feature Phase (Section 4.2.5) by
   using Text Requests and Responses.  In 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 whether the key is declarative or requires
   negotiation.

   For the declarative keys, the declaring party sets a value for the
   key.  The key specification indicates whether the key can be declared
   by the initiator, the 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.
   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 the following Login or Text Response or
   Request.  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
   setting some mandatory parameters.

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

Top      Up      ToC       Page 73 
   Progression from stage to stage is controlled by the T (Transit) 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 (Continue) bit is used (both in Login and Text) to indicate that
   "more follows".

   The text negotiation uses an additional mechanism by which a target
   may deliver larger amounts of data to an inquiring 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 section details the types of keys and values used, the syntax
   rules for parameter formation, and the negotiation schemes to be used
   with different types of parameters.

6.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 case sensitive; they are to be presented and interpreted
   as they appear in this document without change of case.

   The following character symbols are used in this document for text
   items (the hexadecimal values represent Unicode code points):

   (a-z, A-Z) (0x61-0x7a, 0x41-0x5a) - letters
                   (0-9) (0x30-0x39) - digits
                          " " (0x20) - space
                          "." (0x2e) - dot
                          "-" (0x2d) - minus
                          "+" (0x2b) - plus
                          "@" (0x40) - commercial at
                          "_" (0x5f) - underscore
                          "=" (0x3d) - equal
                          ":" (0x3a) - colon

Top      Up      ToC       Page 74 
                          "/" (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 the 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 has the C bit set to 0, or
   that 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.

   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 consists
        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 consists 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
        consists of minus, dot, colon, or any character allowed by the
        output of the iSCSI stringprep template as specified in
        [RFC3722] (see also Section 4.2.7.2).

      - 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".

Top      Up      ToC       Page 75 
      - 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.

      - decimal-constant: An unsigned decimal number with the digit 0 or
        a string of one or more digits that starts 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-constants MUST NOT be used for parameter values if the
        values can be equal to 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, letters, plus
        sign, slash, or equals sign.  The encoding is done according to
        [RFC4648].

      - 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-
        numerical-values.

      - numerical-range: Two numerical-values separated by a tilde,
        where the value to the right of the 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      Up      ToC       Page 76 
      - 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,
        numerical-value, a numerical-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 at least 64 kilobytes of key=value data.

6.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 at 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 a Text or Login Response PDU
   that has the C bit set to 1 MUST NOT have the F bit or 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 a
   Text or Login Request with no data segment (DataSegmentLength 0)
   unless explicitly required by a general or a key-specific negotiation
   rule.

Top      Up      ToC       Page 77 
   There MUST NOT be more than one outstanding Text Request, or Text
   Response PDU on an iSCSI connection.  An outstanding PDU in this
   context is one that has not been acknowledged by the remote iSCSI
   side.

   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 (unless the key is
   not understood by the receiver), while a negotiation is a two-way
   exchange.

   The proposer or declarer can be either the initiator or the target,
   and the acceptor can be either 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 the use of some other value has
   serious consequences.

   The value proposed or declared can be a numerical-value, a numerical-
   range defined by the lower and upper value 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 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
   negotiations.  However, the negotiation is not considered to have
   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

Top      Up      ToC       Page 78 
   keys makes other keys irrelevant.  The following example illustrates
   the use of "Irrelevant":

      I->T InitialR2T=No,ImmediateData=Yes,FirstBurstLength=4192
      T->I InitialR2T=Yes,ImmediateData=No,FirstBurstLength=Irrelevant
      I->T X-rdname-vkey1=(bla,alb,None), X-rdname-vkey2=(bla,alb)
      T->I X-rdname-vkey1=None, X-rdname-vkey2=Irrelevant

   Any key not understood by the acceptor may be ignored by the acceptor
   without affecting the basic function.  However, the answer for a key
   that is not understood MUST be key=NotUnderstood.  Note that
   NotUnderstood is a valid answer for both declarative and negotiated
   keys.  The general iSCSI philosophy is that comprehension precedes
   processing for any iSCSI key.  A proposer of an iSCSI key, negotiated
   or declarative, in a text key exchange MUST thus be able to properly
   handle a NotUnderstood response.

   The proper way to handle a NotUnderstood response depends on where
   the key is specified and whether the key is declarative or
   negotiated.  An iSCSI implementation MUST comprehend all text keys
   defined in this document.  Returning a NotUnderstood response on any
   of these text keys therefore MUST be considered a protocol error and
   handled accordingly.  For all other "later" keys, i.e., text keys
   defined in later specifications, a NotUnderstood answer concludes the
   negotiation for a negotiated key, whereas for a declarative key a
   NotUnderstood answer simply informs the declarer of a lack of
   comprehension by the receiver.

   In either case, a NotUnderstood answer always requires that the
   protocol behavior associated with that key not be used within the
   scope of the key (connection/session) by either side.

   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 renegotiation and is forbidden for
   many keys.

Top      Up      ToC       Page 79 
   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 in which it is sent, the proposer MAY choose to
   terminate the connection or session.

   All keys in this document 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 private keys by prefixing them with X-
   followed by their (reverse) domain name, or with new public keys
   registered with IANA.  For example, the entity owning the domain
   example.com can issue:

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

   Each new public key in the course of standardization MUST define the
   acceptable responses to the key, including NotUnderstood as
   appropriate.  Unlike [RFC3720], note that this document prohibits the
   X# prefix for new public keys.  Based on iSCSI implementation
   experience, we know that there is no longer a need for a standard
   name prefix for keys that allow a NotUnderstood response.  Note that
   NotUnderstood will generally have to be allowed for new public keys
   for backwards compatibility, as well as for private X- keys.  Thus,
   the name prefix "X#" in new public key-names does not carry any
   significance.  To avoid confusion, new public key-names MUST NOT
   begin with an "X#" prefix.

   Implementers MAY also introduce new values, but ONLY for new keys or
   authentication methods (see Section 12) or digests (see
   Section 13.1).

   Whenever parameter actions or acceptance are dependent on other
   parameters, the dependency rules and parameter sequence must be
   specified with the parameters.

   In the Login Phase (see Section 6.3), every stage is a separate
   negotiation.  In the Full Feature Phase, 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 that
   parameter-v be Yes).  Whenever required, integrity rules are
   specified with the keys.  Checking for compliance with the integrity

Top      Up      ToC       Page 80 
   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 terminate within an implementation-specific reasonable time or
   number of exchanges but SHOULD allow at least six (6) exchanges.

6.2.1.  List Negotiations

   In list negotiation, the originator sends a list of values (which may
   include "None"), in 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.  When "None" is proposed as a selection item in
   a negotiation for a key, it indicates to the responder that not
   supporting any functionality related to that key is legal, and if
   "None" is the negotiation result for such a key, it means that key-
   specific semantics are not operational for the negotiation scope
   (connection or session) of that key.

   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 by the originator as a protocol error.

6.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"; otherwise, the
   acceptor MUST select an admissible value.

   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.

Top      Up      ToC       Page 81 
   For a numerical range, the value selected MUST be an integer within
   the proposed range or "Reject" (if the range is unacceptable).

   For Boolean negotiations (i.e., 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 with which to
   answer 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.

6.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 and security parameters, and authenticates the
   initiator and target to each other.

   The Login Phase is only implemented via Login Requests 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).

   There MUST NOT be more than one outstanding Login Request or Login
   Response on an iSCSI connection.  An outstanding PDU in this context
   is one that has not been acknowledged by the remote iSCSI side.

   The default MaxRecvDataSegmentLength is used during login.

Top      Up      ToC       Page 82 
   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)

   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 and MUST include at least one of
   them, but 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.

   Authentication-related security keys (Section 12) MUST be completely
   negotiated within the Login Phase.  The use of underlying IPsec
   security is specified in Section 9.3, in [RFC3723], and in [RFC7146].
   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.

Top      Up      ToC       Page 83 
   Most of the negotiation keys are only allowed in a specific stage.
   The keys used during the SecurityNegotiation stage are listed in
   Section 12, and the keys used during the LoginOperationalNegotiation
   stage are discussed in Section 13.  Only a limited set of keys
   (marked as Any-Stage in Section 13) may be used in either 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.
   Sending a key that is not allowed in the current stage is considered
   a protocol error.

   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 via
   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 Login Request-
   Login Response pair have no bearing on the T bit settings of the next
   pair.  An initiator that has the 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         |
     +-----------------------------------------------------------+

Top      Up      ToC       Page 84 
   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
   by the target, the target MUST respond with a Login reject (initiator
   error); if detected by the initiator, the initiator MUST drop the
   connection.

6.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

Top      Up      ToC       Page 85 
   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 6.3.5)          |
    +----------------------------------------------------------------+
    |existing| non-zero    | new    |   add a new connection to      |
    |        | existing    |        |   the session                  |
    +----------------------------------------------------------------+
    |existing| non-zero    |existing|   do connection reinstatement  |
    |        | existing    |        |   (see Section 7.1.4.3)        |
    +----------------------------------------------------------------+
    |existing| non-zero    | any    |   fail the login               |
    |        | new         |        |   ("session does not exist")   |
    +----------------------------------------------------------------+

   The determination of "existing" or "new" is made by the target.

   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, the CSG field,
        and the NSG field are reserved.

Top      Up      ToC       Page 86 
      - Login Response with Login accept as the Final-Response (T bit
        set to 1 and the NSG in both request and response is 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 11.13) without
   SecurityNegotiation and will terminate the connection with a response
   of Authentication failure (see Section 11.13.5).

   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 13.9), the T bit set to 1, the CSG set to
   SecurityNegotiation, and the NSG set to LoginOperationalNegotiation.

   An initiator that chooses to operate without iSCSI security and 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 the 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.  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.

Top      Up      ToC       Page 87 
6.3.2.  iSCSI Security Negotiation

   The security exchange sets the security mechanism and authenticates
   the initiator and the target to each other.  The exchange proceeds
   according to the authentication method chosen in the negotiation
   phase and is conducted using the key=value parameters carried in the
   Login Requests and Responses.

   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 6.2).  The parameters are encoded in
        UTF-8 as key=value.  For security parameters, see Section 12.

      - When the initiator considers itself 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 stage selected will be the one the target selected.  If the
        next stage is FullFeaturePhase, the target MUST reply 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); see Appendix B for an
   example.

6.3.3.  Operational Parameter Negotiation during the Login Phase

   Operational parameter negotiation during the Login Phase 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.

Top      Up      ToC       Page 88 
   Operational parameter negotiation MAY involve several Login Request-
   Login 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.

   Even when the initiator indicates its intent to switch stages by
   setting the T bit to 1 in a Login Request, the target MAY respond
   with a Login Response with the T bit set to 0.  In that case, the
   initiator SHOULD continue to set the T bit to 1 in subsequent Login
   Requests (even empty requests) that it sends, until the target sends
   a Login Response with the T bit set to 1 or sends a key that requires
   the initiator 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 the
   Full Feature Phase.  New or replacement connections can only be added
   to a session after the session is operational.

   For operational parameters, see Section 13.

6.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 reinstatement of a new Full
   Feature Phase iSCSI connection in its place (with the same CID).
   Thus, the TSIH in the Login Request 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 the 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

Top      Up      ToC       Page 89 
   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 8.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.

6.3.5.  Session Reinstatement, Closure, and Timeout

   Session reinstatement is the process of an initiator logging in with
   an ISID that is possibly active from the target's perspective for
   that initiator, 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 8.3) when the
   initiator attempts a session reinstatement.

   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 8.2) 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 (see the session state
   diagrams in Section 8.3).

Top      Up      ToC       Page 90 
6.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:

      - successful completion of session reinstatement

      - session closure event

      - session timeout event

   Certain SCSI object clearing actions may result due to the
   notification in the SCSI end nodes, as documented in Appendix E.

6.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 6.3.4) 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 8.2) or completes
   a successful recovery logout, thus causing all active tasks (that are
   formerly allegiant to the connection) to start waiting for task
   reassignment.

6.4.  Operational Parameter Negotiation outside the Login Phase

   Some operational parameters MAY be negotiated outside (after) the
   Login Phase.

   Parameter negotiation in the Full Feature Phase is done through Text
   Requests and Responses.  Operational parameter negotiation MAY
   involve several Text Request-Text Response exchanges, all of which
   use the same Initiator Task Tag; the initiator always starts and
   terminates each of these exchanges.  The initiator MUST indicate its
   intent to finish 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 with
   a Text Response with the F bit set to 0, the initiator should keep
   sending the Text Request (even empty requests) 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.

Top      Up      ToC       Page 91 
   Even when the initiator indicates its intent to finish the
   negotiation by setting the F bit to 1 in a Text Request, the target
   MAY respond with a Text Response with the F bit set to 0.  In that
   case, the initiator SHOULD continue to set the F bit to 1 in
   subsequent Text Requests (even empty requests) that it sends, until
   the target sends the final Text Response with the F bit set to 1.
   Note that in the same case of a Text Request with the F bit set to 1,
   the target SHOULD NOT respond with an empty (no key=value pairs) Text
   Response with the F bit set to 0, because such a response may cause
   the initiator to abandon the negotiation.

   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 Text Request-
   Text Response pair 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,
   except for responses to specific keys that explicitly allow repeated
   key declarations (e.g., TargetAddress).  If such an attempt is
   detected by the target, the target MUST respond with a Reject PDU
   with a reason of "Protocol Error".  The initiator MUST reset the
   negotiation as outlined above.

   Parameters negotiated by a text exchange negotiation sequence only
   become effective after the negotiation sequence is completed.


Next RFC Part