[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
Network Working Group Q. Xie
INTERNET-DRAFT Motorola
R. R. Stewart
C. Sharp
Cisco
I. Rytina
Ericsson
Expires in six months April 2001
SCTP Unreliable Data Mode Extension
<draft-ietf-tsvwg-usctp-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026 [RFC2026]. 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.
Abstract
This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) [RFC2960] to provide unreliable data transfer
services. The benefits of this extension includes unified congestion
control over reliable and unreliable data traffics, single association
for multi-type content data services, link level fault tolerance for
unreliable data applications, unreliable data stream multiplexing, etc.
TABLE OF CONTENTS
1. Introduction................................................. 2
2. Conventions.................................................. 2
3. Unreliable Data Design....................................... 3
3.1 Unreliable Streams Parameter For INIT and INIT ACK........ 3
3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN)..... 5
4. Unreliable Data Operation.................................... 5
4.1 Initialization of Unreliable Streams...................... 5
4.2 Send Unreliable Data...................................... 6
4.3 Receive Unreliable Data................................... 8
4.4. Other Issues on Unreliable Data.......................... 9
4.4.1 Unreliable Data Stream Multiplexing................... 9
4.4.2 Fault Tolerant Unreliable Data Transfer............... 9
4.4.3 Detection of Missing Unreliable Data.................. 9
Xie, et al [Page 1]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
5. Acknowledgments.............................................. 9
6. Authors' Addresses........................................... 9
7. References...................................................10
1. Introduction
This memo adds unreliable data transfer services to SCTP. The design
presented in this memo allows the co-existence of unreliable data
streams and reliable streams in a single SCTP association.
The following are some of the advantages for integrating unreliable
data service into SCTP:
1) Some applications services may benefit from U-SCTP by being able
to use a single SCTP association to carry both reliable contents,
such as text pages, billing and accounting information, setup
signaling, and unreliable contents, such as certain type of media
data that does not need a reliable transport.
2) Unreliable data traffic carried within U-SCTP streams will enjoy
the same communication failure detection and protection
capabilities as the normal reliable SCTP data traffic does,
including the ability of quickly detecting a failed destination
address and failing-over to an alternate destination address and
the ability of being notified if the data receiver becomes
unreachable. This enables one to build high system robustness
into unreliable data transfer applications.
3) With U-SCTP streams an application can control its lost data
retransmission policies so as to only perform a certain times of
retransmission to a lost datagram.
4) In addition to providing unordered unreliable data transfer as
UDP does, U-SCTP can provides _ordered_ unreliable data
transfer service.
5) U-SCTP employs the same congestion control and congestion
avoidance over unreliable data traffic as it does to the normal
reliable traffic - this is very desirable since it is much
friendlier towards the network than UDP is.
6) 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.
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 [RFC2119].
Xie, et al [Page 2]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
3. Unreliable Data Design
With the unreliable data 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 (or only be
retransmitted for a limited times) if they are found missing at the
data receiver.
3.1 Unreliable Streams Parameter For INIT and INIT ACK
The following new optional parameter is added to the INIT and INIT ACK
chunks.
Parameter Name Status Type Value
-------------------------------------------------------------
Unreliable Streams Optional 0xC000
At the initialization of the association, the sender of the INIT or
INIT ACK chunk shall include this optional parameter to inform its
peer that it is able to support unreliable streams and to designate
its unreliable outbound streams.
The format of the Unreliable Streams parameter is defined as follows:
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 = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Xie, et al [Page 3]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
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
+------------+-----------+
Example 5: (assuming OS = 10)
+------------+-----------+
|type=0xC000 | length=4 | Streams Mode
+------------+-----------+ ==> ---------------------
0 - 9 reliable
Xie, et al [Page 4]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
If no streams are marked as unreliable but the sender does support the
unreliable streams option, the sender still SHOULD include a parameter
with no u-stream ranges and a fixed Parameter Length of 4.
3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN)
The following chunk type is defined in order to support the SCTP
unreliable stream operation:
Chunk Type Chunk Name
------------------------------------------------------
11000000 Forward Cumulative TSN (FORWARD TSN)
This 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 associated with unreliable data chunks and will
no longer be retransmitted by the sender.
Forward Cumulative TSN chunk has the following format:
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 TSN to the data receiver. Upon
the reception of this value, the data receiver shall consider
any missing TSNs earlier than or equal to this value as received
and stop reporting them as gaps in any subsequent SACKs.
4. Unreliable Data Operation
In this section, we first define 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
Xie, et al [Page 5]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
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 data receiver does not support unreliable inbound
streams, it SHOULD treat the Unreliable Streams parameter as an
invalid or unrecognized parameter and respond to the data sender with
an operational error, following the rules defined in Section 5.1
of [RFC2960].
Upon reception of the operational error indicating that its peer does
not support unreliable streams, the data sender may choose to either:
1) end the initiation process, in consideration of the peer's
inability of meeting the requested features for the new
association, or
2) continue the initiation process, but with the understanding that
ALL its outbound streams will be reliable.
In either case, the data sender SHOULD inform its upper layer its
peer's inability of supporting unreliable data transfer.
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 [RFC2960]) should be expanded to 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 will be treated as unreliable user data and will
automatically be transmitted in unreliable mode.
The data sender shall fragment an unreliable user message if its size
is larger than the current PMTU. The sender shall follow the
fragmentation rules and procedures as defined in [RFC2960].
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:
A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer
to track a theoretical cumulative TSN point of the peer (Note,
this is a new protocol variable and its value is NOT necessarily
the same as the classic SCTP Cumulative TSN Ack Point as defined
in [RFC2960]).
A2) Before retransmitting a DATA chunk (due to either a T3-rtx timer
Xie, et al [Page 6]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
expiration as defined in 6.3.3 of [RFC2960] or a 4th missing
indication as defined in 7.2.4 of [RFC2960]), the SCTP data
sender MUST check whether the DATA chunk is being transmitted on
an unreliable stream. If so, it will perform the following:
B1) Check the value of the unreliable retransmission counter
"Unrel.Trans.Count" value for the DATA chunk. This value may
be set by the SCTP user to 0 (no retransmission) for complete
unreliability, or N (where N >0) for limited reliability at
the time when the user message is passed to SCTP.
B2) If the "Unrel.Trans.Count" of the chunk is currently greater
than 0, the sender MUST retransmit the data chunk and then
decrease the "Unrel.Trans.Count" by 1. The same rules for
retransmission as defined in [RFC2960] SHALL be used for RTO
calculation, destination selection, error reporting, etc.
B3) If the "Unrel.Trans.Count" is currently 0, the sender MUST NOT
retransmit the data chunk. Instead, the sender MUST mark the
data chunk as being finally acked.
A3) whenever the data sender receives a SACK from the data receiver,
it SHALL first process the SACK using the normal procedures as
defined in Section 6.2.1 of [RFC2960].
The data sender MUST then perform the following additional
steps:
C1) Update the "Advanced.Peer.Ack.Point" to the Cumulative TSN
ACK carried in the SACK __if__ the former is behind.
C2) Try to further advance the "Advanced.Peer.Ack.Point" locally,
that is, to move "Advanced.Peer.Ack.Point" up as long as the
chunk next in the out-queue is marked as acknowledged. For
example (assuming that a SACK arrived with the Cumulative TSN
ACK = 102 and the Advanced.Peer.Ack.Point is updated to this
value),
out-queue at the end of ==> out-queue after Adv.Ack.Point
normal SACK processing local advancement
... ...
Adv.Ack.Pt-> 102 acked 102 acked
103 acked 103 acked
104 acked Adv.Ack.P-> 104 acked
105 105
106 acked 106 acked
... ...
In this example, the data sender successfully advanced the
"Advanced.Peer.Ack.Point" from 102 to 104 locally.
C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point"
becomes more advanced than the Cumulative TSN ACK carried in
Xie, et al [Page 7]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
the received SACK, the data sender MUST send the data
receiver a FORWARD TSN chunk containing the latest value of
the "Advanced.Peer.Ack.Point".
Note, an endpoint MUST NOT use the FORWARD TSN for any
purposes other than the above circumstance.
Note, if a TSN is indicated as missing by a SACK carrying gap
reports AND the TSN is earlier than the current
"Advanced.Peer.Ack.Point", the data sender MUST NOT take any
action on this TSN, i.e., it MUST ignore this missing report to
this TSN. When this happens, it is normally an indication that a
previous FORWARD TSN from the data sender may have been lost in
the network.
Note, the detection criterion for out-of-order SACKs MUST remains
the same as stated in RFC2960, that is, a SACK is only considered
out-of-order if the Cumulative TSN ACK carried in the SACK is
earlier than that of the previous received SACK (i.e., the
comparison MUST NOT be made against "Advanced.Peer.Ack.Point").
The ULP primitive "DATA" (defined in Section 10.1 of [RFC2960]) should
be expanded to contain an optional unreliable retransmission parameter
to assign a "Unrel.Trans.Count" value to each user message to be sent
to an unreliable stream.
4.3 Receive Unreliable Data
Regardless whether a DATA chunk arrives from 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 [RFC2960].
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 missing TSNs earlier than or equal
to the new cumulative TSN.
Whenever an unreliable DATA chunk arrives with the 'U' bit set to '0'
(indicating ordered delivery) and is out of order, the receiver must
hold the chunk for reordering. However since it is possible that the
DATA chunk(s) being waited upon is one that will not be retransmitted
by the sender, when a FORWARD TSN chunk arrives, the receiver MUST
examine all of its unreliable stream reordering queues, and
immediately make available for delivery any messages that carry a TSN
(or a starting TSN in the case of reassembled messages) earlier than
the new cumulative TSN updated by the FORWARD TSN.
When receiving a FORWARD TSN, cautions MUST also be taken in updating
the re-assembly queue of the receiver, including the removal of any
partially reassembled message which is still missing one or more TSNs
earlier than or equal to the new cumulative TSN updated by the FORWARD
TSN.
Xie, et al [Page 8]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
4.4. Other Issues on Unreliable Data
4.4.1 Unreliable Data Stream Multiplexing
Sometimes, it is desirable to aggregate different media 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 letting the SCTP's
built-in data bundling mechanism to perform the multiplexing at the
sender and demultiplexing at the receiver.
4.4.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 [RFC2960] for reliable data
transfer.
4.4.3 Detection of Missing Unreliable Data
Detecting missing 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 stream
sequence number of the arrived user messages of that stream to detect
any missing data. Note, this detection only works when all the
messages in that stream are sent in order, i.e. their "U" bit MUST NOT
be set.
5. Acknowledgments
The authors would like to thank Scott Bradner, Jon Berger, John
Loughney, Ivan Arias Rodriguez, and others for their comments.
6. Authors' Addresses
Qiaobing Xie Tel: +1-847-632-3028
Motorola, Inc. EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309
Xie, et al [Page 9]
Internet Draft SCTP Unreliable Data Mode Extension April 2001
Arlington Heights, IL 60004
USA
Randall R. Stewart Tel: +1-815-477-2127
Cisco Systems, Inc. EMail: rrs@cisco.com
8725 West Higgins Road
Suite 300
Chicago, Ill 60631
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
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2960] 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," RFC2960, October 2000.
This Internet Draft expires in 6 months from April 2001.
Xie, et al [Page 10]
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/