Request for Comments: 3758 M. Ramalho
Category: Standards Track Cisco Systems, Inc.
Q. Xie
Motorola, Inc.
M. Tuexen
Univ. of Applied Sciences Muenster
P. Conrad
University of Delaware
May 2004
Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) that allows an SCTP endpoint to signal to its peer
that it should move the cumulative ack point forward. When both
sides of an SCTP association support this extension, it can be used
by an SCTP implementation to provide partially reliable data
transmission service to an upper layer protocol. This memo describes
the protocol extensions, which consist of a new parameter for INIT
and INIT ACK, and a new FORWARD TSN chunk type, and provides one
example of a partially reliable service that can be provided to the
upper layer via this mechanism.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of Protocol Extensions. . . . . . . . . . . . . 2
1.2. Overview of New Services Provided to the Upper Layer . . 3
1.3. Benefits of PR-SCTP . . . . . . . . . . . . . . . . . . 4
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Changes to support PR-SCTP . . . . . . . . . . . . . 5
3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK. . 5
3.2. Forward Cumulative TSN Chunk Definition (FORWARD TSN). . 5
3.3. Negotiation of Forward-TSN-Supported parameter . . . . . 7
3.3.1. Sending Forward-TSN-Supported param in INIT . . . 7
3.3.2. Receipt of Forward-TSN-Supported parameter in
INIT or INIT-ACK. . . . . . . . . . . . . . . . . 7
3.3.3. Receipt of Op. Error for Forward-TSN-Supported
Param . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Definition of "abandoned" in the context of PR-SCTP. . . 8
3.5. Sender Side Implementation of PR-SCTP. . . . . . . . . . 9
3.6. Receiver Side Implementation of PR-SCTP. . . . . . . . . 12
4. Services provided by PR-SCTP to the upper layer. . . . . . . . 14
4.1. PR-SCTP Service Definition for "timed reliability" . . . 15
4.2. PR-SCTP Association Establishment. . . . . . . . . . . . 16
4.3. Guidelines for defining other PR-SCTP Services . . . . . 17
4.4. Usage Notes. . . . . . . . . . . . . . . . . . . . . . . 19
5. Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
10. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 20
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .
1. Introduction
This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) RFC 2960 [2] that allows an SCTP sender to signal to
its peer that it should no longer expect to receive one or more DATA
chunks.
1.1. Overview of Protocol Extensions
The protocol extension described in this document consists of two new
elements:
1. a single new parameter in the INIT/INIT-ACK exchange that
indicates whether the endpoint supports the extension
2. a single new chunk type, FORWARD TSN, that indicates that the
receiver should move its cumulative ack point forward (possibly
skipping past one or more DATA chunks that may not yet have been
received and/or acknowledged.)
1.2. Overview of New Services Provided to the Upper Layer
When this extension is supported by both sides of an SCTP
association, it can be used to provide partially reliable transport
service over an SCTP association. We define partially reliable
transport service as a service that allows the user to specify, on a
per message basis, the rules governing how persistent the transport
service should be in attempting to send the message to the receiver.
One example of partially reliable service is specified in this
document, namely a "timed reliability" service. This service allows
the service user to indicate a limit on the duration of time that the
sender should try to transmit/retransmit the message (this is a
natural extension of the "lifetime" parameter already in the base
protocol).
In addition to this example, we will also show that defining the
semantics of a particular partially reliable service involves two
elements, namely:
1. how the service user indicates the level of reliability required
for a particular message, and
2. how the sender side implementation uses that reliability level to
determine when to give up on further retransmissions of that
message.
Note that other than the fact that the FORWARD-TSN chunk is required,
neither of these two elements impacts the "on-the-wire" protocol;
only the API and the sender side implementation are affected by the
way in which the service is defined to the upper layer. Therefore,
in principle, it is feasible to implement many varieties of partially
reliable services in a particular SCTP implementation without
changing the on-the-wire protocol. Also, the SCTP receiver does not
necessarily need to know which semantics of partially reliable
service are being used by the sender, since the receiver’s only role
is to correctly interpret FORWARD TSN chunks, thereby skipping past
messages that the sender has decided to no longer transmit (or
retransmit).
Nevertheless, it is recommended that a limited number of standard
definitions of partially reliable services be standardized by the
IETF so that the designers of IETF application layer protocols can
match the requirements of their upper layer protocols to standard
service definitions provided by a particular SCTP implementation.
One such definition, "timed reliability", is included in this
document. Given the extensions proposed in this document, other
definitions may be standardized as the need arises without further
changes to the on-the-wire protocol.
1.3. Benefits of PR-SCTP
Hereafter, we use the notation "Partial Reliable Stream Control
Transmission Protocol (PR-SCTP)" to refer to the SCTP protocol,
extended as defined in this document.
The following are some of the advantages for integrating partially
reliable data service into SCTP, i.e., benefits of PR-SCTP:
1. Some application layer protocols may benefit from being able to
use a single SCTP association to carry both reliable content, --
such as text pages, billing and accounting information, setup
signaling -- and unreliable content, e.g., state that is highly
sensitive to timeliness, where generating a new packet is more
advantageous than transmitting an old one [3].
2. Partially reliable data traffic carried by PR-SCTP will enjoy the
same communication failure detection and protection capabilities
as the normal reliable SCTP data traffic does. This includes the
ability to quickly detect a failed destination address, fail-over
to an alternate destination address, and be notified if the data
receiver becomes unreachable.
3. In addition to providing unordered, unreliable data transfer as
UDP does, PR-SCTP can provide ordered, unreliable data transfer
service.
4. PR-SCTP employs the same congestion control and congestion
avoidance for all data traffic, whether reliable or partially
reliable - this is very desirable since SCTP enforces TCP-
friendliness (unlike UDP.)
5. Because of the chunk bundling function of SCTP, reliable and
unreliable messages can be multiplexed over a single PR-SCTP
association. Therefore, the number of IP datagrams (and hence the
network overhead) can be reduced instead of having to send these
different types of data using separate protocols. Additionally,
this multiplexing allows for port savings versus using different
ports for reliable and unreliable connections.
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
BCP 14, RFC 2119 [1].
Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are
governed by the rules in Section 1.6 of RFC 2960 [2].
3. Protocol Changes to support PR-SCTP
3.1. Forward-TSN-Supported 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
-------------------------------------------------------------
Forward-TSN-Supported OPTIONAL 49152 (0xC000)
At the initialization of the association, the sender of the INIT or
INIT ACK chunk MAY include this OPTIONAL parameter to inform its peer
that it is able to support the Forward TSN chunk (see Section 3.3 for
further details). The format of this 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 = 49152 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bit u_int
49152, indicating Forward-TSN-Supported parameter
Length: 16 bit u_int
Indicates the size of the parameter, i.e., 4.
3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN)
The following new chunk type is defined:
Chunk Type Chunk Name
------------------------------------------------------
192 (0xC0) 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 data chunks that SHOULD NOT be
transmitted or 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 192 | Flags = 0x00 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-1 | Stream Sequence-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-N | Stream Sequence-N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 MUST consider
any missing TSNs earlier than or equal to this value as received,
and stop reporting them as gaps in any subsequent SACKs.
Stream-N: 16 bit u_int
This field holds a stream number that was skipped by this
FWD-TSN.
Stream Sequence-N: 16 bit u_int
This field holds the sequence number associated with the stream
that was skipped. The stream sequence field holds the largest
stream sequence number in this stream being skipped. The receiver
of the FWD-TSN’s can use the Stream-N and Stream Sequence-N fields
to enable delivery of any stranded TSN’s that remain on the stream
re-ordering queues. This field MUST NOT report TSN’s corresponding
to DATA chunks that are marked as unordered. For ordered DATA
chunks this field MUST be filled in.
3.3. Negotiation of Forward-TSN-Supported parameter
3.3.1. Sending Forward-TSN-Supported param in INIT
If an SCTP endpoint supports the FORWARD TSN chunk, then any time it
sends an INIT during association establishment, it MAY include the
Forward-TSN-supported parameter in the INIT chunk to indicate this
fact to its peer.
Note that if the endpoint chooses NOT to include the parameter, then
at no time during the life of the association can it send or process
a FORWARD TSN. It MUST instead act as if it does NOT support the
FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any
FORWARD TSN.
3.3.2. Receipt of Forward-TSN-Supported parameter in INIT or INIT-ACK
When a receiver of an INIT detects a Forward-TSN-Supported parameter
and does not support the Forward-TSN chunk type, the receiver MUST
follow the rules defined in Section 3.3.3 of RFC 2960 [2].
When a receiver of an INIT-ACK detects a Forward-TSN-Supported
parameter and it does not support the Forward-TSN chunk type, the
receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960
[2].
When a receiver of an INIT detects a Forward-TSN-Supported parameter
and it does support the Forward-TSN chunk type, the receiver MAY
respond with a Forward-TSN-supported parameter in the INIT-ACK chunk.
Note that if the endpoint chooses NOT to include the parameter, then
at no time during the life of the association can it send or process
a FORWARD TSN. It MUST instead act as if it does NOT support the
FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any
FORWARD TSN.
When an endpoint that supports the FORWARD TSN chunk receives an INIT
that does not contain the Forward-TSN-Supported Parameter, that
endpoint:
o MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
o SHOULD record the fact that the peer does not support the FORWARD
TSN chunk,
o MUST NOT send a FORWARD TSN chunk at any time during the
associations life,
o SHOULD inform the upper layer if the upper layer has requested
such notification.
3.3.3. Receipt of Op. Error for Forward-TSN-Supported Param
When an SCTP endpoint that desires to use the FORWARD TSN chunk
feature for partially reliable data transfer receives an operational
error from the remote endpoint (either bundled with the COOKIE or as
an unrecognized parameter in the INIT-ACK), indicating that the
remote endpoint does not recognize the Forward-TSN-Supported
parameter, the local endpoint SHOULD inform its upper layer of the
remote endpoint’s inability to support partially reliable data
transfer.
The local endpoint may then choose to either:
1) end the initiation process (in cases where the initiation process
has already ended, the endpoint may need to send an ABORT) in
consideration of the peer’s inability to supply the requested
features for the new association, or
2) continue the initiation process (in cases where the initiation
process has already completed, the endpoint MUST just mark the
association as not supporting partial reliability), but with the
understanding that partially reliable data transmission is not
supported. In this case, the endpoint receiving the operational
error SHOULD note that the FORWARD TSN chunk is not supported, and
MUST NOT transmit a FORWARD TSN chunk at any time during the life
of the association.
3.4. Definition of "abandoned" in the context of PR-SCTP
At some point, a sending PR-SCTP implementation MAY determine that a
particular data chunk SHOULD NOT be transmitted or retransmitted
further, in accordance with the rules governing some particular PR-
SCTP service definition (such as the definition of "timed
reliability" in Section 4.1.) For purposes of this document, we
define the term "abandoned" to refer to any data chunk about which
the SCTP sender has made this determination.
Each PR-SCTP service defines the rules for determining when a TSN is
"abandoned", and accordingly, the rules that govern how, whether, and
when to "abandon" a TSN may vary from one service definition to
another. However, the rules governing the actions taken when a TSN
is "abandoned" do NOT vary between service definitions; these rules
are included in Section 3.5.
3.5. Sender Side Implementation of PR-SCTP
The sender side implementation of PR-SCTP is identical to that of the
base SCTP protocol, except for:
o actions a sending side PR-SCTP implementation must take when a TSN
is "abandoned" (as per the rules of whatever PR-SCTP service
definition is in effect)
o special actions that a PR-SCTP implementation must take upon
receipt of SACK
o rules governing the generation of FORWARD TSN chunks.
In detail, these exceptions are as follows:
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 SCTP "Cumulative TSN Ack Point" as
defined in Section 1.4 of RFC 2960 [2], and as discussed
throughout that document.)
A2) From time to time, as governed by the rules of a particular PR-
SCTP service definition (see Section 4), the SCTP data sender may
make a determination that a particular data chunk that has
already been assigned a TSN SHOULD be "abandoned".
When a data chunk is "abandoned", the sender MUST treat the data
chunk as being finally acked and no longer outstanding.
The sender MUST NOT credit an "abandoned" data chunk to the
partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2],
and MUST NOT advance the cwnd based on this "abandoned" data
chunk.
A3) When a TSN is "abandoned", if it is part of a fragmented message,
all other TSN’s within that fragmented message MUST be abandoned
at the same time.
A4) Whenever the data sender receives a SACK from the data receiver,
it MUST first process the SACK using the normal procedures as
defined in Section 6.2.1 of RFC 2960 [2].
The data sender MUST then perform the following additional steps:
C1) Let SackCumAck be the Cumulative TSN ACK carried in the
received SACK.
If (Advanced.Peer.Ack.Point < SackCumAck), then update
Advanced.Peer.Ack.Point to be equal to SackCumAck.
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 space is marked as "abandoned",
as shown in the following 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 abandoned 103 abandoned
104 abandoned Adv.Ack.P-> 104 abandoned
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" is
greater than the Cumulative TSN ACK carried in 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 that the sender MAY delay