idnits 2.17.1 draft-stewart-tsvwg-sctp-ndata-01.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 24, 2013) is 4069 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) == Missing Reference: 'RFCXXXX' is mentioned on line 256, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) == Outdated reference: A later version (-04) exists of draft-ietf-tsvwg-sctp-sack-immediately-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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 28, 2013 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 February 24, 2013 10 A New Data Chunk for Stream Control Transmission Protocol 11 draft-stewart-tsvwg-sctp-ndata-01.txt 13 Abstract 15 The Stream Control Transmission Protocol (SCTP) is a message oriented 16 transport protocol supporting arbitrary large user messages. 17 However, the sender can not interleave different user messages which 18 which causes head of line blocking at the sender side. To overcome 19 this limitation, this document adds a new data chunk to SCTP. 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 28, 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. N-DATA Chunk . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Socket API Considerations . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 1.1. Overview 70 When SCTP [RFC4960] was initially designed it was mainly envisioned 71 for transport of small signaling messages. Late in the design stage 72 it was decided to add support for fragmentation and reassembly of 73 larger messages with the thought that someday Session Initiation 74 Protocol (SIP) [RFC3261] style signaling messages may also need to 75 use SCTP and a single MTU sized message would be too small. 76 Unfortunately this design decision, though valid at the time, did not 77 account for other applications which might send very large messages 78 over SCTP. When such large messages are now sent over SCTP a form of 79 sender side head of line blocking becomes created within the 80 protocol. This head of line blocking is caused by the use of the 81 Transmission Sequence Number (TSN) for two different purposes: 83 1. As an identifier for DATA chunks to provide a reliable transfer. 85 2. As an identifier for the sequence of fragments to allow 86 reassembly. 88 The protocol requires all fragments of a user message to have 89 consecutive TSNs. Therefore the sender can not interleave different 90 messages. 92 This document describes a new Data chunk called N-DATA. This chunk 93 incorporates all the flags and properties of the current SCTP Data 94 chunk but also adds a new field in its chunk header, the Fragment 95 Sequence Number (FSN). Then the FSN is only used for reassembly and 96 the TSN only for the reliability. Therefore, the head of line 97 blocking caused by the original design is avoided. 99 1.2. Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. N-DATA Chunk 107 The following Figure 1 shows the new data chunk N-DATA. 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Type = 17 | Res |I|U|B|E| Length | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | TSN | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Stream Identifier | Stream Sequence Number | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Payload Protocol Identifier | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Fragment Sequence Number | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 \ \ 123 / User Data / 124 \ \ 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Figure 1: N-DATA chunk format 129 The only differences between the N-DATA chunk in Figure 1 and the 130 DATA chunk defined in [RFC4960] and 131 [I-D.ietf-tsvwg-sctp-sack-immediately] is the addition of the new 132 Fragment Sequence Number (FSN). 134 Fragment Sequence Number (FSN): 32 bits (unsigned integer) 135 Identifies the fragment number of this piece of a message. FSN's 136 are unsigned number, the first fragment MUST start at 0 and MUST 137 have the 'B' bit set. The last fragment of a message MUST have 138 the 'E' bit set. Note that the FSN may wrap completely multiple 139 times allowing arbitrary large messages. Please note that the FSN 140 is in "network byte order", a.k.a. Big Endian. 142 3. Procedures 144 3.1. Sender Side Considerations 146 A sender MUST NOT send a N-DATA chunk unless the peer has indicated 147 its support of the N-DATA chunk type within the Supported Extensions 148 Parameter as defined in [RFC5061]. 150 A sender MUST NOT use the N-DATA chunk unless the user has requested 151 that use via the socket API (see Section 4). This constraint is made 152 since usage of this chunk requires that the application be willing to 153 interleave messages upon reception within an association. This is 154 not the default choice within the socket API (see [RFC6458]) thus the 155 user MUST indicate support to the protocol of the reception of 156 completely interleaved messages. Note that for stacks that do not 157 implement [RFC6458] they may use other methods to indicate 158 interleaved message support and thus enable the usage of the N-DATA 159 chunk, the key is that the the stack MUST know the application has 160 indicated its choice in wanting to use the extension. 162 Sender side usage of the N-Data chunk is quite simple. Instead of 163 using the TSN for fragmentation purposes, the sender uses the new FSN 164 field to indicate which fragment number is being sent. The first 165 fragment MUST have the 'B' bit set. The last fragment MUST have the 166 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 167 set. If the 'I' bit is set the 'E' bit MUST also be set, i.e. the 168 'I' bit may only be set on the last fragment of a message. All other 169 properties of the existing SCTP DATA chunk also apply to the N-DATA 170 chunk, i.e. congestion control as well as receiver window conditions 171 MUST be observed as defined in [RFC4960]. 173 Note that the usage of this chunk should also imply late binding of 174 the actual TSN to any chunk being sent. This way other messages from 175 other streams may be interleaved with the fragmented message. 177 The sender MUST NOT have more than one ordered fragmented message 178 being produced in any one stream. The sender MUST NOT have more than 179 one un-ordered fragmented message being produced in any one stream. 180 The sender MAY have one ordered and one unordered fragmented message 181 being produced within a single stream. At any time multiple streams 182 MAY be producing an ordered or unordered fragmented message. 184 3.2. Receiver Side Considerations 186 Upon reception of an SCTP packet containing a N-DATA chunk if the 187 message needs to be reassembled, then the receiver MUST use the FSN 188 for reassembly of the message and not the TSN. Note that a non- 189 fragmented messages is indicated by the fact that both the 'E' and 190 'B' bits are set. A fragmented message is thus identified with any 191 message not having both bits set. 193 4. Socket API Considerations 195 This section describes how the socket API defined in [RFC6458] is 196 extended to allow applications to use the extension described in this 197 document. 199 Please note that this section is informational only. 201 4.1. SCTP_USE_NDATA 203 A new socket option to turn on/off the usage of the N-DATA chunk. 204 Turning this this option on only effect future associations, and MUST 205 be turned on for the protocol stack to indicate support of the N-DATA 206 chunk to the peer during association setup. Turning this option off, 207 will prevent the N-DATA chunk from being indicated supported in 208 future associations, and will also prevent current associations from 209 producing N-DATA chunks for future large fragmented messages. Note 210 that this does not stop the peer from sending N-DATA chunks. 212 An N-DATA chunk aware application should also set the fragment 213 interleave level to 2. This allows the reception from multiple 214 streams simultaneously. Failure to set this option can possibly lead 215 to application deadlock. 217 5. IANA Considerations 219 [NOTE to RFC-Editor: 221 "RFCXXXX" is to be replaced by the RFC number you assign this 222 document. 224 ] 226 [NOTE to RFC-Editor: 228 The suggested values for the chunk type and the chunk flags are 229 tentative and to be confirmed by IANA. 231 ] 233 This document (RFCXXXX) is the reference for all registrations 234 described in this section. 236 A new chunk type has to be assigned by IANA. IANA should assign this 237 value from the pool of chunks with the upper two bits set to '00'. 238 This requires an additional line in the "Chunk Types" registry for 239 SCTP: 241 +----------+-------------------------+-----------+ 242 | ID Value | Chunk Type | Reference | 243 +----------+-------------------------+-----------+ 244 | 17 | New DATA chunk (N-DATA) | [RFCXXXX] | 245 +----------+-------------------------+-----------+ 247 The registration table as defined in [RFC6096] for the chunk flags of 248 this chunk type is initially given by the following table: 250 +------------------+-----------------+-----------+ 251 | Chunk Flag Value | Chunk Flag Name | Reference | 252 +------------------+-----------------+-----------+ 253 | 0x01 | E bit | [RFCXXXX] | 254 | 0x02 | B bit | [RFCXXXX] | 255 | 0x04 | U bit | [RFCXXXX] | 256 | 0x08 | I bit | [RFCXXXX] | 257 +------------------+-----------------+-----------+ 259 6. Security Considerations 261 This document does not add any additional security considerations in 262 addition to the ones given in [RFC4960] and [RFC6458]. 264 7. References 266 7.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 272 RFC 4960, September 2007. 274 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 275 Kozuka, "Stream Control Transmission Protocol (SCTP) 276 Dynamic Address Reconfiguration", RFC 5061, 277 September 2007. 279 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 280 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 281 January 2011. 283 [I-D.ietf-tsvwg-sctp-sack-immediately] 284 Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 285 IMMEDIATELY Extension for the Stream Control Transmission 286 Protocol", draft-ietf-tsvwg-sctp-sack-immediately-00 (work 287 in progress), February 2013. 289 7.2. Informative References 291 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 292 A., Peterson, J., Sparks, R., Handley, M., and E. 293 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 294 June 2002. 296 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 297 Yasevich, "Sockets API Extensions for the Stream Control 298 Transmission Protocol (SCTP)", RFC 6458, December 2011. 300 Authors' Addresses 302 Randall R. Stewart 303 Adara Networks 304 Chapin, SC 29036 305 US 307 Email: randall@lakerest.net 309 Michael Tuexen 310 Muenster University of Applied Sciences 311 Stegerwaldstrasse 39 312 48565 Steinfurt 313 DE 315 Email: tuexen@fh-muenster.de 317 Salvatore Loreto 318 Ericsson 319 Hirsalantie 11 320 Jorvas 02420 321 FI 323 Email: Salvatore.Loreto@ericsson.com