[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-stewart-tsvwg-sctpstrrst) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 6525

Network Working Group                                         R. Stewart
Internet-Draft                                                    Huawei
Intended status: Standards Track                                  P. Lei
Expires: March 30, 2011                              Cisco Systems, Inc.
                                                               M. Tuexen
                                      Muenster Univ. of Applied Sciences
                                                      September 26, 2010


   Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
                  draft-ietf-tsvwg-sctp-strrst-06.txt

Abstract

   Many applications that use SCTP want the ability to "reset" a stream.
   The intention of resetting a stream is to set the numbering sequence
   of the stream back to 'zero' with a corresponding notification to the
   upper layer that this has been performed.  The applications that want
   this feature want it so that they can "re-use" streams for different
   purposes but still utilize the stream sequence number so that the
   application can track the message flows.  Thus, without this feature,
   a new use of an old stream would result in message numbers greater
   than expected unless there is a protocol mechanism to "reset the
   streams back to zero".  This document also includes methods for
   resetting the transport 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
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   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
   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."

   This Internet-Draft will expire on March 30, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Stewart, et al.          Expires March 30, 2011                 [Page 1]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  STREAM RESET Chunk . . . . . . . . . . . . . . . . . . . .  5
   4.  New Parameter Types  . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Outgoing SSN Reset Request Parameter . . . . . . . . . . .  6
     4.2.  Incoming SSN Reset Request Parameter . . . . . . . . . . .  8
     4.3.  SSN/TSN Reset Request Parameter  . . . . . . . . . . . . .  9
     4.4.  Stream Reset Response Parameter  . . . . . . . . . . . . .  9
     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  . . 12
       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  . . . . . . . . . . . . . . . . . . 14
       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  . . . . . . . . . . . . . . 15
     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  . . . . . . . . . . . . . . . . . . 17
       5.2.5.  Receiver Side Procedures for the Add Outgoing
               Streams Request Parameter  . . . . . . . . . . . . . . 18
       5.2.6.  Receiver Side Procedures for the Stream Reset
               Response Parameter . . . . . . . . . . . . . . . . . . 18



