Iser draft status
Download
1 / 9

iSER Draft Status - PowerPoint PPT Presentation


  • 161 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'iSER Draft Status' - denver


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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



Handling of unidirectional nop out pdus at the initiator
Handling of Unidirectional NOP-out PDUs at the Initiator CmdSN Window

  • 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


Handling of unidirectional nop in pdus at the target
Handling of Unidirectional NOP-in PDUs at the Target CmdSN Window

  • 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


Changes in 01 version
Changes in -01 Version CmdSN Window

  • 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


On maxoutstandunexpectedpdus
On MaxOutstandUnexpectedPDUs CmdSN Window

  • 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


Things to do iana considerations
Things to Do: IANA Considerations CmdSN Window

  • 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


Things to do generalized support for ib and sctp
Things to Do: Generalized Support for IB and SCTP? CmdSN Window

  • 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