idnits 2.17.1 draft-proshin-tsvwg-sctp-rtx-bit-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4960, updated by this document, for RFC5378 checks: 2006-02-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 02, 2019) is 1607 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) -- Obsolete informational reference (is this intentional?): RFC 6096 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7053 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Proshin 3 Internet-Draft Ericsson 4 Updates: 4960 (if approved) December 02, 2019 5 Intended status: Standards Track 6 Expires: June 4, 2020 8 Retransmit bit for SCTP DATA, I-DATA and SACK 9 draft-proshin-tsvwg-sctp-rtx-bit-02 11 Abstract 13 This document defines a method which helps an SCTP sender to 14 understand when a received SACK acknowledges the original 15 transmission of a TSN or its retransmission. It is done by 16 specifying a new bit, called Retransmit bit (R-bit), in the header of 17 DATA, I-DATA and SACK chunks. The bit is used when a TSN is 18 retransmitted and returned back in the acknowledgement. This 19 document updates [RFC4960] if approved. 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 https://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 June 4, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Updates in SCTP Chunks Header . . . . . . . . . . . . . . . . 3 58 3.1. R-bit in DATA Chunk Header . . . . . . . . . . . . . . . 3 59 3.2. R-bit in I-DATA Chunk Header . . . . . . . . . . . . . . 4 60 3.3. R-bit in SACK Chunk Header . . . . . . . . . . . . . . . 4 61 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Sender Side Considerations . . . . . . . . . . . . . . . 6 64 4.3. Receiver Side Considerations . . . . . . . . . . . . . . 7 65 4.4. Processing of SACK with and without R-bit . . . . . . . . 7 66 5. R-bit vs Duplicate TSN for Detection of Spurious 67 Retransmission . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Interoperability Considerations . . . . . . . . . . . . . . . 9 69 7. Socket API Considerations . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 11.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 SCTP which is defined in [RFC4960] is a reliable message-oriented 81 protocol. The SCTP sender splits user messages to DATA chunks and 82 sends them to the receiver. The SCTP receiver uses the SACK chunk to 83 acknowledge incoming data. The reliability in SCTP is achieved by 84 the retransmission of DATA chunks which were not acknowledged. 86 If a DATA chunk has been retransmitted at least once, at SACK 87 reception SCTP cannot understand if the SACK was sent in response to 88 the originally sent DATA or retransmitted one. Thus, due to that 89 ambiguity, [RFC4960] prohibits making RTT measurements. Some other 90 SCTP mechanisms such as loss recovery and congestion control are not 91 accurate in that case either. 93 This document describes a simple extension of the DATA and SACK 94 chunks by a new bit, so called Retransmit bit (R-bit). The sender 95 sets the R-bit in the DATA chunk header when it retransmits a DATA 96 and the receiver sets it in the SACK chunk header when a DATA with 97 R-bit is acknowledged. The sender can now distinguish when a SACK 98 acknowledges the originally sent DATA or retransmitted one. The 99 extension requires support by the sender and the receiver. 101 The mechanism described in this document is equally relevant for 102 I-DATA chunk which is introduced in [RFC8260]. 104 2. Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [[RFC8174]] when, and only when, they appear in all 110 capitals, as shown here. 112 3. Updates in SCTP Chunks Header 114 3.1. R-bit in DATA Chunk Header 116 Figure 1 describes the extended DATA chunk header. 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type = 0 | Res |R|I|U|B|E| Length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | TSN | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Stream Identifier | Stream Sequence Number | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Payload Protocol Identifier | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 \ \ 130 / User Data / 131 \ \ 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 1: Extended DATA chunk 136 The only difference between the DATA chunk in Figure 1 and the DATA 137 chunk defined in [RFC4960] is the addition of the R-bit in the flags 138 field of the DATA chunk header. [RFC4960] specified that bit as 139 Reserved and that it should be set to 0 by the sender and ignored by 140 the receiver. 142 3.2. R-bit in I-DATA Chunk Header 144 Figure 2 describes the extended DATA chunk header. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type = 64 | Res |R|I|U|B|E| Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | TSN | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Stream Identifier | Reserved | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Message Identifier | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Payload Protocol Identifier / Fragment Sequence Number | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 \ \ 160 / User Data / 161 \ \ 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 2: Extended I-DATA chunk 166 The only difference between the I-DATA chunk in Figure 2 and the 167 I-DATA chunk defined in [RFC8260] is the addition of the R-bit in the 168 flags field of the I-DATA chunk header. [RFC8260] specified that bit 169 as Reserved and that it should be set to 0 by the sender and ignored 170 by the receiver. 172 3.3. R-bit in SACK Chunk Header 174 Figure 3 describes the extended SACK chunk header. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type = 3 | Reserved |R| Chunk Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Cumulative TSN Ack | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Advertised Receiver Window Credit (a_rwnd) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Gap Ack Block #1 Start | Gap Ack Block #1 End | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 / / 190 \ ... \ 191 / / 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Gap Ack Block #N Start | Gap Ack Block #N End | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Duplicate TSN 1 | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 / / 198 \ ... \ 199 / / 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Duplicate TSN X | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 3: Extended SACK chunk 206 The only difference between the SACK chunk in Figure 3 and the SACK 207 chunk defined in [RFC4960] is the addition of the R-bit in the flags 208 field of the SACK chunk header. [RFC4960] specified that bit as 209 Reserved and that it should be set to 0 by the sender and ignored by 210 the receiver. 212 4. Procedures 214 4.1. Negotiation 216 R-bit MUST NOT be used unless both SCTP peers negotiated its support. 218 The following new optional parameter is added to the INIT and INIT 219 ACK chunks to negotiate R-bit support during association setup: 221 +----------------+-------------------------------------------+ 222 | Parameter Type | Parameter Name | 223 +----------------+-------------------------------------------+ 224 | 0x8100 | Retransmit Bit Supported (RBIT-SUPPORTED) | 225 +----------------+-------------------------------------------+ 227 Table 1 229 The parameter format is the following: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Parameter Type = 0x8100 | Parameter Length = 4 | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 4: Format of RBIT-SUPPORTED 239 Parameter Type: 2 bytes (unsigned integer) 241 This value MUST be set to 0x8100 (33024). 243 Parameter Length: 2 bytes (unsigned integer) 245 This value MUST be set to 4. 247 The RBIT-SUPPORTED parameter MAY be included once in the INIT or INIT 248 ACK chunk if the sender wants to inform its peer that it supports 249 R-bit. 251 The new parameter type is encoded so that it requires the receiver to 252 skip it and continue processing if the parameter is not recognized 253 according to [RFC4960]. 255 4.2. Sender Side Considerations 257 SCTP MUST NOT set the R-bit when it sends a DATA or I-DATA chunk 258 first time. 260 If R-bit support is negotiated as described in Section 4.1, SCTP 261 SHOULD set the R-bit every time it retransmits a DATA or I-DATA 262 chunk. This is regardless of if the chunk is retransmitted on the 263 same path or on an alternative one. 265 Note that it is possible that the same SCTP packet includes DATA or 266 I-DATA chunks with and without the R-bit set in case when SCTP 267 bundles chunks which are marked for retransmission with chunks which 268 are sent first time. This is aligned with [RFC4960] which allows 269 bundling of DATA chunks marked for retransmission with new DATA 270 chunks. 272 IMPLEMENTATION NOTE: According to [RFC4960] new DATA chunks always 273 follow DATA chunks marked for retransmission when bundled in one 274 packet. 276 4.3. Receiver Side Considerations 278 SCTP MUST NOT set the R-bit when it sends a SACK which acknowledges a 279 DATA or I-DATA chunk without the R-bit set. The delay for a SACK 280 without the R-bit set is defined according to [RFC4960]. 282 When SCTP receives a packet with DATA or I-DATA chunk(s) with the 283 R-bit set, it MUST immediately respond with a SACK with the R-bit set 284 acknowledging only DATA or I-DATA chunks where the R-bit was set. If 285 the packet also contains DATA or I-DATA chunk(s) without the R-bit 286 set, SCTP MUST NOT acknowledge them in the same SACK chunk. 288 TBD: SACK with the R-bit bundled with SACK without the R-bit? It may 289 be useful. 291 4.4. Processing of SACK with and without R-bit 293 If a DATA or I-DATA was retransmitted and the corresponding SACK is 294 received, SCTP can distinguish if the SACK acknowledges the original 295 transmission or retransmission by checking the R-bit in the SACK. 296 SCTP mechanisms which can be improved by that information include, 297 but are not limited to, the following: 299 o RTO Calculation: [RFC4960] refers to Karn's algorithm and 300 prohibits SCTP to make RTT measurements using packets that were 301 retransmitted and for which it is ambiguous whether the reply was 302 for the original transmission or retransmission(s). 304 o Path Failure Detection: [RFC4960] specifies that the sender may 305 choose not to clear the path error counter if there is undesirable 306 ambiguity when a DATA is retransmitted on an alternative path. 308 o SCTP-PF Operation in [RFC7829]: additionally to the path error 309 counter case described in the previous bullet [RFC7829] also does 310 not recommend to move a destination address in PF state back to 311 the active state in case of ambiguity. 313 o Detection of spurious retransmissions: using R-bit SCTP can detect 314 spurious retransmissions. Namely, if a DATA was retransmitted and 315 SACK acknowledging it does not include R-bit, it means that the 316 retransmission was spurious. Note that this is valid even if a 317 DATA was retransmitted multiple times which makes this method more 318 effective than detecting of spurious retransmissions based on 319 DSACK. When a spurious retransmission is detected, SCTP 320 implementation may: 322 * Choose to revert the congestion control state. 324 * Choose to adjust RTO settings such as the RTO.Min value to 325 mitigate further spurious retransmissions. 327 * Indicate the SCTP user. 329 o SCTP latency of retransmitted data: If the original DATA is lost, 330 the SCTP receiver will immediately acknowledge the retransmitted 331 DATA. 333 o Calculation of Maximum Ack Delay: SCTP implementations can support 334 a technique for calculating of Maximum Ack Delay in run-time which 335 is impossible to do properly in case of retransmissions. With 336 R-bit SCTP can distinguish if the SACK acknowledges the original 337 transmission or retransmission and can measure the delay even for 338 a retransmitted DATA. 340 o Measurement of packet loss: R-bit can be used for passive loss 341 rate calculation. 343 TBD: dup TSN but without R-bit: SACK loss or reordering: Can be used 344 somehow? 346 Note that this document does not solve the problem when the same DATA 347 or I-DATA chunk is retransmitted multiple times. In that case, when 348 SCTP receives a SACK without the R-bit set, it can ensure that the 349 SACK acknowledges the original transmission but when SCTP receives a 350 SACK with the R-bit set, it cannot distinguish which retransmission 351 is actually acknowledged. Such limitation is not considered as 352 severe because multiple retransmissions of the same DATA or I-DATA is 353 a corner case and, if it happens, SCTP transmission is anyway 354 inefficient. 356 5. R-bit vs Duplicate TSN for Detection of Spurious Retransmission 358 The SACK chunk according to [RFC4960] contains the Duplicate TSN 359 field which is used by the receiver to indicate TSNs received 360 multiple times. This could happen due to spurious retransmissions or 361 if packets were duplicated in the network between endpoints. The 362 Duplicate TSN field in the SACK chunk can also be used by the sender 363 to detect spurious retransmissions in some cases. However, the 364 mechanism based on the Duplicate TSN field would have serious 365 limitations compared to the mechanism based on R-bit: 367 o With R-bit the SCTP sender has an exclusive match between DATA and 368 SACK while in case of the Duplicate TSN it is not guaranteed. 369 Thus, if the original or retranmitted DATA is lost or one of the 370 SACKs is lost or the packets were retransmitted, the SCTP sender 371 cannot rely on the Duplicate TSN field. 373 o Even in those cases where the sender could rely on the Duplicate 374 TSN, it would need to wait the second SACK to detect the spurious 375 retransmission, while with R-bit, the sender can detect it as soon 376 as the first SACK is received. 378 o In case of the Duplicate TSN the SCTP sender needs to keep 379 information about the retransmitted TSN until the second SACK is 380 received or during some time period which impacts memory usage and 381 SCTP performance and complicates implementation. 383 6. Interoperability Considerations 385 This document does not introduce any interoperability issues. 386 Section 4.1 requires both ends to negotiate R-bit support before its 387 usage. [RFC4960] requires the receiver of a DATA or SACK chunk with 388 the R-bit set to ignore the bit if it is not recognized. [RFC8260] 389 requires the receiver of an I-DATA chunk with the R-bit set to ignore 390 the bit if it is not recognized. 392 7. Socket API Considerations 394 This document does not address any changes to the socket API defined 395 in [RFC6458]. 397 8. Acknowledgements 399 TBD 401 9. IANA Considerations 403 [NOTE to RFC-Editor: 405 "RFCXXXX" is to be replaced by the RFC number you assign this 406 document. 408 ] 410 IANA should assign 33024 (0x8100) as a new parameter type to SCTP. 412 Following the chunk flag registration procedure defined in [RFC6096], 413 IANA should register a new bit, the R-bit, for the DATA chunk. The 414 suggested value is 0x10 and the reference should be RFCXXXX. 416 This requires an update of the "DATA Chunk Flags" registry for SCTP: 418 +------------------+-----------------+-----------+ 419 | Chunk Flag Value | Chunk Flag Name | Reference | 420 +------------------+-----------------+-----------+ 421 | 0x01 | E bit | [RFC4960] | 422 | 0x02 | B bit | [RFC4960] | 423 | 0x04 | U bit | [RFC4960] | 424 | 0x08 | I bit | [RFC7053] | 425 | 0x10 | R bit | RFCXXXX | 426 | 0x20 | Unassigned | | 427 | 0x40 | Unassigned | | 428 | 0x80 | Unassigned | | 429 +------------------+-----------------+-----------+ 431 Table 2 433 Following the chunk flag registration procedure defined in [RFC6096], 434 IANA should register a new bit, the R-bit, for the SACK chunk. The 435 suggested value is 0x01 and the reference should be RFCXXXX. 437 This requires an update of the "SACK Chunk Flags" registry for SCTP: 439 +------------------+-----------------+-----------+ 440 | Chunk Flag Value | Chunk Flag Name | Reference | 441 +------------------+-----------------+-----------+ 442 | 0x01 | R bit | RFCXXXX | 443 | 0x02 | Unassigned | | 444 | 0x04 | Unassigned | | 445 | 0x08 | Unassigned | | 446 | 0x10 | Unassigned | | 447 | 0x20 | Unassigned | | 448 | 0x40 | Unassigned | | 449 | 0x80 | Unassigned | | 450 +------------------+-----------------+-----------+ 452 Table 3 454 Following the chunk flag registration procedure defined in [RFC6096], 455 IANA should register a new bit, the R-bit, for the I-DATA chunk. The 456 suggested value is 0x10 and the reference should be RFCXXXX. 458 This requires an update of the "I-DATA Chunk Flags" registry for 459 SCTP: 461 +------------------+-----------------+-----------+ 462 | Chunk Flag Value | Chunk Flag Name | Reference | 463 +------------------+-----------------+-----------+ 464 | 0x01 | E bit | [RFC8260] | 465 | 0x02 | B bit | [RFC8260] | 466 | 0x04 | U bit | [RFC8260] | 467 | 0x08 | I bit | [RFC8260] | 468 | 0x10 | R bit | RFCXXXX | 469 | 0x20 | Unassigned | | 470 | 0x40 | Unassigned | | 471 | 0x80 | Unassigned | | 472 +------------------+-----------------+-----------+ 474 Table 4 476 10. Security Considerations 478 This document does not introduce any additional security 479 considerations in addition to the ones described in [RFC4960] and 480 [RFC8260]. 482 11. References 484 11.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 492 RFC 4960, DOI 10.17487/RFC4960, September 2007, 493 . 495 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 496 "Stream Schedulers and User Message Interleaving for the 497 Stream Control Transmission Protocol", RFC 8260, 498 DOI 10.17487/RFC8260, November 2017, 499 . 501 11.2. Informative References 503 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 504 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 505 DOI 10.17487/RFC6096, January 2011, 506 . 508 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 509 Yasevich, "Sockets API Extensions for the Stream Control 510 Transmission Protocol (SCTP)", RFC 6458, 511 DOI 10.17487/RFC6458, December 2011, 512 . 514 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 515 IMMEDIATELY Extension for the Stream Control Transmission 516 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 517 . 519 [RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. 520 Nielsen, "SCTP-PF: A Quick Failover Algorithm for the 521 Stream Control Transmission Protocol", RFC 7829, 522 DOI 10.17487/RFC7829, April 2016, 523 . 525 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 526 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 527 May 2017, . 529 Author's Address 531 Maksim Proshin 532 Ericsson 533 Kistavaegen 25 534 Stockholm 164 80 535 Sweden 537 Email: mproshin@tieto.mera.ru