Stewart, et al.          Expires March 30, 2011                 [Page 2]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


     5.3.  Examples of the Stream Reset procedures  . . . . . . . . . 19
   6.  Socket API Considerations  . . . . . . . . . . . . . . . . . . 20
     6.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       6.1.1.  Stream Reset Event . . . . . . . . . . . . . . . . . . 21
       6.1.2.  Association Reset Event  . . . . . . . . . . . . . . . 22
       6.1.3.  Stream Change Event  . . . . . . . . . . . . . . . . . 23
     6.2.  Event Subscription . . . . . . . . . . . . . . . . . . . . 24
     6.3.  Socket Options . . . . . . . . . . . . . . . . . . . . . . 25
       6.3.1.  Enable/Disable Stream Reset
               (SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 25
       6.3.2.  Reset Incoming and/or Outgoing Streams
               (SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 26
       6.3.3.  Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 27
       6.3.4.  Add Outgoing Streams (SCTP_ADD_OUT_STREAMS)  . . . . . 27
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
     8.1.  A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 28
     8.2.  Five New Parameter Types . . . . . . . . . . . . . . . . . 29
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 29
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     10.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30




























Stewart, et al.          Expires March 30, 2011                 [Page 3]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


1.  Introduction

   Many applications that use SCTP want the ability to "reset" a stream.
   The intention of resetting a stream is to start the numbering
   sequence of the stream back to 'zero' with a corresponding
   notification to the upper layer that this has been performed.  The
   applications that want this feature want to "re-use" streams for
   different purposes but still utilize the stream sequence number so
   that the application can track the message flows.  Thus, without this
   feature, a new use of an old stream would result in message numbers
   greater than expected unless there is a protocol mechanism to "reset
   the streams back to zero".  This document also includes methods for
   resetting the transport sequence numbers, adding additional streams
   and resetting all stream sequence numbers.


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  New Chunk Type

   This section defines the new chunk type that will be used to reset
   streams.  Table 1 illustrates the new chunk type.

            +------------+-----------------------------------+
            | Chunk Type | Chunk Name                        |
            +------------+-----------------------------------+
            | 0x82       | Stream Reset Chunk (STREAM_RESET) |
            +------------+-----------------------------------+

                                  Table 1

   It should be noted that the format of the STREAM_RESET chunk requires
   the receiver to ignore the chunk if it is not understood and continue
   processing all chunks that follow.  This is accomplished by the use
   of the upper bits of the chunk type as described in section 3.2 of
   [RFC4960].

   All transported integer numbers are in "network byte order" a.k.a.,
   Big Endian, unless otherwise noted.







Stewart, et al.          Expires March 30, 2011                 [Page 4]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


3.1.  STREAM RESET Chunk

   This document adds one new chunk type to SCTP.  The chunk has the
   following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 0x82   |  Chunk Flags  |      Chunk Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Stream Reset Parameter                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Stream Reset Parameter (optional)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Chunk Type: 1 byte (unsigned integer)
      This field holds the IANA defined chunk type for the STREAM RESET
      chunk.

   Chunk Flags: 1 byte (unsigned integer)
      This field is set to 0 by the sender and ignored by the receiver.

   Chunk Length: 2 bytes (unsigned integer)
      This field holds the length of the chunk, including the Chunk
      Type, Chunk Flags and Chunk Length.

   Stream Reset Parameter
      This field holds a Stream Reset Request Parameter or a Stream
      Reset Response Parameter.

   Note that 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 March 30, 2011                 [Page 5]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   8.  Stream Reset Response Parameter, Stream Reset Response Parameter.

   If a sender transmits an unsupported combination, the receiver SHOULD
   send an ERROR chunk with a Protocol Violation cause as defined in
   section 3.3.10.13 of [RFC4960]).


4.  New Parameter Types

   This section defines the new parameter types that will be used in the
   STREAM_RESET chunk.  Table 2 illustrates the new parameter types.

        +----------------+----------------------------------------+
        | Parameter Type | Parameter Name                         |
        +----------------+----------------------------------------+
        | 0x000d         | Outgoing SSN Reset Request Parameter   |
        | 0x000e         | Incoming SSN Reset Request Parameter   |
        | 0x000f         | SSN/TSN Reset Request Parameter        |
        | 0x0010         | Stream Reset Response Parameter        |
        | 0x0011         | Add Outgoing Streams Request Parameter |
        +----------------+----------------------------------------+

                                  Table 2

   It should be noted that the parameter format requires the receiver to
   stop processing the parameter and not to process any further
   parameters within the chunk if the parameter type is not recognized.
   This is accomplished by the use of the upper bits of the parameter
   type as described in section 3.2.1 of [RFC4960].

   All transported integer numbers are in "network byte order" a.k.a.,
   Big Endian, unless otherwise noted.

4.1.  Outgoing SSN Reset Request Parameter

   This parameter is used by the sender to request the reset of some or
   all outgoing streams.














Stewart, et al.          Expires March 30, 2011                 [Page 6]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 0x000d   | Parameter Length = 16 + 2 * N |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             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 in bytes of the parameter; the value
      MUST be 16 + 2 * N.

   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 whenever sending a new
      Stream Reset Request parameter.

   Stream Reset Response Sequence Number: 4 bytes (unsigned integer)
      When this Outgoing SSN Reset Request Parameter is sent in response
      to an Incoming SSN Reset Request Parameter this parameter is also
      an implicit response to the incoming request.  Then this field
      holds the Stream Reset Request Sequence Number of the incoming
      request.  In other cases it holds the next expected Stream Reset
      Request Sequence Number minus 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.







Stewart, et al.          Expires March 30, 2011                 [Page 7]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   Stream Number 1..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.

   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 resets
   some or all of its outgoing streams.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 0x000e   |  Parameter Length = 8 + 2 * N |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            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 in bytes of the parameter; the value
      MUST be 8 + 2 * N.

   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 whenever sending a new
      Stream Reset Request parameter.

   Stream Number 1..N: 2 bytes (unsigned integer)
      This optional field, if included, is used to indicate specific
      streams that are to be reset.  If no streams are listed, then all
      streams are to be reset.

   This parameter can appear in a STREAM RESET chunk.  This parameter



Stewart, et al.          Expires March 30, 2011                 [Page 8]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   MUST NOT appear in any other chunk type.

4.3.  SSN/TSN Reset Request Parameter

   This parameter is used by the sender to request a reset of the TSN
   and SSN numbering of all streams.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 0x000f   |      Parameter Length = 8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           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 in bytes of the parameter; the value
      MUST be 8.

   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 whenever sending a new
      Stream Reset Request parameter.

   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.














Stewart, et al.          Expires March 30, 2011                 [Page 9]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 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.

   Parameter Type Length: 2 bytes (unsigned integer)
      This field holds the length in bytes of the parameter; the value
      MUST be 12 if the optional fields are not present and 20
      otherwise.

   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






Stewart, et al.          Expires March 30, 2011                [Page 10]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   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 an additional
   number of outgoing streams (i.e. the receiver's incoming streams) be
   added to the association.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 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 in bytes of the parameter; the value
      MUST be 12.

   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 whenever sending a new
      Stream Reset Request parameter.

   Number of new streams: 2 bytes (unsigned integer)
      This value holds the number of additional outgoing streams the
      sender requests to be added to the association.  Streams are added
      in order and are consecutive, e.g. if an association has four



Stewart, et al.          Expires March 30, 2011                [Page 11]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


      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 MAY 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 composed of a Type
   Length Value (TLV) parameters.

5.1.1.  Sender Side Procedures for the Stream Reset Chunk

   This SCTP extension uses the Supported Extensions Parameter defined
   in [RFC5061] for negotiating the support for it.

   An SCTP endpoint supporting this extension MUST include the chunk
   type of the STREAM_RESET chunk in the Supported Extensions Parameter
   in either the INIT or INIT-ACK.  Before sending a Stream Reset Chunk
   the sender MUST ensure that the peer advertised support for the
   stream reset extension.  If the chunk type of the STREAM_RESET chunk
   does not appear in the supported extensions list of chunks, then the
   sender MUST NOT send any stream reset request to the peer and any
   request by the application for such service SHOULD be responded to
   with an appropriate error indicating the peer SCTP stack does not
   support the stream reset extension.

   After packaging the Stream Reset Chunk and sending it to the peer the
   sender MUST start a 'Stream Reset Timer' if 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 expires, besides doubling the value,
   the sender MUST retransmit the Stream Reset Chunk, increment the
   appropriate error counts (both for the association and the



Stewart, et al.          Expires March 30, 2011                [Page 12]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   destination), and perform threshold management possibly destroying
   the association if SCTP retransmission thresholds are exceeded.

5.1.2.  Sender Side Procedures for the Outgoing SSN Reset Request
        Parameter

   When an SCTP sender wants to reset the SSNs of some or all outgoing
   streams it can send an Outgoing SSN Reset Request Parameter provided
   that the 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 not known
        whether the receiver of the request will accept or deny it and
        moreover, a lost request might cause an out-of-sequence error in
        a stream that the receiver is not yet prepared to handle.

   A2:  The sender MUST assign the next stream reset request sequence
        number and put it into the Stream Reset Request Sequence Number
        field of the Outgoing SSN Reset Request Parameter.  The next
        stream reset request sequence number MUST then be incremented by
        1.

   A3:  The sender fills in the TSN it last assigned.

   A4:  If this Outgoing SSN Reset Request Parameter is sent in response
        to an Incoming SSN Reset Request Parameter the Stream Numbers
        are copied from the Incoming SSN Reset Request Parameter to the
        Outgoing SSN Reset Request Parameter.  The Stream Reset Response
        Sequence Number of the Outgoing SSN Reset Request Parameter is
        the Stream Reset Request Sequence Number of the Incoming SSN
        Reset Request Parameter.  If this Outgoing SSN Reset Request
        Parameter is sent at the request of the upper layer and the
        sender requests all outgoing streams to be reset no Stream
        Numbers MUST be put into the Outgoing SSN Reset Request
        Parameter.  If the sender requests only some outgoing streams to
        be reset these Stream Numbers MUST be placed in the Outgoing SSN
        Reset Request Parameter.  Stream Reset Response Sequence Number
        is the next expected Stream Reset Request Sequence Number of the
        peer minus 1.

   A5:  The Outgoing SSN Reset Request Parameter is put into a STREAM
        RESET Chunk.  It MAY be put together with either an Incoming SSN
        Reset Request Parameter or an Stream Reset Response Parameter
        but not both, and MUST NOT be put together with any other
        parameter.





Stewart, et al.          Expires March 30, 2011                [Page 13]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   A6:  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 provided
   that 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
        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 but 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 provided that the Stream Reset Timer
   is not running.  The following steps MUST be followed:

   C1:  The sender MUST assign the next stream reset request sequence
        number and put it into the Stream Reset Request Sequence Number
        field of the SSN/TSN Reset Request Parameter.  After assigning
        it the next stream reset request sequence number MUST be
        incremented by 1.

   C2:  The sender MUST queue any user data suspending any new
        transmissions and TSN assignment until the reset procedure is
        finished by the peer either acknowledging or denying the
        request.




Stewart, et al.          Expires March 30, 2011                [Page 14]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   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.

   Only one SSN/TSN Reset Request SHOULD be sent within a maximum
   segment lifetime, the IP MSL.

5.1.5.  Sender Side Procedures for the Stream Reset Response Parameter

   When an implementation receives a reset 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 placed
        in the Result field of the Stream Reset Response Parameter.

   D3:  If the incoming request is a SSN/TSN reset request, 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 in.

   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.  The value
        should be the smallest TSN not acknowledged by the receiver of
        the request plus 2^31.  For other requests the Receiver's next
        TSN field is not filled in.

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 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 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
   for its first ordered message the stream sequence number 0.



Stewart, et al.          Expires March 30, 2011                [Page 15]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


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 multiple parameters have to be returned,
   they MUST be put into one STREAM RESET chunk.  If the received STREAM
   RESET chunk contains at least one request parameter, a SACK chunk
   SHOULD be sent back and MAY be bundled with the STREAM RESET chunk.
   If the received STREAM RESET chunk contains at least one request and
   based on the analysis of the Stream Reset Request Sequence Numbers
   this is the last received STREAM RESET chunk (i.e. a retransmission),
   the same STREAM RESET chunk MUST to be sent back in response as was
   earlier.

   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 process
   a received request parameter it MUST send a corresponding response
   parameter as described in Section 5.1.5 with an appropriate Result
   field.

   Implementation Note: A SACK is recommended to be bundled with any
   stream reset response so that any retransmission processing that
   needs to occur can be expedited.  A SACK chunk is not required for
   this feature to work, but it will in effect help minimize the delay
   in completing a stream reset operation in the face of any data loss.

5.2.2.  Receiver Side Procedures for the Outgoing SSN Reset Request
        Parameter

   In the case that the endpoint is willing to perform a stream reset
   the following steps MUST be followed:

   E1:  If the Senders Last Assigned TSN number is greater than the
        cumulative acknowledgment point, then the endpoint MUST enter
        "deferred reset processing".  In this mode, any data arriving
        with a TSN number larger than the 'senders last assigned TSN'
        for the affected stream(s) MUST be queued locally and held until
        the Cumulative Acknowledgment point reaches the 'senders last
        assigned TSN number'.  When the Cumulative Acknowledgment point
        reaches the last assigned TSN number then proceed to the next
        step.  Note that the receiver of a stream reset that causes it
        to entered deferred reset processing does not withhold the
        stream reset acknowledgment from the peer.  This also means that
        the receiver will need to queue up any additional stream reset
        requests received including the one that caused the receiver to
        enter deferred reset processing.  This is because once the



Stewart, et al.          Expires March 30, 2011                [Page 16]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


        acknowledgement is received by the sender, the sender is free to
        send a new stream reset.

   E2:  If the Stream Reset Timer is running for the Stream Reset
        Request Sequence Number indicated in the Stream Reset Response
        Sequence Number field, the Stream Reset Request Sequence Number
        MUST be marked as acknowledged.  If all Stream Reset Request
        Sequence Numbers the Stream Reset Timer is running for are
        acknowledged, the Stream Reset Timer MUST be stopped.

   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 E1) MUST now be released and
        processed normally.

   E6:  A Stream Reset Response Parameter is put into a STREAM RESET
        chunk indicating successful processing.

   E7:  The STREAM RESET chunk is sent after the incoming STREAM RESET
        chunk is processed completely.

5.2.3.  Receiver Side Procedures for the Incoming SSN Reset Request
        Parameter

   In the case that the endpoint is willing to perform a stream reset
   the following steps MUST be followed:

   F1:  An Outgoing Stream Reset Request Parameter MUST be put into an
        STREAM RESET chunk according to Section 5.1.2.

   F2:  The STREAM RESET chunk is sent after the incoming STREAM RESET
        chunk is processed completely.

5.2.4.  Receiver Side Procedures for the SSN/TSN Reset Request Parameter

   In the case that the endpoint is willing to perform a SSN/TSN reset
   the following steps MUST be followed:







Stewart, et al.          Expires March 30, 2011                [Page 17]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   G1:  Compute an appropriate value for the Receiver's next TSN, the
        TSN the peer should use to send the next DATA chunk.  The value
        should be the smallest TSN not acknowledged by the receiver of
        the request plus 2^31.

   G2:  Compute an appropriate value for the local endpoints next TSN,
        i.e. the receiver of the SSN/TSN reset chunks next TSN to be
        assigned.  The value should be the highest TSN sent by the
        receiver of the request plus 1.

   G3:  Do the same processing as if a SACK chunk with no gap report and
        a cumulative TSN ACK of Sender's next TSN minus 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
        minus 1 was received.

   G5:  The next expected and outgoing stream sequence numbers MUST be
        reset to 0 for all incoming and outgoing streams.

   G6:  A Stream Reset Response Parameter is put into a STREAM RESET
        chunk indicating successful processing.

   G7:  The STREAM RESET chunk is sent after the incoming STREAM RESET
        chunk is processed completely.

5.2.5.  Receiver Side Procedures for the Add Outgoing Streams Request
        Parameter

   When an SCTP endpoint receives a stream reset request adding
   additional streams, it MUST send a response parameter either
   acknowledging or denying the request.  If the response is successful
   the receiver MUST add the requested number of inbound streams to the
   association, initializing the next expected 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



Stewart, et al.          Expires March 30, 2011                [Page 18]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


        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.

   H5:  If the request was to add outgoing streams and the result was
        successful, the endpoint should add the additional streams to
        the association.  Note that an implementation may allocate the
        memory at the time of the request, but it MUST NOT use the
        streams until the peer has responded with a positive
        acknowledgment.

5.3.  Examples of the Stream Reset procedures

   The following message flows between an Endpoint A and an Endpoint Z
   illustrate the described procedures.  The time progresses in downward
   direction.

   The following example illustrates an Endpoint A resetting stream 1
   and 2 for just its outgoing streams.

   E-A                                         E-Z
   ----------[STR_RESET(OUT-REQ:X/1,2)]---------->
   <-------------[STR_RESET(RESP:X)]--------------

   The following example illustrates an Endpoint A resetting stream 1
   and 2 for just its incoming streams.

   E-A                                         E-Z
   -----------[STR_RESET(IN-REQ:X/1,2)]---------->
   <--------[STR_RESET(OUT-REQ:Y,X/1,2)]----------
   -------------[STR_RESET(RESP:Y)]-------------->




Stewart, et al.          Expires March 30, 2011                [Page 19]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   The following example illustrates an Endpoint A resetting all streams
   in both directions.

   E-A                                         E-Z
   -----[STR_RESET(OUT-REQ:X,Y-1)|IN-REQ:X+1]---->
   <------[STR_RESET(RESP:X|OUT-REQ:Y,X+1)]-------
   -------------[STR_RESET(RESP:Y)]-------------->

   The following example illustrates an Endpoint A requesting the
   streams and TSN's be reset.  At the completion E-A has the new
   sending TSN (selected by the peer) of B and E-Z has the new sending
   TSN of A (also selected by the peer).

   E-A                                         E-Z
   ------------[STR_RESET(TSN-REQ:X)]------------>
   <-----[STR_RESET(RESP:X/S-TSN=A, R-TSN=B)]-----

   The following example illustrates an Endpoint A requesting to add 3
   additional outgoing streams.

   E-A                                         E-Z
   --------[STR_RESET(ADD_OUT_STRMS:X/3)]-------->
   <-------------[STR_RESET(RESP:X)]--------------


6.  Socket API Considerations

   This section describes how the socket API defined in
   [I-D.ietf-tsvwg-sctpsocket] needs to be extended to make the features
   of SCTP stream reset available to the application.

   Please note that this section is informational only.

6.1.  Events

   The union sctp_notification {} is extended to contain three new
   fields: sn_strreset_event, sn_assocreset_event, and
   sn_strchange_event:













Stewart, et al.          Expires March 30, 2011                [Page 20]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   union sctp_notification {
     struct {
       uint16_t sn_type;
       uint16_t sn_flags;
       uint32_t sn_length;
     } sn_header;
     ...
     struct sctp_stream_reset_event sn_strreset_event;
     struct sctp_assoc_reset_event sn_assocreset_event;
     struct sctp_stream_change_event sn_strchange_event;
     ...
   }

   The corresponding sn_type values are given in Table 4.

   +--------------------------+----------------------------------------+
   | sn_type                  | valid field in union sctp_notification |
   +--------------------------+----------------------------------------+
   | SCTP_STREAM_RESET_EVENT  | sn_strreset_event                      |
   | SCTP_ASSOC_RESET_EVENT   | sn_assocreset_event                    |
   | SCTP_STREAM_CHANGE_EVENT | sn_strchange_event                     |
   +--------------------------+----------------------------------------+

                                  Table 4

   These events are delivered when an incoming request was processed
   successfully or the processing of an outgoing request has been
   finished.

6.1.1.  Stream Reset Event

   The event delivered has the following structure:

   struct sctp_stream_reset_event {
     uint16_t strreset_type;
     uint16_t strreset_flags;
     uint32_t strreset_length;
     sctp_assoc_t strreset_assoc_id;
     uint16_t strreset_stream_list[];
   };

   strreset_type:  It should be SCTP_STREAM_RESET_EVENT.

   strreset_flags:  This field is formed from the bitwise OR of one or
      more of the following currently defined flags:






Stewart, et al.          Expires March 30, 2011                [Page 21]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


      SCTP_STREAM_RESET_INCOMING_SSN:  The streams identifiers given in
         strreset_stream_list[] refers to incoming streams of the
         endpoint.

      SCTP_STREAM_RESET_OUTGOING_SSN:  The stream identifiers given in
         strreset_stream_list[] refers to outgoing streams of the
         endpoint.

      SCTP_STREAM_RESET_DENIED:  The corresponding request was denied by
         the peer.

      SCTP_STREAM_RESET_FAILED:  The corresponding request failed.

      At least one of SCTP_STREAM_RESET_INCOMING_SSN and
      SCTP_STREAM_RESET_OUTGOING_SSN is set.  SCTP_STREAM_RESET_DENIED
      and SCTP_STREAM_RESET_FAILED are mutually exclusive.  If the
      request was successful, none of these are set.

   strreset_length:  This field is the total length of the delivered
      event, including the header.

   strreset_assoc_id:  The association id field, holds the identifier
      for the association.  All notifications for a given association
      have the same association identifier.  For one-to-one style
      socket, this field is ignored.

   strreset_stream_list:  The list of stream identifiers this event
      refers to.  An empty list identifies all streams as being reset.
      Depending on strreset_flags the identifiers refer to incoming or
      outgoing streams or both.

6.1.2.  Association Reset Event

   The event delivered has the following structure:

   struct sctp_assoc_reset_event {
     uint16_t assocreset_type;
     uint16_t assocreset_flags;
     uint32_t assocreset_length;
     sctp_assoc_t assocreset_assoc_id;
     uint32_t assocreset_local_tsn;
     uint32_t assocreset_remote_tsn;
   };








Stewart, et al.          Expires March 30, 2011                [Page 22]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   assocreset_type:  It should be SCTP_ASSOC_RESET_EVENT.

   assocreset_flags:  This field is formed from the bitwise OR of one or
      more of the following currently defined flags:

      SCTP_ASSOC_RESET_DENIED:  The corresponding outgoing request was
         denied by the peer.

      SCTP_ASSOC_RESET_FAILED:  The corresponding outgoing request
         failed.

      SCTP_ASSOC_RESET_DENIED and SCTP_ASSOC_RESET_FAILED are mutual
      exclusive.  If the request was successful, none of these are set.

   assocreset_length:  This field is the total length of the delivered
      event, including the header.

   assocreset_assoc_id:  The association id field, holds the identifier
      for the association.  All notifications for a given association
      have the same association identifier.  For one-to-one style
      socket, this field is ignored.

   assocreset_local_tsn:  The next TSN used by the endpoint.

   assocreset_remote_tsn:  The next TSN used by the peer.

6.1.3.  Stream Change Event

   The event delivered has the following structure:

   struct sctp_stream_change_event {
     uint16_t strchange_type;
     uint16_t strchange_flags;
     uint32_t strchange_length;
     sctp_assoc_t strchange_assoc_id;
     uint16_t strchange_instrms;
     uint16_t strchange_outstrms;
   };

   strchange_type:  It should be SCTP_STREAM_CHANGE_EVENT.

   strchange_flags:  This field is formed from the bitwise OR of one or
      more of the following currently defined flags:

      SCTP_STREAM_CHANGE_DENIED:  The corresponding request was denied
         by the peer.





Stewart, et al.          Expires March 30, 2011                [Page 23]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


      SCTP_STREAM_CHANGE_FAILED:  The corresponding request failed.

      SCTP_STREAM_CHANGE_DENIED and SCTP_STREAM_CHANGE_FAILED are mutual
      exclusive.  If the request was successful, none of these are set.

   strchange_length:  This field is the total length of the delivered
      event, including the header.

   strchange_assoc_id:  The association id field, holds the identifier
      for the association.  All notifications for a given association
      have the same association identifier.  For one-to-one style
      socket, this field is ignored.

   strchange_instrms:  The number of streams that the peer is allowed to
      use outbound.

   strchange_outstrms:  The number of streams that the endpoint is
      allowed to use outbound.

6.2.  Event Subscription

   There are two methods defined in the SCTP socket API to subscribe to
   events.  The original method defined was an events structure with the
   socket option SCTP_EVENTS.  Some implementations may have already
   expanded their data structure for this API to include the stream
   reset subscriptions.  The new API is to use a setsockopt with the
   SCTP_SET_EVENT socket option.  This option takes a structure that
   defines the association, the event type (using the same value found
   in the event type field) and a on/off boolean.  This newer API is the
   preferred method but we define both methods for compatibility.

   For some implementations the structure now takes on the form:

   struct sctp_event_subscribe {
     uint8_t sctp_data_io_event;
     uint8_t sctp_association_event;
     uint8_t sctp_address_event;
     uint8_t sctp_send_failure_event;
     uint8_t sctp_peer_error_event;
     uint8_t sctp_shutdown_event;
     uint8_t sctp_partial_delivery_event;
     uint8_t sctp_adaptation_layer_event;
     uint8_t sctp_authentication_event;
     uint8_t sctp_sender_dry_event;
     uint8_t sctp_stream_reset_event;
     uint8_t sctp_assoc_reset_event;
     uint8_t sctp_stream_change_event;
   };



Stewart, et al.          Expires March 30, 2011                [Page 24]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   For those implementations that support this method simply putting a 1
   or 0 in the sctp_stream_reset_event and setting the SCTP_EVENTS
   socket option will work.  However not all implementations support
   this method.

   The preferred method is to use the SCTP_SET_EVENT socket option and
   fill in the structure sctp_set_event structure.

   struct sctp_set_event {
     sctp_assoc_t se_assoc_id;
     uint16_t     se_type;
     uint8_t      se_on;
   };

   Using this method, the user fills in the se_type with the same value
   found in strreset_type field i.e.  SCTP_STREAM_RESET_EVENT.  The user
   will also fill in the se_assoc_id field with either the association
   to set this event on (this field is ignored for one-to-one style
   sockets) or one of the reserved constant values defined in the socket
   API document.  Finally the se_on field is set with a 1 to enable the
   event or a 0 to disable the event.

6.3.  Socket Options

   The following table describes the new socket options which make the
   SCTP stream reset features accessible to the user.  They all use
   IPPROTO_SCTP as their level.

   +--------------------------+---------------------------+-----+-----+
   | option name              | data type                 | get | set |
   +--------------------------+---------------------------+-----+-----+
   | SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value   |  X  |  X  |
   | SCTP_RESET_STREAMS       | struct sctp_reset_streams |     |  X  |
   | SCTP_RESET_ASSOC         | sctp_assoc_t              |     |  X  |
   | SCTP_ADD_OUT_STREAMS     | struct sctp_assoc_value   |     |  X  |
   +--------------------------+---------------------------+-----+-----+

                                  Table 5

6.3.1.  Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET)

   This option allows a user to control whether the SCTP implementation
   processes or denies incoming requests in STREAM_RESET chunks.

   The default is to deny incoming requests.

   To set or get this option the user fills in the following structure:




