Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3720

Internet Small Computer Systems Interface (iSCSI)

Pages: 257
Obsoleted by:  7143
Updated by:  3980485050487146
Part 7 of 9 – Pages 160 to 187
First   Prev   Next

ToP   noToC   RFC3720 - Page 160   prevText

10.13. Login Response

The Login Response indicates the progress and/or end of the Login Phase. Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max | Version-active| +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| ISID | + +---------------+---------------+ 12| | TSIH | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| Status-Class | Status-Detail | Reserved | +---------------+---------------+---------------+---------------+ 40/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48/ DataSegment - Login Parameters in Text request Format / +/ / +---------------+---------------+---------------+---------------+

10.13.1. Version-max

This is the highest version number supported by the target. All Login Responses within the Login Phase MUST carry the same Version-max. The initiator MUST use the value presented as a response to the first Login Request.
ToP   noToC   RFC3720 - Page 161

10.13.2. Version-active

Indicates the highest version supported by the target and initiator. If the target does not support a version within the range specified by the initiator, the target rejects the login and this field indicates the lowest version supported by the target. All Login Responses within the Login Phase MUST carry the same Version-active. The initiator MUST use the value presented as a response to the first Login Request.

10.13.3. TSIH

The TSIH is the target assigned session identifying handle. Its internal format and content are not defined by this protocol except for the value 0 that is reserved. With the exception of the Login Final-Response in a new session, this field should be set to the TSIH provided by the initiator in the Login Request. For a new session, the target MUST generate a non-zero TSIH and ONLY return it in the Login Final-Response (see Section 5.3 Login Phase).

10.13.4. StatSN

For the first Login Response (the response to the first Login Request), this is the starting status Sequence Number for the connection. The next response of any kind, including the next Login Response, if any, in the same Login Phase, will carry this number + 1. This field is only valid if the Status-Class is 0.

10.13.5. Status-Class and Status-Detail

The Status returned in a Login Response indicates the execution status of the Login Phase. The status includes: Status-Class Status-Detail 0 Status-Class indicates success. A non-zero Status-Class indicates an exception. In this case, Status-Class is sufficient for a simple initiator to use when handling exceptions, without having to look at the Status-Detail. The Status-Detail allows finer-grained exception handling for more sophisticated initiators and for better information for logging.
ToP   noToC   RFC3720 - Page 162
   The status classes are as follows:

      0 - Success - indicates that the iSCSI target successfully
          received, understood, and accepted the request.  The numbering
          fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if
          Status-Class is 0.

      1 - Redirection - indicates that the initiator must take further
          action to complete the request.  This is usually due to the
          target moving to a different address.  All of the redirection
          status class responses MUST return one or more text key
          parameters of the type "TargetAddress", which indicates the
          target's new address.  A redirection response MAY be issued by
          a target prior or after completing a security negotiation if a
          security negotiation is required.  A redirection SHOULD be
          accepted by an initiator even without having the target
          complete a security negotiation if any security negotiation is
          required, and MUST be accepted by the initiator after the
          completion of the security negotiation if any security
          negotiation is required.

      2 - Initiator Error (not a format error) - indicates that the
          initiator most likely caused the error.  This MAY be due to a
          request for a resource for which the initiator does not have
          permission.  The request should not be tried again.

      3 - Target Error - indicates that the target sees no errors in the
          initiator's Login Request, but is currently incapable of
          fulfilling the request.  The initiator may re-try the same
          Login Request later.

   The table below shows all of the currently allocated status codes.
   The codes are in hexadecimal; the first byte is the status class and
   the second byte is the status detail.

   -----------------------------------------------------------------
   Status        | Code | Description
                 |(hex) |
   -----------------------------------------------------------------
   Success       | 0000 | Login is proceeding OK (*1).
   -----------------------------------------------------------------
   Target moved  | 0101 | The requested iSCSI Target Name (ITN)
   temporarily   |      |  has temporarily moved
                 |      |  to the address provided.
   -----------------------------------------------------------------
   Target moved  | 0102 | The requested ITN has permanently moved
   permanently   |      |  to the address provided.
   -----------------------------------------------------------------
