Network Working Group INTERNET-DRAFT Date: 28 February 2001 Ka Cheong Leung Expires: 28 August 2001 Nokia Research Center SCTP Stream Function Extensions Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes two stream function extensions to SCTP (Stream Transmission Control Protocol) [SCTP]. These extensions are to allow dynamic modifications of stream status when U-SCTP (Unreliable Extension to SCTP) [USCTP] is activated and on demand insertion/deletion of streams within a SCTP association. These extensions will provide a better support of multimedia applications since they allow users to set and modify communication options, say the choices of transport and reliability requirements, on the fly. Leung [Page i] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3. New Reliable Request/Acknowledgement Parameters . . . . . . . . . 2 3.1. New REL-REQ Parameters . . . . . . . . . . . . . . . . . . . 2 3.1.1. Stream Status Modification . . . . . . . . . . . . . . . . 2 3.1.2. Stream Addition . . . . . . . . . . . . . . . . . . . . . 3 3.1.3. Stream Deletion . . . . . . . . . . . . . . . . . . . . . 4 3.2. New REL-ACK Parameters . . . . . . . . . . . . . . . . . . . 4 3.2.1. Error Cause: Failure to Modify Stream Statuses . . . . . . 5 3.2.2. Error Cause: Failure to Delete Streams . . . . . . . . . . 5 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Stream Status Modification . . . . . . . . . . . . . . . . . 6 4.2. Stream Addition and Deletion . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Leung [Page ii] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 1. Introduction To take advantage of the extensibility of the classic SCTP (Stream Control Transmission Protocol) [RFC2960] and the ability to transport reliable SCTP control chunks [RELREQ], this document introduces the use of the reliable control chunks to allow changes in stream status, and insertion and deletion of streams, dynamically within a SCTP association. The idea of introducing U-SCTP (SCTP Unreliable Data Mode Extension) [USCTP] is to support unreliable data delivery over the classic SCTP. In U-SCTP, a construct has been introduced to let a SCTP endpoint tell its peer SCTP endpoint which outbound stream(s) are unreliable. It also provides an option to notify its peer that the sender itself can support unreliable stream transport. This parameter option has been made available in both the INIT (Initiation) and INIT ACK (Initiation Acknowledgement) control chunks. Thus, it is possible to utilize that particular feature to support multimedia applications which allow users to set and to modify their communication options, such as the choices of transport and reliable requirements, on the fly. To make a better support for such applications, it is beneficial to have constructs to modify stream status as well. In delivering multimedia traffic for a single multimedia application, it is advantageous to employ different streams to transport information under different media, say voice, images, and videos. In addition, it is beneficial to send information of different priorities, such as transporting layered video streams, over different streams within the same SCTP association. However, depending on the usage, not every stream is active at all times. This means that, in some cases, some streams may have been initialized during the association phase but they are not used before the association is torn down. Therefore, it is a good idea to introduce some constructs that allow SCTP users, i.e. ULP (Upper- Layer Protocol) to dynamically add and delete streams within an association. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119]. Leung [Page 1] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 3. New Reliable Request/Acknowledgement Parameters This section describes the addition of three new REL-REQ Parameters to allow for the dynamic stream status modification, and the dynamic insertion and deletion of streams to an existing SCTP association. Two new REL-ACK parameters are introduced to handle communication errors or rejections of REL-REQ parameters. The format of these REL-REQ and REL-ACK parameters within the Reliable Request Chunk is described in [RELREQ]. 3.1. New REL-REQ Parameters The three new REL-REQ Parameters follow the format defined in Section 3.1.1 of [RELREQ]. These parameters are described as follows. REL-REQ Parameter Type Value ------------------------------------------------------- Stream Status Modification 49160 (0xC008) Add Stream 49161 (0xC009) Delete Stream 49162 (0xC00A) 3.1.1. Stream Status Modification 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 = 49160 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Stream Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream Parameters: TLV This field contains a set of stream parameters, which re-define which stream(s) are unreliable and which are reliable. Two stream parameters are defined as follows. Leung [Page 2] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 Parameter Name Status Type Value ---------------------------------------------------------- Unreliable Streams Optional 0xC000 Reliable Streams Optional 0xC008 The "Unreliable Streams" Parameter, which is originally designed to be used in INIT and INIT ACK control chunks only, has already been defined in Section 3.1 of [USCTP]. In this document, the functionality of that parameter is extended so that it is applicable to be used within REL-REQ control chunks. The "Reliable Streams" Parameter can be defined similarly as that of "Unreliable Streams". If an invalid stream identifier is contained in a REL-REQ control chunk, the whole modification operation SHOULD NOT go through and an operation error (with code type = 14) SHOULD be reported in a REL-ACK control chunk to the sender of the REL-REQ control chunk. Otherwise, if an endpoint fails to modify some or all the requested stream statuses due to resource shortage, the whole operation SHOULD NOT go through and an operation error (with code type = 12) SHOULD be reported in a REL-ACK control chunk to the sender of the REL-REQ control chunk. 3.1.2. Stream Addition 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 = 49161 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Stream Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream Parameters: TLV This field contains a set of stream parameters , which define which streams (identified by their stream identifiers) to be added as well as their types (i.e. reliable or unreliable). The format of stream parameters is described as in Section 3.1.1 of this document. If an endpoint fails to add inbound stream(s) due to resource constraints, the insertion operation MUST NOT go through and an operational error (with code type = 12, defined in Section 3.2 of Leung [Page 3] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 [ADDIP]) SHOULD be reported in a REQ-ACK control chunk to the sender of the REL-REQ control chunk. 3.1.3. Stream Deletion 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 = 49162 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Stream Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream Parameters: TLV This field contains a set of stream parameters , which define which streams (identified by their stream identifiers) to be deleted. If a stream, say a reliable stream, to be deleted is included in a incorrect stream parameter, say the "Unreliable Streams" Parameter. The deletion operation MUST NOT go through and an operational error (with code type = 15) SHOULD be reported in a REQ-ACK control chunk to the sender of the REL-REQ control chunk. The format of stream parameters is described as in Section 3.1.1 of this document. 3.2. New REL-ACK Parameters Two Error Causes are added to the SCTP Operational Errors. It is primarily used as a part of the REL-REQ Parameter Error reported in the REL-ACK, but MAY also be used in conjunction with an Operational Error or an Abort of a SCTP association, which is defined in RFC 2960 [RFC2960]. Cause Code Value Cause Code --------------------------------------------------------- 14 Failure to Modify Stream Statuses 15 Failure to Delete Streams Leung [Page 4] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 3.2.1. Error Cause: Failure to Modify Stream Statuses Cause of error: This error cause is used to report an error due to modifications of non-existence streams. The entire refused TLV is copied from the REL-REQ control chunk into the error cause. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code = 14 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Stream Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.2. Error Cause: Failure to Delete Streams Cause of error: This error cause is used to report an error due to a failure in deleting a non-existence stream, or no stream within an association if the operation is performed. The entire refused TLV is copied from the REL-REQ control chunk into the error cause. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code = 15 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Stream Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Procedures This section details the specific procedures for the dynamic stream status modification and the dynamic addition/deletion of streams within a SCTP association. The generic procedures for sending reliable SCTP control chunks are covered in [RELREQ]. Leung [Page 5] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 4.1. Stream Status Modification When constructing TLV parameters for the REL-REQ control chunks for modifying stream statuses, the following rules MUST be applied: A1) When modifying a stream status, the modification operation is NOT considered committed until the REL-ACK arrives. This means that the sender MUST NOT regard a stream with its new status until the request is acknowledged. A2) After the REL-ACK arrives and indicates (implicitly or explicitly) a successful operation, the endpoint MAY begin to operate a stream with its modified status. A3) When a stream switches from unreliable to reliable mode, it is possible that the receiver has accepted the modification request and switched the mode of that particular stream, but, at the same time, the sender has not yet received to the REL- ACK control chunk telling the acceptance from its peer. The sender keeps operating that stream under the unreliable mode and sends FORWARD TSN (Transmission Sequence Number) control chunks due to local advancements with respect to that particular stream to its peer. The peer MAY ignore these FORWARD TSN control chunks or it MAY continue to operate such FORWARD TSN control chunks for a small period of time as still valid. A4) If an endpoint receives an Error Cause indicating that its peer does not understand the requested parameters, the endpoint MUST consider the operation is failed and MUST NOT attempt to send any subsequent modification requests to its peer. A5) If a received request is to modify a non-existence stream or to switch some stream(s) to become unreliable but the receiver does not support unreliable data delivery for the association, it MUST refuse the operation and send an Error Cause TLV with the error cause set to the new error code "Failure to Modify Stream Statuses". The requested modification MUST NOT be performed or acted upon, other than to send the operation error. The requester (the sender of the REL-REQ control chunk) MAY indicate the operation error to the ULP. A6) If a request is received to perform stream status modification but the operation is failed due to resource shortage. the receiver MUST refuse the operation and send an Error Cause TLV with the error cause set to the error code "Operation Refused due to Resource Shortage". The requested modification MUST NOT be performed or acted upon, other than to send the operation Leung [Page 6] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 error. When the sender receives a REL-ACK with that error cause, it MUST NOT attempt to send any subsequent modification requests to its peer. The sender MAY indicate the operation error to the ULP. 4.2. Stream Addition and Deletion When constructing TLV parameters for the REL-REQ control chunks for adding or/and deleting streams, the following rules MUST be applied: B1) When adding or deleting a stream, the modification operation is NOT considered committed until the REL-ACK arrives. This means that the sender MUST NOT regard a stream with its new status until the request is acknowledged. B2) After the REL-ACK arrives and indicates (implicitly or explicitly) with a successful operation, the endpoint MAY begin to operate (or to send data) using a newly added stream, and to remove its record from the TCB (Transmission Control Block) and relinquish other resources for a deleted stream. The endpoint MAY elect to hold the stream valid for a small period of time as still valid. B3) If an endpoint receives an Error Cause indicating that its peer does not understand the requested parameters, the endpoint MUST consider the operation is failed and MUST NOT attempt to send any subsequent modification requests to its peer. B4) If a request is received to perform stream addition but the operation is failed due to resource shortage. the receiver MUST refuse the operation and send an Error Cause TLV with the error cause set to the error code "Operation Refused due to Resource Shortage". The requested modification MUST NOT be performed or acted upon, other than to send the operation error. When the sender receives a REL-ACK with that error cause, it MUST NOT attempt to send any subsequent stream addition requests to its peer. It MAY abort the association or, if keeping the existing association alive, indicate the operation error to the ULP. B5) If a request is received to delete a non-existence stream or no stream to be associated with an association if the operation is performed, the receiver MUST refuse the operation and send an Error Cause TLV with the error cause set to the new error code "Failure to Delete Streams". The requested operation MUST NOT be performed or acted upon, other than to send the operation error. The sender MAY indicate the operation error to the ULP. Leung [Page 7] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 B6) The sender MUST NOT send a REL-REQ to delete a stream where it has outstanding data waiting for acknowledgement. It can send the deletion request for streams only when there is no outstanding data to all of these outbound streams. B7) If a request is received to add an existing stream, that particular operation is automatically considered successful without making any specific changes to all control information keeping that particular inbound stream. 5. Security Considerations The reliable chunk passing mechanism does not add any security considerations other than those addressed by the classic SCTP protocol. The proposed extensions are not deemed to create any additional security hazards than those currently exist in an SCTP association. All threats and measures defined in [RFC2960] are applicable to these additional features. 6. IANA Considerations Three new REL-REQ Parameter Types and one new option within a REL-REQ Parameter, and two Error Codes are being defined within this document. 7. Acknowledgements The authors would like to thank Khiem Le, John Loughney, Christopher Clanton, and others for their invaluable comments for improving the quality of this document. Leung [Page 8] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 8. References [ADDIP] R. R. Stewart, Q. Xie, M. Tuexen, and I. Rytina, "SCTP Dynamic Addition of IP Addresses", draft-ietf-sigtran- addip-sctp-00.txt, Internet Draft, Network Working Group, Internet Engineering Task Force, 2 February 2001. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, Network Working Group, Internet Engineering Task Force, October 1996. [RFC219] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, Network Working Group, Internet Engineering Task Force, March 1997. [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, Network Working Group, Internet Engineering Task Force, October 2000. [RELREQ] R. Stewart, Q. Xie, M. Tuexen, and I. Rytina, "Generic Method for Transmitting Reliable SCTP Control Chunks", draft-ietf-sigtran-rel-req-sctp-00.txt, Internet Draft, Network Working Group, Internet Engineering Task Force, 2 February 2001. [USCTP] Q. Xie, R. Stewart, C. Sharp, and I. Rytina, "SCTP Unreliable Data Mode Extension", draft-ietf-sigtran- usctp-01.txt, Internet Draft, Network Working Group, Internet Engineering Task Force, February 2001. Leung [Page 9] INTERNET-DRAFT SCTP Stream Function Extensions 23 February 2001 9. Author's Address Ka Cheong Leung Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 374-0630 Fax: +1 972 894-4589 E-mail: kacheong.leung@nokia.com Leung [Page 10]