Stewart, et al.          Expires March 30, 2011                [Page 25]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   struct sctp_assoc_value {
     sctp_assoc_t assoc_id;
     uint32_t assoc_value;
   };

   assoc_id:  This parameter is ignored for one-to-one style sockets.
      For one-to-many style sockets this parameter indicates which
      association the user is performing an action upon.

   assoc_value:  It is formed from the bitwise OR of one or more of the
      following currently defined flags:

      SCTP_DENY_RESET_IN_STREAM_REQ:  Deny received Incoming SSN Reset
         Requests if this flag is set, process it if not.

      SCTP_DENY_RESET_OUT_STREAM_REQ:  Deny received Outgoing SSN Reset
         Requests if this flag is set, process it if not.

      SCTP_DENY_RESET_ASSOC_REQ:  Deny received SSN/TSN Reset Requests
         if this flag is set, process it if not.

      SCTP_DENY_CHANGE_ASSOC_REQ:  Deny received Add Outgoing Streams
         Requests if this flag is set, process it if not.

      The default value is SCTP_DENY_IN_STREAM_RESET|
      SCTP_DENY_OUT_STREAM_RESET|SCTP_DENY_ASSOC_RESET|
      SCTP_DENY_ASSOC_CHANGE.

   Please note that using the option does not have any impact on
   subscribing to any related events.