ToP   noToC   RFC3720 - Page 163
   Initiator     | 0200 | Miscellaneous iSCSI initiator
   error         |      | errors.
   ----------------------------------------------------------------
   Authentication| 0201 | The initiator could not be
   failure       |      | successfully authenticated or target
                 |      | authentication is not supported.
   -----------------------------------------------------------------
   Authorization | 0202 | The initiator is not allowed access
   failure       |      | to the given target.
   -----------------------------------------------------------------
   Not found     | 0203 | The requested ITN does not
                 |      | exist at this address.
   -----------------------------------------------------------------
   Target removed| 0204 | The requested ITN has been removed and
                 |      |no forwarding address is provided.
   -----------------------------------------------------------------
   Unsupported   | 0205 | The requested iSCSI version range is
   version       |      | not supported by the target.
   -----------------------------------------------------------------
   Too many      | 0206 | Too many connections on this SSID.
   connections   |      |
   -----------------------------------------------------------------
   Missing       | 0207 | Missing parameters (e.g., iSCSI
   parameter     |      | Initiator and/or Target Name).
   -----------------------------------------------------------------
   Can't include | 0208 | Target does not support session
   in session    |      | spanning to this connection (address).
   -----------------------------------------------------------------
   Session type  | 0209 | Target does not support this type of
   not supported |      | of session or not from this Initiator.
   -----------------------------------------------------------------
   Session does  | 020a | Attempt to add a connection
   not exist     |      | to a non-existent session.
   -----------------------------------------------------------------
   Invalid during| 020b | Invalid Request type during Login.
   login         |      |
   -----------------------------------------------------------------
   Target error  | 0300 | Target hardware or software error.
   -----------------------------------------------------------------
   Service       | 0301 | The iSCSI service or target is not
   unavailable   |      | currently operational.
   -----------------------------------------------------------------
   Out of        | 0302 | The target has insufficient session,
   resources     |      | connection, or other resources.
   -----------------------------------------------------------------
ToP   noToC   RFC3720 - Page 164
   (*1) If the response T bit is 1 in both the request and the matching
   response, and the NSG is FullFeaturePhase in both the request and the
   matching response, the Login Phase is finished and the initiator may
   proceed to issue SCSI commands.

   If the Status Class is not 0, the initiator and target MUST close the
   TCP connection.

   If the target wishes to reject the Login Request for more than one
   reason, it should return the primary reason for the rejection.

10.13.6. T (Transit) bit

The T bit is set to 1 as an indicator of the end of the stage. If the T bit is set to 1 and NSG is FullFeaturePhase, then this is also the Final Login Response (see Chapter 5). A T bit of 0 indicates a "partial" response, which means "more negotiation needed". A Login Response with a T bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator within the same stage. If the status class is 0, the T bit MUST NOT be set to 1 if the T bit in the request was set to 0.

10.13.7. C (Continue) Bit

When set to 1, indicates that the text (set of key=value pairs) in this Login Response is not complete (it will be continued on subsequent Login Responses); otherwise, it indicates that this Login Response ends a set of key=value pairs. A Login Response with the C bit set to 1 MUST have the T bit set to 0.

10.13.8. Login Parameters

The target MUST provide some basic parameters in order to enable the initiator to determine if it is connected to the correct port and the initial text parameters for the security exchange. All the rules specified in Section 10.11.6 Text Response Data for text responses also hold for Login Responses. Keys and their explanations are listed in Chapter 11 (security negotiation keys) and Chapter 12 (operational parameter negotiation keys). All keys in Chapter 12, except for the X extension formats, MUST be supported by iSCSI initiators and targets. Keys in Chapter 11, only need to be supported when the function to which they refer is mandatory to implement.
ToP   noToC   RFC3720 - Page 165

10.14. Logout Request

The Logout Request is used to perform a controlled closing of a connection. An initiator MAY use a Logout Request to remove a connection from a session or to close an entire session. After sending the Logout Request PDU, an initiator MUST NOT send any new iSCSI requests on the closing connection. If the Logout Request is intended to close the session, new iSCSI requests MUST NOT be sent on any of the connections participating in the session. When receiving a Logout Request with the reason code of "close the connection" or "close the session", the target MUST terminate all pending commands, whether acknowledged via ExpCmdSN or not, on that connection or session respectively. When receiving a Logout Request with the reason code "remove connection for recovery", the target MUST discard all requests not yet acknowledged via ExpCmdSN that were issued on the specified connection, and suspend all data/status/R2T transfers on behalf of pending commands on the specified connection. The target then issues the Logout Response and half-closes the TCP connection (sends FIN). After receiving the Logout Response and attempting to receive the FIN (if still possible), the initiator MUST completely close the logging-out connection. For the terminated commands, no additional responses should be expected. A Logout for a CID may be performed on a different transport connection when the TCP connection for the CID has already been terminated. In such a case, only a logical "closing" of the iSCSI connection for the CID is implied with a Logout. All commands that were not terminated or not completed (with status) and acknowledged when the connection is closed completely can be reassigned to a new connection if the target supports connection recovery. If an initiator intends to start recovery for a failing connection, it MUST use the Logout Request to "clean-up" the target end of a failing connection and enable recovery to start, or the Login Request with a non-zero TSIH and the same CID on a new connection for the same effect (see Section 10.14.3 CID). In sessions with a single connection, the connection can be closed and then a new connection reopened. A connection reinstatement login can be used for recovery (see Section 5.3.4 Connection Reinstatement).
ToP   noToC   RFC3720 - Page 166
   A successful completion of a Logout Request with the reason code of
   "close the connection" or "remove the connection for recovery"
   results at the target in the discarding of unacknowledged commands
   received on the connection being logged out.  These are commands that
   have arrived on the connection being logged out, but have not been
   delivered to SCSI because one or more commands with a smaller CmdSN
   has not been received by iSCSI.  See Section 3.2.2.1 Command
   Numbering and Acknowledging.  The resulting holes the in command
   sequence numbers will have to be handled by appropriate recovery (see
   Chapter 6) unless the session is also closed.

   The entire logout discussion in this section is also applicable for
   an implicit Logout realized via a connection reinstatement or session
   reinstatement.  When a Login Request performs an implicit Logout, the
   implicit Logout is performed as if having the reason codes specified
   below:

     Reason code        Type of implicit Logout
     -------------------------------------------
         0              session reinstatement
         1              connection reinstatement when
                       the operational ErrorRecoveryLevel < 2
         2              connection reinstatement when
                       the operational ErrorRecoveryLevel = 2
