diff options
Diffstat (limited to 'doc/rfc/rfc6525.txt')
| -rw-r--r-- | doc/rfc/rfc6525.txt | 1907 |
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] + |