idnits 2.17.1 draft-ietf-rddp-sctp-07.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 825. ** 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 issues found here. 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 (September 13, 2006) is 6407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ADDIP-Draft' is mentioned on line 237, but not defined ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-07) exists of draft-ietf-rddp-ddp-06 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-15 == Outdated reference: A later version (-08) exists of draft-ietf-rddp-mpa-06 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-06) exists of draft-ietf-ips-iser-05 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 Intended status: Informational September 13, 2006 6 Expires: March 17, 2007 8 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) 9 Adaptation 10 draft-ietf-rddp-sctp-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 17, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document specifies an Adaptation Layer to provide a Lower Layer 44 Protocol (LLP) service for Direct Data Placement (DDP) using the 45 Stream Control Transmission Protocol (SCTP). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 54 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.1. Adaptation Layer Indicator . . . . . . . . . . . . . . . . 8 57 5.2. Payload Data Chunks . . . . . . . . . . . . . . . . . . . 8 58 5.2.1. DDP Source Sequence Number (DDP-SSN) . . . . . . . . . 9 59 5.2.2. DDP Segment Chunk . . . . . . . . . . . . . . . . . . 9 60 5.2.3. DDP Stream Session Control . . . . . . . . . . . . . . 10 61 6. DDP Stream Sessions . . . . . . . . . . . . . . . . . . . . . 11 62 6.1. Sequencing . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6.2. Legal Sequence: Active/Passive Session Accepted . . . . . 11 64 6.3. Legal Sequence: Active/Passive Session Rejected . . . . . 12 65 6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected . 12 66 6.5. ULP Specific Sequencing . . . . . . . . . . . . . . . . . 13 67 6.6. Other Sequencing Rules . . . . . . . . . . . . . . . . . . 13 68 7. SCTP Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 14 69 7.1. Adaptation Layer Indication Restriction . . . . . . . . . 14 70 7.2. Multihoming Implications . . . . . . . . . . . . . . . . . 14 71 8. Number of Streams . . . . . . . . . . . . . . . . . . . . . . 15 72 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16 73 10. Sequenced Unordered Operation . . . . . . . . . . . . . . . . 17 74 11. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 11.1. Association Initialization . . . . . . . . . . . . . . . . 18 76 11.2. Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . 18 77 11.3. Association Termination . . . . . . . . . . . . . . . . . 19 78 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 82 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 16.1. Normative references . . . . . . . . . . . . . . . . . . . 24 84 16.2. Informative references . . . . . . . . . . . . . . . . . . 24 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 86 Intellectual Property and Copyright Statements . . . . . . . . . . 27 88 1. Introduction 90 This document describes a method to adapt Direct Data Placement 91 [I-D.ietf-rddp-ddp] to Stream Control Transmission Protocol (SCTP) 92 [RFC2960]. 94 Some implementations may include this adaptation layer within their 95 SCTP implementations to obtain maximum performance but the behavior 96 of SCTP will be unaffected. An SCTP Layer used solely by this 97 adaptation layer is able to take certain optimizations based on the 98 limited subset of SCTP capabilities used. In order to allow 99 optimization for these implementations we specify the use of the new 100 adaptation layer indication as defined in [I-D.ietf-tsvwg-addip-sctp] 102 2. Definitions 104 DDP - See Direct Data Placement Protocol. 106 DDP Endpoint - The logical sender/receiver of DDP Segments. An SCTP 107 Stream pair is not assumed to have a DDP Endpoint. DDP Segments 108 may only be sent once a DDP Endpoint has been assigned to an SCTP 109 Stream pair by a local interface. 111 DDP Source Stream Sequence (DDP-SSN) - A stream specific sequence 112 number assigned by the Adaptation Layer for each SCTP Data Chunk 113 sent. This is the order that chunks were submitted to SCTP, no 114 matter what order they are actually sent or received in. 116 DDP Segment - The smallest unit of data transfer for the DDP 117 protocol. It includes a DDP Header and ULP Payload (if present). 118 A DDP Segment should be sized to fit within the Lower Layer 119 Protocol MULPDU. 121 DDP Segment Chunk - An SCTP Payload Data Chunk that encapsulates the 122 DDP-SSN and a DDP Segment. 124 DDP Stream - a sequence of DDP Segments whose ordering is defined by 125 the LLP. For SCTP, a DDP Stream maps directly to a bi-directional 126 pair of SCTP streams with the same Stream IDs. Note that DDP has 127 no ordering guarantees between DDP Streams. 129 DDP Stream Session - A single pairing of DDP Endpoints over a DDP 130 Stream that lasts from a Initiation message through the 131 Termination message(s). 133 DDP Stream Session Control Message - DDP Stream Session Control 134 messages are used to control the association of the DDP Endpoint 135 with the DDP Stream. 137 Direct Data Placement Protocol (DDP) - A wire protocol that supports 138 Direct Data Placement by associating explicit memory buffer 139 placement information with the LLP payload units. 141 Lower Layer Protocol (LLP) - In the context of DDP, the protocol 142 layer beneath RDMA that provides a reliable transport service. 143 The SCTP DDP adaption is one of the initially defined LLPs for 144 DDP. 146 Protection Domain - A common local interface convention to control 147 which Steering Tags (STags) are valid with which DDP Endpoints. 148 Under this convention both the Steering Tag and DDP Endpoint are 149 created within the context of a Protection Domain, and the 150 Steering Tag may only be enabled for DDP Endpoints created under 151 the same Protection Domain. 153 RDMA - Remote Direct Memory Access. 155 RNIC - RDMA Network Interface Card. 157 SCTP association - A protocol relationship between two SCTP 158 endpoints. An SCTP association supports multiple SCTP streams. 160 SCTP Data Chunk - An SCTP Chunk used to convey Payload Data. There 161 can be multiple Chunks within each SCTP packet. Other Chunks are 162 used to control the SCTP Association. 164 SCTP endpoint - The logical sender/receiver of SCTP packets. On a 165 multi-homed host, an SCTP endpoint is represented to its peers as 166 a combination of an SCTP port number and a set of eligible 167 destination transport addresses to which SCTP packets can be sent. 169 SCTP Stream - A uni-directional logical channel established from one 170 to another associated SCTP endpoint. There can be multiple SCTP 171 Streams within each SCTP association. An SCTP Stream is used to 172 form one direction of a DDP stream. 174 Transmission Sequence Number (TSN) - A 32-bit sequence number used 175 internally by SCTP. One TSN is attached to each chunk containing 176 user data to permit the receiving SCTP endpoint to acknowledge its 177 receipt and detect duplicate deliveries. 179 Upper Layer Protocol (ULP) - In the context of RDMA protocol 180 specifications, this is the layer using RDMA services. Typically 181 this is an application or middleware. A primary goal of RDMA 182 protocols is to enable direct transfer of payload to/from ULP 183 buffers. 185 3. Conventions 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC2119 [RFC2119]. 191 4. Introduction 193 4.1. Motivation 195 This document specifies an Adaptation Layer which fulfills the 196 requirements of a Lower Layer Protocol (LLP) for DDP using a specific 197 subset of SCTP capabilities. 199 The defined protocol is intended to be implementable over existing 200 SCTP stacks, while clearly defining what portions of SCTP are 201 required to enable an implementation to be optimized specifically to 202 support DDP. 204 4.2. Overview 206 The Adaptation Layer uses a pair of like-numbered SCTP Streams within 207 an SCTP Association to provide a reliable DDP Stream between two DDP 208 Endpoints. Except as specifically noted, each DDP Segment submitted 209 by the DDP Layer is encoded as a single unordered SCTP Data Chunk. 210 In addition to the DDP Segment the Data Chunk also contains a 211 sequence number (DDP-SSN) that reflects the order that DDP submitted 212 the segments in for that stream. 214 A DDP Stream Session is defined by DDP Stream Session Control Chunks 215 that manage the state of the DDP Stream Session. These Chunks 216 dynamically bind DDP Endpoints to the DDP Stream Session, and DDP 217 Segment Chunks are used to reliably deliver DDP Segments with the 218 session. 220 5. Data Formats 222 5.1. Adaptation Layer Indicator 224 The DDP/SCTP Adaptation Layer uses all streams within an SCTP 225 association. An SCTP Association that has had the DDP Adaptation 226 Indication negotiated will carry only SCTP Data Chunks as defined in 227 this document. 229 It is presumed that the handling of incoming data chunks for DDP 230 enabled associations is sufficiently different than for routine SCTP 231 associations that it is undesirable to require support for mixing DDP 232 and non-DDP streams in a single association. More than a single 233 association is required if an application desires to utilize both DDP 234 and non-DDP traffic with the same remote host. 236 We define a adaptation indication which MUST appear in the INIT or 237 INIT-ACK with the following format as defined in [ADDIP-Draft] 238 [I-D.ietf-tsvwg-addip-sctp] 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type =0xC006 | Length = Variable | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Adaptation Indication | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Adaptation Indication: 250 The following values are suggested for DDP in this document, but 251 the final value will be assigned by IANA: 253 DDP - 0x00000001 255 5.2. Payload Data Chunks 257 The DDP SCTP adaptation uses two types of SCTP Payload Data Chunks, 258 differentiated by the Payload Protocol Identifier: 260 DDP Segment Chunks are used to reliably deliver DDP Segments sent 261 between DDP Endpoints. 263 DDP Stream Session Control Messages are used to establish and 264 teardown DDP Stream Sessions, specifically by controlling the 265 binding of DDP endpoints with SCTP streams. 267 Payload Protocol Identifier: 269 The following value are defined for DDP in this document, 270 but the final values will be assigned by IANA: 272 DDP Segment Chunk - 16 273 DDP Stream Session Control - 17 275 5.2.1. DDP Source Sequence Number (DDP-SSN) 277 All SCTP Payload Data Chunks used by this Adaptation layer include a 278 DDP Source Sequence Number (DDP-SSN). The DDP-SSN tracks the 279 sequence the messages were submitted to the SCTP layer for the SCTP 280 stream in use. The DDP-SSN MUST have the same value that the SCTP 281 Stream Sequence Number (SSN) would have been assigned had ordered 282 SCTP Payload Data Chunks been used rather than unordered. 284 The rationale for specifying the DDP-SSN is as follows: 286 o The SCTP Stream Sequence Number (SSN) is not suitable for this 287 purpose, because all messages defined by this document use 288 unordered Payload Data Chunks to ensure prompt delivery from the 289 receiving SCTP layer. 291 o The SCTP Transmission Sequence Number (TSN) is not suitable for 292 determine the original order of Data Chunks within a stream. The 293 sending SCTP layer is allowed to optimize the transmission 294 sequence of unordered Data Chunks to encourage Chunk Bundling, or 295 other purposes. 297 5.2.2. DDP Segment Chunk 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 | DDP Segment | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 304 | | 305 | ... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 DDP Segments are as defined in [I-D.ietf-rddp-ddp]. The DDP Segment 309 Chunk serves the same purpose as the [I-D.ietf-rddp-mpa] Upper Layer 310 PDU (MULPDU) in that it carries DDP Segments over a reliable protocol 311 with added sequencing information. 313 5.2.3. DDP Stream Session Control 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | DDP-SSN | Function Code | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Private Data (Dependent on Function Code) | 321 | ... | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 The following function code values are defined for DDP in 325 this document: 327 DDP Stream Session Initiate - 0x001 328 DDP Stream Session Accept - 0x002 329 DDP Stream Session Reject - 0x003 330 DDP Stream Session Terminate - 0x004 332 ULP supplied Private Data MUST be included for DDP Stream Session 333 Initiate, DDP Stream Session Accept and DDP Stream Session Reject 334 messages. However, the ULP supplied Private DATA MAY be of zero 335 length. 337 Private Data length MUST NOT exceed 512 bytes in any message. 339 Private Data MUST NOT be included in the DDP Stream Session Terminate 340 message. 342 Received DDP Stream Session Control messages SHOULD be reported to 343 the ULP. If reported, any supplied Private Data MUST be available 344 for the ULP to examine. 346 The DDP/SCTP adaptation layer MAY limit the number of Session 347 Initiate requests that it has submitted to the ULP. When a DDP 348 Stream Session Initiate cannot be forwarded to the ULP due to such a 349 limit the adaptation layer MUST respond with a DDP Stream Session 350 Terminate message. 352 6. DDP Stream Sessions 354 A DDP Endpoint is the logical sender/receiver of DDP Segments. A DDP 355 Stream connects two DDP Endpoints using a matched pair of SCTP 356 Streams having the same SCTP Stream Identifiers. 358 A DDP Stream Session defines the sequence of Data Chunks exchanged 359 between two DDP Endpoints over a DDP Stream that has a distinct 360 beginning and end as defined in the following section. Data Chunks 361 from one DDP Stream Session are never carried over to the next 362 session. Each Data Chunk unambiguously belongs to exactly one 363 session. The DDP-SSNs assigned to the Data Chunks for a session MUST 364 NOT have any gaps. 366 The local interface MAY dynamically associate a DDP Endpoint with the 367 DDP Stream based upon the initial exchanges of a DDP Session, and 368 dynamically terminate that association at the session's end. 369 Alternately a specialized local interface could simply statically map 370 DDP Endpoints to DDP Streams. 372 Conventionally local interfaces for RDMA have deferred the selection 373 of the DDP Endpoint until after the ULP decides to accept an RDMA 374 connection request. But that is a local interface choice and not a 375 wire protocol requirement. 377 A DDP Stream is associated with at most one Protection Domain during 378 a single DDP Stream Session. On the passive side the association is 379 typically deferred until the DDP Stream Session Accept message. 381 6.1. Sequencing 383 The DDP-SSN is reset to zero at the beginning of each DDP Stream 384 Session. 386 The normative sequence for considering Payload Data Chunks within a 387 given session is based upon each Data Chunk's DDP-SSN. When 388 considered in this normative sequence, all sessions MUST conform to 389 one the patterns defined in this section. 391 If the adaptation layer receives a Payload Data Chunk that conforms 392 to none of the enumerated legal patterns the DDP Stream Session MUST 393 be terminated. 395 6.2. Legal Sequence: Active/Passive Session Accepted 397 In this DDP Stream Session sequence one DDP Endpoint assumes the 398 active role in requesting a DDP Stream Session, which the other side 399 accepts. 401 Active Side sends a DDP Stream Session Initiate message. 403 Passive Side sends a DDP Stream Session Accept message. 405 Each side may then send zero or more DDP Segments with increasing 406 DDP-SSNs, subject to any flow control imposed by other protocol 407 layers. 409 The final User Data Chunk for each side MAY be a DDP Stream 410 Terminate. At least one side MUST send a DDP Stream Terminate. 411 Note that this would follow any RDMAP Terminate message, which to 412 the Adaptation layer is simply another DDP Segment. 414 6.3. Legal Sequence: Active/Passive Session Rejected 416 DDP Stream Sessions allow each party to send a single non-payload 417 message before the other end commits specific resources to the 418 session. This allow each end to determine which resources are to be 419 used, and how they are to be configured, or even if the session 420 should be granted. 422 These decision MAY be influenced by the need to assign a specific 423 Protection Domain, to determine how many RDMA Read Credits are 424 required, or to determine now many receive operations the ULP should 425 enable. 427 Because of these, or other, factors the Passive side MAY choose to 428 reject a DDP Stream Session Request. This results in the following 429 legal sequence: 431 Active Side sends a DDP Stream Session Initiate message. 433 Passive Side sends a DDP Stream Session Reject message. 435 An DDP Stream Session Reject message MUST NOT be sent unless the 436 rejection is at the direction of the ULP. 438 6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected 440 Acceptance or rejection of DDP Stream Session Initiate messages 441 SHOULD be under the control of the ULP. This MAY require passing an 442 event to the ULP. There MUST be a finite limit on the number of such 443 requests that are pending a ULP decision. When more session requests 444 are received the passive side MUST respond to the Initiate message 445 with a DDP Stream Terminate Message. 447 6.5. ULP Specific Sequencing 449 An implementation MAY choose to support additional ULP specific 450 sequences, but MUST NOT do so unless requested to do so by the ULP. 452 A defined ULP MUST be able to operate using only the defined 453 mandatory session sequences. Any additional sequences must be used 454 only for optional optimizations. 456 6.6. Other Sequencing Rules 458 A DDP Stream Session Control message MUST NOT be sent if it may be 459 received before a prior DDP Stream Session Control message within the 460 same DDP Stream Session. 462 An active side of a DDP Stream Session MUST NOT send a DDP Segment 463 that might be received before the DDP Stream Session Initiate 464 message. 466 This MAY be determined by SCTP acking of the Data Chunk used to carry 467 the DDP Stream Session Initiate message, or by receipt of a 468 responsive DDP Stream Session Control message. 470 A DDP Stream Identifier MUST NOT be re-used for another DDP Stream 471 Session while any Data Chunk from a prior session might be 472 outstanding. 474 7. SCTP Endpoints 476 7.1. Adaptation Layer Indication Restriction 478 The local interface MUST allow the ULP to specify an SCTP endpoint to 479 use a specific Adaptation Indication. It MAY require the ULP to do 480 so. 482 Once an endpoint decides on its acceptable Adaptation Indication(s), 483 it SHOULD terminate all requests to establish an association with any 484 different Adaptation Indication. 486 An SCTP implementation MAY choose to accept association requests for 487 a given SCTP endpoint only until one association for the endpoint has 488 been established. At that point it MAY choose to restrict all 489 further associations for the same endpoint to use the same Adaptation 490 Indication. 492 7.2. Multihoming Implications 494 SCTP allows an SCTP endpoint to be associated with multiple IP 495 addresses, potentially representing different interface devices. 496 Distribution of the logic for a single DDP stream across multiple 497 input devices can be very undesirable, resulting in complex cache 498 coherency challenges. Therefore the local interface MAY restrict 499 DDP-enabled SCTP endpoints to a single IP address, or to a set of IP 500 addresses that are all assigned to the same input device ("RNIC"). 502 The default binding of a DDP enabled SCTP endpoint SHOULD NOT cover 503 more than a single IP address unless doing so results in no 504 additional bus traffic or duplication of memory registration 505 resources. This will frequently result in a different default than 506 for SCTP endpoints that are not DDP enabled. 508 Applications MAY choose to avoid using out-of-band methods for 509 communicating the set of IP addresses used by an SCTP endpoint when 510 there is potential confusion as to the intended scope of the SCTP 511 endpoint. For example, assuming the SCTP endpoint consists of all IP 512 Addresses advertised by DNS may work for a general purpose SCTP 513 endpoint but not a DDP enabled one. 515 Even when multi-homing is supported, ULPs are cautioned that they 516 SHOULD NOT use ULP control of the source address in attempt to load- 517 balance a stream across multiple paths. A receiving DDP/SCTP 518 implementation that chooses to support multi-homing SHOULD optimize 519 its design on the assumption that multi-homing will be used for 520 network fault tolerance, and not to load-balance between paths. This 521 is consistent with recommended SCTP practices. 523 8. Number of Streams 525 DDP Streams are bidirectional. They are always composed by pairing 526 the inbound and outbound SCTP streams with the same SCTP Stream 527 Identifier. 529 The adaptation layer should request the maximum number of SCTP stream 530 it will wish to use over the lifetime of the association. SCTP 531 streams must still be bound to DDP Endpoints, and a DDP enabled SCTP 532 association does not support ordered Data Chunks. Therefore the mere 533 existence of an SCTP stream is unlikely to require significant 534 supporting resources. 536 This mapping uses an SCTP association to carry one or more DDP 537 Steams. Each DDP Stream will be mapped to a pair of SCTP streams 538 with the same SCTP stream number. The adaptation MUST initialize all 539 of its SCTP associations with the same number of inbound and outbound 540 streams. 542 9. Fragmentation 544 A DDP/SCTP Receiver already deals with fragmentation at both the IP 545 and DDP Layers. Therefore use of SCTP layer segmenting will be 546 avoided for most cases. 548 As a Lower Layer Protocol (LLP) for DDP, the SCTP adaptation layer 549 MUST inform the DDP layer of the maximum DDP Segment size that will 550 be supported. This should be the largest value that can be supported 551 without use of IP or SCTP fragmentation, or 516 bytes, whichever is 552 larger. 554 A minimum of 516 bytes is required to allow a DDP Stream Session 555 Control Message with 512 bytes of Private Data. 557 SCTP data chunk fragmentation MUST NOT be used unless the alternative 558 is IP fragmentation. 560 The SCTP adaptation layer SHOULD set the maximum DDP Segment size 561 below the theoretical maximum in order to allow bundling of Control 562 Chunks in the same SCTP packet. 564 The SCTP adaptation layer MUST reject DDP Segments that are larger 565 than the maximum size specified. 567 10. Sequenced Unordered Operation 569 The Adaptation layer MUST use the Unordered option on all Data Chunks 570 (U Flag set to one). The SCTP Layer is expected to deliver unordered 571 Data Chunks without delay. 573 Because DDP employs unordered SCTP delivery, the receiver MUST NOT 574 rely upon the SCTP Transmission Sequence Number (TSN) to imply 575 ordering of DDP Segments. The fact that the SCTP Data Chunk for a 576 DDP Segment is prior the cumulative ack point does not guarantee that 577 all prior DDP segments have been placed. The SCTP sender is not 578 obligated to transmit unordered Data Chunks in the order presented. 580 The DDP-SSN can be used without special logic to determine the 581 submission sequence when the maximum number of in-flight messages is 582 less than 32768. This also applies if the sending SCTP accepts no 583 more than 32767 Data Chunks for a single stream without assigning 584 TSNs. 586 If SCTP does accept more than 32768 Data chunks for a single stream 587 without assigning TSNs, the sending DDP must simply refrain from 588 sending more than 32767 Data Chunks for a single stream without 589 acknowledgment. Note that it MUST NOT rely upon ULP flow control for 590 this purpose. Typical ULP flow control will deal exclusively with 591 untagged messages, not with DDP segments. 593 The receiver MAY perform a validity check on received DDP-SSNs to 594 ensure that any gap could be accounted for by unreceived Data Chunks. 595 Implementations SHOULD NOT allocate resources on the assumption that 596 DDP-SSNs are valid without first performing such a validity check. 597 An invalid DDP-SSN MAY result in termination of the DDP Stream. 599 11. Procedures 601 11.1. Association Initialization 603 At the startup of an association, a DDP/SCTP Adaptation Layer MUST 604 include an adaptation layer indication in its INIT or INIT-ACK (as 605 defined in Section 5.1. After the exchange of the initial first two 606 SCTP chunks (INIT and INIT-ACK), an endpoint MUST verify and inspect 607 the adaptation indication and compare it to the following table to 608 determine proper action. 610 Indication | Action 611 type | 613 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 614 | This indicates that the peer DOES NOT 615 NONE | support ANY DDP or RDMA adaptation and thus 616 | RDMA and DDP procedures MUST NOT be 617 | performed upon this association. 618 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 619 | This indicates that the peer DOES support 620 DDP | the DDP/SCTP Adaptation Layer defined here. 621 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 622 | This indicates that the peer DOES NOT 623 ANY-OTHER | support the DDP adaptation and thus 624 Indication | DDP procedures MUST NOT be performed 625 | upon this association. 627 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 629 An implementation MAY require that all associations for a given SCTP 630 endpoint be placed in the same mode. 632 The local interface MAY allow the ULP to accept only requests to 633 establish an association in a specified mode. 635 11.2. Chunk Bundling 637 SCTP allows multiple Data Chunks to be bundled in a single SCTP 638 packet. Data chunks containing DDP Segments with untagged messages 639 SHOULD NOT be delayed to facilitate bundling. Data chunks containing 640 DDP Segments with tagged messages will generally be full sized, and 641 hence not subject to bundling. However partial size tagged messages 642 MAY be delayed, as that they are frequently followed by a short 643 untagged message. 645 11.3. Association Termination 647 Termination of an SCTP Association due to errors should be handled at 648 the SCTP layer. The RDMAP defined RDMAP Terminate Message SHOULD NOT 649 be sent on each DDP Stream when a determination has been made to 650 terminate an SCTP association. Sending that message on each SCTP 651 stream could severely delay the termination of the association. 653 The local interface SHOULD notify all consumers of DDP streams when 654 the underlying SCTP stream has been terminated. 656 Other RDMAP defined Terminate Messages MUST be generated as specified 657 when a DDP Stream is terminated. Note that with the SCTP mapping, 658 termination of a DDP Stream does not mandate termination of the 659 Association. 661 12. IANA considerations 663 This document defines a new SCTP Adaptation Layer Indication 664 codepoint. [I-D.ietf-tsvwg-addip-sctp] will create the registry from 665 which this codepoint is to be assigned. Any unallocated codepoint 666 may be assigned. The value of one is suggested. 668 This document also defines two new SCTP Payload Protocol Identifier 669 (PPIDs). RFC2960 [RFC2960] creates the registry from which these 670 identifiers are to be assigned. The Payload Protocol Identifiers 671 allocated need to be unique, but have no other requirements. The 672 following values are suggested: 674 DDP Segment Chunk - 16 675 DDP Stream Session Control - 17 677 13. Security Considerations 679 Any direct placement of memory could pose a significant security risk 680 if adequate local controls are not provided. These threats are 681 addressed in the appropriate DDP [I-D.ietf-rddp-ddp], RDMA 682 [I-D.ietf-rddp-rdmap] or Security [I-D.ietf-rddp-security] drafts. 683 This document does not add any additional security risks over those 684 found in RFC2960 [RFC2960]. 686 The IPsec requirements for RDDP are based on the version of IPsec 687 specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC 688 3723 [RFC3723], despite the existence of a newer version of IPsec 689 specified in RFC 4301 [RFC4301] and related RFCs. One of the 690 important early applications of the RDDP protocols is their use with 691 iSCSI iSER [I-D.ietf-ips-iser]; RDDP's IPsec requirements follow 692 those of IPsec in order to facilitate that usage by allowing a common 693 profile of IPsec to be used with iSCSI and the RDDP protocols. In 694 the future, RFC 3723 may be updated to the newer version of IPsec, 695 the IPsec security requirements of any such update should apply 696 uniformly to iSCSI and the RDDP protocols. 698 14. Contributors 700 Many thanks to our contributors who have spent many hours reading and 701 reviewing keeping us straight: Sukanta Ganguly an independent 702 consultant, Vivek Kashyap of IBM, Jim Pinkerton of Microsoft, and 703 Hemal Shah of Broadcom. Thanks for all your hard work. 705 15. Acknowledgments 707 The authors would like to thank the following people that have 708 provided comments and input: Stephen Bailey, David Black, Douglas 709 Otis, Allyn Romanow and Jim Williams. 711 16. References 713 16.1. Normative references 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, March 1997. 718 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 719 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 720 Zhang, L., and V. Paxson, "Stream Control Transmission 721 Protocol", RFC 2960, October 2000. 723 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. 724 Travostino, "Securing Block Storage Protocols over IP", 725 RFC 3723, April 2004. 727 [I-D.ietf-rddp-ddp] 728 Shah, H., "Direct Data Placement over Reliable 729 Transports", draft-ietf-rddp-ddp-06 (work in progress), 730 June 2006. 732 [I-D.ietf-rddp-rdmap] 733 Recio, R., "A Remote Direct Memory Access Protocol 734 Specification", draft-ietf-rddp-rdmap-07 (work in 735 progress), September 2006. 737 [I-D.ietf-rddp-security] 738 Pinkerton, J., "DDP/RDMAP Security", 739 draft-ietf-rddp-security-10 (work in progress), June 2006. 741 [I-D.ietf-tsvwg-addip-sctp] 742 Stewart, R., "Stream Control Transmission Protocol (SCTP) 743 Dynamic Address Reconfiguration", 744 draft-ietf-tsvwg-addip-sctp-15 (work in progress), 745 June 2006. 747 16.2. Informative references 749 [I-D.ietf-rddp-mpa] 750 Culley, P., "Marker PDU Aligned Framing for TCP 751 Specification", draft-ietf-rddp-mpa-06 (work in progress), 752 September 2006. 754 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 755 Internet Protocol", RFC 2401, November 1998. 757 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 758 Internet Protocol", RFC 4301, December 2005. 760 [I-D.ietf-ips-iser] 761 Ko, M., "iSCSI Extensions for RDMA Specification", 762 draft-ietf-ips-iser-05 (work in progress), October 2005. 764 Authors' Addresses 766 Caitlin Bestler 767 Editor 768 Broadcom Corporation 769 16215 Alton Parkway 770 P.O. Box 57013 771 Irvine, CA 92619-7013 772 USA 774 Phone: 949-926-6383 775 Email: caitlinb@broadcom.com 777 Randall R. Stewart 778 Editor 779 Cisco Systems, Inc. 780 Forest Drive 781 Columbia, SC 29036 782 USA 784 Phone: +1-815-342-5222 785 Email: rrs@cisco.com 787 Full Copyright Statement 789 Copyright (C) The Internet Society (2006). 791 This document is subject to the rights, licenses and restrictions 792 contained in BCP 78, and except as set forth therein, the authors 793 retain all their rights. 795 This document and the information contained herein are provided on an 796 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 797 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 798 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 799 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 800 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 801 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 803 Intellectual Property 805 The IETF takes no position regarding the validity or scope of any 806 Intellectual Property Rights or other rights that might be claimed to 807 pertain to the implementation or use of the technology described in 808 this document or the extent to which any license under such rights 809 might or might not be available; nor does it represent that it has 810 made any independent effort to identify any such rights. Information 811 on the procedures with respect to rights in RFC documents can be 812 found in BCP 78 and BCP 79. 814 Copies of IPR disclosures made to the IETF Secretariat and any 815 assurances of licenses to be made available, or the result of an 816 attempt made to obtain a general license or permission for the use of 817 such proprietary rights by implementers or users of this 818 specification can be obtained from the IETF on-line IPR repository at 819 http://www.ietf.org/ipr. 821 The IETF invites any interested party to bring to its attention any 822 copyrights, patents or patent applications, or other proprietary 823 rights that may cover technology that may be required to implement 824 this standard. Please address the information to the IETF at 825 ietf-ipr@ietf.org. 827 Acknowledgment 829 Funding for the RFC Editor function is provided by the IETF 830 Administrative Support Activity (IASA).