ToP   noToC   RFC3720 - Page 167
   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| 0x06      |1| Reason Code | Reserved                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------------------------------------------------------+
    8/ Reserved                                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| CID or Reserved               | Reserved                      |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ Reserved                                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (Optional)                                      |
     +---------------+---------------+---------------+---------------+

10.14.1. Reason Code

Reason Code indicates the reason for Logout as follows: 0 - close the session. All commands associated with the session (if any) are terminated. 1 - close the connection. All commands associated with connection (if any) are terminated. 2 - remove the connection for recovery. Connection is closed and all commands associated with it, if any, are to be prepared for a new allegiance. All other values are reserved.
ToP   noToC   RFC3720 - Page 168

10.14.2. TotalAHSLength and DataSegmentLength

For this PDU TotalAHSLength and DataSegmentLength MUST be 0.

10.14.3. CID

This is the connection ID of the connection to be closed (including closing the TCP stream). This field is only valid if the reason code is not "close the session".

10.14.4. ExpStatSN

This is the last ExpStatSN value for the connection to be closed.

10.14.5. Implicit termination of tasks

A target implicitly terminates the active tasks due to the iSCSI protocol in the following cases: a) When a connection is implicitly or explicitly logged out with the reason code of "Close the connection" and there are active tasks allegiant to that connection. b) When a connection fails and eventually the connection state times out (state transition M1 in Section 7.2.2 State Transition Descriptions for Initiators and Targets) and there are active tasks allegiant to that connection. c) When a successful recovery Logout is performed while there are active tasks allegiant to that connection, and those tasks eventually time out after the Time2Wait and Time2Retain periods without allegiance reassignment. d) When a connection is implicitly or explicitly logged out with the reason code of "Close the session" and there are active tasks in that session. If the tasks terminated in any of the above cases are SCSI tasks, they must be internally terminated as if with CHECK CONDITION status. This status is only meaningful for appropriately handling the internal SCSI state and SCSI side effects with respect to ordering because this status is never communicated back as a terminating status to the initiator. However additional actions may have to be taken at SCSI level depending on the SCSI context as defined by the SCSI standards (e.g., queued commands and ACA, in cases a), b), and c), after the tasks are terminated, the target MUST report a Unit Attention condition on the next command processed on any connection for each affected I_T_L nexus with the status of CHECK CONDITION, and
ToP   noToC   RFC3720 - Page 169
   the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI
   PROTOCOL EVENT" - etc. - see [SAM2] and [SPC3]).

10.15. Logout Response

The Logout Response is used by the target to indicate if the cleanup operation for the connection(s) has completed. After Logout, the TCP connection referred by the CID MUST be closed at both ends (or all connections must be closed if the logout reason was session close). Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|.| 0x26 |1| Reserved | Response | Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------------------------------------------------------+ 8/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| Reserved | +---------------------------------------------------------------+ 40| Time2Wait | Time2Retain | +---------------+---------------+---------------+---------------+ 44| Reserved | +---------------+---------------+---------------+---------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+
ToP   noToC   RFC3720 - Page 170

10.15.1. Response

Logout Response: 0 - connection or session closed successfully. 1 - CID not found. 2 - connection recovery is not supported. If Logout reason code was recovery and target does not support it as indicated by the ErrorRecoveryLevel. 3 - cleanup failed for various reasons.

10.15.2. TotalAHSLength and DataSegmentLength

For this PDU TotalAHSLength and DataSegmentLength MUST be 0.

10.15.3. Time2Wait

If the Logout Response code is 0 and if the operational ErrorRecoveryLevel is 2, this is the minimum amount of time, in seconds, to wait before attempting task reassignment. If the Logout Response code is 0 and if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored. This field is invalid if the Logout Response code is 1. If the Logout response code is 2 or 3, this field specifies the minimum time to wait before attempting a new implicit or explicit logout. If Time2Wait is 0, the reassignment or a new Logout may be attempted immediately.

