idnits 2.17.1 draft-ietf-tsvwg-sctp-ndata-03.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 (March 9, 2015) is 3336 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 519, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7053 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 2 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 Netflix, Inc. 4 Intended status: Standards Track M. Tuexen 5 Expires: September 10, 2015 Muenster Univ. of Appl. Sciences 6 S. Loreto 7 Ericsson 8 R. Seggelmann 9 T-Systems International GmbH 10 March 9, 2015 12 Stream Schedulers and User Message Interleaving for the Stream Control 13 Transmission Protocol 14 draft-ietf-tsvwg-sctp-ndata-03.txt 16 Abstract 18 The Stream Control Transmission Protocol (SCTP) is a message oriented 19 transport protocol supporting arbitrary large user messages. 20 However, the sender can not interleave different user messages which 21 causes head of line blocking at the sender side. To overcome this 22 limitation, this document adds a new data chunk to SCTP. 24 Whenever an SCTP sender is allowed to send a user data, it can 25 possibly choose from multiple outgoing SCTP streams. Multiple ways 26 for this selection, called stream schedulers, are defined. Some of 27 them don't require the support of user message interleaving, some do. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 10, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. User Message Interleaving . . . . . . . . . . . . . . . . . . 4 67 2.1. The I-DATA Chunk supporting User Message Interleaving . . 4 68 2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . 5 70 2.2.2. Sender Side Considerations . . . . . . . . . . . . . 6 71 2.2.3. Receiver Side Considerations . . . . . . . . . . . . 6 72 2.3. Interaction with other SCTP Extensions . . . . . . . . . 6 73 2.3.1. SCTP Partial Reliability Extension . . . . . . . . . 7 74 2.3.2. SCTP Stream Reconfiguration Extension . . . . . . . . 7 75 3. Stream Schedulers . . . . . . . . . . . . . . . . . . . . . . 7 76 3.1. Stream Scheduler without User Message Interleaving 77 Support . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.2. Stream Scheduler with User Message Interleaving Support . 7 79 4. Socket API Considerations . . . . . . . . . . . . . . . . . . 7 80 4.1. SCTP_ASSOC_CHANGE Notification . . . . . . . . . . . . . 7 81 4.2. Socket Options . . . . . . . . . . . . . . . . . . . . . 7 82 4.2.1. Enable or Disable the Support of User Message 83 Interleaving . . . . . . . . . . . . . . . . . . . . 8 84 4.2.2. Get or Set the Stream Scheduler (SCTP_PLUGGABLE_SS) . 9 85 4.2.3. Get or Set the Stream Scheduler Parameter 86 (SCTP_SS_VALUE) . . . . . . . . . . . . . . . . . . . 10 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 8.2. Informative References . . . . . . . . . . . . . . . . . 13 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 1.1. Overview 99 When SCTP [RFC4960] was initially designed it was mainly envisioned 100 for transport of small signaling messages. Late in the design stage 101 it was decided to add support for fragmentation and reassembly of 102 larger messages with the thought that someday Session Initiation 103 Protocol (SIP) [RFC3261] style signaling messages may also need to 104 use SCTP and a single MTU sized message would be too small. 105 Unfortunately this design decision, though valid at the time, did not 106 account for other applications which might send very large messages 107 over SCTP. When such large messages are now sent over SCTP a form of 108 sender side head of line blocking becomes created within the 109 protocol. This head of line blocking is caused by the use of the 110 Transmission Sequence Number (TSN) for two different purposes: 112 1. As an identifier for DATA chunks to provide a reliable transfer. 114 2. As an identifier for the sequence of fragments to allow 115 reassembly. 117 The protocol requires all fragments of a user message to have 118 consecutive TSNs. Therefore it is impossible for the sender to 119 interleave different user messages. 121 This document describes a new Data chunk called I-DATA. This chunk 122 incorporates all the flags and fields except the Stream Sequence 123 Number (SSN) and properties of the current SCTP Data chunk but also 124 adds two new fields in its chunk header, the Fragment Sequence Number 125 (FSN) and the Message Identifier (MID). Then the FSN is only used 126 for reassembling all fragments with the same MID and the TSN only for 127 the reliability. The MID is also used for ensuring ordered delivery, 128 therefore replacing the stream sequence number. Therefore, the head 129 of line blocking caused by the original design is avoided. 131 The support of the I-DATA chunk is negotiated during the association 132 setup using the Supported Extensions Parameter as defined in 133 [RFC5061]. If I-DATA support has been negotiated for an association 134 I-DATA chunks are used for all user-messages and no DATA chunks. It 135 should be noted, that an SCTP implementation needs to support the 136 coexistence of associations using DATA chunks and associations using 137 I-DATA chunks. 139 This document also defines several stream schedulers for general SCTP 140 associations. If I-DATA support has been negotiated, several more 141 schedulers are available. 143 1.2. Conventions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. User Message Interleaving 151 2.1. The I-DATA Chunk supporting User Message Interleaving 153 The following Figure 1 shows the new I-DATA chunk allowing user 154 messages interleaving. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type = 64 | Res |I|U|B|E| Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | TSN | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Stream Identifier | Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Message Identifier | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Payload Protocol Identifier / Fragment Sequence Number | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 \ \ 170 / User Data / 171 \ \ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: I-DATA chunk format 176 The only differences between the I-DATA chunk in Figure 1 and the 177 DATA chunk defined in [RFC4960] and [RFC7053] is the addition of the 178 new Message Identifier (MID) and Fragment Sequence Number (FSN) and 179 the removal of the Stream Sequence Number (SSN). However, the lower 180 16-bit of the MID can be used as the SSN if necessary. The length of 181 the I-DATA chunk header is 20 bytes, which is 4 bytes more than the 182 length of the DATA chunk header defined in [RFC4960]. 184 Reserved: 16 bits (unsigned integer) 185 This field is reserved. It SHOULD be set to 0 by the sender and 186 ignored by the receiver. 188 Message Identifier (MID): 32 bits (unsigned integer) 189 The MID is the same for all fragments of a user message, it is 190 used to determine which fragments (enumerated by the FSN) belong 191 to the same user message. For ordered user messages, the MID is 192 also used by the SCTP receiver to deliver the user messages in the 193 correct order to the upper layer (similar to the SSN of the DATA 194 chunk defined in [RFC4960]). The sender uses two counters, one 195 for ordered messages, one for unordered messages, for each 196 outgoing streams. All counters are independent and initially 0. 197 They are incremented by 1 for each user message. Please note that 198 the serial number arithmetic defined in [RFC1982] using 199 SERIAL_BITS = 32 applies. Therefore the sender MUST NOT have more 200 than 2**31 - 1 ordered messages for each outgoing stream in flight 201 and MUST NOT have more than 2**31 - 1 unordered messages for each 202 outgoing stream in flight. For ordered user messages, the lower 203 16 bit of the MID can be used as a SSN if required. Please note 204 that the MID is in "network byte order", a.k.a. Big Endian. 206 Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 207 32 bits (unsigned integer) 208 If the B bit is set, this field contains the PPID of the user 209 message. In this case the FSN is implicitly considered to be 0. 210 If the B bit is not set, this field contains the FSN. The FSN is 211 used to enumerate all fragments of a single user message, starting 212 from 0 and incremented by 1. The last fragment of a message MUST 213 have the 'E' bit set. Note that the FSN MAY wrap completely 214 multiple times allowing arbitrary large user messages. For the 215 FSN the serial number arithmetic defined in [RFC1982] applies with 216 SERIAL_BITS = 32. Therefore a sender MUST NOT have more than 217 2**31 - 1 fragments of a single user message in flight. Please 218 note that the FSN is in "network byte order", a.k.a. Big Endian. 220 2.2. Procedures 222 This subsection describes how the support of the I-DATA chunk is 223 negotiated and how the I-DATA chunk is used by the sender and 224 receiver. 226 2.2.1. Negotiation 228 A sender MUST NOT send a I-DATA chunk unless both peers have 229 indicated its support of the I-DATA chunk type within the Supported 230 Extensions Parameter as defined in [RFC5061]. If I-DATA support has 231 been negotiated on an association, I-DATA chunks MUST be used for all 232 user messages and DATA-chunk MUST NOT be used. If I-DATA support has 233 not been negotiated on an association, DATA chunks MUST be used for 234 all user messages and I-DATA chunks MUST NOT be used. 236 A sender MUST NOT use the I-DATA chunk unless the user has requested 237 that use (e.g. via the socket API, see Section 4). This constraint 238 is made since usage of this chunk requires that the application be 239 willing to interleave messages upon reception within an association. 240 This is not the default choice within the socket API (see [RFC6458]) 241 thus the user MUST indicate support to the protocol of the reception 242 of completely interleaved messages. Note that for stacks that do not 243 implement [RFC6458] they may use other methods to indicate 244 interleaved message support and thus enable the usage of the I-DATA 245 chunk, the key is that the the stack MUST know the application has 246 indicated its choice in wanting to use the extension. 248 2.2.2. Sender Side Considerations 250 Sender side usage of the I-DATA chunk is quite simple. Instead of 251 using the TSN for fragmentation purposes, the sender uses the new FSN 252 field to indicate which fragment number is being sent. The first 253 fragment MUST have the 'B' bit set. The last fragment MUST have the 254 'E' bit set. All other fragments MUST NOT have the 'B' or 'E' bit 255 set. All other properties of the existing SCTP DATA chunk also apply 256 to the I-DATA chunk, i.e. congestion control as well as receiver 257 window conditions MUST be observed as defined in [RFC4960]. 259 Note that the usage of this chunk should also imply late binding of 260 the actual TSN to any chunk being sent. This way other messages from 261 other streams may be interleaved with the fragmented message. 263 The sender MUST NOT have more than one ordered fragmented message 264 being produced in any one stream. The sender MUST NOT have more than 265 one un-ordered fragmented message being produced in any one stream. 266 The sender MAY have one ordered and one unordered fragmented message 267 being produced within a single stream. At any time multiple streams 268 MAY be producing an ordered or unordered fragmented message. 270 2.2.3. Receiver Side Considerations 272 Upon reception of an SCTP packet containing a I-DATA chunk if the 273 message needs to be reassembled, then the receiver MUST use the FSN 274 for reassembly of the message and not the TSN. Note that a non- 275 fragmented messages is indicated by the fact that both the 'E' and 276 'B' bits are set. An ordered or unordered fragmented message is thus 277 identified with any message not having both bits set. 279 2.3. Interaction with other SCTP Extensions 281 The usage of the I-DATA chunk might interfere with other SCTP 282 extensions. Future SCTP extensions MUST describe if and how they 283 interfere with the usage of I-DATA chunks. For the SCTP extensions 284 already defined when this document was published, the details are 285 given in the following subsections. 287 2.3.1. SCTP Partial Reliability Extension 289 When the SCTP extension defined in [RFC3758] is used, the lower 16 290 bits of the MID counters for ordered messages MUST be used when 291 filling the SSNs in the FORWARD-TSN chunk. 293 2.3.2. SCTP Stream Reconfiguration Extension 295 When an association resets the SSN using the SCTP extension defined 296 in [RFC6525], the two counters (one for the ordered messages, one for 297 the unordered messages) used for the MID MUST be reset to 0 298 correspondingly. 300 3. Stream Schedulers 302 3.1. Stream Scheduler without User Message Interleaving Support 304 TBD. 306 3.2. Stream Scheduler with User Message Interleaving Support 308 TBD. 310 4. Socket API Considerations 312 This section describes how the socket API defined in [RFC6458] is 313 extended to allow applications to use the extension described in this 314 document. 316 Please note that this section is informational only. 318 4.1. SCTP_ASSOC_CHANGE Notification 320 When an SCTP_ASSOC_CHANGE notification is delivered indicating a 321 sac_state of SCTP_COMM_UP or SCTP_RESTART for an SCTP association 322 where both peers support the I_DATA chunk, 323 SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listen in the sac_info 324 field. 326 4.2. Socket Options 327 +-----------------------------+-------------------------+-----+-----+ 328 | option name | data type | get | set | 329 +-----------------------------+-------------------------+-----+-----+ 330 | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value | X | X | 331 | SCTP_PLUGGABLE_SS | struct sctp_assoc_value | X | X | 332 | SCTP_SS_VALUE | struct | X | X | 333 | | sctp_stream_value | | | 334 +-----------------------------+-------------------------+-----+-----+ 336 4.2.1. Enable or Disable the Support of User Message Interleaving 338 This socket option allows the enabling or disabling of the 339 negotiation of user message interleaving support for future 340 associations. For existing associations it allows to query whether 341 user message interleaving support was negotiated or not on a 342 particular association. 344 User message interleaving is disabled per default. 346 This socket option uses IPPROTO_SCTP as its level and 347 SCTP_INTERLEAVING_SUPPORTED as its name. It can be used with 348 getsockopt() and setsockopt(). The socket option value uses the 349 following structure defined in [RFC6458]: 351 struct sctp_assoc_value { 352 sctp_assoc_t assoc_id; 353 uint32_t assoc_value; 354 }; 356 assoc_id: This parameter is ignored for one-to-one style sockets. 357 For one-to-many style sockets, this parameter indicates upon which 358 association the user is performing an action. The special 359 sctp_assoc_t SCTP_FUTURE_ASSOC can also be used, it is an error to 360 use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. 362 assoc_value: A non-zero value encodes the enabling of user message 363 interleaving whereas a value of 0 encodes the disabling of user 364 message interleaving. 366 sctp_opt_info() needs to be extended to support 367 SCTP_INTERLEAVING_SUPPORTED. 369 An application using user message interleaving should also set the 370 fragment interleave level to 2. This allows the reception from 371 multiple streams simultaneously. Failure to set this option can 372 possibly lead to application deadlock. 374 4.2.2. Get or Set the Stream Scheduler (SCTP_PLUGGABLE_SS) 376 A stream scheduler can be selected with the SCTP_PLUGGABLE_SS option 377 for setsockopt(). The struct sctp_assoc_value is used to specify the 378 association for which the scheduler should be changed and the value 379 of the desired algorithm. 381 The definition of struct sctp_assoc_value is the same as in 382 [RFC6458]: 384 struct sctp_assoc_value { 385 sctp_assoc_t assoc_id; 386 uint32_t assoc_value; 387 }; 389 assoc_id: Holds the identifier for the association of which the 390 scheduler should be changed. The special 391 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 392 is ignored for one-to-one style sockets. 394 assoc_value: This specifies which scheduler is used. The following 395 constants can be used: 397 SCTP_SS_DEFAULT: The default scheduler used by the SCTP 398 implementation. Typical values are SCTP_SS_ROUND_ROBIN or 399 SCTP_SS_FIRST_COME. 401 SCTP_SS_ROUND_ROBIN: This scheduler provides a fair scheduling 402 based on the number of user messages by cycling around non- 403 empty stream queues. 405 SCTP_SS_ROUND_ROBIN_PACKET: This is a round-robin scheduler but 406 only bundles user messages of the same stream in one packet. 407 This minimizes head-of-line blocking when a packet is lost 408 because only a single stream is affected. 410 SCTP_SS_PRIORITY: Scheduling with different priorities is used. 411 Streams having a higher priority will be scheduled first and 412 when multiple streams have the same priority, the default 413 scheduling should be used for them. The priority can be 414 assigned with the sctp_stream_value struct. The higher the 415 assigned value, the lower the priority, that is the default 416 value 0 is the highest priority and therefore the default 417 scheduling will be used if no priorities have been assigned. 419 SCTP_SS_FAIR_BANDWITH: A fair bandwidth distribution between the 420 streams can be activated using this value. This scheduler 421 considers the lengths of the messages of each stream and 422 schedules them in a certain way to maintain an equal bandwidth 423 for all streams. 425 SCTP_SS_WEIGHTED_ROUND_ROBIN: A weighted round robin distribution 426 between the streams can be activated using this value. This 427 scheduler considers the lengths of the messages of each stream 428 and schedules them in a certain way to use the bandwidth 429 according to the given weights. 431 SCTP_SS_FIRST_COME: The simple first-come, first-serve algorithm 432 is selected by using this value. It just passes through the 433 messages in the order in which they have been delivered by the 434 application. No modification of the order is done at all. 436 4.2.3. Get or Set the Stream Scheduler Parameter (SCTP_SS_VALUE) 438 Some schedulers require additional information to be set for single 439 streams as shown in the following table: 441 +----------------------+-----------------+ 442 | name | per stream info | 443 +----------------------+-----------------+ 444 | SCTP_SS_DEFAULT | no | 445 | SCTP_SS_RR | no | 446 | SCTP_SS_RR_INTER | no | 447 | SCTP_SS_RR_PKT | no | 448 | SCTP_SS_RR_PKT_INTER | no | 449 | SCTP_SS_PRIO | yes | 450 | SCTP_SS_PRIO_INTER | yes | 451 | SCTP_SS_FB | no | 452 | SCTP_SS_FB_INTER | no | 453 | SCTP_SS_WRR | yes | 454 | SCTP_SS_WRR_INTER | yes | 455 | SCTP_SS_FCFS | no | 456 +----------------------+-----------------+ 458 This is achieved with the SCTP_SS_VALUE option and the corresponding 459 struct sctp_stream_value. The definition of struct sctp_stream_value 460 is as follows: 462 struct sctp_stream_value { 463 sctp_assoc_t assoc_id; 464 uint16_t stream_id; 465 uint16_t stream_value; 466 }; 468 assoc_id: Holds the identifier for the association of which the 469 scheduler should be changed. The special 470 SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used. This parameter 471 is ignored for one-to-one style sockets. 473 stream_id: Holds the stream id for the stream for which additional 474 information has to be provided. 476 stream_value: The meaning of this field depends on the scheduler 477 specified. It is ignored when the scheduler does not need 478 additional information. 480 5. IANA Considerations 482 [NOTE to RFC-Editor: 484 "RFCXXXX" is to be replaced by the RFC number you assign this 485 document. 487 ] 489 [NOTE to RFC-Editor: 491 The suggested values for the chunk type and the chunk flags are 492 tentative and to be confirmed by IANA. 494 ] 496 This document (RFCXXXX) is the reference for all registrations 497 described in this section. 499 A new chunk type has to be assigned by IANA. IANA should assign this 500 value from the pool of chunks with the upper two bits set to '01'. 501 This requires an additional line in the "Chunk Types" registry for 502 SCTP: 504 +----------+-------------------------+-----------+ 505 | ID Value | Chunk Type | Reference | 506 +----------+-------------------------+-----------+ 507 | 64 | New DATA chunk (I-DATA) | [RFCXXXX] | 508 +----------+-------------------------+-----------+ 510 The registration table as defined in [RFC6096] for the chunk flags of 511 this chunk type is initially given by the following table: 513 +------------------+-----------------+-----------+ 514 | Chunk Flag Value | Chunk Flag Name | Reference | 515 +------------------+-----------------+-----------+ 516 | 0x01 | E bit | [RFCXXXX] | 517 | 0x02 | B bit | [RFCXXXX] | 518 | 0x04 | U bit | [RFCXXXX] | 519 | 0x08 | I bit | [RFCXXXX] | 520 | 0x10 | Unassigned | | 521 | 0x20 | Unassigned | | 522 | 0x40 | Unassigned | | 523 | 0x80 | Unassigned | | 524 +------------------+-----------------+-----------+ 526 6. Security Considerations 528 This document does not add any additional security considerations in 529 addition to the ones given in [RFC4960] and [RFC6458]. 531 7. Acknowledgments 533 The authors wish to thank Christer Holmberg, Karen E. Egede Nielsen, 534 Irene Ruengeler, and Lixia Zhang for her invaluable comments. 536 8. References 538 8.1. Normative References 540 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 541 August 1996. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 547 Conrad, "Stream Control Transmission Protocol (SCTP) 548 Partial Reliability Extension", RFC 3758, May 2004. 550 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 551 4960, September 2007. 553 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 554 Kozuka, "Stream Control Transmission Protocol (SCTP) 555 Dynamic Address Reconfiguration", RFC 5061, September 556 2007. 558 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 559 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 560 January 2011. 562 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 563 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 564 6525, February 2012. 566 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 567 IMMEDIATELY Extension for the Stream Control Transmission 568 Protocol", RFC 7053, November 2013. 570 8.2. Informative References 572 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 573 A., Peterson, J., Sparks, R., Handley, M., and E. 574 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 575 June 2002. 577 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 578 Yasevich, "Sockets API Extensions for the Stream Control 579 Transmission Protocol (SCTP)", RFC 6458, December 2011. 581 Authors' Addresses 583 Randall R. Stewart 584 Netflix, Inc. 585 Chapin, SC 29036 586 US 588 Email: randall@lakerest.net 590 Michael Tuexen 591 Muenster University of Applied Sciences 592 Stegerwaldstrasse 39 593 48565 Steinfurt 594 DE 596 Email: tuexen@fh-muenster.de 598 Salvatore Loreto 599 Ericsson 600 Hirsalantie 11 601 Jorvas 02420 602 FI 604 Email: Salvatore.Loreto@ericsson.com 605 Robin Seggelmann 606 T-Systems International GmbH 607 Fasanenweg 5 608 70771 Leinfelden-Echterdingen 609 DE 611 Email: rfc@robin-seggelmann.com