1 / 9

iSER Draft Status

iSER Draft Status. draft-ietf-ips-iser-01 Mike Ko March 8, 2005. Declared Limit to Control the Number of Unexpected PDUs.

denver
Download Presentation

iSER Draft Status

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 M. Ko

  3. iSCSI Control-Type PDUs from the Initiator Regulated by CmdSN Window M. Ko

  4. 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” M. Ko

  5. 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” M. Ko

  6. 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 7.3.4 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 M. Ko

  7. 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 M. Ko

  8. 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 12.22 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 M. Ko

  9. 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 M. Ko

More Related