draft-ietf-tsvwg-sctp-strrst-11.txt   draft-ietf-tsvwg-sctp-strrst-12.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: January 11, 2012 Muenster Univ. of Appl. Sciences Expires: February 7, 2012 Muenster Univ. of Appl. Sciences
P. Lei P. Lei
Cisco Systems, Inc. Cisco Systems, Inc.
July 10, 2011 August 6, 2011
Stream Control Transmission Protocol (SCTP) Stream Reconfiguration Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
draft-ietf-tsvwg-sctp-strrst-11.txt draft-ietf-tsvwg-sctp-strrst-12.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 January 11, 2012. This Internet-Draft will expire on February 7, 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 4 skipping to change at page 3, line 4
Streams Request Parameter . . . . . . . . . . . . . . 17 Streams Request Parameter . . . . . . . . . . . . . . 17
5.2. Receiver Side Procedures . . . . . . . . . . . . . . . . . 18 5.2. Receiver Side Procedures . . . . . . . . . . . . . . . . . 18
5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk . . . 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 . . . . . . . . . . . . . . . 18 Reset Request Parameter . . . . . . . . . . . . . . . 18
5.2.3. Receiver Side Procedures for the Incoming SSN 5.2.3. Receiver Side Procedures for the Incoming SSN
Reset Request Parameter . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . 20 Streams Request Parameter . . . . . . . . . . . . . . 21
5.2.6. Receiver Side Procedures for the Add Incoming 5.2.6. Receiver Side Procedures for the Add Incoming
Streams Request Parameter . . . . . . . . . . . . . . 21 Streams Request Parameter . . . . . . . . . . . . . . 21
5.2.7. Receiver Side Procedures for the Re-configuration 5.2.7. Receiver Side Procedures for the Re-configuration
Response Parameter . . . . . . . . . . . . . . . . . . 21 Response Parameter . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . . . 25 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) . . . . . . . . . . . . . . 26 (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) . . . . . . . . . . . . . . . . . 27
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) . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 29 8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 30
8.2. Six New Parameter Types . . . . . . . . . . . . . . . . . 30 8.2. Six New Parameter Types . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 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 . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 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
skipping to change at page 19, line 49 skipping to change at page 19, line 49
possible that the local endpoint has just sent an Outgoing SSN Reset possible that the local endpoint has just sent an Outgoing SSN Reset
Request on the same association and has not yet received a response. Request on the same association and has not yet received a response.
In such a case the local endpoint MUST do the following: In such a case the local endpoint MUST do the following:
o If the just sent Outgoing SSN Reset Request Parameter completely o If the just sent Outgoing SSN Reset Request Parameter completely
overlaps the received Incoming SSN Reset Request Parameter respond overlaps the received Incoming SSN Reset Request Parameter respond
to the peer with an acknowledgment indicating that there was to the peer with an acknowledgment indicating that there was
'Nothing to do'. 'Nothing to do'.
o Otherwise process the Incoming SSN Reset Request Parameter o Otherwise process the Incoming SSN Reset Request Parameter
normally responding to the peer with an acknowledgment. normally responding to the peer with an acknowledgment. Note that
this case includes the situation where some of the streams
requested overlap with the just sent Outgoing SSN Reset Request.
Even in such a situation the Incoming SSN Reset MUST be processed
normally even though this means that (if the endpoint elects to do
the stream reset) streams that are already at SSN 0, will be reset
a subsequent time.
It is also possible that the Incoming request will arrive after the It is also possible that the Incoming request will arrive after the
Outgoing SSN Reset Request just completed. In such a case all of the Outgoing SSN Reset Request just completed. In such a case all of 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
 End of changes. 10 change blocks. 
11 lines changed or deleted 18 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/