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