summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5043.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5043.txt')
-rw-r--r--doc/rfc/rfc5043.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc5043.txt b/doc/rfc/rfc5043.txt
new file mode 100644
index 0000000..fd15f0b
--- /dev/null
+++ b/doc/rfc/rfc5043.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group C. Bestler, Ed.
+Request for Comments: 5043 Neterion
+Category: Standards Track R. Stewart, Ed.
+ Cisco Systems, Inc.
+ October 2007
+
+
+ Stream Control Transmission Protocol (SCTP)
+ Direct Data Placement (DDP) Adaptation
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document specifies an adaptation layer to provide a Lower Layer
+ Protocol (LLP) service for Direct Data Placement (DDP) using the
+ Stream Control Transmission Protocol (SCTP).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 1]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1. Adaptation Layer Indicator . . . . . . . . . . . . . . . . 5
+ 5.2. Payload Data Chunks . . . . . . . . . . . . . . . . . . . 6
+ 5.2.1. DDP Source Sequence Number (DDP-SSN) . . . . . . . . . 6
+ 5.2.2. DDP Segment Chunk . . . . . . . . . . . . . . . . . . 7
+ 5.2.3. DDP Stream Session Control . . . . . . . . . . . . . . 7
+ 6. DDP Stream Sessions . . . . . . . . . . . . . . . . . . . . . 8
+ 6.1. Sequencing . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6.2. Legal Sequence: Active/Passive Session Accepted . . . . . 9
+ 6.3. Legal Sequence: Active/Passive Session Rejected . . . . . 9
+ 6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected . 10
+ 6.5. ULP-Specific Sequencing . . . . . . . . . . . . . . . . . 10
+ 6.6. Other Sequencing Rules . . . . . . . . . . . . . . . . . . 10
+ 7. SCTP Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 7.1. Adaptation Layer Indication Restriction . . . . . . . . . 11
+ 7.2. Multihoming Implications . . . . . . . . . . . . . . . . . 11
+ 8. Number of Streams . . . . . . . . . . . . . . . . . . . . . . 12
+ 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10. Sequenced Unordered Operation . . . . . . . . . . . . . . . . 13
+ 11. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 11.1. Association Initialization . . . . . . . . . . . . . . . . 13
+ 11.2. Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . 14
+ 11.3. Association Termination . . . . . . . . . . . . . . . . . 14
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
+ 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 16.1. Normative References . . . . . . . . . . . . . . . . . . . 16
+ 16.2. Informative References . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 2]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+1. Introduction
+
+ This document describes a method to adapt Direct Data Placement
+ [RFC5041] to Stream Control Transmission Protocol (SCTP) [RFC4960].
+
+ Some implementations may include this adaptation layer within their
+ SCTP implementations to obtain maximum performance, but the behavior
+ of SCTP will be unaffected. An SCTP layer used solely by this
+ adaptation layer is able to take certain optimizations based on the
+ limited subset of SCTP capabilities used. In order to allow
+ optimization for these implementations, we specify the use of the new
+ adaptation layer indication as defined in [RFC5061]
+
+1.1. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Definitions
+
+ DDP - See Direct Data Placement Protocol.
+
+ DDP Endpoint - The logical sender/receiver of DDP Segments. An SCTP
+ stream pair is not assumed to have a DDP Endpoint. DDP Segments
+ may only be sent once a DDP Endpoint has been assigned to an SCTP
+ stream pair by a local interface.
+
+ DDP Source Stream Sequence Number (DDP-SSN) - A stream-specific
+ sequence number assigned by the adaptation layer for each SCTP
+ Data Chunk sent. This is the order that chunks were submitted to
+ SCTP, no matter in what order they are actually sent or received.
+
+ DDP Segment - The smallest unit of data transfer for the DDP
+ protocol. It includes a DDP Header and ULP Payload (if present).
+ A DDP Segment should be sized to fit within the Lower Layer
+ Protocol MULPDU (Marker PDU Aligned (MPA) Upper Layer PDU).
+
+ DDP Segment Chunk - An SCTP Payload Data Chunk that encapsulates the
+ DDP-SSN and a DDP Segment.
+
+ DDP Stream - A sequence of DDP Segments whose ordering is defined by
+ the LLP. For SCTP, a DDP stream maps directly to a bidirectional
+ pair of SCTP streams with the same Stream IDs. Note that DDP has
+ no ordering guarantees between DDP streams.
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 3]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ DDP Stream Session - A single pairing of DDP Endpoints over a DDP
+ stream that lasts from an Initiation message through the
+ Termination message(s).
+
+ DDP Stream Session Control Message - A message that is used to
+ control the association of the DDP Endpoint with the DDP stream.
+
+ Direct Data Placement Protocol (DDP) - A wire protocol that supports
+ Direct Data Placement by associating explicit memory buffer
+ placement information with the LLP payload units.
+
+ Lower Layer Protocol (LLP) - In the context of DDP, the protocol
+ layer beneath RDMA that provides a reliable transport service.
+ The SCTP DDP adaption is one of the initially defined LLPs for
+ DDP.
+
+ Protection Domain - A common local interface convention to control
+ which Steering Tags (STags) are valid with which DDP Endpoints.
+ Under this convention, both the Steering Tag and DDP Endpoint are
+ created within the context of a Protection Domain, and the
+ Steering Tag may only be enabled for DDP Endpoints created under
+ the same Protection Domain.
+
+ RDMA - Remote Direct Memory Access.
+
+ RNIC - RDMA Network Interface Card.
+
+ SCTP association - A protocol relationship between two SCTP
+ endpoints. An SCTP association supports multiple SCTP streams.
+
+ SCTP Data Chunk - An SCTP Chunk used to convey Payload Data. There
+ can be multiple Chunks within each SCTP packet. Other Chunks are
+ used to control the SCTP Association.
+
+ SCTP endpoint - The logical sender/receiver of SCTP packets. On a
+ multihomed host, an SCTP endpoint is represented to its peers as a
+ combination of an SCTP port number and a set of eligible
+ destination transport addresses to which SCTP packets can be sent.
+
+ SCTP Stream - A unidirectional logical channel established from one
+ to another associated SCTP endpoint. There can be multiple SCTP
+ streams within each SCTP association. An SCTP stream is used to
+ form one direction of a DDP stream.
+
+ Transmission Sequence Number (TSN) - A 32-bit sequence number used
+ internally by SCTP. One TSN is attached to each chunk containing
+ user data to permit the receiving SCTP endpoint to acknowledge its
+ receipt and detect duplicate deliveries.
+
+
+
+Bestler & Stewart Standards Track [Page 4]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ Upper Layer Protocol (ULP) - In the context of RDMA protocol
+ specifications, this is the layer using RDMA services. Typically,
+ this is an application or middleware. A primary goal of RDMA
+ protocols is to enable direct transfer of payload to/from ULP
+ Buffers.
+
+3. Motivation
+
+ This document specifies an adaptation layer which fulfills the
+ requirements of a Lower Layer Protocol (LLP) for DDP using a specific
+ subset of SCTP capabilities.
+
+ The defined protocol is intended to be implementable over existing
+ SCTP stacks, while clearly defining what portions of SCTP are
+ required to enable an implementation to be optimized specifically to
+ support DDP.
+
+4. Overview
+
+ The adaptation layer uses a pair of like-numbered SCTP streams within
+ an SCTP Association to provide a reliable DDP stream between two DDP
+ Endpoints. Except as specifically noted, each DDP Segment submitted
+ by the DDP layer is encoded as a single unordered SCTP Data Chunk.
+ In addition to the DDP Segment, the Data Chunk also contains a
+ sequence number (DDP-SSN) that reflects the order in which DDP
+ submitted the segments for that stream.
+
+ A DDP Stream Session is defined by DDP Stream Session Control Chunks
+ that manage the state of the DDP Stream Session. These Chunks
+ dynamically bind DDP Endpoints to the DDP Stream Session, and DDP
+ Segment Chunks are used to reliably deliver DDP Segments with the
+ session.
+
+5. Data Formats
+
+5.1. Adaptation Layer Indicator
+
+ The DDP/SCTP adaptation layer uses all streams within an SCTP
+ association. An SCTP Association that has had the DDP Adaptation
+ Indication negotiated will carry only SCTP Data Chunks as defined in
+ this document.
+
+ It is presumed that the handling of incoming data chunks for DDP-
+ enabled associations is sufficiently different than for routine SCTP
+ associations that it is undesirable to require support for mixing DDP
+ and non-DDP streams in a single association. More than a single
+ association is required if an application desires to utilize both DDP
+ and non-DDP traffic with the same remote host.
+
+
+
+Bestler & Stewart Standards Track [Page 5]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ We define an Adaptation Indication that MUST appear in the INIT or
+ INIT-ACK with the following format as defined in [RFC5061].
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type =0xC006 | Length = Variable |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Adaptation Indication |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Adaptation Indication:
+
+ The following value has been assigned for DDP.
+
+ DDP - 0x00000001
+
+
+5.2. Payload Data Chunks
+
+ The DDP SCTP adaptation uses two types of SCTP Payload Data Chunks,
+ differentiated by the Payload Protocol Identifier:
+
+ DDP Segment Chunks are used to reliably deliver DDP Segments sent
+ between DDP Endpoints.
+
+ DDP Stream Session Control Messages are used to establish and tear
+ down DDP Stream Sessions, specifically by controlling the binding
+ of DDP Endpoints with SCTP streams.
+
+
+ Payload Protocol Identifier:
+
+ The following value are defined for DDP in this document
+ and have been assigned by IANA:
+
+ DDP Segment Chunk - 16
+ DDP Stream Session Control - 17
+
+
+5.2.1. DDP Source Sequence Number (DDP-SSN)
+
+ All SCTP Payload Data Chunks used by this adaptation layer include a
+ DDP Source Sequence Number (DDP-SSN). The DDP-SSN tracks the
+ sequence in which the messages were submitted to the SCTP layer for
+ the SCTP stream in use. 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.
+
+
+
+Bestler & Stewart Standards Track [Page 6]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ The rationale for specifying the DDP-SSN is as follows:
+
+ o The SCTP Stream Sequence Number (SSN) is not suitable for this
+ purpose because all messages defined by this document use
+ unordered Payload Data Chunks to ensure prompt delivery from the
+ receiving SCTP layer.
+
+ o The SCTP Transmission Sequence Number (TSN) is not suitable for
+ determining the original order of Data Chunks within a stream.
+ The sending SCTP layer is allowed to optimize the transmission
+ sequence of unordered Data Chunks to encourage Chunk Bundling, or
+ for other purposes.
+
+5.2.2. DDP Segment Chunk
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DDP-SSN | DDP Segment |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+ | |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ DDP Segments are as defined in [RFC5041]. The DDP Segment Chunk
+ serves the same purpose as the MPA [RFC5044] Upper Layer PDU (MULPDU)
+ in that it carries DDP Segments over a reliable protocol with added
+ sequencing information.
+
+5.2.3. DDP Stream Session Control
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DDP-SSN | Function Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Private Data (Dependent on Function Code) |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The following function code values are defined for DDP in
+ this document:
+
+ DDP Stream Session Initiate - 0x001
+ DDP Stream Session Accept - 0x002
+ DDP Stream Session Reject - 0x003
+ DDP Stream Session Terminate - 0x004
+
+
+
+
+Bestler & Stewart Standards Track [Page 7]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ ULP-supplied Private Data MUST be included for DDP Stream Session
+ Initiate, DDP Stream Session Accept, and DDP Stream Session Reject
+ messages. However, the ULP supplied Private DATA MAY be of zero
+ length.
+
+ Private Data length MUST NOT exceed 512 bytes in any message.
+
+ Private Data MUST NOT be included in the DDP Stream Session Terminate
+ message.
+
+ Received DDP Stream Session Control messages SHOULD be reported to
+ the ULP. If reported, any supplied Private Data MUST be available
+ for the ULP to examine.
+
+ The DDP/SCTP adaptation layer MAY limit the number of Session
+ Initiate requests that it has submitted to the ULP. When a DDP
+ Stream Session Initiate cannot be forwarded to the ULP due to such a
+ limit, the adaptation layer MUST respond with a DDP Stream Session
+ Terminate message.
+
+6. DDP Stream Sessions
+
+ A DDP Endpoint is the logical sender/receiver of DDP Segments. A DDP
+ stream connects two DDP Endpoints using a matched pair of SCTP
+ streams having the same SCTP Stream Identifiers.
+
+ A DDP Stream Session defines the sequence of Data Chunks exchanged
+ between two DDP Endpoints over a DDP stream that has a distinct
+ beginning and end as defined in the following section. Data Chunks
+ from one DDP Stream Session are never carried over to the next
+ session. Each Data Chunk unambiguously belongs to exactly one
+ session. The DDP-SSNs assigned to the Data Chunks for a session MUST
+ NOT have any gaps.
+
+ The local interface MAY dynamically associate a DDP Endpoint with the
+ DDP stream based upon the initial exchanges of a DDP Session, and
+ dynamically terminate that association at the session's end.
+ Alternately, a specialized local interface could simply statically
+ map DDP Endpoints to DDP streams.
+
+ Conventionally, local interfaces for RDMA have deferred the selection
+ of the DDP Endpoint until after the ULP decides to accept an RDMA
+ connection request. But that is a local interface choice and not a
+ wire protocol requirement.
+
+ A DDP stream is associated with at most one Protection Domain during
+ a single DDP Stream Session. On the passive side, the association is
+ typically deferred until the DDP Stream Session Accept message.
+
+
+
+Bestler & Stewart Standards Track [Page 8]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+6.1. Sequencing
+
+ The DDP-SSN is reset to zero at the beginning of each DDP Stream
+ Session.
+
+ The normative sequence for considering Payload Data Chunks within a
+ given session is based upon each Data Chunk's DDP-SSN. When
+ considered in this normative sequence, all sessions MUST conform to
+ one of the patterns defined in this section.
+
+ If the adaptation layer receives a Payload Data Chunk that conforms
+ to none of the enumerated legal patterns, the DDP Stream Session MUST
+ be terminated.
+
+6.2. Legal Sequence: Active/Passive Session Accepted
+
+ In this DDP Stream Session sequence, one DDP Endpoint assumes the
+ active role in requesting a DDP Stream Session, which the other side
+ accepts.
+
+ Active side sends a DDP Stream Session Initiate message.
+
+ Passive side sends a DDP Stream Session Accept message.
+
+ Each side may then send zero or more DDP Segments with increasing
+ DDP-SSNs, subject to any flow control imposed by other protocol
+ layers.
+
+ The final User Data Chunk for each side MAY be a DDP Stream
+ Terminate. At least one side MUST send a DDP Stream Terminate.
+ Note that this would follow any RDMAP Terminate message, which to
+ the adaptation layer is simply another DDP Segment.
+
+6.3. Legal Sequence: Active/Passive Session Rejected
+
+ DDP Stream Sessions allow each party to send a single non-payload
+ message before the other end commits specific resources to the
+ session. This allows each end to determine which resources are to be
+ used, and how they are to be configured, or even if the session
+ should be granted.
+
+ These decisions MAY be influenced by the need to assign a specific
+ Protection Domain, to determine how many RDMA Read Credits are
+ required, or to determine how many receive operations the ULP should
+ enable.
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 9]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ Because of these or other factors, the passive side MAY choose to
+ reject a DDP Stream Session Request. This results in the following
+ legal sequence:
+
+ Active side sends a DDP Stream Session Initiate message.
+
+ Passive side sends a DDP Stream Session Reject message.
+
+ A DDP Stream Session Reject message MUST NOT be sent unless the
+ rejection is at the direction of the ULP.
+
+6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected
+
+ Acceptance or rejection of DDP Stream Session Initiate messages
+ SHOULD be under the control of the ULP. This MAY require passing an
+ event to the ULP. There MUST be a finite limit on the number of such
+ requests that are pending a ULP decision. When more session requests
+ are received, the passive side MUST respond to the Initiate message
+ with a DDP Stream Terminate Message.
+
+6.5. ULP-Specific Sequencing
+
+ An implementation MAY choose to support additional ULP-specific
+ sequences, but MUST NOT do so unless requested to do so by the ULP.
+
+ A defined ULP MUST be able to operate using only the defined
+ mandatory session sequences. Any additional sequences must be used
+ only for optional optimizations.
+
+6.6. Other Sequencing Rules
+
+ 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 DDP Stream Session.
+
+ An active side of a DDP Stream Session MUST NOT send a DDP Segment
+ that might be received before the DDP Stream Session Initiate
+ message.
+
+ This MAY be determined by SCTP acking of the Data Chunk used to carry
+ the DDP Stream Session Initiate message, or by receipt of a
+ responsive DDP Stream Session Control message.
+
+ A DDP Stream Identifier MUST NOT be reused for another DDP Stream
+ Session while any Data Chunk from a prior session might be
+ outstanding.
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 10]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+7. SCTP Endpoints
+
+7.1. Adaptation Layer Indication Restriction
+
+ The local interface MUST allow the ULP to specify an SCTP endpoint to
+ use a specific Adaptation Indication. It MAY require the ULP to do
+ so.
+
+ Once an endpoint decides on its acceptable Adaptation Indication(s),
+ it SHOULD terminate all requests to establish an association with any
+ different Adaptation Indication.
+
+ An SCTP implementation MAY choose to accept association requests for
+ a given SCTP endpoint only until one association for the endpoint has
+ been established. At that point, it MAY choose to restrict all
+ further associations for the same endpoint to use the same Adaptation
+ Indication.
+
+7.2. Multihoming Implications
+
+ SCTP allows an SCTP endpoint to be associated with multiple IP
+ addresses, potentially representing different interface devices.
+ Distribution of the logic for a single DDP stream across multiple
+ input devices can be very undesirable, resulting in complex cache
+ coherency challenges. Therefore, the local interface MAY restrict
+ DDP-enabled SCTP endpoints to a single IP address, or to a set of IP
+ addresses that are all assigned to the same input device ("RNIC").
+
+ The default binding of a DDP-enabled SCTP endpoint SHOULD NOT cover
+ more than a single IP address unless doing so results in neither
+ additional bus traffic nor duplication of memory registration
+ resources. This will frequently result in a different default than
+ for SCTP endpoints that are not DDP enabled.
+
+ Applications MAY choose to avoid using out-of-band methods for
+ communicating the set of IP addresses used by an SCTP endpoint when
+ there is potential confusion as to the intended scope of the SCTP
+ endpoint. For example, assuming the SCTP endpoint consists of all IP
+ addresses Advertised by DNS may work for a general purpose SCTP
+ endpoint but not a DDP-enabled one.
+
+ Even when multihoming is supported, ULPs are cautioned that they
+ SHOULD NOT use ULP control of the source address in an attempt to
+ load-balance a stream across multiple paths. A receiving DDP/SCTP
+ implementation that chooses to support multihoming SHOULD optimize
+ its design on the assumption that multihoming will be used for
+ network fault tolerance, and not to load-balance between paths. This
+ is consistent with recommended SCTP practices.
+
+
+
+Bestler & Stewart Standards Track [Page 11]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+8. Number of Streams
+
+ DDP streams are bidirectional. They are always composed by pairing
+ the inbound and outbound SCTP streams with the same SCTP Stream
+ Identifier.
+
+ The adaptation layer should request the maximum number of SCTP
+ streams it will wish to use over the lifetime of the association.
+ SCTP streams must still be bound to DDP Endpoints, and a DDP-enabled
+ SCTP association does not support ordered Data Chunks. Therefore,
+ the mere existence of an SCTP stream is unlikely to require
+ significant supporting resources.
+
+ This mapping uses an SCTP association to carry one or more DDP
+ streams. Each DDP stream will be mapped to a pair of SCTP streams
+ with the same SCTP stream number. The adaptation MUST initialize all
+ of its SCTP associations with the same number of inbound and outbound
+ streams.
+
+9. Fragmentation
+
+ A DDP/SCTP Receiver already deals with fragmentation at both the IP
+ and DDP layers. Therefore, use of SCTP layer segmenting will be
+ avoided for most cases.
+
+ As a Lower Layer Protocol (LLP) for DDP, the SCTP adaptation layer
+ MUST inform the DDP layer of the maximum DDP Segment size that will
+ be supported. This should be the largest value that can be supported
+ without use of IP or SCTP fragmentation, or 516 bytes, whichever is
+ larger.
+
+ A minimum of 516 bytes is required to allow a DDP Stream Session
+ Control Message with 512 bytes of Private Data.
+
+ SCTP data chunk fragmentation MUST NOT be used unless the alternative
+ is IP fragmentation.
+
+ The SCTP adaptation layer SHOULD set the maximum DDP Segment size
+ below the theoretical maximum in order to allow bundling of Control
+ Chunks in the same SCTP packet.
+
+ The SCTP adaptation layer MUST reject DDP Segments that are larger
+ than the maximum size specified.
+
+
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 12]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+10. Sequenced Unordered Operation
+
+ The adaptation layer MUST use the Unordered option on all Data Chunks
+ (U Flag set to one). The SCTP layer is expected to deliver unordered
+ Data Chunks without delay.
+
+ Because DDP employs unordered SCTP delivery, the receiver MUST NOT
+ rely upon the SCTP Transmission Sequence Number (TSN) to imply
+ ordering of DDP Segments. The fact that the SCTP Data Chunk for a
+ DDP Segment is prior to the cumulative ack point does not guarantee
+ that all prior DDP segments have been placed. The SCTP sender is not
+ obligated to transmit unordered Data Chunks in the order presented.
+
+ The DDP-SSN can be used without special logic to determine the
+ submission sequence when the maximum number of in-flight messages is
+ less than 32768. This also applies if the sending SCTP accepts no
+ more than 32767 Data Chunks for a single stream without assigning
+ TSNs.
+
+ If SCTP does accept more than 32768 Data chunks for a single stream
+ without assigning TSNs, the sending DDP must simply refrain from
+ sending more than 32767 Data Chunks for a single stream without
+ acknowledgment. Note that it MUST NOT rely upon ULP flow control for
+ this purpose. Typical ULP flow control will deal exclusively with
+ untagged messages, not with DDP segments.
+
+ The receiver MAY perform a validity check on received DDP-SSNs to
+ ensure that any gap could be accounted for by unreceived Data Chunks.
+ Implementations SHOULD NOT allocate resources on the assumption that
+ DDP-SSNs are valid without first performing such a validity check.
+ An invalid DDP-SSN MAY result in termination of the DDP stream.
+
+11. Procedures
+
+11.1. Association Initialization
+
+ At the startup of an association, a DDP/SCTP adaptation layer MUST
+ include an adaptation layer indication in its INIT or INIT-ACK (as
+ defined in Section 5.1). After the exchange of the initial first two
+ SCTP chunks (INIT and INIT-ACK), an endpoint MUST verify and inspect
+ the Adaptation Indication and compare it to the following table to
+ determine proper action.
+
+
+
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 13]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ Indication | Action
+ type |
+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ | This indicates that the peer DOES NOT
+ NONE | support ANY DDP or RDMA adaptation, and thus
+ | RDMA and DDP procedures MUST NOT be
+ | performed upon this association.
+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ | This indicates that the peer DOES support
+ DDP | the DDP/SCTP adaptation layer defined here.
+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ | This indicates that the peer DOES NOT
+ ANY-OTHER | support the DDP adaptation, and thus
+ Indication | DDP procedures MUST NOT be performed
+ | upon this association.
+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+ An implementation MAY require that all associations for a given SCTP
+ endpoint be placed in the same mode.
+
+ The local interface MAY allow the ULP to accept only requests to
+ establish an association in a specified mode.
+
+11.2. Chunk Bundling
+
+ SCTP allows multiple Data Chunks to be bundled in a single SCTP
+ packet. Data chunks containing DDP Segments with untagged messages
+ SHOULD NOT be delayed to facilitate bundling. Data chunks containing
+ DDP Segments with tagged messages will generally be full sized, and
+ hence not subject to bundling. However, partial-size tagged messages
+ MAY be delayed, as they are frequently followed by a short untagged
+ message.
+
+11.3. Association Termination
+
+ Termination of an SCTP Association due to errors should be handled at
+ the SCTP layer. The RDMAP-defined RDMAP Terminate Message SHOULD NOT
+ be sent on each DDP stream when a determination has been made to
+ terminate an SCTP association. Sending that message on each SCTP
+ stream could severely delay the termination of the association.
+
+ The local interface SHOULD notify all consumers of DDP streams when
+ the underlying SCTP stream has been terminated.
+
+ Other RDMAP-defined Terminate Messages MUST be generated as specified
+ when a DDP stream is terminated. Note that with the SCTP mapping,
+ termination of a DDP Stream does not mandate termination of the
+ Association.
+
+
+
+Bestler & Stewart Standards Track [Page 14]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+12. IANA Considerations
+
+ This document defines a new SCTP Adaptation Layer Indication
+ codepoint for DDP (0x00000001). [RFC5061] creates the registry from
+ which this codepoint has been assigned.
+
+ This document also defines two new SCTP Payload Protocol Identifiers
+ (PPIDs). RFC 4960 [RFC4960] creates the registry from which these
+ identifiers have been assigned. The following values have been
+ assigned:
+
+ DDP Segment Chunk - 16
+ DDP Stream Session Control - 17
+
+13. Security Considerations
+
+ Any direct placement of memory could pose a significant security risk
+ if adequate local controls are not provided. These threats are
+ addressed in the appropriate DDP [RFC5041], RDMA [RFC5040], or
+ Security [RFC5042] documents. This document does not add any
+ additional security risks over those found in RFC 4960 [RFC4960].
+
+ The IPsec requirements for Remote Direct Data Placement (RDDP) are
+ based on the version of IPsec specified in RFC 2401 [RFC2401] and
+ related RFCs, as profiled by RFC 3723 [RFC3723], despite the
+ existence of a newer version of IPsec specified in RFC 4301 [RFC4301]
+ and related RFCs. One of the important early applications of the
+ RDDP protocols is their use with iSCSI iSER [RFC5046]; RDDP's IPsec
+ requirements follow those of IPsec in order to facilitate that usage
+ by allowing a common profile of IPsec to be used with iSCSI and the
+ RDDP protocols. In the future, RFC 3723 may be updated to the newer
+ version of IPsec; the IPsec security requirements of any such update
+ should apply uniformly to iSCSI and the RDDP protocols.
+
+ Additional requirements apply to security for RDDP over SCTP, due to
+ the use of SCTP as the transport protocol. An implementation of
+ IPsec for RDDP over SCTP:
+
+ 1) MUST support IPsec functionality for SCTP equivalent to the IPsec
+ functionality for TCP that is required by RFC 3723,
+
+ 2) SHOULD support the same level of IPsec functionality for SCTP and
+ TCP unless there is no support for TCP, and
+
+ 3) MUST support at least the level of protocol and port selector
+ functionality for SCTP that is supported for TCP.
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 15]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+14. Contributors
+
+ Many thanks to our contributors who have spent many hours reading and
+ reviewing keeping us straight: Sukanta Ganguly an independent
+ consultant, Vivek Kashyap of IBM, Jim Pinkerton of Microsoft, and
+ Hemal Shah of Broadcom. Thanks for all your hard work.
+
+15. Acknowledgments
+
+ The authors would like to thank the following people that have
+ provided comments and input: Stephen Bailey, David Black, Douglas
+ Otis, Allyn Romanow, and Jim Williams.
+
+16. References
+
+16.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
+ Travostino, "Securing Block Storage Protocols over IP",
+ RFC 3723, April 2004.
+
+ [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
+ RFC 4960, September 2007.
+
+ [RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
+ Garcia, "A Remote Direct Memory Access Protocol
+ Specification", RFC 5040, October 2007.
+
+ [RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct
+ Data Placement over Reliable Transports", RFC 5041,
+ October 2007.
+
+ [RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement
+ Protocol (DDP) / Remote Direct Memory Access Protocol
+ (RDMAP) Security", RFC 5042, October 2007.
+
+ [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
+ Kozuka, "Stream Control Transmission Protocol (SCTP)
+ Dynamic Address Reconfiguration", RFC 5061,
+ September 2007.
+
+16.2. Informative References
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+
+
+Bestler & Stewart Standards Track [Page 16]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
+ Carrier, "Marker PDU Aligned Framing for TCP
+ Specification", RFC 5044, October 2007.
+
+ [RFC5046] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., and P.
+ Thaler, "Internet Small Computer System Interface (iSCSI)
+ Extensions for Remote Direct Memory Access (RDMA)",
+ RFC 5046, October 2007.
+
+Authors' Addresses
+
+ Caitlin Bestler (editor)
+ Neterion
+ 20230 Stevens Creek Blvd.
+ Suite C
+ Cupertino, CA 95014
+ USA
+
+ Phone: 408-366-4639
+ EMail: caitlin.bestler@neterion.com
+
+
+ Randall R. Stewart (editor)
+ Cisco Systems, Inc.
+ Forest Drive
+ Columbia, SC 29036
+ USA
+
+ Phone: +1-815-342-5222
+ EMail: rrs@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 17]
+
+RFC 5043 SCTP DDP Adaptation October 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Bestler & Stewart Standards Track [Page 18]
+