idnits 2.17.1 draft-ietf-tsvwg-sctp-strrst-13.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 (December 8, 2011) is 4523 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 1396, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (Obsoleted by RFC 9260) Summary: 2 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 Adara Networks 4 Intended status: Standards Track M. Tuexen 5 Expires: June 10, 2012 Muenster Univ. of Appl. Sciences 6 P. Lei 7 Cisco Systems, Inc. 8 December 8, 2011 10 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration 11 draft-ietf-tsvwg-sctp-strrst-13.txt 13 Abstract 15 Many applications that use SCTP want the ability to "reset" a stream. 16 The intention of resetting a stream is to set the numbering sequence 17 of the stream back to 'zero' with a corresponding notification to the 18 application layer that the reset has been performed. Applications 19 requiring this feature want it so that they can "re-use" streams for 20 different purposes but still utilize the stream sequence number so 21 that the application can track the message flows. Thus, without this 22 feature, a new use of an old stream would result in message numbers 23 greater than expected unless there is a protocol mechanism to "reset 24 the streams back to zero". This document also includes methods for 25 resetting the transport sequence numbers, adding additional streams 26 and resetting all stream sequence numbers. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 10, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. RE-CONFIG Chunk . . . . . . . . . . . . . . . . . . . . . 5 66 4. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Outgoing SSN Reset Request Parameter . . . . . . . . . . . 7 68 4.2. Incoming SSN Reset Request Parameter . . . . . . . . . . . 8 69 4.3. SSN/TSN Reset Request Parameter . . . . . . . . . . . . . 9 70 4.4. Re-configuration Response Parameter . . . . . . . . . . . 9 71 4.5. Add Outgoing Streams Request Parameter . . . . . . . . . . 11 72 4.6. Add Incoming Streams Request Parameter . . . . . . . . . . 12 73 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.1. Sender Side Procedures . . . . . . . . . . . . . . . . . . 13 75 5.1.1. Sender Side Procedures for the RE-CONFIG Chunk . . . . 13 76 5.1.2. Sender Side Procedures for the Outgoing SSN Reset 77 Request Parameter . . . . . . . . . . . . . . . . . . 14 78 5.1.3. Sender Side Procedures for the Incoming SSN Reset 79 Request Parameter . . . . . . . . . . . . . . . . . . 15 80 5.1.4. Sender Side Procedures for the SSN/TSN Reset 81 Request Parameter . . . . . . . . . . . . . . . . . . 16 82 5.1.5. Sender Side Procedures for the Re-configuration 83 Response Parameter . . . . . . . . . . . . . . . . . . 16 84 5.1.6. Sender Side Procedures for the Add Outgoing 85 Streams Request Parameter . . . . . . . . . . . . . . 17 86 5.1.7. Sender Side Procedures for the Add Incoming 87 Streams Request Parameter . . . . . . . . . . . . . . 17 88 5.2. Receiver Side Procedures . . . . . . . . . . . . . . . . . 18 89 5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk . . . 18 90 5.2.2. Receiver Side Procedures for the Outgoing SSN 91 Reset Request Parameter . . . . . . . . . . . . . . . 18 92 5.2.3. Receiver Side Procedures for the Incoming SSN 93 Reset Request Parameter . . . . . . . . . . . . . . . 19 94 5.2.4. Receiver Side Procedures for the SSN/TSN Reset 95 Request Parameter . . . . . . . . . . . . . . . . . . 20 96 5.2.5. Receiver Side Procedures for the Add Outgoing 97 Streams Request Parameter . . . . . . . . . . . . . . 21 98 5.2.6. Receiver Side Procedures for the Add Incoming 99 Streams Request Parameter . . . . . . . . . . . . . . 21 100 5.2.7. Receiver Side Procedures for the Re-configuration 101 Response Parameter . . . . . . . . . . . . . . . . . . 21 102 6. Socket API Considerations . . . . . . . . . . . . . . . . . . 22 103 6.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 6.1.1. Stream Reset Event . . . . . . . . . . . . . . . . . . 23 105 6.1.2. Association Reset Event . . . . . . . . . . . . . . . 24 106 6.1.3. Stream Change Event . . . . . . . . . . . . . . . . . 25 107 6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . 26 108 6.3. Socket Options . . . . . . . . . . . . . . . . . . . . . . 26 109 6.3.1. Enable/Disable Stream Reset 110 (SCTP_ENABLE_STREAM_RESET) . . . . . . . . . . . . . . 27 111 6.3.2. Reset Incoming and/or Outgoing Streams 112 (SCTP_RESET_STREAMS) . . . . . . . . . . . . . . . . . 28 113 6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) . . . . . . . . . . . 28 114 6.3.4. Add Incoming and/or Outgoing Streams 115 (SCTP_ADD_STREAMS) . . . . . . . . . . . . . . . . . . 29 116 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 118 8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 30 119 8.2. Six New Chunk Parameter Types . . . . . . . . . . . . . . 30 120 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 122 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 123 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 124 Appendix A. Examples of the Re-configuration procedures . . . . . 32 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 127 1. Introduction 129 Many applications that use SCTP as defined in [RFC4960] want the 130 ability to "reset" a stream. The intention of resetting a stream is 131 to set the stream sequence numbers (SSNs) of the stream back to 132 'zero' with a corresponding notification to the application layer 133 that the reset has been performed. Applications requiring this 134 feature want to "re-use" streams for different purposes but still 135 utilize the stream sequence number so that the application can track 136 the message flows. Thus, without this feature, a new use of an old 137 stream would result in message numbers greater than expected unless 138 there is a protocol mechanism to "reset the streams back to zero". 139 This document also includes methods for resetting the transport 140 sequence numbers (TSNs), adding additional streams and resetting all 141 stream sequence numbers. 143 The socket API for SCTP defined in [I-D.ietf-tsvwg-sctpsocket] 144 exposes the sequence numbers used by SCTP for user message transfer. 145 Therefore, resetting them can be used by application writers. Please 146 note that the corresponding sequence number for TCP is not exposed 147 via the socket API for TCP. 149 2. Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. New Chunk Type 157 This section defines the new chunk type that will be used to re- 158 configure streams. Table 1 illustrates the new chunk type. 160 +------------+------------------------------------+ 161 | Chunk Type | Chunk Name | 162 +------------+------------------------------------+ 163 | 0x82 | Re-configuration Chunk (RE-CONFIG) | 164 +------------+------------------------------------+ 166 Table 1 168 It should be noted that the format of the RE-CONFIG chunk requires 169 the receiver to ignore the chunk if it is not understood and continue 170 processing all chunks that follow. This is accomplished by the use 171 of the upper bits of the chunk type as described in section 3.2 of 172 [RFC4960]. 174 All transported integer numbers are in "network byte order" a.k.a., 175 Big Endian. 177 3.1. RE-CONFIG Chunk 179 This document adds one new chunk type to SCTP. The chunk has the 180 following format: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type = 0x82 | Chunk Flags | Chunk Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 \ \ 188 / Re-configuration Parameter / 189 \ \ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 \ \ 192 / Re-configuration Parameter (optional) / 193 \ \ 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Chunk Type: 1 byte (unsigned integer) 197 This field holds the IANA defined chunk type for the RE-CONFIG 198 chunk. The suggested value of this field for IANA is 0x82. 200 Chunk Flags: 1 byte (unsigned integer) 201 This field is set to 0 by the sender and ignored by the receiver. 203 Chunk Length: 2 bytes (unsigned integer) 204 This field holds the length of the chunk in bytes, including the 205 Chunk Type, Chunk Flags and Chunk Length. 207 Re-configuration Parameter 208 This field holds a Re-configuration Request Parameter or a Re- 209 configuration Response Parameter. 211 Note that each RE-CONFIG chunk holds at least one parameter and at 212 most two parameters. Only the following combinations are allowed: 214 1. Outgoing SSN Reset Request Parameter. 216 2. Incoming SSN Reset Request Parameter. 218 3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request 219 Parameter. 221 4. SSN/TSN Reset Request Parameter. 223 5. Add Outgoing Streams Request Parameter. 225 6. Add Incoming Streams Request Parameter. 227 7. Add Outgoing Streams Request Parameter, Add Incoming Streams 228 Request Parameter. 230 8. Re-configuration Response Parameter. 232 9. Re-configuration Response Parameter, Outgoing SSN Reset Request 233 Parameter. 235 10. Re-configuration Response Parameter, Re-configuration Response 236 Parameter. 238 If a sender transmits an unsupported combination, the receiver SHOULD 239 send an ERROR chunk with a Protocol Violation cause as defined in 240 section 3.3.10.13 of [RFC4960]). 242 4. New Parameter Types 244 This section defines the new parameter types that will be used in the 245 RE-CONFIG chunk. Table 2 illustrates the new parameter types. 247 +----------------+----------------------------------------+ 248 | Parameter Type | Parameter Name | 249 +----------------+----------------------------------------+ 250 | 0x000d | Outgoing SSN Reset Request Parameter | 251 | 0x000e | Incoming SSN Reset Request Parameter | 252 | 0x000f | SSN/TSN Reset Request Parameter | 253 | 0x0010 | Re-configuration Response Parameter | 254 | 0x0011 | Add Outgoing Streams Request Parameter | 255 | 0x0012 | Add Incoming Streams Request Parameter | 256 +----------------+----------------------------------------+ 258 Table 2 260 It should be noted that the parameter format requires the receiver to 261 stop processing the parameter and not to process any further 262 parameters within the chunk if the parameter type is not recognized. 263 This is accomplished by the use of the upper bits of the parameter 264 type as described in section 3.2.1 of [RFC4960]. 266 All transported integer numbers are in "network byte order" a.k.a., 267 Big Endian. 269 4.1. Outgoing SSN Reset Request Parameter 271 This parameter is used by the sender to request the reset of some or 272 all outgoing streams. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Parameter Type = 0x000d | Parameter Length = 16 + 2 * N | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Re-configuration Request Sequence Number | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Re-configuration Response Sequence Number | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Sender's Last Assigned TSN | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Stream Number 1 (optional) | Stream Number 2 (optional) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 / ...... / 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Stream Number N-1 (optional) | Stream Number N (optional) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Parameter Type: 2 bytes (unsigned integer) 293 This field holds the IANA defined parameter type for the Outgoing 294 SSN Reset Request Parameter. The suggested value of this field 295 for IANA is 0x000d. 297 Parameter Length: 2 bytes (unsigned integer) 298 This field holds the length in bytes of the parameter; the value 299 MUST be 16 + 2 * N, where N is the number of stream numbers 300 listed. 302 Re-configuration Request Sequence Number: 4 bytes (unsigned integer) 303 This field is used to identify the request. It is a monotonically 304 increasing number that is initialized to the same value as the 305 Initial TSN number. It is increased by 1 whenever sending a new 306 Re-configuration Request parameter. 308 Re-configuration Response Sequence Number: 4 bytes (unsigned 309 integer) 310 When this Outgoing SSN Reset Request Parameter is sent in response 311 to an Incoming SSN Reset Request Parameter this parameter is also 312 an implicit response to the incoming request. Then this field 313 holds the Re-configuration Request Sequence Number of the incoming 314 request. In other cases it holds the next expected Re- 315 configuration Request Sequence Number minus 1. 317 Sender's last assigned TSN: 4 bytes (unsigned integer) 318 This value holds the next TSN minus 1, in other words the last TSN 319 that this sender assigned. 321 Stream Number 1..N: 2 bytes (unsigned integer) 322 This optional field, if included, is used to indicate specific 323 streams that are to be reset. If no streams are listed, then all 324 streams are to be reset. 326 This parameter can appear in a RE-CONFIG chunk. This parameter MUST 327 NOT appear in any other chunk type. 329 4.2. Incoming SSN Reset Request Parameter 331 This parameter is used by the sender to request that the peer resets 332 some or all of its outgoing streams. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Parameter Type = 0x000e | Parameter Length = 8 + 2 * N | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Re-configuration Request Sequence Number | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Stream Number 1 (optional) | Stream Number 2 (optional) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 / ...... / 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Stream Number N-1 (optional) | Stream Number N (optional) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Parameter Type: 2 bytes (unsigned integer) 349 This field holds the IANA defined parameter type for the Incoming 350 SSN Reset Request Parameter. The suggested value of this field 351 for IANA is 0x000e. 353 Parameter Length: 2 bytes (unsigned integer) 354 This field holds the length in bytes of the parameter; the value 355 MUST be 8 + 2 * N. 357 Re-configuration Request Sequence Number: 4 bytes (unsigned integer) 358 This field is used to identify the request. It is a monotonically 359 increasing number that is initialized to the same value as the 360 Initial TSN number. It is increased by 1 whenever sending a new 361 Re-configuration Request parameter. 363 Stream Number 1..N: 2 bytes (unsigned integer) 364 This optional field, if included, is used to indicate specific 365 streams that are to be reset. If no streams are listed, then all 366 streams are to be reset. 368 This parameter can appear in a RE-CONFIG chunk. This parameter MUST 369 NOT appear in any other chunk type. 371 4.3. SSN/TSN Reset Request Parameter 373 This parameter is used by the sender to request a reset of the TSN 374 and SSN numbering of all incoming and outgoing streams. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Parameter Type = 0x000f | Parameter Length = 8 | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Re-configuration Request Sequence Number | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Parameter Type: 2 bytes (unsigned integer) 385 This field holds the IANA defined parameter type for the SSN/TSN 386 Reset Request Parameter. The suggested value of this field for 387 IANA is 0x000f. 389 Parameter Length: 2 bytes (unsigned integer) 390 This field holds the length in bytes of the parameter; the value 391 MUST be 8. 393 Re-configuration Request Sequence Number: 4 bytes (unsigned integer) 394 This field is used to identify the request. It is a monotonically 395 increasing number that is initialized to the same value as the 396 Initial TSN number. It is increased by 1 whenever sending a new 397 Re-configuration Request parameter. 399 This parameter can appear in a RE-CONFIG chunk. This parameter MUST 400 NOT appear in any other chunk type. 402 4.4. Re-configuration Response Parameter 404 This parameter is used by the receiver of a Re-configuration Request 405 parameter to respond to the request. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Parameter Type = 0x0010 | Parameter Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Re-configuration Response Sequence Number | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Result | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Sender's next TSN (optional) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Receiver's next TSN (optional) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Parameter Type: 2 bytes (unsigned integer) 422 This field holds the IANA defined parameter type for Re- 423 configuration Response Parameter. The suggested value of this 424 field for IANA is 0x0010. 426 Parameter Type Length: 2 bytes (unsigned integer) 427 This field holds the length in bytes of the parameter; the value 428 MUST be 12 if the optional fields are not present and 20 429 otherwise. 431 Re-configuration Response Sequence Number: 4 bytes (unsigned 432 integer) 433 This value is copied from the request parameter and is used by the 434 receiver of the Re-configuration Response Parameter to tie the 435 response to the request. 437 Result: 4 bytes (unsigned integer) 438 This value describes the result of the processing of the request. 439 It is encoded as given by the following table 441 +--------+-------------------------------------+ 442 | Result | Description | 443 +--------+-------------------------------------+ 444 | 0 | Success - Nothing to do | 445 | 1 | Success - Performed | 446 | 2 | Denied | 447 | 3 | Error - Wrong SSN | 448 | 4 | Error - Request already in progress | 449 | 5 | Error - Bad Sequence Number | 450 | 6 | In progress | 451 +--------+-------------------------------------+ 453 Table 3 455 Sender's next TSN: 4 bytes (unsigned integer) 456 This field holds the TSN the sender of the response will use to 457 send the next DATA chunk. The field is only applicable in 458 responses to SSN/TSN reset requests. 460 Receiver's next TSN: 4 bytes (unsigned integer) 461 This field holds the TSN the receiver of the response must use to 462 send the next DATA chunk. The field is only applicable in 463 responses to SSN/TSN reset requests. 465 Either both optional fields (Sender's next TSN and Receiver's next 466 TSN) MUST be present or none. 468 This parameter can appear in a RE-CONFIG chunk. This parameter MUST 469 NOT appear in any other chunk type. 471 4.5. Add Outgoing Streams Request Parameter 473 This parameter is used by the sender to request that an additional 474 number of outgoing streams (i.e. the receiver's incoming streams) be 475 added to the association. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Parameter Type = 0x0011 | Parameter Length = 12 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Re-configuration Request Sequence Number | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Number of new streams | Reserved | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Parameter Type: 2 bytes (unsigned integer) 488 This field holds the IANA defined parameter type for the the Add 489 Outgoing Streams Request Parameter. The suggested value of this 490 field for IANA is 0x0011. 492 Parameter Length: 2 bytes (unsigned integer) 493 This field holds the length in bytes of the parameter; the value 494 MUST be 12. 496 Re-configuration Request Sequence Number: 4 bytes (unsigned integer) 497 This field is used to identify the request. It is a monotonically 498 increasing number that is initialized to the same value as the 499 Initial TSN number. It is increased by 1 whenever sending a new 500 Re-configuration Request parameter. 502 Number of new streams: 2 bytes (unsigned integer) 503 This value holds the number of additional outgoing streams the 504 sender requests to be added to the association. Streams are added 505 in order and are consecutive, e.g. if an association has four 506 outgoing streams (0-3) and a requested is made to add 3 streams 507 then the new streams will be 4, 5 and 6. 509 Reserved: 2 bytes (unsigned integer) 510 This field is reserved. It SHOULD be set to 0 by the sender and 511 ignored by the receiver. 513 This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST 514 NOT appear in any other chunk type. 516 4.6. Add Incoming Streams Request Parameter 518 This parameter is used by the sender to request that the peer adds an 519 additional number of outgoing streams (i.e. the sender's incoming 520 streams) to the association. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Parameter Type = 0x0012 | Parameter Length = 12 | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Re-configuration Request Sequence Number | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Number of new streams | Reserved | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Parameter Type: 2 bytes (unsigned integer) 533 This field holds the IANA defined parameter type for the the Add 534 Incoming Streams Request Parameter. The suggested value of this 535 field for IANA is 0x0012. 537 Parameter Length: 2 bytes (unsigned integer) 538 This field holds the length in bytes of the parameter; the value 539 MUST be 12. 541 Re-configuration Request Sequence Number: 4 bytes (unsigned integer) 542 This field is used to identify the request. It is a monotonically 543 increasing number that is initialized to the same value as the 544 Initial TSN number. It is increased by 1 whenever sending a new 545 Re-configuration Request parameter. 547 Number of new streams: 2 bytes (unsigned integer) 548 This value holds the number of additional incoming streams the 549 sender requests to be added to the association. Streams are added 550 in order and are consecutive, e.g. if an association has four 551 outgoing streams (0-3) and a requested is made to add 3 streams 552 then the new streams will be 4, 5 and 6. 554 Reserved: 2 bytes (unsigned integer) 555 This field is reserved. It SHOULD be set to 0 by the sender and 556 ignored by the receiver. 558 This parameter MAY appear in a RE-CONFIG chunk. This parameter MUST 559 NOT appear in any other chunk type. 561 5. Procedures 563 This section defines the procedures used by both the sender and 564 receiver of a RE-CONFIG chunk. Various examples of re-configuration 565 scenarios are given in Appendix A. 567 One important thing to remember about SCTP streams is that they are 568 uni-directional. The endpoint for which a stream is an outgoing 569 stream is called the outgoing side, the endpoint for which the stream 570 is an incoming stream is called the incoming side. The procedures 571 outlined in this section are designed so that the incoming side will 572 always reset their stream sequence number first before the outgoing 573 side which means the re-configuration request must always originate 574 from the outgoing side. These two issues have important 575 ramifications upon how an SCTP endpoint might request that its 576 incoming streams be reset. In effect it must ask the peer to start 577 an outgoing reset procedure and once that request is acknowledged let 578 the peer actually control the reset operation. 580 5.1. Sender Side Procedures 582 This section describes the procedures related to the sending of RE- 583 CONFIG chunks. A RE-CONFIG chunk is composed of one or two Type 584 Length Value (TLV) parameters. 586 5.1.1. Sender Side Procedures for the RE-CONFIG Chunk 588 This SCTP extension uses the Supported Extensions Parameter defined 589 in [RFC5061] for negotiating the support for it. 591 An SCTP endpoint supporting this extension MUST include the chunk 592 type of the RE-CONFIG chunk in the Supported Extensions Parameter in 593 either the INIT or INIT-ACK. Before sending a RE-CONFIG chunk the 594 sender MUST ensure that the peer advertised support for the re- 595 configuration extension. If the chunk type of the RE-CONFIG chunk 596 does not appear in the supported extensions list of chunks, then the 597 sender MUST NOT send any re-configuration request to the peer, and 598 any request by the application for such service SHOULD be responded 599 to with an appropriate error indicating the peer SCTP stack does not 600 support the re-configuration extension. 602 At any given time there MUST NOT be more than one request be in 603 flight. So if the Re-configuration Timer is running and the the RE- 604 CONFIG chunk contains at least one request parameter the chunk MUST 605 be buffered. 607 After packaging the RE-CONFIG chunk and sending it to the peer the 608 sender MUST start the Re-configuration Timer if the RE-CONFIG chunk 609 contains at least one request parameter. If it contains no request 610 parameters, the Re-configuration Timer MUST NOT be started. This 611 timer MUST use the same value as SCTP's Data transmission timer (i.e. 612 the RTO timer) and MUST use exponential backoff doubling the value at 613 every expiration. If the timer expires, besides doubling the value, 614 the sender MUST retransmit the RE-CONFIG chunk, increment the 615 appropriate error counts (both for the association and the 616 destination), and perform threshold management possibly destroying 617 the association if SCTP retransmission thresholds are exceeded. 619 5.1.2. Sender Side Procedures for the Outgoing SSN Reset Request 620 Parameter 622 When an SCTP sender wants to reset the SSNs of some or all outgoing 623 streams it can send an Outgoing SSN Reset Request Parameter provided 624 that the Re-configuration Timer is not running. The following steps 625 must be followed: 627 A1: The sender MUST stop assigning new SSNs to new user data 628 provided by the upper layer for the affected streams and queue 629 it. This is because it is not known whether the receiver of the 630 request will accept or deny it and moreover, a lost request 631 might cause an out-of-sequence error in a stream that the 632 receiver is not yet prepared to handle. 634 A2: The sender MUST assign the next re-configuration request 635 sequence number and MUST put it into the Re-configuration 636 Request Sequence Number field of the Outgoing SSN Reset Request 637 Parameter. The next re-configuration request sequence number 638 MUST then be incremented by 1. 640 A3: The Sender's Last Assigned TSN MUST be set to the next TSN the 641 sender assigns minus 1. 643 A4: If this Outgoing SSN Reset Request Parameter is sent in response 644 to an Incoming SSN Reset Request Parameter the Stream Numbers 645 MUST be copied from the Incoming SSN Reset Request Parameter to 646 the Outgoing SSN Reset Request Parameter. The Re-configuration 647 Response Sequence Number of the Outgoing SSN Reset Request 648 Parameter MUST be the Re-configuration Request Sequence Number 649 of the Incoming SSN Reset Request Parameter. If this Outgoing 650 SSN Reset Request Parameter is sent at the request of the upper 651 layer and the sender requests all outgoing streams to be reset 652 Stream Numbers SHOULD NOT be put into the Outgoing SSN Reset 653 Request Parameter. If the sender requests only some outgoing 654 streams to be reset these Stream Numbers MUST be placed in the 655 Outgoing SSN Reset Request Parameter. Re-configuration Response 656 Sequence Number is the next expected Re-configuration Request 657 Sequence Number of the peer minus 1. 659 A5: The Outgoing SSN Reset Request Parameter MUST be put into a RE- 660 CONFIG Chunk. The Outgoing SSN Reset Request Parameter MAY be 661 put together with either an Incoming SSN Reset Request Parameter 662 or an Re-configuration Response Parameter but not both. It MUST 663 NOT be put together with any other parameter as described in 664 Section 3.1. 666 A6: The RE-CONFIG chunk MUST be sent following the rules given in 667 Section 5.1.1. 669 5.1.3. Sender Side Procedures for the Incoming SSN Reset Request 670 Parameter 672 When an SCTP sender wants to reset the SSNs of some or all incoming 673 streams it can send an Incoming SSN Reset Request Parameter provided 674 that the Re-configuration Timer is not running. The following steps 675 must be followed: 677 B1: The sender MUST assign the next re-configuration request 678 sequence number and MUST put it into the Re-configuration 679 Request Sequence Number field of the Incoming SSN Reset Request 680 Parameter. After assigning it the next re-configuration request 681 sequence number MUST be incremented by 1. 683 B2: If the sender wants all incoming streams to be reset Stream 684 Numbers SHOULD NOT be put into the Incoming SSN Reset Request 685 Parameter. If the sender wants only some incoming streams to be 686 reset these Stream Numbers MUST be filled in the Incoming SSN 687 Reset Request Parameter. 689 B3: The Incoming SSN Reset Request Parameter MUST be put into a RE- 690 CONFIG Chunk. It MAY be put together with an Outgoing SSN Reset 691 Request Parameter but MUST NOT be put together with any other 692 parameter. 694 B4: The RE-CONFIG chunk MUST be sent following the rules given in 695 Section 5.1.1. 697 When sending an Incoming SSN Reset Request there is a potential that 698 the peer has just reset or is in the process of resetting the same 699 streams via an Outgoing SSN Reset Request. This collision scenario 700 is discussed in Section 5.2.3. 702 5.1.4. Sender Side Procedures for the SSN/TSN Reset Request Parameter 704 When an SCTP sender wants to reset the SSNs and TSNs it can send an 705 SSN/TSN Reset Request Parameter provided that the Re-configuration 706 Timer is not running. The following steps must be followed: 708 C1: The sender MUST assign the next re-configuration request 709 sequence number and put it into the Re-configuration Request 710 Sequence Number field of the SSN/TSN Reset Request Parameter. 711 After assigning it the next re-configuration request sequence 712 number MUST be incremented by 1. 714 C2: The sender has either no outstanding TSNs or considers all 715 outstanding TSNs abandoned. The sender MUST queue any user data 716 suspending any new transmissions and TSN assignment until the 717 reset procedure is finished by the peer either acknowledging or 718 denying the request. 720 C3: The SSN/TSN Reset Request Parameter MUST be put into a RE-CONFIG 721 chunk. There MUST NOT be any other parameter in this chunk. 723 C4: The RE-CONFIG chunk MUST be sent following the rules given in 724 Section 5.1.1. 726 Only one SSN/TSN Reset Request SHOULD be sent within 30 seconds, 727 which is considered a maximum segment lifetime, the IP MSL. 729 5.1.5. Sender Side Procedures for the Re-configuration Response 730 Parameter 732 When an implementation receives a reset request parameter it must 733 respond with a Re-configuration Response Parameter in the following 734 manner: 736 D1: The Re-configuration Request Sequence number of the incoming 737 request MUST be copied to the Re-configuration Response Sequence 738 Number field of the Re-configuration Response Parameter. 740 D2: The result of the processing of the incoming request according 741 to Table 3 MUST be placed in the Result field of the Re- 742 configuration Response Parameter. 744 D3: If the incoming request is an SSN/TSN reset request, the 745 Sender's next TSN field MUST be filled with the next TSN the 746 sender of this Re-configuration Response Parameter will assign. 747 For other requests the Sender's next TSN field, which is 748 optional, MUST NOT be used. 750 D4: If the incoming request is an SSN/TSN reset request, the 751 Receiver's next TSN field MUST be filled with a TSN such that 752 the sender of the Re-configuration Response Parameter can be 753 sure it can discard received DATA chunks with smaller TSNs. The 754 value SHOULD be the smallest TSN not acknowledged by the 755 receiver of the request plus 2^31. For other requests the 756 Receiver's next TSN field, which is optional, MUST NOT be used. 758 5.1.6. Sender Side Procedures for the Add Outgoing Streams Request 759 Parameter 761 When an SCTP sender wants to increase the number of outbound streams 762 to which it is able to send, it may add an Add Outgoing Streams 763 Request parameter to the RE-CONFIG chunk. Upon sending the request 764 the sender MUST await a positive acknowledgment (Success) before 765 using any additional stream added by this request. Note that new 766 streams are added adjacent to the previous streams with no gaps. 767 This means that if a request is made to add 2 streams to an 768 association that has already 5 (0-4) then the new streams, upon 769 successful completion, are streams 5 and 6. A new stream MUST use 770 the stream sequence number 0 for its first ordered message. 772 5.1.7. Sender Side Procedures for the Add Incoming Streams Request 773 Parameter 775 When an SCTP sender wants to increase the number of inbound streams 776 to which the peer is able to send, it may add an Add Incoming Streams 777 Request parameter to the RE-CONFIG chunk. Note that new streams are 778 added adjacent to the previous streams with no gaps. This means that 779 if a request is made to add 2 streams to an association that has 780 already 5 (0-4) then the new streams, upon successful completion, are 781 streams 5 and 6. A new stream MUST use the stream sequence number 0 782 for its first ordered message. 784 5.2. Receiver Side Procedures 786 5.2.1. Receiver Side Procedures for the RE-CONFIG Chunk 788 Upon reception of a RE-CONFIG chunk each parameter within it SHOULD 789 be processed. If multiple parameters have to be returned, they MUST 790 be put into one RE_CONFIG chunk. If the received RE-CONFIG chunk 791 contains at least one request parameter, a SACK chunk SHOULD be sent 792 back and MAY be bundled with the RE-CONFIG chunk. If the received 793 RE-CONFIG chunk contains at least one request and based on the 794 analysis of the Re-configuration Request Sequence Numbers this is the 795 last received RE-CONFIG chunk (i.e. a retransmission), the same RE- 796 CONFIG chunk MUST to be sent back in response as was earlier. 798 The decision to deny a re-configuration request is an administrative 799 decision and may be user configurable even after the association has 800 formed. If for whatever reason the endpoint does not wish to process 801 a received request parameter it MUST send a corresponding response 802 parameter as described in Section 5.1.5 with an appropriate Result 803 field. 805 Implementation Note: A SACK is recommended to be bundled with any re- 806 configuration response so that any retransmission processing that 807 needs to occur can be expedited. A SACK chunk is not required for 808 this feature to work, but it will in effect help minimize the delay 809 in completing a re-configuration operation in the face of any data 810 loss. 812 5.2.2. Receiver Side Procedures for the Outgoing SSN Reset Request 813 Parameter 815 In the case that the endpoint is willing to perform a stream reset 816 the following steps must be followed: 818 E1: If the Re-configuration Timer is running for the Re- 819 configuration Request Sequence Number indicated in the Re- 820 configuration Response Sequence Number field, the Re- 821 configuration Request Sequence Number MUST be marked as 822 acknowledged. If all Re-configuration Request Sequence Numbers 823 the Re-configuration Timer is running for are acknowledged, the 824 Re-configuration Timer MUST be stopped. 826 E2: If the Sender's Last Assigned TSN number is greater than the 827 cumulative acknowledgment point, then the endpoint MUST enter 828 "deferred reset processing". In this mode, any data arriving 829 with a TSN number larger than the 'senders last assigned TSN' 830 for the affected stream(s) MUST be queued locally and held until 831 the Cumulative Acknowledgment point reaches the 'senders last 832 assigned TSN number'. When the Cumulative Acknowledgment point 833 reaches the last assigned TSN number then proceed to the next 834 step. If the endpoint enters "deferred reset processing", it 835 MUST put a Re-configuration Response Parameter into a RE-CONFIG 836 chunk indicating 'In progress' and MUST send the RE-CONFIG 837 chunk. 839 E3: If no Stream Numbers are listed in the parameter, then all 840 incoming streams MUST be reset to 0 as the next expected stream 841 sequence number. If specific Stream Numbers are listed, then 842 only these specific streams MUST be reset to 0 and all other 843 non-listed stream sequence numbers remain unchanged. 845 E4: Any queued TSN's (queued at step E2) MUST now be released and 846 processed normally. 848 E5: A Re-configuration Response Parameter MUST be put into a RE- 849 CONFIG chunk indicating successful processing. 851 E6: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG 852 chunk is processed completely. 854 5.2.3. Receiver Side Procedures for the Incoming SSN Reset Request 855 Parameter 857 In the case that the endpoint is willing to perform a stream reset 858 the following steps must be followed: 860 F1: An Outgoing SSN Reset Request Parameter MUST be put into an RE- 861 CONFIG chunk according to Section 5.1.2. 863 F2: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG 864 chunk is processed completely. 866 When a peer endpoint requests an Incoming SSN Reset Request it is 867 possible that the local endpoint has just sent an Outgoing SSN Reset 868 Request on the same association and has not yet received a response. 869 In such a case the local endpoint MUST do the following: 871 o If the just sent Outgoing SSN Reset Request Parameter completely 872 overlaps the received Incoming SSN Reset Request Parameter respond 873 to the peer with an acknowledgment indicating that there was 874 'Nothing to do'. 876 o Otherwise process the Incoming SSN Reset Request Parameter 877 normally responding to the peer with an acknowledgment. Note that 878 this case includes the situation where some of the streams 879 requested overlap with the just sent Outgoing SSN Reset Request. 881 Even in such a situation the Incoming SSN Reset MUST be processed 882 normally even though this means that (if the endpoint elects to do 883 the stream reset) streams that are already at SSN 0, will be reset 884 a subsequent time. 886 It is also possible that the Incoming request will arrive after the 887 Outgoing SSN Reset Request just completed. In such a case all of the 888 streams being requested will be already set to 0. If so, the local 889 endpoint SHOULD send back a Re-configuration Response with the 890 success code "Nothing to do". 892 Note that in either race condition the local endpoint could 893 optionally also perform the reset. This would result in streams that 894 are already at sequence 0 being reset again to 0 which would cause no 895 harm to the application but will add an extra message to the network. 897 5.2.4. Receiver Side Procedures for the SSN/TSN Reset Request Parameter 899 In the case that the endpoint is willing to perform an SSN/TSN reset 900 the following steps must be followed: 902 G1: Compute an appropriate value for the Receiver's next TSN, the 903 TSN the peer should use to send the next DATA chunk. The value 904 SHOULD be the smallest TSN not acknowledged by the receiver of 905 the request plus 2^31. 907 G2: Compute an appropriate value for the local endpoint's next TSN, 908 i.e. the receiver of the SSN/TSN reset chunk next TSN to be 909 assigned. The value SHOULD be the highest TSN sent by the 910 receiver of the request plus 1. 912 G3: The same processing as if a SACK chunk with no gap report and a 913 cumulative TSN ACK of Sender's next TSN minus 1 was received 914 MUST be performed. 916 G4: The same processing as if a FWD-TSN chunk as defined in 917 [RFC3758] with all streams affected and a new cumulative TSN ACK 918 of Receiver's next TSN minus 1 was received MUST be performed. 920 G5: The next expected and outgoing stream sequence numbers MUST be 921 reset to 0 for all incoming and outgoing streams. 923 G6: A Re-configuration Response Parameter MUST be put into a RE- 924 CONFIG chunk indicating successful processing. 926 G7: The RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG 927 chunk is processed completely. 929 5.2.5. Receiver Side Procedures for the Add Outgoing Streams Request 930 Parameter 932 When an SCTP endpoint receives a re-configuration request adding 933 additional streams, it MUST send a response parameter either 934 acknowledging or denying the request. If the response is successful 935 the receiver MUST add the requested number of inbound streams to the 936 association, initializing the next expected stream sequence number to 937 be 0. The SCTP endpoint SHOULD deny the request if the number of 938 streams exceeds a limit which should be configurable by the 939 application. 941 5.2.6. Receiver Side Procedures for the Add Incoming Streams Request 942 Parameter 944 When an SCTP endpoint receives a re-configuration request adding 945 additional incoming streams, it MUST either send a response parameter 946 denying the request or sending a corresponding Add Outgoing Streams 947 Request Parameter following the rules given in Section 5.1.6. The 948 SCTP endpoint SHOULD deny the request if the number of streams 949 exceeds a limit which should be configurable by the application. 951 5.2.7. Receiver Side Procedures for the Re-configuration Response 952 Parameter 954 On receipt of a Re-configuration Response Parameter the following 955 must be performed: 957 H1: If the Re-confguration Timer is running for the Re-configuration 958 Request Sequence Number indicated in the Re-configuration 959 Response Sequence Number field, the Re-configuration Request 960 Sequence Number MUST be marked as acknowledged. If all Re- 961 configuration Request Sequence Numbers the Re-configuration 962 Timer is running for are acknowledged, the Re-configuration 963 Timer MUST be stopped. If the timer was not running for the Re- 964 configuration Request Sequence Number, the processing of the Re- 965 configuration Response Parameter is complete. 967 H2: If the Result field indicates 'In progress', the timer for the 968 Re-configuration Request Sequence Number is started again. If 969 the timer runs off, the RE-CONFIG chunk MUST be retransmitted 970 but the corresponding error counters MUST NOT be incremented. 972 H3: If the Result field does not indicate successful processing the 973 processing of this response is complete. 975 H4: If the request was an Outgoing SSN Reset Request the affected 976 streams MUST now be reset and all queued data should be 977 processed now and assigning of stream sequence numbers is 978 allowed again. 980 H5: If the request was an SSN/TSN Reset Request new data MUST be 981 sent from Receiver's next TSN and beginning with stream sequence 982 number 0 for all outgoing streams. All incoming streams MUST be 983 reset to 0 as the next expected stream sequence number. The 984 peer will send DATA chunks starting with Sender's next TSN. 986 H6: If the request was to add outgoing streams, the endpoint MUST 987 add the additional streams to the association. Note that an 988 implementation may allocate the memory at the time of the 989 request, but it MUST NOT use the streams until the peer has 990 responded with a positive acknowledgment. 992 6. Socket API Considerations 994 This section describes how the socket API defined in 995 [I-D.ietf-tsvwg-sctpsocket] needs to be extended to make the features 996 of SCTP re-configuration available to the application. 998 Please note that this section is informational only. 1000 6.1. Events 1002 When the SCTP_ASSOC_CHANGE notification is delivered and both peers 1003 support the extension described in this document, 1004 SCTP_ASSOC_SUPPORTS_RE_CONFIG should be listed in the sac_info field. 1006 The union sctp_notification {} is extended to contain three new 1007 fields: sn_strreset_event, sn_assocreset_event, and 1008 sn_strchange_event: 1010 union sctp_notification { 1011 struct { 1012 uint16_t sn_type; 1013 uint16_t sn_flags; 1014 uint32_t sn_length; 1015 } sn_header; 1016 ... 1017 struct sctp_stream_reset_event sn_strreset_event; 1018 struct sctp_assoc_reset_event sn_assocreset_event; 1019 struct sctp_stream_change_event sn_strchange_event; 1020 ... 1021 } 1023 The corresponding sn_type values are given in Table 4. 1025 +--------------------------+----------------------------------------+ 1026 | sn_type | valid field in union sctp_notification | 1027 +--------------------------+----------------------------------------+ 1028 | SCTP_STREAM_RESET_EVENT | sn_strreset_event | 1029 | SCTP_ASSOC_RESET_EVENT | sn_assocreset_event | 1030 | SCTP_STREAM_CHANGE_EVENT | sn_strchange_event | 1031 +--------------------------+----------------------------------------+ 1033 Table 4 1035 These events are delivered when an incoming request was processed 1036 successfully or the processing of an outgoing request has been 1037 finished. 1039 6.1.1. Stream Reset Event 1041 The event delivered has the following structure: 1043 struct sctp_stream_reset_event { 1044 uint16_t strreset_type; 1045 uint16_t strreset_flags; 1046 uint32_t strreset_length; 1047 sctp_assoc_t strreset_assoc_id; 1048 uint16_t strreset_stream_list[]; 1049 }; 1051 strreset_type: It should be SCTP_STREAM_RESET_EVENT. 1053 strreset_flags: This field is formed from the bitwise OR of one or 1054 more of the following currently defined flags: 1056 SCTP_STREAM_RESET_INCOMING_SSN: The stream identifiers given in 1057 strreset_stream_list[] refer to incoming streams of the 1058 endpoint. 1060 SCTP_STREAM_RESET_OUTGOING_SSN: The stream identifiers given in 1061 strreset_stream_list[] refer to outgoing streams of the 1062 endpoint. 1064 SCTP_STREAM_RESET_DENIED: The corresponding request was denied by 1065 the peer. 1067 SCTP_STREAM_RESET_FAILED: The corresponding request failed. 1069 At least one of SCTP_STREAM_RESET_INCOMING_SSN and 1070 SCTP_STREAM_RESET_OUTGOING_SSN is set. SCTP_STREAM_RESET_DENIED 1071 and SCTP_STREAM_RESET_FAILED are mutually exclusive. If the 1072 request was successful, none of these are set. 1074 strreset_length: This field is the total length in bytes of the 1075 delivered event, including the header. 1077 strreset_assoc_id: The association id field, holds the identifier 1078 for the association. All notifications for a given association 1079 have the same association identifier. For one-to-one style 1080 sockets, this field is ignored. 1082 strreset_stream_list: The list of stream identifiers this event 1083 refers to. An empty list identifies all streams as being reset. 1084 Depending on strreset_flags the identifiers refer to incoming or 1085 outgoing streams or both. 1087 6.1.2. Association Reset Event 1089 The event delivered has the following structure: 1091 struct sctp_assoc_reset_event { 1092 uint16_t assocreset_type; 1093 uint16_t assocreset_flags; 1094 uint32_t assocreset_length; 1095 sctp_assoc_t assocreset_assoc_id; 1096 uint32_t assocreset_local_tsn; 1097 uint32_t assocreset_remote_tsn; 1098 }; 1099 assocreset_type: It should be SCTP_ASSOC_RESET_EVENT. 1101 assocreset_flags: This field is formed from the bitwise OR of one or 1102 more of the following currently defined flags: 1104 SCTP_ASSOC_RESET_DENIED: The corresponding outgoing request was 1105 denied by the peer. 1107 SCTP_ASSOC_RESET_FAILED: The corresponding outgoing request 1108 failed. 1110 SCTP_ASSOC_RESET_DENIED and SCTP_ASSOC_RESET_FAILED are mutual 1111 exclusive. If the request was successful, none of these are set. 1113 assocreset_length: This field is the total length in bytes of the 1114 delivered event, including the header. 1116 assocreset_assoc_id: The association id field, holds the identifier 1117 for the association. All notifications for a given association 1118 have the same association identifier. For one-to-one style 1119 sockets, this field is ignored. 1121 assocreset_local_tsn: The next TSN used by the endpoint. 1123 assocreset_remote_tsn: The next TSN used by the peer. 1125 6.1.3. Stream Change Event 1127 The event delivered has the following structure: 1129 struct sctp_stream_change_event { 1130 uint16_t strchange_type; 1131 uint16_t strchange_flags; 1132 uint32_t strchange_length; 1133 sctp_assoc_t strchange_assoc_id; 1134 uint16_t strchange_instrms; 1135 uint16_t strchange_outstrms; 1136 }; 1138 strchange_type: It should be SCTP_STREAM_CHANGE_EVENT. 1140 strchange_flags: This field is formed from the bitwise OR of one or 1141 more of the following currently defined flags: 1143 SCTP_STREAM_CHANGE_DENIED: The corresponding request was denied 1144 by the peer. 1146 SCTP_STREAM_CHANGE_FAILED: The corresponding request failed. 1148 SCTP_STREAM_CHANGE_DENIED and SCTP_STREAM_CHANGE_FAILED are mutual 1149 exclusive. If the request was successful, none of these are set. 1151 strchange_length: This field is the total length in bytes of the 1152 delivered event, including the header. 1154 strchange_assoc_id: The association id field, holds the identifier 1155 for the association. All notifications for a given association 1156 have the same association identifier. For one-to-one style 1157 sockets, this field is ignored. 1159 strchange_instrms: The number of streams that the peer is allowed to 1160 use outbound. 1162 strchange_outstrms: The number of streams that the endpoint is 1163 allowed to use outbound. 1165 6.2. Event Subscription 1167 Subscribing to events as described in [I-D.ietf-tsvwg-sctpsocket] 1168 uses a setsockopt() call with the SCTP_EVENT socket option. This 1169 option takes the following structure that specifies the association, 1170 the event type (using the same value found in the event type field) 1171 and an on/off boolean. 1173 struct sctp_event { 1174 sctp_assoc_t se_assoc_id; 1175 uint16_t se_type; 1176 uint8_t se_on; 1177 }; 1179 The user fills in the se_type with the same value found in the 1180 strreset_type field i.e. SCTP_STREAM_RESET_EVENT. The user will 1181 also fill in the se_assoc_id field with either the association to set 1182 this event on (this field is ignored for one-to-one style sockets) or 1183 one of the reserved constant values defined in 1184 [I-D.ietf-tsvwg-sctpsocket]. Finally the se_on field is set with a 1 1185 to enable the event or a 0 to disable the event. 1187 6.3. Socket Options 1189 The following table describes the new socket options which make the 1190 re-configuration features accessible to the user. They all use 1191 IPPROTO_SCTP as their level. 1193 If a call to setsockopt() is used to issue a Re-configuration request 1194 while the Re-configuration timer is running, setsockopt() will return 1195 -1 and error is set to EALREADY. 1197 +--------------------------+---------------------------+-----+-----+ 1198 | option name | data type | get | set | 1199 +--------------------------+---------------------------+-----+-----+ 1200 | SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value | X | X | 1201 | SCTP_RESET_STREAMS | struct sctp_reset_streams | | X | 1202 | SCTP_RESET_ASSOC | sctp_assoc_t | | X | 1203 | SCTP_ADD_STREAMS | struct sctp_add_streams | | X | 1204 +--------------------------+---------------------------+-----+-----+ 1206 Table 5 1208 6.3.1. Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET) 1210 This option allows a user to control whether the SCTP implementation 1211 processes or denies incoming requests in STREAM_RESET chunks. 1213 The default is to deny all incoming requests. 1215 To set or get this option the user fills in the following structure: 1217 struct sctp_assoc_value { 1218 sctp_assoc_t assoc_id; 1219 uint32_t assoc_value; 1220 }; 1222 assoc_id: This parameter is ignored for one-to-one style sockets. 1223 For one-to-many style sockets this parameter indicates which 1224 association the user is performing an action upon. 1226 assoc_value: It is formed from the bitwise OR of one or more of the 1227 following currently defined flags: 1229 SCTP_ENABLE_RESET_STREAM_REQ: Process received Incoming/Outgoing 1230 SSN Reset Requests if this flag is set, deny them if not. 1232 SCTP_ENABLE_RESET_ASSOC_REQ: Process received SSN/TSN Reset 1233 Requests if this flag is set, deny them if not. 1235 SCTP_ENABLE_CHANGE_ASSOC_REQ: Process received Add Outgoing 1236 Streams Requests if this flag is set, deny them if not. 1238 The default value is !(SCTP_ENABLE_RESET_STREAM_REQ| 1239 SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ). 1241 Please note that using the option does not have any impact on 1242 subscribing to any related events. 1244 6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS) 1246 This option allows the user to request the reset of incoming and/or 1247 outgoing streams. 1249 To set or get this option the user fills in the following structure: 1251 struct sctp_reset_streams { 1252 sctp_assoc_t srs_assoc_id; 1253 uint16_t srs_flags; 1254 uint16_t srs_number_streams; 1255 uint16_t srs_stream_list[]; 1256 }; 1258 srs_assoc_id: This parameter is ignored for one-to-one style 1259 sockets. For one-to-many style sockets this parameter indicates 1260 which association the user is performing an action upon. 1262 srs_flags: This parameter describes which class of streams is reset. 1263 It is formed from the bitwise OR of one or more of the following 1264 currently defined flags: 1266 * SCTP_STREAM_RESET_INCOMING 1268 * SCTP_STREAM_RESET_OUTGOING 1270 srs_number_streams: This parameter is the number of elements in the 1271 srs_stream_list. If it is zero, the operation is performed on all 1272 streams. 1274 srs_stream_list: This parameter contains a list of stream 1275 identifiers the operation is performed upon. It contains 1276 srs_number_streams elements. If it is empty, the operation is 1277 performed on all streams. Depending on srs_flags the identifiers 1278 refer to incoming or outgoing streams or both. 1280 6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) 1282 This option allows a user to request the reset of the SSN/TSN. 1284 To set this option the user provides an option_value of type 1285 sctp_assoc_t. 1287 On one-to-one style sockets the option_value is ignored. For one-to- 1288 many style sockets the option_value is the association identifier of 1289 the association the action is to be performed upon. 1291 6.3.4. Add Incoming and/or Outgoing Streams (SCTP_ADD_STREAMS) 1293 This option allows a user to request the addition of a number of 1294 incoming and/or outgoing streams. 1296 To set this option the user fills in the following structure: 1298 struct sctp_add_streams { 1299 sctp_assoc_t sas_assoc_id; 1300 uint16_t sas_instrms; 1301 uint16_t sas_outstrms; 1302 }; 1304 sas_assoc_id: This parameter is ignored for one-to-one style 1305 sockets. For one-to-many style sockets this parameter indicates 1306 which association the user is performing an action upon. 1308 sas_instrms: This parameter is the number of incoming streams to 1309 add. 1311 sas_outstrms: This parameter is the number of outgoing streams to 1312 add. 1314 An endpoint can limit the number of incoming and outgoing streams by 1315 using the sinit_max_instreams field in the struct sctp_initmsg{} when 1316 issuing an SCTP_INIT socket option, as defined in 1317 [I-D.ietf-tsvwg-sctpsocket]. An incoming request asking for more 1318 streams than allowed will be denied. 1320 7. Security Considerations 1322 The SCTP socket API as described in [I-D.ietf-tsvwg-sctpsocket] 1323 exposes the sequence numbers of received DATA chunks to the 1324 application. An application might expect them to be monotonically 1325 increasing. When using the re-configuration extension this might no 1326 longer be true. Therefore the applications must enable this 1327 extension explicitly before it is used. In addition, applications 1328 must subscribe explicitly to notifications related to the re- 1329 configuration extension before receiving them. 1331 SCTP associations are protected against blind attackers by using the 1332 verification tags. This is still valid when using the re- 1333 configuration extension. Therefore this extension does not add any 1334 additional security risk to SCTP in relation to blind attackers. 1336 When the both sequence numbers are reset, the maximum segment 1337 lifetime is used to avoid the wrap-around for the TSN. 1339 8. IANA Considerations 1341 [NOTE to RFC-Editor: 1343 "RFCXXXX" is to be replaced by the RFC number you assign this 1344 document. 1346 ] 1348 [NOTE to RFC-Editor: 1350 The suggested values for the chunk type and the chunk parameter 1351 types are tentative and to be confirmed by IANA. 1353 ] 1355 This document (RFCXXXX) is the reference for all registrations 1356 described in this section. The suggested changes are described 1357 below. 1359 8.1. A New Chunk Type 1361 A chunk type has to be assigned by IANA. It is suggested to use the 1362 values given in Table 1. IANA should assign this value from the pool 1363 of chunks with the upper two bits set to '10'. 1365 This requires an additional line in the "Chunk Types" registry for 1366 SCTP: 1368 Chunk Types 1370 ID Value Chunk Type Reference 1371 ----- ---------- --------- 1372 130 Re-configuration Chunk (RE-CONFIG) [RFCXXXX] 1374 The registration table as defined in [RFC6096] for the chunk flags of 1375 this chunk type is empty. 1377 8.2. Six New Chunk Parameter Types 1379 Six chunk parameter types have to be assigned by IANA. It is 1380 suggested to use the values given in Table 2. IANA should assign 1381 these values from the pool of parameters with the upper two bits set 1382 to '00'. 1384 This requires six additional lines in the "Chunk Parameter Types" 1385 registry for SCTP: 1387 Chunk Parameter Types 1389 ID Value Chunk Parameter Type Reference 1390 -------- ------------------------------------------------ --------- 1391 13 Outgoing SSN Reset Request Parameter [RFCXXXX] 1392 14 Incoming SSN Reset Request Parameter [RFCXXXX] 1393 15 SSN/TSN Reset Request Parameter [RFCXXXX] 1394 16 Re-configuration Response Parameter [RFCXXXX] 1395 17 Add Outgoing Streams Request Parameter [RFCXXXX] 1396 18 Add Incoming Streams Request Parameter [RFCXXXX] 1398 9. Acknowledgments 1400 The authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch, 1401 Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and 1402 Vlad Yasevich for there invaluable comments. 1404 10. References 1406 10.1. Normative References 1408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1409 Requirement Levels", BCP 14, RFC 2119, March 1997. 1411 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1412 Conrad, "Stream Control Transmission Protocol (SCTP) 1413 Partial Reliability Extension", RFC 3758, May 2004. 1415 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1416 RFC 4960, September 2007. 1418 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1419 Kozuka, "Stream Control Transmission Protocol (SCTP) 1420 Dynamic Address Reconfiguration", RFC 5061, 1421 September 2007. 1423 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 1424 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 1425 January 2011. 1427 10.2. Informative References 1429 [I-D.ietf-tsvwg-sctpsocket] 1430 Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1431 Yasevich, "Sockets API Extensions for Stream Control 1432 Transmission Protocol (SCTP)", 1433 draft-ietf-tsvwg-sctpsocket-32 (work in progress), 1434 October 2011. 1436 Appendix A. Examples of the Re-configuration procedures 1438 Please note that this appendix is informational only. 1440 The following message flows between an Endpoint A and an Endpoint Z 1441 illustrate the described procedures. The time progresses in downward 1442 direction. 1444 The following example illustrates an Endpoint A resetting stream 1 1445 and 2 for just its outgoing streams. 1447 E-A E-Z 1448 ----------[RE-CONFIG(OUT-REQ:X/1,2)]----------> 1449 <-------------[RE-CONFIG(RESP:X)]-------------- 1451 The following example illustrates an Endpoint A resetting stream 1 1452 and 2 for just its incoming streams. 1454 E-A E-Z 1455 -----------[RE-CONFIG(IN-REQ:X/1,2)]----------> 1456 <--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]---------- 1457 -------------[RE-CONFIG(RESP:Y)]--------------> 1459 The following example illustrates an Endpoint A resetting all streams 1460 in both directions. 1462 E-A E-Z 1463 -----[RE-CONFIG(OUT-REQ:X,Y-1|IN-REQ:X+1)]----> 1464 <------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]------- 1465 -------------[RE-CONFIG(RESP:Y)]--------------> 1467 The following example illustrates an Endpoint A requesting the 1468 streams and TSNs be reset. At the completion E-A has the new sending 1469 TSN (selected by the peer) of B and E-Z has the new sending TSN of A 1470 (also selected by the peer). 1472 E-A E-Z 1473 ------------[RE-CONFIG(TSN-REQ:X)]------------> 1474 <-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]----- 1476 The following example illustrates an Endpoint A requesting to add 3 1477 additional outgoing streams. 1479 E-A E-Z 1480 --------[RE-CONFIG(ADD_OUT_STRMS:X/3)]--------> 1481 <-------------[RE-CONFIG(RESP:X)]-------------- 1483 The following example illustrates an Endpoint A requesting to add 3 1484 additional incoming streams. 1486 E-A E-Z 1487 ---------[RE-CONFIG(ADD_IN_STRMS:X/3)]--------> 1488 <----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y,X/3)]------ 1489 -------------[RE-CONFIG(RESP:Y)]--------------> 1491 Authors' Addresses 1493 Randall R. Stewart 1494 Adara Networks 1495 Chapin, SC 29036 1496 USA 1498 Email: randall@lakerest.net 1500 Michael Tuexen 1501 Muenster University of Applied Sciences 1502 Stegerwaldstr. 39 1503 48565 Steinfurt 1504 DE 1506 Email: tuexen@fh-muenster.de 1508 Peter Lei 1509 Cisco Systems, Inc. 1510 8735 West Higgins Road 1511 Suite 300 1512 Chicago, IL 60631 1513 USA 1515 Email: peterlei@cisco.com