draft-ietf-sigtran-usctp-00.txt   draft-ietf-sigtran-usctp-01.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
INTERNET-DRAFT Motorola INTERNET-DRAFT Motorola
R. R. Stewart R. R. Stewart
C. Sharp C. Sharp
Cisco Cisco
I. Rytina I. Rytina
Ericsson Ericsson
Expires in six months January 2001 Expires in six months February 2001
SCTP Unreliable Data Mode Extension SCTP Unreliable Data Mode Extension
<draft-ietf-sigtran-usctp-00.txt> <draft-ietf-sigtran-usctp-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 1, line 38 skipping to change at page 1, line 39
Abstract Abstract
This document describes an extension to the Stream Control This document describes an extension to the Stream Control
Transmission Protocol (SCTP) [RFC2960] to provide unreliable data Transmission Protocol (SCTP) [RFC2960] to provide unreliable data
transfer services. The benefits of this extension includes unified transfer services. The benefits of this extension includes unified
congestion control over reliable and unreliable data streams, single congestion control over reliable and unreliable data streams, single
association for multi-content data services, link level association for multi-content data services, link level
fault tolerance for unreliable data transfer, unreliable data stream fault tolerance for unreliable data transfer, unreliable data stream
multiplexing, etc. multiplexing, etc.
The unreliable data transfer service will also support partial payload The data transfer service extension will also support partial payload
checksum in order to facilitate bit-error tolerance media checksum in order to facilitate bit-error tolerance media
applications. applications.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction................................................. 2 1. Introduction................................................. 2
2. Conventions.................................................. 3 2. Conventions.................................................. 3
3. Unreliable Data Extension Design............................. 3 3. Unreliable Data and Partial Checksum Design.................. 3
3.1 New INIT and INIT-ACK parameters.......................... 3 3.1 New INIT and INIT-ACK parameters.......................... 3
3.1.1 Unreliable Streams Parameter Definition............... 3 3.1.1 Unreliable Streams Parameter Definition............... 3
3.1.2 Partial Checksum Parameter Definition................ 5 3.1.2 Partial Checksum Parameter Definition................. 5
3.2 New chunk definitions..................................... 5 3.2 New chunk definitions..................................... 5
3.2.1 Forward Cumulative TSN Chunk (FORWARD TSN)............ 5 3.2.1 Forward Cumulative TSN Chunk (FORWARD TSN)............ 5
3.2.2 Partial Checksum Data Chunk (P-DATA).................. 6 3.2.2 Partial Checksum Data Chunk (P-DATA).................. 6
4. Unreliable Stream Operations................................. 8 4. Unreliable Stream Operations................................. 8
4.1 Initialization of Unreliable Streams...................... 8 4.1 Initialization of Unreliable Streams...................... 8
4.2 Send Unreliable Data...................................... 9 4.2 Send Unreliable Data...................................... 9
4.3 Receive Unreliable Data...................................10 4.3 Receive Unreliable Data...................................11
4.4 Usage of the P-DATA chunk.................................10 4.4 Other Issues on Unreliable Data...........................11
4.4.1 Unreliable Data Stream Multiplexing...................11
Internet draft SCTP Unreliable Data Mode Extension January 2001 4.4.2 Fault Tolerant Unreliable Data Transfer...............12
4.4.3 Unreliable Data Out-of-order Detection................12
5. Other Issues.................................................11 5. Usage of the P-DATA chunk....................................12
5.1 Unreliable Data Stream Multiplexing.......................11 6. Acknowledgments..............................................13
5.2 Fault Tolerant Unreliable Data Transfer...................11 7. Authors' Addresses...........................................13
5.3 Unreliable Data Out-of-order Detection....................11 8. References...................................................14
6. Acknowledgments..............................................12
7. Authors' Addresses...........................................12
8. References...................................................12
1. Introduction 1. Introduction
Taking advantage of the extensibility of SCTP, this document adds Taking advantage of the extensibility of SCTP, this document adds
unreliable data transfer services to SCTP and an optional method to unreliable data transfer services to SCTP and an optional method to
send SCTP Data Chunks with limited checksum coverage. The design send SCTP Data Chunks with limited checksum coverage. The design
presented here allows the co-existence of unreliable data streams presented here allows the co-existence of unreliable data streams
and reliable streams in a single SCTP association. and reliable streams in a single SCTP association.
The following are some advantages for integrating unreliable data The following are some of the advantages for integrating unreliable
services into SCTP: and partial checksum data services into SCTP:
1) Unreliable extension to SCTP (U-SCTP) supports congestion 1) Unreliable extension to SCTP (U-SCTP) supports congestion
control and congestion avoidance over unreliable data traffic; control and congestion avoidance over unreliable data traffic;
this is very desirable since it is much friendlier towards the this is very desirable since it is much friendlier towards the
network than UDP. network than UDP.
2) Some applications services can greatly benefit from U-SCTP by 2) Some applications services can greatly benefit from U-SCTP by
using a single SCTP association to carry both reliable content using a single SCTP association to carry both reliable content
(e.g., text, billing, accounting, set-up information, etc.) and (e.g., text, billing, accounting, set-up information, etc.) and
unreliable content (e.g., Fiber channel, SCSI over IP, etc.). unreliable content (e.g., Fiber channel, SCSI over IP, etc.).
skipping to change at page 3, line 5 skipping to change at page 3, line 9
6) U-SCTP can achieve either ordered or unordered unreliable data 6) U-SCTP can achieve either ordered or unordered unreliable data
transfer, while UDP is incapable of controlling the order of data transfer, while UDP is incapable of controlling the order of data
delivery. delivery.
7) An application can control its retransmission policies if 7) An application can control its retransmission policies if
retransmission is deemed needed. retransmission is deemed needed.
8) Some applications may find it desirable to limit the coverage 8) Some applications may find it desirable to limit the coverage
of the Adler32 checksum over the actual data chunks. of the Adler32 checksum over the actual data chunks.
Internet draft SCTP Unreliable Data Mode Extension January 2001
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they
appear in this document, are to be interpreted as described in appear in this document, are to be interpreted as described in
RFC 2119 [RFC2119]. RFC 2119 [RFC2119].
3. Unreliable Data Extension Design 3. Unreliable Data and Partial Checksum Design
With the present extension, an SCTP data sender will be allowed to With the unreliable data extension, an SCTP data sender will be allowed to
designate a sub-set of its outbound streams to be unreliable designate a sub-set of its outbound streams to be unreliable
streams. The user data chunks sent to an unreliable stream will share streams. The user data chunks sent to an unreliable stream will share
the same TSN space, the same congestion control/avoidance treatment, the same TSN space, the same congestion control/avoidance treatment,
and the same transmission priority as those sent to a reliable stream, 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 but they will not be retransmitted (or only be retransmitted for a
data receiver. limited times) if they are found missing at the data receiver.
The partial checksum extension allows the sending application to
specify a portion of an outbound user message to be excluded from SCTP
checksum protection.
3.1 New INIT and INIT-ACK parameters 3.1 New INIT and INIT-ACK parameters
The following new optional parameter, are added to the INIT The following new optional parameter, are added to the INIT
and INIT ACK chunks. At the initialization of the association, the and INIT ACK chunks. At the initialization of the association, the
sender of the INIT or INIT ACK chunk may include these parameters sender of the INIT or INIT ACK chunk may include these parameters
to indicate its ability to support these features. to indicate its ability to support these features.
Parameter Name Status Type Value Parameter Name Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
Unreliable Streams Optional 0xC000 Unreliable Streams Optional 0xC000
Partial Checksum support Optional 0xC004 Partial Checksum Support Optional 0xC004
3.1.1 Unreliable Streams Parameter Definition 3.1.1 Unreliable Streams Parameter Definition
The Unreliable Streams parameter is added to the INIT and INIT ACK The Unreliable Streams parameter is added to the INIT and INIT ACK
chunks. At the initialization of the association, the sender of the chunks. At the initialization of the association, the sender of the
INIT or INIT ACK chunk shall include this optional parameter INIT or INIT ACK chunk shall include this optional parameter
to inform its peer that it is able to support unreliable streams to inform its peer that it is able to support unreliable streams
and to designate its unreliable outbound streams. If no streams and to designate its unreliable outbound streams. If no streams
are marked as unreliable but the sender does support the are marked as unreliable but the sender does support the
unreliable streams option the sender SHOULD include a parameter unreliable streams option the sender SHOULD include a parameter
skipping to change at page 4, line 5 skipping to change at page 4, line 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
\ . . . . \ \ . . . . \
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| u-stream start #k = USk | u-stream end #k = UEk | | u-stream start #k = USk | u-stream end #k = UEk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bit u_int Type: 16 bit u_int
Internet draft SCTP Unreliable Data Mode Extension January 2001
0xC000, indicating Unreliable Streams parameter 0xC000, indicating Unreliable Streams parameter
Length: 16 bit u_int Length: 16 bit u_int
Indicate the size of the parameter in octets, including the Indicate the size of the parameter in octets, including the
Type, Length, u-stream start, and u-stream end fields. Type, Length, u-stream start, and u-stream end fields.
u-stream start: 16 bit u_int, and u-stream start: 16 bit u_int, and
u-stream end: 16 bit u_int u-stream end: 16 bit u_int
skipping to change at page 5, line 4 skipping to change at page 5, line 17
| u-start= 9 | u-end= 9 | 0 unreliable | u-start= 9 | u-end= 9 | 0 unreliable
+------------+-----------+ 1 - 8 reliable +------------+-----------+ 1 - 8 reliable
| u-start= 0 | u-end= 0 | 9 unreliable | u-start= 0 | u-end= 0 | 9 unreliable
+------------+-----------+ +------------+-----------+
Example 4: (assuming OS = 10) Example 4: (assuming OS = 10)
+------------+-----------+ +------------+-----------+
|type=0xC000 | length=8 | Streams Mode |type=0xC000 | length=8 | Streams Mode
+------------+-----------+ ==> --------------------- +------------+-----------+ ==> ---------------------
Internet draft SCTP Unreliable Data Mode Extension January 2001
| u-start= 0 | u-end= 9 | 0 - 9 unreliable | u-start= 0 | u-end= 9 | 0 - 9 unreliable
+------------+-----------+ +------------+-----------+
Example 5: (assuming OS = 10) Example 5: (assuming OS = 10)
+------------+-----------+ +------------+-----------+
|type=0xC000 | length=4 | Streams Mode |type=0xC000 | length=4 | Streams Mode
+------------+-----------+ ==> --------------------- +------------+-----------+ ==> ---------------------
0 - 9 reliable 0 - 9 reliable
3.1.2 Partial Checksum Parameter Definition 3.1.2 Partial Checksum Parameter Definition
skipping to change at page 5, line 31 skipping to change at page 5, line 41
to inform its peer that it is able to support the partial checksum to inform its peer that it is able to support the partial checksum
P-DATA (Chunk Type = 0xC3 or 195), see section 3.2.2. P-DATA (Chunk Type = 0xC3 or 195), see section 3.2.2.
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 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 = 0xc004 | Parameter Length=4 | | Parameter Type = 0xc004 | Parameter Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2 New chunk definitions 3.2 New chunk definitions
The following new control chunks, are added to support two The following new chunk types are added to support the two new
new features in SCTP. The FORWARD TSN supports the unreliable features in SCTP.
stream. The Partial Checksum Data Chunk will support Data chunks
that are not completely covered by the Adler32 checksum in the SCTP
packet header.
Chunk Type Chunk Name Chunk Type Chunk Name
------------------------------------------------------ ------------------------------------------------------
11000000 Forward Cumulative TSN (FORWARD TSN) 11000000 Forward Cumulative TSN (FORWARD TSN)
11000011 Partial Checksum Data Chunk (P-DATA) 11000011 Partial Checksum Data Chunk (P-DATA)
The FORWARD TSN supports the unreliable stream. The Partial Checksum
Data Chunk supports data chunks that are not completely covered by the
Adler32 checksum in the SCTP packet header.
3.2.1 Forward Cumulative TSN Chunk Definition (FORWARD TSN) 3.2.1 Forward Cumulative TSN Chunk Definition (FORWARD TSN)
This new chunk type 'Forward Cumulative TSN chunk' shall be used by Forward Cumulative TSN chunk shall be used by the data sender to
the data sender to inform the data receiver to adjust its cumulative inform the data receiver to adjust its cumulative received TSN point
received TSN point forward because some missing TSNs are unreliable forward because some missing TSNs are associated with unreliable data
data chunks and are hence omitted from retransmission. chunks and will no longer be retransmitted by the sender.
0 1 2 3 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 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| |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 | | New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags: Chunk Flags:
Set to all zeros on transmit and ignored on receipt. Set to all zeros on transmit and ignored on receipt.
New Cumulative TSN: 32 bit u_int New Cumulative TSN: 32 bit u_int
This indicates the new cumulative received TSN to the data receiver. This indicates the new cumulative TSN to the data receiver.
Upon the reception of this value, the data receiver shall consider Upon the reception of this value, the data receiver shall consider
Internet draft SCTP Unreliable Data Mode Extension January 2001
any missing TSNs earlier than this value received and stop reporting any missing TSNs earlier than this value received and stop reporting
them as gaps in the subsequent SACKs. them as gaps in the subsequent SACKs.
3.2.2 Partial Checksum Data Chunk (P-DATA) 3.2.2 Partial Checksum Data Chunk (P-DATA)
Note, fragmentation MUST NOT be performed on an unreliable user
message. In other words, an unreliable user message MUST be sent in a
single chunk regardless of its size.
The following format MUST be used for the P-DATA chunk: The following format MUST be used for the P-DATA chunk:
0 1 2 3 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 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 1 1| Reserved|U|B|E| Length | |1 1 0 0 0 0 1 1| Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN | | TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n | | Stream Identifier S | Stream Sequence Number n |
skipping to change at page 6, line 37 skipping to change at page 6, line 52
| Payload Protocol Identifier | | Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum Coverage | | Checksum Coverage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ User Data (seq n of Stream S) / / User Data (seq n of Stream S) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5 bits Reserved: 5 bits
Should be set to all '0's and ignored by the receiver. Should be set to all '0's and ignored by the receiver.
U bit: 1 bit U bit: 1 bit
Same as in DATA [RFC2960], the (U)nordered bit, if set to '1', Same as in a DATA chunk [RFC2960], the (U)nordered bit, if set to '1',
indicates that this is an unordered P-DATA chunk, and there is no indicates that this is an unordered P-DATA chunk, and there is no
Stream Sequence Number assigned to this P-DATA chunk. Therefore, the Stream Sequence Number assigned to this P-DATA chunk. Therefore, the
receiver MUST ignore the Stream Sequence Number field. receiver MUST ignore the Stream Sequence Number field.
Unordered P-DATA chunks MUST be dispatched to the upper layer by the Unordered P-DATA chunks MUST be dispatched to the upper layer by the
receiver without any attempt to re-order them. receiver without any attempt to re-order them.
B bit: 1 bit B bit: 1 bit
MUST be set to 1 by the sender. MUST be set to 1 by the sender.
E bit: 1 bit E bit: 1 bit
MUST be set to 1 by the sender.
Internet draft SCTP Unreliable Data Mode Extension January 2001 MUST be set to 1 by the sender.
Length: 16 bits (unsigned integer) Length: 16 bits (unsigned integer)
This field indicates the length of the P-DATA chunk in bytes from the This field indicates the length of the P-DATA chunk in bytes from the
beginning of the type field to the end of the user data field beginning of the type field to the end of the user data field
excluding any padding. A P-DATA chunk with no user data field will excluding any padding. For example, a P-DATA chunk with 5 bytes of
have Length set to 20 (indicating 20 bytes). user data field will have Length set to 25 (indicating 25 bytes).
TSN: 32 bits (unsigned integer) TSN: 32 bits (unsigned integer)
This value represents the TSN for this P-DATA chunk. The valid range This value represents the TSN for this P-DATA chunk. The valid range
of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0
after reaching 4294967295. after reaching 4294967295.
Stream Identifier S: 16 bits (unsigned integer) Stream Identifier S: 16 bits (unsigned integer)
Identifies the stream to which the following the user data belongs. Identifies the stream to which the following the user data belongs.
Stream Sequence Number n: 16 bits (unsigned integer) Stream Sequence Number n: 16 bits (unsigned integer)
This value represents the stream sequence number of the following This value represents the stream sequence number of the following
user data within the stream S. Valid range is 0 to 65535. user data within the stream S. Valid range is 0 to 65535.
Payload Protocol Identifier: 32 bits (unsigned integer) Payload Protocol Identifier: 32 bits (unsigned integer)
Same as in DATA [RFC2960], this value represents an application (or Same as in a DATA chunk [RFC2960], this value represents an
upper layer) specified protocol identifier. This value is passed to application (or upper layer) specified protocol identifier. This
SCTP by its upper layer and sent to its peer. This identifier is value is passed to SCTP by its upper layer and sent to its peer.
not used by SCTP but can be used by certain network entities as well This identifier is not used by SCTP but can be used by certain
as the peer application to identify the type of information being network entities as well as the peer application to identify the
carried in this P-DATA chunk. type of information being carried in this P-DATA chunk.
The value 0 indicates no application identifier is specified by The value 0 indicates no application identifier is specified by
the upper layer for this payload data. the upper layer for this payload data.
Internet draft SCTP Unreliable Data Mode Extension January 2001 Checksum Coverage: 32 bits (unsigned integer)
Checksum Coverage: 16 bits (unsigned integer)
This field contains an integer that indicates how much User Data (in This field contains an integer that indicates how much User Data (in
octets) of this P-DATA chunk is covered by the Adler32 checksum in octets) of this P-DATA chunk is covered by the Adler32 checksum in
the SCTP packet common header. the SCTP packet common header.
(Note, all chunk headers, as well as the common header of the SCTP Note, all chunk headers, as well as the common header of the SCTP
packet are always covered by the packet checksum, regardless of the packet are always covered by the packet checksum, regardless of
value of the Checksum Coverage.) the value of the Checksum Coverage.
The coverage area is defined as starting from the first transmitted The coverage area is defined as starting from the first transmitted
byte in the User Data part of the Chunk for exactly byte in the User Data part of the Chunk for exactly
'Checksum Coverage' bytes in length. 'Checksum Coverage' bytes in length.
For example, if a value of "5" appears in the Checksum Coverage For example, if a value of "5" appears in the Checksum Coverage
field, only the first 5 bytes of the User Data are included in the field, only the first 5 bytes of the User Data are included in the
calculation of the packet checksum. A value of "0" in the Checksum calculation of the packet checksum. A value of "0" in the Checksum
Coverage field will indicate that all the User Data in this P-DATA Coverage field will indicate that all the User Data in this P-DATA
chunk is excluded from the packet checksum. chunk is excluded from the packet checksum.
The value of Checksum Coverage MUST NOT be larger than the length of The sender of a P-DATA chunk SHOULD NOT set a value of Checksum
the User Data, i.e., it MUST be smaller than or equal to Length - 20. Coverage larger than the length of the User Data in the chunk. In
other words, the Checksum Coverage SHOULD be set smaller than or
equal to the chunk Length - 20.
On the receiver side, if the value of Checksum Coverage in a
received P-DATA chunk is found larger than the length of the User
Data in the chunk, the receiver MUST accept the chunk and MUST
consider the entire User Data in the chunk covered by the Adler-32
checksum.
User Data: variable length User Data: variable length
This is the payload user data. The implementation MUST pad the end This is the payload user data. The implementation MUST pad the end
of the data to a 4 byte boundary with all-zero bytes. Any padding of the data to a 4 byte boundary with all-zero bytes. Any padding
MUST NOT be included in the Length field. A sender MUST never add MUST NOT be included in the Length field. A sender MUST never add
more than 3 bytes of padding. more than 3 bytes of padding.
4. Unreliable Stream Operations 4. Unreliable Stream Operations
skipping to change at page 8, line 59 skipping to change at page 9, line 8
streams. streams.
Upon the reception of the Unreliable Streams parameter, the data Upon the reception of the Unreliable Streams parameter, the data
receiver SHALL determine and record the mode (reliable or unreliable) receiver SHALL determine and record the mode (reliable or unreliable)
of each inbound stream, as it allocates resource for its inbound of each inbound stream, as it allocates resource for its inbound
streams. streams.
Note, if the data receiver does not support unreliable inbound Note, if the data receiver does not support unreliable inbound
streams, it SHOULD treat the Unreliable Streams parameter as an streams, it SHOULD treat the Unreliable Streams parameter as an
invalid or unrecognized parameter and respond to the data sender with invalid or unrecognized parameter and respond to the data sender with
an operational error, following the rules defined in Section 5.1 of an operational error, following the rules defined in Section 5.1
[RFC2960]. of [RFC2960].
Upon reception of the operational error indicating that its peer does Upon reception of the operational error indicating that its peer does
not support unreliable streams, the data sender may choose to either: not support unreliable streams, the data sender may choose to either:
1) end the initiation process, in consideration of the peer's 1) end the initiation process, in consideration of the peer's
inability of meeting the requested features for the new inability of meeting the requested features for the new
association, or association, or
2) continue the initiation process, but with the understanding that 2) continue the initiation process, but with the understanding that
ALL its outbound streams will be reliable. ALL its outbound streams will be reliable.
In either case, the data sender SHOULD inform its upper layer its In either case, the data sender SHOULD inform its upper layer its
peer's inability of supporting unreliable data transfer. peer's inability of supporting unreliable data transfer.
Internet draft SCTP Unreliable Data Mode Extension January 2001
Initiation of streams as reliable and/or unreliable may be under the Initiation of streams as reliable and/or unreliable may be under the
control of the SCTP user. Hence, the ULP primitive "ASSOCIATE" (see control of the SCTP user. Hence, the ULP primitive "ASSOCIATE" (see
Section 10.1 of [RFC2960]) should contain the optional U-stream-start Section 10.1 of [RFC2960]) should be expanded to contain the optional
and U-stream-end values. U-stream-start and U-stream-end values.
4.2 Send Unreliable Data 4.2 Send Unreliable Data
During the lifetime of the association, any user data sent to an During the lifetime of the association, any user data sent to an
unreliable stream will be treated as unreliable user data and will unreliable stream will be treated as unreliable user data and will
automatically be transmitted in unreliable mode. automatically be transmitted in unreliable mode.
Note, fragmentation MUST NOT be performed on an unreliable user
message. In other words, an unreliable user message MUST be sent in a
single DATA or P-DATA chunk regardless of its size.
The SCTP data sender shall handle user data sent to an unreliable 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 stream the same way as it handles user data sent to a reliable stream
(i.e., the same timer rules, congestion control rules, failure (i.e., the same timer rules, congestion control rules, failure
detection rules, RTO control rules, etc.), with the following detection rules, RTO control rules, etc.), with the following
exceptions: exceptions:
A1) The sender maintains a "Peer.Cumulative.TSN" for each peer so as A1) The sender maintains a "Peer.Cumulative.TSN" for each peer so as
to track the latest cumulative TSN point of the peer (Note, this to track the latest cumulative TSN point of the peer (Note, this
variable may already exist in a classic SCTP implementation for variable may already exist in a classic SCTP implementation for
outqueue management and for detecting out-of-order SACKs). outqueue management and for detecting out-of-order SACKs).
A2) Before retransmitting a DATA chunk (due to either a T3-rtx timer A2) Before retransmitting a DATA chunk (due to either a T3-rtx timer
expiration as defined in 6.3.3 of [RFC2960] or a 4th missing 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 indication as defined in 7.2.4 of [RFC2960]), the SCTP data
sender MUST check whether the DATA chunk is being transmitted on sender MUST check whether the DATA chunk is being transmitted on
an unreliable stream. If so, it will perform the following: an unreliable stream. If so, it will perform the following:
B1) Check the value of the unreliable retransmission counter B1) Check the value of the unreliable retransmission counter
"Unrel.Trans.Count" value for the DATA chunk. This value may "Unrel.Trans.Count" value for the DATA chunk. This value may
be set by the SCTP user to 0 (no retransmission) for complete be set by the SCTP user to 0 (no retransmission) for complete
unreliability, or N (where N >0) for limited reliability, at unreliability, or N (where N >0) for limited reliability at
the time when the user message is passed to SCTP. the time when the user message is passed to SCTP.
B2) If the "Unrel.Trans.Count" of the chunk is currently greater B2) If the "Unrel.Trans.Count" of the chunk is currently greater
than 0, the sender MUST retransmit the data chunk and then than 0, the sender MUST retransmit the data chunk and then
decrease the "Unrel.Trans.Count" by 1. The same rules for decrease the "Unrel.Trans.Count" by 1. The same rules for
retransmission as defined in [RFC2960] SHALL be used for RTO retransmission as defined in [RFC2960] SHALL be used for RTO
calculation, destination selection, error reporting, etc. calculation, destination selection, error reporting, etc.
B3) If "Unrel.Trans.Count" is currently 0, the sender MUST NOT B3) If the "Unrel.Trans.Count" is currently 0, the sender MUST NOT
retransmit the data chunk. Instead, the sender MUST mark the retransmit the data chunk. Instead, the sender MUST mark the
data chunk as being finally acked. data chunk as being finally acked.
A3) whenever the data sender receives a SACK from the data receiver, A3) whenever the data sender receives a SACK from the data receiver,
it SHALL first process the SACK using the normal procedures as it SHALL first process the SACK using the normal procedures as
defined in [RFC2960] for classic SCTP, this includes the adoption defined in [RFC2960] for classic SCTP. This includes, among other
of the Cumulative TSN ACK carried in the SACK as the new things: a) check if the SACK is received out-of-order; if not, b)
"Peer.Cumulative.TSN" if the SACK is found not out-of-order and adopt the Cumulative TSN ACK carried in the SACK as the new
processing any gap reports if present (see [RFC2960]). "Peer.Cumulative.TSN"; and c) process any gap reports if present
(see [RFC2960]).
The data sender MUST then perform the following additional The data sender MUST then perform the following additional
steps: steps:
C1) Try to further advance the "Peer.Cumulative.TSN" locally, C1) Try to further advance the "Peer.Cumulative.TSN" locally,
that is, to move "Peer.Cumulative.TSN" up as long as the that is, to move "Peer.Cumulative.TSN" up as long as the
chunk next in the out-queue is marked as acknowledged. For chunk next in the out-queue is marked as acknowledged. For
example (assuming a SACK arrived with Cumulative TSN example (assuming a SACK arrived with the Cumulative TSN
ACK=102), ACK=102),
out-queue status after ==> out-queue after cmTSN out-queue at the end of ==> out-queue after cmTSN
normal SACK processing local advancement normal SACK processing local advancement
... ... ... ...
cmTSN -> 102 acked 102 acked cmTSN -> 102 acked 102 acked
103 acked 103 acked 103 acked 103 acked
104 acked cmTSN -> 104 acked 104 acked cmTSN -> 104 acked
105 105 105 105
106 acked 106 acked 106 acked 106 acked
... ... ... ...
Here, the data sender successfully advanced the Here, the data sender successfully advanced the
"Peer.Cumulative.TSN" from 102 to 104 locally. "Peer.Cumulative.TSN" from 102 to 104 locally.
C2) Whenever a local advancement of the "Peer.Cumulative.TSN" has C2) Whenever a local advancement of the "Peer.Cumulative.TSN" is
been made, the data sender MUST send the data receiver a made, the data sender MUST send the data receiver a
FORWARD TSN chunk containing the new value of the FORWARD TSN chunk containing the new value of the
"Peer.Cumulative.TSN". "Peer.Cumulative.TSN" (which is 104 in the above example).
Note, an endpoint MUST NOT use the forward TSN for any other Note, an endpoint MUST NOT use the forward TSN for any other
purposes other than the above circumstance. purposes other than the above circumstance.
Note, if a TSN is indicated as missing by a SACK carrying gap Note, if a TSN is indicated as missing by a SACK carrying gap
reports AND the TSN is earlier than the current reports AND the TSN is earlier than the current
"Peer.Cumulative.TSN", the data sender MUST NOT take any action "Peer.Cumulative.TSN", the data sender MUST NOT take any action
on this TSN, i.e., it MUST ignore this missing report to this on this TSN, i.e., it MUST ignore this missing report to this
TSN. TSN. When this happens, it is normally an indication that a
previous FORWARD TSN from the data sender may have been lost in
(When this happens, it is an indication that a previous FORWARD the network.
TSN from the data sender may be lost in the network.)
A4) The data sender MUST NOT fragment a user message sent to an
unreliable outbound stream. Instead, it MUST put the entire user
message in a single DATA or P-DATA chunk for transmission.
Internet draft SCTP Unreliable Data Mode Extension January 2001 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 the locally advanced
"Peer.Cumulative.TSN").
The ULP primitive "DATA" (defined in Section 10.1 of [RFC2960]) should The ULP primitive "DATA" (defined in Section 10.1 of [RFC2960]) should
be expanded to contain an optional unreliable retransmission parameter be expanded to contain an optional unreliable retransmission parameter
to assign a "Unrel.Trans.Count" value to each user message to be sent to assign a "Unrel.Trans.Count" value to each user message to be sent
to an unreliable stream. to an unreliable stream.
4.3 Receive Unreliable Data 4.3 Receive Unreliable Data
Regardless whether a DATA chunk arrives from a reliable stream or an Regardless whether a DATA chunk arrives from a reliable stream or an
unreliable stream, the receiver MUST perform the same TSN handling unreliable stream, the receiver MUST perform the same TSN handling
(e.g, duplicate detection, gap detection, SACK generation, cumulative (e.g, duplicate detection, gap detection, SACK generation, cumulative
TSN advancement, etc.) as defined in [RFC2960]. TSN advancement, etc.) as defined in [RFC2960].
However, whenever a FORWARD TSN chunk arrives the data receiver MUST However, whenever a FORWARD TSN chunk arrives the data receiver MUST
update its cumulative TSN to the value carried in the FORWARD TSN update its cumulative TSN to the value carried in the FORWARD TSN
chunk, and MUST stop reporting any un-received TSN before the new chunk, and MUST stop reporting any missing TSNs before the new
cumulative TSN as missing. cumulative TSN.
Whenever an unreliable DATA chunk arrives with the 'U' bit set to '0' Whenever an unreliable DATA chunk arrives with the 'U' bit set to '0'
(indicating ordered delivery) and is out of order, the receiver must (indicating ordered delivery) and is out of order, the receiver must
hold the chunk for reordering. However since it is possible that the 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 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 by the sender, when a FORWARD TSN chunk arrives, the receiver MUST
examine all of its unreliable stream reordering queues, and examine all of its unreliable stream reordering queues, and
immediately make available for delivery any chunks that carry a TSN immediately make available for delivery any messages that carry a TSN
earlier than the new cumulative TSN updated by the FORWARD TSN. earlier than the new cumulative TSN updated by the FORWARD TSN.
4.4 Usage of the P-DATA chunk. 4.4. Other Issues on Unreliable Data
For some applications it is beneficial NOT to discard an SCTP
packet due to an error within the User Data portion. For these
types of applications this new optional chunk type is being
added.
All rules defined in [RFC2960] for DATA Chunks MUST be followed for
the P-DATA chunk with the following exceptions:
E1) The Payload Protocol Identifier (PPI) field is limited to
16 bits. If the ULP presents a PPI that is larger
than 16 bits for transmission, the upper 16 bits MUST be
discarded.
E2) When passing a partial checksum user message to SCTP data sender,
the upper layer should indicate how many bytes of the first
portion of the user message need checksum protection. The data
sender will then add 16 to this amount and put the resulting value
into the Checksum Coverage field of the outbound P-DATA chunk.
For a valid P-DATA, the value of Checksum Coverage MUST be greater
or equal to 16 and MUST NOT be larger than the value of the Length
field of the chunk. If the Checksum Coverage value in a received
P-DATA is out of this range, the data receiver MUST silently
discard the chunk.
E3) The Checksum Coverage field defines how much of this P-DATA
chunk the Adler-32 checksum is to cover. During Checksum
computation the sender and receiver MUST use this field
to determine how much of the P-DATA chunk to add to the
Checksum of the SCTP packet. After summing the specified
amount of data to the checksum, the checksum routine MUST
skip to the next chunk (if this is a bundled chunk) and
NOT include the rest of the data in the P-DATA chunk in its
checksum computation.
E4) A sender MUST NOT send a P-DATA chunk unless the 'Partial Checksum
support' parameter was seen in the INIT or INIT-ACK from its peer.
It is important to note that P-DATA chunk uses the SAME TSN values as
the normal DATA Chunk type. The sender and receiver do NOT hold a
Internet draft SCTP Unreliable Data Mode Extension January 2001
separate TSN sequence spaces for DATA and P-DATA. Instead, the two
chunk types use the same TSN sequence space.
In effect the P-DATA chunk is treated in all considerations to be a
DATA chunk, with all of the normal DATA chunk rules for congestion
control effecting this chunk. The only difference in treatment of
P-DATA chunk comes during the calculation and verification of the
Adler32 checksum.
P-DATA chunk MAY be used with either a reliable or un-reliable stream,
no restrictions are placed on its usage except those listed above.
Use of the P-DATA chunk may be under the control of the SCTP user.
Hence, the ULP primitive "DATA" (see section 10.1 of RFC2960) should
contain an optional Checksum Coverage value.
When a reliable user message subscribing for partial checksum
protection is fragmented at the SCTP sender, the sender shall
calculate the Checksum Coverage value for each of the resulting P-DATA
chunks, based upon the user's original coverage requirement.
5. Other Issues
5.1 Unreliable Data Stream Multiplexing 4.4.1 Unreliable Data Stream Multiplexing
Sometimes, it is desirable to aggregate different real time media Sometimes, it is desirable to aggregate different real time media
streams (e.g., RTP streams) and send them over a single communication streams (e.g., RTP streams) and send them over a single communication
connection. And normally, unreliable transport is preferred for these connection, and normally unreliable transport is preferred for these
types of media streams. types of media streams.
With U-SCTP this is easily achieved by assigning each different media With U-SCTP this is easily achieved by assigning each different media
stream to a different unreliable SCTP stream and enabling the SCTP stream to a different unreliable SCTP stream and enabling the SCTP
data bundling to perform the multiplexing. data bundling to perform the multiplexing.
The implementation of the data sender MAY use a bundling timer with a The implementation of the data sender MAY use a bundling timer with a
time interval adjusted to the timing characteristics of the specific time interval adjusted to the timing characteristics of the specific
media type in order to achieve the optimal multiplexing efficiency. media type in order to achieve the optimal multiplexing efficiency.
5.2 Fault Tolerant Unreliable Data Transfer 4.4.2 Fault Tolerant Unreliable Data Transfer
When the data receiver is multi-homed, unreliable data transfer using When the data receiver is multi-homed, unreliable data transfer using
U-SCTP will obtain the same fault tolerance benefit as that of the U-SCTP will obtain the same fault tolerance benefit as that of the
reliable data services across an SCTP association. reliable data services across an SCTP association.
This is because the data sender still follows the same failure This is because the data sender still follows the same failure
detection rules and still counts the omitted retransmission against detection rules and still counts the omitted retransmission against
the association and the destination transport address to which the the association and the destination transport address to which the
unreliable DATA chunk was originally sent. Thus, when failure occurs, unreliable DATA chunk was originally sent. Thus, when failure occurs,
the data sender will detect the failure and shift the unreliable data the data sender will detect the failure and shift the unreliable data
services to an alternate destination address, following the same services to an alternate destination address, following the same
procedures as defined in Section 8 of [RFC2960] for reliable data transfer. procedures as defined in Section 8 of [RFC2960] for reliable data transfer.
5.3 Unreliable Data Out-of-order Detection 4.4.3 Unreliable Data Out-of-order Detection
Detecting out-of-order data in an unreliable stream is useful for some 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 applications (e.g. Fiber channel or SCSI over IP). With U-SCTP this
becomes possible - the upper layer simply needs to examine the the becomes possible - the upper layer simply needs to examine the the
stream sequence number of the delivered data chunks to detect any stream sequence number of the arrived user messages to detect any
missing data or out-of-order data. This detection only works when 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 the DATA chunks are sent in order, i.e. their "U" bit MUST NOT be
set.
Internet draft SCTP Unreliable Data Mode Extension January 2001 5 Usage of the P-DATA chunk.
set. For some applications it is beneficial NOT to discard a data
packet due to bit errors within the User Data portion. For this
type of applications this new optional chunk type is defined.
All rules defined in [RFC2960] for DATA Chunks MUST be followed for
the P-DATA chunk with the following exceptions:
E1) When passing a partial checksum user message to SCTP data sender,
the upper layer should indicate how many bytes of the first
portion of the user message need checksum protection. The data
sender will then put this value into the Checksum Coverage field
of the outbound P-DATA chunk.
E2) The Checksum Coverage field defines how much of this P-DATA
chunk the Adler-32 checksum is to cover. During checksum
computation the sender and receiver MUST use this field
to determine how much of a P-DATA chunk to add to the
Adler-32 checksum of the SCTP packet.
For each P-DATA in a received SCTP packet, after summing the
chunk header bytes and the specified number of User Data bytes to
the checksum, the receiver MUST skip to the next chunk if this
P-DATA is not the last chunk in the SCTP packet and MUST NOT
include the rest of the User Data in the P-DATA chunk in its
checksum computation.
E3) A sender MUST NOT send a P-DATA chunk unless the 'Partial Checksum
Support' parameter was seen in the INIT or INIT-ACK from its peer.
It is important to note that P-DATA chunk uses the SAME TSN values as
the normal DATA Chunk type. The sender and receiver do NOT hold
separate TSN sequence spaces for DATA and P-DATA. Instead, the two
chunk types use a single TSN sequence space.
In effect the P-DATA chunk is treated in all considerations to be a
DATA chunk, with all of the normal DATA chunk rules for congestion
control effecting this chunk. The only difference in treatment of
P-DATA chunk comes during the calculation and verification of the
Adler-32 checksum.
P-DATA chunk MAY be used with either a reliable or un-reliable stream,
no restrictions are placed on its usage except those listed above.
Use of the P-DATA chunk may be under the control of the SCTP user.
Hence, the ULP primitive "DATA" (see section 10.1 of RFC2960) should
be expanded to contain an optional Checksum Coverage value.
When a reliable user message subscribing for partial checksum
protection is fragmented at the SCTP sender, the sender shall
calculate the Checksum Coverage value for each of the resulting P-DATA
chunks, based upon the user's original coverage requirement.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Scott Bradner for his comments. The authors would like to thank Scott Bradner, Jon Berger, and others
for their comments.
7. Authors' Addresses 7. Authors' Addresses
Qiaobing Xie Tel: +1-847-632-3028 Qiaobing Xie Tel: +1-847-632-3028
Motorola, Inc. EMail: qxie1@email.mot.com Motorola, Inc. EMail: qxie1@email.mot.com
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Randall R. Stewart Tel: +1-815-477-2127 Randall R. Stewart Tel: +1-815-477-2127
skipping to change at page 12, line 47 skipping to change at page 14, line 24
Australia Australia
8. References 8. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla,
"Stream Control Transmission Protocol," RFC2960, October 2000. L. Zhang, and, V. Paxson, "Stream Control Transmission
Protocol," RFC2960, October 2000.
This Internet Draft expires in 6 months from January 2001. This Internet Draft expires in 6 months from February 2001.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/