9. iSER Control and Data Transfer
For iSCSI data-type PDUs (see Section 7.1), the iSER layer uses RDMA Read and RDMA Write operations to transfer the solicited data. For iSCSI control-type PDUs (see Section 7.2), the iSER layer uses Send Messages of RCaP.9.1. iSER Header Format
An iSER header MUST be present in every Send Message of RCaP. The iSER header is located in the first 28 bytes of the message payload of the Send Message of RCaP, as shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode| Opcode Specific Fields | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode Specific Fields (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Opcode Specific Fields (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode Specific Fields (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Opcode Specific Fields (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: iSER Header Format Opcode - Operation Code: 4 bits The Opcode field identifies the type of iSER Messages: 0001b = iSCSI control-type PDU 0010b = iSER Hello Message 0011b = iSER HelloReply Message All other Opcodes are unassigned.
9.2. iSER Header Format for iSCSI Control-Type PDU
The iSER layer uses Send Messages of RCaP to transfer iSCSI control- type PDUs (see Section 7.2). The message payload of each of the Send Messages of RCaP used for transferring an iSER Message contains an iSER Header followed by an iSCSI control-type PDU. The iSER header in a Send Message of RCaP carrying an iSCSI control- type PDU MUST have the format as described in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |W|R| | | 0001b |S|S| Reserved | | |V|V| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Write STag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Write Base Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Read STag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Read Base Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: iSER Header Format for iSCSI Control-Type PDU WSV - Write STag Valid flag: 1 bit This flag indicates the validity of the Write STag field and the Write Base Offset field of the iSER Header. If set to one, the Write STag field and the Write Base Offset field in this iSER Header are valid. If set to zero, the Write STag field and the Write Base Offset field in this iSER Header MUST be ignored at the receiver. The Write STag Valid flag is set to one when there is solicited data to be transferred for a SCSI Write or bidirectional command, or when there are non-immediate unsolicited and solicited data to be transferred for the referenced task specified in a Task Management Function Request with the TASK REASSIGN function. RSV - Read STag Valid flag: 1 bit This flag indicates the validity of the Read STag field and the Read Base Offset field of the iSER Header. If set to one, the Read STag field and the Read Base Offset field in this iSER Header
are valid. If set to zero, the Read STag field and the Read Base Offset field in this iSER Header MUST be ignored at the receiver. The Read STag Valid flag is set to one for a SCSI Read or bidirectional command, or a Task Management Function Request with the TASK REASSIGN function. Write STag - Write Steering Tag: 32 bits This field contains the Write STag when the Write STag Valid flag is set to one. For a SCSI Write or bidirectional command, the Write STag is used to Advertise the initiator's I/O Buffer containing the solicited data. For a Task Management Function Request with the TASK REASSIGN function, the Write STag is used to Advertise the initiator's I/O Buffer containing the non-immediate unsolicited data and solicited data. This Write STag is used as the Data Source STag in the resultant RDMA Read operation(s). When the Write STag Valid flag is set to zero, this field MUST be set to zero and ignored on receive. Write Base Offset: 64 bits This field contains the Base Offset associated with the I/O Buffer for the SCSI Write command when the Write STag Valid flag is set to one. When the Write STag Valid flag is set to zero, this field MUST be set to zero and ignored on receive. Read STag - Read Steering Tag: 32 bits This field contains the Read STag when the Read STag Valid flag is set to one. The Read STag is used to Advertise the initiator's Read I/O Buffer of a SCSI Read or bidirectional command, or a Task Management Function Request with the TASK REASSIGN function. This Read STag is used as the Data Sink STag in the resultant RDMA Write operation(s). When the Read STag Valid flag is zero, this field MUST be set to zero and ignored on receive. Read Base Offset: 64 bits This field contains the Base Offset associated with the I/O Buffer for the SCSI Read command when the Read STag Valid flag is set to one. When the Read STag Valid flag is set to zero, this field MUST be set to zero and ignored on receive. Reserved: Reserved fields MUST be set to zero on transmit and MUST be ignored on receive.
9.3. iSER Header Format for iSER Hello Message
An iSER Hello Message MUST only contain the iSER header, which MUST have the format as described in Figure 4. If iSERHelloRequired is negotiated to "Yes", then iSER Hello Message is the first iSER Message sent on the RCaP Stream from the iSER layer at the initiator to the iSER layer at the target. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | 0010b | Rsvd | MaxVer| MinVer| iSER-IRD | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: iSER Header Format for iSER Hello Message MaxVer - Maximum Version: 4 bits This field specifies the maximum version of the iSER protocol supported. It MUST be set to 10 to indicate the version of the specification described in this document. MinVer - Minimum Version: 4 bits This field specifies the minimum version of the iSER protocol supported. It MUST be set to 10 to indicate the version of the specification described in this document. iSER-IRD: 16 bits This field contains the value of the iSER-IRD at the initiator. Reserved (Rsvd): Reserved fields MUST be set to zero on transmit and MUST be ignored on receive.
9.4. iSER Header Format for iSER HelloReply Message
An iSER HelloReply Message MUST only contain the iSER header, which MUST have the format as described in Figure 5. If iSERHelloRequired is negotiated to "Yes", then the iSER HelloReply Message is the first iSER Message sent on the RCaP Stream from the iSER layer at the target to the iSER layer at the initiator. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |R| | | | | 0011b |Rsvd |E| MaxVer| CurVer| iSER-ORD | | | |J| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: iSER Header Format for iSER HelloReply Message REJ - Reject flag: 1 bit This flag indicates whether the target is rejecting this connection. If set to one, the target is rejecting the connection. MaxVer - Maximum Version: 4 bits This field specifies the maximum version of the iSER protocol supported. It MUST be set to 10 to indicate the version of the specification described in this document. CurVer - Current Version: 4 bits This field specifies the current version of the iSER protocol supported. It MUST be set to 10 to indicate the version of the specification described in this document.
iSER-ORD: 16 bits This field contains the value of the iSER-ORD at the target. Reserved (Rsvd): Reserved fields MUST be set to zero on transmit and MUST be ignored on receive.9.5. SCSI Data Transfer Operations
The iSER layer at the initiator and the iSER layer at the target handle each SCSI Write, SCSI Read, and bidirectional operation as described below.9.5.1. SCSI Write Operation
The iSCSI layer at the initiator MUST invoke the Send_Control Operational Primitive to request the iSER layer at the initiator to send the SCSI Write Command. The iSER layer at the initiator MUST request the RCaP layer to transmit a Send Message with the message payload consisting of the iSER header followed by the SCSI Command PDU and immediate data (if any). The SendSE Message should be used if supported by the RCaP layer (e.g., iWARP). If there is solicited data, the iSER layer MUST Advertise the Write STag and the Base Offset in the iSER header of the Send Message, as described in Section 9.2. Upon receiving the Send Message, the iSER layer at the target MUST notify the iSCSI layer at the target by invoking the Control_Notify Operational Primitive qualified with the SCSI Command PDU. See Section 7.3.1 for details on the handling of the SCSI Write Command. For the non-immediate unsolicited data, the iSCSI layer at the initiator MUST invoke a Send_Control Operational Primitive qualified with the SCSI Data-Out PDU. Upon receiving each Send Message containing the non-immediate unsolicited data, the iSER layer at the target MUST notify the iSCSI layer at the target by invoking the Control_Notify Operational Primitive qualified with the SCSI Data-Out PDU. See Section 7.3.4 for details on the handling of the SCSI Data- Out PDU. For the solicited data, when the iSCSI layer at the target has an I/O Buffer available, it MUST invoke the Get_Data Operational Primitive qualified with the R2T PDU. See Section 7.3.6 for details on the handling of the R2T PDU.
When the data transfer associated with this SCSI Write operation is complete, the iSCSI layer at the target MUST invoke the Send_Control Operational Primitive when it is ready to send the SCSI Response PDU. Upon receiving a Send Message containing the SCSI Response PDU, the iSER layer at the initiator MUST notify the iSCSI layer at the initiator by invoking the Control_Notify Operational Primitive qualified with the SCSI Response PDU. See Section 7.3.2 for details on the handling of the SCSI Response PDU.9.5.2. SCSI Read Operation
The iSCSI layer at the initiator MUST invoke the Send_Control Operational Primitive to request the iSER layer at the initiator to send the SCSI Read Command. The iSER layer at the initiator MUST request the RCaP layer to transmit a Send Message with the message payload consisting of the iSER header followed by the SCSI Command PDU. The SendSE Message should be used if supported by the RCaP layer (e.g., iWARP). The iSER layer at the initiator MUST Advertise the Read STag and the Base Offset in the iSER header of the Send Message, as described in Section 9.2. Upon receiving the Send Message, the iSER layer at the target MUST notify the iSCSI layer at the target by invoking the Control_Notify Operational Primitive qualified with the SCSI Command PDU. See Section 7.3.1 for details on the handling of the SCSI Read Command. When the requested SCSI data is available in the I/O Buffer, the iSCSI layer at the target MUST invoke the Put_Data Operational Primitive qualified with the SCSI Data-In PDU. See Section 7.3.5 for details on the handling of the SCSI Data-In PDU. When the data transfer associated with this SCSI Read operation is complete, the iSCSI layer at the target MUST invoke the Send_Control Operational Primitive when it is ready to send the SCSI Response PDU. The SendInvSE Message should be used if supported by the RCaP layer (e.g., iWARP). Upon receiving the Send Message containing the SCSI Response PDU, the iSER layer at the initiator MUST notify the iSCSI layer at the initiator by invoking the Control_Notify Operational Primitive qualified with the SCSI Response PDU. See Section 7.3.2 for details on the handling of the SCSI Response PDU.9.5.3. Bidirectional Operation
The initiator and the target handle the SCSI Write and the SCSI Read portions of this bidirectional operation the same as described in Sections 9.5.1 and 9.5.2, respectively.
10. iSER Error Handling and Recovery
RCaP provides the iSER layer with reliable in-order delivery. Therefore, the error management needs of an iSER-assisted connection are somewhat different than those of a Traditional iSCSI connection.10.1. Error Handling
iSER error handling is described in the following sections, classified loosely based on the sources of errors: 1. Those originating at the transport layer (e.g., TCP). 2. Those originating at the RCaP layer. 3. Those originating at the iSER layer. 4. Those originating at the iSCSI layer.10.1.1. Errors in the Transport Layer
If the transport layer is TCP, then TCP packets with detected errors are silently dropped by the TCP layer and result in retransmission at the TCP layer. This has no impact on the iSER layer. However, connection loss (e.g., link failure) and unexpected termination (e.g., TCP graceful or abnormal close without the iSCSI Logout exchanges) at the transport layer will cause the iSCSI/iSER connection to be terminated as well.10.1.1.1. Failure in the Transport Layer Before RCaP Mode is Enabled
If the connection is lost or terminated before the iSCSI layer invokes the Allocate_Connection_Resources Operational Primitive, the login process is terminated and no further action is required. If the connection is lost or terminated after the iSCSI layer has invoked the Allocate_Connection_Resources Operational Primitive, then the iSCSI layer MUST request the iSER layer to deallocate all connection resources by invoking the Deallocate_Connection_Resources Operational Primitive.
10.1.1.2. Failure in the Transport Layer After RCaP Mode is Enabled
If the connection is lost or terminated after the iSCSI layer has invoked the Enable_Datamover Operational Primitive, the iSER layer MUST notify the iSCSI layer of the connection loss by invoking the Connection_Terminate_Notify Operational Primitive. Prior to invoking the Connection_Terminate_Notify Operational Primitive, the iSER layer MUST perform the actions described in Section 5.2.3.2.10.1.2. Errors in the RCaP Layer
The RCaP layer does not have error recovery operations built in. If errors are detected at the RCaP layer, the RCaP layer will terminate the RCaP Stream and the associated connection.10.1.2.1. Errors Detected in the Local RCaP Layer
If an error is encountered at the local RCaP layer, the RCaP layer MAY send a Send Message to the Remote Peer to report the error if possible. (For iWARP, see [RDMAP] for the list of errors where a Terminate Message is sent.) The RCaP layer is responsible for terminating the connection. After the RCaP layer notifies the iSER layer that the connection is terminated, the iSER layer MUST notify the iSCSI layer by invoking the Connection_Terminate_Notify Operational Primitive. Prior to invoking the Connection_Terminate_Notify Operational Primitive, the iSER layer MUST perform the actions described in Section 5.2.3.2.10.1.2.2. Errors Detected in the RCaP Layer at the Remote Peer
If an error is encountered at the RCaP layer at the Remote Peer, the RCaP layer at the Remote Peer may send a Send Message to report the error if possible. If it is unable to send a Send Message, the connection is terminated. This is treated the same as a failure in the transport layer after RDMA is enabled, as described in Section 10.1.1.2. If an error is encountered at the RCaP layer at the Remote Peer and it is able to send a Send Message, the RCaP layer at the Remote Peer is responsible for terminating the connection. After the local RCaP layer notifies the iSER layer that the connection is terminated, the iSER layer MUST notify the iSCSI layer by invoking the Connection_Terminate_Notify Operational Primitive. Prior to invoking the Connection_Terminate_Notify Operational Primitive, the iSER layer MUST perform the actions described in Section 5.2.3.2.
10.1.3. Errors in the iSER Layer
The error handling due to errors at the iSER layer is described in the following sections.10.1.3.1. Insufficient Connection Resources to Support RCaP at Connection Setup
After the iSCSI layer at the initiator invokes the Allocate_Connection_Resources Operational Primitive during the iSCSI login negotiation phase, if the iSER layer at the initiator fails to allocate the connection resources necessary to support RCaP, it MUST return a status of failure to the iSCSI layer at the initiator. The iSCSI layer at the initiator MUST terminate the connection as described in Section 5.2.3.1. After the iSCSI layer at the target invokes the Allocate_Connection_Resources Operational Primitive during the iSCSI login negotiation phase, if the iSER layer at the target fails to allocate the connection resources necessary to support RCaP, it MUST return a status of failure to the iSCSI layer at the target. The iSCSI layer at the target MUST send a Login Response with a Status- Class of 0x03 (Target Error), and a Status-Code of 0x02 (Out of Resources). The iSCSI layers at the initiator and the target MUST terminate the connection as described in Section 5.2.3.1.10.1.3.2. iSER Negotiation Failures
If iSERHelloRequired is negotiated to "Yes" and the RCaP or iSER related parameters declared by the initiator in the iSER Hello Message are unacceptable to the iSER layer at the target, the iSER layer at the target MUST set the Reject (REJ) flag, as described in Section 9.4, in the iSER HelloReply Message. The following are the cases when the iSER layer MUST set the REJ flag to 1 in the HelloReply Message: * The initiator-declared iSER-IRD value is greater than 0, and the target-declared iSER-ORD value is 0. * The initiator-supported and the target-supported iSER protocol versions do not overlap. After requesting the RCaP layer to send the iSER HelloReply Message, the handling of the error situation is the same as that for iSER format errors as described in Section 10.1.3.3.
10.1.3.3. iSER Format Errors
The following types of errors in an iSER header are considered format errors: * Illegal contents of any iSER header field * Inconsistent field contents in an iSER header * Length error for an iSER Hello or HelloReply Message (see Sections 9.3 and 9.4) When a format error is detected, the following events MUST occur in the specified sequence: 1. The iSER layer MUST request the RCaP layer to terminate the RCaP Stream. The RCaP layer MUST terminate the associated connection. 2. The iSER layer MUST notify the iSCSI layer of the connection termination by invoking the Connection_Terminate_Notify Operational Primitive. Prior to invoking the Connection_Terminate_Notify Operational Primitive, the iSER layer MUST perform the actions described in Section 5.2.3.2.10.1.3.4. iSER Protocol Errors
If iSERHelloRequired is negotiated to "Yes", then the first iSER Message sent by the iSER layer at the initiator MUST be the iSER Hello Message (see Section 9.3). In this case the first iSER Message sent by the iSER layer at the target MUST be the iSER HelloReply Message (see Section 9.4). Failure to send the iSER Hello or HelloReply Message, as indicated by the wrong Opcode in the iSER header, is a protocol error. Conversely, if the iSER Hello Message is sent by the iSER layer at the initiator when iSERHelloRequired is negotiated to "No", the iSER layer at the target MAY treat this as a protocol error or respond with an iSER HelloReply Message. The handling of iSER protocol errors is the same as that for iSER format errors as described in Section 10.1.3.3. If the sending side of an iSER-enabled connection acts in a manner not permitted by the negotiated or declared login/text operational key values as described in Section 6, this is a protocol error and the receiving side MAY handle this the same as for iSER format errors as described in Section 10.1.3.3.
10.1.4. Errors in the iSCSI Layer
The error handling due to errors at the iSCSI layer is described in the following sections. For error recovery, see Section 10.2.10.1.4.1. iSCSI Format Errors
When an iSCSI format error is detected, the iSCSI layer MUST request the iSER layer to terminate the RCaP Stream by invoking the Connection_Terminate Operational Primitive. For more details on connection termination, see Section 5.2.3.1.10.1.4.2. iSCSI Digest Errors
In the iSER-assisted mode, the iSCSI layer will not see any digest error because both the HeaderDigest and the DataDigest keys are negotiated to "None".10.1.4.3. iSCSI Sequence Errors
For Traditional iSCSI, sequence errors are caused by dropped PDUs due to header or data digest errors. Since digests are not used in iSER- assisted mode and the RCaP layer will deliver all messages in the order they were sent, sequence errors will not occur in iSER-assisted mode.10.1.4.4. iSCSI Protocol Error
When the iSCSI layer handles certain protocol errors by dropping the connection, the error handling is the same as that for iSCSI format errors as described in Section 10.1.4.1. When the iSCSI layer uses the iSCSI Reject PDU and response codes to handle certain other protocol errors, no special handling at the iSER layer is required.10.1.4.5. SCSI Timeouts and Session Errors
This is handled at the iSCSI layer, and no special handling at the iSER layer is required.10.1.4.6. iSCSI Negotiation Failures
For negotiation failures that happen during the Login Phase at the initiator after the iSCSI layer has invoked the Allocate_Connection_Resources Operational Primitive and before the Enable_Datamover Operational Primitive has been invoked, the iSCSI layer MUST request the iSER layer to deallocate all connection
resources by invoking the Deallocate_Connection_Resources Operational Primitive. The iSCSI layer at the initiator MUST terminate the connection. For negotiation failures during the Login Phase at the target, the iSCSI layer can use a Login Response with a Status-Class other than 0 (success) to terminate the Login Phase. If the iSCSI layer has invoked the Allocate_Connection_Resources Operational Primitive and has not yet invoked the Enable_Datamover Operational Primitive, the iSCSI layer at the target MUST request the iSER layer at the target to deallocate all connection resources by invoking the Deallocate_Connection_Resources Operational Primitive. The iSCSI layer at both the initiator and the target MUST terminate the connection. During the iSCSI Login Phase, if the iSCSI layer at the initiator receives a Login Response from the target with a Status-Class other than 0 (Success) after the iSCSI layer at the initiator has invoked the Allocate_Connection_Resources Operational Primitive, the iSCSI layer MUST request the iSER layer to deallocate all connection resources by invoking the Deallocate_Connection_Resources Operational Primitive. The iSCSI layer MUST terminate the connection in this case. For negotiation failures during the Full Feature Phase, the error handling is left to the iSCSI layer and no special handling at the iSER layer is required.10.2. Error Recovery
Error recovery requirements of iSCSI/iSER are the same as that of Traditional iSCSI. All three ErrorRecoveryLevels as defined in [iSCSI] are supported in iSCSI/iSER. * For ErrorRecoveryLevel 0, session recovery is handled by iSCSI and no special handling by the iSER layer is required. * For ErrorRecoveryLevel 1, see Section 10.2.1 on PDU Recovery. * For ErrorRecoveryLevel 2, see Section 10.2.2 on Connection Recovery. The iSCSI layer may invoke the Notice_Key_Values Operational Primitive during connection setup to request the iSER layer to take note of the value of the operational ErrorRecoveryLevel, as described in Sections 5.1.1 and 5.1.2.
10.2.1. PDU Recovery
As described in Sections 10.1.4.2 and 10.1.4.3, digest and sequence errors will not occur in the iSER-assisted mode. If the RCaP layer detects an error, it will close the iSCSI/iSER connection, as described in Section 10.1.2. Therefore, PDU recovery is not useful in the iSER-assisted mode. The iSCSI layer at the initiator SHOULD disable iSCSI timeout-driven PDU retransmissions.10.2.2. Connection Recovery
The iSCSI layer at the initiator MAY reassign connection allegiance for non-immediate commands that are still in progress and are associated with the failed connection by using a Task Management Function Request with the TASK REASSIGN function. See Section 7.3.3 for more details. When the iSCSI layer at the initiator does a task reassignment for a SCSI Write command, it MUST qualify the Send_Control Operational Primitive invocation with DataDescriptorOut, which defines the I/O Buffer for both the non-immediate unsolicited data and the solicited data. This allows the iSCSI layer at the target to use recovery R2Ts to request data originally sent as unsolicited and solicited from the initiator. When the iSCSI layer at the target accepts a reassignment request for a SCSI Read command, it MUST request the iSER layer to process SCSI Data-In for all unacknowledged data by invoking the Put_Data Operational Primitive. See Section 7.3.5 on the handling of SCSI Data-In. When the iSCSI layer at the target accepts a reassignment request for a SCSI Write command, it MUST request the iSER layer to process a recovery R2T for any non-immediate unsolicited data and any solicited data sequences that have not been received by invoking the Get_Data Operational Primitive. See Section 7.3.6 on the handling of Ready To Transfer (R2T). The iSCSI layer at the target MUST NOT issue recovery R2Ts on an iSCSI/iSER connection for a task for which the connection allegiance was never reassigned. The iSER layer at the target MAY reject such a recovery R2T received via the Get_Data Operational Primitive invocation from the iSCSI layer at the target, with an appropriate error code.
The iSER layer at the target will process the requests invoked by the Put_Data and Get_Data Operational Primitives for a reassigned task in the same way as for the original commands.