idnits 2.17.1 draft-ietf-tsvwg-usctp-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: ---------------------------------------------------------------------------- ** 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 24 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 (April 2001) is 8412 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: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Xie 3 INTERNET-DRAFT Motorola 4 R. R. Stewart 5 C. Sharp 6 Cisco 7 I. Rytina 8 Ericsson 9 Expires in six months April 2001 11 SCTP Unreliable Data Mode Extension 12 14 Status of This Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This memo describes an extension to the Stream Control Transmission 31 Protocol (SCTP) [RFC2960] to provide unreliable data transfer 32 services. The benefits of this extension includes unified congestion 33 control over reliable and unreliable data traffics, single association 34 for multi-type content data services, link level fault tolerance for 35 unreliable data applications, unreliable data stream multiplexing, etc. 37 TABLE OF CONTENTS 38 1. Introduction................................................. 2 39 2. Conventions.................................................. 2 40 3. Unreliable Data Design....................................... 3 41 3.1 Unreliable Streams Parameter For INIT and INIT ACK........ 3 42 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN)..... 5 43 4. Unreliable Data Operation.................................... 5 44 4.1 Initialization of Unreliable Streams...................... 5 45 4.2 Send Unreliable Data...................................... 6 46 4.3 Receive Unreliable Data................................... 8 47 4.4. Other Issues on Unreliable Data.......................... 9 48 4.4.1 Unreliable Data Stream Multiplexing................... 9 49 4.4.2 Fault Tolerant Unreliable Data Transfer............... 9 50 4.4.3 Detection of Missing Unreliable Data.................. 9 52 5. Acknowledgments.............................................. 9 53 6. Authors' Addresses........................................... 9 54 7. References...................................................10 56 1. Introduction 58 This memo adds unreliable data transfer services to SCTP. The design 59 presented in this memo allows the co-existence of unreliable data 60 streams and reliable streams in a single SCTP association. 62 The following are some of the advantages for integrating unreliable 63 data service into SCTP: 65 1) Some applications services may benefit from U-SCTP by being able 66 to use a single SCTP association to carry both reliable contents, 67 such as text pages, billing and accounting information, setup 68 signaling, and unreliable contents, such as certain type of media 69 data that does not need a reliable transport. 71 2) Unreliable data traffic carried within U-SCTP streams will enjoy 72 the same communication failure detection and protection 73 capabilities as the normal reliable SCTP data traffic does, 74 including the ability of quickly detecting a failed destination 75 address and failing-over to an alternate destination address and 76 the ability of being notified if the data receiver becomes 77 unreachable. This enables one to build high system robustness 78 into unreliable data transfer applications. 80 3) With U-SCTP streams an application can control its lost data 81 retransmission policies so as to only perform a certain times of 82 retransmission to a lost datagram. 84 4) In addition to providing unordered unreliable data transfer as 85 UDP does, U-SCTP can provides _ordered_ unreliable data 86 transfer service. 88 5) U-SCTP employs the same congestion control and congestion 89 avoidance over unreliable data traffic as it does to the normal 90 reliable traffic - this is very desirable since it is much 91 friendlier towards the network than UDP is. 93 6) Taking advantage of SCTP data chunk bundling function, sending 94 multiple unreliable data streams across a single SCTP association 95 creates a very efficient and effective way of data multiplexing. 97 2. Conventions 99 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 100 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they 101 appear in this document, are to be interpreted as described in 102 RFC 2119 [RFC2119]. 104 3. Unreliable Data Design 106 With the unreliable data extension, an SCTP data sender will be 107 allowed to designate a sub-set of its outbound streams to be 108 unreliable streams. The user data chunks sent to an unreliable stream 109 will share the same TSN space, the same congestion control/avoidance 110 treatment, and the same transmission priority as those sent to a 111 reliable stream, but they will not be retransmitted (or only be 112 retransmitted for a limited times) if they are found missing at the 113 data receiver. 115 3.1 Unreliable Streams Parameter For INIT and INIT ACK 117 The following new optional parameter is added to the INIT and INIT ACK 118 chunks. 120 Parameter Name Status Type Value 121 ------------------------------------------------------------- 122 Unreliable Streams Optional 0xC000 124 At the initialization of the association, the sender of the INIT or 125 INIT ACK chunk shall include this optional parameter to inform its 126 peer that it is able to support unreliable streams and to designate 127 its unreliable outbound streams. 129 The format of the Unreliable Streams parameter is defined as follows: 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Parameter Type = 0xC000 | Parameter Length = variable | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | u-stream start #1 = US1 | u-stream end #1 = UE1 | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 / / 138 \ . . . . \ 139 / / 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | u-stream start #k = USk | u-stream end #k = UEk | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Type: 16 bit u_int 146 0xC000, indicating Unreliable Streams parameter 148 Length: 16 bit u_int 150 Indicate the size of the parameter in octets, including the 151 Type, Length, u-stream start, and u-stream end fields. 153 u-stream start: 16 bit u_int, and 154 u-stream end: 16 bit u_int 155 Each pair of u-stream start and u-stream end fields defines one 156 or more unreliable outbound streams, starting from stream number 157 US and ending with stream number UE. The union of all the pairs 158 together defines the complete sub-set of all unreliable 159 outbound streams. 161 The following are some examples of unreliable stream designation 162 (assuming OS = 10): 164 Example 1: (assuming OS = 10) 166 +------------+-----------+ 167 |type=0xC000 | length=8 | Streams Mode 168 +------------+-----------+ ==> --------------------- 169 | u-start= 3 | u-end= 5 | 0 - 2 reliable 170 +------------+-----------+ 3 - 5 unreliable 171 6 - 9 reliable 173 Example 2: (assuming OS = 10) 175 +------------+-----------+ 176 |type=0xC000 | length=12 | Streams Mode 177 +------------+-----------+ ==> --------------------- 178 | u-start= 3 | u-end= 5 | 0 - 2 reliable 179 +------------+-----------+ 3 - 9 unreliable 180 | u-start= 6 | u-end= 9 | 181 +------------+-----------+ 183 Example 3: (assuming OS = 10) 185 +------------+-----------+ 186 |type=0xC000 | length=12 | Streams Mode 187 +------------+-----------+ ==> --------------------- 188 | u-start= 9 | u-end= 9 | 0 unreliable 189 +------------+-----------+ 1 - 8 reliable 190 | u-start= 0 | u-end= 0 | 9 unreliable 191 +------------+-----------+ 193 Example 4: (assuming OS = 10) 195 +------------+-----------+ 196 |type=0xC000 | length=8 | Streams Mode 197 +------------+-----------+ ==> --------------------- 198 | u-start= 0 | u-end= 9 | 0 - 9 unreliable 199 +------------+-----------+ 201 Example 5: (assuming OS = 10) 202 +------------+-----------+ 203 |type=0xC000 | length=4 | Streams Mode 204 +------------+-----------+ ==> --------------------- 205 0 - 9 reliable 207 If no streams are marked as unreliable but the sender does support the 208 unreliable streams option, the sender still SHOULD include a parameter 209 with no u-stream ranges and a fixed Parameter Length of 4. 211 3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN) 213 The following chunk type is defined in order to support the SCTP 214 unreliable stream operation: 216 Chunk Type Chunk Name 217 ------------------------------------------------------ 218 11000000 Forward Cumulative TSN (FORWARD TSN) 220 This chunk shall be used by the data sender to inform the data 221 receiver to adjust its cumulative received TSN point forward because 222 some missing TSNs are associated with unreliable data chunks and will 223 no longer be retransmitted by the sender. 225 Forward Cumulative TSN chunk has the following format: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |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| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | New Cumulative TSN | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Chunk Flags: 237 Set to all zeros on transmit and ignored on receipt. 239 New Cumulative TSN: 32 bit u_int 241 This indicates the new cumulative TSN to the data receiver. Upon 242 the reception of this value, the data receiver shall consider 243 any missing TSNs earlier than or equal to this value as received 244 and stop reporting them as gaps in any subsequent SACKs. 246 4. Unreliable Data Operation 248 In this section, we first define the procedures for opening 249 unreliable streams in an SCTP association. Then, we will discuss 250 procedures for sending and receiving unreliable SCTP data chunks. 252 4.1 Initialization of Unreliable Streams 254 If the SCTP data sender plans to send unreliable data, at the 255 initialization of the association it MUST include the Unreliable 256 Streams parameter in its INIT or INIT ACK chunk to indicate to its 257 peer which of its outbound streams are going to be used as unreliable 258 streams. 260 Upon the reception of the Unreliable Streams parameter, the data 261 receiver SHALL determine and record the mode (reliable or unreliable) 262 of each inbound stream, as it allocates resource for its inbound 263 streams. 265 Note, if the data receiver does not support unreliable inbound 266 streams, it SHOULD treat the Unreliable Streams parameter as an 267 invalid or unrecognized parameter and respond to the data sender with 268 an operational error, following the rules defined in Section 5.1 269 of [RFC2960]. 271 Upon reception of the operational error indicating that its peer does 272 not support unreliable streams, the data sender may choose to either: 274 1) end the initiation process, in consideration of the peer's 275 inability of meeting the requested features for the new 276 association, or 277 2) continue the initiation process, but with the understanding that 278 ALL its outbound streams will be reliable. 280 In either case, the data sender SHOULD inform its upper layer its 281 peer's inability of supporting unreliable data transfer. 283 Initiation of streams as reliable and/or unreliable may be under the 284 control of the SCTP user. Hence, the ULP primitive "ASSOCIATE" (see 285 Section 10.1 of [RFC2960]) should be expanded to contain the optional 286 U-stream-start and U-stream-end values. 288 4.2 Send Unreliable Data 290 During the lifetime of the association, any user data sent to an 291 unreliable stream will be treated as unreliable user data and will 292 automatically be transmitted in unreliable mode. 294 The data sender shall fragment an unreliable user message if its size 295 is larger than the current PMTU. The sender shall follow the 296 fragmentation rules and procedures as defined in [RFC2960]. 298 The SCTP data sender shall handle user data sent to an unreliable 299 stream the same way as it handles user data sent to a reliable stream 300 (i.e., the same timer rules, congestion control rules, failure 301 detection rules, RTO control rules, etc.), with the following 302 exceptions: 304 A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer 305 to track a theoretical cumulative TSN point of the peer (Note, 306 this is a new protocol variable and its value is NOT necessarily 307 the same as the classic SCTP Cumulative TSN Ack Point as defined 308 in [RFC2960]). 310 A2) Before retransmitting a DATA chunk (due to either a T3-rtx timer 311 expiration as defined in 6.3.3 of [RFC2960] or a 4th missing 312 indication as defined in 7.2.4 of [RFC2960]), the SCTP data 313 sender MUST check whether the DATA chunk is being transmitted on 314 an unreliable stream. If so, it will perform the following: 316 B1) Check the value of the unreliable retransmission counter 317 "Unrel.Trans.Count" value for the DATA chunk. This value may 318 be set by the SCTP user to 0 (no retransmission) for complete 319 unreliability, or N (where N >0) for limited reliability at 320 the time when the user message is passed to SCTP. 322 B2) If the "Unrel.Trans.Count" of the chunk is currently greater 323 than 0, the sender MUST retransmit the data chunk and then 324 decrease the "Unrel.Trans.Count" by 1. The same rules for 325 retransmission as defined in [RFC2960] SHALL be used for RTO 326 calculation, destination selection, error reporting, etc. 328 B3) If the "Unrel.Trans.Count" is currently 0, the sender MUST NOT 329 retransmit the data chunk. Instead, the sender MUST mark the 330 data chunk as being finally acked. 332 A3) whenever the data sender receives a SACK from the data receiver, 333 it SHALL first process the SACK using the normal procedures as 334 defined in Section 6.2.1 of [RFC2960]. 336 The data sender MUST then perform the following additional 337 steps: 339 C1) Update the "Advanced.Peer.Ack.Point" to the Cumulative TSN 340 ACK carried in the SACK __if__ the former is behind. 342 C2) Try to further advance the "Advanced.Peer.Ack.Point" locally, 343 that is, to move "Advanced.Peer.Ack.Point" up as long as the 344 chunk next in the out-queue is marked as acknowledged. For 345 example (assuming that a SACK arrived with the Cumulative TSN 346 ACK = 102 and the Advanced.Peer.Ack.Point is updated to this 347 value), 349 out-queue at the end of ==> out-queue after Adv.Ack.Point 350 normal SACK processing local advancement 352 ... ... 353 Adv.Ack.Pt-> 102 acked 102 acked 354 103 acked 103 acked 355 104 acked Adv.Ack.P-> 104 acked 356 105 105 357 106 acked 106 acked 358 ... ... 360 In this example, the data sender successfully advanced the 361 "Advanced.Peer.Ack.Point" from 102 to 104 locally. 363 C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" 364 becomes more advanced than the Cumulative TSN ACK carried in 365 the received SACK, the data sender MUST send the data 366 receiver a FORWARD TSN chunk containing the latest value of 367 the "Advanced.Peer.Ack.Point". 369 Note, an endpoint MUST NOT use the FORWARD TSN for any 370 purposes other than the above circumstance. 372 Note, if a TSN is indicated as missing by a SACK carrying gap 373 reports AND the TSN is earlier than the current 374 "Advanced.Peer.Ack.Point", the data sender MUST NOT take any 375 action on this TSN, i.e., it MUST ignore this missing report to 376 this TSN. When this happens, it is normally an indication that a 377 previous FORWARD TSN from the data sender may have been lost in 378 the network. 380 Note, the detection criterion for out-of-order SACKs MUST remains 381 the same as stated in RFC2960, that is, a SACK is only considered 382 out-of-order if the Cumulative TSN ACK carried in the SACK is 383 earlier than that of the previous received SACK (i.e., the 384 comparison MUST NOT be made against "Advanced.Peer.Ack.Point"). 386 The ULP primitive "DATA" (defined in Section 10.1 of [RFC2960]) should 387 be expanded to contain an optional unreliable retransmission parameter 388 to assign a "Unrel.Trans.Count" value to each user message to be sent 389 to an unreliable stream. 391 4.3 Receive Unreliable Data 393 Regardless whether a DATA chunk arrives from a reliable stream or an 394 unreliable stream, the receiver MUST perform the same TSN handling 395 (e.g, duplicate detection, gap detection, SACK generation, cumulative 396 TSN advancement, etc.) as defined in [RFC2960]. 398 However, whenever a FORWARD TSN chunk arrives the data receiver MUST 399 update its cumulative TSN to the value carried in the FORWARD TSN 400 chunk, and MUST stop reporting any missing TSNs earlier than or equal 401 to the new cumulative TSN. 403 Whenever an unreliable DATA chunk arrives with the 'U' bit set to '0' 404 (indicating ordered delivery) and is out of order, the receiver must 405 hold the chunk for reordering. However since it is possible that the 406 DATA chunk(s) being waited upon is one that will not be retransmitted 407 by the sender, when a FORWARD TSN chunk arrives, the receiver MUST 408 examine all of its unreliable stream reordering queues, and 409 immediately make available for delivery any messages that carry a TSN 410 (or a starting TSN in the case of reassembled messages) earlier than 411 the new cumulative TSN updated by the FORWARD TSN. 413 When receiving a FORWARD TSN, cautions MUST also be taken in updating 414 the re-assembly queue of the receiver, including the removal of any 415 partially reassembled message which is still missing one or more TSNs 416 earlier than or equal to the new cumulative TSN updated by the FORWARD 417 TSN. 419 4.4. Other Issues on Unreliable Data 421 4.4.1 Unreliable Data Stream Multiplexing 423 Sometimes, it is desirable to aggregate different media streams and 424 send them over a single communication connection, and normally 425 unreliable transport is preferred for these types of media streams. 427 With U-SCTP this is easily achieved by assigning each different media 428 stream to a different unreliable SCTP stream and letting the SCTP's 429 built-in data bundling mechanism to perform the multiplexing at the 430 sender and demultiplexing at the receiver. 432 4.4.2 Fault Tolerant Unreliable Data Transfer 434 When the data receiver is multi-homed, unreliable data transfer using 435 U-SCTP will obtain the same fault tolerance benefit as that of the 436 reliable data services across an SCTP association. 438 This is because the data sender still follows the same failure 439 detection rules and still counts the omitted retransmission against 440 the association and the destination transport address to which the 441 unreliable DATA chunk was originally sent. Thus, when failure occurs, 442 the data sender will detect the failure and shift the unreliable data 443 services to an alternate destination address, following the same 444 procedures as defined in Section 8 of [RFC2960] for reliable data 445 transfer. 447 4.4.3 Detection of Missing Unreliable Data 449 Detecting missing data in an unreliable stream is useful for some 450 applications (e.g. Fiber channel or SCSI over IP). With U-SCTP this 451 becomes possible - the upper layer simply needs to examine the stream 452 sequence number of the arrived user messages of that stream to detect 453 any missing data. Note, this detection only works when all the 454 messages in that stream are sent in order, i.e. their "U" bit MUST NOT 455 be set. 457 5. Acknowledgments 459 The authors would like to thank Scott Bradner, Jon Berger, John 460 Loughney, Ivan Arias Rodriguez, and others for their comments. 462 6. Authors' Addresses 464 Qiaobing Xie Tel: +1-847-632-3028 465 Motorola, Inc. EMail: qxie1@email.mot.com 466 1501 W. Shure Drive, #2309 467 Arlington Heights, IL 60004 468 USA 470 Randall R. Stewart Tel: +1-815-477-2127 471 Cisco Systems, Inc. EMail: rrs@cisco.com 472 8725 West Higgins Road 473 Suite 300 474 Chicago, Ill 60631 476 Chip Sharp Tel: +1-919-392-3121 477 Cisco Systems Inc. EMail:chsharp@cisco.com 478 7025 Kit Creek Road 479 Research Triangle Park, NC 27709 480 USA 482 Ian Rytina Tel: +61-3-9301-6164 483 Ericsson Australia EMail:ian.rytina@ericsson.com 484 37/360 Elizabeth Street 485 Melbourne, Victoria 3000 486 Australia 488 7. References 490 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 491 RFC 2026, October 1996. 493 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 497 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, 498 L. Zhang, and, V. Paxson, "Stream Control Transmission 499 Protocol," RFC2960, October 2000. 501 This Internet Draft expires in 6 months from April 2001.