Internet DRAFT - draft-xie-stewart-usctp


Network Working Group                                           Q. Xie
INTERNET-DRAFT                                                Motorola
                                                         R. R. Stewart
                                                              C. Sharp
                                                             I. Rytina
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

The list of Internet-Draft Shadow Directories can be accessed at

Xie, et al                                                    [Page 1]
Internet Draft   SCTP Unreliable Data Mode Extension        April 2000


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

  7) An application can control its retransmission policies if 
     retransmission is deemed needed.

2. Conventions

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

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

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

  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

6. Authors' Addresses

Qiaobing Xie                            Tel: +1-847-632-3028
Motorola, Inc.                          EMail:
1501 W. Shure Drive, #2309	    
Arlington Heights, IL 60004	    

Randall R. Stewart                      Tel: +1-815-479-8536
Cisco Systems, Inc.                     EMail:
7025 Kit Creek Road		    
Research Triangle Park, NC  27709   

Chip Sharp                              Tel: +1-919-392-3121
Cisco Systems Inc.            
7025 Kit Creek Road		    
Research Triangle Park, NC  27709   

Ian Rytina                              Tel: +61-3-9301-6164
Ericsson Australia            
37/360 Elizabeth Street		   
Melbourne, Victoria 3000	   

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 ??]