iSER Draft Status draft-ietf-ips-iser-01 Mike Ko March 8, 2005

3/8/2005M. Ko2 Declared Limit to Control the Number of Unexpected PDUs A new key, MaxOutstandingUnexpectedPDUs, can be used by both the initiator and the target to declare the maximum number of outstanding “unexpected” control- type PDUs it can receive For the PDUs listed on slide 3, the PDU is outstanding until the target responds with the corresponding response PDU –NOP-out PDU with ITT = 0xffffffff and TTT /= 0xffffffff (ping echo) is not subject to the declared limit since it is sent as a response to a NOP-in PDU from the target –Similarly, NOP-in PDU with ITT/= 0xffffffff and TTT = 0xffffffff sent as a response to a NOP-out PDU from the initiator is not subject to the limit

3/8/2005M. Ko3 iSCSI Control-Type PDUs from the Initiator Regulated by CmdSN Window If the Initiator sends this PDUIt must provision a buffer for this PDU from the Target SCSI CommandSCSI Response or Reject before the task is active Task Management Function Request Task Management Function Response Text RequestText Response Login RequestLogin Response NOP-out (request) ITT /= 0xffffffff TTT = 0xffffffff NOP-in (response) ITT /= 0xffffffff TTT =0xffffffff

3/8/2005M. Ko4 Handling of Unidirectional NOP-out PDUs at the Initiator For a unidirectional NOP-out PDU from the initiator with ITT = TTT = 0xffffffff, CmdSN is not advanced To retire a unidirectional NOP-out PDU, needs confirmation from the target that the PDU has been processed –A unidirectional NOP-out PDU is outstanding until the target responds with a control-type PDU with ExpCmdSN set to at least x + 1 where x is the CmdSN of the PDU with the immediate flag set For a session with multiple connections, a PDU with no immediate flag and CmdSN=x sent in a different connection could trigger a control-type PDU with ExpCmdSN=x+1 from the target To avoid ambiguity, the control-type PDU from the target with ExpCmdSN=x+1 (or larger) must be received on the same connection as the unidirectional NOP-out PDU in order to retire the NOP-out PDU An implementation note was also added which recommended that “To avoid complexity, a NOP-out PDU with ITT /= 0xffffffff can be used instead”

3/8/2005M. Ko5 Handling of Unidirectional NOP-in PDUs at the Target Similarly, for a NOP-in PDU with ITT = TTT = 0xffffffff and StatSN = x, the PDU is outstanding until the initiator responds with a control-type PDU on the same connection where ExpStatSN is at least x+1 An implementation note was also added which recommended that “To avoid complexity, a NOP-in PDU with TTT /= 0xffffffff can be used instead”

3/8/2005M. Ko6 Changes in -01 Version Section 6.7 was added to describe a new key, MaxOutstandingUnexpectedPDUs, which allows both the initiator and the target to declare the maximum number of outstanding “unexpected” control-type PDUs it can receive Last paragraph in section was modified to clarify that SCSI Data-out is not used for solicited data since an R2T is always transformed into an RDMA Read Request Section 8.3 and 8.4 were added to describe the buffering requirements for the expected and unexpected control- type PDUs and when these PDUs are no longer outstanding –Described the use of the MaxOutstandingUnexpectedPDUs key –Added an implementation note to suggest using NOP-in and NOP-out as ping request and ping response to avoid complexity

3/8/2005M. Ko7 On MaxOutstandUnexpectedPDUs Consensus needed for the following parameters: –Default value is “none” –Minimum value is 2 Rationale: RFC3720 states that “An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI command per connection at any time” –Maximum value is 2**32-1

3/8/2005M. Ko8 Things to Do: IANA Considerations Need to register new keys with IANA –RDMAExtensions –TargetRecvDataSegmentLength –InitiatorRecvDataSegmentLength –MaxOutstandingUnexpectedPDUs Need to indicate in the IANA Considerations section that these new keys are in the “iSCSI extended key registry” –Need to add reminder in the key descriptions that these keys should be used with the X# prefix RFC3720 states in section that “For IANA registered keys the string following X# must be registered with IANA and the use of the key MUST be described by an informational RFC” –Assume the intent is for an “informational RFC” or better

3/8/2005M. Ko9 Things to Do: Generalized Support for IB and SCTP? draft-hufferd-ips-iser-sctp-ib-00.txt described changes/adjustments to be made to the iSER draft to generalize the transport layer to include other RDMA-capable protocol layer –Allows iSCSI/iSER to layer over SCTP version of iWARP, or Infiniband, etc. Only the iSER draft will be affected if the recommendations in draft-hufferd-ips-iser-sctp- ib-00.txt are accepted –No impact to the DA draft