< draft-ietf-rddp-sctp-06.txt   draft-ietf-rddp-sctp-07.txt >
Remote Direct Data Placement C. Bestler Remote Direct Data Placement C. Bestler
Working Group R. Stewart Working Group R. Stewart
Internet-Draft Editor Internet-Draft Editor
Expires: December 29, 2006 June 27, 2006 Intended status: Informational September 13, 2006
Expires: March 17, 2007
Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP)
Adaptation Adaptation
draft-ietf-rddp-sctp-06.txt draft-ietf-rddp-sctp-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2006. This Internet-Draft will expire on March 17, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies an Adaptation Layer to provide a Lower Layer This document specifies an Adaptation Layer to provide a Lower Layer
Protocol (LLP) service for Direct Data Placement (DDP) using the Protocol (LLP) service for Direct Data Placement (DDP) using the
Stream Control Transmission Protocol (SCTP). Stream Control Transmission Protocol (SCTP).
skipping to change at page 2, line 40 skipping to change at page 2, line 46
9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Sequenced Unordered Operation . . . . . . . . . . . . . . . . 17 10. Sequenced Unordered Operation . . . . . . . . . . . . . . . . 17
11. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Association Initialization . . . . . . . . . . . . . . . . 18 11.1. Association Initialization . . . . . . . . . . . . . . . . 18
11.2. Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . 18 11.2. Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . 18
11.3. Association Termination . . . . . . . . . . . . . . . . . 19 11.3. Association Termination . . . . . . . . . . . . . . . . . 19
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
16. Normative references . . . . . . . . . . . . . . . . . . . . . 23 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 16.1. Normative references . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 16.2. Informative references . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
This document describes a method to adapt Direct Data Placement This document describes a method to adapt Direct Data Placement
[I-D.ietf-rddp-ddp] to Stream Control Transmission Protocol (SCTP) [I-D.ietf-rddp-ddp] to Stream Control Transmission Protocol (SCTP)
[RFC2960]. [RFC2960].
Some implementations may include this adaptation layer within their Some implementations may include this adaptation layer within their
SCTP implementations to obtain maximum performance but the behavior SCTP implementations to obtain maximum performance but the behavior
of SCTP will be unaffected. An SCTP Layer used solely by this of SCTP will be unaffected. An SCTP Layer used solely by this
adaptation layer is able to take certain optimizations based on the adaptation layer is able to take certain optimizations based on the
limited subset of SCTP capabilities used. In order to allow limited subset of SCTP capabilities used. In order to allow
optimization for these implementations we specify the use of the new optimization for these implementations we specify the use of the new
adaptation layer indication as defined in [I-D.ietf-tsvwg-addip-sctp] adaptation layer indication as defined in [I-D.ietf-tsvwg-addip-sctp]
2. Definitions 2. Definitions
DDP - See Direct Data Placement Protocol. DDP - See Direct Data Placement Protocol.
DDP Endpoint - The logical sender/receiver of DDP Segments. An SCTP DDP Endpoint - The logical sender/receiver of DDP Segments. An SCTP
Stream pair is not assumed to have a DDP Endpoint. DDP Segments 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 may only be sent once a DDP Endpoint has been assigned to an SCTP
Stream pair by a local interface. Stream pair by a local interface.
DDP Source Stream Sequence (DDP-SSN) - A stream specific sequence DDP Source Stream Sequence (DDP-SSN) - A stream specific sequence
number assigned by the Adaptation Layer for each SCTP Data Chunk number assigned by the Adaptation Layer for each SCTP Data Chunk
sent. This is the order that chunks were submitted to SCTP, no sent. This is the order that chunks were submitted to SCTP, no
matter what order they are actually sent or received in. matter what order they are actually sent or received in.
DDP Segment - The smallest unit of data transfer for the DDP DDP Segment - The smallest unit of data transfer for the DDP
protocol. It includes a DDP Header and ULP Payload (if present). protocol. It includes a DDP Header and ULP Payload (if present).
A DDP Segment should be sized to fit within the Lower Layer A DDP Segment should be sized to fit within the Lower Layer
Protocol MULPDU. Protocol MULPDU.
DDP Segment Chunk - An SCTP Payload Data Chunk that encapsulates the DDP Segment Chunk - An SCTP Payload Data Chunk that encapsulates the
DDP Stream Sequence (DDP-SSN) and a DDP Segment. DDP-SSN and a DDP Segment.
DDP Stream - a sequence of DDP Segments whose ordering is defined by DDP Stream - a sequence of DDP Segments whose ordering is defined by
the LLP. For SCTP, a DDP Stream maps directly to a bi-directional the LLP. For SCTP, a DDP Stream maps directly to a bi-directional
pair of SCTP streams with the same Stream IDs. Note that DDP has pair of SCTP streams with the same Stream IDs. Note that DDP has
no ordering guarantees between DDP Streams. no ordering guarantees between DDP Streams.
DDP Stream Session - A single pairing of DDP Endpoints over a DDP DDP Stream Session - A single pairing of DDP Endpoints over a DDP
Stream that lasts from a Initiation message through the Stream that lasts from a Initiation message through the
Termination message(s). Termination message(s).
DDP Stream Session Control Message - DDP Stream Session Control DDP Stream Session Control Message - DDP Stream Session Control
messages are used to control the association of the DDP Endpoint messages are used to control the association of the DDP Endpoint
with the DDP Stream. with the DDP Stream.
Direct Data Placement Protocol (DDP) - A wire protocol that supports Direct Data Placement Protocol (DDP) - A wire protocol that supports
Direct Data Placement by associating explicit memory buffer Direct Data Placement by associating explicit memory buffer
placement information with the LLP payload units. placement information with the LLP payload units.
Protection Domain - A common local interface convention to control 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. which Steering Tags (STags) are valid with which DDP Endpoints.
Under this convention both the Steering Tag and DDP Endpoint are Under this convention both the Steering Tag and DDP Endpoint are
created within the context of a Protection Domain, and the created within the context of a Protection Domain, and the
Steering Tag may only be enabled for DDP Endpoints created under Steering Tag may only be enabled for DDP Endpoints created under
the same Protection Domain. the same Protection Domain.
RDMA - Remote Direct Memory Access. RDMA - Remote Direct Memory Access.
RNIC - RDMA Network Interface Card. RNIC - RDMA Network Interface Card.
SCTP association - A protocol relationship between two SCTP SCTP association - A protocol relationship between two SCTP
endpoints. An SCTP association supports multiple SCTP streams. endpoints. An SCTP association supports multiple SCTP streams.
SCTP Data Chunk - An SCTP Chunk used to convey Payload Data. There SCTP Data Chunk - An SCTP Chunk used to convey Payload Data. There
can be multiple Chunks within each SCTP packet. Other Chunks are can be multiple Chunks within each SCTP packet. Other Chunks are
used to control the SCTP Association. used to control the SCTP Association.
SCTP endpoint - The logical sender/receiver of SCTP packets. On a SCTP endpoint - The logical sender/receiver of SCTP packets. On a
multi-homed host, an SCTP endpoint is represented to its peers as multi-homed host, an SCTP endpoint is represented to its peers as
a combination of a SCTP port number and a set of eligible a combination of an SCTP port number and a set of eligible
destination transport addresses to which SCTP packets can be sent. destination transport addresses to which SCTP packets can be sent.
SCTP Stream - A uni-directional logical channel established from one SCTP Stream - A uni-directional logical channel established from one
to another associated SCTP endpoint. There can be multiple SCTP to another associated SCTP endpoint. There can be multiple SCTP
Streams within each SCTP association. An SCTP Stream is used to Streams within each SCTP association. An SCTP Stream is used to
form one direction of a DDP stream. form one direction of a DDP stream.
Transmission Sequence Number (TSN) - A 32-bit sequence number used Transmission Sequence Number (TSN) - A 32-bit sequence number used
internally by SCTP. One TSN is attached to each chunk containing internally by SCTP. One TSN is attached to each chunk containing
user data to permit the receiving SCTP endpoint to acknowledge its user data to permit the receiving SCTP endpoint to acknowledge its
receipt and detect duplicate deliveries. receipt and detect duplicate deliveries.
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. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
4. Introduction 4. Introduction
4.1. Motivation 4.1. Motivation
skipping to change at page 9, line 10 skipping to change at page 9, line 10
DDP Stream Session Control Messages are used to establish and DDP Stream Session Control Messages are used to establish and
teardown DDP Stream Sessions, specifically by controlling the teardown DDP Stream Sessions, specifically by controlling the
binding of DDP endpoints with SCTP streams. binding of DDP endpoints with SCTP streams.
Payload Protocol Identifier: Payload Protocol Identifier:
The following value are defined for DDP in this document, The following value are defined for DDP in this document,
but the final values will be assigned by IANA: but the final values will be assigned by IANA:
DDP Segment Chunk - 0x00000010 DDP Segment Chunk - 16
DDP Stream Session Control - 0x00000011 DDP Stream Session Control - 17
5.2.1. DDP Source Sequence Number (DDP-SSN) 5.2.1. DDP Source Sequence Number (DDP-SSN)
All SCTP Payload Data Chunks used by this Adaptation layer include a All SCTP Payload Data Chunks used by this Adaptation layer include a
DDP Source Sequence Number (DDP-SSN). The DDP-SSN tracks the DDP Source Sequence Number (DDP-SSN). The DDP-SSN tracks the
sequence the messages were submitted to the SCTP layer for the SCTP sequence 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 in use. The DDP-SSN MUST have the same value that the SCTP
Stream Sequence Number (SSN) would have been assigned had ordered Stream Sequence Number (SSN) would have been assigned had ordered
SCTP Payload Data Chunks been used rather than unordered. SCTP Payload Data Chunks been used rather than unordered.
The rationale for specifying the DDP-SSN is as follows: The rationale for specifying the DDP-SSN is as follows:
The SCTP Stream Sequence Number (SSN) is not suitable for this o The SCTP Stream Sequence Number (SSN) is not suitable for this
purpose, because all messages defined by this document use purpose, because all messages defined by this document use
unordered Payload Data Chunks to ensure prompt delivery from the unordered Payload Data Chunks to ensure prompt delivery from the
receiving SCTP layer. receiving SCTP layer.
The SCTP Transmission Sequence Number (TSN) is not suitable for o The SCTP Transmission Sequence Number (TSN) is not suitable for
determine the original order of Data Chunks within a stream. The determine the original order of Data Chunks within a stream. The
sending SCTP layer is allowed to optimize the transmission sending SCTP layer is allowed to optimize the transmission
sequence of unordered Data Chunks to encourage Chunk Bundling, or sequence of unordered Data Chunks to encourage Chunk Bundling, or
other purposes. other purposes.
5.2.2. DDP Segment Chunk 5.2.2. DDP Segment Chunk
0 1 2 3 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 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-SSN | DDP Segment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DDP Segments are as defined in [I-D.ietf-rddp-ddp]. The DDP Segment DDP Segments are as defined in [I-D.ietf-rddp-ddp]. The DDP Segment
Chunk serves the same purpose as the MPA Upper Layer PDU (MULPDU) in Chunk serves the same purpose as the [I-D.ietf-rddp-mpa] Upper Layer
that it carries DDP Segments over a reliable protocol with added PDU (MULPDU) in that it carries DDP Segments over a reliable protocol
sequencing information. with added sequencing information.
5.2.3. DDP Stream Session Control 5.2.3. DDP Stream Session Control
0 1 2 3 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 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 | | DDP-SSN | Function Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Data (Dependent on Function Code) | | Private Data (Dependent on Function Code) |
| ... | | ... |
skipping to change at page 10, line 25 skipping to change at page 10, line 25
The following function code values are defined for DDP in The following function code values are defined for DDP in
this document: this document:
DDP Stream Session Initiate - 0x001 DDP Stream Session Initiate - 0x001
DDP Stream Session Accept - 0x002 DDP Stream Session Accept - 0x002
DDP Stream Session Reject - 0x003 DDP Stream Session Reject - 0x003
DDP Stream Session Terminate - 0x004 DDP Stream Session Terminate - 0x004
ULP supplied Private Data MUST be included for DDP Stream Session ULP supplied Private Data MUST be included for DDP Stream Session
Initiate DDP Stream Session Accept and DDP Stream Session Reject Initiate, DDP Stream Session Accept and DDP Stream Session Reject
messages. However, the ULP supplied Private DATA MAY be of zero messages. However, the ULP supplied Private DATA MAY be of zero
length. length.
Private Data length MUST NOT exceed 512 bytes in any message. Private Data length MUST NOT exceed 512 bytes in any message.
Private Data MUST NOT be included in the DDP Stream Session Terminate Private Data MUST NOT be included in the DDP Stream Session Terminate
message. message.
Received DDP Stream Session Control messages SHOULD be reported to Received DDP Stream Session Control messages SHOULD be reported to
the ULP. If reported, any supplied Private Data MUST be available the ULP. If reported, any supplied Private Data MUST be available
skipping to change at page 11, line 16 skipping to change at page 11, line 16
A DDP Endpoint is the logical sender/receiver of DDP Segments. A DDP A DDP Endpoint is the logical sender/receiver of DDP Segments. A DDP
Stream connects two DDP Endpoints using a matched pair of SCTP Stream connects two DDP Endpoints using a matched pair of SCTP
Streams having the same SCTP Stream Identifiers. Streams having the same SCTP Stream Identifiers.
A DDP Stream Session defines the sequence of Data Chunks exchanged A DDP Stream Session defines the sequence of Data Chunks exchanged
between two DDP Endpoints over a DDP Stream that has a distinct between two DDP Endpoints over a DDP Stream that has a distinct
beginning and end as defined in the following section. Data Chunks beginning and end as defined in the following section. Data Chunks
from one DDP Stream Session are never carried over to the next from one DDP Stream Session are never carried over to the next
session. Each Data Chunk unambiguously belongs to exactly one session. Each Data Chunk unambiguously belongs to exactly one
session. The DDP Source Sequence Numbers assigned to the Data Chunks session. The DDP-SSNs assigned to the Data Chunks for a session MUST
for a session MUST NOT have any gaps. NOT have any gaps.
The local interface MAY dynamically associate a DDP Endpoint with the The local interface MAY dynamically associate a DDP Endpoint with the
DDP Stream based upon the initial exchanges of a DDP Session, and DDP Stream based upon the initial exchanges of a DDP Session, and
dynamically terminate that association at the session's end. dynamically terminate that association at the session's end.
Alternately a specialized local interface could simply statically map Alternately a specialized local interface could simply statically map
DDP Endpoints to DDP Streams. DDP Endpoints to DDP Streams.
Conventionally local interfaces for RDMA have deferred the selection Conventionally local interfaces for RDMA have deferred the selection
of the DDP Endpoint until after the ULP decides to accept an RDMA 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 connection request. But that is a local interface choice and not a
wire protocol requirement. wire protocol requirement.
A DDP Stream is associated with at most one Protection Domain during A DDP Stream is associated with at most one Protection Domain during
a single DDP Stream Session. On the passive side the association is a single DDP Stream Session. On the passive side the association is
typically deferred until the DDP Stream Session Accept message. typically deferred until the DDP Stream Session Accept message.
6.1. Sequencing 6.1. Sequencing
The DDP Source Sequence Number(DDP-SSN) is reset to zero at the The DDP-SSN is reset to zero at the beginning of each DDP Stream
beginning of each DDP Stream Session. Session.
The normative sequence for considering Payload Data Chunks within a The normative sequence for considering Payload Data Chunks within a
given session is based upon each Data Chunk's DDP-SSN. When given session is based upon each Data Chunk's DDP-SSN. When
considered in this normative sequence, all sessions MUST conform to considered in this normative sequence, all sessions MUST conform to
one the patterns defined in this section. one the patterns defined in this section.
If the adaptation layer receives a Payload Data Chunk that conforms If the adaptation layer receives a Payload Data Chunk that conforms
to none of the enumerated legal patterns the DDP Stream Session MUST to none of the enumerated legal patterns the DDP Stream Session MUST
be terminated. be terminated.
skipping to change at page 13, line 28 skipping to change at page 13, line 28
same DDP Stream Session. same DDP Stream Session.
An active side of a DDP Stream Session MUST NOT send a DDP Segment An active side of a DDP Stream Session MUST NOT send a DDP Segment
that might be received before the DDP Stream Session Initiate that might be received before the DDP Stream Session Initiate
message. message.
This MAY be determined by SCTP acking of the Data Chunk used to carry 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 the DDP Stream Session Initiate message, or by receipt of a
responsive DDP Stream Session Control message. responsive DDP Stream Session Control message.
A DDP Stream MUST NOT be re-used for another DDP Stream Session while A DDP Stream Identifier MUST NOT be re-used for another DDP Stream
any Data Chunk from a prior session might be outstanding. Session while any Data Chunk from a prior session might be
outstanding.
7. SCTP Endpoints 7. SCTP Endpoints
7.1. Adaptation Layer Indication Restriction 7.1. Adaptation Layer Indication Restriction
The local interface MUST allow the ULP to specify an SCTP endpoint to 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 use a specific Adaptation Indication. It MAY require the ULP to do
so. so.
Once an endpoint decides on its acceptable Adaptation Indication(s), Once an endpoint decides on its acceptable Adaptation Indication(s),
skipping to change at page 14, line 39 skipping to change at page 14, line 39
coherency challenges. Therefore the local interface MAY restrict coherency challenges. Therefore the local interface MAY restrict
DDP-enabled SCTP endpoints to a single IP address, or to a set of IP 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"). addresses that are all assigned to the same input device ("RNIC").
The default binding of a DDP enabled SCTP endpoint SHOULD NOT cover The default binding of a DDP enabled SCTP endpoint SHOULD NOT cover
more than a single IP address unless doing so results in no more than a single IP address unless doing so results in no
additional bus traffic or duplication of memory registration additional bus traffic or duplication of memory registration
resources. This will frequently result in a different default than resources. This will frequently result in a different default than
for SCTP endpoints that are not DDP enabled. 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 multi-homing is supported, ULPs are cautioned that they Even when multi-homing is supported, ULPs are cautioned that they
SHOULD NOT use ULP control of the source address in attempt to load- SHOULD NOT use ULP control of the source address in attempt to load-
balance a stream across multiple paths. A receiving DDP/SCTP balance a stream across multiple paths. A receiving DDP/SCTP
implementation that chooses to support multi-homing SHOULD optimize implementation that chooses to support multi-homing SHOULD optimize
its design on the assumption that multi-homing will be used for its design on the assumption that multi-homing will be used for
network fault tolerance, and not to load-balance between paths. This network fault tolerance, and not to load-balance between paths. This
is consistent with recommended SCTP practices. is consistent with recommended SCTP practices.
8. Number of Streams 8. Number of Streams
skipping to change at page 20, line 8 skipping to change at page 20, line 8
the underlying SCTP stream has been terminated. the underlying SCTP stream has been terminated.
Other RDMAP defined Terminate Messages MUST be generated as specified Other RDMAP defined Terminate Messages MUST be generated as specified
when a DDP Stream is terminated. Note that with the SCTP mapping, when a DDP Stream is terminated. Note that with the SCTP mapping,
termination of a DDP Stream does not mandate termination of the termination of a DDP Stream does not mandate termination of the
Association. Association.
12. IANA considerations 12. IANA considerations
This document defines a new SCTP Adaptation Layer Indication This document defines a new SCTP Adaptation Layer Indication
codepoint. [I-D.ietf-tsvwg-addip-sctp] creates the registry from codepoint. [I-D.ietf-tsvwg-addip-sctp] will create the registry from
which this codepoint is to be assigned. Any unallocated codepoint which this codepoint is to be assigned. Any unallocated codepoint
may be assigned. The value of one is suggested. may be assigned. The value of one is suggested.
This document also defines two new SCTP Payload Protocol Identifier This document also defines two new SCTP Payload Protocol Identifier
(PPIDs). RFC2960 [RFC2960] creates the registry from which these (PPIDs). RFC2960 [RFC2960] creates the registry from which these
identifiers are to be assigned. The Payload Protocol Identifiers identifiers are to be assigned. The Payload Protocol Identifiers
allocated need to be unique, but have no other requirements. The allocated need to be unique, but have no other requirements. The
following values are suggested: following values are suggested:
DDP Segment Chunk - 0x00000010 DDP Segment Chunk - 16
DDP Stream Session Control - 0x00000011 DDP Stream Session Control - 17
13. Security Considerations 13. Security Considerations
Any direct placement of memory could pose a significant security risk Any direct placement of memory could pose a significant security risk
if adequate local controls are not provided. These threats are if adequate local controls are not provided. These threats are
addressed in the appropriate DDP [I-D.ietf-rddp-ddp], RDMA [I-D.ietf- addressed in the appropriate DDP [I-D.ietf-rddp-ddp], RDMA
rddp-rdmap] or Security [I-D.ietf-rddp-security] drafts. This [I-D.ietf-rddp-rdmap] or Security [I-D.ietf-rddp-security] drafts.
document does not add any additional security risks over those found This document does not add any additional security risks over those
in RFC2960 [RFC2960]. found in RFC2960 [RFC2960].
The IPsec requirements for 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 [I-D.ietf-ips-iser]; 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.
14. Contributors 14. Contributors
Many thanks to our contributors who have spent many hours reading and Many thanks to our contributors who have spent many hours reading and
reviewing keeping us straight: Sukanta Ganguly an independent reviewing keeping us straight: Sukanta Ganguly an independent
consultant, Vivek Kashyap of IBM, Jim Pinkerton of Microsoft, and consultant, Vivek Kashyap of IBM, Jim Pinkerton of Microsoft, and
Hemal Shah of Broadcom. Thanks for all your hard work. Hemal Shah of Broadcom. Thanks for all your hard work.
15. Acknowledgments 15. Acknowledgments
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided comments and input: Stephen Bailey, David Black, Douglas provided comments and input: Stephen Bailey, David Black, Douglas
Otis, Allyn Romanow and Jim Williams. Otis, Allyn Romanow and Jim Williams.
16. Normative references 16. References
16.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004.
[I-D.ietf-rddp-ddp] [I-D.ietf-rddp-ddp]
Shah, H., "Direct Data Placement over Reliable Shah, H., "Direct Data Placement over Reliable
Transports", draft-ietf-rddp-ddp-05 (work in progress), Transports", draft-ietf-rddp-ddp-06 (work in progress),
July 2005. June 2006.
[I-D.ietf-rddp-rdmap] [I-D.ietf-rddp-rdmap]
Recio, R., "A Remote Direct Memory Access Protocol Recio, R., "A Remote Direct Memory Access Protocol
Specification", draft-ietf-rddp-rdmap-06 (work in Specification", draft-ietf-rddp-rdmap-07 (work in
progress), June 2006. progress), September 2006.
[I-D.ietf-rddp-security] [I-D.ietf-rddp-security]
Pinkerton, J., "DDP/RDMAP Security", Pinkerton, J., "DDP/RDMAP Security",
draft-ietf-rddp-security-10 (work in progress), June 2006. draft-ietf-rddp-security-10 (work in progress), June 2006.
[I-D.ietf-tsvwg-addip-sctp] [I-D.ietf-tsvwg-addip-sctp]
Stewart, R., "Stream Control Transmission Protocol (SCTP) Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-15 (work in progress), draft-ietf-tsvwg-addip-sctp-15 (work in progress),
June 2006. June 2006.
16.2. Informative references
[I-D.ietf-rddp-mpa]
Culley, P., "Marker PDU Aligned Framing for TCP
Specification", draft-ietf-rddp-mpa-06 (work in progress),
September 2006.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[I-D.ietf-ips-iser]
Ko, M., "iSCSI Extensions for RDMA Specification",
draft-ietf-ips-iser-05 (work in progress), October 2005.
Authors' Addresses Authors' Addresses
Caitlin Bestler Caitlin Bestler
Editor Editor
Broadcom Corporation Broadcom Corporation
16215 Alton Parkway 16215 Alton Parkway
P.O. Box 57013 P.O. Box 57013
Irvine, CA 92619-7013 Irvine, CA 92619-7013
USA USA
skipping to change at page 25, line 5 skipping to change at page 27, line 5
Randall R. Stewart Randall R. Stewart
Editor Editor
Cisco Systems, Inc. Cisco Systems, Inc.
Forest Drive Forest Drive
Columbia, SC 29036 Columbia, SC 29036
USA USA
Phone: +1-815-342-5222 Phone: +1-815-342-5222
Email: rrs@cisco.com Email: rrs@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 25, line 29 skipping to change at page 27, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 43 change blocks. 
68 lines changed or deleted 125 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/