draft-ietf-tsvwg-sctp-strrst-10.txt   draft-ietf-tsvwg-sctp-strrst-11.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Adara Networks Internet-Draft Adara Networks
Intended status: Standards Track P. Lei Intended status: Standards Track M. Tuexen
Expires: December 28, 2011 Cisco Systems, Inc. Expires: January 11, 2012 Muenster Univ. of Appl. Sciences
M. Tuexen P. Lei
Muenster Univ. of Appl. Sciences Cisco Systems, Inc.
June 26, 2011 July 10, 2011
Stream Control Transmission Protocol (SCTP) Stream Reconfiguration Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
draft-ietf-tsvwg-sctp-strrst-10.txt draft-ietf-tsvwg-sctp-strrst-11.txt
Abstract Abstract
Many applications that use SCTP want the ability to "reset" a stream. Many applications that use SCTP want the ability to "reset" a stream.
The intention of resetting a stream is to set the numbering sequence The intention of resetting a stream is to set the numbering sequence
of the stream back to 'zero' with a corresponding notification to the of the stream back to 'zero' with a corresponding notification to the
upper layer that this has been performed. The applications that want upper layer that this has been performed. The applications that want
this feature want it so that they can "re-use" streams for different this feature want it so that they can "re-use" streams for different
purposes but still utilize the stream sequence number so that the purposes but still utilize the stream sequence number so that the
application can track the message flows. Thus, without this feature, application can track the message flows. Thus, without this feature,
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2011. This Internet-Draft will expire on January 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 4 3. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. RE-CONFIG Chunk . . . . . . . . . . . . . . . . . . . . . 5 3.1. RE-CONFIG Chunk . . . . . . . . . . . . . . . . . . . . . 5
4. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 6 4. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 6
4.1. Outgoing SSN Reset Request Parameter . . . . . . . . . . . 6 4.1. Outgoing SSN Reset Request Parameter . . . . . . . . . . . 7
4.2. Incoming SSN Reset Request Parameter . . . . . . . . . . . 8 4.2. Incoming SSN Reset Request Parameter . . . . . . . . . . . 8
4.3. SSN/TSN Reset Request Parameter . . . . . . . . . . . . . 9 4.3. SSN/TSN Reset Request Parameter . . . . . . . . . . . . . 9
4.4. Re-configuration Response Parameter . . . . . . . . . . . 9 4.4. Re-configuration Response Parameter . . . . . . . . . . . 9
4.5. Add Outgoing Streams Request Parameter . . . . . . . . . . 11 4.5. Add Outgoing Streams Request Parameter . . . . . . . . . . 11
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Add Incoming Streams Request Parameter . . . . . . . . . . 12
5.1. Sender Side Procedures . . . . . . . . . . . . . . . . . . 12 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Sender Side Procedures for the RE-CONFIG Chunk . . . . 12 5.1. Sender Side Procedures . . . . . . . . . . . . . . . . . . 13
5.1.1. Sender Side Procedures for the RE-CONFIG Chunk . . . . 13
5.1.2. Sender Side Procedures for the Outgoing SSN Reset 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 Request Parameter . . . . . . . . . . . . . . . . . . 14
5.1.4. Sender Side Procedures for the SSN/TSN Reset 5.1.3. Sender Side Procedures for the Incoming SSN Reset
Request Parameter . . . . . . . . . . . . . . . . . . 15 Request Parameter . . . . . . . . . . . . . . . . . . 15
5.1.4. Sender Side Procedures for the SSN/TSN Reset
Request Parameter . . . . . . . . . . . . . . . . . . 16
5.1.5. Sender Side Procedures for the Re-configuration 5.1.5. Sender Side Procedures for the Re-configuration
Response Parameter . . . . . . . . . . . . . . . . . . 15 Response Parameter . . . . . . . . . . . . . . . . . . 16
5.1.6. Sender Side Procedures for the Add Outgoing 5.1.6. Sender Side Procedures for the Add Outgoing
Streams Request Parameter . . . . . . . . . . . . . . 16 Streams Request Parameter . . . . . . . . . . . . . . 17
5.2. Receiver Side Procedures . . . . . . . . . . . . . . . . . 16 5.1.7. Sender Side Procedures for the Add Incoming
5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk . . . 16 Streams Request Parameter . . . . . . . . . . . . . . 17
5.2. Receiver Side Procedures . . . . . . . . . . . . . . . . . 18
5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk . . . 18
5.2.2. Receiver Side Procedures for the Outgoing SSN 5.2.2. Receiver Side Procedures for the Outgoing SSN
Reset Request Parameter . . . . . . . . . . . . . . . 17
5.2.3. Receiver Side Procedures for the Incoming SSN
Reset Request Parameter . . . . . . . . . . . . . . . 18 Reset Request Parameter . . . . . . . . . . . . . . . 18
5.2.3. Receiver Side Procedures for the Incoming SSN
Reset Request Parameter . . . . . . . . . . . . . . . 19
5.2.4. Receiver Side Procedures for the SSN/TSN Reset 5.2.4. Receiver Side Procedures for the SSN/TSN Reset
Request Parameter . . . . . . . . . . . . . . . . . . 19 Request Parameter . . . . . . . . . . . . . . . . . . 20
5.2.5. Receiver Side Procedures for the Add Outgoing 5.2.5. Receiver Side Procedures for the Add Outgoing
Streams Request Parameter . . . . . . . . . . . . . . 19 Streams Request Parameter . . . . . . . . . . . . . . 20
5.2.6. Receiver Side Procedures for the Re-configuration 5.2.6. Receiver Side Procedures for the Add Incoming
Response Parameter . . . . . . . . . . . . . . . . . . 19 Streams Request Parameter . . . . . . . . . . . . . . 21
5.2.7. Receiver Side Procedures for the Re-configuration
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 20 Response Parameter . . . . . . . . . . . . . . . . . . 21
6.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Socket API Considerations . . . . . . . . . . . . . . . . . . 22
6.1.1. Stream Reset Event . . . . . . . . . . . . . . . . . . 21 6.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1.2. Association Reset Event . . . . . . . . . . . . . . . 22 6.1.1. Stream Reset Event . . . . . . . . . . . . . . . . . . 23
6.1.3. Stream Change Event . . . . . . . . . . . . . . . . . 23 6.1.2. Association Reset Event . . . . . . . . . . . . . . . 24
6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . 24 6.1.3. Stream Change Event . . . . . . . . . . . . . . . . . 25
6.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . 25
6.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 26
6.3.1. Enable/Disable Stream Reset 6.3.1. Enable/Disable Stream Reset
(SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 25 (SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 26
6.3.2. Reset Incoming and/or Outgoing Streams 6.3.2. Reset Incoming and/or Outgoing Streams
(SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 26 (SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 27
6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 26 6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 28
6.3.4. Add Outgoing Streams (SCTP_ADD_OUT_STREAMS) . . . . . 27 6.3.4. Add Incoming and/or Outgoing Streams
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 (SCTP_ADD_STREAMS) . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.2. Five New Parameter Types . . . . . . . . . . . . . . . . . 28 8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Six New Parameter Types . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. Examples of the Re-configuration procedures . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Examples of the Re-configuration procedures . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Many applications that use SCTP want the ability to "reset" a stream. Many applications that use SCTP want the ability to "reset" a stream.
The intention of resetting a stream is to set the numbering sequence The intention of resetting a stream is to set the numbering sequence
of the stream back to 'zero' with a corresponding notification to the of the stream back to 'zero' with a corresponding notification to the
upper layer that this has been performed. The applications that want upper layer that this has been performed. The applications that want
this feature want to "re-use" streams for different purposes but this feature want to "re-use" streams for different purposes but
still utilize the stream sequence number so that the application can still utilize the stream sequence number so that the application can
track the message flows. Thus, without this feature, a new use of an track the message flows. Thus, without this feature, a new use of an
skipping to change at page 5, line 45 skipping to change at page 5, line 45
This field holds the length of the chunk in bytes, including the This field holds the length of the chunk in bytes, including the
Chunk Type, Chunk Flags and Chunk Length. Chunk Type, Chunk Flags and Chunk Length.
Re-configuration Parameter Re-configuration Parameter
This field holds a Re-configuration Request Parameter or a Re- This field holds a Re-configuration Request Parameter or a Re-
configuration Response Parameter. configuration Response Parameter.
Note that each RE-CONFIG chunk holds at least one parameter and at Note that each RE-CONFIG chunk holds at least one parameter and at
most two parameters. Only the following combinations are allowed: most two parameters. Only the following combinations are allowed:
1. Outgoing SSN Reset Request Parameter. 1. Outgoing SSN Reset Request Parameter.
2. Incoming SSN Reset Request Parameter. 2. Incoming SSN Reset Request Parameter.
3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request 3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request
Parameter. Parameter.
4. SSN/TSN Reset Request Parameter. 4. SSN/TSN Reset Request Parameter.
5. Add Outgoing Streams Request Parameter. 5. Add Outgoing Streams Request Parameter.
6. Re-configuration Response Parameter. 6. Add Incoming Streams Request Parameter.
7. Re-configuration Response Parameter, Outgoing SSN Reset Request 7. Add Outgoing Streams Request Parameter, Add Incoming Streams
Parameter. Request Parameter.
8. Re-configuration Response Parameter, Re-configuration Response 8. Re-configuration Response Parameter.
Parameter.
9. Re-configuration Response Parameter, Outgoing SSN Reset Request
Parameter.
10. Re-configuration Response Parameter, Re-configuration Response
Parameter.
If a sender transmits an unsupported combination, the receiver SHOULD If a sender transmits an unsupported combination, the receiver SHOULD
send an ERROR chunk with a Protocol Violation cause as defined in send an ERROR chunk with a Protocol Violation cause as defined in
section 3.3.10.13 of [RFC4960]). section 3.3.10.13 of [RFC4960]).
4. New Parameter Types 4. New Parameter Types
This section defines the new parameter types that will be used in the This section defines the new parameter types that will be used in the
RE-CONFIG chunk. Table 2 illustrates the new parameter types. RE-CONFIG chunk. Table 2 illustrates the new parameter types.
+----------------+----------------------------------------+ +----------------+----------------------------------------+
| Parameter Type | Parameter Name | | Parameter Type | Parameter Name |
+----------------+----------------------------------------+ +----------------+----------------------------------------+
| 0x000d | Outgoing SSN Reset Request Parameter | | 0x000d | Outgoing SSN Reset Request Parameter |
| 0x000e | Incoming SSN Reset Request Parameter | | 0x000e | Incoming SSN Reset Request Parameter |
| 0x000f | SSN/TSN Reset Request Parameter | | 0x000f | SSN/TSN Reset Request Parameter |
| 0x0010 | Re-configuration Response Parameter | | 0x0010 | Re-configuration Response Parameter |
| 0x0011 | Add Outgoing Streams Request Parameter | | 0x0011 | Add Outgoing Streams Request Parameter |
| 0x0012 | Add Incoming Streams Request Parameter |
+----------------+----------------------------------------+ +----------------+----------------------------------------+
Table 2 Table 2
It should be noted that the parameter format requires the receiver to It should be noted that the parameter format requires the receiver to
stop processing the parameter and not to process any further stop processing the parameter and not to process any further
parameters within the chunk if the parameter type is not recognized. parameters within the chunk if the parameter type is not recognized.
This is accomplished by the use of the upper bits of the parameter This is accomplished by the use of the upper bits of the parameter
type as described in section 3.2.1 of [RFC4960]. type as described in section 3.2.1 of [RFC4960].
skipping to change at page 11, line 6 skipping to change at page 11, line 6
| 2 | Denied | | 2 | Denied |
| 3 | Error - Wrong SSN | | 3 | Error - Wrong SSN |
| 4 | Error - Request already in progress | | 4 | Error - Request already in progress |
| 5 | Error - Bad Sequence Number | | 5 | Error - Bad Sequence Number |
| 6 | In progress | | 6 | In progress |
+--------+-------------------------------------+ +--------+-------------------------------------+
Table 3 Table 3
Sender's next TSN: 4 bytes (unsigned integer) Sender's next TSN: 4 bytes (unsigned integer)
This field holds the TSN the sender of the Response will use to This field holds the TSN the sender of the response will use to
send the next DATA chunk. The field is only applicable in send the next DATA chunk. The field is only applicable in
responses to SSN/TSN reset requests. responses to SSN/TSN reset requests.
Receiver's next TSN: 4 bytes (unsigned integer) Receiver's next TSN: 4 bytes (unsigned integer)
This field holds the TSN the receiver of the response must use to This field holds the TSN the receiver of the response must use to
send the next DATA chunk. The field is only applicable in send the next DATA chunk. The field is only applicable in
responses to SSN/TSN reset requests. responses to SSN/TSN reset requests.
Either both optional fields (Sender's next TSN and Receiver's next Either both optional fields (Sender's next TSN and Receiver's next
TSN) MUST be present or none. TSN) MUST be present or none.
skipping to change at page 11, line 39 skipping to change at page 11, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x0011 | Parameter Length = 12 | | Parameter Type = 0x0011 | Parameter Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number | | Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of new streams | Reserved | | Number of new streams | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the the Add This field holds the IANA defined parameter type for the the Add
Outgoing Streams Parameter. The suggested value of this field for Outgoing Streams Request Parameter. The suggested value of this
IANA is 0x0011. field for IANA is 0x0011.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value This field holds the length in bytes of the parameter; the value
MUST be 12. MUST be 12.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new Initial TSN number. It is increased by 1 whenever sending a new
Re-configuration Request parameter. Re-configuration Request parameter.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
outgoing streams (0-3) and a requested is made to add 3 streams outgoing streams (0-3) and a requested is made to add 3 streams
then the new streams will be 4, 5 and 6. then the new streams will be 4, 5 and 6.
Reserved: 2 bytes (unsigned integer) Reserved: 2 bytes (unsigned integer)
This field is reserved. It SHOULD be set to 0 by the sender and This field is reserved. It SHOULD be set to 0 by the sender and
ignored by the receiver. ignored by the receiver.
This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
4.6. Add Incoming Streams Request Parameter
This parameter is used by the sender to request that the peer adds an
additional number of outgoing streams (i.e. the sender's incoming
streams) to the association.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x0012 | Parameter Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Re-configuration Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of new streams | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the the Add
Incoming Streams Request Parameter. The suggested value of this
field for IANA is 0x0012.
Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value
MUST be 12.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new
Re-configuration Request parameter.
Number of new streams: 2 bytes (unsigned integer)
This value holds the number of additional incoming streams the
sender requests to be 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 MAY appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type.
5. Procedures 5. Procedures
This section defines the procedures used by both the sender and This section defines the procedures used by both the sender and
receiver of a RE-CONFIG chunk. Various examples of re-configuration receiver of a RE-CONFIG chunk. Various examples of re-configuration
scenarios are given in Appendix A. scenarios are given in Appendix A.
One important thing to remember about SCTP streams is that they are One important thing to remember about SCTP streams is that they are
uni-directional and there is no coorespondance between outgoing and uni-directional and there is no correspondence between outgoing and
incoming streams. The procedures outlined in this section are incoming streams. The procedures outlined in this section are
designed so that the incoming side will always reset their stream designed so that the incoming side will always reset their stream
sequence number first before the outgoing side which means the re- sequence number first before the outgoing side which means the re-
configuration request must always originate from the outgoing side. configuration request must always originate from the outgoing side.
These two issues have important ramifications upon how an SCTP These two issues have important ramifications upon how an SCTP
endpoint might request that its incoming streams be reset. In effect endpoint might request that its incoming streams be reset. In effect
it must ask the peer to start an outgoing reset proceedure and once it must ask the peer to start an outgoing reset procedure and once
that request is acknowledged let the peer actually control the reset that request is acknowledged let the peer actually control the reset
operation. operation.
5.1. Sender Side Procedures 5.1. Sender Side Procedures
This section describes the procedures related to the sending of RE- This section describes the procedures related to the sending of RE-
CONFIG chunks. A RE-CONFIG chunk is composed of one or two Type CONFIG chunks. A RE-CONFIG chunk is composed of one or two Type
Length Value (TLV) parameters. Length Value (TLV) parameters.
5.1.1. Sender Side Procedures for the RE-CONFIG Chunk 5.1.1. Sender Side Procedures for the RE-CONFIG Chunk
skipping to change at page 13, line 19 skipping to change at page 14, line 19
support the re-configuration extension. support the re-configuration extension.
At any given time there MUST NOT be more than one request be in At any given time there MUST NOT be more than one request be in
flight. So if the Re-configuration Timer is running and the the RE- flight. So if the Re-configuration Timer is running and the the RE-
CONFIG chunk contains at least one request parameter the chunk MUST CONFIG chunk contains at least one request parameter the chunk MUST
be buffered. be buffered.
After packaging the RE-CONFIG chunk and sending it to the peer the After packaging the RE-CONFIG chunk and sending it to the peer the
sender MUST start the Re-configuration Timer if the RE-CONFIG chunk sender MUST start the Re-configuration Timer if the RE-CONFIG chunk
contains at least one request parameter. If it contains no request contains at least one request parameter. If it contains no request
parameter, the Re-configuration Timer MUST NOT be started. This parameters, the Re-configuration Timer MUST NOT be started. This
timer MUST use the same value as SCTP's Data transmission timer (i.e. timer MUST use the same value as SCTP's Data transmission timer (i.e.
the RTO timer) and MUST use exponential backoff doubling the value at the RTO timer) and MUST use exponential backoff doubling the value at
every expiration. If the timer expires, besides doubling the value, every expiration. If the timer expires, besides doubling the value,
the sender MUST retransmit the RE-CONFIG chunk, increment the the sender MUST retransmit the RE-CONFIG chunk, increment the
appropriate error counts (both for the association and the appropriate error counts (both for the association and the
destination), and perform threshold management possibly destroying destination), and perform threshold management possibly destroying
the association if SCTP retransmission thresholds are exceeded. the association if SCTP retransmission thresholds are exceeded.
5.1.2. Sender Side Procedures for the Outgoing SSN Reset Request 5.1.2. Sender Side Procedures for the Outgoing SSN Reset Request
Parameter Parameter
skipping to change at page 15, line 13 skipping to change at page 16, line 13
Reset Request Parameter. Reset Request Parameter.
B3: The Incoming SSN Reset Request Parameter MUST be put into a RE- B3: The Incoming SSN Reset Request Parameter MUST be put into a RE-
CONFIG Chunk. It MAY be put together with an Outgoing SSN Reset CONFIG Chunk. It MAY be put together with an Outgoing SSN Reset
Request Parameter but MUST NOT be put together with any other Request Parameter but MUST NOT be put together with any other
parameter. parameter.
B4: The RE-CONFIG chunk MUST be sent following the rules given in B4: The RE-CONFIG chunk MUST be sent following the rules given in
Section 5.1.1. Section 5.1.1.
When sending a Incoming SSN Reset Request their is a potential that When sending an Incoming SSN Reset Request there is a potential that
the peer has just reset or is in the process of resetting the same the peer has just reset or is in the process of resetting the same
streams via an Outgoing SSN Reset Request. This collision scenario streams via an Outgoing SSN Reset Request. This collision scenario
is discussed in Section 5.2.3. is discussed in Section 5.2.3.
5.1.4. Sender Side Procedures for the SSN/TSN Reset Request Parameter 5.1.4. Sender Side Procedures for the SSN/TSN Reset Request Parameter
When an SCTP sender wants to reset the SSNs and TSNs it can send an When an SCTP sender wants to reset the SSNs and TSNs it can send an
SSN/TSN Reset Request Parameter provided that the Re-configuration SSN/TSN Reset Request Parameter provided that the Re-configuration
Timer is not running. The following steps must be followed: Timer is not running. The following steps must be followed:
C1: The sender MUST assign the next re-configuration request C1: The sender MUST assign the next re-configuration request
sequence number and put it into the Re-configuration Request sequence number and put it into the Re-configuration Request
Sequence Number field of the SSN/TSN Reset Request Parameter. Sequence Number field of the SSN/TSN Reset Request Parameter.
After assigning it the next re-configuration request sequence After assigning it the next re-configuration request sequence
number MUST be incremented by 1. number MUST be incremented by 1.
C2: The sender MUST queue any user data suspending any new C2: The sender has either no outstanding TSNs or considers all
transmissions and TSN assignment until the reset procedure is outstanding TSNs abandoned. The sender MUST queue any user data
finished by the peer either acknowledging or denying the suspending any new transmissions and TSN assignment until the
request. reset procedure is finished by the peer either acknowledging or
denying the request.
C3: The SSN/TSN Reset Request Parameter MUST be put into a RE-CONFIG C3: The SSN/TSN Reset Request Parameter MUST be put into a RE-CONFIG
chunk. There MUST NOT be any other parameter in this chunk. chunk. There MUST NOT be any other parameter in this chunk.
C4: The RE-CONFIG chunk MUST be sent following the rules given in C4: The RE-CONFIG chunk MUST be sent following the rules given in
Section 5.1.1. Section 5.1.1.
Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds, Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds,
which is considered a maximum segment lifetime, the IP MSL. which is considered a maximum segment lifetime, the IP MSL.
skipping to change at page 16, line 41 skipping to change at page 17, line 41
to which it is able to send, it may add an Add Outgoing Streams to which it is able to send, it may add an Add Outgoing Streams
Request parameter to the RE-CONFIG chunk. Upon sending the request Request parameter to the RE-CONFIG chunk. Upon sending the request
the sender MUST await a positive acknowledgment (Success) before the sender MUST await a positive acknowledgment (Success) before
using any additional stream added by this request. Note that new using any additional stream added by this request. Note that new
streams are added adjacent to the previous streams with no gaps. 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 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 association that has already 5 (0-4) then the new streams, upon
successful completion, are streams 5 and 6. A new stream MUST use successful completion, are streams 5 and 6. A new stream MUST use
the stream sequence number 0 for its first ordered message. the stream sequence number 0 for its first ordered message.
5.1.7. Sender Side Procedures for the Add Incoming Streams Request
Parameter
When an SCTP sender wants to increase the number of inbound streams
to which the peer is able to send, it may add an Add Incoming Streams
Request parameter to the RE-CONFIG chunk. Note that new streams are
added adjacent to the previous streams with no gaps. This means that
if a request is made to add 2 streams to an association that has
already 5 (0-4) then the new streams, upon successful completion, are
streams 5 and 6. A new stream MUST use the stream sequence number 0
for its first ordered message.
5.2. Receiver Side Procedures 5.2. Receiver Side Procedures
5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk 5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk
Upon reception of a RE-CONFIG chunk each parameter within it SHOULD Upon reception of a RE-CONFIG chunk each parameter within it SHOULD
be processed. If multiple parameters have to be returned, they MUST be processed. If multiple parameters have to be returned, they MUST
be put into one RE_CONFIG chunk. If the received RE-CONFIG chunk be put into one RE_CONFIG chunk. If the received RE-CONFIG chunk
contains at least one request parameter, a SACK chunk SHOULD be sent contains at least one request parameter, a SACK chunk SHOULD be sent
back and MAY be bundled with the RE-CONFIG chunk. If the received back and MAY be bundled with the RE-CONFIG chunk. If the received
RE-CONFIG chunk contains at least one request and based on the RE-CONFIG chunk contains at least one request and based on the
skipping to change at page 18, line 26 skipping to change at page 19, line 38
In the case that the endpoint is willing to perform a stream reset In the case that the endpoint is willing to perform a stream reset
the following steps must be followed: the following steps must be followed:
F1: An Outgoing SSN Reset Request Parameter MUST be put into an RE- F1: An Outgoing SSN Reset Request Parameter MUST be put into an RE-
CONFIG chunk according to Section 5.1.2. CONFIG chunk according to Section 5.1.2.
F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG
chunk is processed completely. chunk is processed completely.
If the endpoint is un-willing to perform the stream reset it MUST When a peer endpoint requests an Incoming SSN Reset Request it is
send a Re-configuration Response Parameter with the appropriate error
set to "Denied".
When a peer endpoint requests a Incoming SSN Reset Request it is
possible that the local endpoint has just sent an Outgoing SSN Reset possible that the local endpoint has just sent an Outgoing SSN Reset
Request on the same stream and has not yet received a response. In Request on the same association and has not yet received a response.
such a case the local endpoint MUST do the following: In such a case the local endpoint MUST do the following:
1) If the stream reset overlaps the outstanding request completely o If the just sent Outgoing SSN Reset Request Parameter completely
respond to the requestor with a acknowledgment indicating that overlaps the received Incoming SSN Reset Request Parameter respond
there was 'Nothing to do'. to the peer with an acknowledgment indicating that there was
'Nothing to do'.
2) Otherwise process the re-configuration request normally responding o Otherwise process the Incoming SSN Reset Request Parameter
to the requestor with a acknowledgment. normally responding to the peer with an acknowledgment.
It is also possible that the Incoming request will arrive after the It is also possible that the Incoming request will arrive after the
Outgoing SSN Reset Request just completed. In such a case all of the Outgoing SSN Reset Request just completed. In such a case all of the
streams being requested will be already set to 0. If so, the local streams being requested will be already set to 0. If so, the local
endpoint SHOULD send back a Re-configuration Response with the endpoint SHOULD send back a Re-configuration Response with the
success code "Nothing to do". success code "Nothing to do".
Note that in either race condition the local endpoint could Note that in either race condition the local endpoint could
optionally also perform the reset. This would result in streams that optionally also perform the reset. This would result in streams that
are already at sequence 0 being reset again to 0 which would cause no are already at sequence 0 being reset again to 0 which would cause no
skipping to change at page 19, line 47 skipping to change at page 21, line 8
5.2.5. Receiver Side Procedures for the Add Outgoing Streams Request 5.2.5. Receiver Side Procedures for the Add Outgoing Streams Request
Parameter Parameter
When an SCTP endpoint receives a re-configuration request adding When an SCTP endpoint receives a re-configuration request adding
additional streams, it MUST send a response parameter either additional streams, it MUST send a response parameter either
acknowledging or denying the request. If the response is successful acknowledging or denying the request. If the response is successful
the receiver MUST add the requested number of inbound streams to the the receiver MUST add the requested number of inbound streams to the
association, initializing the next expected stream sequence number to association, initializing the next expected stream sequence number to
be 0. be 0.
5.2.6. Receiver Side Procedures for the Re-configuration Response 5.2.6. Receiver Side Procedures for the Add Incoming Streams Request
Parameter
When an SCTP endpoint receives a re-configuration request adding
additional incoming streams, it MUST either send a response parameter
denying the request or sending a corresponding Add Outgoing Streams
Request Parameter following the rules given in Section 5.1.6.
5.2.7. Receiver Side Procedures for the Re-configuration Response
Parameter Parameter
On receipt of a Re-configuration Response Parameter the following On receipt of a Re-configuration Response Parameter the following
must be performed: must be performed:
H1: If the Re-confguration Timer is running for the Re-configuration H1: If the Re-confguration Timer is running for the Re-configuration
Request Sequence Number indicated in the Re-configuration Request Sequence Number indicated in the Re-configuration
Response Sequence Number field, the Re-configuration Request Response Sequence Number field, the Re-configuration Request
Sequence Number MUST be marked as acknowledged. If all Re- Sequence Number MUST be marked as acknowledged. If all Re-
configuration Request Sequence Numbers the Re-configuration configuration Request Sequence Numbers the Re-configuration
skipping to change at page 25, line 5 skipping to change at page 26, line 25
one of the reserved constant values defined in one of the reserved constant values defined in
[I-D.ietf-tsvwg-sctpsocket]. Finally the se_on field is set with a 1 [I-D.ietf-tsvwg-sctpsocket]. Finally the se_on field is set with a 1
to enable the event or a 0 to disable the event. to enable the event or a 0 to disable the event.
6.3. Socket Options 6.3. Socket Options
The following table describes the new socket options which make the The following table describes the new socket options which make the
re-configuration features accessible to the user. They all use re-configuration features accessible to the user. They all use
IPPROTO_SCTP as their level. IPPROTO_SCTP as their level.
If a call to setsockopt() is used to issue a Re-configuration request
while the Re-configuration timer is running, setsockopt() will return
-1 and error is set to EALREADY.
+--------------------------+---------------------------+-----+-----+ +--------------------------+---------------------------+-----+-----+
| option name | data type | get | set | | option name | data type | get | set |
+--------------------------+---------------------------+-----+-----+ +--------------------------+---------------------------+-----+-----+
| SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value | X | X | | SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value | X | X |
| SCTP_RESET_STREAMS | struct sctp_reset_streams | | X | | SCTP_RESET_STREAMS | struct sctp_reset_streams | | X |
| SCTP_RESET_ASSOC | sctp_assoc_t | | X | | SCTP_RESET_ASSOC | sctp_assoc_t | | X |
| SCTP_ADD_OUT_STREAMS | struct sctp_assoc_value | | X | | SCTP_ADD_STREAMS | struct sctp_add_streams | | X |
+--------------------------+---------------------------+-----+-----+ +--------------------------+---------------------------+-----+-----+
Table 5 Table 5
6.3.1. Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET) 6.3.1. Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET)
This option allows a user to control whether the SCTP implementation This option allows a user to control whether the SCTP implementation
processes or denies incoming requests in STREAM_RESET chunks. processes or denies incoming requests in STREAM_RESET chunks.
The default is to deny all incoming requests. The default is to deny all incoming requests.
skipping to change at page 25, line 29 skipping to change at page 27, line 4
processes or denies incoming requests in STREAM_RESET chunks. processes or denies incoming requests in STREAM_RESET chunks.
The default is to deny all incoming requests. The default is to deny all incoming requests.
To set or get this option the user fills in the following structure: To set or get this option the user fills in the following structure:
struct sctp_assoc_value { struct sctp_assoc_value {
sctp_assoc_t assoc_id; sctp_assoc_t assoc_id;
uint32_t assoc_value; uint32_t assoc_value;
}; };
assoc_id: This parameter is ignored for one-to-one style sockets. assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets this parameter indicates which For one-to-many style sockets this parameter indicates which
association the user is performing an action upon. association the user is performing an action upon.
assoc_value: It is formed from the bitwise OR of one or more of the assoc_value: It is formed from the bitwise OR of one or more of the
following currently defined flags: following currently defined flags:
SCTP_ENABLE_RESET_IN_STREAM_REQ: Process received Incoming SSN SCTP_ENABLE_RESET_STREAM_REQ: Process received Incoming/Outgoing
Reset Requests if this flag is set, deny them if not. SSN Reset Requests if this flag is set, deny them if not.
SCTP_ENABLE_RESET_OUT_STREAM_REQ: Process received Outgoing SSN
Reset Requests if this flag is set, deny them if not.
SCTP_ENABLE_RESET_ASSOC_REQ: Process received SSN/TSN Reset SCTP_ENABLE_RESET_ASSOC_REQ: Process received SSN/TSN Reset
Requests if this flag is set, deny them if not. Requests if this flag is set, deny them if not.
SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing
Streams Requests if this flag is set, deny them if not. Streams Requests if this flag is set, deny them if not.
The default value is !(SCTP_ENABLE_IN_STREAM_RESET| The default value is !(SCTP_ENABLE_RESET_STREAM_REQ|
SCTP_ENABLE_OUT_STREAM_RESET|SCTP_ENABLE_ASSOC_RESET| SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ).
SCTP_ENABLE_ASSOC_CHANGE).
Please note that using the option does not have any impact on Please note that using the option does not have any impact on
subscribing to any related events. subscribing to any related events.
6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS) 6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS)
This option allows the user to request the reset of incoming and/or This option allows the user to request the reset of incoming and/or
outgoing streams. outgoing streams.
To set or get this option the user fills in the following structure: To set or get this option the user fills in the following structure:
skipping to change at page 27, line 6 skipping to change at page 28, line 26
This option allows a user to request the reset of the SSN/TSN. This option allows a user to request the reset of the SSN/TSN.
To set this option the user provides an option_value of type To set this option the user provides an option_value of type
sctp_assoc_t. sctp_assoc_t.
On one-to-one style sockets the option_value is ignored. For one-to- On one-to-one style sockets the option_value is ignored. For one-to-
many style sockets the option_value is the association identifier of many style sockets the option_value is the association identifier of
the association the action is to be performed upon. the association the action is to be performed upon.
6.3.4. Add Outgoing Streams (SCTP_ADD_OUT_STREAMS) 6.3.4. Add Incoming and/or Outgoing Streams (SCTP_ADD_STREAMS)
This option allows a user to request the addition of a number of This option allows a user to request the addition of a number of
outgoing streams. incoming and/or outgoing streams.
To set this option the user fills in the following structure: To set this option the user fills in the following structure:
struct sctp_assoc_value { struct sctp_add_streams {
sctp_assoc_t assoc_id; sctp_assoc_t sas_assoc_id;
uint32_t assoc_value; uint16_t sas_instrms;
uint16_t sas_outstrms;
}; };
assoc_id: This parameter is ignored for one-to-one style sockets. sas_assoc_id: This parameter is ignored for one-to-one style
For one-to-many style sockets this parameter indicates which sockets. For one-to-many style sockets this parameter indicates
association the user is performing an action upon. which association the user is performing an action upon.
assoc_value: This parameter is the number of outgoing streams to sas_instrms: This parameter is the number of incoming streams to
add. add.
An endpoint can limit the number of incoming streams by using the sas_outstrms: This parameter is the number of outgoing streams to
sinit_max_instreams field in the struct sctp_initmsg{} when issuing add.
an SCTP_INIT socket option, as defined in
An endpoint can limit the number of incoming and outgoing streams by
using the sinit_max_instreams field in the struct sctp_initmsg{} when
issuing an SCTP_INIT socket option, as defined in
[I-D.ietf-tsvwg-sctpsocket]. An incoming request asking for more [I-D.ietf-tsvwg-sctpsocket]. An incoming request asking for more
streams than allowed will be denied. streams than allowed will be denied.
7. Security Considerations 7. Security Considerations
The SCTP socket API as described in [I-D.ietf-tsvwg-sctpsocket] The SCTP socket API as described in [I-D.ietf-tsvwg-sctpsocket]
exposes the sequence numbers of received DATA chunks to the exposes the sequence numbers of received DATA chunks to the
application. An application might expect them to be monotonically application. An application might expect them to be monotonically
increasing. When using the re-configuration extension this might no increasing. When using the re-configuration extension this might no
longer be true. Therefore the application must enable this extension longer be true. Therefore the application must enable this extension
skipping to change at page 28, line 42 skipping to change at page 30, line 16
CHUNK TYPES CHUNK TYPES
ID Value Chunk Type Reference ID Value Chunk Type Reference
----- ---------- --------- ----- ---------- ---------
130 Re-configuration Chunk (RE-CONFIG) [RFCXXXX] 130 Re-configuration Chunk (RE-CONFIG) [RFCXXXX]
The registration table as defined in [RFC6096] for the chunk flags of The registration table as defined in [RFC6096] for the chunk flags of
this chunk type is empty. this chunk type is empty.
8.2. Five New Parameter Types 8.2. Six New Parameter Types
IANA is requested to create a new sub-registry, "RE-CONFIG Chunk IANA is requested to create a new sub-registry, "RE-CONFIG Chunk
Parameter Types" with the following initial contents, taken from Parameter Types" with the following initial contents, taken from
Table 2 of this document: Table 2 of this document:
--RE-CONFIG Chunk Parameter Types --RE-CONFIG Chunk Parameter Types
Chunk Parameter Type Value Chunk Parameter Type Value
-------------------- ---------- -------------------- ----------
Outgoing SSN Reset Request Parameter 13 (0x000d) Outgoing SSN Reset Request Parameter 13 (0x000d)
Incoming SSN Reset Request Parameter 14 (0x000e) Incoming SSN Reset Request Parameter 14 (0x000e)
SSN/TSN Reset Request Parameter 15 (0x000f) SSN/TSN Reset Request Parameter 15 (0x000f)
Re-configuration Response Parameter 16 (0x0010) Re-configuration Response Parameter 16 (0x0010)
Add Outgoing Streams Request Parameter 17 (0x0011) Add Outgoing Streams Request Parameter 17 (0x0011)
Add Incoming Streams Request Parameter 18 (0x0012)
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch, The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch,
Kacheong Poon, Irene Ruengeler, Robin Seggelmann, and Vlad Yasevich Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and
for there invaluable comments. Vlad Yasevich for there invaluable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
skipping to change at page 30, line 33 skipping to change at page 32, line 6
E-A E-Z E-A E-Z
-----------[RE-CONFIG(IN-REQ:X/1,2)]----------> -----------[RE-CONFIG(IN-REQ:X/1,2)]---------->
<--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]---------- <--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]----------
-------------[RE-CONFIG(RESP:Y)]--------------> -------------[RE-CONFIG(RESP:Y)]-------------->
The following example illustrates an Endpoint A resetting all streams The following example illustrates an Endpoint A resetting all streams
in both directions. in both directions.
E-A E-Z E-A E-Z
-----[RE-CONFIG(OUT-REQ:X,Y-1)|IN-REQ:X+1]----> -----[RE-CONFIG(OUT-REQ:X,Y-1|IN-REQ:X+1)]---->
<------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]------- <------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]-------
-------------[RE-CONFIG(RESP:Y)]--------------> -------------[RE-CONFIG(RESP:Y)]-------------->
The following example illustrates an Endpoint A requesting the The following example illustrates an Endpoint A requesting the
streams and TSNs be reset. At the completion E-A has the new sending streams and TSNs 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 TSN (selected by the peer) of B and E-Z has the new sending TSN of A
(also selected by the peer). (also selected by the peer).
E-A E-Z E-A E-Z
------------[RE-CONFIG(TSN-REQ:X)]------------> ------------[RE-CONFIG(TSN-REQ:X)]------------>
<-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]----- <-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]-----
The following example illustrates an Endpoint A requesting to add 3 The following example illustrates an Endpoint A requesting to add 3
additional outgoing streams. additional outgoing streams.
E-A E-Z E-A E-Z
--------[RE-CONFIG(ADD_OUT_STRMS:X/3)]--------> --------[RE-CONFIG(ADD_OUT_STRMS:X/3)]-------->
<-------------[RE-CONFIG(RESP:X)]-------------- <-------------[RE-CONFIG(RESP:X)]--------------
The following example illustrates an Endpoint A requesting to add 3
additional incoming streams.
E-A E-Z
---------[RE-CONFIG(ADD_IN_STRMS:X/3)]-------->
<----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y,X/3)]------
-------------[RE-CONFIG(RESP:Y)]-------------->
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Adara Networks Adara Networks
Chapin, SC 29036 Chapin, SC 29036
USA USA
Email: randall@lakerest.net Email: randall@lakerest.net
Michael Tuexen
Muenster University of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
DE
Email: tuexen@fh-muenster.de
Peter Lei Peter Lei
Cisco Systems, Inc. Cisco Systems, Inc.
8735 West Higgins Road 8735 West Higgins Road
Suite 300 Suite 300
Chicago, IL 60631 Chicago, IL 60631
USA USA
Email: peterlei@cisco.com Email: peterlei@cisco.com
Michael Tuexen
Muenster University of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
 End of changes. 57 change blocks. 
107 lines changed or deleted 200 lines changed or added

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