Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
updated by
Extracted elements (26)
All Data Chunks use unordered delivery to ensure prompt delivery from the receiving SCTP layer, avoiding head-of-line blocking that ordered delivery would impose on DDP segments.
DDP-enabled SCTP associations are restricted to a single Adaptation Indication and cannot mix DDP and non-DDP streams, because the handling of incoming DDP data chunks is sufficiently different from routine SCTP that mixing is undesirable.
DDP-SSN is introduced because neither SCTP SSN nor TSN is suitable for tracking submission order: SSN is not assigned to unordered chunks, and TSN ordering is non-deterministic since the SCTP sender may reorder unordered chunks to encourage bundling.
The default binding of a DDP-enabled SCTP endpoint SHOULD NOT cover more than a single IP address, because distributing a single DDP stream across multiple input devices creates complex cache coherency challenges for RNIC implementations.
An SCTP association used for DDP does not support ordered Data Chunks. Applications requiring both DDP and non-DDP traffic with the same remote host must use more than one SCTP association.
A DDP Stream Identifier MUST NOT be reused for another DDP Stream Session while any Data Chunk from a prior session might be outstanding.
A DDP Stream Session Control message MUST NOT be sent if it may be received before a prior DDP Stream Session Control message within the same session. An active side MUST NOT send a DDP Segment that might be received before the Session Initiate message.
A DDP Stream Session Reject message MUST NOT be sent unless the rejection is at the direction of the ULP. There MUST be a finite limit on the number of session requests pending a ULP decision.
At association startup, a DDP/SCTP adaptation layer MUST include an adaptation layer indication in its INIT or INIT-ACK. After the INIT/INIT-ACK exchange, an endpoint MUST verify the Adaptation Indication: NONE or any other value means DDP/RDMA procedures MUST NOT be performed.
IPsec for RDDP over SCTP MUST support IPsec functionality for SCTP equivalent to that required for TCP by RFC 3723, and MUST support at least the level of protocol and port selector functionality for SCTP that is supported for TCP.
SCTP data chunk fragmentation MUST NOT be used unless the alternative is IP fragmentation. The adaptation layer MUST inform DDP of the maximum DDP Segment size (largest value without IP or SCTP fragmentation, or 516 bytes, whichever is larger). The adaptation layer MUST reject DDP Segments larger than the maximum size specified.
The adaptation layer MUST use the Unordered option (U Flag=1) on all Data Chunks. The receiver MUST NOT rely on the SCTP TSN to imply ordering of DDP Segments.
The adaptation MUST initialize all SCTP associations with the same number of inbound and outbound streams.
The DDP-SSN MUST have the same value that the SCTP Stream Sequence Number (SSN) would have been assigned had ordered SCTP Payload Data Chunks been used rather than unordered.
The DDP-SSNs assigned to Data Chunks for a session MUST NOT have any gaps. If a received Payload Data Chunk conforms to none of the legal session patterns, the DDP Stream Session MUST be terminated.
ULP-supplied Private Data MUST be included for DDP Stream Session Initiate, Accept, and Reject messages (though MAY be zero length). Private Data length MUST NOT exceed 512 bytes. Private Data MUST NOT be included in the Terminate message.
When a DDP Stream Session Initiate cannot be forwarded to the ULP due to a pending-request limit, the adaptation layer MUST respond with a DDP Stream Session Terminate message.
When terminating an SCTP Association due to errors, the RDMAP Terminate Message SHOULD NOT be sent on each DDP stream, as doing so could severely delay association termination. Other RDMAP-defined Terminate Messages MUST be generated as specified when a DDP stream is terminated.
The DDP/SCTP adaptation layer uses a pair of like-numbered SCTP streams within an SCTP Association to provide a reliable DDP stream. Each DDP Segment is encoded as a single unordered SCTP Data Chunk, accompanied by a DDP-SSN reflecting submission order.
A new SCTP Adaptation Layer Indication codepoint for DDP (0x00000001) is defined and assigned from the registry created by RFC 5061.
Two SCTP Payload Protocol Identifiers (PPIDs) are assigned for DDP: DDP Segment Chunk (16) and DDP Stream Session Control (17), registered in the SCTP PPID registry created by RFC 4960.
Direct memory placement poses significant security risks if adequate local controls are absent; these are addressed by RFC 5041 (DDP), RFC 5040 (RDMA), and RFC 5042 (Security). This document adds no security risks beyond those in RFC 4960. IPsec requirements for RDDP over SCTP follow RFC 3723 to enable a common profile with iSCSI.
A DDP Stream Session follows defined legal sequences: (1) Active/Passive Accepted — Initiate, Accept, zero or more DDP Segments, at least one Terminate; (2) Active/Passive Rejected — Initiate, Reject; (3) Non-ULP Rejected — Initiate, Terminate (when ULP queue is full). Any chunk sequence not matching a legal pattern triggers session termination.
The Adaptation Layer Indicator is a variable-length chunk with Type=0xC006 and a 32-bit Adaptation Indication field. The DDP value is 0x00000001, and this chunk MUST appear in the INIT or INIT-ACK.
The DDP Segment Chunk consists of a 16-bit DDP-SSN followed by the DDP Segment payload. It serves the same role as the MPA MULPDU, carrying DDP Segments over a reliable transport with added sequencing.
The DDP Stream Session Control message contains a 16-bit DDP-SSN, a 16-bit Function Code, and optional Private Data. Function codes are: Initiate (0x001), Accept (0x002), Reject (0x003), Terminate (0x004).