idnits 2.17.1 draft-ietf-sigtran-usctp-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 26 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (February 2001) is 8464 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) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Q. Xie 2 INTERNET-DRAFT Motorola 3 R. R. Stewart 4 C. Sharp 5 Cisco 6 I. Rytina 7 Ericsson 8 Expires in six months February 2001 10 SCTP Unreliable Data Mode Extension 11 13 Status of This Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document describes an extension to the Stream Control 30 Transmission Protocol (SCTP) [RFC2960] to provide unreliable data 31 transfer services. The benefits of this extension includes unified 32 congestion control over reliable and unreliable data streams, single 33 association for multi-content data services, link level 34 fault tolerance for unreliable data transfer, unreliable data stream 35 multiplexing, etc. 37 The data transfer service extension will also support partial payload 38 checksum in order to facilitate bit-error tolerance media 39 applications. 41 TABLE OF CONTENTS 42 1. Introduction................................................. 2 43 2. Conventions.................................................. 3 44 3. Unreliable Data and Partial Checksum Design.................. 3 45 3.1 New INIT and INIT-ACK parameters.......................... 3 46 3.1.1 Unreliable Streams Parameter Definition............... 3 47 3.1.2 Partial Checksum Parameter Definition................. 5 48 3.2 New chunk definitions..................................... 5 49 3.2.1 Forward Cumulative TSN Chunk (FORWARD TSN)............ 5 50 3.2.2 Partial Checksum Data Chunk (P-DATA).................. 6 52 4. Unreliable Stream Operations................................. 8 53 4.1 Initialization of Unreliable Streams...................... 8 54 4.2 Send Unreliable Data...................................... 9 55 4.3 Receive Unreliable Data...................................11 56 4.4 Other Issues on Unreliable Data...........................11 57 4.4.1 Unreliable Data Stream Multiplexing...................11 58 4.4.2 Fault Tolerant Unreliable Data Transfer...............12 59 4.4.3 Unreliable Data Out-of-order Detection................12 60 5. Usage of the P-DATA chunk....................................12 61 6. Acknowledgments..............................................13 62 7. Authors' Addresses...........................................13 63 8. References...................................................14 65 1. Introduction 67 Taking advantage of the extensibility of SCTP, this document adds 68 unreliable data transfer services to SCTP and an optional method to 69 send SCTP Data Chunks with limited checksum coverage. The design 70 presented here allows the co-existence of unreliable data streams 71 and reliable streams in a single SCTP association. 73 The following are some of the advantages for integrating unreliable 74 and partial checksum data services into SCTP: 76 1) Unreliable extension to SCTP (U-SCTP) supports congestion 77 control and congestion avoidance over unreliable data traffic; 78 this is very desirable since it is much friendlier towards the 79 network than UDP. 81 2) Some applications services can greatly benefit from U-SCTP by 82 using a single SCTP association to carry both reliable content 83 (e.g., text, billing, accounting, set-up information, etc.) and 84 unreliable content (e.g., Fiber channel, SCSI over IP, etc.). 86 3) U-SCTP allows the use of a unified congestion control across 87 both reliable and unreliable traffic between two endpoints. This 88 has the potential for better utilization of network resources, 89 achieving similar objectives of the Endpoint Congestion 90 Management (ecm) Working Group. 92 4) Taking advantage of SCTP data chunk bundling function, sending 93 multiple unreliable data streams across a single SCTP association 94 creates a very efficient and effective way of data multiplexing. 96 5) U-SCTP gives even the unreliable data traffic "link-level" fault 97 tolerance, taking advantage of SCTP multi-homing ability. This is 98 not possible with UDP. 100 6) U-SCTP can achieve either ordered or unordered unreliable data 101 transfer, while UDP is incapable of controlling the order of data 102 delivery. 104 7) An application can control its retransmission policies if 105 retransmission is deemed needed. 107 8) Some applications may find it desirable to limit the coverage 108 of the Adler32 checksum over the actual data chunks. 110 2. Conventions 112 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 113 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they 114 appear in this document, are to be interpreted as described in 115 RFC 2119 [RFC2119]. 117 3. Unreliable Data and Partial Checksum Design 119 With the unreliable data extension, an SCTP data sender will be allowed to 120 designate a sub-set of its outbound streams to be unreliable 121 streams. The user data chunks sent to an unreliable stream will share 122 the same TSN space, the same congestion control/avoidance treatment, 123 and the same transmission priority as those sent to a reliable stream, 124 but they will not be retransmitted (or only be retransmitted for a 125 limited times) if they are found missing at the data receiver. 127 The partial checksum extension allows the sending application to 128 specify a portion of an outbound user message to be excluded from SCTP 129 checksum protection. 131 3.1 New INIT and INIT-ACK parameters 133 The following new optional parameter, are added to the INIT 134 and INIT ACK chunks. At the initialization of the association, the 135 sender of the INIT or INIT ACK chunk may include these parameters 136 to indicate its ability to support these features. 138 Parameter Name Status Type Value 139 ------------------------------------------------------------- 140 Unreliable Streams Optional 0xC000 141 Partial Checksum Support Optional 0xC004 143 3.1.1 Unreliable Streams Parameter Definition 145 The Unreliable Streams parameter is added to the INIT and INIT ACK 146 chunks. At the initialization of the association, the sender of the 147 INIT or INIT ACK chunk shall include this optional parameter 148 to inform its peer that it is able to support unreliable streams 149 and to designate its unreliable outbound streams. If no streams 150 are marked as unreliable but the sender does support the 151 unreliable streams option the sender SHOULD include a parameter 152 with no u-stream ranges and a fixed Parameter Length of 4. 154 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Parameter Type = 0xC000 | Parameter Length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | u-stream start #1 = US1 | u-stream end #1 = UE1 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 / / 162 \ . . . . \ 163 / / 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | u-stream start #k = USk | u-stream end #k = UEk | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Type: 16 bit u_int 170 0xC000, indicating Unreliable Streams parameter 172 Length: 16 bit u_int 174 Indicate the size of the parameter in octets, including the 175 Type, Length, u-stream start, and u-stream end fields. 177 u-stream start: 16 bit u_int, and 178 u-stream end: 16 bit u_int 180 Each pair of u-stream start and u-stream end fields defines one or more 181 unreliable outbound streams, starting from stream number US and 182 ending with stream number UE. The union of all the pairs 183 together defines the complete sub-set of all unreliable 184 outbound streams. 186 The following are some examples of unreliable stream designation 187 (assuming OS = 10): 189 Example 1: (assuming OS = 10) 191 +------------+-----------+ 192 |type=0xC000 | length=8 | Streams Mode 193 +------------+-----------+ ==> --------------------- 194 | u-start= 3 | u-end= 5 | 0 - 2 reliable 195 +------------+-----------+ 3 - 5 unreliable 196 6 - 9 reliable 198 Example 2: (assuming OS = 10) 200 +------------+-----------+ 201 |type=0xC000 | length=12 | Streams Mode 202 +------------+-----------+ ==> --------------------- 203 | u-start= 3 | u-end= 5 | 0 - 2 reliable 204 +------------+-----------+ 3 - 9 unreliable 205 | u-start= 6 | u-end= 9 | 206 +------------+-----------+ 208 Example 3: (assuming OS = 10) 209 +------------+-----------+ 210 |type=0xC000 | length=12 | Streams Mode 211 +------------+-----------+ ==> --------------------- 212 | u-start= 9 | u-end= 9 | 0 unreliable 213 +------------+-----------+ 1 - 8 reliable 214 | u-start= 0 | u-end= 0 | 9 unreliable 215 +------------+-----------+ 217 Example 4: (assuming OS = 10) 219 +------------+-----------+ 220 |type=0xC000 | length=8 | Streams Mode 221 +------------+-----------+ ==> --------------------- 222 | u-start= 0 | u-end= 9 | 0 - 9 unreliable 223 +------------+-----------+ 225 Example 5: (assuming OS = 10) 226 +------------+-----------+ 227 |type=0xC000 | length=4 | Streams Mode 228 +------------+-----------+ ==> --------------------- 229 0 - 9 reliable 231 3.1.2 Partial Checksum Parameter Definition 233 The Partial Checksum Parameter is added to the INIT and INIT ACK 234 chunks. At the initialization of the association, the sender of the 235 INIT or INIT ACK chunk shall include this optional parameter 236 to inform its peer that it is able to support the partial checksum 237 P-DATA (Chunk Type = 0xC3 or 195), see section 3.2.2. 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Parameter Type = 0xc004 | Parameter Length=4 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 3.2 New chunk definitions 246 The following new chunk types are added to support the two new 247 features in SCTP. 249 Chunk Type Chunk Name 250 ------------------------------------------------------ 251 11000000 Forward Cumulative TSN (FORWARD TSN) 252 11000011 Partial Checksum Data Chunk (P-DATA) 254 The FORWARD TSN supports the unreliable stream. The Partial Checksum 255 Data Chunk supports data chunks that are not completely covered by the 256 Adler32 checksum in the SCTP packet header. 258 3.2.1 Forward Cumulative TSN Chunk Definition (FORWARD TSN) 259 Forward Cumulative TSN chunk shall be used by the data sender to 260 inform the data receiver to adjust its cumulative received TSN point 261 forward because some missing TSNs are associated with unreliable data 262 chunks and will no longer be retransmitted by the sender. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |1 1 0 0 0 0 0 0| Chunk Flags |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | New Cumulative TSN | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Chunk Flags: 274 Set to all zeros on transmit and ignored on receipt. 276 New Cumulative TSN: 32 bit u_int 278 This indicates the new cumulative TSN to the data receiver. 279 Upon the reception of this value, the data receiver shall consider 280 any missing TSNs earlier than this value received and stop reporting 281 them as gaps in the subsequent SACKs. 283 3.2.2 Partial Checksum Data Chunk (P-DATA) 285 The following format MUST be used for the P-DATA chunk: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |1 1 0 0 0 0 1 1| Reserved|U|B|E| Length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | TSN | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Stream Identifier S | Stream Sequence Number n | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Payload Protocol Identifier | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Checksum Coverage | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 \ \ 301 / User Data (seq n of Stream S) / 302 \ \ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Reserved: 5 bits 307 Should be set to all '0's and ignored by the receiver. 309 U bit: 1 bit 310 Same as in a DATA chunk [RFC2960], the (U)nordered bit, if set to '1', 311 indicates that this is an unordered P-DATA chunk, and there is no 312 Stream Sequence Number assigned to this P-DATA chunk. Therefore, the 313 receiver MUST ignore the Stream Sequence Number field. 315 Unordered P-DATA chunks MUST be dispatched to the upper layer by the 316 receiver without any attempt to re-order them. 318 B bit: 1 bit 320 MUST be set to 1 by the sender. 322 E bit: 1 bit 324 MUST be set to 1 by the sender. 326 Length: 16 bits (unsigned integer) 328 This field indicates the length of the P-DATA chunk in bytes from the 329 beginning of the type field to the end of the user data field 330 excluding any padding. For example, a P-DATA chunk with 5 bytes of 331 user data field will have Length set to 25 (indicating 25 bytes). 333 TSN: 32 bits (unsigned integer) 335 This value represents the TSN for this P-DATA chunk. The valid range 336 of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 337 after reaching 4294967295. 339 Stream Identifier S: 16 bits (unsigned integer) 341 Identifies the stream to which the following the user data belongs. 343 Stream Sequence Number n: 16 bits (unsigned integer) 345 This value represents the stream sequence number of the following 346 user data within the stream S. Valid range is 0 to 65535. 348 Payload Protocol Identifier: 32 bits (unsigned integer) 350 Same as in a DATA chunk [RFC2960], this value represents an 351 application (or upper layer) specified protocol identifier. This 352 value is passed to SCTP by its upper layer and sent to its peer. 353 This identifier is not used by SCTP but can be used by certain 354 network entities as well as the peer application to identify the 355 type of information being carried in this P-DATA chunk. 357 The value 0 indicates no application identifier is specified by 358 the upper layer for this payload data. 360 Checksum Coverage: 32 bits (unsigned integer) 362 This field contains an integer that indicates how much User Data (in 363 octets) of this P-DATA chunk is covered by the Adler32 checksum in 364 the SCTP packet common header. 366 Note, all chunk headers, as well as the common header of the SCTP 367 packet are always covered by the packet checksum, regardless of 368 the value of the Checksum Coverage. 370 The coverage area is defined as starting from the first transmitted 371 byte in the User Data part of the Chunk for exactly 372 'Checksum Coverage' bytes in length. 374 For example, if a value of "5" appears in the Checksum Coverage 375 field, only the first 5 bytes of the User Data are included in the 376 calculation of the packet checksum. A value of "0" in the Checksum 377 Coverage field will indicate that all the User Data in this P-DATA 378 chunk is excluded from the packet checksum. 380 The sender of a P-DATA chunk SHOULD NOT set a value of Checksum 381 Coverage larger than the length of the User Data in the chunk. In 382 other words, the Checksum Coverage SHOULD be set smaller than or 383 equal to the chunk Length - 20. 385 On the receiver side, if the value of Checksum Coverage in a 386 received P-DATA chunk is found larger than the length of the User 387 Data in the chunk, the receiver MUST accept the chunk and MUST 388 consider the entire User Data in the chunk covered by the Adler-32 389 checksum. 391 User Data: variable length 393 This is the payload user data. The implementation MUST pad the end 394 of the data to a 4 byte boundary with all-zero bytes. Any padding 395 MUST NOT be included in the Length field. A sender MUST never add 396 more than 3 bytes of padding. 398 4. Unreliable Stream Operations 400 In this section, we first defines the procedures for opening 401 unreliable streams in an SCTP association. Then, we will discuss 402 procedures for sending and receiving unreliable SCTP data chunks. 404 4.1 Initialization of Unreliable Streams 406 If the SCTP data sender plans to send unreliable data, at the 407 initialization of the association it MUST include the Unreliable 408 Streams parameter in its INIT or INIT ACK chunk to indicate to its 409 peer which of its outbound streams are going to be used as unreliable 410 streams. 412 Upon the reception of the Unreliable Streams parameter, the data 413 receiver SHALL determine and record the mode (reliable or unreliable) 414 of each inbound stream, as it allocates resource for its inbound 415 streams. 417 Note, if the data receiver does not support unreliable inbound 418 streams, it SHOULD treat the Unreliable Streams parameter as an 419 invalid or unrecognized parameter and respond to the data sender with 420 an operational error, following the rules defined in Section 5.1 421 of [RFC2960]. 423 Upon reception of the operational error indicating that its peer does 424 not support unreliable streams, the data sender may choose to either: 426 1) end the initiation process, in consideration of the peer's 427 inability of meeting the requested features for the new 428 association, or 429 2) continue the initiation process, but with the understanding that 430 ALL its outbound streams will be reliable. 432 In either case, the data sender SHOULD inform its upper layer its 433 peer's inability of supporting unreliable data transfer. 435 Initiation of streams as reliable and/or unreliable may be under the 436 control of the SCTP user. Hence, the ULP primitive "ASSOCIATE" (see 437 Section 10.1 of [RFC2960]) should be expanded to contain the optional 438 U-stream-start and U-stream-end values. 440 4.2 Send Unreliable Data 442 During the lifetime of the association, any user data sent to an 443 unreliable stream will be treated as unreliable user data and will 444 automatically be transmitted in unreliable mode. 446 Note, fragmentation MUST NOT be performed on an unreliable user 447 message. In other words, an unreliable user message MUST be sent in a 448 single DATA or P-DATA chunk regardless of its size. 450 The SCTP data sender shall handle user data sent to an unreliable 451 stream the same way as it handles user data sent to a reliable stream 452 (i.e., the same timer rules, congestion control rules, failure 453 detection rules, RTO control rules, etc.), with the following 454 exceptions: 456 A1) The sender maintains a "Peer.Cumulative.TSN" for each peer so as 457 to track the latest cumulative TSN point of the peer (Note, this 458 variable may already exist in a classic SCTP implementation for 459 outqueue management and for detecting out-of-order SACKs). 461 A2) Before retransmitting a DATA chunk (due to either a T3-rtx timer 462 expiration as defined in 6.3.3 of [RFC2960] or a 4th missing 463 indication as defined in 7.2.4 of [RFC2960]), the SCTP data 464 sender MUST check whether the DATA chunk is being transmitted on 465 an unreliable stream. If so, it will perform the following: 467 B1) Check the value of the unreliable retransmission counter 468 "Unrel.Trans.Count" value for the DATA chunk. This value may 470 be set by the SCTP user to 0 (no retransmission) for complete 471 unreliability, or N (where N >0) for limited reliability at 472 the time when the user message is passed to SCTP. 474 B2) If the "Unrel.Trans.Count" of the chunk is currently greater 475 than 0, the sender MUST retransmit the data chunk and then 476 decrease the "Unrel.Trans.Count" by 1. The same rules for 477 retransmission as defined in [RFC2960] SHALL be used for RTO 478 calculation, destination selection, error reporting, etc. 480 B3) If the "Unrel.Trans.Count" is currently 0, the sender MUST NOT 481 retransmit the data chunk. Instead, the sender MUST mark the 482 data chunk as being finally acked. 484 A3) whenever the data sender receives a SACK from the data receiver, 485 it SHALL first process the SACK using the normal procedures as 486 defined in [RFC2960] for classic SCTP. This includes, among other 487 things: a) check if the SACK is received out-of-order; if not, b) 488 adopt the Cumulative TSN ACK carried in the SACK as the new 489 "Peer.Cumulative.TSN"; and c) process any gap reports if present 490 (see [RFC2960]). 492 The data sender MUST then perform the following additional 493 steps: 495 C1) Try to further advance the "Peer.Cumulative.TSN" locally, 496 that is, to move "Peer.Cumulative.TSN" up as long as the 497 chunk next in the out-queue is marked as acknowledged. For 498 example (assuming a SACK arrived with the Cumulative TSN 499 ACK = 102), 501 out-queue at the end of ==> out-queue after cmTSN 502 normal SACK processing local advancement 504 ... ... 505 cmTSN -> 102 acked 102 acked 506 103 acked 103 acked 507 104 acked cmTSN -> 104 acked 508 105 105 509 106 acked 106 acked 510 ... ... 512 Here, the data sender successfully advanced the 513 "Peer.Cumulative.TSN" from 102 to 104 locally. 515 C2) Whenever a local advancement of the "Peer.Cumulative.TSN" is 516 made, the data sender MUST send the data receiver a 517 FORWARD TSN chunk containing the new value of the 518 "Peer.Cumulative.TSN" (which is 104 in the above example). 520 Note, an endpoint MUST NOT use the forward TSN for any other 521 purposes other than the above circumstance. 523 Note, if a TSN is indicated as missing by a SACK carrying gap 524 reports AND the TSN is earlier than the current 525 "Peer.Cumulative.TSN", the data sender MUST NOT take any action 526 on this TSN, i.e., it MUST ignore this missing report to this 527 TSN. When this happens, it is normally an indication that a 528 previous FORWARD TSN from the data sender may have been lost in 529 the network. 531 Note, the detection criterion for out-of-order SACKs MUST remains 532 the same as stated in RFC2960, that is, a SACK is only considered 533 out-of-order if the Cumulative TSN ACK carried in the SACK is 534 earlier than that of the previous received SACK (i.e., the 535 comparison MUST NOT be made against the locally advanced 536 "Peer.Cumulative.TSN"). 538 The ULP primitive "DATA" (defined in Section 10.1 of [RFC2960]) should 539 be expanded to contain an optional unreliable retransmission parameter 540 to assign a "Unrel.Trans.Count" value to each user message to be sent 541 to an unreliable stream. 543 4.3 Receive Unreliable Data 545 Regardless whether a DATA chunk arrives from a reliable stream or an 546 unreliable stream, the receiver MUST perform the same TSN handling 547 (e.g, duplicate detection, gap detection, SACK generation, cumulative 548 TSN advancement, etc.) as defined in [RFC2960]. 550 However, whenever a FORWARD TSN chunk arrives the data receiver MUST 551 update its cumulative TSN to the value carried in the FORWARD TSN 552 chunk, and MUST stop reporting any missing TSNs before the new 553 cumulative TSN. 555 Whenever an unreliable DATA chunk arrives with the 'U' bit set to '0' 556 (indicating ordered delivery) and is out of order, the receiver must 557 hold the chunk for reordering. However since it is possible that the 558 DATA chunk(s) being waited upon is one that will not be retransmitted 559 by the sender, when a FORWARD TSN chunk arrives, the receiver MUST 560 examine all of its unreliable stream reordering queues, and 561 immediately make available for delivery any messages that carry a TSN 562 earlier than the new cumulative TSN updated by the FORWARD TSN. 564 4.4. Other Issues on Unreliable Data 566 4.4.1 Unreliable Data Stream Multiplexing 568 Sometimes, it is desirable to aggregate different real time media 569 streams (e.g., RTP streams) and send them over a single communication 570 connection, and normally unreliable transport is preferred for these 571 types of media streams. 573 With U-SCTP this is easily achieved by assigning each different media 574 stream to a different unreliable SCTP stream and enabling the SCTP 575 data bundling to perform the multiplexing. 577 The implementation of the data sender MAY use a bundling timer with a 578 time interval adjusted to the timing characteristics of the specific 579 media type in order to achieve the optimal multiplexing efficiency. 581 4.4.2 Fault Tolerant Unreliable Data Transfer 583 When the data receiver is multi-homed, unreliable data transfer using 584 U-SCTP will obtain the same fault tolerance benefit as that of the 585 reliable data services across an SCTP association. 587 This is because the data sender still follows the same failure 588 detection rules and still counts the omitted retransmission against 589 the association and the destination transport address to which the 590 unreliable DATA chunk was originally sent. Thus, when failure occurs, 591 the data sender will detect the failure and shift the unreliable data 592 services to an alternate destination address, following the same 593 procedures as defined in Section 8 of [RFC2960] for reliable data transfer. 595 4.4.3 Unreliable Data Out-of-order Detection 597 Detecting out-of-order data in an unreliable stream is useful for some 598 applications (e.g. Fiber channel or SCSI over IP). With U-SCTP this 599 becomes possible - the upper layer simply needs to examine the the 600 stream sequence number of the arrived user messages to detect any 601 missing data or out-of-order data. This detection only works when 602 the DATA chunks are sent in order, i.e. their "U" bit MUST NOT be 603 set. 605 5 Usage of the P-DATA chunk. 607 For some applications it is beneficial NOT to discard a data 608 packet due to bit errors within the User Data portion. For this 609 type of applications this new optional chunk type is defined. 611 All rules defined in [RFC2960] for DATA Chunks MUST be followed for 612 the P-DATA chunk with the following exceptions: 614 E1) When passing a partial checksum user message to SCTP data sender, 615 the upper layer should indicate how many bytes of the first 616 portion of the user message need checksum protection. The data 617 sender will then put this value into the Checksum Coverage field 618 of the outbound P-DATA chunk. 620 E2) The Checksum Coverage field defines how much of this P-DATA 621 chunk the Adler-32 checksum is to cover. During checksum 622 computation the sender and receiver MUST use this field 623 to determine how much of a P-DATA chunk to add to the 624 Adler-32 checksum of the SCTP packet. 626 For each P-DATA in a received SCTP packet, after summing the 627 chunk header bytes and the specified number of User Data bytes to 628 the checksum, the receiver MUST skip to the next chunk if this 629 P-DATA is not the last chunk in the SCTP packet and MUST NOT 630 include the rest of the User Data in the P-DATA chunk in its 631 checksum computation. 633 E3) A sender MUST NOT send a P-DATA chunk unless the 'Partial Checksum 634 Support' parameter was seen in the INIT or INIT-ACK from its peer. 636 It is important to note that P-DATA chunk uses the SAME TSN values as 637 the normal DATA Chunk type. The sender and receiver do NOT hold 638 separate TSN sequence spaces for DATA and P-DATA. Instead, the two 639 chunk types use a single TSN sequence space. 641 In effect the P-DATA chunk is treated in all considerations to be a 642 DATA chunk, with all of the normal DATA chunk rules for congestion 643 control effecting this chunk. The only difference in treatment of 644 P-DATA chunk comes during the calculation and verification of the 645 Adler-32 checksum. 647 P-DATA chunk MAY be used with either a reliable or un-reliable stream, 648 no restrictions are placed on its usage except those listed above. 650 Use of the P-DATA chunk may be under the control of the SCTP user. 651 Hence, the ULP primitive "DATA" (see section 10.1 of RFC2960) should 652 be expanded to contain an optional Checksum Coverage value. 654 When a reliable user message subscribing for partial checksum 655 protection is fragmented at the SCTP sender, the sender shall 656 calculate the Checksum Coverage value for each of the resulting P-DATA 657 chunks, based upon the user's original coverage requirement. 659 6. Acknowledgments 661 The authors would like to thank Scott Bradner, Jon Berger, and others 662 for their comments. 664 7. Authors' Addresses 666 Qiaobing Xie Tel: +1-847-632-3028 667 Motorola, Inc. EMail: qxie1@email.mot.com 668 1501 W. Shure Drive, #2309 669 Arlington Heights, IL 60004 670 USA 672 Randall R. Stewart Tel: +1-815-477-2127 673 Cisco Systems, Inc. EMail: rrs@cisco.com 674 8725 West Higgins Road 675 Suite 300 676 Chicago, Ill 60631 678 Chip Sharp Tel: +1-919-392-3121 679 Cisco Systems Inc. EMail:chsharp@cisco.com 680 7025 Kit Creek Road 681 Research Triangle Park, NC 27709 682 USA 684 Ian Rytina Tel: +61-3-9301-6164 685 Ericsson Australia EMail:ian.rytina@ericsson.com 686 37/360 Elizabeth Street 687 Melbourne, Victoria 3000 688 Australia 690 8. References 692 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 693 RFC 2026, October 1996. 695 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 698 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 699 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, 700 L. Zhang, and, V. Paxson, "Stream Control Transmission 701 Protocol," RFC2960, October 2000. 703 This Internet Draft expires in 6 months from February 2001.