draft-ietf-tsvwg-sctp-strrst-13.txt   rfc6525.txt 
Network Working Group R. Stewart Internet Engineering Task Force (IETF) R. Stewart
Internet-Draft Adara Networks Request for Comments: 6525 Adara Networks
Intended status: Standards Track M. Tuexen Category: Standards Track M. Tuexen
Expires: June 10, 2012 Muenster Univ. of Appl. Sciences ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
P. Lei P. Lei
Cisco Systems, Inc. Cisco Systems, Inc.
December 8, 2011 February 2012
Stream Control Transmission Protocol (SCTP) Stream Reconfiguration Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
draft-ietf-tsvwg-sctp-strrst-13.txt
Abstract Abstract
Many applications that use SCTP want the ability to "reset" a stream. Many applications that use the Stream Control Transmission Protocol
The intention of resetting a stream is to set the numbering sequence (SCTP) want the ability to "reset" a stream. The intention of
of the stream back to 'zero' with a corresponding notification to the resetting a stream is to set the numbering sequence of the stream
application layer that the reset has been performed. Applications back to 'zero' with a corresponding notification to the application
requiring this feature want it so that they can "re-use" streams for layer that the reset has been performed. Applications requiring this
different purposes but still utilize the stream sequence number so feature want it so that they can "reuse" streams for different
that the application can track the message flows. Thus, without this purposes but still utilize the stream sequence number so that the
feature, a new use of an old stream would result in message numbers application can track the message flows. Thus, without this feature,
greater than expected unless there is a protocol mechanism to "reset a new use of an old stream would result in message numbers greater
the streams back to zero". This document also includes methods for than expected, unless there is a protocol mechanism to "reset the
resetting the transport sequence numbers, adding additional streams streams back to zero". This document also includes methods for
and resetting all stream sequence numbers. resetting the transmission sequence numbers, adding additional
streams, and resetting all stream sequence numbers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 10, 2012. 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.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions .....................................................4
3. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 4 3. New Chunk Type ..................................................4
3.1. RE-CONFIG Chunk . . . . . . . . . . . . . . . . . . . . . 5 3.1. RE-CONFIG Chunk ............................................5
4. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 6 4. New Parameter Types .............................................6
4.1. Outgoing SSN Reset Request Parameter . . . . . . . . . . . 7 4.1. Outgoing SSN Reset Request Parameter .......................7
4.2. Incoming SSN Reset Request Parameter . . . . . . . . . . . 8 4.2. Incoming SSN Reset Request Parameter .......................8
4.3. SSN/TSN Reset Request Parameter . . . . . . . . . . . . . 9 4.3. SSN/TSN Reset Request Parameter ............................9
4.4. Re-configuration Response Parameter . . . . . . . . . . . 9 4.4. Re-configuration Response Parameter .......................10
4.5. Add Outgoing Streams Request Parameter . . . . . . . . . . 11 4.5. Add Outgoing Streams Request Parameter ....................12
4.6. Add Incoming Streams Request Parameter . . . . . . . . . . 12 4.6. Add Incoming Streams Request Parameter ....................13
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Procedures .....................................................14
5.1. Sender Side Procedures . . . . . . . . . . . . . . . . . . 13 5.1. Sender-Side Procedures ....................................14
5.1.1. Sender Side Procedures for the RE-CONFIG Chunk . . . . 13 5.1.1. Sender-Side Procedures for the RE-CONFIG Chunk .....14
5.1.2. Sender Side Procedures for the Outgoing SSN Reset 5.1.2. Sender-Side Procedures for the Outgoing SSN
Request Parameter . . . . . . . . . . . . . . . . . . 14 Reset Request Parameter ............................15
5.1.3. Sender Side Procedures for the Incoming SSN Reset 5.1.3. Sender-Side Procedures for the Incoming SSN
Request Parameter . . . . . . . . . . . . . . . . . . 15 Reset Request Parameter ............................16
5.1.4. Sender Side Procedures for the SSN/TSN Reset 5.1.4. Sender-Side Procedures for the SSN/TSN
Request Parameter . . . . . . . . . . . . . . . . . . 16 Reset Request Parameter ............................17
5.1.5. Sender Side Procedures for the Re-configuration 5.1.5. Sender-Side Procedures for the Add Outgoing
Response Parameter . . . . . . . . . . . . . . . . . . 16 Streams Request Parameter ..........................17
5.1.6. Sender Side Procedures for the Add Outgoing 5.1.6. Sender-Side Procedures for the Add Incoming
Streams Request Parameter . . . . . . . . . . . . . . 17 Streams Request Parameter ..........................17
5.1.7. Sender Side Procedures for the Add Incoming 5.1.7. Sender-Side Procedures for the
Streams Request Parameter . . . . . . . . . . . . . . 17 Re-configuration Response Parameter ................18
5.2. Receiver Side Procedures . . . . . . . . . . . . . . . . . 18
5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk . . . 18 5.2. Receiver-Side Procedures ..................................18
5.2.2. Receiver Side Procedures for the Outgoing SSN 5.2.1. Receiver-Side Procedures for the RE-CONFIG Chunk ...18
Reset Request Parameter . . . . . . . . . . . . . . . 18 5.2.2. Receiver-Side Procedures for the Outgoing
5.2.3. Receiver Side Procedures for the Incoming SSN SSN Reset Request Parameter ........................19
Reset Request Parameter . . . . . . . . . . . . . . . 19 5.2.3. Receiver-Side Procedures for the Incoming
5.2.4. Receiver Side Procedures for the SSN/TSN Reset SSN Reset Request Parameter ........................20
Request Parameter . . . . . . . . . . . . . . . . . . 20 5.2.4. Receiver-Side Procedures for the SSN/TSN
5.2.5. Receiver Side Procedures for the Add Outgoing Reset Request Parameter ............................21
Streams Request Parameter . . . . . . . . . . . . . . 21 5.2.5. Receiver-Side Procedures for the Add
5.2.6. Receiver Side Procedures for the Add Incoming Outgoing Streams Request Parameter .................21
Streams Request Parameter . . . . . . . . . . . . . . 21 5.2.6. Receiver-Side Procedures for the Add
5.2.7. Receiver Side Procedures for the Re-configuration Incoming Streams Request Parameter .................22
Response Parameter . . . . . . . . . . . . . . . . . . 21 5.2.7. Receiver-Side Procedures for the
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 22 Re-configuration Response Parameter ................22
6.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Sockets API Considerations .....................................23
6.1.1. Stream Reset Event . . . . . . . . . . . . . . . . . . 23 6.1. Events ....................................................23
6.1.2. Association Reset Event . . . . . . . . . . . . . . . 24 6.1.1. Stream Reset Event .................................24
6.1.3. Stream Change Event . . . . . . . . . . . . . . . . . 25 6.1.2. Association Reset Event ............................25
6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . 26 6.1.3. Stream Change Event ................................26
6.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 26 6.2. Event Subscription ........................................27
6.3.1. Enable/Disable Stream Reset 6.3. Socket Options ............................................27
(SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 27 6.3.1. Enable/Disable Stream Reset
6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_ENABLE_STREAM_RESET) .........................28
(SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 28 6.3.2. Reset Incoming and/or Outgoing Streams
6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 28 (SCTP_RESET_STREAMS) ...............................29
6.3.4. Add Incoming and/or Outgoing Streams 6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) ...................29
(SCTP_ADD_STREAMS) . . . . . . . . . . . . . . . . . . 29 6.3.4. Add Incoming and/or Outgoing Streams
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 (SCTP_ADD_STREAMS) .................................30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations ........................................30
8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations ............................................31
8.2. Six New Chunk Parameter Types . . . . . . . . . . . . . . 30 8.1. A New Chunk Type ..........................................31
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 8.2. Six New Chunk Parameter Types .............................31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments ................................................31
10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 10. References ....................................................32
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative References .....................................32
Appendix A. Examples of the Re-configuration procedures . . . . . 32 10.2. Informative References ...................................32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Examples of the Reconfiguration Procedures ............33
1. Introduction 1. Introduction
Many applications that use SCTP as defined in [RFC4960] want the Many applications that use SCTP as defined in [RFC4960] want the
ability to "reset" a stream. The intention of resetting a stream is ability to "reset" a stream. The intention of resetting a stream is
to set the stream sequence numbers (SSNs) of the stream back to to set the Stream Sequence Numbers (SSNs) of the stream back to
'zero' with a corresponding notification to the application layer 'zero' with a corresponding notification to the application layer
that the reset has been performed. Applications requiring this that the reset has been performed. Applications requiring this
feature want to "re-use" streams for different purposes but still feature want to "reuse" streams for different purposes but still
utilize the stream sequence number so that the application can track utilize the SSN so that the application can track the message flows.
the message flows. Thus, without this feature, a new use of an old Thus, without this feature, a new use of an old stream would result
stream would result in message numbers greater than expected unless in message numbers greater than expected, unless there is a protocol
there is a protocol mechanism to "reset the streams back to zero". mechanism to "reset the streams back to zero". This document also
This document also includes methods for resetting the transport includes methods for resetting the Transmission Sequence Numbers
sequence numbers (TSNs), adding additional streams and resetting all (TSNs), adding additional streams, and resetting all SSNs.
stream sequence numbers.
The socket API for SCTP defined in [I-D.ietf-tsvwg-sctpsocket] The sockets API for SCTP defined in [RFC6458] exposes the sequence
exposes the sequence numbers used by SCTP for user message transfer. numbers used by SCTP for user message transfer. Therefore, resetting
Therefore, resetting them can be used by application writers. Please them can be used by application writers. Please note that the
note that the corresponding sequence number for TCP is not exposed corresponding sequence number for TCP is not exposed via the sockets
via the socket API for TCP. API for TCP.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. New Chunk Type 3. New Chunk Type
This section defines the new chunk type that will be used to re- This section defines the new chunk type that will be used to
configure streams. Table 1 illustrates the new chunk type. reconfigure streams. Table 1 illustrates the new chunk type.
+------------+------------------------------------+ +------------+------------------------------------+
| Chunk Type | Chunk Name | | Chunk Type | Chunk Name |
+------------+------------------------------------+ +------------+------------------------------------+
| 0x82 | Re-configuration Chunk (RE-CONFIG) | | 130 | Re-configuration Chunk (RE-CONFIG) |
+------------+------------------------------------+ +------------+------------------------------------+
Table 1 Table 1
It should be noted that the format of the RE-CONFIG chunk requires It should be noted that the format of the RE-CONFIG chunk requires
the receiver to ignore the chunk if it is not understood and continue that the receiver ignore the chunk if it is not understood and
processing all chunks that follow. This is accomplished by the use continue processing all chunks that follow. This is accomplished by
of the upper bits of the chunk type as described in section 3.2 of the use of the upper bits of the chunk type as described in
[RFC4960]. Section 3.2 of [RFC4960].
All transported integer numbers are in "network byte order" a.k.a., All transported integer numbers are in "network byte order", a.k.a.
Big Endian. Big Endian.
3.1. RE-CONFIG Chunk 3.1. RE-CONFIG Chunk
This document adds one new chunk type to SCTP. The chunk has the This document adds one new chunk type to SCTP. The chunk has the
following format: following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x82 | Chunk Flags | Chunk Length | | Type = 130 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Re-configuration Parameter / / Re-configuration Parameter /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ Re-configuration Parameter (optional) / / Re-configuration Parameter (optional) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Type: 1 byte (unsigned integer) Chunk Type: 1 byte (unsigned integer)
This field holds the IANA defined chunk type for the RE-CONFIG This field holds the IANA-defined chunk type for the RE-CONFIG
chunk. The suggested value of this field for IANA is 0x82. chunk. The value of this field is 130.
Chunk Flags: 1 byte (unsigned integer) Chunk Flags: 1 byte (unsigned integer)
This field is set to 0 by the sender and ignored by the receiver. This field is set to 0 by the sender and ignored by the receiver.
Chunk Length: 2 bytes (unsigned integer) Chunk Length: 2 bytes (unsigned integer)
This field holds the length of the chunk in bytes, including the This field holds the length of the chunk in bytes, including the
Chunk Type, Chunk Flags and Chunk Length. Chunk Type, Chunk Flags, and Chunk Length.
Re-configuration Parameter Re-configuration Parameter
This field holds a Re-configuration Request Parameter or a Re- This field holds a Re-configuration Request Parameter or a
configuration Response Parameter. Re-configuration Response Parameter.
Note that each RE-CONFIG chunk holds at least one parameter and at Note that each RE-CONFIG chunk holds at least one parameter and at
most two parameters. Only the following combinations are allowed: most two parameters. Only the following combinations are allowed:
1. Outgoing SSN Reset Request Parameter. 1. Outgoing SSN Reset Request Parameter.
2. Incoming SSN Reset Request Parameter. 2. Incoming SSN Reset Request Parameter.
3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request 3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request
Parameter. Parameter.
skipping to change at page 6, line 23 skipping to change at page 6, line 19
8. Re-configuration Response Parameter. 8. Re-configuration Response Parameter.
9. Re-configuration Response Parameter, Outgoing SSN Reset Request 9. Re-configuration Response Parameter, Outgoing SSN Reset Request
Parameter. Parameter.
10. Re-configuration Response Parameter, Re-configuration Response 10. Re-configuration Response Parameter, Re-configuration Response
Parameter. Parameter.
If a sender transmits an unsupported combination, the receiver SHOULD If a sender transmits an unsupported combination, the receiver SHOULD
send an ERROR chunk with a Protocol Violation cause as defined in send an ERROR chunk with a Protocol Violation cause, as defined in
section 3.3.10.13 of [RFC4960]). Section 3.3.10.13 of [RFC4960]).
4. New Parameter Types 4. New Parameter Types
This section defines the new parameter types that will be used in the This section defines the new parameter types that will be used in the
RE-CONFIG chunk. Table 2 illustrates the new parameter types. RE-CONFIG chunk. Table 2 illustrates the new parameter types.
+----------------+----------------------------------------+ +----------------+----------------------------------------+
| Parameter Type | Parameter Name | | Parameter Type | Parameter Name |
+----------------+----------------------------------------+ +----------------+----------------------------------------+
| 0x000d | Outgoing SSN Reset Request Parameter | | 13 | Outgoing SSN Reset Request Parameter |
| 0x000e | Incoming SSN Reset Request Parameter | | 14 | Incoming SSN Reset Request Parameter |
| 0x000f | SSN/TSN Reset Request Parameter | | 15 | SSN/TSN Reset Request Parameter |
| 0x0010 | Re-configuration Response Parameter | | 16 | Re-configuration Response Parameter |
| 0x0011 | Add Outgoing Streams Request Parameter | | 17 | Add Outgoing Streams Request Parameter |
| 0x0012 | Add Incoming Streams Request Parameter | | 18 | Add Incoming Streams Request Parameter |
+----------------+----------------------------------------+ +----------------+----------------------------------------+
Table 2 Table 2
It should be noted that the parameter format requires the receiver to It should be noted that the parameter format requires that the
stop processing the parameter and not to process any further receiver stop processing the parameter and not process any further
parameters within the chunk if the parameter type is not recognized. parameters within the chunk if the parameter type is not recognized.
This is accomplished by the use of the upper bits of the parameter This is accomplished by the use of the upper bits of the parameter
type as described in section 3.2.1 of [RFC4960]. type as described in Section 3.2.1 of [RFC4960].
All transported integer numbers are in "network byte order" a.k.a., All transported integer numbers are in "network byte order", a.k.a.
Big Endian. Big Endian.
4.1. Outgoing SSN Reset Request Parameter 4.1. Outgoing SSN Reset Request Parameter
This parameter is used by the sender to request the reset of some or This parameter is used by the sender to request the reset of some or
all outgoing streams. all outgoing streams.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000d | Parameter Length = 16 + 2 * N | | Parameter Type = 13 | Parameter Length = 16 + 2 * N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number | | Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Response Sequence Number | | Re-configuration Response Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Last Assigned TSN | | Sender's Last Assigned TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) | | Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... / / ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) | | Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the Outgoing This field holds the IANA-defined parameter type for the Outgoing
SSN Reset Request Parameter. The suggested value of this field SSN Reset Request Parameter. The value of this field is 13.
for IANA is 0x000d.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value 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 MUST be 16 + 2 * N, where N is the number of stream numbers
listed. listed.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new initial TSN. It is increased by 1 whenever sending a new Re-
Re-configuration Request parameter. configuration Request Parameter.
Re-configuration Response Sequence Number: 4 bytes (unsigned Re-configuration Response Sequence Number: 4 bytes (unsigned
integer) integer)
When this Outgoing SSN Reset Request Parameter is sent in response When this Outgoing SSN Reset Request Parameter is sent in response
to an Incoming SSN Reset Request Parameter this parameter is also to an Incoming SSN Reset Request Parameter, this parameter is also
an implicit response to the incoming request. Then this field an implicit response to the incoming request. This field then
holds the Re-configuration Request Sequence Number of the incoming holds the Re-configuration Request Sequence Number of the incoming
request. In other cases it holds the next expected Re- request. In other cases, it holds the next expected
configuration Request Sequence Number minus 1. Re-configuration Request Sequence Number minus 1.
Sender's last assigned TSN: 4 bytes (unsigned integer) Sender's Last Assigned TSN: 4 bytes (unsigned integer)
This value holds the next TSN minus 1, in other words the last TSN This value holds the next TSN minus 1 -- in other words, the last
that this sender assigned. TSN that this sender assigned.
Stream Number 1..N: 2 bytes (unsigned integer) Stream Number 1..N: 2 bytes (unsigned integer)
This optional field, if included, is used to indicate specific This optional field, if included, is used to indicate specific
streams that are to be reset. If no streams are listed, then all streams that are to be reset. If no streams are listed, then all
streams are to be reset. streams are to be reset.
This parameter can appear in a RE-CONFIG chunk. This parameter MUST This parameter can appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
4.2. Incoming SSN Reset Request Parameter 4.2. Incoming SSN Reset Request Parameter
This parameter is used by the sender to request that the peer resets This parameter is used by the sender to request that the peer reset
some or all of its outgoing streams. some or all of its outgoing streams.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000e | Parameter Length = 8 + 2 * N | | Parameter Type = 14 | Parameter Length = 8 + 2 * N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number | | Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number 1 (optional) | Stream Number 2 (optional) | | Stream Number 1 (optional) | Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ...... / / ...... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Number N-1 (optional) | Stream Number N (optional) | | Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the Incoming This field holds the IANA-defined parameter type for the Incoming
SSN Reset Request Parameter. The suggested value of this field SSN Reset Request Parameter. The value of this field is 14.
for IANA is 0x000e.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value This field holds the length in bytes of the parameter; the value
MUST be 8 + 2 * N. MUST be 8 + 2 * N.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new initial TSN. It is increased by 1 whenever sending a new Re-
Re-configuration Request parameter. configuration Request Parameter.
Stream Number 1..N: 2 bytes (unsigned integer) Stream Number 1..N: 2 bytes (unsigned integer)
This optional field, if included, is used to indicate specific This optional field, if included, is used to indicate specific
streams that are to be reset. If no streams are listed, then all streams that are to be reset. If no streams are listed, then all
streams are to be reset. streams are to be reset.
This parameter can appear in a RE-CONFIG chunk. This parameter MUST This parameter can appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
4.3. SSN/TSN Reset Request Parameter 4.3. SSN/TSN Reset Request Parameter
This parameter is used by the sender to request a reset of the TSN This parameter is used by the sender to request a reset of the TSN
and SSN numbering of all incoming and outgoing streams. and SSN numbering of all incoming and outgoing streams.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x000f | Parameter Length = 8 | | Parameter Type = 15 | Parameter Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number | | Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the SSN/TSN This field holds the IANA-defined parameter type for the SSN/TSN
Reset Request Parameter. The suggested value of this field for Reset Request Parameter. The value of this field is 15.
IANA is 0x000f.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value This field holds the length in bytes of the parameter; the value
MUST be 8. MUST be 8.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new initial TSN. It is increased by 1 whenever sending a new Re-
Re-configuration Request parameter. configuration Request Parameter.
This parameter can appear in a RE-CONFIG chunk. This parameter MUST This parameter can appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
4.4. Re-configuration Response Parameter 4.4. Re-configuration Response Parameter
This parameter is used by the receiver of a Re-configuration Request This parameter is used by the receiver of a Re-configuration Request
parameter to respond to the request. Parameter to respond to the request.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x0010 | Parameter Length | | Parameter Type = 16 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Response Sequence Number | | Re-configuration Response Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | | Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's next TSN (optional) | | Sender's Next TSN (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's next TSN (optional) | | Receiver's Next TSN (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for Re- This field holds the IANA-defined parameter type for the
configuration Response Parameter. The suggested value of this Re-configuration Response Parameter. The value of this field
field for IANA is 0x0010. is 16.
Parameter Type Length: 2 bytes (unsigned integer) Parameter Type Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value This field holds the length in bytes of the parameter; the value
MUST be 12 if the optional fields are not present and 20 MUST be 12 if the optional fields are not present and 20
otherwise. otherwise.
Re-configuration Response Sequence Number: 4 bytes (unsigned Re-configuration Response Sequence Number: 4 bytes (unsigned
integer) integer)
This value is copied from the request parameter and is used by the This value is copied from the request parameter and is used by the
receiver of the Re-configuration Response Parameter to tie the receiver of the Re-configuration Response Parameter to tie the
response to the request. response to the request.
Result: 4 bytes (unsigned integer) Result: 4 bytes (unsigned integer)
This value describes the result of the processing of the request. This value describes the result of the processing of the request.
It is encoded as given by the following table It is encoded as indicated in Table 3:
+--------+-------------------------------------+ +--------+-------------------------------------+
| Result | Description | | Result | Description |
+--------+-------------------------------------+ +--------+-------------------------------------+
| 0 | Success - Nothing to do | | 0 | Success - Nothing to do |
| 1 | Success - Performed | | 1 | Success - Performed |
| 2 | Denied | | 2 | Denied |
| 3 | Error - Wrong SSN | | 3 | Error - Wrong SSN |
| 4 | Error - Request already in progress | | 4 | Error - Request already in progress |
| 5 | Error - Bad Sequence Number | | 5 | Error - Bad Sequence Number |
| 6 | In progress | | 6 | In progress |
+--------+-------------------------------------+ +--------+-------------------------------------+
Table 3 Table 3
Sender's next TSN: 4 bytes (unsigned integer) Sender's Next TSN: 4 bytes (unsigned integer)
This field holds the TSN the sender of the response will use to This field holds the TSN that the sender of the response will use
send the next DATA chunk. The field is only applicable in to send the next DATA chunk. The field is only applicable in
responses to SSN/TSN reset requests. responses to SSN/TSN reset requests.
Receiver's next TSN: 4 bytes (unsigned integer) Receiver's Next TSN: 4 bytes (unsigned integer)
This field holds the TSN the receiver of the response must use to This field holds the TSN that the receiver of the response must
send the next DATA chunk. The field is only applicable in use to send the next DATA chunk. The field is only applicable in
responses to SSN/TSN reset requests. responses to SSN/TSN reset requests.
Either both optional fields (Sender's next TSN and Receiver's next Either both optional fields (Sender's Next TSN and Receiver's Next
TSN) MUST be present or none. TSN) MUST be present, or no field.
This parameter can appear in a RE-CONFIG chunk. This parameter MUST This parameter can appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
4.5. Add Outgoing Streams Request Parameter 4.5. Add Outgoing Streams Request Parameter
This parameter is used by the sender to request that an additional This parameter is used by the sender to request that an additional
number of outgoing streams (i.e. the receiver's incoming streams) be number of outgoing streams (i.e., the receiver's incoming streams) be
added to the association. added to the association.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x0011 | Parameter Length = 12 | | Parameter Type = 17 | Parameter Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number | | Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of new streams | Reserved | | Number of new streams | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the the Add This field holds the IANA-defined parameter type for the Add
Outgoing Streams Request Parameter. The suggested value of this Outgoing Streams Request Parameter. The value of this field
field for IANA is 0x0011. is 17.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value This field holds the length in bytes of the parameter; the value
MUST be 12. MUST be 12.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new initial TSN. It is increased by 1 whenever sending a new Re-
Re-configuration Request parameter. configuration Request Parameter.
Number of new streams: 2 bytes (unsigned integer) Number of new streams: 2 bytes (unsigned integer)
This value holds the number of additional outgoing streams the This value holds the number of additional outgoing streams that
sender requests to be added to the association. Streams are added the sender requests be added to the association. Streams are
in order and are consecutive, e.g. if an association has four added in order and are consecutive; e.g., if an association has 4
outgoing streams (0-3) and a requested is made to add 3 streams outgoing streams (0-3) and a request is made to add 3 streams,
then the new streams will be 4, 5 and 6. then the new streams will be 4, 5, and 6.
Reserved: 2 bytes (unsigned integer) Reserved: 2 bytes (unsigned integer)
This field is reserved. It SHOULD be set to 0 by the sender and This field is reserved. It SHOULD be set to 0 by the sender and
ignored by the receiver. ignored by the receiver.
This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
4.6. Add Incoming Streams Request Parameter 4.6. Add Incoming Streams Request Parameter
This parameter is used by the sender to request that the peer adds an 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 additional number of outgoing streams (i.e., the sender's incoming
streams) to the association. streams) to the association.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x0012 | Parameter Length = 12 | | Parameter Type = 18 | Parameter Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number | | Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of new streams | Reserved | | Number of new streams | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the the Add This field holds the IANA-defined parameter type for the Add
Incoming Streams Request Parameter. The suggested value of this Incoming Streams Request Parameter. The value of this field
field for IANA is 0x0012. is 18.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value This field holds the length in bytes of the parameter; the value
MUST be 12. MUST be 12.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new initial TSN. It is increased by 1 whenever sending a new Re-
Re-configuration Request parameter. configuration Request Parameter.
Number of new streams: 2 bytes (unsigned integer) Number of new streams: 2 bytes (unsigned integer)
This value holds the number of additional incoming streams the This value holds the number of additional incoming streams that
sender requests to be added to the association. Streams are added the sender requests be added to the association. Streams are
in order and are consecutive, e.g. if an association has four added in order and are consecutive; e.g., if an association has 4
outgoing streams (0-3) and a requested is made to add 3 streams outgoing streams (0-3) and a request is made to add 3 streams,
then the new streams will be 4, 5 and 6. then the new streams will be 4, 5, and 6.
Reserved: 2 bytes (unsigned integer) Reserved: 2 bytes (unsigned integer)
This field is reserved. It SHOULD be set to 0 by the sender and This field is reserved. It SHOULD be set to 0 by the sender and
ignored by the receiver. ignored by the receiver.
This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
5. Procedures 5. Procedures
This section defines the procedures used by both the sender and This section defines the procedures used by both the sender and
receiver of a RE-CONFIG chunk. Various examples of re-configuration receiver of a RE-CONFIG chunk. Various examples of re-configuration
scenarios are given in Appendix A. scenarios are given in Appendix A.
One important thing to remember about SCTP streams is that they are One important thing to remember about SCTP streams is that they are
uni-directional. The endpoint for which a stream is an outgoing uni-directional and there is no correspondence between outgoing and
stream is called the outgoing side, the endpoint for which the stream incoming streams. The procedures outlined in this section are
is an incoming stream is called the incoming side. The procedures designed so that the incoming side will always reset its SSN first
outlined in this section are designed so that the incoming side will (before the outgoing side), which means the re-configuration request
always reset their stream sequence number first before the outgoing must always originate from the outgoing side. These two issues have
side which means the re-configuration request must always originate important ramifications upon how an SCTP endpoint might request that
from the outgoing side. These two issues have important its incoming streams be reset. In effect, it must ask the peer to
ramifications upon how an SCTP endpoint might request that its start an outgoing reset procedure and once that request is
incoming streams be reset. In effect it must ask the peer to start acknowledged let the peer actually control the reset operation.
an outgoing reset procedure and once that request is acknowledged let
the peer actually control the reset operation.
5.1. Sender Side Procedures 5.1. Sender-Side Procedures
This section describes the procedures related to the sending of RE- This section describes the procedures related to the sending of
CONFIG chunks. A RE-CONFIG chunk is composed of one or two Type RE-CONFIG chunks. A RE-CONFIG chunk is composed of one or two Type-
Length Value (TLV) parameters. Length-Value (TLV) parameters.
5.1.1. Sender Side Procedures for the RE-CONFIG Chunk 5.1.1. Sender-Side Procedures for the RE-CONFIG Chunk
This SCTP extension uses the Supported Extensions Parameter defined The SCTP protocol extension described in this document uses the
in [RFC5061] for negotiating the support for it. Supported Extensions Parameter defined in [RFC5061] for negotiating
the support.
An SCTP endpoint supporting this extension MUST include the chunk An SCTP endpoint supporting this extension MUST include the chunk
type of the RE-CONFIG chunk in the Supported Extensions Parameter in 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 either the INIT or INIT-ACK. Before sending a RE-CONFIG chunk, the
sender MUST ensure that the peer advertised support for the re- sender MUST ensure that the peer advertised support for the
configuration extension. If the chunk type of the RE-CONFIG chunk re-configuration extension. If the chunk type of the RE-CONFIG chunk
does not appear in the supported extensions list of chunks, then the 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 sender MUST NOT send any re-configuration request to the peer, and
any request by the application for such service SHOULD be responded any request by the application for such service SHOULD be responded
to with an appropriate error indicating the peer SCTP stack does not to with an appropriate error indicating that the peer SCTP stack does
support the re-configuration extension. not support the re-configuration extension.
At any given time there MUST NOT be more than one request be in At any given time, there MUST NOT be more than one request in flight.
flight. So if the Re-configuration Timer is running and the the RE- So, if the Re-configuration Timer is running and the RE-CONFIG chunk
CONFIG chunk contains at least one request parameter the chunk MUST contains at least one request parameter, the chunk MUST be buffered.
be buffered.
After packaging the RE-CONFIG chunk and sending it to the peer the 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 sender MUST start the Re-configuration Timer if the RE-CONFIG chunk
contains at least one request parameter. If it contains no request contains at least one request parameter. If it contains no request
parameters, the Re-configuration Timer MUST NOT be started. This parameters, the Re-configuration Timer MUST NOT be started. This
timer MUST use the same value as SCTP's Data transmission timer (i.e. timer MUST use the same value as SCTP's data transmission timer
the RTO timer) and MUST use exponential backoff doubling the value at (i.e., the retransmission timeout (RTO) timer) and MUST use
every expiration. If the timer expires, besides doubling the value, exponential backoff, doubling the value at every expiration. If the
the sender MUST retransmit the RE-CONFIG chunk, increment the timer expires, besides doubling the value, the sender MUST retransmit
appropriate error counts (both for the association and the the RE-CONFIG chunk, increment the appropriate error counts (for both
destination), and perform threshold management possibly destroying the association and the destination), and perform threshold
the association if SCTP retransmission thresholds are exceeded. management, possibly destroying the association if SCTP
retransmission thresholds are exceeded.
5.1.2. Sender Side Procedures for the Outgoing SSN Reset Request 5.1.2. Sender-Side Procedures for the Outgoing SSN Reset Request
Parameter Parameter
When an SCTP sender wants to reset the SSNs of some or all outgoing 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 streams, it can send an Outgoing SSN Reset Request Parameter,
that the Re-configuration Timer is not running. The following steps provided that the Re-configuration Timer is not running. The
must be followed: following steps must be followed:
A1: The sender MUST stop assigning new SSNs to new user data A1: The sender MUST stop assigning new SSNs to new user data
provided by the upper layer for the affected streams and queue provided by the upper layer for the affected streams and queue
it. This is because it is not known whether the receiver of the it. This is because it is not known whether the receiver of the
request will accept or deny it and moreover, a lost request request will accept or deny it; moreover, a lost request might
might cause an out-of-sequence error in a stream that the cause an out-of-sequence error in a stream that the receiver is
receiver is not yet prepared to handle. not yet prepared to handle.
A2: The sender MUST assign the next re-configuration request A2: The sender MUST assign the next re-configuration request
sequence number and MUST put it into the Re-configuration sequence number and MUST put it into the Re-configuration
Request Sequence Number field of the Outgoing SSN Reset Request Request Sequence Number field of the Outgoing SSN Reset Request
Parameter. The next re-configuration request sequence number Parameter. The next re-configuration request sequence number
MUST then be incremented by 1. MUST then be incremented by 1.
A3: The Sender's Last Assigned TSN MUST be set to the next TSN the A3: The Sender's Last Assigned TSN MUST be set to the next TSN the
sender assigns minus 1. sender assigns minus 1.
A4: If this Outgoing SSN Reset Request Parameter is sent in response A4: If this Outgoing SSN Reset Request Parameter is sent in response
to an Incoming SSN Reset Request Parameter the Stream Numbers to an Incoming SSN Reset Request Parameter, the stream numbers
MUST be copied from the Incoming SSN Reset Request Parameter to MUST be copied from the Incoming SSN Reset Request Parameter to
the Outgoing SSN Reset Request Parameter. The Re-configuration the Outgoing SSN Reset Request Parameter. The Re-configuration
Response Sequence Number of the Outgoing SSN Reset Request Response Sequence Number of the Outgoing SSN Reset Request
Parameter MUST be the Re-configuration Request Sequence Number Parameter MUST be the Re-configuration Request Sequence Number
of the Incoming SSN Reset Request Parameter. If this Outgoing of the Incoming SSN Reset Request Parameter. If this Outgoing
SSN Reset Request Parameter is sent at the request of the upper SSN Reset Request Parameter is sent at the request of the upper
layer and the sender requests all outgoing streams to be reset layer and the sender requests that all outgoing streams be
Stream Numbers SHOULD NOT be put into the Outgoing SSN Reset reset, stream numbers SHOULD NOT be put into the Outgoing SSN
Request Parameter. If the sender requests only some outgoing Reset Request Parameter. If the sender requests that only some
streams to be reset these Stream Numbers MUST be placed in the outgoing streams be reset, these stream numbers MUST be placed
Outgoing SSN Reset Request Parameter. Re-configuration Response in the Outgoing SSN Reset Request Parameter. The
Sequence Number is the next expected Re-configuration Request Re-configuration Response Sequence Number is the next expected
Sequence Number of the peer minus 1. Re-configuration Request Sequence Number of the peer minus 1.
A5: The Outgoing SSN Reset Request Parameter MUST be put into a RE- A5: The Outgoing SSN Reset Request Parameter MUST be put into a
CONFIG Chunk. The Outgoing SSN Reset Request Parameter MAY be RE-CONFIG Chunk. The Outgoing SSN Reset Request Parameter MAY
put together with either an Incoming SSN Reset Request Parameter be put together with either an Incoming SSN Reset Request
or an Re-configuration Response Parameter but not both. It MUST Parameter or a Re-configuration Response Parameter, but not with
NOT be put together with any other parameter as described in both. It MUST NOT be put together with any other parameter, as
Section 3.1. described in Section 3.1.
A6: The RE-CONFIG chunk MUST be sent following the rules given in A6: The RE-CONFIG chunk MUST be sent following the rules given in
Section 5.1.1. Section 5.1.1.
5.1.3. Sender Side Procedures for the Incoming SSN Reset Request 5.1.3. Sender-Side Procedures for the Incoming SSN Reset Request
Parameter Parameter
When an SCTP sender wants to reset the SSNs of some or all incoming 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 streams, it can send an Incoming SSN Reset Request Parameter,
that the Re-configuration Timer is not running. The following steps provided that the Re-configuration Timer is not running. The
must be followed: following steps must be followed:
B1: The sender MUST assign the next re-configuration request B1: The sender MUST assign the next re-configuration request
sequence number and MUST put it into the Re-configuration sequence number and MUST put it into the Re-configuration
Request Sequence Number field of the Incoming SSN Reset Request Request Sequence Number field of the Incoming SSN Reset Request
Parameter. After assigning it the next re-configuration request Parameter. After assigning it, the next re-configuration
sequence number MUST be incremented by 1. request sequence number MUST be incremented by 1.
B2: If the sender wants all incoming streams to be reset Stream B2: If the sender wants all incoming streams to be reset, stream
Numbers SHOULD NOT be put into the Incoming SSN Reset Request numbers SHOULD NOT be put into the Incoming SSN Reset Request
Parameter. If the sender wants only some incoming streams to be Parameter. If the sender wants only some incoming streams to be
reset these Stream Numbers MUST be filled in the Incoming SSN reset, these stream numbers MUST be filled in the Incoming SSN
Reset Request Parameter. Reset Request Parameter.
B3: The Incoming SSN Reset Request Parameter MUST be put into a RE- B3: The Incoming SSN Reset Request Parameter MUST be put into a
CONFIG Chunk. It MAY be put together with an Outgoing SSN Reset RE-CONFIG Chunk. It MAY be put together with an Outgoing SSN
Request Parameter but MUST NOT be put together with any other Reset Request Parameter but MUST NOT be put together with any
parameter. other parameter.
B4: The RE-CONFIG chunk MUST be sent following the rules given in B4: The RE-CONFIG chunk MUST be sent following the rules given in
Section 5.1.1. Section 5.1.1.
When sending an Incoming SSN Reset Request there is a potential that 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 the peer has just reset or is in the process of resetting the same
streams via an Outgoing SSN Reset Request. This collision scenario streams via an Outgoing SSN Reset Request. This collision scenario
is discussed in Section 5.2.3. is discussed in Section 5.2.3.
5.1.4. Sender Side Procedures for the SSN/TSN Reset Request Parameter 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 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 SSN/TSN Reset Request Parameter, provided that the Re-configuration
Timer is not running. The following steps must be followed: Timer is not running. The following steps must be followed:
C1: The sender MUST assign the next re-configuration request C1: The sender MUST assign the next re-configuration request
sequence number and put it into the Re-configuration Request sequence number and put it into the Re-configuration Request
Sequence Number field of the SSN/TSN Reset Request Parameter. Sequence Number field of the SSN/TSN Reset Request Parameter.
After assigning it the next re-configuration request sequence After assigning it, the next re-configuration request sequence
number MUST be incremented by 1. number MUST be incremented by 1.
C2: The sender has either no outstanding TSNs or considers all C2: The sender has either no outstanding TSNs or considers all
outstanding TSNs abandoned. The sender MUST queue any user data outstanding TSNs abandoned. The sender MUST queue any user
suspending any new transmissions and TSN assignment until the data, suspending any new transmissions and TSN assignment until
reset procedure is finished by the peer either acknowledging or the reset procedure is finished by the peer either acknowledging
denying the request. or denying the request.
C3: The SSN/TSN Reset Request Parameter MUST be put into a RE-CONFIG 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. chunk. There MUST NOT be any other parameter in this chunk.
C4: The RE-CONFIG chunk MUST be sent following the rules given in C4: The RE-CONFIG chunk MUST be sent following the rules given in
Section 5.1.1. Section 5.1.1.
Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds, Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds,
which is considered a maximum segment lifetime, the IP MSL. which is considered a maximum segment lifetime (the IP MSL).
5.1.5. Sender Side Procedures for the Re-configuration Response 5.1.5. Sender-Side Procedures for the Add Outgoing Streams Request
Parameter Parameter
When an implementation receives a reset request parameter it must 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
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 respond with a Re-configuration Response Parameter in the following
manner: manner:
D1: The Re-configuration Request Sequence number of the incoming D1: The Re-configuration Request Sequence number of the incoming
request MUST be copied to the Re-configuration Response Sequence request MUST be copied to the Re-configuration Response Sequence
Number field of the Re-configuration Response Parameter. Number field of the Re-configuration Response Parameter.
D2: The result of the processing of the incoming request according D2: The result of the processing of the incoming request according
to Table 3 MUST be placed in the Result field of the Re- to Table 3 MUST be placed in the Result field of the
configuration Response Parameter. Re-configuration Response Parameter.
D3: If the incoming request is an SSN/TSN reset request, the 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's Next TSN field MUST be filled with the next TSN the
sender of this Re-configuration Response Parameter will assign. sender of this Re-configuration Response Parameter will assign.
For other requests the Sender's next TSN field, which is For other requests, the Sender's Next TSN field, which is
optional, MUST NOT be used. optional, MUST NOT be used.
D4: If the incoming request is an SSN/TSN reset request, the 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 Receiver's Next TSN field MUST be filled with a TSN such that
the sender of the Re-configuration Response Parameter can be the sender of the Re-configuration Response Parameter can be
sure it can discard received DATA chunks with smaller TSNs. The sure it can discard received DATA chunks with smaller TSNs. The
value SHOULD be the smallest TSN not acknowledged by the value SHOULD be the smallest TSN not acknowledged by the
receiver of the request plus 2^31. For other requests the receiver of the request plus 2^31. For other requests, the
Receiver's next TSN field, which is optional, MUST NOT be used. Receiver's Next TSN field, which is optional, MUST NOT be used.
5.1.6. Sender Side Procedures for the Add Outgoing Streams Request
Parameter
When an SCTP sender wants to increase the number of outbound streams
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 has already 5 (0-4) then the new streams, upon
successful completion, are streams 5 and 6. A new stream MUST use
the stream sequence number 0 for its first ordered message.
5.1.7. 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
if a request is made to add 2 streams to an association that has
already 5 (0-4) then the new streams, upon successful completion, are
streams 5 and 6. A new stream MUST use the stream sequence number 0
for its first ordered message.
5.2. Receiver Side Procedures 5.2. Receiver-Side Procedures
5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk 5.2.1. Receiver-Side Procedures for the RE-CONFIG Chunk
Upon reception of a RE-CONFIG chunk each parameter within it SHOULD Upon reception of a RE-CONFIG chunk, each parameter within it SHOULD
be processed. If multiple parameters have to be returned, they MUST be processed. If multiple parameters have to be returned, they MUST
be put into one RE_CONFIG chunk. If the received RE-CONFIG chunk be put into one RE_CONFIG chunk. If the received RE-CONFIG chunk
contains at least one request parameter, a SACK chunk SHOULD be sent contains at least one request parameter, a selective acknowledgment
back and MAY be bundled with the RE-CONFIG chunk. If the received (SACK) chunk SHOULD be sent back and MAY be bundled with the
RE-CONFIG chunk contains at least one request and based on the RE-CONFIG chunk. If the received RE-CONFIG chunk contains at least
analysis of the Re-configuration Request Sequence Numbers this is the one request and based on the analysis of the Re-configuration Request
last received RE-CONFIG chunk (i.e. a retransmission), the same RE- Sequence Numbers this is the last received RE-CONFIG chunk (i.e., a
CONFIG chunk MUST to be sent back in response as was earlier. retransmission), the same RE-CONFIG chunk MUST to be sent back in
response, as it was earlier.
The decision to deny a re-configuration request is an administrative The decision to deny a re-configuration request is an administrative
decision and may be user configurable even after the association has decision and may be user configurable even after the association has
formed. If for whatever reason the endpoint does not wish to process formed. If for whatever reason the endpoint does not wish to process
a received request parameter it MUST send a corresponding response a received request parameter, it MUST send a corresponding response
parameter as described in Section 5.1.5 with an appropriate Result parameter as described in Section 5.1.7, with an appropriate Result
field. field.
Implementation Note: A SACK is recommended to be bundled with any re- Implementation Note: It is recommended that a SACK be bundled with
configuration response so that any retransmission processing that any re-configuration response so that any retransmission
needs to occur can be expedited. A SACK chunk is not required for processing that needs to occur can be expedited. A SACK chunk is
this feature to work, but it will in effect help minimize the delay not required for this feature to work, but it will in effect help
in completing a re-configuration operation in the face of any data minimize the delay in completing a re-configuration operation in
loss. the face of any data loss.
5.2.2. Receiver Side Procedures for the Outgoing SSN Reset Request 5.2.2. Receiver-Side Procedures for the Outgoing SSN Reset Request
Parameter Parameter
In the case that the endpoint is willing to perform a stream reset In the case that the endpoint is willing to perform a stream reset,
the following steps must be followed: the following steps must be followed:
E1: If the Re-configuration Timer is running for the Re- E1: If the Re-configuration Timer is running for the
configuration Request Sequence Number indicated in the Re- Re-configuration Request Sequence Number indicated in the
configuration Response Sequence Number field, the Re- Re-configuration Response Sequence Number field, the
configuration Request Sequence Number MUST be marked as Re-configuration Request Sequence Number MUST be marked as
acknowledged. If all Re-configuration Request Sequence Numbers acknowledged. If all Re-configuration Request Sequence Numbers
the Re-configuration Timer is running for are acknowledged, the for which the Re-configuration Timer is running are
Re-configuration Timer MUST be stopped. acknowledged, the Re-configuration Timer MUST be stopped.
E2: If the Sender's Last Assigned TSN number is greater than the E2: If the Sender's Last Assigned TSN is greater than the cumulative
cumulative acknowledgment point, then the endpoint MUST enter acknowledgment point, then the endpoint MUST enter "deferred
"deferred reset processing". In this mode, any data arriving reset processing". In this mode, any data arriving with a TSN
with a TSN number larger than the 'senders last assigned TSN' larger than the Sender's Last Assigned TSN for the affected
for the affected stream(s) MUST be queued locally and held until stream(s) MUST be queued locally and held until the cumulative
the Cumulative Acknowledgment point reaches the 'senders last acknowledgment point reaches the Sender's Last Assigned TSN.
assigned TSN number'. When the Cumulative Acknowledgment point When the cumulative acknowledgment point reaches the last
reaches the last assigned TSN number then proceed to the next assigned TSN, then proceed to the next step. If the endpoint
step. If the endpoint enters "deferred reset processing", it enters "deferred reset processing", it MUST put a Re-
MUST put a Re-configuration Response Parameter into a RE-CONFIG configuration Response Parameter into a RE-CONFIG chunk
chunk indicating 'In progress' and MUST send the RE-CONFIG indicating "In progress" and MUST send the RE-CONFIG chunk.
chunk.
E3: If no Stream Numbers are listed in the parameter, then all E3: If no stream numbers are listed in the parameter, then all
incoming streams MUST be reset to 0 as the next expected stream incoming streams MUST be reset to 0 as the next expected SSN.
sequence number. If specific Stream Numbers are listed, then If specific stream numbers are listed, then only these specific
only these specific streams MUST be reset to 0 and all other streams MUST be reset to 0, and all other non-listed SSNs remain
non-listed stream sequence numbers remain unchanged. unchanged.
E4: Any queued TSN's (queued at step E2) MUST now be released and E4: Any queued TSNs (queued at step E2) MUST now be released and
processed normally. processed normally.
E5: A Re-configuration Response Parameter MUST be put into a RE- E5: A Re-configuration Response Parameter MUST be put into a
CONFIG chunk indicating successful processing. RE-CONFIG chunk indicating successful processing.
E6: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG E6: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG
chunk is processed completely. chunk is processed completely.
5.2.3. Receiver Side Procedures for the Incoming SSN Reset Request 5.2.3. Receiver-Side Procedures for the Incoming SSN Reset Request
Parameter Parameter
In the case that the endpoint is willing to perform a stream reset In the case that the endpoint is willing to perform a stream reset,
the following steps must be followed: the following steps must be followed:
F1: An Outgoing SSN Reset Request Parameter MUST be put into an RE- F1: An Outgoing SSN Reset Request Parameter MUST be put into a
CONFIG chunk according to Section 5.1.2. RE-CONFIG chunk according to Section 5.1.2.
F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG
chunk is processed completely. chunk is processed completely.
When a peer endpoint requests an Incoming SSN Reset Request it is When a peer endpoint requests an Incoming SSN Reset Request, it is
possible that the local endpoint has just sent an Outgoing SSN Reset possible that the local endpoint has just sent an Outgoing SSN Reset
Request on the same association and has not yet received a response. Request on the same association and has not yet received a response.
In such a case the local endpoint MUST do the following: In such a case, the local endpoint MUST do the following:
o If the just sent Outgoing SSN Reset Request Parameter 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 o If the Outgoing SSN Reset Request Parameter that was just sent
normally responding to the peer with an acknowledgment. Note that completely overlaps the received Incoming SSN Reset Request
this case includes the situation where some of the streams Parameter, respond to the peer with an acknowledgment indicating
requested overlap with the just sent Outgoing SSN Reset Request. that there was "Nothing to do".
Even in such a situation the Incoming SSN Reset MUST be processed o Otherwise, process the Incoming SSN Reset Request Parameter
normally even though this means that (if the endpoint elects to do normally, responding to the peer with an acknowledgment. Note
the stream reset) streams that are already at SSN 0, will be reset that this case includes the situation where some of the streams
a subsequent time. 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 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 Outgoing SSN Reset Request just completed. In such a case, all of
streams being requested will be already set to 0. If so, the local the streams being requested will be already set to 0. If so, the
endpoint SHOULD send back a Re-configuration Response with the local endpoint SHOULD send back a Re-configuration Response with the
success code "Nothing to do". success code "Nothing to do".
Note that in either race condition the local endpoint could Note that in either race condition, the local endpoint could
optionally also perform the reset. This would result in streams that 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 are already at sequence 0 being reset again to 0, which would cause
harm to the application but will add an extra message to the network. no harm to the application but will add an extra message to the
network.
5.2.4. Receiver Side Procedures for the SSN/TSN Reset Request Parameter 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 In the case that the endpoint is willing to perform an SSN/TSN reset,
the following steps must be followed: the following steps must be followed:
G1: Compute an appropriate value for the Receiver's next TSN, the G1: Compute an appropriate value for the Receiver's Next TSN -- the
TSN the peer should use to send the next DATA chunk. The value TSN that the peer should use to send the next DATA chunk. The
SHOULD be the smallest TSN not acknowledged by the receiver of value SHOULD be the smallest TSN not acknowledged by the
the request plus 2^31. receiver of the request plus 2^31.
G2: Compute an appropriate value for the local endpoint's next TSN, G2: Compute an appropriate value for the local endpoint's next TSN,
i.e. the receiver of the SSN/TSN reset chunk next TSN to be i.e., the next TSN assigned by the receiver of the SSN/TSN reset
assigned. The value SHOULD be the highest TSN sent by the chunk. The value SHOULD be the highest TSN sent by the receiver
receiver of the request plus 1. of the request plus 1.
G3: The same processing as if a SACK chunk with no gap report and a G3: The same processing as though a SACK chunk with no gap report
cumulative TSN ACK of Sender's next TSN minus 1 was received and a cumulative TSN ACK of the Sender's Next TSN minus 1 were
MUST be performed. received MUST be performed.
G4: The same processing as if a FWD-TSN chunk as defined in G4: The same processing as though a FWD-TSN chunk (as defined in
[RFC3758] with all streams affected and a new cumulative TSN ACK [RFC3758]) with all streams affected and a new cumulative TSN
of Receiver's next TSN minus 1 was received MUST be performed. ACK of the Receiver's Next TSN minus 1 were received MUST be
performed.
G5: The next expected and outgoing stream sequence numbers MUST be G5: The next expected and outgoing SSNs MUST be reset to 0 for all
reset to 0 for all incoming and outgoing streams. incoming and outgoing streams.
G6: A Re-configuration Response Parameter MUST be put into a RE- G6: A Re-configuration Response Parameter MUST be put into a
CONFIG chunk indicating successful processing. RE-CONFIG chunk indicating successful processing.
G7: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG G7: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG
chunk is processed completely. chunk is processed completely.
5.2.5. Receiver Side Procedures for the Add Outgoing Streams Request 5.2.5. Receiver-Side Procedures for the Add Outgoing Streams Request
Parameter Parameter
When an SCTP endpoint receives a re-configuration request adding When an SCTP endpoint receives a re-configuration request adding
additional streams, it MUST send a response parameter either additional streams, it MUST send a response parameter either
acknowledging or denying the request. If the response is successful acknowledging or denying the request. If the response is successful,
the receiver MUST add the requested number of inbound streams to the the receiver MUST add the requested number of inbound streams to the
association, initializing the next expected stream sequence number to association, initializing the next expected SSN to 0. The SCTP
be 0. The SCTP endpoint SHOULD deny the request if the number of endpoint SHOULD deny the request if the number of streams exceeds a
streams exceeds a limit which should be configurable by the limit that should be configurable by the application.
application.
5.2.6. Receiver Side Procedures for the Add Incoming Streams Request 5.2.6. Receiver-Side Procedures for the Add Incoming Streams Request
Parameter Parameter
When an SCTP endpoint receives a re-configuration request adding When an SCTP endpoint receives a re-configuration request adding
additional incoming streams, it MUST either send a response parameter additional incoming streams, it MUST either send a response parameter
denying the request or sending a corresponding Add Outgoing Streams denying the request or send a corresponding Add Outgoing Streams
Request Parameter following the rules given in Section 5.1.6. The Request Parameter, following the rules given in Section 5.1.5. The
SCTP endpoint SHOULD deny the request if the number of streams SCTP endpoint SHOULD deny the request if the number of streams
exceeds a limit which should be configurable by the application. exceeds a limit that should be configurable by the application.
5.2.7. Receiver Side Procedures for the Re-configuration Response 5.2.7. Receiver-Side Procedures for the Re-configuration Response
Parameter Parameter
On receipt of a Re-configuration Response Parameter the following On receipt of a Re-configuration Response Parameter, the following
must be performed: must be performed:
H1: If the Re-confguration Timer is running for the Re-configuration H1: If the Re-configuration Timer is running for the Re-
Request Sequence Number indicated in the Re-configuration configuration Request Sequence Number indicated in the Re-
Response Sequence Number field, the Re-configuration Request configuration Response Sequence Number field, the
Sequence Number MUST be marked as acknowledged. If all Re- Re-configuration Request Sequence Number MUST be marked as
configuration Request Sequence Numbers the Re-configuration acknowledged. If all Re-configuration Request Sequence Numbers
Timer is running for are acknowledged, the Re-configuration for which the Re-configuration Timer is running are
Timer MUST be stopped. If the timer was not running for the Re- acknowledged, the Re-configuration Timer MUST be stopped. If
configuration Request Sequence Number, the processing of the Re- the timer was not running for the Re-configuration Request
configuration Response Parameter is complete. Sequence Number, the processing of the Re-configuration Response
Parameter is complete.
H2: If the Result field indicates 'In progress', the timer for the H2: If the Result field indicates "In progress", the timer for the
Re-configuration Request Sequence Number is started again. If Re-configuration Request Sequence Number is started again. If
the timer runs off, the RE-CONFIG chunk MUST be retransmitted the timer runs out, the RE-CONFIG chunk MUST be retransmitted
but the corresponding error counters MUST NOT be incremented. but the corresponding error counters MUST NOT be incremented.
H3: If the Result field does not indicate successful processing the H3: If the Result field does not indicate successful processing, the
processing of this response is complete. processing of this response is complete.
H4: If the request was an Outgoing SSN Reset Request the affected H4: If the request was an Outgoing SSN Reset Request, the affected
streams MUST now be reset and all queued data should be streams MUST now be reset and all queued data should now be
processed now and assigning of stream sequence numbers is processed. The assigning of SSNs is allowed again.
allowed again.
H5: If the request was an SSN/TSN Reset Request new data MUST be H5: If the request was an SSN/TSN Reset Request, new data MUST be
sent from Receiver's next TSN and beginning with stream sequence sent from the Receiver's Next TSN, beginning with SSN 0 for all
number 0 for all outgoing streams. All incoming streams MUST be outgoing streams. All incoming streams MUST be reset to 0 as
reset to 0 as the next expected stream sequence number. The the next expected SSN. The peer will send DATA chunks starting
peer will send DATA chunks starting with Sender's next TSN. with the Sender's Next TSN.
H6: If the request was to add outgoing streams, the endpoint MUST H6: If the request was to add outgoing streams, the endpoint MUST
add the additional streams to the association. Note that an add the additional streams to the association. Note that an
implementation may allocate the memory at the time of the implementation may allocate the memory at the time of the
request, but it MUST NOT use the streams until the peer has request, but it MUST NOT use the streams until the peer has
responded with a positive acknowledgment. responded with a positive acknowledgment.
6. Socket API Considerations 6. Sockets API Considerations
This section describes how the socket API defined in This section describes how the sockets API defined in [RFC6458] needs
[I-D.ietf-tsvwg-sctpsocket] needs to be extended to make the features to be extended to make the features of SCTP re-configuration
of SCTP re-configuration available to the application. available to the application.
Please note that this section is informational only. Please note that this section is informational only.
6.1. Events 6.1. Events
When the SCTP_ASSOC_CHANGE notification is delivered and both peers When the SCTP_ASSOC_CHANGE notification is delivered and both peers
support the extension described in this document, support the extension described in this document,
SCTP_ASSOC_SUPPORTS_RE_CONFIG should be listed in the sac_info field. SCTP_ASSOC_SUPPORTS_RE_CONFIG should be listed in the sac_info field.
The union sctp_notification {} is extended to contain three new The union sctp_notification {} is extended to contain three new
fields: sn_strreset_event, sn_assocreset_event, and fields: sn_strreset_event, sn_assocreset_event, and
sn_strchange_event: sn_strchange_event:
union sctp_notification { union sctp_notification {
struct { struct sctp_tlv {
uint16_t sn_type; uint16_t sn_type; /* Notification type. */
uint16_t sn_flags; uint16_t sn_flags;
uint32_t sn_length; uint32_t sn_length;
} sn_header; } sn_header;
... ...
struct sctp_stream_reset_event sn_strreset_event; struct sctp_stream_reset_event sn_strreset_event;
struct sctp_assoc_reset_event sn_assocreset_event; struct sctp_assoc_reset_event sn_assocreset_event;
struct sctp_stream_change_event sn_strchange_event; struct sctp_stream_change_event sn_strchange_event;
... ...
} }
skipping to change at page 23, line 46 skipping to change at page 24, line 21
The event delivered has the following structure: The event delivered has the following structure:
struct sctp_stream_reset_event { struct sctp_stream_reset_event {
uint16_t strreset_type; uint16_t strreset_type;
uint16_t strreset_flags; uint16_t strreset_flags;
uint32_t strreset_length; uint32_t strreset_length;
sctp_assoc_t strreset_assoc_id; sctp_assoc_t strreset_assoc_id;
uint16_t strreset_stream_list[]; uint16_t strreset_stream_list[];
}; };
strreset_type: It should be SCTP_STREAM_RESET_EVENT. strreset_type: This field should be SCTP_STREAM_RESET_EVENT.
strreset_flags: This field is formed from the bitwise OR of one or strreset_flags: This field is formed from the bitwise OR of one or
more of the following currently defined flags: more of the following currently defined flags:
SCTP_STREAM_RESET_INCOMING_SSN: The stream identifiers given in SCTP_STREAM_RESET_INCOMING_SSN: The stream identifiers given in
strreset_stream_list[] refer to incoming streams of the strreset_stream_list[] refer to incoming streams of the
endpoint. endpoint.
SCTP_STREAM_RESET_OUTGOING_SSN: The stream identifiers given in SCTP_STREAM_RESET_OUTGOING_SSN: The stream identifiers given in
strreset_stream_list[] refer to outgoing streams of the strreset_stream_list[] refer to outgoing streams of the
skipping to change at page 24, line 26 skipping to change at page 24, line 47
SCTP_STREAM_RESET_FAILED: The corresponding request failed. SCTP_STREAM_RESET_FAILED: The corresponding request failed.
At least one of SCTP_STREAM_RESET_INCOMING_SSN and At least one of SCTP_STREAM_RESET_INCOMING_SSN and
SCTP_STREAM_RESET_OUTGOING_SSN is set. SCTP_STREAM_RESET_DENIED SCTP_STREAM_RESET_OUTGOING_SSN is set. SCTP_STREAM_RESET_DENIED
and SCTP_STREAM_RESET_FAILED are mutually exclusive. If the and SCTP_STREAM_RESET_FAILED are mutually exclusive. If the
request was successful, none of these are set. request was successful, none of these are set.
strreset_length: This field is the total length in bytes of the strreset_length: This field is the total length in bytes of the
delivered event, including the header. delivered event, including the header.
strreset_assoc_id: The association id field, holds the identifier strreset_assoc_id: This association id field holds the identifier
for the association. All notifications for a given association for the association. All notifications for a given association
have the same association identifier. For one-to-one style have the same association identifier. For one-to-one style
sockets, this field is ignored. sockets, this field is ignored.
strreset_stream_list: The list of stream identifiers this event strreset_stream_list: This is the list of stream identifiers to
refers to. An empty list identifies all streams as being reset. which this event refers. An empty list identifies all streams as
Depending on strreset_flags the identifiers refer to incoming or being reset. Depending on strreset_flags, the identifiers refer
outgoing streams or both. to incoming or outgoing streams, or both.
6.1.2. Association Reset Event 6.1.2. Association Reset Event
The event delivered has the following structure: The event delivered has the following structure:
struct sctp_assoc_reset_event { struct sctp_assoc_reset_event {
uint16_t assocreset_type; uint16_t assocreset_type;
uint16_t assocreset_flags; uint16_t assocreset_flags;
uint32_t assocreset_length; uint32_t assocreset_length;
sctp_assoc_t assocreset_assoc_id; sctp_assoc_t assocreset_assoc_id;
uint32_t assocreset_local_tsn; uint32_t assocreset_local_tsn;
uint32_t assocreset_remote_tsn; uint32_t assocreset_remote_tsn;
}; };
assocreset_type: It should be SCTP_ASSOC_RESET_EVENT.
assocreset_type: This field should be SCTP_ASSOC_RESET_EVENT.
assocreset_flags: This field is formed from the bitwise OR of one or assocreset_flags: This field is formed from the bitwise OR of one or
more of the following currently defined flags: more of the following currently defined flags:
SCTP_ASSOC_RESET_DENIED: The corresponding outgoing request was SCTP_ASSOC_RESET_DENIED: The corresponding outgoing request was
denied by the peer. denied by the peer.
SCTP_ASSOC_RESET_FAILED: The corresponding outgoing request SCTP_ASSOC_RESET_FAILED: The corresponding outgoing request
failed. failed.
SCTP_ASSOC_RESET_DENIED and SCTP_ASSOC_RESET_FAILED are mutual SCTP_ASSOC_RESET_DENIED and SCTP_ASSOC_RESET_FAILED are mutually
exclusive. If the request was successful, none of these are set. exclusive. If the request was successful, none of these are set.
assocreset_length: This field is the total length in bytes of the assocreset_length: This field is the total length in bytes of the
delivered event, including the header. delivered event, including the header.
assocreset_assoc_id: The association id field, holds the identifier assocreset_assoc_id: This association id field holds the identifier
for the association. All notifications for a given association for the association. All notifications for a given association
have the same association identifier. For one-to-one style have the same association identifier. For one-to-one style
sockets, this field is ignored. sockets, this field is ignored.
assocreset_local_tsn: The next TSN used by the endpoint. assocreset_local_tsn: This field is the next TSN used by the
endpoint.
assocreset_remote_tsn: The next TSN used by the peer. assocreset_remote_tsn: This field is the next TSN used by the peer.
6.1.3. Stream Change Event 6.1.3. Stream Change Event
The event delivered has the following structure: The event delivered has the following structure:
struct sctp_stream_change_event { struct sctp_stream_change_event {
uint16_t strchange_type; uint16_t strchange_type;
uint16_t strchange_flags; uint16_t strchange_flags;
uint32_t strchange_length; uint32_t strchange_length;
sctp_assoc_t strchange_assoc_id; sctp_assoc_t strchange_assoc_id;
uint16_t strchange_instrms; uint16_t strchange_instrms;
uint16_t strchange_outstrms; uint16_t strchange_outstrms;
}; };
strchange_type: It should be SCTP_STREAM_CHANGE_EVENT. strchange_type: This field should be SCTP_STREAM_CHANGE_EVENT.
strchange_flags: This field is formed from the bitwise OR of one or strchange_flags: This field is formed from the bitwise OR of one or
more of the following currently defined flags: more of the following currently defined flags:
SCTP_STREAM_CHANGE_DENIED: The corresponding request was denied SCTP_STREAM_CHANGE_DENIED: The corresponding request was denied
by the peer. by the peer.
SCTP_STREAM_CHANGE_FAILED: The corresponding request failed. SCTP_STREAM_CHANGE_FAILED: The corresponding request failed.
SCTP_STREAM_CHANGE_DENIED and SCTP_STREAM_CHANGE_FAILED are mutual SCTP_STREAM_CHANGE_DENIED and SCTP_STREAM_CHANGE_FAILED are
exclusive. If the request was successful, none of these are set. mutually exclusive. If the request was successful, none of these
are set.
strchange_length: This field is the total length in bytes of the strchange_length: This field is the total length in bytes of the
delivered event, including the header. delivered event, including the header.
strchange_assoc_id: The association id field, holds the identifier strchange_assoc_id: This association id field holds the identifier
for the association. All notifications for a given association for the association. All notifications for a given association
have the same association identifier. For one-to-one style have the same association identifier. For one-to-one style
sockets, this field is ignored. sockets, this field is ignored.
strchange_instrms: The number of streams that the peer is allowed to strchange_instrms: The number of streams that the peer is allowed to
use outbound. use outbound.
strchange_outstrms: The number of streams that the endpoint is strchange_outstrms: The number of streams that the endpoint is
allowed to use outbound. allowed to use outbound.
6.2. Event Subscription 6.2. Event Subscription
Subscribing to events as described in [I-D.ietf-tsvwg-sctpsocket] Subscribing to events as described in [RFC6458] uses a setsockopt()
uses a setsockopt() call with the SCTP_EVENT socket option. This call with the SCTP_EVENT socket option. This option takes the
option takes the following structure that specifies the association, following structure, which specifies the association, the event type
the event type (using the same value found in the event type field) (using the same value found in the event type field), and an on/off
and an on/off boolean. boolean.
struct sctp_event { struct sctp_event {
sctp_assoc_t se_assoc_id; sctp_assoc_t se_assoc_id;
uint16_t se_type; uint16_t se_type;
uint8_t se_on; uint8_t se_on;
}; };
The user fills in the se_type with the same value found in the 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 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 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 this event on (this field is ignored for one-to-one style sockets) or
one of the reserved constant values defined in one of the reserved constant values defined in [RFC6458]. Finally,
[I-D.ietf-tsvwg-sctpsocket]. Finally the se_on field is set with a 1 the se_on field is set with a 1 to enable the event or a 0 to disable
to enable the event or a 0 to disable the event. the event.
6.3. Socket Options 6.3. Socket Options
The following table describes the new socket options which make the Table 5 describes the new socket options that make the
re-configuration features accessible to the user. They all use re-configuration features accessible to the user. They all use
IPPROTO_SCTP as their level. IPPROTO_SCTP as their level.
If a call to setsockopt() is used to issue a Re-configuration request If a call to setsockopt() is used to issue a re-configuration request
while the Re-configuration timer is running, setsockopt() will return while the Re-configuration timer is running, setsockopt() will return
-1 and error is set to EALREADY. -1, and error is set to EALREADY.
+--------------------------+---------------------------+-----+-----+ +--------------------------+---------------------------+-----+-----+
| option name | data type | get | set | | option name | data type | get | set |
+--------------------------+---------------------------+-----+-----+ +--------------------------+---------------------------+-----+-----+
| SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value | X | X | | SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value | X | X |
| SCTP_RESET_STREAMS | struct sctp_reset_streams | | X | | SCTP_RESET_STREAMS | struct sctp_reset_streams | | X |
| SCTP_RESET_ASSOC | sctp_assoc_t | | X | | SCTP_RESET_ASSOC | sctp_assoc_t | | X |
| SCTP_ADD_STREAMS | struct sctp_add_streams | | X | | SCTP_ADD_STREAMS | struct sctp_add_streams | | X |
+--------------------------+---------------------------+-----+-----+ +--------------------------+---------------------------+-----+-----+
Table 5 Table 5
6.3.1. Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET) 6.3.1. Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET)
This option allows a user to control whether the SCTP implementation This option allows a user to control whether the SCTP implementation
processes or denies incoming requests in STREAM_RESET chunks. processes or denies incoming requests in STREAM_RESET chunks.
The default is to deny all incoming requests. The default is to deny all incoming requests.
To set or get this option the user fills in the following structure: To set or get this option, the user fills in the following structure:
struct sctp_assoc_value { struct sctp_assoc_value {
sctp_assoc_t assoc_id; sctp_assoc_t assoc_id;
uint32_t assoc_value; uint32_t assoc_value;
}; };
assoc_id: This parameter is ignored for one-to-one style sockets. assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets this parameter indicates which For one-to-many style sockets, this parameter indicates which
association the user is performing an action upon. association the user is performing an action upon.
assoc_value: It is formed from the bitwise OR of one or more of the assoc_value: This field is formed from the bitwise OR of one or more
following currently defined flags: of the following currently defined flags:
SCTP_ENABLE_RESET_STREAM_REQ: Process received Incoming/Outgoing SCTP_ENABLE_RESET_STREAM_REQ: Process received Incoming/Outgoing
SSN Reset Requests if this flag is set, deny them if not. SSN Reset Requests if this flag is set; deny them if not.
SCTP_ENABLE_RESET_ASSOC_REQ: Process received SSN/TSN Reset SCTP_ENABLE_RESET_ASSOC_REQ: Process received SSN/TSN Reset
Requests if this flag is set, deny them if not. Requests if this flag is set; deny them if not.
SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing
Streams Requests if this flag is set, deny them if not. Streams Requests if this flag is set; deny them if not.
The default value is !(SCTP_ENABLE_RESET_STREAM_REQ| The default value is !(SCTP_ENABLE_RESET_STREAM_REQ|
SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ). SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ).
Please note that using the option does not have any impact on Please note that using the option does not have any impact on
subscribing to any related events. subscribing to any related events.
6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS) 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 This option allows the user to request the reset of incoming and/or
outgoing streams. outgoing streams.
To set or get this option the user fills in the following structure: To set or get this option, the user fills in the following structure:
struct sctp_reset_streams { struct sctp_reset_streams {
sctp_assoc_t srs_assoc_id; sctp_assoc_t srs_assoc_id;
uint16_t srs_flags; uint16_t srs_flags;
uint16_t srs_number_streams; uint16_t srs_number_streams;
uint16_t srs_stream_list[]; uint16_t srs_stream_list[];
}; };
srs_assoc_id: This parameter is ignored for one-to-one style srs_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets this parameter indicates sockets. For one-to-many style sockets, this parameter indicates
which association the user is performing an action upon. which association the user is performing an action upon.
srs_flags: This parameter describes which class of streams is reset. 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 It is formed from the bitwise OR of one or more of the following
currently defined flags: currently defined flags:
* SCTP_STREAM_RESET_INCOMING * SCTP_STREAM_RESET_INCOMING
* SCTP_STREAM_RESET_OUTGOING * SCTP_STREAM_RESET_OUTGOING
srs_number_streams: This parameter is the number of elements in the 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 srs_stream_list. If it is zero, the operation is performed on all
streams. streams.
srs_stream_list: This parameter contains a list of stream srs_stream_list: This parameter contains a list of stream
identifiers the operation is performed upon. It contains identifiers the operation is performed upon. It contains
srs_number_streams elements. If it is empty, the operation is srs_number_streams elements. If it is empty, the operation is
performed on all streams. Depending on srs_flags the identifiers performed on all streams. Depending on srs_flags, the identifiers
refer to incoming or outgoing streams or both. refer to incoming or outgoing streams, or both.
6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) 6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC)
This option allows a user to request the reset of the SSN/TSN. 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 To set this option, the user provides an option_value of type
sctp_assoc_t. sctp_assoc_t.
On one-to-one style sockets the option_value is ignored. For one-to- On one-to-one style sockets, the option_value is ignored. For one-
many style sockets the option_value is the association identifier of to-many style sockets, the option_value is the association identifier
the association the action is to be performed upon. of the association the action is to be performed upon.
6.3.4. Add Incoming and/or Outgoing Streams (SCTP_ADD_STREAMS) 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 This option allows a user to request the addition of a number of
incoming and/or outgoing streams. incoming and/or outgoing streams.
To set this option the user fills in the following structure: To set this option, the user fills in the following structure:
struct sctp_add_streams { struct sctp_add_streams {
sctp_assoc_t sas_assoc_id; sctp_assoc_t sas_assoc_id;
uint16_t sas_instrms; uint16_t sas_instrms;
uint16_t sas_outstrms; uint16_t sas_outstrms;
}; };
sas_assoc_id: This parameter is ignored for one-to-one style sas_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets this parameter indicates sockets. For one-to-many style sockets, this parameter indicates
which association the user is performing an action upon. which association the user is performing an action upon.
sas_instrms: This parameter is the number of incoming streams to sas_instrms: This parameter is the number of incoming streams
add. to add.
sas_outstrms: This parameter is the number of outgoing streams to sas_outstrms: This parameter is the number of outgoing streams
add. to add.
An endpoint can limit the number of incoming and outgoing streams by An endpoint can limit the number of incoming and outgoing streams by
using the sinit_max_instreams field in the struct sctp_initmsg{} when using the sinit_max_instreams field in the struct sctp_initmsg{} when
issuing an SCTP_INIT socket option, as defined in issuing an SCTP_INIT socket option, as defined in [RFC6458]. An
[I-D.ietf-tsvwg-sctpsocket]. An incoming request asking for more incoming request asking for more streams than allowed will be denied.
streams than allowed will be denied.
7. Security Considerations 7. Security Considerations
The SCTP socket API as described in [I-D.ietf-tsvwg-sctpsocket] The SCTP sockets API as described in [RFC6458] exposes the sequence
exposes the sequence numbers of received DATA chunks to the numbers of received DATA chunks to the application. An application
application. An application might expect them to be monotonically might expect them to be monotonically increasing. When using the
increasing. When using the re-configuration extension this might no re-configuration extension, this might no longer be true. Therefore,
longer be true. Therefore the applications must enable this the applications must enable this extension explicitly before it is
extension explicitly before it is used. In addition, applications used. In addition, applications must subscribe explicitly to
must subscribe explicitly to notifications related to the re- notifications related to the re-configuration extension before
configuration extension before receiving them. receiving them.
SCTP associations are protected against blind attackers by using the SCTP associations are protected against blind attackers by using
verification tags. This is still valid when using the re- verification tags. This is still valid when using the
configuration extension. Therefore this extension does not add any re-configuration extension. Therefore, this extension does not add
additional security risk to SCTP in relation to blind attackers. any additional security risk to SCTP in relation to blind attackers.
When the both sequence numbers are reset, the maximum segment When both the SSN and TSN are reset, the maximum segment lifetime is
lifetime is used to avoid the wrap-around for the TSN. used to avoid TSN wrap-around.
8. IANA Considerations 8. IANA Considerations
[NOTE to RFC-Editor: This document (RFC 6525) is the reference for all registrations
described in this section. The changes are described below.
"RFCXXXX" is to be replaced by the RFC number you assign this
document.
]
[NOTE to RFC-Editor:
The suggested values for the chunk type and the chunk parameter
types are tentative and to be confirmed by IANA.
]
This document (RFCXXXX) is the reference for all registrations
described in this section. The suggested changes are described
below.
8.1. A New Chunk Type 8.1. A New Chunk Type
A chunk type has to be assigned by IANA. It is suggested to use the A chunk type has been assigned by IANA. The values given in Table 1
values given in Table 1. IANA should assign this value from the pool have been used. IANA has assigned this value from the pool of chunks
of chunks with the upper two bits set to '10'. with the upper two bits set to '10'.
This requires an additional line in the "Chunk Types" registry for This has added a line in the "Chunk Types" registry for SCTP:
SCTP:
Chunk Types Chunk Types
ID Value Chunk Type Reference ID Value Chunk Type Reference
----- ---------- --------- ----- ---------- ---------
130 Re-configuration Chunk (RE-CONFIG) [RFCXXXX] 130 Re-configuration Chunk (RE-CONFIG) [RFC6525]
The registration table as defined in [RFC6096] for the chunk flags of The registration table as defined in [RFC6096] for the chunk flags of
this chunk type is empty. this chunk type is empty.
8.2. Six New Chunk Parameter Types 8.2. Six New Chunk Parameter Types
Six chunk parameter types have to be assigned by IANA. It is Six chunk parameter types have been assigned by IANA. It the values
suggested to use the values given in Table 2. IANA should assign given in Table 2 have been used. IANA has assigned these values from
these values from the pool of parameters with the upper two bits set the pool of parameters with the upper two bits set to '00'.
to '00'.
This requires six additional lines in the "Chunk Parameter Types" Six additional lines in the "Chunk Parameter Types" registry for SCTP
registry for SCTP: have been added:
Chunk Parameter Types Chunk Parameter Types
ID Value Chunk Parameter Type Reference ID Value Chunk Parameter Type Reference
-------- ------------------------------------------------ --------- -------- ------------------------------------------------ ---------
13 Outgoing SSN Reset Request Parameter [RFCXXXX] 13 Outgoing SSN Reset Request Parameter [RFC6525]
14 Incoming SSN Reset Request Parameter [RFCXXXX] 14 Incoming SSN Reset Request Parameter [RFC6525]
15 SSN/TSN Reset Request Parameter [RFCXXXX] 15 SSN/TSN Reset Request Parameter [RFC6525]
16 Re-configuration Response Parameter [RFCXXXX] 16 Re-configuration Response Parameter [RFC6525]
17 Add Outgoing Streams Request Parameter [RFCXXXX] 17 Add Outgoing Streams Request Parameter [RFC6525]
18 Add Incoming Streams Request Parameter [RFCXXXX] 18 Add Incoming Streams Request Parameter [RFC6525]
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch, The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch,
Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and
Vlad Yasevich for there invaluable comments. Vlad Yasevich for their invaluable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004. Partial Reliability Extension", RFC 3758, May 2004.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, Dynamic Address Reconfiguration", RFC 5061,
September 2007. September 2007.
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Chunk Flags Registration", RFC 6096, Protocol (SCTP) Chunk Flags Registration", RFC 6096,
January 2011. January 2011.
10.2. Informative References 10.2. Informative References
[I-D.ietf-tsvwg-sctpsocket] [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control
Yasevich, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-32 (work in progress),
October 2011.
Appendix A. Examples of the Re-configuration procedures Appendix A. Examples of the Reconfiguration Procedures
Please note that this appendix is informational only. Please note that this appendix is informational only.
The following message flows between an Endpoint A and an Endpoint Z The following message flows between Endpoints E-A and E-Z illustrate
illustrate the described procedures. The time progresses in downward the described procedures. The time progresses in downward direction.
direction.
The following example illustrates an Endpoint A resetting stream 1 The following example illustrates E-A resetting streams 1 and 2 for
and 2 for just its outgoing streams. just its outgoing streams.
E-A E-Z E-A E-Z
----------[RE-CONFIG(OUT-REQ:X/1,2)]----------> ----------[RE-CONFIG(OUT-REQ:X/1,2)]---------->
<-------------[RE-CONFIG(RESP:X)]-------------- <-------------[RE-CONFIG(RESP:X)]--------------
The following example illustrates an Endpoint A resetting stream 1 The following example illustrates E-A resetting streams 1 and 2 for
and 2 for just its incoming streams. just its incoming streams.
E-A E-Z E-A E-Z
-----------[RE-CONFIG(IN-REQ:X/1,2)]----------> -----------[RE-CONFIG(IN-REQ:X/1,2)]---------->
<--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]---------- <--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]----------
-------------[RE-CONFIG(RESP:Y)]--------------> -------------[RE-CONFIG(RESP:Y)]-------------->
The following example illustrates an Endpoint A resetting all streams The following example illustrates E-A resetting all streams in both
in both directions. directions.
E-A E-Z E-A E-Z
-----[RE-CONFIG(OUT-REQ:X,Y-1|IN-REQ:X+1)]----> -----[RE-CONFIG(OUT-REQ:X,Y-1|IN-REQ:X+1)]---->
<------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]------- <------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]-------
-------------[RE-CONFIG(RESP:Y)]--------------> -------------[RE-CONFIG(RESP:Y)]-------------->
The following example illustrates an Endpoint A requesting the The following example illustrates E-A requesting that the streams and
streams and TSNs be reset. At the completion E-A has the new sending TSNs be reset. At completion, E-A has the new sending TSN (selected
TSN (selected by the peer) of B and E-Z has the new sending TSN of A by the peer) of B, and E-Z has the new sending TSN of A (also
(also selected by the peer). selected by the peer).
E-A E-Z E-A E-Z
------------[RE-CONFIG(TSN-REQ:X)]------------> ------------[RE-CONFIG(TSN-REQ:X)]------------>
<-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]----- <-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]-----
The following example illustrates an Endpoint A requesting to add 3 The following example illustrates E-A requesting the addition of 3
additional outgoing streams. outgoing streams.
E-A E-Z E-A E-Z
--------[RE-CONFIG(ADD_OUT_STRMS:X/3)]--------> --------[RE-CONFIG(ADD_OUT_STRMS:X/3)]-------->
<-------------[RE-CONFIG(RESP:X)]-------------- <-------------[RE-CONFIG(RESP:X)]--------------
The following example illustrates an Endpoint A requesting to add 3 The following example illustrates E-A requesting the addition of 3
additional incoming streams. incoming streams.
E-A E-Z E-A E-Z
---------[RE-CONFIG(ADD_IN_STRMS:X/3)]--------> ---------[RE-CONFIG(ADD_IN_STRMS:X/3)]-------->
<----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y,X/3)]------ <----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y,X/3)]------
-------------[RE-CONFIG(RESP:Y)]--------------> -------------[RE-CONFIG(RESP:Y)]-------------->
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Adara Networks Adara Networks
Chapin, SC 29036 Chapin, SC 29036
USA USA
Email: randall@lakerest.net EMail: randall@lakerest.net
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
DE DE
Email: tuexen@fh-muenster.de EMail: tuexen@fh-muenster.de
Peter Lei Peter Lei
Cisco Systems, Inc. Cisco Systems, Inc.
8735 West Higgins Road 9501 Technology Blvd.
Suite 300 West Office Center
Chicago, IL 60631 Rosemont, IL 60018
USA USA
Email: peterlei@cisco.com EMail: peterlei@cisco.com
 End of changes. 208 change blocks. 
601 lines changed or deleted 574 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/