6.3.2.  Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS)

   This option allows the user to request the reset of incoming and/or
   outgoing streams.

   To set or get this option the user fills in the following structure:

   struct sctp_reset_streams {
     sctp_assoc_t srs_assoc_id;
     uint16_t srs_flags;
     uint16_t srs_number_streams;
     uint16_t srs_stream_list[];
   };







Stewart, et al.          Expires March 30, 2011                [Page 26]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   srs_assoc_id:  This parameter is ignored for one-to-one style
      sockets.  For one-to-many style sockets this parameter indicates
      which association the user is performing an action upon.

   srs_flags:  This parameter describes which class of streams are
      reset.  It is formed from the bitwise OR of one or more of the
      following currently defined flags:

      *  SCTP_STREAM_RESET_INCOMING

      *  SCTP_STREAM_RESET_OUTGOING

   srs_number_streams:  This parameter is the number of elements in the
      srs_stream_list.  If it is zero, the operation is performed on all
      streams.

   srs_stream_list:  This parameter contains a list of stream
      identifiers on which the operation is performed on.  It contains
      srs_number_streams elements.  If it is empty, the operation is
      performed on all streams.  Depending on srs_flags the identifiers
      refer to incoming or outgoing streams or both.

6.3.3.  Reset SSN/TSN (SCTP_RESET_ASSOC)

   This option allows a user to request the reset of the SSN/TSN.

   To set this option the user provides an option_value of type
   sctp_assoc_t.

   On one-to-one style sockets the option_value is ignored.  For one-to-
   many style sockets the option_value is the association identifier of
   the association on which the action is to be performed on.