10.15.4. Time2Retain

If the Logout response code is 0 and if the operational ErrorRecoveryLevel is 2, this is the maximum amount of time, in seconds, after the initial wait (Time2Wait), the target waits for the allegiance reassignment for any active task after which the task state is discarded. If the Logout response code is 0 and if the operational ErrorRecoveryLevel is less than 2, this field is to be ignored. This field is invalid if the Logout response code is 1.
ToP   noToC   RFC3720 - Page 171
   If the Logout response code is 2 or 3, this field specifies the
   maximum amount of time, in seconds, after the initial wait
   (Time2Wait), the target waits for a new implicit or explicit logout.

   If it is the last connection of a session, the whole session state is
   discarded after Time2Retain.

   If Time2Retain is 0, the target has already discarded the connection
   (and possibly the session) state along with the task states.  No
   reassignment or Logout is required in this case.

10.16. SNACK Request

Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|.| 0x10 |1|.|.|.| Type | Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| LUN or Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 20| Target Transfer Tag or SNACK Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| Reserved | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 40| BegRun | +---------------------------------------------------------------+ 44| RunLength | +---------------------------------------------------------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+ If the implementation supports ErrorRecoveryLevel greater than zero, it MUST support all SNACK types.
ToP   noToC   RFC3720 - Page 172
   The SNACK is used by the initiator to request the retransmission of
   numbered-responses, data, or R2T PDUs from the target.  The SNACK
   request indicates the numbered-responses or data "runs" whose
   retransmission is requested by the target, where the run starts with
   the first StatSN, DataSN, or R2TSN whose retransmission is requested
   and indicates the number of Status, Data, or R2T PDUs requested
   including the first.  0 has special meaning when used as a starting
   number and length:

     - When used in RunLength, it means all PDUs starting with the
       initial.
     - When used in both BegRun and RunLength, it means all
       unacknowledged PDUs.

   The numbered-response(s) or R2T(s), requested by a SNACK, MUST be
   delivered as exact replicas of the ones that the target transmitted
   originally except for the fields ExpCmdSN, MaxCmdSN, and ExpDataSN,
   which MUST carry the current values.  R2T(s)requested by SNACK MUST
   also carry the current value of StatSN.

   The numbered Data-In PDUs, requested by a Data SNACK MUST be
   delivered as exact replicas of the ones that the target transmitted
   originally except for the fields ExpCmdSN and MaxCmdSN, which MUST
   carry the current values and except for resegmentation (see Section
   10.16.3 Resegmentation).

   Any SNACK that requests a numbered-response, Data, or R2T that was
   not sent by the target or was already acknowledged by the initiator,
   MUST be rejected with a reason code of "Protocol error".

10.16.1. Type

This field encodes the SNACK function as follows: 0-Data/R2T SNACK - requesting retransmission of one or more Data- In or R2T PDUs. 1-Status SNACK - requesting retransmission of one or more numbered responses. 2-DataACK - positively acknowledges Data-In PDUs. 3-R-Data SNACK - requesting retransmission of Data-In PDUs with possible resegmentation and status tagging.
ToP   noToC   RFC3720 - Page 173
   All other values are reserved.

   Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST
   precede status acknowledgement for the given command.

10.16.2. Data Acknowledgement

If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the A bit set to 1. However, if the initiator has detected holes in the input sequence, it MUST postpone issuing the SNACK of type DataACK until the holes are filled. An initiator MAY ignore the A bit if it deems that the bit is being set aggressively by the target (i.e., before the MaxBurstLength limit is reached). The DataACK is used to free resources at the target and not to request or imply data retransmission. An initiator MUST NOT request retransmission for any data it had already acknowledged.

10.16.3. Resegmentation

If the initiator MaxRecvDataSegmentLength changed between the original transmission and the time the initiator requests retransmission, the initiator MUST issue a R-Data SNACK (see Section 10.16.1 Type). With R-Data SNACK, the initiator indicates that it discards all the unacknowledged data and expects the target to resend it. It also expects resegmentation. In this case, the retransmitted Data-In PDUs MAY be different from the ones originally sent in order to reflect changes in MaxRecvDataSegmentLength. Their DataSN starts with the BegRun of the last DataACK received by the target if any was received; otherwise it starts with 0 and is increased by 1 for each resent Data-In PDU. A target that has received a R-Data SNACK MUST return a SCSI Response that contains a copy of the SNACK Tag field from the R-Data SNACK in the SCSI Response SNACK Tag field as its last or only Response. For example, if it has already sent a response containing another value in the SNACK Tag field or had the status included in the last Data-In PDU, it must send a new SCSI Response PDU. If a target sends more than one SCSI Response PDU due to this rule, all SCSI responses must carry the same StatSN (see Section 10.4.4 SNACK Tag). If an initiator attempts to recover a lost SCSI Response (with a Status SNACK, see Section 10.16.1 Type) when more than one response has been sent, the target will send the SCSI Response with the latest content known to the target, including the last SNACK Tag for the command.
ToP   noToC   RFC3720 - Page 174
   For considerations in allegiance reassignment of a task to a
   connection with a different MaxRecvDataSegmentLength, refer to
   Section 6.2.2 Allegiance Reassignment.

