idnits 2.17.1 draft-stewart-tsvwg-sctpstrrst-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 879. 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 Copyright Line does not match the current year -- 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 (June 20, 2008) is 5790 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft The Resource Group 4 Intended status: Standards Track P. Lei 5 Expires: December 22, 2008 Cisco Systems, Inc. 6 M. Tuexen 7 Muenster Univ. of Applied Sciences 8 June 20, 2008 10 Stream Control Transmission Protocol (SCTP) Stream Reset 11 draft-stewart-tsvwg-sctpstrrst-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 22, 2008. 38 Abstract 40 Many applications that desire to use SCTP have requested the ability 41 to "reset" a stream. The intention of resetting a stream is to start 42 the numbering sequence of the stream back at 'zero' with a 43 corresponding notification to the upper layer that this act as been 44 performed. The applications that have requested this feature 45 normally desire it so that they can "re-use" streams for different 46 purposes but still utilize the stream sequence number for the 47 application to track the message flows. Thus, without this feature, 48 a new use on an old stream would result in message numbers larger 49 than expected without a protocol mechanism to "start the streams back 50 at zero". This documents presents also a method for resetting the 51 transport sequence numbers and all stream sequence numbers. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. STREAM RESET Chunk . . . . . . . . . . . . . . . . . . . . 3 59 3.2. New Parameters . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2.1. Outgoing SSN Reset Request Parameter . . . . . . . . . 4 61 3.2.2. Incoming SSN Reset Request Parameter . . . . . . . . . 6 62 3.2.3. SSN/TSN Reset Request Parameter . . . . . . . . . . . 6 63 3.2.4. Stream Reset Response Parameter . . . . . . . . . . . 7 64 3.2.5. Add Streams . . . . . . . . . . . . . . . . . . . . . 8 65 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.1. Sender side procedures . . . . . . . . . . . . . . . . . . 9 67 4.1.1. Sender side procedures for the Stream Reset Chunk . . 10 68 4.1.2. Sender side procedures for the Outgoing SSN Reset 69 Request Parameter . . . . . . . . . . . . . . . . . . 10 70 4.1.3. Sender side procedures for the Incoming SSN Reset 71 Request Parameter . . . . . . . . . . . . . . . . . . 11 72 4.1.4. Sender side procedures for the SSN/TSN Reset 73 Request Parameter . . . . . . . . . . . . . . . . . . 12 74 4.1.5. Sender side procedures for the Stream Reset 75 Response Parameter . . . . . . . . . . . . . . . . . . 12 76 4.1.6. Sender side procedures for addition of streams . . . . 13 77 4.2. Receiver side procedures . . . . . . . . . . . . . . . . . 13 78 4.2.1. Receiver side procedures for the Stream Reset Chunk . 13 79 4.2.2. Receiver side procedures for the Outgoing SSN 80 Reset Request Parameter . . . . . . . . . . . . . . . 13 81 4.2.3. Receiver side procedures for the Incoming SSN 82 Reset Request Parameter . . . . . . . . . . . . . . . 14 83 4.2.4. Receiver side procedures for the SSN/TSN Reset 84 Request Parameter . . . . . . . . . . . . . . . . . . 15 85 4.2.5. Receiver side procedures for addition of streams . . . 16 86 4.2.6. Receiver side procedures for the Stream Reset 87 Response Parameter . . . . . . . . . . . . . . . . . . 16 88 4.3. Various Examples of the Stream Reset procedures . . . . . 16 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 6. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 92 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 94 Intellectual Property and Copyright Statements . . . . . . . . . . 20 96 1. Introduction 98 Many applications that desire to use [RFC4960] have requested the 99 ability to "reset" a stream. The intention of resetting a stream is 100 to start the numbering sequence of the stream back at 'zero' with a 101 corresponding notification to the upper layer that this act as been 102 performed. The applications that have requested this feature 103 normally desire it so that they can "re-use" streams for different 104 purposes but still utilize the stream sequence number for the 105 application to track the message flows. Thus, without this feature, 106 a new use of an old stream would result in message numbers larger 107 than expected without a protocol mechanism to "start the streams back 108 at zero". This documents presents also a method for resetting the 109 transport sequence numbers and all stream sequence numbers. 111 [ Editors note: We probably need to add more text here ] 113 2. Conventions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Data Formats 121 This section examines all new data formats defined by this document. 122 All transported integer numbers are in "network byte order" a.k.a., 123 Big Endian, unless otherwise noted. 125 3.1. STREAM RESET Chunk 127 This document adds one new chunk type to SCTP. The suggested value 128 for this chunk is 0x82 hex or 130 decimal. The range selected by 129 IANA must have the upper bit (or ignore bit) set and the next to 130 highest bit (or the report bit) cleared. The chunk has the following 131 format: 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Type = 0x82 | Chunk Flags | Chunk Length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Stream Reset Parameter | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Stream Reset Parameter (optional) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Chunk Type: 1 byte (unsigned integer) 144 This field holds the IANA defined chunk type for the STREAM RESET 145 chunk. 147 Chunk Flags: 1 byte (unsigned integer) 148 This field is set to 0 by the sender and ignored by the receiver. 150 Chunk Length: 2 bytes (unsigned integer) 151 This field holds the length of the chunk, including the Chunk 152 Type, Chunk Flags and Chunk Length. 154 Stream Reset Parameter 155 This field holds a Stream Reset Request Parameter or a Stream 156 Reset Response Parameter. 158 Note each STREAM RESET chunk holds at least one parameter and at most 159 two parameters. Only the following combinations are allowed: 161 1. Outgoing SSN Reset Request Parameter. 163 2. Incoming SSN Reset Request Parameter. 165 3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request 166 Parameter. 168 4. SSN/TSN Reset Request Parameter. 170 5. Stream Reset Response Parameter. 172 6. Stream Reset Response Parameter, Outgoing SSN Reset Request 173 Parameter. 175 7. Stream Reset Response Parameter, Stream Reset Response Parameter. 177 3.2. New Parameters 179 This section identifies four new parameters, their formats, and in 180 what chunk type these parameters may appear. 182 3.2.1. Outgoing SSN Reset Request Parameter 184 This parameter is used by the sender to request some outgoing streams 185 to be reset. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Parameter Type = 0x000d | Parameter Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Stream Reset Request Sequence Number | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Stream Reset Response Sequence Number | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Senders Last Assigned TSN | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Stream Number 1 (optional) | Stream Number 2 (optional) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 / ...... / 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Stream Number N-1 (optional) | Stream Number N (optional) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Parameter Type: 2 bytes (unsigned integer) 206 This field holds the IANA defined parameter type for Stream Reset 207 Request Parameter. The suggested value of this field for IANA is 208 0x000d. 210 Parameter Length: 2 bytes (unsigned integer) 211 This field holds the length of the parameter. 213 Stream Reset Request Sequence Number: 4 bytes (unsigned integer) 214 This field is used to identify the request. It is a monotonically 215 increasing number that is initialized to the same value as the 216 Initial TSN number. It is increased by 1. 218 Stream Reset Response Sequence Number: 4 bytes (unsigned integer) 219 In case that this Outgoing SSN Reset Request Parameter is sent in 220 response to an Incoming SSN Reset Request Parameter this parameter 221 is also an implicit response to the incoming request. Then this 222 field holds the Stream Reset Request Sequence Number of the 223 incoming request. In the other case it holds the next expected 224 Stream Reset Request Sequence Number - 1. 226 Senders last assigned TSN: 4 bytes (unsigned integer) 227 This value holds the next TSN minus 1, in other words the last TSN 228 that this sender assigned. 230 Stream Number N: 2 bytes (unsigned integer) 231 This optional field, if included, is used to indicates specific 232 streams that are to be reset. If no streams are listed, then ALL 233 streams are to be reset. 235 This parameter can appear in a STREAM RESET chunk. This parameter 236 MUST NOT appear in any other chunk type. 238 3.2.2. Incoming SSN Reset Request Parameter 240 This parameter is used by the sender to request that the peer 241 requests some of its outgoing streams to be reset. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Parameter Type = 0x000e | Parameter Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Stream Reset Request Sequence Number | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Stream Number 1 (optional) | Stream Number 2 (optional) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 / ...... / 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Stream Number N-1 (optional) | Stream Number N (optional) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Parameter Type: 2 bytes (unsigned integer) 258 This field holds the IANA defined parameter type for Stream Reset 259 Request Parameter. The suggested value of this field for IANA is 260 0x000e. 262 Parameter Length: 2 bytes (unsigned integer) 263 This field holds the length of the parameter. 265 Stream Reset Request Sequence Number: 4 bytes (unsigned integer) 266 This field is used to identify the request. It is a monotonically 267 increasing number that is initialized to the same value as the 268 Initial TSN number. It is increased by 1. 270 Stream Number N: 2 bytes (unsigned integer) 271 This optional field, if included, is used to indicate specific 272 streams that are to be reset. If no streams are listed, then ALL 273 streams are to be reset. 275 This parameter can appear in a STREAM RESET chunk. This parameter 276 MUST NOT appear in any other chunk type. 278 3.2.3. SSN/TSN Reset Request Parameter 280 This parameter is used by the sender to request to reset the TSN and 281 SSN numbering of all streams. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Parameter Type = 0x000f | Parameter Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Stream Reset Request Sequence Number | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Parameter Type: 2 bytes (unsigned integer) 292 This field holds the IANA defined parameter type for Stream Reset 293 Request Parameter. The suggested value of this field for IANA is 294 0x000f. 296 Parameter Length: 2 bytes (unsigned integer) 297 This field holds the length of the parameter. 299 Stream Reset Request Sequence Number: 4 bytes (unsigned integer) 300 This field is used to identify the request. It is a monotonically 301 increasing number that is initialized to the same value as the 302 Initial TSN number. It is increased by 1. 304 This parameter can appear in a STREAM RESET chunk. This parameter 305 MUST NOT appear in any other chunk type. 307 3.2.4. Stream Reset Response Parameter 309 This parameter is used by the receiver of a stream reset request 310 parameter to respond to the stream reset request. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Parameter Type = 0x0010 | Parameter Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Stream Reset Response Sequence Number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Result | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Sender's next TSN (optional) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Receiver's next TSN (optional) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Parameter Type: 2 bytes (unsigned integer) 327 This field holds the IANA defined parameter type for Stream Reset 328 Response Parameter. The suggested value of this field for IANA is 329 0x0010. 331 Parameter Type Length: 2 bytes (unsigned integer) 332 This field holds the length of the parameter. 334 Stream Reset Response Sequence Number: 4 bytes (unsigned integer) 335 This value is copied from the request parameter and is used by the 336 receiver of the Stream Reset Response Parameter to tie the 337 response to the request. 339 Result: 4 bytes (unsigned integer) 340 This value describes the result of the processing of the request. 341 It is encoded as given by the following table 343 +--------+-------------------------------------+ 344 | Result | Description | 345 +--------+-------------------------------------+ 346 | 0 | Nothing to do | 347 | 1 | Performed | 348 | 2 | Denied | 349 | 3 | Error - Wrong SSN | 350 | 4 | Error - Request already in progress | 351 | 5 | Error - Bad Sequence Number | 352 +--------+-------------------------------------+ 354 Table 1 356 Sender's next TSN: 4 bytes (unsigned integer) This field holds the 357 TSN the sender of the Response will use to send the next DATA 358 chunk. The field is only applicable in responses to SSN/TSN reset 359 requests. 361 Receiver's next TSN: 4 bytes (unsigned integer) This field holds the 362 TSN the receiver of the response must use to send the next DATA 363 chunk. The field is only applicable in responses to SSN/TSN reset 364 requests. 366 This parameter can appear in a STREAM RESET chunk. This parameter 367 MUST NOT appear in any other chunk type. 369 3.2.5. Add Streams 371 This parameter is used by the sender to request that the peer add the 372 requested number of streams to the association. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Parameter Type = 0x0011 | Parameter Length=12 | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Stream Reset Request Sequence Number | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Number of new streams | Reserved | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Parameter Type: 2 bytes (unsigned integer) 385 This field holds the IANA defined parameter type for the Add 386 Streams Parameter. The suggested value of this field for IANA is 387 0x0011. 389 Parameter Length: 2 bytes (unsigned integer) 390 This field holds the length of the parameter, a fixed value of 12 391 MUST be found in this field. 393 Stream Reset 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. 398 Number of new streams: 2 bytes (unsigned integer) This value holds 399 the number of additional streams the sender would like added to 400 the association. Streams are added in order and are consecutive, 401 e.g. if an association has four streams (0-3) and a requested is 402 made to add 3 streams then the new streams will be 4, 5 and 6. 404 Reserved: 2 bytes (unsigned integer) This field is reserved. It 405 SHOULD be set to 0 by the sender and ignored by the receiver. 407 This parameter can appear in a STREAM RESET chunk. This parameter 408 MUST NOT appear in any other chunk type. 410 4. Procedures 412 This section defines the procedures used by both the sender and 413 receiver of a stream reset. We also give various example stream 414 reset scenarios. 416 4.1. Sender side procedures 418 This section describes the procedures related to the sending of 419 Stream Reset Chunks. A Stream Reset Chunk is a composition of a Type 420 Length Value (TLV) parameters. 422 4.1.1. Sender side procedures for the Stream Reset Chunk 424 Note that before sending a Stream Reset Chunk the sender MUST ensure 425 that the peer advertised support for the stream reset extension. The 426 indication for support of the extensions MUST be determined using the 427 Supported Extensions Parameter in either the INIT or INIT-ACK. This 428 parameter is defined in [RFC5061]. If the chunk value '0x82' does 429 NOT appear in the supported extensions list of chunks, then the 430 sender MUST NOT send any stream reset request to the peer and any 431 request by the application for such service SHOULD be responded to 432 with an appropriate error indicating the peer SCTP stack does not 433 support the stream reset extension. 435 After packaging the Stream Reset Chunk and sending it to the peer the 436 sender MUST start a 'Stream Reset Timer' when the STREAM RESET chunk 437 contains at least one request parameter. If it contains no request 438 parameter, the Stream Reset Timer MUST NOT be started. This timer 439 MUST use the same value as SCTP's Data transmission timer (i.e. the 440 RTO timer) and MUST use exponential backoff doubling the value at 441 every expiration. If the timer does expire, besides doubling the 442 value, the sender MUST retransmit the Stream Reset Chunk, increment 443 the appropriate error counts (both for the association and the 444 destination), and do threshold management possibly destroying the 445 association if SCTP retransmission thresholds are surpassed. 447 4.1.2. Sender side procedures for the Outgoing SSN Reset Request 448 Parameter 450 When an SCTP sender wants to reset the SSNs of some or all outgoing 451 streams it can send an Outgoing SSN Reset Request Parameter if the 452 Stream Reset Timer is not running. The following steps MUST be 453 followed: 455 A1: The sender MUST stop assigning new SSNs to new user data 456 provided by the upper layer. This is because it is unknown as 457 to if the receiver of the request will accept or deny it and 458 more so, a lost request might cause an out-of-sequence error in 459 a stream that the receiver is not yet prepared to handle. 461 A2: The sender MUST assign the next stream reset request sequence 462 number and put it into the Stream Reset Request Sequence Number 463 field of the Outgoing SSN Reset Request Parameter. After 464 assigning it the next stream reset request sequence number MUST 465 be incremented by '1'. 467 A3: If this Outgoing SSN Reset Request Parameter is sent in response 468 to an Incoming SSN Request Parameter the Stream Reset Request 469 Sequence Number of the Incoming SSN Request Parameter is copied 470 into the Stream Reset Response Sequence Number field of the 471 Outgoing SSN Reset Request Parameter. If the Outgoing SSN Reset 472 Request Parameter is sent on request of the upper layer the 473 Stream Reset Response Sequence Number is the next expected 474 Stream Reset Request Sequence Number of the peer - 3. 476 A4: The sender fills in the TSN it has assigned last. 478 A5: If this Outgoing SSN Reset Request Parameter is sent in response 479 to an Incoming SSN Request Parameter the Stream Numbers are 480 copied from the Incoming SSN Request Parameter to the Outgoing 481 SSN Reset Request Parameter. If this Outgoing SSN Reset Request 482 Parameter is sent on request of the upper layer and the sender 483 wants all outgoing streams to be reset no Stream Numbers MUST be 484 put into the Outgoing SSN Reset Request Parameter. If the 485 sender wants only some outgoing streams to be reset these Stream 486 Numbers MUST be filled in the Outgoing SSN Reset Request 487 Parameter. 489 A6: The Outgoing SSN Reset Request Parameter is put into a STREAM 490 RESET Chunk. It MAY be put together with an Incoming SSN Reset 491 Request Parameter or an Stream Reset Response Parameter and MUST 492 NOT be put together with any other parameter. 494 A7: The STREAM RESET Chunk is sent following the rules given in 495 Section 4.1.1 497 4.1.3. Sender side procedures for the Incoming SSN Reset Request 498 Parameter 500 When an SCTP sender wants to reset the SSNs of some or all incoming 501 streams it can send an Incoming SSN Reset Request Parameter if the 502 Stream Reset Timer is not running. The following steps MUST be 503 followed: 505 B1: The sender MUST assign the next stream reset request sequence 506 number and put it into the Stream Reset Request Sequence Number 507 field of the Incoming SSN Reset Request Parameter. After 508 assigning it the next stream reset request sequence number MUST 509 be incremented by '1'. 511 B2: If the sender wants all incoming streams to be reset no Stream 512 Numbers MUST be put into the Incoming SSN Reset Request 513 Parameter. If the sender wants only some incoming streams to be 514 reset these Stream Numbers MUST be filled in the Incoming SSN 515 Reset Request Parameter. 517 B3: The Incoming SSN Reset Request Parameter is put into a STREAM 518 RESET Chunk. It MAY be put together with an Outgoing SSN Reset 519 Request Parameter and MUST NOT be put together with any other 520 parameter. 522 B4: The STREAM RESET Chunk is sent following the rules given in 523 Section 4.1.1 525 4.1.4. Sender side procedures for the SSN/TSN Reset Request Parameter 527 When an SCTP sender wants to reset the SSNs and TSNs it can send a 528 SSN/TSN Reset Request Parameter if the Stream Reset Timer is not 529 running. The following steps MUST be followed: 531 C1: The sender MUST assign the next stream reset request sequence 532 number and put it into the Stream Reset Request Sequence Number 533 field of the SSN/TSN Reset Request Parameter. After assigning 534 it the next stream reset request sequence number MUST be 535 incremented by '1'. 537 C2: The sender MUST queue any user data. 539 C3: The SSN/TSN Reset Request Parameter is put into a STREAM RESET 540 Chunk. There MUST NOT be any other parameter in this chunk. 542 C4: The STREAM RESET Chunk is sent following the rules given in 543 Section 4.1.1 545 4.1.5. Sender side procedures for the Stream Reset Response Parameter 547 When an implementation receives a request parameter it MUST respond 548 with a Stream Reset Response Parameter in the following manner: 550 D1 The Stream Reset Request Sequence number of the incoming request 551 is copied to the Stream Reset Response Sequence Number field of 552 the Stream Reset Response Parameter. 554 D2 The result of the processing of the incoming request is filled in 555 the Result field of the Stream Reset Response Parameter 557 D3 If the incoming request is a SSN/TSN reset requests, the Sender's 558 next TSN field is filled with the next TSN the sender of this 559 Stream Reset Response Parameter will assign. For other requests 560 the Sender's next TSN field is not filled. 562 D4 If the incoming request is a SSN/TSN reset request, the 563 Receiver's next TSN field is filled with a TSN such that the 564 sender of the Stream Reset Response Parameter can be sure it can 565 discard received DATA chunks with smaller TSNs. A good value for 566 this is the highest TSN it has seen plus some delta. For other 567 requests the Sender's next TSN field is not filled. 569 4.1.6. Sender side procedures for addition of streams 571 When an SCTP sender wants to increase the number of outbound streams 572 it is able to send to, it may add a Add Streams parameter to the 573 STREAM RESET chunk. Upon sending the request the sender MUST await a 574 positive acknowledgment (Success) before using any additional stream 575 added by this request. Note that new streams are added adjacent to 576 the previous steams with no gaps. This means that if a request is 577 made to add 2 streams to an association that has already 5 (0-4) then 578 the new streams, upon successful completion, are streams 5 and 6. 579 Any new stream MUST number its first message to be stream sequence 0. 581 4.2. Receiver side procedures 583 4.2.1. Receiver side procedures for the Stream Reset Chunk 585 Upon reception of a Stream Reset Chunk each parameter within it 586 should be processed. If some parameters have to be sent back, they 587 MUST all be put into one STREAM RESET chunk. If the received STREAM 588 RESET chunk contains at least one request parameter, a SACK chunk 589 MUST be sent back and MAY be bundled with the STREAM RESET chunk. If 590 the received STREAM RESET chunk contains at least one request and 591 based on the analysis of the Stream Reset Request Sequence Numbers 592 this is the last received STREAM RESET chunk, the same STREAM RESET 593 chunk has to be sent back in response as earlier. 595 4.2.2. Receiver side procedures for the Outgoing SSN Reset Request 596 Parameter 598 The decision to deny a stream reset request is an administrative 599 decision and may be user configurable even after the association has 600 formed. If for whatever reason the endpoint does NOT wish to reset 601 any streams it MUST send a stream reset response as described in 602 Section 4.1.5 with an appropriate Result field. 604 In the case that the endpoint is willing to perform a stream reset 605 the following steps SHOULD be followed: 607 E1 If the Senders Last Assigned TSN number is greater than the 608 cumulative acknowledgment point, then the endpoint must enter 609 "deferred reset processing". In this mode, any data arriving 610 with a TSN number larger than the 'senders last assigned TSN' for 611 the effected stream(s) MUST be queued locally and held until the 612 Cumulative Acknowledgment point reaches the 'senders last 613 assigned TSN number'. When the Cumulative Acknowledgment point 614 reaches the last assigned TSN number then proceed to the next 615 step. Note that the receiver of a stream reset that causes it to 616 entered deferred reset processing does NOT withhold the stream 617 reset acknowledgment from the peer. This also means that the 618 receiver will need to queue up any additional stream reset 619 requests received including the one that caused the receiver to 620 enter deferred reset processing. 622 E2 If the Stream Reset Timer is running for the Stream Reset Request 623 Sequence Number indicated in the Stream Reset Response Sequence 624 Number field, mark the Stream Reset Request Sequence Number as 625 acknowledged. If all Stream Reset Request Sequence Numbers the 626 Stream Reset Timer is running for are acknowledged, stop the 627 Stream Reset Timer. 629 E3 If no Stream Numbers are listed in the parameter, then all 630 incoming streams MUST be reset to '0' as the next expected stream 631 sequence number. If specific Stream Numbers are listed, then 632 only these specific streams MUST be reset to '0' and all other 633 non-listed stream sequence numbers remain unchanged. 635 E4 Optionally an Upper Layer Notification SHOULD be sent to inform 636 the local endpoint that the inbound streams have been reset. 638 E5 Any queued TSN's (queued at step D3) should now be released and 639 processed normally. 641 E6 A Stream Reset Response Parameter is put into a STREAM RESET 642 chunk indicating successful processing. 644 E7 The STREAM RESET chunk is sent after the incoming STREAM RESET 645 chunk is processed completely. 647 4.2.3. Receiver side procedures for the Incoming SSN Reset Request 648 Parameter 650 The decision to deny a stream reset request is an administrative 651 decision and may be user configurable even after the association has 652 formed. If for whatever reason the endpoint does NOT wish to reset 653 any streams it MUST send a stream reset response as described in 654 Section 4.1.5 with an appropriate Result field. 656 In the case that the endpoint is willing to perform a stream reset 657 the following steps SHOULD be followed: 659 F1 An Outgoing Stream Reset Request Parameter MUST be put into an 660 STREAM RESET chunk according to Section 4.1.2. 662 F2 The STREAM RESET chunk is sent after the incoming STREAM RESET 663 chunk is processed completely. 665 4.2.4. Receiver side procedures for the SSN/TSN Reset Request Parameter 667 The decision to deny a stream reset request is an administrative 668 decision and may be user configurable even after the association has 669 formed. If for whatever reason the endpoint does NOT wish to reset 670 any streams it MUST send a stream reset response as described in 671 Section 4.1.5 with an appropriate Result field. 673 In the case that the endpoint is willing to perform a SSN/TSN reset 674 the following steps SHOULD be followed: 676 G1 Compute an appropriate value for the Receiver's next TSN, the TSN 677 the peer should use to send the next DATA chunk. Note that an 678 appropriate value should be larger than the highest TSN last 679 received plus a delta of at least 500 additional TSN's. 681 G2 Compute an appropriate value for the local endpoints next TSN, 682 i.e. the receiver of the SSN/TSN reset chunks next TSN to be 683 assigned. Note that an appropriate value should be larger than 684 the endpoints current next TSN to send by at least one TSN. 686 G3 Do the same processing as if a SACK chunk with no gap report and 687 a cumulative TSN ACK of Sender's next TSN - 1 was received. 689 G4 Do the same processing as if an FWD-TSN chunk with all streams 690 affected and a new cumulative TSN ACK of Receiver's next TSN - 1 691 was received. 693 G5 All incoming and outgoing streams MUST be reset to '0' as the 694 next expected and outgoing stream sequence numbers, respectively. 696 G6 A Stream Reset Response Parameter is put into a STREAM RESET 697 chunk indicating successful processing. 699 G7 The STREAM RESET chunk is sent after the incoming STREAM RESET 700 chunk is processed completely. 702 4.2.5. Receiver side procedures for addition of streams 704 When an SCTP endpoint receives a stream reset request adding 705 additional streams, it MUST send a response parameter either 706 acknowledging or rejecting the request. If the response is 707 successful the receiver MUST add the requested number of inbound 708 streams to the association, initializing the next expected stream 709 sequence number to be 0. 711 4.2.6. Receiver side procedures for the Stream Reset Response Parameter 713 On receipt of a Stream Reset Response Parameter the following MUST be 714 performed: 716 H1 If the Stream Reset Timer is running for the Stream Reset Request 717 Sequence Number indicated in the Stream Reset Response Sequence 718 Number field, mark the Stream Reset Request Sequence Number as 719 acknowledged. If all Stream Reset Request Sequence Numbers the 720 Stream Reset Timer is running for are acknowledged, stop the 721 Stream Reset Timer. If the timer was not running for the Stream 722 Reset Request Sequence Number, the processing of the Stream Reset 723 Response Parameter is complete. 725 H2 If the Result field does not indicate successful processing an 726 Upper Layer Notification SHOULD be sent to inform the local 727 endpoint of the failure to reset its outbound streams. 728 Afterwards processing of this response is complete. 730 H3 If the request was an Outgoing Stream Reset Request the affected 731 streams should now be reset and all queued data should be 732 processed now and assigning of stream sequence numbers is allowed 733 again. Optionally an Upper Layer Notification SHOULD be sent to 734 inform the local endpoint that the outbound streams have been 735 reset. 737 H4 If the request was a SSN/TSN Reset Request new DATA should be 738 sent from Receiver's next TSN and beginning with stream sequence 739 number '0' for all outgoing streams. All incoming streams are 740 also reset to '0' as the next expected stream sequence number. 741 The peer will send DATA chunks starting with Sender's next TSN. 743 4.3. Various Examples of the Stream Reset procedures 745 The following example illustrates an Endpoint A resetting all streams 746 in both directions. 748 E-A E-Z 749 ----------[STR_RESET(IN-REQ:X|OUT-REQ:X+1,Y-3)]-------> 750 <-[STR_RESET(RESP:Y|OUT-REQ:Y+1,X+1))]--------- 751 -------[STR_RESET(RESP:Y)]-----------------> 753 The following example illustrates an Endpoint A resetting stream 1 754 and 2 for just its outgoing streams. 756 E-A E-Z 757 -------[STR_RESET(OUT-REQ:X/1,2]------------------> 758 <---[STR_RESET(RESP:X/1,2)]------------ 760 The following example illustrates an Endpoint A resetting stream 1 761 and 2 for just its incoming streams. 763 E-A E-Z 764 ------[STR_RESET(IN-REQ:X/1,2]-----------> 765 <---[STR_RESET(RESP:X/1,2]------- 767 The following example illustrates an Endpoint A requesting the 768 streams and TSN's be reset. At the completion E-A has the new 769 sending TSN (selected by the peer) of B and E-Z has the new sending 770 TSN of A (also selected by the peer). 772 E-A E-Z 773 ------[STR_RESET(TSN-REQ:X]-----------> 774 <---[STR_RESET(RESP:X/S-TSN=A, R-TSN=B]------- 776 5. Security Considerations 778 Having the ability to reset a stream should not pose any additional 779 security risk to SCTP. An attacker that can successfully inject a 780 stream reset would also be able to inject data or other malicious 781 information into an association such as an ABORT. 783 6. Iana Considerations 785 This document defines one new chunk type and four new parameter 786 types. This document recommends the values of 0x82 for the chunk 787 type and 0x000d, 0x000e, 0x000f, 0x0010 and 0x0011 for the new 788 parameter types. However IANA may assign any free chunk or parameter 789 type as long it is from the same chunk or parameter pool. In the 790 case of the chunk, it MUST be from the pool of chunks with the upper 791 two bits set to '10'. In the case of the parameters, it MUST be from 792 the pool whose upper bits are set to '00'. 794 7. Acknowledgments 796 The authors wish to thank Paul Aitken and Irene Ruengeler for there 797 invaluable comments. 799 8. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, March 1997. 804 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 805 RFC 4960, September 2007. 807 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 808 Kozuka, "Stream Control Transmission Protocol (SCTP) 809 Dynamic Address Reconfiguration", RFC 5061, 810 September 2007. 812 Authors' Addresses 814 Randall R. Stewart 815 The Resource Group 816 1700 Pennsylvania Ave NW 817 Suite 56 818 Washington, DC 20006 819 USA 821 Phone: 822 Email: randall.stewart@trgworld.com 823 Peter Lei 824 Cisco Systems, Inc. 825 8735 West Higgins Road 826 Suite 300 827 Chicago, IL 60631 828 USA 830 Phone: 831 Email: peterlei@cisco.com 833 Michael Tuexen 834 Muenster Univ. of Applied Sciences 835 Stegerwaldstr. 39 836 48565 Steinfurt 837 Germany 839 Email: tuexen@fh-muenster.de 841 Full Copyright Statement 843 Copyright (C) The IETF Trust (2008). 845 This document is subject to the rights, licenses and restrictions 846 contained in BCP 78, and except as set forth therein, the authors 847 retain all their rights. 849 This document and the information contained herein are provided on an 850 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 851 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 852 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 853 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 854 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 855 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 857 Intellectual Property 859 The IETF takes no position regarding the validity or scope of any 860 Intellectual Property Rights or other rights that might be claimed to 861 pertain to the implementation or use of the technology described in 862 this document or the extent to which any license under such rights 863 might or might not be available; nor does it represent that it has 864 made any independent effort to identify any such rights. Information 865 on the procedures with respect to rights in RFC documents can be 866 found in BCP 78 and BCP 79. 868 Copies of IPR disclosures made to the IETF Secretariat and any 869 assurances of licenses to be made available, or the result of an 870 attempt made to obtain a general license or permission for the use of 871 such proprietary rights by implementers or users of this 872 specification can be obtained from the IETF on-line IPR repository at 873 http://www.ietf.org/ipr. 875 The IETF invites any interested party to bring to its attention any 876 copyrights, patents or patent applications, or other proprietary 877 rights that may cover technology that may be required to implement 878 this standard. Please address the information to the IETF at 879 ietf-ipr@ietf.org.