Network Working Group R. Stewart
Internet-Draft Huawei
Intended status: Standards Track P. Lei
Expires: August 27, 2010 Cisco Systems, Inc.
M. Tuexen
Muenster Univ. of Applied Sciences
February 23, 2010
Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
draft-ietf-tsvwg-sctp-strrst-04.txt
Abstract
Many applications that desire to use SCTP have requested the ability
to "reset" a stream. The intention of resetting a stream is to start
the numbering sequence of the stream back at 'zero' with a
corresponding notification to the upper layer that this act as been
performed. The applications that have requested this feature
normally desire it so that they can "re-use" streams for different
purposes but still utilize the stream sequence number for the
application to track the message flows. Thus, without this feature,
a new use on an old stream would result in message numbers larger
than expected without a protocol mechanism to "start the streams back
at zero". This documents presents also a method for resetting the
transport sequence numbers, adding additional streams and resetting
all stream sequence numbers.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
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.
Stewart, et al. Expires August 27, 2010 [Page 1]
Internet-Draft SCTP Stream Reconfiguration February 2010
This Internet-Draft will expire on August 27, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Stewart, et al. Expires August 27, 2010 [Page 2]
Internet-Draft SCTP Stream Reconfiguration February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. STREAM RESET Chunk . . . . . . . . . . . . . . . . . . . . 6
4. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 7
4.1. Outgoing SSN Reset Request Parameter . . . . . . . . . . . 7
4.2. Incoming SSN Reset Request Parameter . . . . . . . . . . . 9
4.3. SSN/TSN Reset Request Parameter . . . . . . . . . . . . . 9
4.4. Stream Reset Response Parameter . . . . . . . . . . . . . 10
4.5. Add Outgoing Streams Request Parameter . . . . . . . . . . 11
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Sender Side Procedures . . . . . . . . . . . . . . . . . . 12
5.1.1. Sender Side Procedures for the Stream Reset Chunk . . 13
5.1.2. Sender Side Procedures for the Outgoing SSN Reset
Request Parameter . . . . . . . . . . . . . . . . . . 13
5.1.3. Sender Side Procedures for the Incoming SSN Reset
Request Parameter . . . . . . . . . . . . . . . . . . 14
5.1.4. Sender Side Procedures for the SSN/TSN Reset
Request Parameter . . . . . . . . . . . . . . . . . . 15
5.1.5. Sender Side Procedures for the Stream Reset
Response Parameter . . . . . . . . . . . . . . . . . . 15
5.1.6. Sender Side Procedures for the Add Outgoing
Streams Request Parameter . . . . . . . . . . . . . . 16
5.2. Receiver Side Procedures . . . . . . . . . . . . . . . . . 16
5.2.1. Receiver Side Procedures for the Stream Reset Chunk . 16
5.2.2. Receiver Side Procedures for the Outgoing SSN
Reset Request Parameter . . . . . . . . . . . . . . . 17
5.2.3. Receiver Side Procedures for the Incoming SSN
Reset Request Parameter . . . . . . . . . . . . . . . 18
5.2.4. Receiver Side Procedures for the SSN/TSN Reset
Request Parameter . . . . . . . . . . . . . . . . . . 18
5.2.5. Receiver Side Procedures for the Add Outgoing
Streams Request Parameter . . . . . . . . . . . . . . 19
5.2.6. Receiver Side Procedures for the Stream Reset
Response Parameter . . . . . . . . . . . . . . . . . . 19
5.3. Various Examples of the Stream Reset procedures . . . . . 20
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 21
6.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1. Stream Reset Event . . . . . . . . . . . . . . . . . . 22
6.1.2. Association Reset Event . . . . . . . . . . . . . . . 23
6.1.3. Stream Change Event . . . . . . . . . . . . . . . . . 23
6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . 24
6.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 25
6.3.1. Enable/Disable Stream Reset
(SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 26
6.3.2. Reset Incoming and/or Outgoing Streams
Stewart, et al. Expires August 27, 2010 [Page 3]
Internet-Draft SCTP Stream Reconfiguration February 2010
(SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 27
6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 27
6.3.4. Add Outgoing Streams (SCTP_ADD_OUT_STREAMS) . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 29
8.2. Five New Parameter Types . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Stewart, et al. Expires August 27, 2010 [Page 4]
Internet-Draft SCTP Stream Reconfiguration February 2010
1. Introduction
Many applications that desire to use SCTP have requested the ability
to "reset" a stream. The intention of resetting a stream is to start
the numbering sequence of the stream back at 'zero' with a
corresponding notification to the upper layer that this act as been
performed. The applications that have requested this feature
normally desire it so that they can "re-use" streams for different
purposes but still utilize the stream sequence number for the
application to track the message flows. Thus, without this feature,
a new use on an old stream would result in message numbers larger
than expected without a protocol mechanism to "start the streams back
at zero". This documents presents also a method for resetting the
transport sequence numbers, adding additional streams and resetting
all stream sequence numbers.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. New Chunk Type
This section defines the new chunk type that will be used to reset
streams. Table 1 illustrates the new chunk type.
+------------+-----------------------------------+
| Chunk Type | Chunk Name |
+------------+-----------------------------------+
| 0x82 | Stream Reset Chunk (STREAM_RESET) |
+------------+-----------------------------------+
Table 1
It should be noted that the STREAM_RESET-chunk format requires the
receiver to ignore the chunk if it is not understood and continue
processing all chunks that follow. This is accomplished by the use
of the upper bits of the chunk type as described in section 3.2 of
[RFC4960].
All transported integer numbers are in "network byte order" a.k.a.,
Big Endian, unless otherwise noted.
Stewart, et al. Expires August 27, 2010 [Page 5]
Internet-Draft SCTP Stream Reconfiguration February 2010
3.1. STREAM RESET Chunk
This document adds one new chunk type to SCTP. The 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 = 0x82 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Parameter (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 1 byte (unsigned integer)
This field holds the IANA defined chunk type for the STREAM RESET
chunk.
Chunk Flags: 1 byte (unsigned integer)
This field is set to 0 by the sender and ignored by the receiver.
Chunk Length: 2 bytes (unsigned integer)
This field holds the length of the chunk, including the Chunk
Type, Chunk Flags and Chunk Length.
Stream Reset Parameter
This field holds a Stream Reset Request Parameter or a Stream
Reset Response Parameter.
Note each STREAM RESET chunk holds at least one parameter and at most
two parameters. Only the following combinations are allowed:
1. Outgoing SSN Reset Request Parameter.
2. Incoming SSN Reset Request Parameter.
3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request
Parameter.
4. SSN/TSN Reset Request Parameter.
5. Add Outgoing Streams Request Parameter.
6. Stream Reset Response Parameter.
7. Stream Reset Response Parameter, Outgoing SSN Reset Request
Parameter.
Stewart, et al. Expires August 27, 2010 [Page 6]
Internet-Draft SCTP Stream Reconfiguration February 2010
8. Stream Reset Response Parameter, Stream Reset Response Parameter.
If a sender transmits an unsupported combination, the receiver SHOULD
send an ERROR chunk with a protocol violation cause.
4. New Parameter Types
This section defines the new parameter types that will be used in the
STREAM_RESET chunk. Table 2 illustrates the new parameter types.
+----------------+----------------------------------------+
| Parameter Type | Parameter Name |
+----------------+----------------------------------------+
| 0x000d | Outgoing SSN Reset Request Parameter |
| 0x000e | Incoming SSN Reset Request Parameter |
| 0x000f | SSN/TSN Reset Request Parameter |
| 0x0010 | Stream Reset Response Parameter |
| 0x0011 | Add Outgoing Streams Request Parameter |
+----------------+----------------------------------------+
Table 2
It should be noted that the parameter format requires the receiver to
stop processing the parameter and not to process any further
parameters within the chunk if the parameter type is not recognized.
This is accomplished by the use of the upper bits of the parameter
type as described in section 3.2.1 of [RFC4960].
All transported integer numbers are in "network byte order" a.k.a.,
Big Endian, unless otherwise noted.
4.1. Outgoing SSN Reset Request Parameter
This parameter is used by the sender to request some outgoing streams
to be reset.
Stewart, et al. Expires August 27, 2010 [Page 7]
Internet-Draft SCTP Stream Reconfiguration February 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000d | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Response Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Senders Last Assigned TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for Stream Reset
Request Parameter. The suggested value of this field for IANA is
0x000d.
Parameter Length: 2 bytes (unsigned integer)
This field holds the length of the parameter.
Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1.
Stream Reset Response Sequence Number: 4 bytes (unsigned integer)
In case that this Outgoing SSN Reset Request Parameter is sent in
response to an Incoming SSN Reset Request Parameter this parameter
is also an implicit response to the incoming request. Then this
field holds the Stream Reset Request Sequence Number of the
incoming request. In the other case it holds the next expected
Stream Reset Request Sequence Number - 1.
Senders last assigned TSN: 4 bytes (unsigned integer)
This value holds the next TSN minus 1, in other words the last TSN
that this sender assigned.
Stream Number N: 2 bytes (unsigned integer)
This optional field, if included, is used to indicates specific
streams that are to be reset. If no streams are listed, then all
streams are to be reset.
Stewart, et al. Expires August 27, 2010 [Page 8]
Internet-Draft SCTP Stream Reconfiguration February 2010
This parameter can appear in a STREAM RESET chunk. This parameter
MUST NOT appear in any other chunk type.
4.2. Incoming SSN Reset Request Parameter
This parameter is used by the sender to request that the peer
requests some of its outgoing streams to be reset.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000e | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for Stream Reset
Request Parameter. The suggested value of this field for IANA is
0x000e.
Parameter Length: 2 bytes (unsigned integer)
This field holds the length of the parameter.
Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1.
Stream Number N: 2 bytes (unsigned integer)
This optional field, if included, is used to indicate specific
streams that are to be reset. If no streams are listed, then all
streams are to be reset.
This parameter can appear in a STREAM RESET chunk. This parameter
MUST NOT appear in any other chunk type.
4.3. SSN/TSN Reset Request Parameter
This parameter is used by the sender to request to reset the TSN and
SSN numbering of all streams.
Stewart, et al. Expires August 27, 2010 [Page 9]
Internet-Draft SCTP Stream Reconfiguration February 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000f | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for Stream Reset
Request Parameter. The suggested value of this field for IANA is
0x000f.
Parameter Length: 2 bytes (unsigned integer)
This field holds the length of the parameter.
Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1.
This parameter can appear in a STREAM RESET chunk. This parameter
MUST NOT appear in any other chunk type.
4.4. Stream Reset Response Parameter
This parameter is used by the receiver of a stream reset request
parameter to respond to the stream reset request.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x0010 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Response Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's next TSN (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's next TSN (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for Stream Reset
Response Parameter. The suggested value of this field for IANA is
0x0010.
Stewart, et al. Expires August 27, 2010 [Page 10]
Internet-Draft SCTP Stream Reconfiguration February 2010
Parameter Type Length: 2 bytes (unsigned integer)
This field holds the length of the parameter.
Stream Reset Response Sequence Number: 4 bytes (unsigned integer)
This value is copied from the request parameter and is used by the
receiver of the Stream Reset Response Parameter to tie the
response to the request.
Result: 4 bytes (unsigned integer)
This value describes the result of the processing of the request.
It is encoded as given by the following table
+--------+-------------------------------------+
| Result | Description |
+--------+-------------------------------------+
| 0 | Nothing to do |
| 1 | Performed |
| 2 | Denied |
| 3 | Error - Wrong SSN |
| 4 | Error - Request already in progress |
| 5 | Error - Bad Sequence Number |
+--------+-------------------------------------+
Table 3
Sender's next TSN: 4 bytes (unsigned integer) This field holds the
TSN the sender of the Response will use to send the next DATA
chunk. The field is only applicable in responses to SSN/TSN reset
requests.
Receiver's next TSN: 4 bytes (unsigned integer) This field holds the
TSN the receiver of the response must use to send the next DATA
chunk. The field is only applicable in responses to SSN/TSN reset
requests.
This parameter can appear in a STREAM RESET chunk. This parameter
MUST NOT appear in any other chunk type.
4.5. Add Outgoing Streams Request Parameter
This parameter is used by the sender to request an additional number
of outgoing streams (i.e. the receiver's incoming streams) be added
to the association.
Stewart, et al. Expires August 27, 2010 [Page 11]
Internet-Draft SCTP Stream Reconfiguration February 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x0011 | Parameter Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Reset Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of new streams | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the Add
Streams Parameter. The suggested value of this field for IANA is
0x0011.
Parameter Length: 2 bytes (unsigned integer)
This field holds the length of the parameter, a fixed value of 12
MUST be found in this field.
Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1.
Number of new streams: 2 bytes (unsigned integer) This value holds
the number of additional outgoing streams the sender would like
added to the association. Streams are added in order and are
consecutive, e.g. if an association has four outgoing streams
(0-3) and a requested is made to add 3 streams then the new
streams will be 4, 5 and 6.
Reserved: 2 bytes (unsigned integer) This field is reserved. It
SHOULD be set to 0 by the sender and ignored by the receiver.
This parameter can appear in a STREAM RESET chunk. This parameter
MUST NOT appear in any other chunk type.
5. Procedures
This section defines the procedures used by both the sender and
receiver of a stream reset. We also give various example stream
reset scenarios.
5.1. Sender Side Procedures
This section describes the procedures related to the sending of
Stream Reset Chunks. A Stream Reset Chunk is a composition of a Type
Stewart, et al. Expires August 27, 2010 [Page 12]
Internet-Draft SCTP Stream Reconfiguration February 2010
Length Value (TLV) parameters.
5.1.1. Sender Side Procedures for the Stream Reset Chunk
This SCTP extension uses the Supported Extensions Parameter defined
in [RFC5061] for negotiating the support of it.
An SCTP endpoint supporting this extension MUST include the chunk
type of the STREAM_RESET chunk in the Supported Extensions Parameter
in either the INIT or INIT-ACK. Before sending a Stream Reset Chunk
the sender MUST ensure that the peer advertised support for the
stream reset extension. If the chunk type of the STREAM_RESET chunk
does NOT appear in the supported extensions list of chunks, then the
sender MUST NOT send any stream reset request to the peer and any
request by the application for such service SHOULD be responded to
with an appropriate error indicating the peer SCTP stack does not
support the stream reset extension.
After packaging the Stream Reset Chunk and sending it to the peer the
sender MUST start a 'Stream Reset Timer' when the STREAM RESET chunk
contains at least one request parameter. If it contains no request
parameter, the Stream Reset Timer MUST NOT be started. This timer
MUST use the same value as SCTP's Data transmission timer (i.e. the
RTO timer) and MUST use exponential backoff doubling the value at
every expiration. If the timer does expire, besides doubling the
value, the sender MUST retransmit the Stream Reset Chunk, increment
the appropriate error counts (both for the association and the
destination), and do threshold management possibly destroying the
association if SCTP retransmission thresholds are surpassed.
5.1.2. Sender Side Procedures for the Outgoing SSN Reset Request
Parameter
When an SCTP sender wants to reset the SSNs of some or all outgoing
streams it can send an Outgoing SSN Reset Request Parameter if the
Stream Reset Timer is not running. The following steps MUST be
followed:
A1: The sender MUST stop assigning new SSNs to new user data
provided by the upper layer. This is because it is unknown as
to if the receiver of the request will accept or deny it and
more so, a lost request might cause an out-of-sequence error in
a stream that the receiver is not yet prepared to handle.
A2: The sender MUST assign the next stream reset request sequence
number and put it into the Stream Reset Request Sequence Number
field of the Outgoing SSN Reset Request Parameter. After
assigning it the next stream reset request sequence number MUST
Stewart, et al. Expires August 27, 2010 [Page 13]
Internet-Draft SCTP Stream Reconfiguration February 2010
be incremented by '1'.
A3: If this Outgoing SSN Reset Request Parameter is sent in response
to an Incoming SSN Request Parameter, the Stream Numbers between
the Outgoing and the Incoming parameters MUST match. If the
Outgoing SSN Reset Request Parameter is sent on request of the
upper layer the Stream Reset Response Sequence Number is the
next expected Stream Reset Request Sequence Number of the peer -
3.
A4: The sender fills in the TSN it has assigned last.
A5: If this Outgoing SSN Reset Request Parameter is sent in response
to an Incoming SSN Request Parameter the Stream Numbers are
copied from the Incoming SSN Request Parameter to the Outgoing
SSN Reset Request Parameter. If this Outgoing SSN Reset Request
Parameter is sent on request of the upper layer and the sender
wants all outgoing streams to be reset no Stream Numbers MUST be
put into the Outgoing SSN Reset Request Parameter. If the
sender wants only some outgoing streams to be reset these Stream
Numbers MUST be filled in the Outgoing SSN Reset Request
Parameter.
A6: The Outgoing SSN Reset Request Parameter is put into a STREAM
RESET Chunk. It MAY be put together with an Incoming SSN Reset
Request Parameter or an Stream Reset Response Parameter and MUST
NOT be put together with any other parameter.
A7: The STREAM RESET Chunk is sent following the rules given in
Section 5.1.1
5.1.3. Sender Side Procedures for the Incoming SSN Reset Request
Parameter
When an SCTP sender wants to reset the SSNs of some or all incoming
streams it can send an Incoming SSN Reset Request Parameter if the
Stream Reset Timer is not running. The following steps MUST be
followed:
B1: The sender MUST assign the next stream reset request sequence
number and put it into the Stream Reset Request Sequence Number
field of the Incoming SSN Reset Request Parameter. After
assigning it the next stream reset request sequence number MUST
be incremented by '1'.
Stewart, et al. Expires August 27, 2010 [Page 14]
Internet-Draft SCTP Stream Reconfiguration February 2010
B2: If the sender wants all incoming streams to be reset no Stream
Numbers MUST be put into the Incoming SSN Reset Request
Parameter. If the sender wants only some incoming streams to be
reset these Stream Numbers MUST be filled in the Incoming SSN
Reset Request Parameter.
B3: The Incoming SSN Reset Request Parameter is put into a STREAM
RESET Chunk. It MAY be put together with an Outgoing SSN Reset
Request Parameter and MUST NOT be put together with any other
parameter.
B4: The STREAM RESET Chunk is sent following the rules given in
Section 5.1.1
5.1.4. Sender Side Procedures for the SSN/TSN Reset Request Parameter
When an SCTP sender wants to reset the SSNs and TSNs it can send a
SSN/TSN Reset Request Parameter if the Stream Reset Timer is not
running. The following steps MUST be followed:
C1: The sender MUST assign the next stream reset request sequence
number and put it into the Stream Reset Request Sequence Number
field of the SSN/TSN Reset Request Parameter. After assigning
it the next stream reset request sequence number MUST be
incremented by '1'.
C2: The sender MUST queue any user data suspending any new
transmissions and TSN assignment until the reset procedure is
finished by the peer either acknowledging or denying the
request.
C3: The SSN/TSN Reset Request Parameter is put into a STREAM RESET
Chunk. There MUST NOT be any other parameter in this chunk.
C4: The STREAM RESET Chunk is sent following the rules given in
Section 5.1.1
There SHOULD NOT be sent more than one SSN/TSN Reset Request within a
maximum segment lifetime.
5.1.5. Sender Side Procedures for the Stream Reset Response Parameter
When an implementation receives a request parameter it MUST respond
with a Stream Reset Response Parameter in the following manner:
Stewart, et al. Expires August 27, 2010 [Page 15]
Internet-Draft SCTP Stream Reconfiguration February 2010
D1: The Stream Reset Request Sequence number of the incoming request
is copied to the Stream Reset Response Sequence Number field of
the Stream Reset Response Parameter.
D2: The result of the processing of the incoming request is filled
in the Result field of the Stream Reset Response Parameter
D3: If the incoming request is a SSN/TSN reset requests, the
Sender's next TSN field is filled with the next TSN the sender
of this Stream Reset Response Parameter will assign. For other
requests the Sender's next TSN field is not filled.
D4: If the incoming request is a SSN/TSN reset request, the
Receiver's next TSN field is filled with a TSN such that the
sender of the Stream Reset Response Parameter can be sure it can
discard received DATA chunks with smaller TSNs. A good value
for this is the highest TSN it has seen plus some delta. For
other requests the Sender's next TSN field is not filled.
5.1.6. Sender Side Procedures for the Add Outgoing Streams Request
Parameter
When an SCTP sender wants to increase the number of outbound streams
it is able to send to, it may add a Add Streams parameter to the
STREAM RESET chunk. Upon sending the request the sender MUST await a
positive acknowledgment (Success) before using any additional stream
added by this request. Note that new streams are added adjacent to
the previous steams with no gaps. This means that if a request is
made to add 2 streams to an association that has already 5 (0-4) then
the new streams, upon successful completion, are streams 5 and 6.
Any new stream MUST number its first message to be stream sequence 0.
5.2. Receiver Side Procedures
5.2.1. Receiver Side Procedures for the Stream Reset Chunk
Upon reception of a Stream Reset Chunk each parameter within it
should be processed. If some parameters have to be sent back, they
MUST all be put into one STREAM RESET chunk. If the received STREAM
RESET chunk contains at least one request parameter, a SACK chunk
SHOULD be sent back and MAY be bundled with the STREAM RESET chunk.
If the received STREAM RESET chunk contains at least one request and
based on the analysis of the Stream Reset Request Sequence Numbers
this is the last received STREAM RESET chunk (i.e. a retransmission),
the same STREAM RESET chunk has to be sent back in response as
earlier.
The decision to deny a stream reset request is an administrative
Stewart, et al. Expires August 27, 2010 [Page 16]
Internet-Draft SCTP Stream Reconfiguration February 2010
decision and may be user configurable even after the association has
formed. If for whatever reason the endpoint does NOT wish to process
a received request parameter it MUST send a corresponding response
parameter as described in Section 5.1.5 with an appropriate Result
field.
Implementation Note: A SACK is recommended to be bundled with any
stream reset response so that any retransmission processing that
needs to occur can be expedited. A SACK chunk is not required for
this feature to work, but it will in effect help minimize the delay
in completing a stream reset operation in the face of any data loss.
5.2.2. Receiver Side Procedures for the Outgoing SSN Reset Request
Parameter
In the case that the endpoint is willing to perform a stream reset
the following steps SHOULD be followed:
E1: If the Senders Last Assigned TSN number is greater than the
cumulative acknowledgment point, then the endpoint MUST enter
"deferred reset processing". In this mode, any data arriving
with a TSN number larger than the 'senders last assigned TSN'
for the effected stream(s) MUST be queued locally and held until
the Cumulative Acknowledgment point reaches the 'senders last
assigned TSN number'. When the Cumulative Acknowledgment point
reaches the last assigned TSN number then proceed to the next
step. Note that the receiver of a stream reset that causes it
to entered deferred reset processing does NOT withhold the
stream reset acknowledgment from the peer. This also means that
the receiver will need to queue up any additional stream reset
requests received including the one that caused the receiver to
enter deferred reset processing. This is because once the
acknowledgement is received by the sender, the sender is free to
send a new stream reset.
E2: If the Stream Reset Timer is running for the Stream Reset
Request Sequence Number indicated in the Stream Reset Response
Sequence Number field, mark the Stream Reset Request Sequence
Number as acknowledged. If all Stream Reset Request Sequence
Numbers the Stream Reset Timer is running for are acknowledged,
stop the Stream Reset Timer.
E3: If no Stream Numbers are listed in the parameter, then all
incoming streams MUST be reset to '0' as the next expected
stream sequence number. If specific Stream Numbers are listed,
then only these specific streams MUST be reset to '0' and all
other non-listed stream sequence numbers remain unchanged.
Stewart, et al. Expires August 27, 2010 [Page 17]
Internet-Draft SCTP Stream Reconfiguration February 2010
E4: Optionally an Upper Layer Notification SHOULD be sent to inform
the local endpoint that the inbound streams have been reset.
E5: Any queued TSN's (queued at step E1) should now be released and
processed normally.
E6: A Stream Reset Response Parameter is put into a STREAM RESET
chunk indicating successful processing.
E7: The STREAM RESET chunk is sent after the incoming STREAM RESET
chunk is processed completely.
5.2.3. Receiver Side Procedures for the Incoming SSN Reset Request
Parameter
In the case that the endpoint is willing to perform a stream reset
the following steps SHOULD be followed:
F1: An Outgoing Stream Reset Request Parameter MUST be put into an
STREAM RESET chunk according to Section 5.1.2.
F2: The STREAM RESET chunk is sent after the incoming STREAM RESET
chunk is processed completely.
5.2.4. Receiver Side Procedures for the SSN/TSN Reset Request Parameter
In the case that the endpoint is willing to perform a SSN/TSN reset
the following steps SHOULD be followed:
G1: Compute an appropriate value for the Receiver's next TSN, the
TSN the peer should use to send the next DATA chunk. The value
SHOULD be the smallest TSN not acknowledged by the receiver of
the request plus 2^31.
G2: Compute an appropriate value for the local endpoints next TSN,
i.e. the receiver of the SSN/TSN reset chunks next TSN to be
assigned. The value SHOULD be the highest TSN sent by the
receiver of the request plus 1.
G3: Do the same processing as if a SACK chunk with no gap report and
a cumulative TSN ACK of Sender's next TSN - 1 was received.
G4: Do the same processing as if an FWD-TSN chunk with all streams
affected and a new cumulative TSN ACK of Receiver's next TSN - 1
was received.
Stewart, et al. Expires August 27, 2010 [Page 18]
Internet-Draft SCTP Stream Reconfiguration February 2010
G5: All incoming and outgoing streams MUST be reset to '0' as the
next expected and outgoing stream sequence numbers,
respectively.
G6: A Stream Reset Response Parameter is put into a STREAM RESET
chunk indicating successful processing.
G7: The STREAM RESET chunk is sent after the incoming STREAM RESET
chunk is processed completely.
5.2.5. Receiver Side Procedures for the Add Outgoing Streams Request
Parameter
When an SCTP endpoint receives a stream reset request adding
additional streams, it MUST send a response parameter either
acknowledging or rejecting the request. If the response is
successful the receiver MUST add the requested number of inbound
streams to the association, initializing the next expected stream
sequence number to be 0.
5.2.6. Receiver Side Procedures for the Stream Reset Response Parameter
On receipt of a Stream Reset Response Parameter the following MUST be
performed:
H1: If the Stream Reset Timer is running for the Stream Reset
Request Sequence Number indicated in the Stream Reset Response
Sequence Number field, mark the Stream Reset Request Sequence
Number as acknowledged. If all Stream Reset Request Sequence
Numbers the Stream Reset Timer is running for are acknowledged,
stop the Stream Reset Timer. If the timer was not running for
the Stream Reset Request Sequence Number, the processing of the
Stream Reset Response Parameter is complete.
H2: If the Result field does not indicate successful processing an
Upper Layer Notification SHOULD be sent to inform the local
endpoint of the failure to reset its outbound streams.
Afterwards processing of this response is complete.
H3: If the request was an Outgoing Stream Reset Request the affected
streams should now be reset and all queued data should be
processed now and assigning of stream sequence numbers is
allowed again. Optionally an Upper Layer Notification SHOULD be
sent to inform the local endpoint that the outbound streams have
been reset.
Stewart, et al. Expires August 27, 2010 [Page 19]
Internet-Draft SCTP Stream Reconfiguration February 2010
H4: If the request was a SSN/TSN Reset Request new DATA should be
sent from Receiver's next TSN and beginning with stream sequence
number '0' for all outgoing streams. All incoming streams are
also reset to '0' as the next expected stream sequence number.
The peer will send DATA chunks starting with Sender's next TSN.
H5: If the request was to add outgoing streams and the result was
successful, the endpoint should add the additional streams to
the association. Note that an implementation may allocate the
memory at the time of the request, but it MUST NOT use the
streams until the peer has responded with a positive
acknowledgment.
5.3. Various Examples of the Stream Reset procedures
The following example illustrates an Endpoint A resetting stream 1
and 2 for just its outgoing streams.
E-A E-Z
----------[STR_RESET(OUT-REQ:X/1,2)]---------->
<-------------[STR_RESET(RESP:X)]--------------
The following example illustrates an Endpoint A resetting stream 1
and 2 for just its incoming streams.
E-A E-Z
-----------[STR_RESET(IN-REQ:X/1,2)]---------->
<-----------[STR_RESET(OUT-REQ:Y,X)]-----------
-------------[STR_RESET(RESP:Y)]-------------->
The following example illustrates an Endpoint A resetting all streams
in both directions.
E-A E-Z
-----[STR_RESET(OUT-REQ:X,Y-1)|IN-REQ:X+1]---->
<------[STR_RESET(RESP:X|OUT-REQ:Y,X+1)]-------
-------------[STR_RESET(RESP:Y)]-------------->
The following example illustrates an Endpoint A requesting the
streams and TSN's be reset. At the completion E-A has the new
sending TSN (selected by the peer) of B and E-Z has the new sending
TSN of A (also selected by the peer).
E-A E-Z
------------[STR_RESET(TSN-REQ:X)]------------>
<-----[STR_RESET(RESP:X/S-TSN=A, R-TSN=B)]-----
The following example illustrates an Endpoint A requesting to add 3
Stewart, et al. Expires August 27, 2010 [Page 20]
Internet-Draft SCTP Stream Reconfiguration February 2010
additional outgoing streams.
E-A E-Z
--------[STR_RESET(ADD_OUT_STRMS:X/3)]-------->
<-------------[STR_RESET(RESP:X)]--------------
6. Socket API Considerations
This section describes how the socket API defined in
[I-D.ietf-tsvwg-sctpsocket] SHOULD be extended to make the features
of SCTP stream reset available to the application.
6.1. Events
The union sctp_notification {} is extended by containing three new
fields: sn_strreset_event, sn_assocreset_event, and
sn_strchange_event:
union sctp_notification {
struct {
uint16_t sn_type;
uint16_t sn_flags;
uint32_t sn_length;
} sn_header;
...
struct sctp_stream_reset_event sn_strreset_event;
struct sctp_assoc_reset_event sn_assocreset_event;
struct sctp_stream_change_event sn_strchange_event;
...
}
The corresponding sn_type values are given in Table 4.
+--------------------------+----------------------------------------+
| sn_type | valid field in union sctp_notification |
+--------------------------+----------------------------------------+
| SCTP_STREAM_RESET_EVENT | sn_strreset_event |
| SCTP_ASSOC_RESET_EVENT | sn_assocreset_event |
| SCTP_STREAM_CHANGE_EVENT | sn_strchange_event |
+--------------------------+----------------------------------------+
Table 4
These events are delivered when an incoming request was processed
successfully or the processing of an outgoing request has been
finished.
Stewart, et al. Expires August 27, 2010 [Page 21]
Internet-Draft SCTP Stream Reconfiguration February 2010
6.1.1. Stream Reset Event
The event delivered has the following structure:
struct sctp_stream_reset_event {
uint16_t strreset_type;
uint16_t strreset_flags;
uint32_t strreset_length;
sctp_assoc_t strreset_assoc_id;
uint16_t strreset_stream_list[];
};
strreset_type: It should be SCTP_STREAM_RESET_EVENT.
strreset_flags: This field is formed from the bitwise OR of one or
more of the following currently defined flags:
SCTP_STREAM_RESET_INCOMING_SSN: The streams identifiers given in
strreset_stream_list[] refers to incoming streams of the
endpoint.
SCTP_STREAM_RESET_OUTGOING_SSN: The stream identifiers given in
strreset_stream_list[] refers to outgoing streams of the
endpoint.
SCTP_STREAM_RESET_DENIED: The corresponding request was denied by
the peer.
SCTP_STREAM_RESET_FAILED: The corresponding request failed.
At least one of SCTP_STREAM_RESET_INCOMING_SSN and
SCTP_STREAM_RESET_OUTGOING_SSN are set. SCTP_STREAM_RESET_DENIED
and SCTP_STREAM_RESET_FAILED are mutual exclusive. If the request
was successful, none of these are set.
strreset_length: This field is the total length of the delivered
event, including the header.
strreset_assoc_id: The association id field, holds the identifier
for the association. All notifications for a given association
have the same association identifier. For one-to-one style
socket, this field is ignored.
strreset_stream_list: The list of stream identifiers this event
refers to. An empty list identifies all streams as being reset.
Depending on strreset_flags the identifiers refer to incoming or
outgoing streams or both.
Stewart, et al. Expires August 27, 2010 [Page 22]
Internet-Draft SCTP Stream Reconfiguration February 2010
6.1.2. Association Reset Event
The event delivered has the following structure:
struct sctp_assoc_reset_event {
uint16_t assocreset_type;
uint16_t assocreset_flags;
uint32_t assocreset_length;
sctp_assoc_t assocreset_assoc_id;
uint32_t assocreset_local_tsn;
uint32_t assocreset_remote_tsn;
};
assocreset_type: It should be SCTP_ASSOC_RESET_EVENT.
assocreset_flags: This field is formed from the bitwise OR of one or
more of the following currently defined flags:
SCTP_ASSOC_RESET_DENIED: The corresponding outgoing request was
denied by the peer.
SCTP_ASSOC_RESET_FAILED: The corresponding outgoing request
failed.
SCTP_ASSOC_RESET_DENIED and SCTP_ASSOC_RESET_FAILED are mutual
exclusive. If the request was successful, none of these are set.
assocreset_length: This field is the total length of the delivered
event, including the header.
assocreset_assoc_id: The association id field, holds the identifier
for the association. All notifications for a given association
have the same association identifier. For one-to-one style
socket, this field is ignored.
assocreset_local_tsn: The next TSN used by the endpoint.
assocreset_remote_tsn: The next TSN used by the peer.
6.1.3. Stream Change Event
The event delivered has the following structure:
Stewart, et al. Expires August 27, 2010 [Page 23]
Internet-Draft SCTP Stream Reconfiguration February 2010
struct sctp_stream_change_event {
uint16_t strchange_type;
uint16_t strchange_flags;
uint32_t strchange_length;
sctp_assoc_t strchange_assoc_id;
uint16_t strchange_instrms;
uint16_t strchange_outstrms;
};
strchange_type: It should be SCTP_STREAM_CHANGE_EVENT.
strchange_flags: This field is formed from the bitwise OR of one or
more of the following currently defined flags:
SCTP_STREAM_CHANGE_DENIED: The corresponding request was denied
by the peer.
SCTP_STREAM_CHANGE_FAILED: The corresponding request failed.
SCTP_STREAM_CHANGE_DENIED and SCTP_STREAM_CHANGE_FAILED are mutual
exclusive. If the request was successful, none of these are set.
strchange_length: This field is the total length of the delivered
event, including the header.
strchange_assoc_id: The association id field, holds the identifier
for the association. All notifications for a given association
have the same association identifier. For one-to-one style
socket, this field is ignored.
strchange_instrms: The number of streams that the peer is allowed to
use outbound.
strchange_outstrms: The number of streams that the endpoint is
allowed to use outbound.
6.2. Event Subscription
There are two methods defined in the SCTP socket API to subscribe to
events. The original method defined was an events structure with the
socket option SCTP_EVENTS. Some implementations may have already
expanded their data structure for this API to include the stream
reset subscriptions. The new API is to use a setsockopt with the
SCTP_SET_EVENT socket option. This option takes a structure that
defines the association, the event type (using the same value found
in the event type field) and a on/off boolean. This newer API is the
preferred method but we define both methods for compatibility.
Stewart, et al. Expires August 27, 2010 [Page 24]
Internet-Draft SCTP Stream Reconfiguration February 2010
For some implementations the structure now takes on the form:
struct sctp_event_subscribe {
uint8_t sctp_data_io_event;
uint8_t sctp_association_event;
uint8_t sctp_address_event;
uint8_t sctp_send_failure_event;
uint8_t sctp_peer_error_event;
uint8_t sctp_shutdown_event;
uint8_t sctp_partial_delivery_event;
uint8_t sctp_adaptation_layer_event;
uint8_t sctp_authentication_event;
uint8_t sctp_sender_dry_event;
uint8_t sctp_stream_reset_event;
uint8_t sctp_assoc_reset_event;
uint8_t sctp_stream_change_event;
};
For those implementations that support this method simply putting a 1
or 0 in the sctp_stream_reset_event and setting the SCTP_EVENTS
socket option will work. However not all implementations support
this method.
The preferred method is to use the SCTP_SET_EVENT socket option and
fill in the structure sctp_set_event structure.
struct sctp_set_event {
sctp_assoc_t se_assoc_id;
uint16_t se_type;
uint8_t se_on;
};
Using this method, the user fill in the se_type with the same value
found in strreset_type field i.e. SCTP_STREAM_RESET_EVENT. The user
will also fill in the se_assoc_id field with either the association
to set this event on (this field is ignored for one-to-one style
sockets) or one of the reserved constant values defined in the socket
API document. Finally the se_on field is set with a 1 to enable the
event or a 0 to disable the event.
6.3. Socket Options
The following table describes the new socket options which make the
SCTP stream reset features accessible to the user. They all use
IPPROTO_SCTP as their level.
Stewart, et al. Expires August 27, 2010 [Page 25]
Internet-Draft SCTP Stream Reconfiguration February 2010
+--------------------------+---------------------------+-----+-----+
| option name | data type | get | set |
+--------------------------+---------------------------+-----+-----+
| SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value | X | X |
| SCTP_RESET_STREAMS | struct sctp_reset_streams | | X |
| SCTP_RESET_ASSOC | sctp_assoc_t | | X |
| SCTP_ADD_OUT_STREAMS | struct sctp_assoc_value | | X |
+--------------------------+---------------------------+-----+-----+
Table 5
6.3.1. Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET)
This option allows a user to control whether the SCTP implementation
processes or denies incoming requests in STREAM_RESET chunks.
The default is not to process incoming requests.
To set or get this option the user fills in the following structure:
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets this parameter indicates which
association the user is performing an action upon.
assoc_value: It is formed from the bitwise OR of one or more of the
following currently defined flags:
SCTP_DENY_RESET_IN_STREAM_REQ: Deny received Incoming SSN Reset
Requests if this flag is set, process it if not.
SCTP_DENY_RESET_OUT_STREAM_REQ: Deny received Outgoing SSN Reset
Requests if this flag is set, process it if not.
SCTP_DENY_RESET_ASSOC_REQ: Deny received SSN/TSN Reset Requests
if this flag is set, process it if not.
SCTP_DENY_CHANGE_ASSOC_REQ: Deny received Add Outgoing Streams
Requests if this flag is set, process it if not.
The default value is ~(SCTP_DENY_IN_STREAM_RESET|
SCTP_DENY_OUT_STREAM_RESET|SCTP_DENY_ASSOC_RESET|
SCTP_DENY_ASSOC_CHANGE)
Stewart, et al. Expires August 27, 2010 [Page 26]
Internet-Draft SCTP Stream Reconfiguration February 2010
Please note that using the option does not have any impact on
subscribing to any related events.
6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS)
This option allows the user to request the reset incoming and/or
outgoing streams.
To set or get this option the user fills in the following structure:
struct sctp_reset_streams {
sctp_assoc_t srs_assoc_id;
uint16_t srs_flags;
uint16_t srs_number_streams;
uint16_t srs_stream_list[];
};
srs_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets this parameter indicates
which association the user is performing an action upon.
srs_flags: This parameter describes which class of streams are
reset. It is formed from the bitwise OR of one or more of the
following currently defined flags:
* SCTP_STREAM_RESET_INCOMING
* SCTP_STREAM_RESET_OUTGOING
srs_number_streams: This parameter is the number of elements in the
srs_stream_list. If it is zero, the operation is performed on all
streams.
srs_stream_list: This parameter contains a list of stream
identifiers on which the operation is performed on. It contains
srs_number_streams elements. If it is empty, the operation is
performed on all streams. Depending on srs_flags the identifiers
refer to incoming or outgoing streams or both.
6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC)
This option allows a user to request the reset the SSN/TSN.
To set this option the user provides an option_value of type
sctp_assoc_t.
On one-to-one style sockets the option_value is ignored. For one-to-
many style sockets the option_value is the association identifier of
Stewart, et al. Expires August 27, 2010 [Page 27]
Internet-Draft SCTP Stream Reconfiguration February 2010
the association on which the action is to be performed on.
6.3.4. Add Outgoing Streams (SCTP_ADD_OUT_STREAMS)
This option allows a user to request the addition a number of
outgoing streams.
To set this option the user fills in the following structure:
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets this parameter indicates which
association the user is performing an action upon.
assoc_value: This parameter is the number of outgoing streams to
add.
An endpoint can limit the number of incoming streams by using the
sinit_max_instreams field in the struct sctp_initmsg{} when issuing
an SCTP_INIT socket option, as defined in
[I-D.ietf-tsvwg-sctpsocket]. An incoming request asking for more
streams than allow will be denied.
7. Security Considerations
Having the ability to reset a stream should not pose any additional
security risk to SCTP. An attacker that can successfully inject a
stream reset would also be able to inject data or other malicious
information into an association such as an ABORT.
8. IANA Considerations
[NOTE to RFC-Editor:
"RFCXXXX" is to be replaced by the RFC number you assign this
document.
]
This document (RFCXXX) is the reference for all registrations
described in this section. All registrations need to be listed in
the document available at sctp-parameters [1]. The suggested changes
Stewart, et al. Expires August 27, 2010 [Page 28]
Internet-Draft SCTP Stream Reconfiguration February 2010
are described below.
8.1. A New Chunk Type
A chunk type has to be assigned by IANA. It is suggested to use the
values given in Table 1. The value MUST be from the pool of chunks
with the upper two bits set to '10'.
This requires an additional line in the "CHUNK TYPES" table of sctp-
parameters [1]:
CHUNK TYPES
ID Value Chunk Type Reference
----- ---------- ---------
130 Stream Reset Chunk (STREAM_RESET) [RFCXXXX]
8.2. Five New Parameter Types
Five parameter types have to be assigned by IANA. It is suggested to
use the values given in Table 2. The values MUST be from the pool of
parameters with the upper two bits set to '00'.
This requires an addition to the "CHUNK PARAMETER TPYES" tables in
sctp-parameters [1]: An Entry for "STREAM RESET Chunk Parameter
Types" has to be made with the following initial contents:
--STREAM RESET Chunk Parameter Types
Chunk Parameter Type Value
-------------------- ----------
Outgoing SSN Reset Request Parameter 13 (0x000d)
Incoming SSN Reset Request Parameter 14 (0x000e)
SSN/TSN Reset Request Parameter 15 (0x000f)
Stream Reset Response Parameter 16 (0x0010)
Add Outgoing Streams Request Parameter 17 (0x0011)
9. Acknowledgments
The authors wish to thank Paul Aitken, Kacheong Poon, Irene
Ruengeler, Robin Seggelmann, and Vlad Yasevich for there invaluable
comments.
10. References
Stewart, et al. Expires August 27, 2010 [Page 29]
Internet-Draft SCTP Stream Reconfiguration February 2010
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
September 2007.
10.2. Informative References
[I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-21 (work in progress),
February 2010.
URIs
[1] <http://www.iana.org/assignments/sctp-parameters>
Authors' Addresses
Randall R. Stewart
Huawei
Chapin, SC 29036
USA
Phone:
Email: rstewart@huawei.com
Peter Lei
Cisco Systems, Inc.
8735 West Higgins Road
Suite 300
Chicago, IL 60631
USA
Phone:
Email: peterlei@cisco.com
Stewart, et al. Expires August 27, 2010 [Page 30]
Internet-Draft SCTP Stream Reconfiguration February 2010
Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
Stewart, et al. Expires August 27, 2010 [Page 31]