10.16.4. Initiator Task Tag

For Status SNACK and DataACK, the Initiator Task Tag MUST be set to the reserved value 0xffffffff. In all other cases, the Initiator Task Tag field MUST be set to the Initiator Task Tag of the referenced command.

10.16.5. Target Transfer Tag or SNACK Tag

For an R-Data SNACK, this field MUST contain a value that is different from 0 or 0xffffffff and is unique for the task (identified by the Initiator Task Tag). This value MUST be copied by the iSCSI target in the last or only SCSI Response PDU it issues for the command. For DataACK, the Target Transfer Tag MUST contain a copy of the Target Transfer Tag and LUN provided with the SCSI Data-In PDU with the A bit set to 1. In all other cases, the Target Transfer Tag field MUST be set to the reserved value of 0xffffffff.

10.16.6. BegRun

The DataSN, R2TSN, or StatSN of the first PDU whose retransmission is requested (Data/R2T and Status SNACK), or the next expected DataSN (DataACK SNACK). BegRun 0 when used in conjunction with RunLength 0 means resend all unacknowledged Data-In, R2T or Response PDUs. BegRun MUST be 0 for a R-Data SNACK.

10.16.7. RunLength

The number of PDUs whose retransmission is requested. RunLength 0 signals that all Data-In, R2T, or Response PDUs carrying the numbers equal to or greater than BegRun have to be resent. The RunLength MUST also be 0 for a DataACK SNACK in addition to R-Data SNACK.
ToP   noToC   RFC3720 - Page 175

10.17. Reject

Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|.| 0x3f |1| Reserved | Reason | Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 16| 0xffffffff | +---------------+---------------+---------------+---------------+ 20| Reserved | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| DataSN/R2TSN or Reserved | +---------------+---------------+---------------+---------------+ 40| Reserved | +---------------+---------------+---------------+---------------+ 44| Reserved | +---------------+---------------+---------------+---------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+ xx/ Complete Header of Bad PDU / +/ / +---------------+---------------+---------------+---------------+ yy/Vendor specific data (if any) / / / +---------------+---------------+---------------+---------------+ zz| Data-Digest (Optional) | +---------------+---------------+---------------+---------------+ Reject is used to indicate an iSCSI error condition (protocol, unsupported option, etc.).
ToP   noToC   RFC3720 - Page 176

10.17.1. Reason

The reject Reason is coded as follows: +------+----------------------------------------+------------------+ | Code | Explanation | Can the original | | (hex)| | PDU be re-sent? | +------+----------------------------------------+------------------+ | 0x01 | Reserved | no | | | | | | 0x02 | Data (payload) Digest Error | yes (Note 1) | | | | | | 0x03 | SNACK Reject | yes | | | | | | 0x04 | Protocol Error (e.g., SNACK request for| no | | | a status that was already acknowledged)| | | | | | | 0x05 | Command not supported | no | | | | | | 0x06 | Immediate Command Reject - too many | yes | | | immediate commands | | | | | | | 0x07 | Task in progress | no | | | | | | 0x08 | Invalid Data ACK | no | | | | | | 0x09 | Invalid PDU field | no (Note 2) | | | | | | 0x0a | Long Operation Reject - Can't generate | yes | | | Target Transfer Tag - out of resources | | | | | | | 0x0b | Negotiation Reset | no | | | | | | 0x0c | Waiting for Logout | no | +------+----------------------------------------+------------------+ Note 1: For iSCSI, Data-Out PDU retransmission is only done if the target requests retransmission with a recovery R2T. However, if this is the data digest error on immediate data, the initiator may choose to retransmit the whole PDU including the immediate data. Note 2: A target should use this reason code for all invalid values of PDU fields that are meant to describe a task, a response, or a data transfer. Some examples are invalid TTT/ITT, buffer offset, LUN qualifying a TTT, and an invalid sequence number in a SNACK. All other values for Reason are reserved.
ToP   noToC   RFC3720 - Page 177
   In all the cases in which a pre-instantiated SCSI task is terminated
   because of the reject, the target MUST issue a proper SCSI command
   response with CHECK CONDITION as described in Section 10.4.3
   Response.  In these cases in which a status for the SCSI task was
   already sent before the reject, no additional status is required.  If
   the error is detected while data from the initiator is still expected
   (i.e., the command PDU did not contain all the data and the target
   has not received a Data-Out PDU with the Final bit set to 1 for the
   unsolicited data, if any, and all outstanding R2Ts, if any), the
   target MUST wait until it receives the last expected Data-Out PDUs
   with the F bit set to 1 before sending the Response PDU.

   For additional usage semantics of Reject PDU, see Section 6.3 Usage
   Of Reject PDU in Recovery.

