iSER Draft Status

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

3
iSCSI Control-Type PDUs from the Initiator
Regulated by CmdSN Window
If the Initiator sends this PDU It must provision a buffer for this PDU from the Target
SCSI Command SCSI Response or Reject before the task is active
Task Management Function Request Task Management Function Response
Text Request Text Response
Login Request Login Response
NOP-out (request) ITT / 0xffffffff TTT 0xffffffff NOP-in (response) ITT / 0xffffffff TTT 0xffffffff
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 CmdSNx sent in a
  different connection could trigger a control-type
  PDU with ExpCmdSNx1 from the target
• To avoid ambiguity, the control-type PDU from the
  target with ExpCmdSNx1 (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

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 x1
• An implementation note was also added which
  recommended that To avoid complexity, a NOP-in
  PDU with TTT / 0xffffffff can be used instead

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 MaxOutstandingUnexpectedP
  DUs key
• Added an implementation note to suggest using
  NOP-in and NOP-out as ping request and ping
  response to avoid complexity

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 232-1

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

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