Network Working Group R. Stewart Internet-Draft Adara Networks Intended status: Standards Track M. Tuexen Expires: August 22, 2013 Muenster Univ. of Appl. Sciences February 18, 2013 A New Data Chunk for Stream Control Transmission Protocol draft-stewart-tsvwg-sctp-ndata-00.txt Abstract This document describes an extension to Stream Control Transmission Protocol (SCTP) which adds a new data chunk to SCTP. This new chunk is designed to follow closely the existing DATA chunk but incorporates a new field in the header, the Fragmentation Sequence Number (FSN). This new field is used for the purposes of fragmentation of large messages without causing head of line blocking. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 22, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Stewart & Tuexen Expires August 22, 2013 [Page 1] Internet-Draft SCTP NewData Chunk February 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SCTP N-DATA Format . . . . . . . . . . . . . . . . . . . . . . 3 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Socket API Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Stewart & Tuexen Expires August 22, 2013 [Page 2] Internet-Draft SCTP NewData Chunk February 2013 1. Introduction 1.1. Overview When SCTP [RFC4960] was first designed it was mainly envisioned for transport of small signaling messages. Late in the design stage it was decided to add support for fragmentation and reassembly of larger messages with the thought that someday Session Initiation Protocol (SIP) [RFC3261] style signaling messages may also need to use SCTP and a single MTU sized message would be too small. Unfortunately this design decision, though valid at the time, did not account for other applications which might wish to send very large messages over SCTP. When such large messages are now sent over SCTP a form of head of line blocking becomes created within the protocol. The head of line blocking is cause by the use of the Transmission Sequence Number (TSN) for reassembly. Once a large message is begun transmission, the message cannot be interspersed with other smaller messages but must be sent in sequence with respect to the TSN. This document describes a new Data chunk called N-DATA. This chunk incorporates all the flags and properties of the current SCTP Data chunk but also adds a new field in its header, the Fragment Sequence Number (FSN) and the usage of the I-bit (SACK immediately). The FSN is used to reassemble large messages without regard to the TSN. This then escapes the head of line blocking caused by the original design. 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. SCTP N-DATA Format The following Figure 1 shows the new data chunk N-DATA. Stewart & Tuexen Expires August 22, 2013 [Page 3] Internet-Draft SCTP NewData Chunk February 2013 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 = 17 | Res |I|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | Stream Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: N-DATA chunk format The only differences between the N-DATA chunk in Figure 1 and the DATA chunk defined in [RFC4960] is the addition of the I-bit in the flags field of the chunk header and the new Fragment Sequence Number. I bit: 1 bit The I-bit, if set, requests that the receiver of this data chunk not delay sending of any Acknowledgment but send the response SACK immediately. Fragment Sequence Number: 32 bits (unsigned integer) Identifies the fragment number of this piece of a message. FSN's MUST start at 0 and are unsigned numbers. The first fragment of a message MUST have the 'B' bit set and the last fragment of the message MUST have the 'E' bit set. Note that the FSN may wrap completely multiple times allowing infinitely large messages. 3. Procedures 3.1. Sender Side Considerations A sender MUST NOT send a N-DATA chunk unless the peer has indicated its support of the N-DATA chunk type within the Supported Extensions Parameter as defined in [RFC5061]. Stewart & Tuexen Expires August 22, 2013 [Page 4] Internet-Draft SCTP NewData Chunk February 2013 3.1.1. The I-bit Whenever the sender of a N-DATA chunk can benefit from the corresponding SACK chunk being sent back without delay, the sender MAY set the I-bit in the N-DATA chunk header. Please note that it is irrelevant to the receiver why the sender has set the I-bit. Reasons for setting the I-bit include but are not limited to the following: o The application requests to set the I-bit of the last N-DATA chunk of a user message when providing the user message to the SCTP implementation (see Section 4). o The sender is in the SHUTDOWN-PENDING state. o The sending of a N-DATA chunk fills the congestion or receiver window. o The sending of an Outgoing SSN Reset Request Parameter or an SSN/ TSN Reset Request Parameter is pending, if the association supports the Stream Reconfiguration extension defined in [RFC6525]. 3.1.2. Fragment Sequence Number A sender MUST NOT use the N-DATA chunk unless the user has requested that use via the socket API (see Section 4). This constraint is made since usage of this chunk requires that the application be willing to interleave messages upon reception within an association. This is not the default choice within the socket API (see [RFC6458]) thus the user MUST indicate support to the protocol of the reception of completely interleaved messages. Note that for stacks that do not implement [RFC6458] they may use other methods to indicate interleaved message support and thus enable the usage of the N-DATA chunk. Sender side usage of the N-Data chunk is quite simple. Instead of using the TSN for fragmentation purposes, the sender uses the new FSN field to indicate which fragment number is being sent. The first fragment MUST have the 'B' bit set. The last fragment MUST have the 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit set. If the 'I' bit is set the 'E' bit MUST also be set, i.e. the 'I' bit may only be set on the last fragment of a message. Note that the usage of this chunk should also imply late binding of the actual TSN to any chunk being sent. This way other messages from other streams may be interleaved with the fragmented message. Stewart & Tuexen Expires August 22, 2013 [Page 5] Internet-Draft SCTP NewData Chunk February 2013 The sender MUST NOT have more than one ordered fragmented message being produced in any one stream. The sender MUST NOT have more than one un-ordered fragmented message being produced in any one stream. The sender MAY have one ordered and one unordered fragmented message being produced within a single stream. At any time multiple streams MAY be producing an ordered fragmented message. 3.2. Receiver Side Considerations 3.2.1. The I-bit On reception of an SCTP packet containing a N-DATA chunk with the I-bit set, the receiver SHOULD NOT delay the sending of the corresponding SACK chunk and SHOULD send it back immediately. 3.2.2. Fragment Sequence Number Upon reception of an SCTP packet containing a N-DATA chunk if the message needs to be reassembled, then the receiver MUST use the FSN for reassembly of the message and not the TSN. Note that a non- fragmented messages is indicated by the fact that both the 'E' and 'B' bits are set. 4. Socket API Considerations This section describes how the socket API defined in [RFC6458] is extended to provide a way for the application to set the I-bit and to indicate that it would like to use the N-DATA chunk. Please note that this section is informational only. 4.1. SCTP_SACK_IMMEDIATELY A socket API implementation based on [RFC6458] is extended by supporting a flag called SCTP_SACK_IMMEDIATELY, which can be set in the snd_flags field of the struct sctp_sndinfo structure or the sinfo_flags field of the struct sctp_sndrcvinfo structure, which is deprecated. If the SCTP_SACK_IMMEDIATELY flag is set when sending a user message, the I-bit of the last DATA chunk of the corresponding user message is set. 4.2. SCTP_USE_NDATA A new socket option to turn on/off the usage of the NDATA chunk. Turning this this option on only effect future associations, and MUST Stewart & Tuexen Expires August 22, 2013 [Page 6] Internet-Draft SCTP NewData Chunk February 2013 be turned on for the protocol stack to indicate support of the NDATA chunk to the peer during association setup. Turning this flag off, will prevent the NDATA chunk from being indicated supported in future associations, and will also prevent current associations from producing NDATA chunks for future large fragmented messages. Note that this does not stop the peer from sending NDATA chunks however. 5. IANA Considerations This document defines the following new SCTP chunk (http://www.iana.org/assignments/sctp-parameters): o one new chunk types, The chunk types with their assigned values are shown below. Chunk Type Chunk Name -------------------------------------------------------------- 0x11 New Data Chunk (N-DATA) 6. Security Considerations This document does not add any additional security considerations in addition to the ones given in [RFC4960] and [RFC3758]. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. Stewart & Tuexen Expires August 22, 2013 [Page 7] Internet-Draft SCTP NewData Chunk February 2013 7.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011. [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012. Authors' Addresses Randall R. Stewart Adara Networks Chapin, SC 29036 US Email: randall@lakerest.net Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt DE Email: tuexen@fh-muenster.de Stewart & Tuexen Expires August 22, 2013 [Page 8]