One document matched: draft-stewart-tsvwg-sctp-ndata-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 00:43:46 |