A New Data Chunk for Stream Control Transmission Protocol
draft-stewart-tsvwg-sctp-ndata-00

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]