idnits 2.17.1 draft-ietf-rddp-sctp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 739. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2006) is 6516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ADDIP-Draft' on line 222 ** Obsolete normative reference: RFC 2960 (ref. '2') (Obsoleted by RFC 4960) == Outdated reference: A later version (-07) exists of draft-ietf-rddp-ddp-05 == Outdated reference: A later version (-07) exists of draft-ietf-rddp-rdmap-05 == Outdated reference: A later version (-10) exists of draft-ietf-rddp-security-09 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-15 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Remote Direct Data Placement C. Bestler 3 Working Group R. Stewart 4 Internet-Draft Editor 5 Expires: December 25, 2006 June 23, 2006 7 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) 8 Adaptation 9 draft-ietf-rddp-sctp-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies an Adaptation Layer to provide a Lower Layer 43 Protocol (LLP) service for Direct Data Placement (DDP) using the 44 Stream Control Transmission Protocol (SCTP). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 4. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 53 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 5.1. Adaptation Layer Indicator . . . . . . . . . . . . . . . . 8 56 5.2. Payload Data Chunks . . . . . . . . . . . . . . . . . . . 8 57 5.2.1. DDP Source Sequence Number (DDP-SSN) . . . . . . . . . 9 58 5.2.2. DDP Segment Chunk . . . . . . . . . . . . . . . . . . 9 59 5.2.3. DDP Stream Session Control . . . . . . . . . . . . . . 10 60 6. DDP Stream Sessions . . . . . . . . . . . . . . . . . . . . . 11 61 6.1. Sequencing . . . . . . . . . . . . . . . . . . . . . . . . 11 62 6.2. Legal Sequence: Active/Passive Session Accepted . . . . . 11 63 6.3. Legal Sequence: Active/Passive Session Rejected . . . . . 12 64 6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected . 12 65 6.5. ULP Specific Sequencing . . . . . . . . . . . . . . . . . 13 66 6.6. Other Sequencing Rules . . . . . . . . . . . . . . . . . . 13 67 7. SCTP Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.1. Adaptation Layer Indication Restriction . . . . . . . . . 14 69 7.2. Multihoming Implications . . . . . . . . . . . . . . . . . 14 70 8. Number of Streams . . . . . . . . . . . . . . . . . . . . . . 15 71 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16 72 10. Sequenced Unordered Operation . . . . . . . . . . . . . . . . 17 73 11. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 11.1. Association Initialization . . . . . . . . . . . . . . . . 18 75 11.2. Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . 18 76 11.3. Association Termination . . . . . . . . . . . . . . . . . 19 77 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 81 16. Normative references . . . . . . . . . . . . . . . . . . . . . 23 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 83 Intellectual Property and Copyright Statements . . . . . . . . . . 25 85 1. Introduction 87 This document describes a method to adapt Direct Data Placement [3] 88 to Stream Control Transmission Protocol (SCTP) [2]. 90 Some implementations may include this adaptation layer within their 91 SCTP implementations to obtain maximum performance but the behavior 92 of SCTP will be unaffected. An SCTP Layer used solely by this 93 adaptation layer is able to take certain optimizations based on the 94 limited subset of SCTP capabilities used. In order to allow 95 optimization for these implementations we specify the use of the new 96 adaptation layer indication as defined in [6] 98 2. Definitions 100 DDP - See Direct Data Placement Protocol. 102 DDP Endpoint - The logical sender/receiver of DDP Segments. An SCTP 103 Stream pair is not assumed to have a DDP Endpoint. DDP Segments 104 may only be sent once a DDP Endpoint has been assigned to an SCTP 105 Stream pair by a local interface. 107 DDP Source Stream Sequence (DDP-SSN) - A stream specific sequence 108 number assigned by the Adaptation Layer for each SCTP Data Chunk 109 sent. This is the order that chunks were submitted to SCTP, no 110 matter what order they are actually sent or received in. 112 DDP Segment - The smallest unit of data transfer for the DDP 113 protocol. It includes a DDP Header and ULP Payload (if present). 114 A DDP Segment should be sized to fit within the Lower Layer 115 Protocol MULPDU. 117 DDP Segment Chunk - An SCTP Payload Data Chunk that encapsulates the 118 DDP Stream Sequence (DDP-SSN) and a DDP Segment. 120 DDP Stream - a sequence of DDP Segments whose ordering is defined by 121 the LLP. For SCTP, a DDP Stream maps directly to a bi-directional 122 pair of SCTP streams with the same Stream IDs. Note that DDP has 123 no ordering guarantees between DDP Streams. 125 DDP Stream Session - A single pairing of DDP Endpoints over a DDP 126 Stream that lasts from a Initiation message through the 127 Termination message(s). 129 DDP Stream Session Control Message - DDP Stream Session Control 130 messages are used to control the association of the DDP Endpoint 131 with the DDP Stream. 133 Direct Data Placement Protocol (DDP) - A wire protocol that supports 134 Direct Data Placement by associating explicit memory buffer 135 placement information with the LLP payload units. 137 Protection Domain - A common local interface convention to control 138 which Steering Tags (STags) are valid with which DDP Endpoints. 139 Under this convention both the Steering Tag and DDP Endpoint are 140 created within the context of a Protection Domain, and the 141 Steering Tag may only be enabled for DDP Endpoints created under 142 the same Protection Domain. 144 RDMA - Remote Direct Memory Access. 146 RNIC - RDMA Network Interface Card. 148 SCTP association - A protocol relationship between two SCTP 149 endpoints. An SCTP association supports multiple SCTP streams. 151 SCTP Data Chunk - An SCTP Chunk used to convey Payload Data. There 152 can be multiple Chunks within each SCTP packet. Other Chunks are 153 used to control the SCTP Association. 155 SCTP endpoint - The logical sender/receiver of SCTP packets. On a 156 multi-homed host, an SCTP endpoint is represented to its peers as 157 a combination of a SCTP port number and a set of eligible 158 destination transport addresses to which SCTP packets can be sent. 160 SCTP Stream - A uni-directional logical channel established from one 161 to another associated SCTP endpoint. There can be multiple SCTP 162 Streams within each SCTP association. An SCTP Stream is used to 163 form one direction of a DDP stream. 165 Transmission Sequence Number (TSN) - A 32-bit sequence number used 166 internally by SCTP. One TSN is attached to each chunk containing 167 user data to permit the receiving SCTP endpoint to acknowledge its 168 receipt and detect duplicate deliveries. 170 3. Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC2119 [1]. 176 4. Introduction 178 4.1. Motivation 180 This document specifies an Adaptation Layer which fulfills the 181 requirements of a Lower Layer Protocol (LLP) for DDP using a specific 182 subset of SCTP capabilities. 184 The defined protocol is intended to be implementable over existing 185 SCTP stacks, while clearly defining what portions of SCTP are 186 required to enable an implementation to be optimized specifically to 187 support DDP. 189 4.2. Overview 191 The Adaptation Layer uses a pair of like-numbered SCTP Streams within 192 an SCTP Association to provide a reliable DDP Stream between two DDP 193 Endpoints. Except as specifically noted, each DDP Segment submitted 194 by the DDP Layer is encoded as a single unordered SCTP Data Chunk. 195 In addition to the DDP Segment the Data Chunk also contains a 196 sequence number (DDP-SSN) that reflects the order that DDP submitted 197 the segments in for that stream. 199 A DDP Stream Session is defined by DDP Stream Session Control Chunks 200 that manage the state of the DDP Stream Session. These Chunks 201 dynamically bind DDP Endpoints to the DDP Stream Session, and DDP 202 Segment Chunks are used to reliably deliver DDP Segments with the 203 session. 205 5. Data Formats 207 5.1. Adaptation Layer Indicator 209 The DDP/SCTP Adaptation Layer uses all streams within an SCTP 210 association. An SCTP Association that has had the DDP Adaptation 211 Indication negotiated will carry only SCTP Data Chunks as defined in 212 this document. 214 It is presumed that the handling of incoming data chunks for DDP 215 enabled associations is sufficiently different than for routine SCTP 216 associations that it is undesirable to require support for mixing DDP 217 and non-DDP streams in a single association. More than a single 218 association is required if an application desires to utilize both DDP 219 and non-DDP traffic with the same remote host. 221 We define a adaptation indication which MUST appear in the INIT or 222 INIT-ACK with the following format as defined in [ADDIP-Draft] [6] 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type =0xC006 | Length = Variable | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Adaptation Indication | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Adaptation Indication: 234 The following values are suggested for DDP in this document, but 235 the final value will be assigned by IANA: 237 DDP - 0x00000001 239 5.2. Payload Data Chunks 241 The DDP SCTP adaptation uses two types of SCTP Payload Data Chunks, 242 differentiated by the Payload Protocol Identifier: 244 DDP Segment Chunks are used to reliably deliver DDP Segments sent 245 between DDP Endpoints. 247 DDP Stream Session Control Messages are used to establish and 248 teardown DDP Stream Sessions, specifically by controlling the 249 binding of DDP endpoints with SCTP streams. 251 Payload Protocol Identifier: 253 The following value are defined for DDP in this document, 254 but the final values will be assigned by IANA: 256 DDP Segment Chunk - 0x00000010 257 DDP Stream Session Control - 0x00000011 259 5.2.1. DDP Source Sequence Number (DDP-SSN) 261 All SCTP Payload Data Chunks used by this Adaptation layer include a 262 DDP Source Sequence Number (DDP-SSN). The DDP-SSN tracks the 263 sequence the messages were submitted to the SCTP layer for the SCTP 264 stream in use. The DDP-SSN MUST have the same value that the SCTP 265 Stream Sequence Number (SSN) would have been assigned had ordered 266 SCTP Payload Data Chunks been used rather than unordered. 268 The rationale for specifying the DDP-SSN is as follows: 270 The SCTP Stream Sequence Number (SSN) is not suitable for this 271 purpose, because all messages defined by this document use 272 unordered Payload Data Chunks to ensure prompt delivery from the 273 receiving SCTP layer. 275 The SCTP Transmission Sequence Number (TSN) is not suitable for 276 determine the original order of Data Chunks within a stream. The 277 sending SCTP layer is allowed to optimize the transmission 278 sequence of unordered Data Chunks to encourage Chunk Bundling, or 279 other purposes. 281 5.2.2. DDP Segment Chunk 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | DDP-SSN | DDP Segment | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 288 | | 289 | ... | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 DDP Segments are as defined in [3]. The DDP Segment Chunk serves the 293 same purpose as the MPA Upper Layer PDU (MULPDU) in that it carries 294 DDP Segments over a reliable protocol with added sequencing 295 information. 297 5.2.3. DDP Stream Session Control 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | DDP-SSN | Function Code | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Private Data (Dependent on Function Code) | 305 | ... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 The following function code values are defined for DDP in 309 this document: 311 DDP Stream Session Initiate - 0x001 312 DDP Stream Session Accept - 0x002 313 DDP Stream Session Reject - 0x003 314 DDP Stream Session Terminate - 0x004 316 ULP supplied Private Data MUST be included for DDP Stream Session 317 Initiate DDP Stream Session Accept and DDP Stream Session Reject 318 messages. However, the ULP supplied Private DATA MAY be of zero 319 length. 321 Private Data length MUST NOT exceed 512 bytes in any message. 323 Private Data MUST NOT be included in the DDP Stream Session Terminate 324 message. 326 Received DDP Stream Session Control messages SHOULD be reported to 327 the ULP. If reported, any supplied Private Data MUST be available 328 for the ULP to examine. 330 The DDP/SCTP adaptation layer MAY limit the number of Session 331 Initiate requests that it has submitted to the ULP. When a DDP 332 Stream Session Initiate cannot be forwarded to the ULP due to such a 333 limit the adaptation layer MUST respond with a DDP Stream Session 334 Terminate message. 336 6. DDP Stream Sessions 338 A DDP Endpoint is the logical sender/receiver of DDP Segments. A DDP 339 Stream connects two DDP Endpoints using a matched pair of SCTP 340 Streams having the same SCTP Stream Identifiers. 342 A DDP Stream Session defines the sequence of Data Chunks exchanged 343 between two DDP Endpoints over a DDP Stream that has a distinct 344 beginning and end as defined in the following section. Data Chunks 345 from one DDP Stream Session are never carried over to the next 346 session. Each Data Chunk unambiguously belongs to exactly one 347 session. The DDP Source Sequence Numbers assigned to the Data Chunks 348 for a session MUST NOT have any gaps. 350 The local interface MAY dynamically associate a DDP Endpoint with the 351 DDP Stream based upon the initial exchanges of a DDP Session, and 352 dynamically terminate that association at the session's end. 353 Alternately a specialized local interface could simply statically map 354 DDP Endpoints to DDP Streams. 356 Conventionally local interfaces for RDMA have deferred the selection 357 of the DDP Endpoint until after the ULP decides to accept an RDMA 358 connection request. But that is a local interface choice and not a 359 wire protocol requirement. 361 A DDP Stream is associated with at most one Protection Domain during 362 a single DDP Stream Session. On the passive side the association is 363 typically deferred until the DDP Stream Session Accept message. 365 6.1. Sequencing 367 The DDP Source Sequence Number(DDP-SSN) is reset to zero at the 368 beginning of each DDP Stream Session. 370 The Payload Data Chunks for a given session, when sequenced by their 371 DDP-SSN, MUST follow one of the patterns defined in this section. 373 If the adaptation layer receives a Payload Data Chunk that conforms 374 to none of the enumerated legal patterns the DDP Stream Session MUST 375 be terminated. 377 6.2. Legal Sequence: Active/Passive Session Accepted 379 In this DDP Stream Session sequence one DDP Endpoint assumes the 380 active role in requesting a DDP Stream Session, which the other side 381 accepts. 383 Active Side sends a DDP Stream Session Initiate message. 385 Passive Side sends a DDP Stream Session Accept message. 387 Each side may then send zero or more DDP Segments with increasing 388 DDP-SSNs, subject to any flow control imposed by other protocol 389 layers. 391 The final User Data Chunk for each side MAY be a DDP Stream 392 Terminate. At least one side MUST send a DDP Stream Terminate. 393 Note that this would follow any RDMAP Terminate message, which to 394 the Adaptation layer is simply another DDP Segment. 396 6.3. Legal Sequence: Active/Passive Session Rejected 398 DDP Stream Sessions allow each party to send a single non-payload 399 message before the other end commits specific resources to the 400 session. This allow each end to determine which resources are to be 401 used, and how they are to be configured, or even if the session 402 should be granted. 404 These decision MAY be influenced by the need to assign a specific 405 Protection Domain, to determine how many RDMA Read Credits are 406 required, or to determine now many receive operations the ULP should 407 enable. 409 Because of these, or other, factors the Passive side MAY choose to 410 reject a DDP Stream Session Request. This results in the following 411 legal sequence: 413 Active Side sends a DDP Stream Session Initiate message. 415 Passive Side sends a DDP Stream Session Reject message. 417 An DDP Stream Session Reject message MUST NOT be sent unless the 418 rejection is at the direction of the ULP. 420 6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected 422 Acceptance or rejection of DDP Stream Session Initiate messages 423 SHOULD be under the control of the ULP. This MAY require passing an 424 event to the ULP. There MUST be a finite limit on the number of such 425 requests that are pending a ULP decision. When more session requests 426 are received the passive side MUST respond to the Initiate message 427 with a DDP Stream Terminate Message. 429 6.5. ULP Specific Sequencing 431 An implementation MAY choose to support additional ULP specific 432 sequences, but MUST NOT do so unless requested to do so by the ULP. 434 A defined ULP MUST be able to operate using only the defined 435 mandatory session sequences. Any additional sequences must be used 436 only for optional optimizations. 438 6.6. Other Sequencing Rules 440 A DDP Stream Session Control message MUST NOT be sent if it may be 441 received before a prior DDP Stream Session Control message within the 442 same DDP Stream Session. 444 An active side of a DDP Stream Session MUST NOT send a DDP Segment 445 that might be received before the DDP Stream Session Initiate 446 message. 448 This MAY be determined by SCTP acking of the Data Chunk used to carry 449 the DDP Stream Session Initiate message, or by receipt of a 450 responsive DDP Stream Session Control message. 452 A DDP Stream MUST NOT be re-used for another DDP Stream Session while 453 any Data Chunk from a prior session might be outstanding. 455 7. SCTP Endpoints 457 7.1. Adaptation Layer Indication Restriction 459 The local interface MUST allow the ULP to specify an SCTP endpoint to 460 use a specific Adaptation Indication. It MAY require the ULP to do 461 so. 463 Once an endpoint decides on its acceptable Adaptation Indication(s), 464 it SHOULD terminate all requests to establish an association with any 465 different Adaptation Indication. 467 An SCTP implementation MAY choose to accept association requests for 468 a given SCTP endpoint only until one association for the endpoint has 469 been established. At that point it MAY choose to restrict all 470 further associations for the same endpoint to use the same Adaptation 471 Indication. 473 7.2. Multihoming Implications 475 SCTP allows an SCTP endpoint to be associated with multiple IP 476 addresses, potentially representing different interface devices. 477 Distribution of the logic for a single DDP stream across multiple 478 input devices can be very undesirable, resulting in complex cache 479 coherency challenges. Therefore the local interface MAY restrict 480 DDP-enabled SCTP endpoints to a single IP address, or to a set of IP 481 addresses that are all assigned to the same input device ("RNIC"). 483 The default binding of a DDP enabled SCTP endpoint SHOULD NOT cover 484 more than a single IP address unless doing so results in no 485 additional bus traffic or duplication of memory registration 486 resources. This will frequently result in a different default than 487 for SCTP endpoints that are not DDP enabled. 489 Even when multi-homing is supported, ULPs are cautioned that they 490 SHOULD NOT use ULP control of the source address in attempt to load- 491 balance a stream across multiple paths. A receiving DDP/SCTP 492 implementation that chooses to support multi-homing SHOULD optimize 493 its design on the assumption that multi-homing will be used for 494 network fault tolerance, and not to load-balance between paths. This 495 is consistent with recommended SCTP practices. 497 8. Number of Streams 499 DDP Streams are bidirectional. They are always composed by pairing 500 the inbound and outbound SCTP streams with the same SCTP Stream 501 Identifier. 503 The adaptation layer should request the maximum number of SCTP stream 504 it will wish to use over the lifetime of the association. SCTP 505 streams must still be bound to DDP Endpoints, and a DDP enabled SCTP 506 association does not support ordered Data Chunks. Therefore the mere 507 existence of an SCTP stream is unlikely to require significant 508 supporting resources. 510 This mapping uses an SCTP association to carry one or more DDP 511 Steams. Each DDP Stream will be mapped to a pair of SCTP streams 512 with the same SCTP stream number. The adaptation MUST initialize all 513 of its SCTP associations with the same number of inbound and outbound 514 streams. 516 9. Fragmentation 518 A DDP/SCTP Receiver already deals with fragmentation at both the IP 519 and DDP Layers. Therefore use of SCTP layer segmenting will be 520 avoided for most cases. 522 As a Lower Layer Protocol (LLP) for DDP, the SCTP adaptation layer 523 MUST inform the DDP layer of the maximum DDP Segment size that will 524 be supported. This should be the largest value that can be supported 525 without use of IP or SCTP fragmentation, or 516 bytes, whichever is 526 larger. 528 A minimum of 516 bytes is required to allow a DDP Stream Session 529 Control Message with 512 bytes of Private Data. 531 SCTP data chunk fragmentation MUST NOT be used unless the alternative 532 is IP fragmentation. 534 The SCTP adaptation layer SHOULD set the maximum DDP Segment size 535 below the theoretical maximum in order to allow bundling of Control 536 Chunks in the same SCTP packet. 538 The SCTP adaptation layer MUST reject DDP Segments that are larger 539 than the maximum size specified. 541 10. Sequenced Unordered Operation 543 The Adaptation layer MUST use the Unordered option on all Data Chunks 544 (U Flag set to one). The SCTP Layer is expected to deliver unordered 545 Data Chunks without delay. 547 Because DDP employs unordered SCTP delivery, the receiver MUST NOT 548 rely upon the SCTP Transmission Sequence Number (TSN) to imply 549 ordering of DDP Segments. The fact that the SCTP Data Chunk for a 550 DDP Segment is prior the cumulative ack point does not guarantee that 551 all prior DDP segments have been placed. The SCTP sender is not 552 obligated to transmit unordered Data Chunks in the order presented. 554 The DDP-SSN can be used without special logic to determine the 555 submission sequence when the maximum number of in-flight messages is 556 less than 32768. This also applies if the sending SCTP accepts no 557 more than 32767 Data Chunks for a single stream without assigning 558 TSNs. 560 If SCTP does accept more than 32768 Data chunks for a single stream 561 without assigning TSNs, the sending DDP must simply refrain from 562 sending more than 32767 Data Chunks for a single stream without 563 acknowledgment. Note that it MUST NOT rely upon ULP flow control for 564 this purpose. Typical ULP flow control will deal exclusively with 565 untagged messages, not with DDP segments. 567 The receiver MAY perform a validity check on received DDP-SSNs to 568 ensure that any gap could be accounted for by unreceived Data Chunks. 569 Implementations SHOULD NOT allocate resources on the assumption that 570 DDP-SSNs are valid without first performing such a validity check. 571 An invalid DDP-SSN MAY result in termination of the DDP Stream. 573 11. Procedures 575 11.1. Association Initialization 577 At the startup of an association, a DDP/SCTP Adaptation Layer MUST 578 include an adaptation layer indication in its INIT or INIT-ACK (as 579 defined in Section 5.1. After the exchange of the initial first two 580 SCTP chunks (INIT and INIT-ACK), an endpoint MUST verify and inspect 581 the adaptation indication and compare it to the following table to 582 determine proper action. 584 Indication | Action 585 type | 587 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 588 | This indicates that the peer DOES NOT 589 NONE | support ANY DDP or RDMA adaptation and thus 590 | RDMA and DDP procedures MUST NOT be 591 | performed upon this association. 592 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 593 | This indicates that the peer DOES support 594 DDP | the DDP/SCTP Adaptation Layer defined here. 595 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 596 | This indicates that the peer DOES NOT 597 ANY-OTHER | support the DDP adaptation and thus 598 Indication | DDP procedures MUST NOT be performed 599 | upon this association. 601 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 603 An implementation MAY require that all associations for a given SCTP 604 endpoint be placed in the same mode. 606 The local interface MAY allow the ULP to accept only requests to 607 establish an association in a specified mode. 609 11.2. Chunk Bundling 611 SCTP allows multiple Data Chunks to be bundled in a single SCTP 612 packet. Data chunks containing DDP Segments with untagged messages 613 SHOULD NOT be delayed to facilitate bundling. Data chunks containing 614 DDP Segments with tagged messages will generally be full sized, and 615 hence not subject to bundling. However partial size tagged messages 616 MAY be delayed, as that they are frequently followed by a short 617 untagged message. 619 11.3. Association Termination 621 Termination of an SCTP Association due to errors should be handled at 622 the SCTP layer. The RDMAP defined RDMAP Terminate Message SHOULD NOT 623 be sent on each DDP Stream when a determination has been made to 624 terminate an SCTP association. Sending that message on each SCTP 625 stream could severely delay the termination of the association. 627 The local interface SHOULD notify all consumers of DDP streams when 628 the underlying SCTP stream has been terminated. 630 Other RDMAP defined Terminate Messages MUST be generated as specified 631 when a DDP Stream is terminated. Note that with the SCTP mapping, 632 termination of a DDP Stream does not mandate termination of the 633 Association. 635 12. IANA considerations 637 This document defines a new SCTP Adaptation Layer Indication 638 codepoint. [6] creates the registry from which this codepoint is to 639 be assigned. Any unallocated codepoint may be assigned. The value 640 of one is suggested. 642 This document also defines two new SCTP Payload Protocol Identifier 643 (PPIDs). RFC2960 [2] creates the registry from which these 644 identifiers are to be assigned. The Payload Protocol Identifiers 645 allocated need to be unique, but have no other requirements. The 646 following values are suggested: 648 DDP Segment Chunk - 0x00000010 649 DDP Stream Session Control - 0x00000011 651 13. Security Considerations 653 Any direct placement of memory could pose a significant security risk 654 if adequate local controls are not provided. These threats are 655 addressed in the appropriate DDP [3], RDMA [4] or Security [5] 656 drafts. This document does not add any additional security risks 657 over those found in RFC2960 [2]. 659 14. Contributors 661 Many thanks to our contributors who have spent many hours reading and 662 reviewing keeping us straight: Sukanta Ganguly an independent 663 consultant, Vivek Kashyap of IBM, Jim Pinkerton of Microsoft, and 664 Hemal Shah of Broadcom. Thanks for all your hard work. 666 15. Acknowledgments 668 The authors would like to thank the following people that have 669 provided comments and input: Stephen Bailey, David Black, Douglas 670 Otis, Allyn Romanow and Jim Williams. 672 16. Normative references 674 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 675 Levels", BCP 14, RFC 2119, March 1997. 677 [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 678 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 679 "Stream Control Transmission Protocol", RFC 2960, October 2000. 681 [3] Shah, H., "Direct Data Placement over Reliable Transports", 682 draft-ietf-rddp-ddp-05 (work in progress), July 2005. 684 [4] Recio, R., "An RDMA Protocol Specification", 685 draft-ietf-rddp-rdmap-05 (work in progress), July 2005. 687 [5] Pinkerton, J., "DDP/RDMAP Security", draft-ietf-rddp-security-09 688 (work in progress), May 2006. 690 [6] Stewart, R., "Stream Control Transmission Protocol (SCTP) 691 Dynamic Address Reconfiguration", 692 draft-ietf-tsvwg-addip-sctp-15 (work in progress), June 2006. 694 Authors' Addresses 696 Caitlin Bestler 697 Editor 698 Broadcom Corporation 699 16215 Alton Parkway 700 P.O. Box 57013 701 Irvine, CA 92619-7013 702 USA 704 Phone: 949-926-6383 705 Email: caitlinb@broadcom.com 707 Randall R. Stewart 708 Editor 709 Cisco Systems, Inc. 710 Forest Drive 711 Columbia, SC 29036 712 USA 714 Phone: +1-815-342-5222 715 Email: rrs@cisco.com 717 Intellectual Property Statement 719 The IETF takes no position regarding the validity or scope of any 720 Intellectual Property Rights or other rights that might be claimed to 721 pertain to the implementation or use of the technology described in 722 this document or the extent to which any license under such rights 723 might or might not be available; nor does it represent that it has 724 made any independent effort to identify any such rights. Information 725 on the procedures with respect to rights in RFC documents can be 726 found in BCP 78 and BCP 79. 728 Copies of IPR disclosures made to the IETF Secretariat and any 729 assurances of licenses to be made available, or the result of an 730 attempt made to obtain a general license or permission for the use of 731 such proprietary rights by implementers or users of this 732 specification can be obtained from the IETF on-line IPR repository at 733 http://www.ietf.org/ipr. 735 The IETF invites any interested party to bring to its attention any 736 copyrights, patents or patent applications, or other proprietary 737 rights that may cover technology that may be required to implement 738 this standard. Please address the information to the IETF at 739 ietf-ipr@ietf.org. 741 Disclaimer of Validity 743 This document and the information contained herein are provided on an 744 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 745 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 746 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 747 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 748 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 749 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 751 Copyright Statement 753 Copyright (C) The Internet Society (2006). This document is subject 754 to the rights, licenses and restrictions contained in BCP 78, and 755 except as set forth therein, the authors retain all their rights. 757 Acknowledgment 759 Funding for the RFC Editor function is currently provided by the 760 Internet Society.