idnits 2.17.1 draft-stewart-tsvwg-sctp-ndata-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2013) is 4079 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Adara Networks 4 Intended status: Standards Track M. Tuexen 5 Expires: August 22, 2013 Muenster Univ. of Appl. Sciences 6 February 18, 2013 8 A New Data Chunk for Stream Control Transmission Protocol 9 draft-stewart-tsvwg-sctp-ndata-00.txt 11 Abstract 13 This document describes an extension to Stream Control Transmission 14 Protocol (SCTP) which adds a new data chunk to SCTP. This new chunk 15 is designed to follow closely the existing DATA chunk but 16 incorporates a new field in the header, the Fragmentation Sequence 17 Number (FSN). This new field is used for the purposes of 18 fragmentation of large messages without causing head of line 19 blocking. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 22, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. SCTP N-DATA Format . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Socket API Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 1.1. Overview 70 When SCTP [RFC4960] was first designed it was mainly envisioned for 71 transport of small signaling messages. Late in the design stage it 72 was decided to add support for fragmentation and reassembly of larger 73 messages with the thought that someday Session Initiation Protocol 74 (SIP) [RFC3261] style signaling messages may also need to use SCTP 75 and a single MTU sized message would be too small. Unfortunately 76 this design decision, though valid at the time, did not account for 77 other applications which might wish to send very large messages over 78 SCTP. When such large messages are now sent over SCTP a form of head 79 of line blocking becomes created within the protocol. The head of 80 line blocking is cause by the use of the Transmission Sequence Number 81 (TSN) for reassembly. Once a large message is begun transmission, 82 the message cannot be interspersed with other smaller messages but 83 must be sent in sequence with respect to the TSN. 85 This document describes a new Data chunk called N-DATA. This chunk 86 incorporates all the flags and properties of the current SCTP Data 87 chunk but also adds a new field in its header, the Fragment Sequence 88 Number (FSN) and the usage of the I-bit (SACK immediately). The FSN 89 is used to reassemble large messages without regard to the TSN. This 90 then escapes the head of line blocking caused by the original design. 92 1.2. Conventions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. SCTP N-DATA Format 100 The following Figure 1 shows the new data chunk N-DATA. 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Type = 17 | Res |I|U|B|E| Length | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | TSN | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Stream Identifier | Stream Sequence Number | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Fragment Sequence Number | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Payload Protocol Identifier | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 \ \ 116 / User Data / 117 \ \ 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Figure 1: N-DATA chunk format 122 The only differences between the N-DATA chunk in Figure 1 and the 123 DATA chunk defined in [RFC4960] is the addition of the I-bit in the 124 flags field of the chunk header and the new Fragment Sequence Number. 126 I bit: 1 bit 128 The I-bit, if set, requests that the receiver of this data chunk 129 not delay sending of any Acknowledgment but send the response SACK 130 immediately. 132 Fragment Sequence Number: 32 bits (unsigned integer) 134 Identifies the fragment number of this piece of a message. FSN's 135 MUST start at 0 and are unsigned numbers. The first fragment of a 136 message MUST have the 'B' bit set and the last fragment of the 137 message MUST have the 'E' bit set. Note that the FSN may wrap 138 completely multiple times allowing infinitely large messages. 140 3. Procedures 142 3.1. Sender Side Considerations 144 A sender MUST NOT send a N-DATA chunk unless the peer has indicated 145 its support of the N-DATA chunk type within the Supported Extensions 146 Parameter as defined in [RFC5061]. 148 3.1.1. The I-bit 150 Whenever the sender of a N-DATA chunk can benefit from the 151 corresponding SACK chunk being sent back without delay, the sender 152 MAY set the I-bit in the N-DATA chunk header. Please note that it is 153 irrelevant to the receiver why the sender has set the I-bit. 155 Reasons for setting the I-bit include but are not limited to the 156 following: 158 o The application requests to set the I-bit of the last N-DATA chunk 159 of a user message when providing the user message to the SCTP 160 implementation (see Section 4). 162 o The sender is in the SHUTDOWN-PENDING state. 164 o The sending of a N-DATA chunk fills the congestion or receiver 165 window. 167 o The sending of an Outgoing SSN Reset Request Parameter or an SSN/ 168 TSN Reset Request Parameter is pending, if the association 169 supports the Stream Reconfiguration extension defined in 170 [RFC6525]. 172 3.1.2. Fragment Sequence Number 174 A sender MUST NOT use the N-DATA chunk unless the user has requested 175 that use via the socket API (see Section 4). This constraint is made 176 since usage of this chunk requires that the application be willing to 177 interleave messages upon reception within an association. This is 178 not the default choice within the socket API (see [RFC6458]) thus the 179 user MUST indicate support to the protocol of the reception of 180 completely interleaved messages. Note that for stacks that do not 181 implement [RFC6458] they may use other methods to indicate 182 interleaved message support and thus enable the usage of the N-DATA 183 chunk. 185 Sender side usage of the N-Data chunk is quite simple. Instead of 186 using the TSN for fragmentation purposes, the sender uses the new FSN 187 field to indicate which fragment number is being sent. The first 188 fragment MUST have the 'B' bit set. The last fragment MUST have the 189 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 190 set. If the 'I' bit is set the 'E' bit MUST also be set, i.e. the 191 'I' bit may only be set on the last fragment of a message. 193 Note that the usage of this chunk should also imply late binding of 194 the actual TSN to any chunk being sent. This way other messages from 195 other streams may be interleaved with the fragmented message. 197 The sender MUST NOT have more than one ordered fragmented message 198 being produced in any one stream. The sender MUST NOT have more than 199 one un-ordered fragmented message being produced in any one stream. 200 The sender MAY have one ordered and one unordered fragmented message 201 being produced within a single stream. At any time multiple streams 202 MAY be producing an ordered fragmented message. 204 3.2. Receiver Side Considerations 206 3.2.1. The I-bit 208 On reception of an SCTP packet containing a N-DATA chunk with the 209 I-bit set, the receiver SHOULD NOT delay the sending of the 210 corresponding SACK chunk and SHOULD send it back immediately. 212 3.2.2. Fragment Sequence Number 214 Upon reception of an SCTP packet containing a N-DATA chunk if the 215 message needs to be reassembled, then the receiver MUST use the FSN 216 for reassembly of the message and not the TSN. Note that a non- 217 fragmented messages is indicated by the fact that both the 'E' and 218 'B' bits are set. 220 4. Socket API Considerations 222 This section describes how the socket API defined in [RFC6458] is 223 extended to provide a way for the application to set the I-bit and to 224 indicate that it would like to use the N-DATA chunk. 226 Please note that this section is informational only. 228 4.1. SCTP_SACK_IMMEDIATELY 230 A socket API implementation based on [RFC6458] is extended by 231 supporting a flag called SCTP_SACK_IMMEDIATELY, which can be set in 232 the snd_flags field of the struct sctp_sndinfo structure or the 233 sinfo_flags field of the struct sctp_sndrcvinfo structure, which is 234 deprecated. 236 If the SCTP_SACK_IMMEDIATELY flag is set when sending a user message, 237 the I-bit of the last DATA chunk of the corresponding user message is 238 set. 240 4.2. SCTP_USE_NDATA 242 A new socket option to turn on/off the usage of the NDATA chunk. 243 Turning this this option on only effect future associations, and MUST 244 be turned on for the protocol stack to indicate support of the NDATA 245 chunk to the peer during association setup. Turning this flag off, 246 will prevent the NDATA chunk from being indicated supported in future 247 associations, and will also prevent current associations from 248 producing NDATA chunks for future large fragmented messages. Note 249 that this does not stop the peer from sending NDATA chunks however. 251 5. IANA Considerations 253 This document defines the following new SCTP chunk 254 (http://www.iana.org/assignments/sctp-parameters): 256 o one new chunk types, 258 The chunk types with their assigned values are shown below. 260 Chunk Type Chunk Name 261 -------------------------------------------------------------- 262 0x11 New Data Chunk (N-DATA) 264 6. Security Considerations 266 This document does not add any additional security considerations in 267 addition to the ones given in [RFC4960] and [RFC3758]. 269 7. References 271 7.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 277 Conrad, "Stream Control Transmission Protocol (SCTP) 278 Partial Reliability Extension", RFC 3758, May 2004. 280 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 281 RFC 4960, September 2007. 283 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 284 Kozuka, "Stream Control Transmission Protocol (SCTP) 285 Dynamic Address Reconfiguration", RFC 5061, 286 September 2007. 288 7.2. Informative References 290 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 291 A., Peterson, J., Sparks, R., Handley, M., and E. 292 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 293 June 2002. 295 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 296 Yasevich, "Sockets API Extensions for the Stream Control 297 Transmission Protocol (SCTP)", RFC 6458, December 2011. 299 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 300 Transmission Protocol (SCTP) Stream Reconfiguration", 301 RFC 6525, February 2012. 303 Authors' Addresses 305 Randall R. Stewart 306 Adara Networks 307 Chapin, SC 29036 308 US 310 Email: randall@lakerest.net 312 Michael Tuexen 313 Muenster University of Applied Sciences 314 Stegerwaldstrasse 39 315 48565 Steinfurt 316 DE 318 Email: tuexen@fh-muenster.de