draft-ietf-tsvwg-sctp-strrst-12.txt   draft-ietf-tsvwg-sctp-strrst-13.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Adara Networks Internet-Draft Adara Networks
Intended status: Standards Track M. Tuexen Intended status: Standards Track M. Tuexen
Expires: February 7, 2012 Muenster Univ. of Appl. Sciences Expires: June 10, 2012 Muenster Univ. of Appl. Sciences
P. Lei P. Lei
Cisco Systems, Inc. Cisco Systems, Inc.
August 6, 2011 December 8, 2011
Stream Control Transmission Protocol (SCTP) Stream Reconfiguration Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
draft-ietf-tsvwg-sctp-strrst-12.txt draft-ietf-tsvwg-sctp-strrst-13.txt
Abstract Abstract
Many applications that use SCTP want the ability to "reset" a stream. Many applications that use 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 application layer that the reset has been performed. Applications
this feature want it so that they can "re-use" streams for different requiring this feature want it so that they can "re-use" streams for
purposes but still utilize the stream sequence number so that the different purposes but still utilize the stream sequence number so
application can track the message flows. Thus, without this feature, that the application can track the message flows. Thus, without this
a new use of an old stream would result in message numbers greater feature, a new use of an old stream would result in message numbers
than expected unless there is a protocol mechanism to "reset the greater than expected unless there is a protocol mechanism to "reset
streams back to zero". This document also includes methods for the streams back to zero". This document also includes methods for
resetting the transport sequence numbers, adding additional streams resetting the transport sequence numbers, adding additional streams
and resetting all stream sequence numbers. and resetting all stream sequence numbers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 7, 2012. This Internet-Draft will expire on June 10, 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 3, line 19 skipping to change at page 3, line 19
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 22 6. Socket API Considerations . . . . . . . . . . . . . . . . . . 22
6.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1.1. Stream Reset Event . . . . . . . . . . . . . . . . . . 23 6.1.1. Stream Reset Event . . . . . . . . . . . . . . . . . . 23
6.1.2. Association Reset Event . . . . . . . . . . . . . . . 24 6.1.2. Association Reset Event . . . . . . . . . . . . . . . 24
6.1.3. Stream Change Event . . . . . . . . . . . . . . . . . 25 6.1.3. Stream Change Event . . . . . . . . . . . . . . . . . 25
6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . 26 6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . 26
6.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 26 6.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 26
6.3.1. Enable/Disable Stream Reset 6.3.1. Enable/Disable Stream Reset
(SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 27 (SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 27
6.3.2. Reset Incoming and/or Outgoing Streams 6.3.2. Reset Incoming and/or Outgoing Streams
(SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 27 (SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 28
6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 28 6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 28
6.3.4. Add Incoming and/or Outgoing Streams 6.3.4. Add Incoming and/or Outgoing Streams
(SCTP_ADD_STREAMS) . . . . . . . . . . . . . . . . . . 28 (SCTP_ADD_STREAMS) . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 30 8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 30
8.2. Six New Parameter Types . . . . . . . . . . . . . . . . . 30 8.2. Six New Chunk Parameter Types . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Examples of the Re-configuration procedures . . . . . 31 Appendix A. Examples of the Re-configuration procedures . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Many applications that use SCTP want the ability to "reset" a stream. Many applications that use SCTP as defined in [RFC4960] want the
The intention of resetting a stream is to set the numbering sequence ability to "reset" a stream. The intention of resetting a stream is
of the stream back to 'zero' with a corresponding notification to the to set the stream sequence numbers (SSNs) of the stream back to
upper layer that this has been performed. The applications that want 'zero' with a corresponding notification to the application layer
this feature want to "re-use" streams for different purposes but that the reset has been performed. Applications requiring this
still utilize the stream sequence number so that the application can feature want to "re-use" streams for different purposes but still
track the message flows. Thus, without this feature, a new use of an utilize the stream sequence number so that the application can track
old stream would result in message numbers greater than expected the message flows. Thus, without this feature, a new use of an old
unless there is a protocol mechanism to "reset the streams back to stream would result in message numbers greater than expected unless
zero". This document also includes methods for resetting the there is a protocol mechanism to "reset the streams back to zero".
transport sequence numbers, adding additional streams and resetting This document also includes methods for resetting the transport
all stream sequence numbers. sequence numbers (TSNs), adding additional streams and resetting all
stream sequence numbers.
The socket API for SCTP defined in [I-D.ietf-tsvwg-sctpsocket] The socket API for SCTP defined in [I-D.ietf-tsvwg-sctpsocket]
exposes the sequence numbers used by SCTP for user message transfer. exposes the sequence numbers used by SCTP for user message transfer.
Therefore, resetting them can be used by application writers. Please Therefore, resetting them can be used by application writers. Please
note that the corresponding sequence number for TCP is not exposed note that the corresponding sequence number for TCP is not exposed
via the socket API for TCP. via the socket API for TCP.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 35 skipping to change at page 7, line 35
| Stream Number N-1 (optional) | Stream Number N (optional) | | Stream Number N-1 (optional) | Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type: 2 bytes (unsigned integer) Parameter Type: 2 bytes (unsigned integer)
This field holds the IANA defined parameter type for the Outgoing This field holds the IANA defined parameter type for the Outgoing
SSN Reset Request Parameter. The suggested value of this field SSN Reset Request Parameter. The suggested value of this field
for IANA is 0x000d. for IANA is 0x000d.
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter; the value This field holds the length in bytes of the parameter; the value
MUST be 16 + 2 * N. MUST be 16 + 2 * N, where N is the number of stream numbers
listed.
Re-configuration Request Sequence Number: 4 bytes (unsigned integer) Re-configuration Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new Initial TSN number. It is increased by 1 whenever sending a new
Re-configuration Request parameter. Re-configuration Request parameter.
Re-configuration Response Sequence Number: 4 bytes (unsigned Re-configuration Response Sequence Number: 4 bytes (unsigned
integer) integer)
When this Outgoing SSN Reset Request Parameter is sent in response When this Outgoing SSN Reset Request Parameter is sent in response
skipping to change at page 13, line 26 skipping to change at page 13, line 26
This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST
NOT appear in any other chunk type. NOT appear in any other chunk type.
5. Procedures 5. Procedures
This section defines the procedures used by both the sender and This section defines the procedures used by both the sender and
receiver of a RE-CONFIG chunk. Various examples of re-configuration receiver of a RE-CONFIG chunk. Various examples of re-configuration
scenarios are given in Appendix A. scenarios are given in Appendix A.
One important thing to remember about SCTP streams is that they are One important thing to remember about SCTP streams is that they are
uni-directional and there is no correspondence between outgoing and uni-directional. The endpoint for which a stream is an outgoing
incoming streams. The procedures outlined in this section are stream is called the outgoing side, the endpoint for which the stream
designed so that the incoming side will always reset their stream is an incoming stream is called the incoming side. The procedures
sequence number first before the outgoing side which means the re- outlined in this section are designed so that the incoming side will
configuration request must always originate from the outgoing side. always reset their stream sequence number first before the outgoing
These two issues have important ramifications upon how an SCTP side which means the re-configuration request must always originate
endpoint might request that its incoming streams be reset. In effect from the outgoing side. These two issues have important
it must ask the peer to start an outgoing reset procedure and once ramifications upon how an SCTP endpoint might request that its
that request is acknowledged let the peer actually control the reset incoming streams be reset. In effect it must ask the peer to start
operation. an outgoing reset procedure and once that request is acknowledged let
the peer actually control the reset operation.
5.1. Sender Side Procedures 5.1. Sender Side Procedures
This section describes the procedures related to the sending of RE- This section describes the procedures related to the sending of 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
This SCTP extension uses the Supported Extensions Parameter defined This SCTP extension uses the Supported Extensions Parameter defined
skipping to change at page 15, line 48 skipping to change at page 15, line 48
streams it can send an Incoming SSN Reset Request Parameter provided streams it can send an Incoming SSN Reset Request Parameter provided
that the Re-configuration Timer is not running. The following steps that the Re-configuration Timer is not running. The following steps
must be followed: must be followed:
B1: The sender MUST assign the next re-configuration request B1: The sender MUST assign the next re-configuration request
sequence number and MUST put it into the Re-configuration sequence number and MUST put it into the Re-configuration
Request Sequence Number field of the Incoming SSN Reset Request Request Sequence Number field of the Incoming SSN Reset Request
Parameter. After assigning it the next re-configuration request Parameter. After assigning it the next re-configuration request
sequence number MUST be incremented by 1. sequence number MUST be incremented by 1.
B2: If the sender wants all incoming streams to be reset no Stream B2: If the sender wants all incoming streams to be reset Stream
Numbers SHOULD be put into the Incoming SSN Reset Request Numbers SHOULD NOT be put into the Incoming SSN Reset Request
Parameter. If the sender wants only some incoming streams to be Parameter. If the sender wants only some incoming streams to be
reset these Stream Numbers MUST be filled in the Incoming SSN reset these Stream Numbers MUST be filled in the Incoming SSN
Reset Request Parameter. Reset Request Parameter.
B3: The Incoming SSN Reset Request Parameter MUST be put into a RE- B3: The Incoming SSN Reset Request Parameter MUST be put into a 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
skipping to change at page 21, line 16 skipping to change at page 21, line 16
chunk is processed completely. chunk is processed completely.
5.2.5. Receiver Side Procedures for the Add Outgoing Streams Request 5.2.5. Receiver Side Procedures for the Add Outgoing Streams Request
Parameter Parameter
When an SCTP endpoint receives a re-configuration request adding When an SCTP endpoint receives a re-configuration request adding
additional streams, it MUST send a response parameter either additional streams, it MUST send a response parameter either
acknowledging or denying the request. If the response is successful acknowledging or denying the request. If the response is successful
the receiver MUST add the requested number of inbound streams to the the receiver MUST add the requested number of inbound streams to the
association, initializing the next expected stream sequence number to association, initializing the next expected stream sequence number to
be 0. be 0. The SCTP endpoint SHOULD deny the request if the number of
streams exceeds a limit which should be configurable by the
application.
5.2.6. Receiver Side Procedures for the Add Incoming Streams Request 5.2.6. Receiver Side Procedures for the Add Incoming Streams Request
Parameter Parameter
When an SCTP endpoint receives a re-configuration request adding When an SCTP endpoint receives a re-configuration request adding
additional incoming streams, it MUST either send a response parameter additional incoming streams, it MUST either send a response parameter
denying the request or sending a corresponding Add Outgoing Streams denying the request or sending a corresponding Add Outgoing Streams
Request Parameter following the rules given in Section 5.1.6. Request Parameter following the rules given in Section 5.1.6. The
SCTP endpoint SHOULD deny the request if the number of streams
exceeds a limit which should be configurable by the application.
5.2.7. Receiver Side Procedures for the Re-configuration Response 5.2.7. Receiver Side Procedures for the Re-configuration Response
Parameter Parameter
On receipt of a Re-configuration Response Parameter the following On receipt of a Re-configuration Response Parameter the following
must be performed: must be performed:
H1: If the Re-confguration Timer is running for the Re-configuration H1: If the Re-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
skipping to change at page 29, line 26 skipping to change at page 29, line 40
issuing an SCTP_INIT socket option, as defined in 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 applications must enable this
explicitly before it is used. In addition, application must extension explicitly before it is used. In addition, applications
subscribe explicitly to notifications related to the re-configuration must subscribe explicitly to notifications related to the re-
extension before receiving them. configuration extension before receiving them.
SCTP associations are protected against blind attackers by using the SCTP associations are protected against blind attackers by using the
verification tags. This is still valid when using the re- verification tags. This is still valid when using the re-
configuration extension. Therefore this extension does not add any configuration extension. Therefore this extension does not add any
additional security risk to SCTP in relation to blind attackers. additional security risk to SCTP in relation to blind attackers.
When the both sequence numbers are reset, the maximum segment When the both sequence numbers are reset, the maximum segment
lifetime is used to avoid the wrap-around for the TSN. lifetime is used to avoid the wrap-around for the TSN.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 30, line 20 skipping to change at page 30, line 31
This document (RFCXXXX) is the reference for all registrations This document (RFCXXXX) is the reference for all registrations
described in this section. The suggested changes are described described in this section. The suggested changes are described
below. below.
8.1. A New Chunk Type 8.1. A New Chunk Type
A chunk type has to be assigned by IANA. It is suggested to use the A chunk type has to be assigned by IANA. It is suggested to use the
values given in Table 1. IANA should assign this value from the pool values given in Table 1. IANA should assign this value from the pool
of chunks with the upper two bits set to '10'. of chunks with the upper two bits set to '10'.
This requires an additional line in the "CHUNK TYPES" table for SCTP: This requires an additional line in the "Chunk Types" registry for
SCTP:
CHUNK TYPES Chunk Types
ID Value Chunk Type Reference ID Value Chunk Type Reference
----- ---------- --------- ----- ---------- ---------
130 Re-configuration Chunk (RE-CONFIG) [RFCXXXX] 130 Re-configuration Chunk (RE-CONFIG) [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. Six New Parameter Types 8.2. Six New Chunk Parameter Types
IANA is requested to create a new sub-registry, "RE-CONFIG Chunk Six chunk parameter types have to be assigned by IANA. It is
Parameter Types" with the following initial contents, taken from suggested to use the values given in Table 2. IANA should assign
Table 2 of this document: these values from the pool of parameters with the upper two bits set
to '00'.
--RE-CONFIG Chunk Parameter Types This requires six additional lines in the "Chunk Parameter Types"
registry for SCTP:
Chunk Parameter Type Value Chunk Parameter Types
-------------------- ----------
Outgoing SSN Reset Request Parameter 13 (0x000d) ID Value Chunk Parameter Type Reference
Incoming SSN Reset Request Parameter 14 (0x000e) -------- ------------------------------------------------ ---------
SSN/TSN Reset Request Parameter 15 (0x000f) 13 Outgoing SSN Reset Request Parameter [RFCXXXX]
Re-configuration Response Parameter 16 (0x0010) 14 Incoming SSN Reset Request Parameter [RFCXXXX]
Add Outgoing Streams Request Parameter 17 (0x0011) 15 SSN/TSN Reset Request Parameter [RFCXXXX]
Add Incoming Streams Request Parameter 18 (0x0012) 16 Re-configuration Response Parameter [RFCXXXX]
17 Add Outgoing Streams Request Parameter [RFCXXXX]
18 Add Incoming Streams Request Parameter [RFCXXXX]
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch, The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch,
Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and
Vlad Yasevich for there invaluable comments. Vlad Yasevich for there invaluable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 31, line 35 skipping to change at page 32, line 4
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Chunk Flags Registration", RFC 6096, Protocol (SCTP) Chunk Flags Registration", RFC 6096,
January 2011. January 2011.
10.2. Informative References 10.2. Informative References
[I-D.ietf-tsvwg-sctpsocket] [I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for Stream Control Yasevich, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-30 (work in progress), draft-ietf-tsvwg-sctpsocket-32 (work in progress),
June 2011. October 2011.
Appendix A. Examples of the Re-configuration procedures Appendix A. Examples of the Re-configuration procedures
Please note that this appendix is informational only. Please note that this appendix is informational only.
The following message flows between an Endpoint A and an Endpoint Z The following message flows between an Endpoint A and an Endpoint Z
illustrate the described procedures. The time progresses in downward illustrate the described procedures. The time progresses in downward
direction. direction.
The following example illustrates an Endpoint A resetting stream 1 The following example illustrates an Endpoint A resetting stream 1
 End of changes. 24 change blocks. 
66 lines changed or deleted 78 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/