10.17.2. DataSN/R2TSN

This field is only valid if the rejected PDU is a Data/R2T SNACK and the Reject reason code is "Protocol error" (see Section 10.16 SNACK Request). The DataSN/R2TSN is the next Data/R2T sequence number that the target would send for the task, if any.

10.17.3. StatSN, ExpCmdSN and MaxCmdSN

These fields carry their usual values and are not related to the rejected command. StatSN is advanced after a Reject.

10.17.4. Complete Header of Bad PDU

The target returns the header (not including digest) of the PDU in error as the data of the response.
ToP   noToC   RFC3720 - Page 178

10.18. NOP-Out

Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|I| 0x00 |1| Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| LUN or Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 20| Target Transfer Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+ / DataSegment - Ping Data (optional) / +/ / +---------------+---------------+---------------+---------------+ | Data-Digest (Optional) | +---------------+---------------+---------------+---------------+ A NOP-Out may be used by an initiator as a "ping request" to verify that a connection/session is still active and all its components are operational. The NOP-In response is the "ping echo". A NOP-Out is also sent by an initiator in response to a NOP-In. A NOP-Out may also be used to confirm a changed ExpStatSN if another PDU will not be available for a long time. Upon receipt of a NOP-In with the Target Transfer Tag set to a valid value (not the reserved 0xffffffff), the initiator MUST respond with a NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST contain a copy of the NOP-In Target Transfer Tag.
ToP   noToC   RFC3720 - Page 179

10.18.1. Initiator Task Tag

The NOP-Out MUST have the Initiator Task Tag set to a valid value only if a response in the form of NOP-In is requested (i.e., the NOP-Out is used as a ping request). Otherwise, the Initiator Task Tag MUST be set to 0xffffffff. When a target receives the NOP-Out with a valid Initiator Task Tag, it MUST respond with a Nop-In Response (see Section 10.19 NOP-In). If the Initiator Task Tag contains 0xffffffff, the I bit MUST be set to 1 and the CmdSN is not advanced after this PDU is sent.

10.18.2. Target Transfer Tag

A target assigned identifier for the operation. The NOP-Out MUST only have the Target Transfer Tag set if it is issued in response to a NOP-In with a valid Target Transfer Tag. In this case, it copies the Target Transfer Tag from the NOP-In PDU. Otherwise, the Target Transfer Tag MUST be set to 0xffffffff. When the Target Transfer Tag is set to a value other than 0xffffffff, the LUN field MUST also be copied from the NOP-In.

10.18.3. Ping Data

Ping data are reflected in the NOP-In Response. The length of the reflected data are limited to MaxRecvDataSegmentLength. The length of ping data are indicated by the DataSegmentLength. 0 is a valid value for the DataSegmentLength and indicates the absence of ping data.
ToP   noToC   RFC3720 - Page 180

10.19. NOP-In

Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +---------------+---------------+---------------+---------------+ 0|.|.| 0x20 |1| Reserved | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| LUN or Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 20| Target Transfer Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Header-Digest (Optional) | +---------------+---------------+---------------+---------------+ / DataSegment - Return Ping Data / +/ / +---------------+---------------+---------------+---------------+ | Data-Digest (Optional) | +---------------+---------------+---------------+---------------+ NOP-In is either sent by a target as a response to a NOP-Out, as a "ping" to an initiator, or as a means to carry a changed ExpCmdSN and/or MaxCmdSN if another PDU will not be available for a long time (as determined by the target). When a target receives the NOP-Out with a valid Initiator Task Tag (not the reserved value 0xffffffff), it MUST respond with a NOP-In with the same Initiator Task Tag that was provided in the NOP-Out request. It MUST also duplicate up to the first MaxRecvDataSegmentLength bytes of the initiator provided Ping Data. For such a response, the Target Transfer Tag MUST be 0xffffffff.
ToP   noToC   RFC3720 - Page 181
   Otherwise, when a target sends a NOP-In that is not a response to a
   Nop-Out received from the initiator, the Initiator Task Tag MUST be
   set to 0xffffffff and the Data Segment MUST NOT contain any data
   (DataSegmentLength MUST be 0).

10.19.1. Target Transfer Tag

If the target is responding to a NOP-Out, this is set to the reserved value 0xffffffff. If the target is sending a NOP-In as a Ping (intending to receive a corresponding NOP-Out), this field is set to a valid value (not the reserved 0xffffffff). If the target is initiating a NOP-In without wanting to receive a corresponding NOP-Out, this field MUST hold the reserved value of 0xffffffff.

10.19.2. StatSN

The StatSN field will always contain the next StatSN. However, when the Initiator Task Tag is set to 0xffffffff, StatSN for the connection is not advanced after this PDU is sent.

10.19.3. LUN

