idnits 2.17.1 draft-ietf-rddp-sctp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [RDMA-Draft], [DDP-Draft]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 15, 2003) is 7528 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RDMA-Draft' on line 596 -- Looks like a reference, but probably isn't: 'DDP-Draft' on line 596 -- Looks like a reference, but probably isn't: 'ADDIP-Draft' on line 176 == Unused Reference: '5' is defined on line 621, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (ref. '2') (Obsoleted by RFC 4960) == Outdated reference: A later version (-07) exists of draft-ietf-rddp-ddp-00 == Outdated reference: A later version (-07) exists of draft-ietf-rddp-rdmap-00 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-05 ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-sctpsocket (ref. '5') == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-06 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Remote Direct Data Placement R. Stewart 3 Working Group Cisco Systems, Inc. 4 Internet-Draft C. Bestler 5 Expires: March 15, 2004 Consultant 6 J. Pinkerton 7 Microsoft 8 S. Ganguly 9 Iomega Corp, Inc. 10 H. Shah 11 Intel Corporation 12 V. Kashyap 13 IBM 14 September 15, 2003 16 Stream Control Transmission Protocol (SCTP) Remote Direct Memory 17 Access (RDMA) Direct Data Placement (DDP) Adaptation 18 draft-ietf-rddp-sctp-00.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 15, 2004. 42 Copyright Notice 44 Copyright (C) The Internet Society (2003). All Rights Reserved. 46 Abstract 48 This document describes a method to adapt Direct Data Placement (DDP) 49 and Remote Direct Memory Access (RDMA) to Stream Control Transmission 50 Protocol (SCTP) RFC2960 [2] using a generic description found in 51 [RDMA-Draft] [4] and [DDP-Draft] [3]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1 Adaptation Layer Indicator . . . . . . . . . . . . . . . . . 5 60 2.2 Payload Data Chunks . . . . . . . . . . . . . . . . . . . . 5 61 2.2.1 DDP Source Sequence Number (DDP-SSN) . . . . . . . . . . . . 6 62 2.2.2 DDP Segment . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.3 DDP Stream Session Control . . . . . . . . . . . . . . . . . 6 64 3. DDP Stream Sessions . . . . . . . . . . . . . . . . . . . . 8 65 3.1 Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.2 Legal Sequence: Active/Passive Session Accepted . . . . . . 8 67 3.3 Legal Sequence: Negotiation-only . . . . . . . . . . . . . . 9 68 3.4 Legal Sequence: Active/Passive Session Rejected . . . . . . 9 69 3.5 Legal Sequence: Active/Active Session Accepted . . . . . . . 9 70 3.6 Other Sequencing Rules . . . . . . . . . . . . . . . . . . . 10 71 4. SCTP Endpoints . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.1 Adaptation Layer Indication Restriction . . . . . . . . . . 11 73 4.2 Multihoming Implications . . . . . . . . . . . . . . . . . . 11 74 5. Number of Streams . . . . . . . . . . . . . . . . . . . . . 12 75 6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. Sequenced Unordered Operation . . . . . . . . . . . . . . . 14 77 8. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8.1 Association Initialization . . . . . . . . . . . . . . . . . 15 79 8.2 Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . . 15 80 8.3 Association Termination . . . . . . . . . . . . . . . . . . 16 81 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 17 82 10. Security Considerations . . . . . . . . . . . . . . . . . . 18 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 84 References . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 86 Intellectual Property and Copyright Statements . . . . . . . 22 88 1. Introduction 90 This document describes a method to adapt Direct Data Placement (DDP) 91 and Remote Direct Memory Access (RDMA) to Stream Control Transmission 92 Protocol (SCTP) RFC2960 [2] using a generic description found in 93 [RDMA-Draft] [4] and [DDP-Draft] [3] This adaption provides a method 94 for two peers to know that each side is performing DDP or RDMA thus 95 enabling hardware acceleration if available. 97 Some implementations may include this adaptation layer within their 98 SCTP implementations to obtain maximum performance but the behavior 99 of SCTP will be unaffected. In order to accomplish this we specify 100 the use of the new adaptation layer indication as defined in 101 [ADDIP-Draft] [6] 103 1.1 Definitions 105 DDP Endpoint - The logical sender/receiver of DDP Segments. An SCTP 106 Stream pair is not assumed to have a DDP Endpoint. DDP Segments 107 may only be sent once a DDP Endpoint has been assigned to an SCTP 108 Stream pair by a local interface. 110 DDP Source Stream Sequence (DDP-SSN) - A stream specific sequence 111 number assigned by the DDP layer for each SCTP Data Chunk sent. 112 Use of the SCTP Stream Sequence Number (SSN) could result in 113 ordered delivery at the receiving end. Use of unordered Data 114 Chunks indicates that the receiving SCTP layer is to deliver them 115 without delay. The DDP-SSN retains the original order the Data 116 Chunks were generated in, no matter what order they were actually 117 sent or received. 119 DDP Stream - A bi-directional pair of SCTP streams which have the 120 same SCTP stream identifier. 122 DDP Stream Session - A single pairing of DDP Endpoints over a DDP 123 Stream that lasts from a Initiation message through the 124 Termination message(s). 126 DDP Stream Session Control - DDP Stream Session Control messages are 127 used to control the association of the DDP Endpoint with the DDP 128 Stream. 130 RDMA - Remote Direct Memory Access. 132 RNIC - RDMA Network Interface Card. 134 SCTP association - A protocol relationship between two SCTP 135 endpoints. An SCTP association supports multiple SCTP streams. 137 SCTP Data Chunk - An SCTP Chunk used to convey Payload Data. There 138 can be multiple Chunks within each SCTP packet. Other Chunks are 139 used to control the SCTP Association. 141 SCTP endpoint - The logical sender/receiver of SCTP packets. On a 142 multi-homed host, an SCTP endpoint is represented to its peers as 143 a combination of a SCTP port number and a set of eligible 144 destination transport addresses to which SCTP packets can be sent. 146 SCTP Stream - A uni-directional logical channel established from one 147 to another associated SCTP endpoint. There can be multiple SCTP 148 Streams within each SCTP association. An SCTP Stream is used to 149 form one direction of a DDP stream. 151 Transmission Sequence Number (TSN) - A 32-bit sequence number used 152 internally by SCTP. One TSN is attached to each chunk containing 153 user data to permit the receiving SCTP endpoint to acknowledge its 154 receipt and detect duplicate deliveries. 156 1.2 Conventions 158 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 159 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 160 they appear in this document, are to be interpreted as described in 161 RFC2119 [1]. 163 2. Data Formats 165 2.1 Adaptation Layer Indicator 167 This mapping places an entire SCTP association into a specific DDP 168 mode: DDP or DDP+RDMA. It is presumed that the handling of incoming 169 data chunks for DDP enabled associations is sufficiently different 170 than for routine SCTP associations that it is undesirable to mix DDP 171 and non-DDP streams in a single association. An application that 172 needs to mix DDP and non-DDP traffic must use use more than a single 173 association. 175 We define a adaption indication which MUST appear in the INIT or 176 INIT-ACK with the following format as defined in [ADDIP-Draft] [6] 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type =0xC006 | Length = Variable | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Adaptation Indication | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Adaptation Indication: 188 The following values are defined for DDP in this document: 190 DDP - 0x00000001 191 DDP+RDMA - 0x00000002 193 2.2 Payload Data Chunks 195 After the SCTP association has been established, all DDP relevant 196 messages are encoded as Payload Data Chunks. Each includes a SCTP 197 Stream identifier, a Transmissions Sequence Number (TSN), a Payload 198 Protocol Identifier, the chunk length and the payload data bytes. 200 The DDP SCTP adaptation uses two types of Payload Data Chunks, 201 differentiated by the Payload Protocol Identifier: 203 DDP Segments are use to for messages send between DDP Endpoints. 205 DDP Stream Session messages are used to control the binding of DDP 206 endpoints with SCTP streams. 208 Payload Protocol Identifier: 210 The following value are defined for DDP in this document: 212 DDP Segment - 0x00000001 213 DDP Stream Session Control - 0x00000002 215 2.2.1 DDP Source Sequence Number (DDP-SSN) 217 All Payload Data Chunks include a DDP Source Sequence Number 218 (DDP-SSN) that tracks the sequence the messages were submitted to the 219 SCTP layer. It is initialized to 1 for each stream at the beginning 220 of each DDP Stream Session. It wraps to zero after 65535. 222 The SCTP Stream Sequence Number (SSN) is not suitable for this 223 purpose, because all messages defined by this document use unordered 224 Payload Data Chunks to ensure prompt delivery from the receiving SCTP 225 layer. 227 The SCTP Transmission Sequence Number (TSN) is not suitable for 228 determine the original order of Data Chunks within a stream. The 229 sending SCTP layer is allowed to optimize the transmission sequence 230 of unordered Data Chunks to encourage Chunk Bundling, or other 231 purposes. 233 2.2.2 DDP Segment 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | DDP-SSN | DDP Segment | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 240 | | 241 | ... | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 DDP Segments are as defined in [DDP-Draft]. 246 2.2.3 DDP Stream Session Control 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | DDP-SSN | Function Code | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Private Data (Dependent on Function Code) | 254 | ... | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 The following function code values are defined for DDP in 258 this document: 260 DDP Stream Session Negotiate - 0x001 261 DDP Stream Session Initiate - 0x002 262 DDP Stream Session Accept - 0x003 263 DDP Stream Session Terminate - 0x004 265 ULP supplied Private Data MUST be included for DDP Stream Session 266 Negotiate, DDP Stream Session Initiate and DDP Stream Session Accept 267 messages. However, the ULP supplied Private DATA MAY be of zero 268 length. Private Data MUST NOT be included for the DDP Stream Session 269 Termiante message. 271 Received DDP Stream Session Control messages MUST be reported to the 272 ULP. Any supplied Private Data MUST be available for the ULP. 274 3. DDP Stream Sessions 276 A DDP Endpoint is the logical sender/receiver of DDP Segments. A DDP 277 Stream connects two DDP Endpoints using a matched pair of SCTP 278 Streams. 280 A DDP Stream Session defines the sequence of Data Chunks exchanged 281 between two DDP Endpoints over a DDP Stream that has a distinct 282 beginning and end. Data Chunks from one DDP Stream Session are never 283 carried over to the next session. 285 The local interface MAY associate a DDP Endpoint with the DDP Stream 286 based upon the initial exchanges of a DDP Session, and terminate that 287 association at the session's end. 289 A DDP Stream is associated with at most one Protection Domain during 290 a single DDP Stream Session. 292 3.1 Sequencing 294 The DDP Source Sequence Number(DDP-SSN) is reset to one at the 295 beginning of each DDP Stream Session. 297 The Payload Data Chunks for a given session, when sequenced by their 298 DDP-SSN, MUST follow one of the patterns defined in this section. 300 If the adaptation layer receives a Payload Data Chunk that conforms 301 to none of the enumerated legal patterns the DDP Stream Session MUST 302 be terminated. 304 3.2 Legal Sequence: Active/Passive Session Accepted 306 In this DDP Stream Session sequence one DDP Endpoint assumes the 307 active role in requesting a DDP Stream Session, which the other side 308 accepts. 310 Either the Active or Passive side may send zero or more DDP Stream 311 Session Negotiate messages. 313 Active Side sends a DDP Stream Session Initiate message. 315 Passive Side sends a DDP Stream Session Accept mesage. 317 Each side may then send zero or more DDP Segments with increasing 318 DDP-SSNs, subject to various layers of flow control. 320 The final DDP Segment for each side MAY be a DDP Stream Terminate. 321 At least one side MUST send a DDP Stream Terminate. 323 3.3 Legal Sequence: Negotiation-only 325 Either the Active or Passive side may send zero or more DDP Stream 326 Session Negotiate messages. The session does not have to proceed 327 further if the ULPs so desire. 329 3.4 Legal Sequence: Active/Passive Session Rejected 331 DDP Stream Sessions allow each party to send a single non-negotiation 332 message before the other end commits specific resources to the 333 session. This allow each end to determine which resources are to be 334 used, and how they are to be configured, or even if the session 335 should be granted. 337 These decision MAY be influenced by the need to assign a specific 338 Protection Domain, to determine how many RDMA Read Credits are 339 required, or to determine now many receive operations the ULP should 340 enable. 342 Because of these, or other, factors the Passive side MAY choose to 343 reject a DDP Stream Session Request. This results in the following 344 legal sequence: 346 Either the Active or Passive side MAY send zero or more DDP Stream 347 Session Negotiate messages. However, if the result of these 348 negotiations allow the ULP to determine that a session is not to 349 be set up, the ULP SHOULD simply refrain from sending the DDP 350 Stream Initiate message. 352 Active Side sends a DDP Stream Session Initiate message. 354 Passive Side sends a DDP Stream Session Terminate mesage. 356 3.5 Legal Sequence: Active/Active Session Accepted 358 In this DDP Stream Session sequence both ends seek to establish the 359 session concurrently, after any negotiation messages required. 360 Active/Active session establishment MAY require different support 361 from the local interface than for Active/Passive session 362 establishment. 364 The following legal sequence is defined: 366 Each side may send zero or more DDP Stream Session Negotiate 367 messages. 369 Each Side, viewing itself as active, sends a DDP Stream Session 370 Initiate message. 372 Each side may then send zero or more DDP Segments with increasing 373 DDP-SSNs, subject to various layers of flow control. 375 The final DDP Segment for each side MAY be a DDP Stream Terminate. 376 At least one side MUST send a DDP Stream Terminate. 378 3.6 Other Sequencing Rules 380 A DDP Stream Session Control message MUST NOT be sent if it may be 381 received before a prior DDP Stream Session Control message within the 382 same DDP Stream Session. 384 An active side of a DDP Stream Session MUST NOT send a DDP Segment 385 that might be received before the DDP Stream Session Initiate 386 message. 388 This MAY be determined by SCTP acking of the Data Chunk used to carry 389 the DDP Stream Session Initiate message, or by receipt of a 390 responsive DDP Stream Session Control message. 392 A DDP Stream MUST NOT be re-used for another DDP Stream Session while 393 any Data Chunk from a prior session might be outstanding. 395 Unless explicitly allowed for by the Upper Layer Protocol, there may 396 be no more than one outstanding DDP Stream Session Negotiate message 397 per side. Multiple messages are intended to support rounds of 398 negotiations between the potential peers. 400 4. SCTP Endpoints 402 4.1 Adaptation Layer Indication Restriction 404 The local interface MUST allow the ULP to specify an SCTP endpoint to 405 use a specific Adaptation Indication. It MAY require the ULP to do 406 so. 408 Once an endpoint decides on its acceptable Adaptation Indication(s), 409 it SHOULD terminate all requests to establish an association with any 410 different Adaptation Indication. 412 An SCTP implementation MAY choose to accept association requests for 413 a given SCTP endpoint only until one association for the endpoint has 414 been established. At that point it MAY choose to restrict all further 415 associations for the same endpoint to use the same Adaptation 416 Indication. 418 4.2 Multihoming Implications 420 SCTP allows an SCTP endpoint to be associated with multiple IP 421 addresses, potentially representing different interface devices. 422 Distribution of the logic for a single DDP stream across multiple 423 input devices can be very undesirable, resulting in complex cache 424 coherency challenges. Therefore the local interface MAY restrict 425 DDP-enabled SCTP endpoints to a single IP address, or to a set of IP 426 addresses that are all assigned to the same input device ("RNIC"). 428 The default binding of a DDP enabled SCTP endpoint SHOULD NOT cover 429 more than a single IP address unless doing so results in no 430 additional bus traffic or duplication of memory registration 431 resources. This will frequently result in a different default than 432 for SCTP endpoints that are not DDP enabled. 434 Even when multi-homing is supported, ULPs are cautioned that they 435 SHOULD NOT use ULP control of the source address in attempt to 436 load-balance a stream across multiple paths. A receiving DDP/SCTP 437 implementation that chooses to support multi-homing SHOULD optimize 438 its design on the assumption that multi-homing will be used for 439 network fault tolerance, and not to load-balance between paths. This 440 is consistent with recommended SCTP practices. 442 5. Number of Streams 444 DDP Streams are bidirectional. They are always composed by pairing 445 the inbound and outbound SCTP streams with the same SCTP Stream 446 Identifier. 448 DDP should request the maximum number of SCTP stream it will wish to 449 use over the lifetime of the association. SCTP streams must still be 450 bound to DDP Endpoints, and a DDP or DDP+RDMA enabled SCTP 451 association does not support ordered Data Chunks. Therefore the mere 452 existence of an SCTP stream is unlikely to require signifigant 453 supporting resources. 455 This mapping uses an SCTP association to carry one or more DDP 456 Steams. Each DDP Stream will be mapped to a pair of SCTP streams with 457 the same SCTP stream number. DDP MUST initialize all of its SCTP 458 associations with the same number of inbound and outbound streams. 460 6. Fragmentation 462 A DDP/SCTP Receiver already must deal with fragementation at both the 463 IP and DDP Layers. Therefore the sending DDP layer MUST disable SCTP 464 layer segmenting of data chunks. If the DDP layer presents messages 465 that are too large, the result will be IP fragmentation. While SCTP 466 layer fragmentation is theoretically preferable, virtually all 467 fragmentation will be done at the DDP layer. Because SCTP layer 468 fragmentation would only be invoked under corner conditions, its 469 benefits do not justify the complexity of its inclusion. 471 When disabling SCTP fragmentation, SCTP will reject messages that are 472 known to be larger than the MTU size. This means that the DDP layer 473 MUST be prepared to handle this error case. 475 7. Sequenced Unordered Operation 477 DDP MUST use the Unordered option on all Data Chunks (U Flag set to 478 one). The SCTP Layer is expected to deliver Data Chunks to the DDP 479 layer without delay. 481 Because DDP employs unordered SCTP delivery, the receiver MUST NOT 482 rely upon the SCTP Transmission Sequence Number (TSN) to imply 483 ordering of DDP Segments. The fact that the SCTP Data Chunk for a DDP 484 Segment is prior the cumulative ack point does not guarantee that all 485 prior DDP segments have been placed. The SCTP sender is not obligated 486 to transmit unordered Data Chunks in the order presented. 488 The DDP-SSN can be used without special logic to determine the 489 submission sequence when the maximum number of in-flight messages is 490 less than 32768. This also applies if the sending SCTP accepts no 491 more than 32767 Data Chunks for a single stream without assigning 492 TSNs. 494 If SCTP does accept more than 32768 Data chunks for a single stream 495 without assigning TSNs, the sending DDP must simply refrain from 496 sending more than 32767 Data Chunks for a single stream without 497 acknowledgement. Note that it MUST NOT rely upon ULP flow control 498 for this purpose. Typical ULP flow control will deal exclusively with 499 tagged messages, not with DDP segments. 501 The receiving DDP implementation MAY perform a validity check on 502 received DDP-SSNs to ensure that any gap could be accounted for by 503 unreceived Data Chunks. Implementations are advised against 504 allocating resources on the assumption that DDP-SSNs are valid 505 without first performing such a validtity check. An invalid DDP-SSN 506 MAY result in termination of the DDP Stream. 508 8. Procedures 510 8.1 Association Initialization 512 At the startup of an association, an endpoint wishing to perform DDP, 513 RDMA, or DDP+RDMA placement MUST include an adaptation layer 514 indication in its INIT or INIT-ACK (as defined in Section 2.1. After 515 the exchange of the initial first two SCTP chunks (INIT and 516 INIT-ACK), an endpoint MUST verify and inspect the adaptation 517 indication and compare it to the following table to determine proper 518 action. 520 Indication | Action 521 type | 523 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 524 | This indicates that the peer DOES NOT 525 NONE | support ANY DDP or RDMA adaption and thus 526 | RDMA and DDP procedures MUST NOT be 527 | performed upon this association. 528 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 529 | This indicates that the peer DOES support 530 DDP | DDP (but not RDMA). Procedures outlined in 531 | [DDP-Draft] MUST be followed. 532 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 533 | This indicates that the peer supports BOTH 534 DDP+RDMA | RDMA and DDP. If the receiving endpoint 535 | indicated the same, then the procedures in 536 | both [RDMA-Draft] and [DDP-Draft] 537 | MUST be followed. If the local endpoint 538 | only indicated DDP, then ONLY the 539 | procedures in [DDP-Draft] MUST be followed. 540 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 541 | This indicates that the peer DOES NOT 542 ANY-OTHER | support ANY DDP or RDMA adaption and thus 543 Indication | RDMA and DDP procedures MUST NOT be 544 | performed upon this association. 546 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 548 An implementation MAY require that all associations for a given SCTP 549 endpoint be placed in the same mode. 551 The local interface MAY allow the ULP to accept only requests to 552 establish an association in a specified mode. 554 8.2 Chunk Bundling 555 SCTP allows multiple Data Chunks to be bundled in a single SCTP 556 packet. Data chunks containing DDP Segments with untagged messages 557 SHOULD NOT be delayed to facilitate bundling. Data chunks containing 558 DDP Segments with tagged messages will generally be full sized, and 559 hence not subject to bundling. However partial size tagged messages 560 MAY be delayed, as that they are frequently followed by a short 561 untagged message. 563 8.3 Association Termination 565 Termination of an SCTP Association due to errors should be handled at 566 the SCTP layer. The RDMAP defined RDMAP Terminate Message SHOULD NOT 567 be sent on each DDP Stream when a determination has been made to 568 terminate an SCTP association. Sending that message on each SCTP 569 stream could severely delay the termination of the association. 571 The local interface SHOULD notify all consumers of DDP streams when 572 the underlying SCTP stream has been terminated. 574 Other RDMAP defined Terminate Messages MUST be generated as specified 575 when a DDP Stream is terminated. Note that with the SCTP mapping, 576 termination of a DDP Stream does not mandate termination of the 577 Association. 579 9. IANA considerations 581 This document defines two new Adaptation Layer Indication codepoints: 583 DDP - 0x00000001 584 DDP+RDMA - 0x00000002 586 This document also defines two new Payload Protocol Identifier 587 (PPIDs): 589 DDP Segment - 0x00000001 590 DDP Stream Session Control - 0x00000002 592 10. Security Considerations 594 Any direct placement of memory could pose a significant security risk 595 if adequate local controls are not provided. These threats should be 596 addressed in the appropriate DDP [DDP-Draft] [3] or RDMA [RDMA-Draft] 597 [4] drafts. This document does not add any additional security risks 598 over those found in RFC2960 [2]. 600 11. Acknowledgments 602 The authors would like to thank the following people that have 603 provided comments and input: Stephen Bailey, David Black, Douglas 604 Otis, Allyn Romanow and Jim Williams. 606 References 608 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 609 Levels", BCP 14, RFC 2119, March 1997. 611 [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 612 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 613 "Stream Control Transmission Protocol", RFC 2960, October 2000. 615 [3] Shah, H., "Direct Data Placement over Reliable Transports", 616 draft-ietf-rddp-ddp-00 (work in progress), February 2003. 618 [4] Recio, R., "An RDMA Protocol Specification", 619 draft-ietf-rddp-rdmap-00 (work in progress), February 2003. 621 [5] Stewart, R., "Sockets API Extensions for Stream Control 622 Transmission Protocol", draft-ietf-tsvwg-sctpsocket-05 (work in 623 progress), September 2002. 625 [6] Stewart, R., "Stream Control Transmission Protocol (SCTP) 626 Dynamic Address Reconfiguration", 627 draft-ietf-tsvwg-addip-sctp-06 (work in progress), September 628 2002. 630 Authors' Addresses 632 Randall R. Stewart 633 Cisco Systems, Inc. 634 8725 West Higgins Road 635 Suite 300 636 Chicago, IL 60631 637 USA 639 Phone: +1-815-477-2127 640 EMail: rrs@cisco.com 642 Caitlin Bestler 643 Consultant 644 1241 W. North Shore 645 # 2G 646 Chicago, IL 60626 647 USA 649 Phone: +1-773-743-1594 650 EMail: cait@asomi.com 651 Jim Pinkerton 652 Microsoft 653 One Microsoft Way 654 Redmond, WA 98052 655 USA 657 Phone: +1-425-705-5442 658 EMail: jpink@microsoft.com 660 Sukanta Ganguly 661 Iomega Corp, Inc. 662 10955 Vista Sorrento Parkway 664 San Diego, CA 665 USA 667 Phone: +1-858-314-7026 668 EMail: ganguly@iomega.com 670 Hemal V. Shah 671 Intel Corporation 672 Mailstop: PTL1 673 1501 S. Mopac Expressway, #400 674 Austin, TX 78746 675 USA 677 Phone: +1-512-732-3963 678 EMail: hemal.shah@intel.com 680 Vivek Kashyap 681 IBM 682 15450 SW Koll Parkway 683 Beaverton, OR 57006 684 USA 686 Phone: +1-503-578-3422 687 EMail: vivk@us.ibm.com 689 Intellectual Property Statement 691 The IETF takes no position regarding the validity or scope of any 692 intellectual property or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; neither does it represent that it 696 has made any effort to identify any such rights. Information on the 697 IETF's procedures with respect to rights in standards-track and 698 standards-related documentation can be found in BCP-11. Copies of 699 claims of rights made available for publication and any assurances of 700 licenses to be made available, or the result of an attempt made to 701 obtain a general license or permission for the use of such 702 proprietary rights by implementors or users of this specification can 703 be obtained from the IETF Secretariat. 705 The IETF invites any interested party to bring to its attention any 706 copyrights, patents or patent applications, or other proprietary 707 rights which may cover technology that may be required to practice 708 this standard. Please address the information to the IETF Executive 709 Director. 711 Full Copyright Statement 713 Copyright (C) The Internet Society (2003). All Rights Reserved. 715 This document and translations of it may be copied and furnished to 716 others, and derivative works that comment on or otherwise explain it 717 or assist in its implementation may be prepared, copied, published 718 and distributed, in whole or in part, without restriction of any 719 kind, provided that the above copyright notice and this paragraph are 720 included on all such copies and derivative works. However, this 721 document itself may not be modified in any way, such as by removing 722 the copyright notice or references to the Internet Society or other 723 Internet organizations, except as needed for the purpose of 724 developing Internet standards in which case the procedures for 725 copyrights defined in the Internet Standards process must be 726 followed, or as required to translate it into languages other than 727 English. 729 The limited permissions granted above are perpetual and will not be 730 revoked by the Internet Society or its successors or assignees. 732 This document and the information contained herein is provided on an 733 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 734 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 735 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 736 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 737 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 739 Acknowledgement 741 Funding for the RFC Editor function is currently provided by the 742 Internet Society.