iser draft status
Download
Skip this Video
Download Presentation
iSER Draft Status

Loading in 2 Seconds...

play fullscreen
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
  • 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
  • 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
  • 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
  • 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
  • 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?
  • 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

ad