6.3.4.  Add Outgoing Streams (SCTP_ADD_OUT_STREAMS)

   This option allows a user to request the addition a number of
   outgoing streams.

   To set this option the user fills in the following structure:

   struct sctp_assoc_value {
     sctp_assoc_t assoc_id;
     uint32_t assoc_value;
   };







Stewart, et al.          Expires March 30, 2011                [Page 27]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   assoc_id:  This parameter is ignored for one-to-one style sockets.
      For one-to-many style sockets this parameter indicates which
      association the user is performing an action upon.

   assoc_value:  This parameter is the number of outgoing streams to
      add.

   An endpoint can limit the number of incoming streams by using the
   sinit_max_instreams field in the struct sctp_initmsg{} when issuing
   an SCTP_INIT socket option, as defined in
   [I-D.ietf-tsvwg-sctpsocket].  An incoming request asking for more
   streams than allow will be denied.


7.  Security Considerations

   Having the ability to reset a stream should not pose any additional
   security risk to SCTP.  An attacker that can successfully inject a
   stream reset would also be able to inject data or other malicious
   information into an association such as an ABORT.


8.  IANA Considerations

   [NOTE to RFC-Editor:

      "RFCXXXX" is to be replaced by the RFC number you assign this
      document.

   ]

   This document (RFCXXX) is the reference for all registrations
   described in this section.  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.  IANA shoal assign this value from the pool
   of chunks with the upper two bits set to '10'.

   This requires an additional line in the "CHUNK TYPES" table for SCTP:

   CHUNK TYPES

   ID Value    Chunk Type                                     Reference
   -----       ----------                                     ---------
   130         Stream Reset Chunk (STREAM_RESET)              [RFCXXXX]



