summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6525.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6525.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6525.txt')
-rw-r--r--doc/rfc/rfc6525.txt1907
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc6525.txt b/doc/rfc/rfc6525.txt
new file mode 100644
index 0000000..9f4125c
--- /dev/null
+++ b/doc/rfc/rfc6525.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Stewart
+Request for Comments: 6525 Adara Networks
+Category: Standards Track M. Tuexen
+ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
+ P. Lei
+ Cisco Systems, Inc.
+ February 2012
+
+
+ Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
+
+Abstract
+
+ Many applications that use the Stream Control Transmission Protocol
+ (SCTP) want the ability to "reset" a stream. The intention of
+ resetting a stream is to set the numbering sequence of the stream
+ back to 'zero' with a corresponding notification to the application
+ layer that the reset has been performed. Applications requiring this
+ feature want it so that they can "reuse" streams for different
+ purposes but still utilize the stream sequence number so that the
+ application can track the message flows. Thus, without this feature,
+ a new use of an old stream would result in message numbers greater
+ than expected, unless there is a protocol mechanism to "reset the
+ streams back to zero". This document also includes methods for
+ resetting the transmission sequence numbers, adding additional
+ streams, and resetting all stream sequence numbers.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6525.
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 1]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 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 Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions .....................................................4
+ 3. New Chunk Type ..................................................4
+ 3.1. RE-CONFIG Chunk ............................................5
+ 4. New Parameter Types .............................................6
+ 4.1. Outgoing SSN Reset Request Parameter .......................7
+ 4.2. Incoming SSN Reset Request Parameter .......................8
+ 4.3. SSN/TSN Reset Request Parameter ............................9
+ 4.4. Re-configuration Response Parameter .......................10
+ 4.5. Add Outgoing Streams Request Parameter ....................12
+ 4.6. Add Incoming Streams Request Parameter ....................13
+ 5. Procedures .....................................................14
+ 5.1. Sender-Side Procedures ....................................14
+ 5.1.1. Sender-Side Procedures for the RE-CONFIG Chunk .....14
+ 5.1.2. Sender-Side Procedures for the Outgoing SSN
+ Reset Request Parameter ............................15
+ 5.1.3. Sender-Side Procedures for the Incoming SSN
+ Reset Request Parameter ............................16
+ 5.1.4. Sender-Side Procedures for the SSN/TSN
+ Reset Request Parameter ............................17
+ 5.1.5. Sender-Side Procedures for the Add Outgoing
+ Streams Request Parameter ..........................17
+ 5.1.6. Sender-Side Procedures for the Add Incoming
+ Streams Request Parameter ..........................17
+ 5.1.7. Sender-Side Procedures for the
+ Re-configuration Response Parameter ................18
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 2]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ 5.2. Receiver-Side Procedures ..................................18
+ 5.2.1. Receiver-Side Procedures for the RE-CONFIG Chunk ...18
+ 5.2.2. Receiver-Side Procedures for the Outgoing
+ SSN Reset Request Parameter ........................19
+ 5.2.3. Receiver-Side Procedures for the Incoming
+ SSN Reset Request Parameter ........................20
+ 5.2.4. Receiver-Side Procedures for the SSN/TSN
+ Reset Request Parameter ............................21
+ 5.2.5. Receiver-Side Procedures for the Add
+ Outgoing Streams Request Parameter .................21
+ 5.2.6. Receiver-Side Procedures for the Add
+ Incoming Streams Request Parameter .................22
+ 5.2.7. Receiver-Side Procedures for the
+ Re-configuration Response Parameter ................22
+ 6. Sockets API Considerations .....................................23
+ 6.1. Events ....................................................23
+ 6.1.1. Stream Reset Event .................................24
+ 6.1.2. Association Reset Event ............................25
+ 6.1.3. Stream Change Event ................................26
+ 6.2. Event Subscription ........................................27
+ 6.3. Socket Options ............................................27
+ 6.3.1. Enable/Disable Stream Reset
+ (SCTP_ENABLE_STREAM_RESET) .........................28
+ 6.3.2. Reset Incoming and/or Outgoing Streams
+ (SCTP_RESET_STREAMS) ...............................29
+ 6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) ...................29
+ 6.3.4. Add Incoming and/or Outgoing Streams
+ (SCTP_ADD_STREAMS) .................................30
+ 7. Security Considerations ........................................30
+ 8. IANA Considerations ............................................31
+ 8.1. A New Chunk Type ..........................................31
+ 8.2. Six New Chunk Parameter Types .............................31
+ 9. Acknowledgments ................................................31
+ 10. References ....................................................32
+ 10.1. Normative References .....................................32
+ 10.2. Informative References ...................................32
+ Appendix A. Examples of the Reconfiguration Procedures ............33
+
+1. Introduction
+
+ Many applications that use SCTP as defined in [RFC4960] want the
+ ability to "reset" a stream. The intention of resetting a stream is
+ to set the Stream Sequence Numbers (SSNs) of the stream back to
+ 'zero' with a corresponding notification to the application layer
+ that the reset has been performed. Applications requiring this
+ feature want to "reuse" streams for different purposes but still
+ utilize the SSN so that the application can track the message flows.
+ Thus, without this feature, a new use of an old stream would result
+
+
+
+Stewart, et al. Standards Track [Page 3]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ in message numbers greater than expected, unless there is a protocol
+ mechanism to "reset the streams back to zero". This document also
+ includes methods for resetting the Transmission Sequence Numbers
+ (TSNs), adding additional streams, and resetting all SSNs.
+
+ The sockets API for SCTP defined in [RFC6458] exposes the sequence
+ numbers used by SCTP for user message transfer. Therefore, resetting
+ them can be used by application writers. Please note that the
+ corresponding sequence number for TCP is not exposed via the sockets
+ API for TCP.
+
+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
+ reconfigure streams. Table 1 illustrates the new chunk type.
+
+ +------------+------------------------------------+
+ | Chunk Type | Chunk Name |
+ +------------+------------------------------------+
+ | 130 | Re-configuration Chunk (RE-CONFIG) |
+ +------------+------------------------------------+
+
+ Table 1
+
+ It should be noted that the format of the RE-CONFIG chunk requires
+ that the receiver 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 4]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+3.1. RE-CONFIG 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 = 130 | Chunk Flags | Chunk Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ \ \
+ / Re-configuration Parameter /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ \ \
+ / Re-configuration Parameter (optional) /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Chunk Type: 1 byte (unsigned integer)
+ This field holds the IANA-defined chunk type for the RE-CONFIG
+ chunk. The value of this field is 130.
+
+ 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 in bytes, including the
+ Chunk Type, Chunk Flags, and Chunk Length.
+
+ Re-configuration Parameter
+ This field holds a Re-configuration Request Parameter or a
+ Re-configuration Response Parameter.
+
+ Note that each RE-CONFIG 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.
+
+
+
+
+Stewart, et al. Standards Track [Page 5]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ 6. Add Incoming Streams Request Parameter.
+
+ 7. Add Outgoing Streams Request Parameter, Add Incoming Streams
+ Request Parameter.
+
+ 8. Re-configuration Response Parameter.
+
+ 9. Re-configuration Response Parameter, Outgoing SSN Reset Request
+ Parameter.
+
+ 10. Re-configuration Response Parameter, Re-configuration Response
+ Parameter.
+
+ If a sender transmits an unsupported combination, the receiver SHOULD
+ send an ERROR chunk with a Protocol Violation cause, as defined in
+ Section 3.3.10.13 of [RFC4960]).
+
+4. New Parameter Types
+
+ This section defines the new parameter types that will be used in the
+ RE-CONFIG chunk. Table 2 illustrates the new parameter types.
+
+ +----------------+----------------------------------------+
+ | Parameter Type | Parameter Name |
+ +----------------+----------------------------------------+
+ | 13 | Outgoing SSN Reset Request Parameter |
+ | 14 | Incoming SSN Reset Request Parameter |
+ | 15 | SSN/TSN Reset Request Parameter |
+ | 16 | Re-configuration Response Parameter |
+ | 17 | Add Outgoing Streams Request Parameter |
+ | 18 | Add Incoming Streams Request Parameter |
+ +----------------+----------------------------------------+
+
+ Table 2
+
+ It should be noted that the parameter format requires that the
+ receiver stop processing the parameter and not 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.
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 6]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+4.1. Outgoing SSN Reset Request Parameter
+
+ This parameter is used by the sender to request the reset of some or
+ all outgoing streams.
+
+ 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 = 13 | Parameter Length = 16 + 2 * N |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Re-configuration Request Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Re-configuration Response Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sender's 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 the Outgoing
+ SSN Reset Request Parameter. The value of this field is 13.
+
+ Parameter Length: 2 bytes (unsigned integer)
+ This field holds the length in bytes of the parameter; the value
+ MUST be 16 + 2 * N, where N is the number of stream numbers
+ listed.
+
+ Re-configuration 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. It is increased by 1 whenever sending a new Re-
+ configuration Request Parameter.
+
+ Re-configuration Response Sequence Number: 4 bytes (unsigned
+ integer)
+ When 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. This field then
+ holds the Re-configuration Request Sequence Number of the incoming
+ request. In other cases, it holds the next expected
+ Re-configuration Request Sequence Number minus 1.
+
+
+
+
+
+Stewart, et al. Standards Track [Page 7]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ Sender's 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 1..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 RE-CONFIG 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 reset
+ some or all of its outgoing streams.
+
+ 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 = 14 | Parameter Length = 8 + 2 * N |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Re-configuration 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 the Incoming
+ SSN Reset Request Parameter. The value of this field is 14.
+
+ Parameter Length: 2 bytes (unsigned integer)
+ This field holds the length in bytes of the parameter; the value
+ MUST be 8 + 2 * N.
+
+ Re-configuration 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. It is increased by 1 whenever sending a new Re-
+ configuration Request Parameter.
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 8]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ Stream Number 1..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 RE-CONFIG 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 a reset of the TSN
+ and SSN numbering of all incoming and outgoing streams.
+
+ 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 = 15 | Parameter Length = 8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Re-configuration Request Sequence Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Parameter Type: 2 bytes (unsigned integer)
+ This field holds the IANA-defined parameter type for the SSN/TSN
+ Reset Request Parameter. The value of this field is 15.
+
+ Parameter Length: 2 bytes (unsigned integer)
+ This field holds the length in bytes of the parameter; the value
+ MUST be 8.
+
+ Re-configuration 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. It is increased by 1 whenever sending a new Re-
+ configuration Request Parameter.
+
+ This parameter can appear in a RE-CONFIG chunk. This parameter MUST
+ NOT appear in any other chunk type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 9]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+4.4. Re-configuration Response Parameter
+
+ This parameter is used by the receiver of a Re-configuration Request
+ Parameter to respond to the 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 = 16 | Parameter Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Re-configuration 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 the
+ Re-configuration Response Parameter. The value of this field
+ is 16.
+
+ Parameter Type Length: 2 bytes (unsigned integer)
+ This field holds the length in bytes of the parameter; the value
+ MUST be 12 if the optional fields are not present and 20
+ otherwise.
+
+ Re-configuration Response Sequence Number: 4 bytes (unsigned
+ integer)
+ This value is copied from the request parameter and is used by the
+ receiver of the Re-configuration Response Parameter to tie the
+ response to the request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 10]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ Result: 4 bytes (unsigned integer)
+ This value describes the result of the processing of the request.
+ It is encoded as indicated in Table 3:
+
+ +--------+-------------------------------------+
+ | Result | Description |
+ +--------+-------------------------------------+
+ | 0 | Success - Nothing to do |
+ | 1 | Success - Performed |
+ | 2 | Denied |
+ | 3 | Error - Wrong SSN |
+ | 4 | Error - Request already in progress |
+ | 5 | Error - Bad Sequence Number |
+ | 6 | In progress |
+ +--------+-------------------------------------+
+
+ Table 3
+
+ Sender's Next TSN: 4 bytes (unsigned integer)
+ This field holds the TSN that 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 that 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.
+
+ Either both optional fields (Sender's Next TSN and Receiver's Next
+ TSN) MUST be present, or no field.
+
+ This parameter can appear in a RE-CONFIG chunk. This parameter MUST
+ NOT appear in any other chunk type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 11]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+4.5. Add Outgoing Streams Request Parameter
+
+ This parameter is used by the sender to request that an additional
+ number of outgoing streams (i.e., the receiver's incoming streams) be
+ added to the association.
+
+ 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 = 17 | Parameter Length = 12 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Re-configuration 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
+ Outgoing Streams Request Parameter. The value of this field
+ is 17.
+
+ Parameter Length: 2 bytes (unsigned integer)
+ This field holds the length in bytes of the parameter; the value
+ MUST be 12.
+
+ Re-configuration 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. It is increased by 1 whenever sending a new Re-
+ configuration Request Parameter.
+
+ Number of new streams: 2 bytes (unsigned integer)
+ This value holds the number of additional outgoing streams that
+ the sender requests be added to the association. Streams are
+ added in order and are consecutive; e.g., if an association has 4
+ outgoing streams (0-3) and a request 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 MAY appear in a RE-CONFIG chunk. This parameter MUST
+ NOT appear in any other chunk type.
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 12]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+4.6. Add Incoming Streams Request Parameter
+
+ This parameter is used by the sender to request that the peer add an
+ additional number of outgoing streams (i.e., the sender's incoming
+ streams) to the association.
+
+ 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 = 18 | Parameter Length = 12 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Re-configuration 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
+ Incoming Streams Request Parameter. The value of this field
+ is 18.
+
+ Parameter Length: 2 bytes (unsigned integer)
+ This field holds the length in bytes of the parameter; the value
+ MUST be 12.
+
+ Re-configuration 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. It is increased by 1 whenever sending a new Re-
+ configuration Request Parameter.
+
+ Number of new streams: 2 bytes (unsigned integer)
+ This value holds the number of additional incoming streams that
+ the sender requests be added to the association. Streams are
+ added in order and are consecutive; e.g., if an association has 4
+ outgoing streams (0-3) and a request 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 MAY appear in a RE-CONFIG chunk. This parameter MUST
+ NOT appear in any other chunk type.
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 13]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+5. Procedures
+
+ This section defines the procedures used by both the sender and
+ receiver of a RE-CONFIG chunk. Various examples of re-configuration
+ scenarios are given in Appendix A.
+
+ One important thing to remember about SCTP streams is that they are
+ uni-directional and there is no correspondence between outgoing and
+ incoming streams. The procedures outlined in this section are
+ designed so that the incoming side will always reset its SSN first
+ (before the outgoing side), which means the re-configuration request
+ must always originate from the outgoing side. These two issues have
+ important ramifications upon how an SCTP endpoint might request that
+ its incoming streams be reset. In effect, it must ask the peer to
+ start an outgoing reset procedure and once that request is
+ acknowledged let the peer actually control the reset operation.
+
+5.1. Sender-Side Procedures
+
+ This section describes the procedures related to the sending of
+ RE-CONFIG chunks. A RE-CONFIG chunk is composed of one or two Type-
+ Length-Value (TLV) parameters.
+
+5.1.1. Sender-Side Procedures for the RE-CONFIG Chunk
+
+ The SCTP protocol extension described in this document uses the
+ Supported Extensions Parameter defined in [RFC5061] for negotiating
+ the support.
+
+ An SCTP endpoint supporting this extension MUST include the chunk
+ type of the RE-CONFIG chunk in the Supported Extensions Parameter in
+ either the INIT or INIT-ACK. Before sending a RE-CONFIG chunk, the
+ sender MUST ensure that the peer advertised support for the
+ re-configuration extension. If the chunk type of the RE-CONFIG chunk
+ does not appear in the supported extension's list of chunks, then the
+ sender MUST NOT send any re-configuration request to the peer, and
+ any request by the application for such service SHOULD be responded
+ to with an appropriate error indicating that the peer SCTP stack does
+ not support the re-configuration extension.
+
+ At any given time, there MUST NOT be more than one request in flight.
+ So, if the Re-configuration Timer is running and the RE-CONFIG chunk
+ contains at least one request parameter, the chunk MUST be buffered.
+
+ After packaging the RE-CONFIG chunk and sending it to the peer, the
+ sender MUST start the Re-configuration Timer if the RE-CONFIG chunk
+ contains at least one request parameter. If it contains no request
+ parameters, the Re-configuration Timer MUST NOT be started. This
+
+
+
+Stewart, et al. Standards Track [Page 14]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ timer MUST use the same value as SCTP's data transmission timer
+ (i.e., the retransmission timeout (RTO) timer) and MUST use
+ exponential backoff, doubling the value at every expiration. If the
+ timer expires, besides doubling the value, the sender MUST retransmit
+ the RE-CONFIG chunk, increment the appropriate error counts (for both
+ the association and the destination), and perform threshold
+ management, possibly destroying the association if SCTP
+ retransmission thresholds are exceeded.
+
+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,
+ provided that the Re-configuration 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 for the affected streams and queue
+ it. This is because it is not known whether the receiver of the
+ request will accept or deny it; moreover, 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 re-configuration request
+ sequence number and MUST put it into the Re-configuration
+ Request Sequence Number field of the Outgoing SSN Reset Request
+ Parameter. The next re-configuration request sequence number
+ MUST then be incremented by 1.
+
+ A3: The Sender's Last Assigned TSN MUST be set to the next TSN the
+ sender assigns minus 1.
+
+ A4: If this Outgoing SSN Reset Request Parameter is sent in response
+ to an Incoming SSN Reset Request Parameter, the stream numbers
+ MUST be copied from the Incoming SSN Reset Request Parameter to
+ the Outgoing SSN Reset Request Parameter. The Re-configuration
+ Response Sequence Number of the Outgoing SSN Reset Request
+ Parameter MUST be the Re-configuration Request Sequence Number
+ of the Incoming SSN Reset Request Parameter. If this Outgoing
+ SSN Reset Request Parameter is sent at the request of the upper
+ layer and the sender requests that all outgoing streams be
+ reset, stream numbers SHOULD NOT be put into the Outgoing SSN
+ Reset Request Parameter. If the sender requests that only some
+ outgoing streams be reset, these stream numbers MUST be placed
+ in the Outgoing SSN Reset Request Parameter. The
+ Re-configuration Response Sequence Number is the next expected
+ Re-configuration Request Sequence Number of the peer minus 1.
+
+
+
+Stewart, et al. Standards Track [Page 15]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ A5: The Outgoing SSN Reset Request Parameter MUST be put into a
+ RE-CONFIG Chunk. The Outgoing SSN Reset Request Parameter MAY
+ be put together with either an Incoming SSN Reset Request
+ Parameter or a Re-configuration Response Parameter, but not with
+ both. It MUST NOT be put together with any other parameter, as
+ described in Section 3.1.
+
+ A6: The RE-CONFIG chunk MUST be 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,
+ provided that the Re-configuration Timer is not running. The
+ following steps must be followed:
+
+ B1: The sender MUST assign the next re-configuration request
+ sequence number and MUST put it into the Re-configuration
+ Request Sequence Number field of the Incoming SSN Reset Request
+ Parameter. After assigning it, the next re-configuration
+ request sequence number MUST be incremented by 1.
+
+ B2: If the sender wants all incoming streams to be reset, stream
+ numbers SHOULD NOT 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 MUST be put into a
+ RE-CONFIG Chunk. It MAY be put together with an Outgoing SSN
+ Reset Request Parameter but MUST NOT be put together with any
+ other parameter.
+
+ B4: The RE-CONFIG chunk MUST be sent following the rules given in
+ Section 5.1.1.
+
+ When sending an Incoming SSN Reset Request, there is a potential that
+ the peer has just reset or is in the process of resetting the same
+ streams via an Outgoing SSN Reset Request. This collision scenario
+ is discussed in Section 5.2.3.
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 16]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+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 an
+ SSN/TSN Reset Request Parameter, provided that the Re-configuration
+ Timer is not running. The following steps must be followed:
+
+ C1: The sender MUST assign the next re-configuration request
+ sequence number and put it into the Re-configuration Request
+ Sequence Number field of the SSN/TSN Reset Request Parameter.
+ After assigning it, the next re-configuration request sequence
+ number MUST be incremented by 1.
+
+ C2: The sender has either no outstanding TSNs or considers all
+ outstanding TSNs abandoned. 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 MUST be put into a RE-CONFIG
+ chunk. There MUST NOT be any other parameter in this chunk.
+
+ C4: The RE-CONFIG chunk MUST be sent following the rules given in
+ Section 5.1.1.
+
+ Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds,
+ which is considered a maximum segment lifetime (the IP MSL).
+
+5.1.5. Sender-Side Procedures for the Add Outgoing Streams Request
+ Parameter
+
+ When an SCTP sender wants to increase the number of outbound streams
+ to which it is able to send, it may add an Add Outgoing Streams
+ Request Parameter to the RE-CONFIG 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 streams with no gaps.
+ This means that if a request is made to add 2 streams to an
+ association that already has 5 (0-4), then the new streams, upon
+ successful completion, are streams 5 and 6. A new stream MUST use
+ SSN 0 for its first ordered message.
+
+5.1.6. Sender-Side Procedures for the Add Incoming Streams Request
+ Parameter
+
+ When an SCTP sender wants to increase the number of inbound streams
+ to which the peer is able to send, it may add an Add Incoming Streams
+ Request Parameter to the RE-CONFIG chunk. Note that new streams are
+ added adjacent to the previous streams with no gaps. This means that
+
+
+
+Stewart, et al. Standards Track [Page 17]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ if a request is made to add 2 streams to an association that already
+ has 5 (0-4), then the new streams, upon successful completion, are
+ streams 5 and 6. A new stream MUST use SSN 0 for its first ordered
+ message.
+
+5.1.7. Sender-Side Procedures for the Re-configuration Response
+ Parameter
+
+ When an implementation receives a reset request parameter, it must
+ respond with a Re-configuration Response Parameter in the following
+ manner:
+
+ D1: The Re-configuration Request Sequence number of the incoming
+ request MUST be copied to the Re-configuration Response Sequence
+ Number field of the Re-configuration Response Parameter.
+
+ D2: The result of the processing of the incoming request according
+ to Table 3 MUST be placed in the Result field of the
+ Re-configuration Response Parameter.
+
+ D3: If the incoming request is an SSN/TSN reset request, the
+ Sender's Next TSN field MUST be filled with the next TSN the
+ sender of this Re-configuration Response Parameter will assign.
+ For other requests, the Sender's Next TSN field, which is
+ optional, MUST NOT be used.
+
+ D4: If the incoming request is an SSN/TSN reset request, the
+ Receiver's Next TSN field MUST be filled with a TSN such that
+ the sender of the Re-configuration Response Parameter can be
+ sure it can discard received DATA chunks with smaller TSNs. The
+ value SHOULD be the smallest TSN not acknowledged by the
+ receiver of the request plus 2^31. For other requests, the
+ Receiver's Next TSN field, which is optional, MUST NOT be used.
+
+5.2. Receiver-Side Procedures
+
+5.2.1. Receiver-Side Procedures for the RE-CONFIG Chunk
+
+ Upon reception of a RE-CONFIG chunk, each parameter within it SHOULD
+ be processed. If multiple parameters have to be returned, they MUST
+ be put into one RE_CONFIG chunk. If the received RE-CONFIG chunk
+ contains at least one request parameter, a selective acknowledgment
+ (SACK) chunk SHOULD be sent back and MAY be bundled with the
+ RE-CONFIG chunk. If the received RE-CONFIG chunk contains at least
+ one request and based on the analysis of the Re-configuration Request
+ Sequence Numbers this is the last received RE-CONFIG chunk (i.e., a
+ retransmission), the same RE-CONFIG chunk MUST to be sent back in
+ response, as it was earlier.
+
+
+
+Stewart, et al. Standards Track [Page 18]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ The decision to deny a re-configuration request is an administrative
+ 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.7, with an appropriate Result
+ field.
+
+ Implementation Note: It is recommended that a SACK be bundled with
+ any re-configuration 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 re-configuration 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 must be followed:
+
+ E1: If the Re-configuration Timer is running for the
+ Re-configuration Request Sequence Number indicated in the
+ Re-configuration Response Sequence Number field, the
+ Re-configuration Request Sequence Number MUST be marked as
+ acknowledged. If all Re-configuration Request Sequence Numbers
+ for which the Re-configuration Timer is running are
+ acknowledged, the Re-configuration Timer MUST be stopped.
+
+ E2: If the Sender's Last Assigned TSN is greater than the cumulative
+ acknowledgment point, then the endpoint MUST enter "deferred
+ reset processing". In this mode, any data arriving with a TSN
+ larger than the Sender's Last Assigned TSN for the affected
+ stream(s) MUST be queued locally and held until the cumulative
+ acknowledgment point reaches the Sender's Last Assigned TSN.
+ When the cumulative acknowledgment point reaches the last
+ assigned TSN, then proceed to the next step. If the endpoint
+ enters "deferred reset processing", it MUST put a Re-
+ configuration Response Parameter into a RE-CONFIG chunk
+ indicating "In progress" and MUST send the RE-CONFIG chunk.
+
+ E3: If no stream numbers are listed in the parameter, then all
+ incoming streams MUST be reset to 0 as the next expected SSN.
+ If specific stream numbers are listed, then only these specific
+ streams MUST be reset to 0, and all other non-listed SSNs remain
+ unchanged.
+
+ E4: Any queued TSNs (queued at step E2) MUST now be released and
+ processed normally.
+
+
+
+Stewart, et al. Standards Track [Page 19]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ E5: A Re-configuration Response Parameter MUST be put into a
+ RE-CONFIG chunk indicating successful processing.
+
+ E6: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG
+ 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 must be followed:
+
+ F1: An Outgoing SSN Reset Request Parameter MUST be put into a
+ RE-CONFIG chunk according to Section 5.1.2.
+
+ F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG
+ chunk is processed completely.
+
+ When a peer endpoint requests an Incoming SSN Reset Request, it is
+ possible that the local endpoint has just sent an Outgoing SSN Reset
+ Request on the same association and has not yet received a response.
+ In such a case, the local endpoint MUST do the following:
+
+ o If the Outgoing SSN Reset Request Parameter that was just sent
+ completely overlaps the received Incoming SSN Reset Request
+ Parameter, respond to the peer with an acknowledgment indicating
+ that there was "Nothing to do".
+
+ o Otherwise, process the Incoming SSN Reset Request Parameter
+ normally, responding to the peer with an acknowledgment. Note
+ that this case includes the situation where some of the streams
+ requested overlap with the Outgoing SSN Reset Request that was
+ just sent. Even in such a situation, the Incoming SSN Reset MUST
+ be processed normally, even though this means that (if the
+ endpoint elects to do the stream reset) streams that are already
+ at SSN 0 will be reset a subsequent time.
+
+ It is also possible that the Incoming request will arrive after the
+ Outgoing SSN Reset Request just completed. In such a case, all of
+ the streams being requested will be already set to 0. If so, the
+ local endpoint SHOULD send back a Re-configuration Response with the
+ success code "Nothing to do".
+
+ Note that in either race condition, the local endpoint could
+ optionally also perform the reset. This would result in streams that
+ are already at sequence 0 being reset again to 0, which would cause
+ no harm to the application but will add an extra message to the
+ network.
+
+
+
+Stewart, et al. Standards Track [Page 20]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+5.2.4. Receiver-Side Procedures for the SSN/TSN Reset Request Parameter
+
+ In the case that the endpoint is willing to perform an SSN/TSN reset,
+ the following steps must be followed:
+
+ G1: Compute an appropriate value for the Receiver's Next TSN -- the
+ TSN that 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 endpoint's next TSN,
+ i.e., the next TSN assigned by the receiver of the SSN/TSN reset
+ chunk. The value SHOULD be the highest TSN sent by the receiver
+ of the request plus 1.
+
+ G3: The same processing as though a SACK chunk with no gap report
+ and a cumulative TSN ACK of the Sender's Next TSN minus 1 were
+ received MUST be performed.
+
+ G4: The same processing as though a FWD-TSN chunk (as defined in
+ [RFC3758]) with all streams affected and a new cumulative TSN
+ ACK of the Receiver's Next TSN minus 1 were received MUST be
+ performed.
+
+ G5: The next expected and outgoing SSNs MUST be reset to 0 for all
+ incoming and outgoing streams.
+
+ G6: A Re-configuration Response Parameter MUST be put into a
+ RE-CONFIG chunk indicating successful processing.
+
+ G7: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG
+ chunk is processed completely.
+
+5.2.5. Receiver-Side Procedures for the Add Outgoing Streams Request
+ Parameter
+
+ When an SCTP endpoint receives a re-configuration request adding
+ additional streams, it MUST send a response parameter either
+ acknowledging or denying the request. If the response is successful,
+ the receiver MUST add the requested number of inbound streams to the
+ association, initializing the next expected SSN to 0. The SCTP
+ endpoint SHOULD deny the request if the number of streams exceeds a
+ limit that should be configurable by the application.
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 21]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+5.2.6. Receiver-Side Procedures for the Add Incoming Streams Request
+ Parameter
+
+ When an SCTP endpoint receives a re-configuration request adding
+ additional incoming streams, it MUST either send a response parameter
+ denying the request or send a corresponding Add Outgoing Streams
+ Request Parameter, following the rules given in Section 5.1.5. The
+ SCTP endpoint SHOULD deny the request if the number of streams
+ exceeds a limit that should be configurable by the application.
+
+5.2.7. Receiver-Side Procedures for the Re-configuration Response
+ Parameter
+
+ On receipt of a Re-configuration Response Parameter, the following
+ must be performed:
+
+ H1: If the Re-configuration Timer is running for the Re-
+ configuration Request Sequence Number indicated in the Re-
+ configuration Response Sequence Number field, the
+ Re-configuration Request Sequence Number MUST be marked as
+ acknowledged. If all Re-configuration Request Sequence Numbers
+ for which the Re-configuration Timer is running are
+ acknowledged, the Re-configuration Timer MUST be stopped. If
+ the timer was not running for the Re-configuration Request
+ Sequence Number, the processing of the Re-configuration Response
+ Parameter is complete.
+
+ H2: If the Result field indicates "In progress", the timer for the
+ Re-configuration Request Sequence Number is started again. If
+ the timer runs out, the RE-CONFIG chunk MUST be retransmitted
+ but the corresponding error counters MUST NOT be incremented.
+
+ H3: If the Result field does not indicate successful processing, the
+ processing of this response is complete.
+
+ H4: If the request was an Outgoing SSN Reset Request, the affected
+ streams MUST now be reset and all queued data should now be
+ processed. The assigning of SSNs is allowed again.
+
+ H5: If the request was an SSN/TSN Reset Request, new data MUST be
+ sent from the Receiver's Next TSN, beginning with SSN 0 for all
+ outgoing streams. All incoming streams MUST be reset to 0 as
+ the next expected SSN. The peer will send DATA chunks starting
+ with the Sender's Next TSN.
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 22]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ H6: If the request was to add outgoing streams, the endpoint MUST
+ 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.
+
+6. Sockets API Considerations
+
+ This section describes how the sockets API defined in [RFC6458] needs
+ to be extended to make the features of SCTP re-configuration
+ available to the application.
+
+ Please note that this section is informational only.
+
+6.1. Events
+
+ When the SCTP_ASSOC_CHANGE notification is delivered and both peers
+ support the extension described in this document,
+ SCTP_ASSOC_SUPPORTS_RE_CONFIG should be listed in the sac_info field.
+
+ The union sctp_notification {} is extended to contain three new
+ fields: sn_strreset_event, sn_assocreset_event, and
+ sn_strchange_event:
+
+ union sctp_notification {
+ struct sctp_tlv {
+ uint16_t sn_type; /* Notification 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
+
+
+
+Stewart, et al. Standards Track [Page 23]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ These events are delivered when an incoming request was processed
+ successfully or the processing of an outgoing request has been
+ finished.
+
+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: This field 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 stream identifiers given in
+ strreset_stream_list[] refer to incoming streams of the
+ endpoint.
+
+ SCTP_STREAM_RESET_OUTGOING_SSN: The stream identifiers given in
+ strreset_stream_list[] refer 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 is set. SCTP_STREAM_RESET_DENIED
+ and SCTP_STREAM_RESET_FAILED are mutually exclusive. If the
+ request was successful, none of these are set.
+
+ strreset_length: This field is the total length in bytes of the
+ delivered event, including the header.
+
+ strreset_assoc_id: This 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
+ sockets, this field is ignored.
+
+
+
+
+
+Stewart, et al. Standards Track [Page 24]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ strreset_stream_list: This is the list of stream identifiers to
+ which this event refers. An empty list identifies all streams as
+ being reset. Depending on strreset_flags, the identifiers refer
+ to incoming or outgoing streams, or both.
+
+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: This field 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 mutually
+ exclusive. If the request was successful, none of these are set.
+
+ assocreset_length: This field is the total length in bytes of the
+ delivered event, including the header.
+
+ assocreset_assoc_id: This 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
+ sockets, this field is ignored.
+
+ assocreset_local_tsn: This field is the next TSN used by the
+ endpoint.
+
+ assocreset_remote_tsn: This field is the next TSN used by the peer.
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 25]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+6.1.3. Stream Change Event
+
+ The event delivered has the following structure:
+
+ 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: This field 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
+ mutually exclusive. If the request was successful, none of these
+ are set.
+
+ strchange_length: This field is the total length in bytes of the
+ delivered event, including the header.
+
+ strchange_assoc_id: This 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
+ sockets, 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.
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 26]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+6.2. Event Subscription
+
+ Subscribing to events as described in [RFC6458] uses a setsockopt()
+ call with the SCTP_EVENT socket option. This option takes the
+ following structure, which specifies the association, the event type
+ (using the same value found in the event type field), and an on/off
+ boolean.
+
+ struct sctp_event {
+ sctp_assoc_t se_assoc_id;
+ uint16_t se_type;
+ uint8_t se_on;
+ };
+
+ The user fills in the se_type field with the same value found in the
+ 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 [RFC6458]. 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
+
+ Table 5 describes the new socket options that make the
+ re-configuration features accessible to the user. They all use
+ IPPROTO_SCTP as their level.
+
+ If a call to setsockopt() is used to issue a re-configuration request
+ while the Re-configuration timer is running, setsockopt() will return
+ -1, and error is set to EALREADY.
+
+ +--------------------------+---------------------------+-----+-----+
+ | 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_STREAMS | struct sctp_add_streams | | X |
+ +--------------------------+---------------------------+-----+-----+
+
+ Table 5
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 27]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+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 to deny all 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: This field is formed from the bitwise OR of one or more
+ of the following currently defined flags:
+
+ SCTP_ENABLE_RESET_STREAM_REQ: Process received Incoming/Outgoing
+ SSN Reset Requests if this flag is set; deny them if not.
+
+ SCTP_ENABLE_RESET_ASSOC_REQ: Process received SSN/TSN Reset
+ Requests if this flag is set; deny them if not.
+
+ SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing
+ Streams Requests if this flag is set; deny them if not.
+
+ The default value is !(SCTP_ENABLE_RESET_STREAM_REQ|
+ SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ).
+
+ Please note that using the option does not have any impact on
+ subscribing to any related events.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 28]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS)
+
+ This option allows the user to request the reset of 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 is 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 the operation is performed upon. 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 of 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 the association the action is to be performed upon.
+
+
+
+
+
+Stewart, et al. Standards Track [Page 29]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+6.3.4. Add Incoming and/or Outgoing Streams (SCTP_ADD_STREAMS)
+
+ This option allows a user to request the addition of a number of
+ incoming and/or outgoing streams.
+
+ To set this option, the user fills in the following structure:
+
+ struct sctp_add_streams {
+ sctp_assoc_t sas_assoc_id;
+ uint16_t sas_instrms;
+ uint16_t sas_outstrms;
+ };
+
+ sas_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.
+
+ sas_instrms: This parameter is the number of incoming streams
+ to add.
+
+ sas_outstrms: This parameter is the number of outgoing streams
+ to add.
+
+ An endpoint can limit the number of incoming and outgoing streams by
+ using the sinit_max_instreams field in the struct sctp_initmsg{} when
+ issuing an SCTP_INIT socket option, as defined in [RFC6458]. An
+ incoming request asking for more streams than allowed will be denied.
+
+7. Security Considerations
+
+ The SCTP sockets API as described in [RFC6458] exposes the sequence
+ numbers of received DATA chunks to the application. An application
+ might expect them to be monotonically increasing. When using the
+ re-configuration extension, this might no longer be true. Therefore,
+ the applications must enable this extension explicitly before it is
+ used. In addition, applications must subscribe explicitly to
+ notifications related to the re-configuration extension before
+ receiving them.
+
+ SCTP associations are protected against blind attackers by using
+ verification tags. This is still valid when using the
+ re-configuration extension. Therefore, this extension does not add
+ any additional security risk to SCTP in relation to blind attackers.
+
+ When both the SSN and TSN are reset, the maximum segment lifetime is
+ used to avoid TSN wrap-around.
+
+
+
+
+
+Stewart, et al. Standards Track [Page 30]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+8. IANA Considerations
+
+ This document (RFC 6525) is the reference for all registrations
+ described in this section. The changes are described below.
+
+8.1. A New Chunk Type
+
+ A chunk type has been assigned by IANA. The values given in Table 1
+ have been used. IANA has assigned this value from the pool of chunks
+ with the upper two bits set to '10'.
+
+ This has added a line in the "Chunk Types" registry for SCTP:
+
+ Chunk Types
+
+ ID Value Chunk Type Reference
+ ----- ---------- ---------
+ 130 Re-configuration Chunk (RE-CONFIG) [RFC6525]
+
+ The registration table as defined in [RFC6096] for the chunk flags of
+ this chunk type is empty.
+
+8.2. Six New Chunk Parameter Types
+
+ Six chunk parameter types have been assigned by IANA. It the values
+ given in Table 2 have been used. IANA has assigned these values from
+ the pool of parameters with the upper two bits set to '00'.
+
+ Six additional lines in the "Chunk Parameter Types" registry for SCTP
+ have been added:
+
+ Chunk Parameter Types
+
+ ID Value Chunk Parameter Type Reference
+ -------- ------------------------------------------------ ---------
+ 13 Outgoing SSN Reset Request Parameter [RFC6525]
+ 14 Incoming SSN Reset Request Parameter [RFC6525]
+ 15 SSN/TSN Reset Request Parameter [RFC6525]
+ 16 Re-configuration Response Parameter [RFC6525]
+ 17 Add Outgoing Streams Request Parameter [RFC6525]
+ 18 Add Incoming Streams Request Parameter [RFC6525]
+
+9. Acknowledgments
+
+ The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch,
+ Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and
+ Vlad Yasevich for their invaluable comments.
+
+
+
+
+Stewart, et al. Standards Track [Page 31]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+ Conrad, "Stream Control Transmission Protocol (SCTP)
+ Partial Reliability Extension", RFC 3758, May 2004.
+
+ [RFC4960] Stewart, R., Ed., "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.
+
+ [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission
+ Protocol (SCTP) Chunk Flags Registration", RFC 6096,
+ January 2011.
+
+10.2. Informative References
+
+ [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
+ Yasevich, "Sockets API Extensions for the Stream Control
+ Transmission Protocol (SCTP)", RFC 6458, December 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 32]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+Appendix A. Examples of the Reconfiguration Procedures
+
+ Please note that this appendix is informational only.
+
+ The following message flows between Endpoints E-A and E-Z illustrate
+ the described procedures. The time progresses in downward direction.
+
+ The following example illustrates E-A resetting streams 1 and 2 for
+ just its outgoing streams.
+
+ E-A E-Z
+ ----------[RE-CONFIG(OUT-REQ:X/1,2)]---------->
+ <-------------[RE-CONFIG(RESP:X)]--------------
+
+ The following example illustrates E-A resetting streams 1 and 2 for
+ just its incoming streams.
+
+ E-A E-Z
+ -----------[RE-CONFIG(IN-REQ:X/1,2)]---------->
+ <--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]----------
+ -------------[RE-CONFIG(RESP:Y)]-------------->
+
+ The following example illustrates E-A resetting all streams in both
+ directions.
+
+ E-A E-Z
+ -----[RE-CONFIG(OUT-REQ:X,Y-1|IN-REQ:X+1)]---->
+ <------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]-------
+ -------------[RE-CONFIG(RESP:Y)]-------------->
+
+ The following example illustrates E-A requesting that the streams and
+ TSNs be reset. At 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
+ ------------[RE-CONFIG(TSN-REQ:X)]------------>
+ <-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]-----
+
+ The following example illustrates E-A requesting the addition of 3
+ outgoing streams.
+
+ E-A E-Z
+ --------[RE-CONFIG(ADD_OUT_STRMS:X/3)]-------->
+ <-------------[RE-CONFIG(RESP:X)]--------------
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 33]
+
+RFC 6525 SCTP Stream Reconfiguration February 2012
+
+
+ The following example illustrates E-A requesting the addition of 3
+ incoming streams.
+
+ E-A E-Z
+ ---------[RE-CONFIG(ADD_IN_STRMS:X/3)]-------->
+ <----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y,X/3)]------
+ -------------[RE-CONFIG(RESP:Y)]-------------->
+
+Authors' Addresses
+
+ Randall R. Stewart
+ Adara Networks
+ Chapin, SC 29036
+ USA
+
+ EMail: randall@lakerest.net
+
+
+ Michael Tuexen
+ Muenster University of Applied Sciences
+ Stegerwaldstr. 39
+ 48565 Steinfurt
+ DE
+
+ EMail: tuexen@fh-muenster.de
+
+
+ Peter Lei
+ Cisco Systems, Inc.
+ 9501 Technology Blvd.
+ West Office Center
+ Rosemont, IL 60018
+ USA
+
+ EMail: peterlei@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Standards Track [Page 34]
+