Network Working Group Q. Xie INTERNET-DRAFT Motorola R. R. Stewart C. Sharp Cisco I. Rytina Ericsson expires in six months August 3,2000 SCTP Unreliable Data Mode Extension Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Xie, et al [Page 1] Internet Draft SCTP Unreliable Data Mode Extension April 2000 Abstract This document describes an extension to the Stream Control Transmission Protocol (SCTP) [1] to provide unreliable data transfer services. The benefits of this extension includes unified congestion control over reliable and unreliable data streams, single association for multi-content data services, link level fault tolerance for unreliable data transfer, unreliable data stream multiplexing, etc. 1. Introduction Taking advantage of the extensibility of SCTP, this document adds unreliable data transfer services to SCTP. The design presented here allows the co-existence of unreliable data streams and reliable streams in a single SCTP association. The following are some advantages for integrating unreliable data services into SCTP: 1) Unreliable extension to SCTP (U-SCTP) supports congestion control and congestion avoidance over unreliable data traffic; this is very desirable since it is much friendlier towards the network than UDP. 2) Some applications services can greatly benefit from U-SCTP by using a single SCTP association to carry both reliable content (e.g., text, billing, accounting, set-up information, etc.) and unreliable content (e.g., Fiber channel, SCSI over IP, etc.). 3) U-SCTP allows the use of a unified congestion control across both reliable and unreliable traffic between two endpoints. This has the potential for better utilization of network resources, achieving similar objectives of the Endpoint Congestion Management (ecm) Working Group. 4) Taking advantage of SCTP data chunk bundling function, sending multiple unreliable data streams across a single SCTP association creates a very efficient and effective way of data multiplexing. 5) U-SCTP gives even the unreliable data traffic "link-level" fault tolerance, taking advantage of SCTP multi-homing ability. This is not possible with UDP. 6) U-SCTP can achieve either ordered or unordered unreliable data transfer, while UDP is incapable of controlling the order of data delivery. 7) An application can control its retransmission policies if retransmission is deemed needed. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [18]. 3. Unreliable Data Extension Design With the present extension, an SCTP data sender will be allowed to designate a sub-set of its outbound streams to be unreliable streams. The user data chunks sent to an unreliable stream will share the same TSN space, the same congestion control/avoidance treatment, and the same transmission priority as those sent to a reliable stream, but they will not be retransmitted if they are found missing at the data receiver. 3.1 Unreliable Streams Parameter Definition The following new optional parameter, namely Unreliable Streams, is added to the INIT and INIT ACK chunks. At the initialization of the association, the sender of the INIT or INIT ACK chunk shall include this optional parameter inside the INIT or INIT ACK to inform its peer about its unreliable outbound stream designation. Parameter Name Status Type Value ------------------------------------------------------------- Unreliable Streams Optional 0xc000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 0xc000 | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | u-stream start #1 = US1 | u-stream end #1 = UE1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ . . . . \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | u-stream start #k = USk | u-stream end #k = UEk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 bit u_int 0xc000, indicating Unreliable Streams parameter Length: 16 bit u_int Indicate the size of the parameter in octets, including the Type, Length, u-stream start, and u-stream end fields. u-stream start: 16 bit u_int, and u-stream end: 16 bit u_int Each pair of u-stream start and u-stream end fields defines one or more unreliable outbound streams, starting from stream number US and ending with stream number UE. The union of all the pairs together defines the complete sub-set of all unreliable outbound streams. The following are some examples of unreliable stream designation (assuming OS = 10): Example 1: (assuming OS = 10) +------------+-----------+ |type=0xc000 | length=8 | Streams Mode +------------+-----------+ ==> --------------------- | u-start= 3 | u-end= 5 | 0 - 2 reliable +------------+-----------+ 3 - 5 unreliable 6 - 9 reliable Example 2: (assuming OS = 10) +------------+-----------+ |type=0xc000 | length=12 | Streams Mode +------------+-----------+ ==> --------------------- | u-start= 3 | u-end= 5 | 0 - 2 reliable +------------+-----------+ 3 - 9 unreliable | u-start= 6 | u-end= 9 | +------------+-----------+ Example 3: (assuming OS = 10) +------------+-----------+ |type=0xc000 | length=12 | Streams Mode +------------+-----------+ ==> --------------------- | u-start= 9 | u-end= 9 | 0 unreliable +------------+-----------+ 1 - 8 reliable | u-start= 0 | u-end= 0 | 9 unreliable +------------+-----------+ Example 4: (assuming OS = 10) +------------+-----------+ |type=0xc000 | length=8 | Streams Mode +------------+-----------+ ==> --------------------- | u-start= 0 | u-end= 9 | 0 - 9 unreliable +------------+-----------+ 3.2 Forward Cumulative TSN Chunk Definition The following new control chunk, namely Forward Cumulative TSN chunk, shall be used by the data sender to inform the data receiver to adjust its cumulative received TSN point forward because some missing TSNs are unreliable data chunks and are hence omitted from retransmission. Chunk Type Chunk Name ------------------------------------------------------ 11000000 Forward Cumulative TSN (FORWARD TSN) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Cumulative TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: Set to all zeros on transmit and ignored on receipt. New Cumulative TSN: 32 bit u_int This indicates the new cumulative received TSN to the data receiver. Upon the reception of this value, the data receiver shall consider any missing TSNs earlier than this value received and stop reporting them as gaps in the subsequent SACKs. 4. Unreliable Stream Operations In this section, we first defines the procedures for opening unreliable streams in an SCTP association. Then, we will discuss procedures for sending and receiving unreliable SCTP data chunks. 4.1 Initialization of Unreliable Streams If the SCTP data sender plans to send unreliable data, at the initialization of the association it must include the Unreliable Streams parameter in its INIT or INIT ACK chunk to indicate to its peer which of its outbound streams are going to be used as unreliable streams. Upon the reception of the Unreliable Streams parameter, the data receiver shall determine and record the mode (reliable or unreliable) of each inbound stream, as it allocates resource for its inbound streams. Note, if the endpoint does not support unreliable inbound streams, it SHOULD treat the Unreliable Streams parameter as an invalid or unrecognized parameter, following the rules defined in Section 5.1 of [1]. The initiator of the unreliable streams may choose either to give up the initiation process or to re-initiate without the unreliable streams. Initiation of streams as reliable and/or unreliable may be under the control of the SCTP user. Hence, the ULP primitive "ASSOCIATE" (see Section 10.1 of [1]) should contain the optional U-stream-start and U-stream-end values. 4.2 Send Unreliable Data During the lifetime of the association, any user data sent to an unreliable stream is considered as unreliable user data and will automatically be transmitted in unreliable mode. The SCTP data sender shall handle user data sent to an unreliable stream the same way as it handles user data sent to a reliable stream (i.e., the same timer rules, congestion control rules, failure detection rules, RTO control rules, etc.), with the following exceptions: A) the SCTP data sender MUST NOT fragment the user data if the data is being sent through an unreliable stream, i.e., the unreliable user data MUST be sent in a single DATA chunk. B) before retransmitting a DATA chunk (due to either a T3-rxt timer expiration as defined in 6.3.3 of [1] or a 4th missing indication as defined in 7.2.4 of [1]), the SCTP data sender MUST check whether the DATA chunk is an unreliable chunk. If so, the sender MUST NOT retransmit the data chunk. Instead, the sender MUST mark the data chunk as being finally acked and advance its cumulative TSN accordingly. C) whenever the data sender receives a SACK from the data receiver that carries a cumulative TSN which is earlier than the sender's own cumulative TSN (indicating that the receiver is still waiting for some missing unreliable data chunks to advance its cumulative TSN), the sender MUST send the data receiver a FORWARD TSN chunk containing its own latest cumulative TSN. A sender MUST NOT use the forward TSN for any other purposes other than the above scenario. 4.3 Receive Unreliable Data Regardless whether a DATA chunk arrives for a reliable stream or an unreliable stream, the receiver MUST perform the same TSN handling (e.g, duplicate detection, gap detection, SACK generation, cumulative TSN advancement, etc.) as defined in [1]. However, whenever a FORWARD TSN chunk arrives the data receiver MUST update its cumulative TSN to the value carried in the FORWARD TSN chunk, and MUST stop reporting any un-received TSN before the new cumulative TSN as missing. After TSN handling, if the data arrived for an unreliable stream, the data receiver MUST immediately make the data available for the upper layer to read, bypassing the re-assembly and stream sequence re-ordering mechanisms. 5. Other Issues 5.1 Unreliable Data Stream Multiplexing Sometimes, it is desirable to aggregate different real time media streams (e.g., RTP streams) and send them over a single communication connection. And normally, unreliable transport is preferred for these types of media streams. With U-SCTP this is easily achieved by assigning each different media stream to a different unreliable SCTP stream and enabling the SCTP data bundling to perform the multiplexing. The implementation of the data sender MAY use a bundling timer with a time interval adjusted to the timing characteristics of the specific media type in order to achieve the optimal multiplexing efficiency. 5.2 Fault Tolerant Unreliable Data Transfer When the data receiver is multi-homed, unreliable data transfer using U-SCTP will obtain the same fault tolerance benefit as that of the reliable data services across an SCTP association. This is because the data sender still follows the same failure detection rules and still counts the omitted retransmission against the association and the destination transport address to which the unreliable DATA chunk was originally sent. Thus, when failure occurs, the data sender will detect the failure and shift the unreliable data services to an alternate destination address, following the same procedures as defined in Section 8 of [1] for reliable data transfer. 5.3 Unreliable Data Out-of-order Detection Detecting out-of-order data in an unreliable stream is useful for some applications (e.g. Fiber channel or SCSI over IP). With U-SCTP this becomes possible - the upper layer simply needs to examine the the stream sequence number of the delivered data chunks to detect any missing data or out-of-order data. This detection only works when the DATA chunks are sent in order, i.e. their "U" bit MUST NOT be set. 6. Authors' Addresses Qiaobing Xie Tel: +1-847-632-3028 Motorola, Inc. EMail: qxie1@email.mot.com 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Randall R. Stewart Tel: +1-815-479-8536 Cisco Systems, Inc. EMail: rrs@cisco.com 7025 Kit Creek Road Research Triangle Park, NC 27709 USA Chip Sharp Tel: +1-919-392-3121 Cisco Systems Inc. EMail:chsharp@cisco.com 7025 Kit Creek Road Research Triangle Park, NC 27709 USA Ian Rytina Tel: +61-3-9301-6164 Ericsson Australia EMail:ian.rytina@ericsson.com 37/360 Elizabeth Street Melbourne, Victoria 3000 Australia 7. References [1] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, "Stream Control Transmission Protocol," RFC XXXX, July 2000. This Internet Draft expires in 6 months from April, 2000 Xie, et al [Page ??]