Stewart, et al.          Expires March 30, 2011                [Page 28]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


   The registration table as defined in
   [I-D.ietf-tsvwg-sctp-chunk-flags] for the chunk flags of this chunk
   type is empty.

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.  IANA shoal assign this value from
   the pool of parameters with the upper two bits set to '00'.

   This requires an additional table in the "CHUNK PARAMETER TYPES"
   tables for SCTP: 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, Gorry Fairhurst, Tom Pelch,
   Kacheong Poon, Irene Ruengeler, Robin Seggelmann, and Vlad Yasevich
   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,
              September 2007.

   [I-D.ietf-tsvwg-sctp-chunk-flags]



Stewart, et al.          Expires March 30, 2011                [Page 29]

Internet-Draft         SCTP Stream Reconfiguration        September 2010


              Tuexen, M. and R. Stewart, "Stream Control Transmission
              Protocol (SCTP) Chunk Flags Registration",
              draft-ietf-tsvwg-sctp-chunk-flags-01 (work in progress),
              September 2010.

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-23 (work in progress),
              July 2010.


Authors' Addresses

   Randall R. Stewart
   Huawei
   Chapin, SC  29036
   USA

   Phone:
   Email: rstewart@huawei.com


   Peter Lei
   Cisco Systems, Inc.
   8735 West Higgins Road
   Suite 300
   Chicago, IL  60631
   USA

   Phone:
   Email: peterlei@cisco.com


   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt
   Germany

   Email: tuexen@fh-muenster.de







Stewart, et al.          Expires March 30, 2011                [Page 30]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/