A LUN MUST be set to a correct value when the Target Transfer Tag is valid (not the reserved value 0xffffffff).

11. iSCSI Security Text Keys and Authentication Methods

Only the following keys are used during the SecurityNegotiation stage of the Login Phase: SessionType InitiatorName TargetName TargetAddress InitiatorAlias TargetAlias TargetPortalGroupTag AuthMethod and the keys used by the authentication methods specified under Section 11.1 AuthMethod along with all of their associated keys as well as Vendor Specific Authentication Methods.
ToP   noToC   RFC3720 - Page 182
   Other keys MUST NOT be used.

   SessionType, InitiatorName, TargetName, InitiatorAlias, TargetAlias,
   and TargetPortalGroupTag are described in Chapter 12 as they can be
   used also in the OperationalNegotiation stage.

   All security keys have connection-wide applicability.

11.1. AuthMethod

Use: During Login - Security Negotiation Senders: Initiator and Target Scope: connection AuthMethod = <list-of-values> The main item of security negotiation is the authentication method (AuthMethod). The authentication methods that can be used (appear in the list-of-values) are either those listed in the following table or are vendor-unique methods: +------------------------------------------------------------+ | Name | Description | +------------------------------------------------------------+ | KRB5 | Kerberos V5 - defined in [RFC1510] | +------------------------------------------------------------+ | SPKM1 | Simple Public-Key GSS-API Mechanism | | | defined in [RFC2025] | +------------------------------------------------------------+ | SPKM2 | Simple Public-Key GSS-API Mechanism | | | defined in [RFC2025] | +------------------------------------------------------------+ | SRP | Secure Remote Password | | | defined in [RFC2945] | +------------------------------------------------------------+ | CHAP | Challenge Handshake Authentication Protocol| | | defined in [RFC1994] | +------------------------------------------------------------+ | None | No authentication | +------------------------------------------------------------+ The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method selected. The authentication method proposal may be made by either the initiator or the target. However the initiator MUST make the first step specific to the selected authentication method as soon as it is
ToP   noToC   RFC3720 - Page 183
   selected.  It follows that if the target makes the authentication
   method proposal the initiator sends the first keys(s) of the exchange
   together with its authentication method selection.

   The authentication exchange authenticates the initiator to the
   target, and optionally, the target to the initiator.  Authentication
   is OPTIONAL to use but MUST be supported by the target and initiator.

   The initiator and target MUST implement CHAP.  All other
   authentication methods are OPTIONAL.

   Private or public extension algorithms MAY also be negotiated for
   authentication methods.  Whenever a private or public extension
   algorithm is part of the default offer (the offer made in absence of
   explicit administrative action) the implementer MUST ensure that CHAP
   is listed as an alternative  in the default offer and "None" is not
   part of the default offer.

   Extension authentication methods MUST be named using one of the
   following two formats:

       a)  Z-reversed.vendor.dns_name.do_something=
       b)  Z<#><IANA-registered-string>=

   Authentication methods named using the Z- format are used as private
   extensions.  Authentication methods named using the Z# format are
   used as public extensions that must be registered with IANA and MUST
   be described by an informational RFC.

   For all of the public or private extension authentication methods,
   the method specific keys MUST conform to the format specified in
   Section 5.1 Text Format for standard-label.

   To identify the vendor for private extension authentication methods,
   we suggest you use the reversed DNS-name as a prefix to the proper
   digest names.

   The part of digest-name following Z- and Z# MUST conform to the
   format for standard-label specified in Section 5.1 Text Format.

   Support for public or private extension authentication methods is
   OPTIONAL.

   The following subsections define the specific exchanges for each of
   the standardized authentication methods.  As mentioned earlier the
   first step is always done by the initiator.
ToP   noToC   RFC3720 - Page 184

11.1.1. Kerberos

For KRB5 (Kerberos V5) [RFC1510] and [RFC1964], the initiator MUST use: KRB_AP_REQ=<KRB_AP_REQ> where KRB_AP_REQ is the client message as defined in [RFC1510]. The default principal name assumed by an iSCSI initiator or target (prior to any administrative configuration action) MUST be the iSCSI Initiator Name or iSCSI Target Name respectively, prefixed by the string "iscsi/". If the initiator authentication fails, the target MUST respond with a Login reject with "Authentication Failure" status. Otherwise, if the initiator has selected the mutual authentication option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), the target MUST reply with: KRB_AP_REP=<KRB_AP_REP> where KRB_AP_REP is the server's response message as defined in [RFC1510]. If mutual authentication was selected and target authentication fails, the initiator MUST close the connection. KRB_AP_REQ and KRB_AP_REP are binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 65536 bytes.

11.1.2. Simple Public-Key Mechanism (SPKM)

For SPKM1 and SPKM2 [RFC2025], the initiator MUST use: SPKM_REQ=<SPKM-REQ> where SPKM-REQ is the first initiator token as defined in [RFC2025]. [RFC2025] defines situations where each side may send an error token that may cause the peer to re-generate and resend its last token. This scheme is followed in iSCSI, and the error token syntax is: SPKM_ERROR=<SPKM-ERROR>
ToP   noToC   RFC3720 - Page 185
   However, SPKM-DEL tokens that are defined by [RFC2025] for fatal
   errors will not be used by iSCSI.  If the target needs to send a
   SPKM-DEL token, it will, instead, send a Login "login reject" message
   with the "Authentication Failure" status and terminate the
   connection.  If the initiator needs to send a SPKM-DEL token, it will
   close the connection.

   In the following sections, we assume that no SPKM-ERROR tokens are
   required.

   If the initiator authentication fails, the target MUST return an
   error.  Otherwise, if the AuthMethod is SPKM1 or if the initiator has
   selected the mutual authentication option (by setting mutual-state
   bit in the options field of the REQ-TOKEN in the SPKM-REQ), the
   target MUST reply with:

      SPKM_REP_TI=<SPKM-REP-TI>

   where SPKM-REP-TI is the target token as defined in [RFC2025].

   If mutual authentication was selected and target authentication
   fails, the initiator MUST close the connection.  Otherwise, if the
   AuthMethod is SPKM1, the initiator MUST continue with:

      SPKM_REP_IT=<SPKM-REP-IT>

   where SPKM-REP-IT is the second initiator token as defined in
   [RFC2025].  If the initiator authentication fails, the target MUST
   answer with a Login reject with "Authentication Failure" status.

   SPKM requires support for very long authentication items.

   All the SPKM-* tokens are binary-values and their binary length (not
   the length of the character string that represents them in encoded
   form) MUST not exceed 65536 bytes.

11.1.3. Secure Remote Password (SRP)

For SRP [RFC2945], the initiator MUST use: SRP_U=<U> TargetAuth=Yes /* or TargetAuth=No */ The target MUST answer with a Login reject with the "Authorization Failure" status or reply with: SRP_GROUP=<G1,G2...> SRP_s=<s> Where G1,G2... are proposed groups, in order of preference.
ToP   noToC   RFC3720 - Page 186
   The initiator MUST either close the connection or continue with:

   SRP_A=<A> SRP_GROUP=<G>

   Where G is one of G1,G2... that were proposed by the target.

   The target MUST answer with a Login reject with the "Authentication
   Failure" status or reply with:

      SRP_B=<B>

   The initiator MUST close the connection or continue with:

      SRP_M=<M>

   If the initiator authentication fails, the target MUST answer with a
   Login reject with "Authentication Failure" status.  Otherwise, if the
   initiator sent TargetAuth=Yes in the first message (requiring target
   authentication), the target MUST reply with:

     SRP_HM=<H(A | M | K)>

   If the target authentication fails, the initiator MUST close the
   connection.

   Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using
   the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn stands for
   G1,G2...) are identifiers of SRP groups specified in [RFC3723].  G,
   Gn, and U are text strings, s,A,B,M, and H(A | M | K) are
   binary-values.  The length of s,A,B,M and H(A | M | K) in binary form
   (not the length of the character string that represents them in
   encoded form) MUST not exceed 1024 bytes.

   For the SRP_GROUP, all the groups specified in [RFC3723] up to 1536
   bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be supported
   by initiators and targets.  To guarantee interoperability, targets
   MUST always offer "SRP-1536" as one of the proposed groups.

11.1.4. Challenge Handshake Authentication Protocol (CHAP)

For CHAP [RFC1994], in the first step, the initiator MUST send: CHAP_A=<A1,A2...> Where A1,A2... are proposed algorithms, in order of preference.
ToP   noToC   RFC3720 - Page 187
   In the second step, the target MUST answer with a Login reject with
   the "Authentication Failure" status or reply with:

      CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>

   Where A is one of A1,A2... that were proposed by the initiator.

   In the third step, the initiator MUST continue with:

      CHAP_N=<N> CHAP_R=<R>

   or, if it requires target authentication, with:

      CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C>

   If the initiator authentication fails, the target MUST answer with a
   Login reject with "Authentication Failure" status.  Otherwise, if the
   initiator required target authentication, the target MUST either
   answer with a Login reject with "Authentication Failure" or reply
   with:

      CHAP_N=<N> CHAP_R=<R>

   If target authentication fails, the initiator MUST close the
   connection.

   Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name,
   Algorithm, Identifier, Challenge, and Response as defined in
   [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C and
   R are large-binary-values and their binary length (not the length of
   the character string that represents them in encoded form) MUST not
   exceed 1024 bytes.

   For the Algorithm, as stated in [RFC1994], one value is required to
   be implemented:

       5     (CHAP with MD5)

   To guarantee interoperability, initiators MUST always offer it as one
   of the proposed algorithms.



(page 187 continued on part 8)

Next Section