idnits 2.17.1 draft-ietf-tsvwg-addip-sctp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 28 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2402], [RFC2026], [RFC2119], [RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '... The keywords MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 114: '... SHOULD NOT, RECOMMENDED, NOT RECOM...' RFC 2119 keyword, line 158: '...ge requests that MUST be acknowledged....' RFC 2119 keyword, line 247: '... of a ASCONF-ACK MAY indicate complete...' RFC 2119 keyword, line 402: '... [RFC2960]). The receiver MAY mark this as its primary upon...' (69 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the sender of a ASCONF chunk receives a Operational Error indicating that the ASCONF chunk type is not understood, then the sender MUST not send subsequent ASCONF chunks to the peer. The endpoint should also inform the upper level application that the peer endpoint does not support any of the extensions detailed in this document. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: X1) Parse the ASCONF Chunk TLV's but the endpoint MUST not take any action on the TLV's parsed (since it has already performed these actions). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that the parameter type field upper two bits dictates that any parameter not understood should be skipped and reported to the sender with an Operational Error. If an Operational Error is received that indicates that the 'Stream Flow Limit Request' is not understood, the sender of the limit request MUST not send subsequent limit requests. The endpoint SHOULD also inform the upper level application that the peer endpoint does not support this feature. -- 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 (May 7, 2001) is 8389 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 section? 'RFC2026' on line 1110 looks like a reference -- Missing reference section? 'RFC2960' on line 1105 looks like a reference -- Missing reference section? 'RFC2119' on line 1113 looks like a reference -- Missing reference section? 'RFC2402' on line 1116 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. R. Stewart 2 INTERNET-DRAFT M. A. Ramalho 3 Cisco Systems 4 Q. Xie 5 Motorola 6 M. Tuexen 7 Siemens AG 8 I. Rytina 9 Ericsson 10 P. Conrad 11 Temple University 13 expires in six months May 7, 2001 15 SCTP Dynamic Addition of IP addresses 16 18 Status of This Memo 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are 22 working documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes extensions to the Stream Control 35 Transmission Protocol (SCTP) [RFC2960] that provide a method to 36 reconfigure IP address information on an existing association or 37 to request that a peer set a stream flow limit. 39 TABLE OF CONTENTS 40 1. Introduction............................................... 2 41 2. Conventions................................................ 3 42 3. Additional Chunks and Parameters........................... 3 43 3.1 New Chunk Types........................................... 3 44 3.1.1 Address Configuration Change Chunk (ASCONF)............ 3 45 3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK) 46 3.2 New Parameter Types....................................... 4 47 3.2.1 Add IP Address.......................................... 6 48 3.2.2 Delete IP Address....................................... 6 49 3.2.3 Stream Flow Limit Change................................ 7 50 3.2.4 Error Cause Indication.................................. 7 51 3.2.5 Set Primary IP Address.................................. 8 52 3.2.6 Success Indication...................................... 8 53 3.3 New Error Causes.......................................... 9 54 3.3.1 Error Cause: Request to Delete Last remaining IP Address 9 55 3.3.2 Error Cause: Operation Refused due to Resource Shortage.10 56 3.3.3 Error Cause: Request to Delete Source IP Address........10 57 4. Procedures.................................................11 58 4.1 ASCONF Chunk Procedures...................................11 59 4.1.1 Congestion Control of ASCONF Chunks.....................12 60 4.2 Upon reception of a ASCONF Chunk..........................13 61 4.3 General rules for address manipulation....................15 62 4.3.1 A special case for OOTB ABORT chunks....................17 63 4.4 Setting of the primary address............................18 64 4.5 Steam Flow Limit Procedures...............................18 65 4.5.1 Stream Receiver side procedures.........................19 66 4.5.2 Stream Sender side procedures...........................19 67 4.5.3 ULP considerations on the use of SCTP flow limit 68 facility................................................20 69 5. Security Considerations....................................20 70 6. IANA considerations........................................20 71 7. Authors' Addresses.........................................20 72 8. References.................................................21 74 1. Introduction 76 To extend the utility and application senarios of SCTP, this 77 document introduces optional extensions that provide SCTP with the 78 ability to reconfigure IP address information on an existing 79 association or to request the peer set a stream flow limit. 81 These extensions enable SCTP to be utilized in the following 82 applications: 84 - Dynamic IP addresses added and subtracted extension: For 85 computational or networking platforms that allow addition/removal of 86 physical interface cards this feature can provide: 88 A) a graceful method to add to the interfaces of an existing 89 association. For the multi-homed IPv6 case this feature will 90 allow renumbering of existing associations. 92 B) provides a method for an endpoint to request that its peer set 93 its primary destination address: This can be useful 94 when an address is about to be deleted. Or when an endpoint 95 has some predetermined knowledge about which is the 96 preferred address to receive SCTP packets upon. 98 - The SCTP flow limit extension: This extension enables the 99 ability to request a sender to set a limit to the 100 outstanding data sent to each stream. This in turn will 101 provide: 103 A) The ability to minimize the occurrence of a single stream 104 monopolizing all transport level resources (e.g. a_rwnd 105 "deadlock"). 107 B) The ability to dynamically change the stream buffering 108 limits as the application deems appropriate at any particular 109 instant. 111 2. Conventions 113 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 114 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 115 they appear in this document, are to be interpreted as described in 116 RFC 2119 [RFC2119]. 118 3. Additional Chunks and Parameters 120 This section describes the addition of two new chunks and, six 121 new parameters to allow: 123 - Dynamic addition of IP Addresses to an association. 124 - Dynamic deletion of IP Addresses to an association. 125 - A request to set the primary address the peer will 126 use when sending to an endpoint. 127 - The setting of stream flow limits. 129 Additionally, this section describes three new error causes that 130 support these new chunks and parameters. 132 3.1 New Chunk Types 134 This section defines two new Chunk types that will be used to 135 transfer the control information reliably. Table 1 illustrates the two 136 new chunk types. 138 Chunk Type Chunk Name 139 -------------------------------------------------------------- 140 11000001 Address/Stream Configuration Change Chunk (ASCONF) 141 10000000 Address Configuration Acknowledgment (ASCONF-ACK) 143 Table 1: Address/Stream Configuration Chunks 145 It should be noted that the ASCONF Chunk format requires the 146 receiver to report to the sender if it does not understand the 147 ASCONF chunk. This is accomplished by setting the upper bits in the 148 Chunk type as described in [RFC2960] section 3.2. Note that the 149 upper two bits in the ASCONF chunk are set to one. As defined in 150 [RFC2960] section 3.2, setting these upper bits in this manner will 151 cause the receiver that does not understand this chunk to skip the 152 chunk and continue processing, but report in an Operation Error 153 Chunk using the 'Unrecognized Chunk Type' cause of error. 155 3.1.1 Address Configuration Change Chunk (ASCONF) 157 This chunk is used to communicate to the remote endpoint one of the 158 configuration change requests that MUST be acknowledged. The 159 information carried in the ASCONF chunk is always in the form of a 160 Tag-Length-Value (TLV) as described in "3.2.1 161 Optional/Variable-length Parameter Format" in [RFC2960]. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type = 0xC1 | Chunk Flags | Chunk Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Serial Number | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | ASCONF-Request Correlation ID #1 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | ASCONF Parameter #1 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 \ \ 175 / .... / 176 \ \ 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | ASCONF-Request Correlation ID #N | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | ASCONF Parameter #N | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Serial Number : 32 bits (unsigned integer) 185 This value represents a Serial Number for the ASCONF Chunk. The 186 valid range of Serial Number is from 0 to 4294967295 (2**32 - 1). 187 Serial Numbers wrap back to 0 after reaching 4294967295. 189 ASCONF-Request Correlation ID: 32 bits (unsigned integer) 191 This is an opaque integer assigned by the sender to identify each 192 request parameter. It is in host byte order and is only meaningful 193 to the sender. The receiver of the ASCONF chunk will copy this 32 194 bit value into the ASCONF Correlation ID field of the 195 ASCONF-ACK. The sender of the ASCONF can use this same value in the 196 ASCONF-ACK to find which request the response is for. 198 ASCONF Parameter: TLV format 200 Each Address configuration change is represented by a TLV 201 parameter has defined in Section 3.2. One or more request 202 may be present in a ASCONF chunk. 204 3.1.2 Address Configuration Acknowledgment Chunk (ASCONF-ACK) 206 This chunk is used by the receiver of an ASCONF chunk to acknowledge 207 its reception. It carries zero or more results for any ASCONF 208 Parameters that were processed by the receiver. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type = 0x80 | Chunk Flags | Chunk Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Serial Number | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | ASCONF-Request Correlation ID #1 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | ASCONF Parameter Response#1 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 \ \ 222 / .... / 223 \ \ 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | ASCONF-Request Correlation ID #N | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | ASCONF Parameter Response#N | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Serial Number : 32 bits (unsigned integer) 232 This value represents the Serial Number for the ASCONF chunk that 233 was received to which this Chunk is acknowledgment of. This value is 234 copied from the received ASCONF chunk. 236 ASCONF-Request Correlation ID: 32 bits (unsigned integer) 238 This value is copied from the ASCONF Correlation ID received in the 239 ASCONF chunk. It is used by the receiver of the ASCONF-ACK to identify 240 which ASCONF parameter this response is associated with. 242 ASCONF Parameter Response : TLV format 244 The ASCONF Parameter Response is used in the ASCONF-ACK to report 245 status of ASCONF processing. By default, if a responding endpoint 246 does not include any Error cause a success is indicated. Thus a 247 sender of a ASCONF-ACK MAY indicate complete success of all TLV's in 248 a ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length 249 (set to 8) and the Serial Number. 251 3.2 New Parameter Types 253 The six new parameters added follow the format defined in section 254 3.2.1 of [RFC2960]. Table 2 describes the Parameters. 256 Address Configuration Parameters Parameter Type 257 ------------------------------------------------- 258 Add IP Address 49153 (0xC001) 259 Delete IP Address 49154 (0xC002) 260 Stream Flow limit Request 49155 (0xC003) 261 Error Cause Indication 49156 (0xC004) 262 Set Primary Address 49157 (0xC005) 263 Success report 49158 (0xC006) 265 Table 2: Address Configuration Parameters 267 3.2.1 Add IP Address 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type = 0xC001 | Length = Variable | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Address Parameter | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Address Parameter: TLV 279 This field contains an IPv4 or IPv6 address parameter as described 280 in 3.3.2.1 of RFC2960. The complete TLV is wrapped within this 281 parameter. It informs the receiver that the Address specified is to 282 be added to the existing association. 284 An example TLV requesting that the IPv4 address 10.1.1.1 should be 285 made the primary destination address would look as follows: 287 +--------------------------------+ 288 | Type=0xC001 | Length = 12 | 289 +--------------------------------+ 290 | Type=5 | Length = 8 | 291 +----------------+---------------+ 292 | Value=0x0a010101 | 293 +----------------+---------------+ 295 Valid Chunk Appearance 297 The Add IP Address parameter may only appear in the ASCONF chunk 298 type. 300 3.2.2 Delete IP Address 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type =0xC002 | Length = Variable | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Address Parameter | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Address Parameter: TLV 312 This field contains an IPv4 or IPv6 address parameter as described in 313 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 314 parameter. It informs the receiver that the Address specified is to 315 be removed from the existing association. 317 An example TLV deleting the IPv4 address 10.1.1.1 from an existing 318 association would look as follows: 320 +--------------------------------+ 321 | Type=0xC002 | Length = 12 | 322 +--------------------------------+ 323 | Type=5 | Length = 8 | 324 +----------------+---------------+ 325 | Value=0x0a010101 | 326 +----------------+---------------+ 328 Valid Chunk Appearance 330 The Delete IP Address parameter may only appear in the ASCONF chunk 331 type. 333 3.2.3 Stream Flow Limit Change 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type =0xC003 | Length = Variable | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Stream Number 1 | Flow Limit 1 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 \ / 343 / \ 344 \ / 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Stream Number N | Flow Limit N | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Stream Number n : 16 bits (unsigned integer) 351 This is the stream number that is requesting a limit be placed 352 on the sender based on the applications receive buffer sizes. 354 Flow Limit n : 16 bits (unsigned integer) 356 This is the limit the receiver is requesting (in bytes) as to the 357 maximum amount of data that the receiver may accept. Note that the 358 value 0 holds a special meaning described in Section 4.5. 360 Valid Chunk Appearance 362 The Stream Flow Limit Change parameter may only appear in the ASCONF 363 chunk type. 365 3.2.4 Error Cause Indication 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type = 0xC004 | Length = Variable | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Error Cause(s) or Return Info on Success | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 When reporting an error this response parameter is used to wrap 376 one or more standard error causes normally found within an SCTP 377 Operational Error or SCTP Abort (as defined in [RFC2960]). The 378 Error Cause(s) follow the format defined in section 3.3.10 of 379 [RFC2960]. 381 Valid Chunk Appearance 383 The Error Cause Indication parameter may only appear in the 384 ASCONF-ACK chunk type. 386 3.2.5 Set Primary IP Address 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type =0xC005 | Length = Variable | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Address Parameter | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Address Parameter: TLV 398 This field contains an IPv4 or IPv6 address parameter as described in 399 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 400 parameter. It requests the receiver to mark the specified address 401 as the primary address to send data to (see section 5.1.2 of 402 [RFC2960]). The receiver MAY mark this as its primary upon 403 receiving this request. 405 An example TLV requesting that the IPv4 address 10.1.1.1 be made the 406 primary destination address would look as follows: 408 +--------------------------------+ 409 | Type=0xC005 | Length = 12 | 410 +--------------------------------+ 411 | Type=5 | Length = 8 | 412 +----------------+---------------+ 413 | Value=0x0a010101 | 414 +----------------+---------------+ 416 Valid Chunk Appearance 418 The Set Primary IP Address parameter may appear in the ASCONF chunk, 419 the INIT, or the INIT-ACK chunk type. The inclusion of this parameter 420 in the INIT or INIT-ACK can be used to indicate an initial preference 421 of primary address. 423 3.2.6 Success Indication 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type = 0xC006 | Length = 4 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 By default if a responding endpoint does not report an error for any 431 requested TLV, a success is implicitly indicated. Thus a sender of a 432 ASCONF-ACK MAY indicate complete success of all TLV's in a ASCONF by 433 returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) 434 and the Serial Number. 436 The responding endpoint MAY also choose to explicitly report a 437 success for a requested TLV, by returning a success report ASCONF 438 Parameter Response. 440 Valid Chunk Appearance 442 The Success Indication parameter may only appear in the ASCONF-ACK 443 chunk type. 445 3.3 New Error Causes 447 Three new Error Causes are added to the SCTP Operational Errors, 448 primarily for use in the ASCONF-ACK chunk. 450 Cause Code 451 Value Cause Code 452 --------- ---------------- 453 12 Request to delete last remaining IP address. 454 13 Operation Refused due to resource shortage. 455 14 Request to delete source IP address. 457 Table 3: New Error Causes 459 3.3.1 Error Cause: Request to Delete Last remaining IP Address 461 Cause of error 462 --------------- 463 Request to delete last remaining IP address: The receiver of this 464 error sent a request to delete the last IP address from its 465 association with its peer. This error indicates that the request is 466 rejected. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Cause Code=12 | Cause Length=Variable | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 \ TLV-Copied-From-ASCONF / 474 / \ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 An example of a failed delete in an Error Cause TLV would look as 477 follows in the response ASCONF-ACK message: 479 +--------------------------------+ 480 | Type = 0xC004 | Length = 20 | 481 +--------------------------------+ 482 | Cause=12 | Length = 16 | 483 +----------------+---------------+ 484 | Type= 0xC002 | Length = 12 | 485 +----------------+---------------+ 486 | Type=5 | Length = 8 | 487 +----------------+---------------+ 488 | Value=0x0a010101 | 489 +----------------+---------------+ 491 3.3.2 Error Cause: Operation Refused due to Resource Shortage 493 Cause of error 494 --------------- 495 This error cause is used to report a failure by the receiver to 496 perform the requested operation due to a lack of resources. The 497 entire TLV that is refused is copied from the ASCONF-REQ into the 498 error cause. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Cause Code=13 | Cause Length=Variable | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 \ TLV-Copied-From-ASCONF / 506 / \ 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 An example of a failed addition in an Error Cause TLV would look as 510 follows in the response ASCONF-ACK message: 512 +--------------------------------+ 513 | Type = 0xC004 | Length = 20 | 514 +--------------------------------+ 515 | Cause=13 | Length = 16 | 516 +----------------+---------------+ 517 | Type=0xC001 | Length = 12 | 518 +--------------------------------+ 519 | Type=5 | Length = 8 | 520 +----------------+---------------+ 521 | Value=0x0a010101 | 522 +----------------+---------------+ 524 3.3.3 Error Cause: Request to Delete Source IP Address 526 Cause of error 527 --------------- 528 Request to delete source IP address: The receiver of this error sent 529 a request to delete the source IP address of the ASCONF 530 message. This error indicates that the request is rejected. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Cause Code=14 | Cause Length=Variable | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 \ TLV-Copied-From-ASCONF / 538 / \ 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 An example of a failed delete in an Error Cause TLV would look as 542 follows in the response ASCONF-ACK message: 544 +--------------------------------+ 545 | Type = 0xC004 | Length = 20 | 546 +--------------------------------+ 547 | Cause=14 | Length = 16 | 548 +----------------+---------------+ 549 | Type=0xC002 | Length = 12 | 550 +----------------+---------------+ 551 | Type=5 | Length = 8 | 552 +----------------+---------------+ 553 | Value=0x0a010101 | 554 +----------------+---------------+ 556 IMPLEMENTATION NOTE: It is unlikely that an endpoint would source 557 a packet from the address being deleted, unless the endpoint 558 does not do proper source address selection. 560 4. Procedures 562 This section will lay out the specific procedures for address/stream 563 configuration change chunk type and its processing. 565 4.1 ASCONF Chunk Procedures 567 When an endpoint has an ASCONF signaled change to be sent to the 568 remote endpoint it should do the following: 570 A1) Create a ASCONF Chunk as defined in section 3.1.1. The chunk 571 should contain all of the TLV('s) of information necessary to be 572 sent to the remote endpoint, and unique correlation identities for 573 each request. 575 A2) A serial number should be assigned to the Chunk. The serial 576 number should be a monotonically increasing number. All serial 577 numbers are defined to be initialized at the start of the 578 association to the same value as the Initial TSN. 580 A3) If no ASCONF chunk is outstanding (un-acknowledged) with the 581 remote peer AND there is less than cwnd bytes of user data 582 outstanding send the chunk. 584 A4) Start a T-4 RTO timer, using the RTO value of the selected 585 destination address (normally the primary path see [RFC2960] section 586 6.4 for details). 588 A5) When the ASCONF-ACK which acknowledges the serial number last 589 sent arrives, stop the T-4 RTO timer and clear the appropriate 590 association and destination error counters as defined in [RFC2960] 591 section 8.1 and 8.2. 593 A6) Process all of the TLV's within the ASCONF-ACK to find out 594 particular status information returned to the various requests that 595 were sent. Use the Correlation IDs to correlate the request and the 596 responses. 598 A7) If an error response is received to a TLV whose parameter type 599 all TLVs with no response before the failed TLV are considered 600 successful if not reported. All TLVs after the failed response are 601 considered unsuccessful unless a specific success indication is 602 present for the parameter. 604 A8) If there are no responses to TLVs whose parameter type begins 605 all TLVs not responded to are considered successful. 607 If the T-4 RTO timer expires the endpoint should do the following: 609 B1) Increment the error counter and perform path failure detection 610 on the appropriate destination address as defined in [RFC2960] 611 section 8.2. 613 B2) Increment the association error counter and perform endpoint 614 failure detection on the association as defined in [RFC2960] section 615 8.1. 617 B3) Back-off the destination address RTO timer to which the ASCONF 618 chunk was sent. 620 B4) Re-transmit the ASCONF chunk last sent and if possible choose an 621 alternate destination address (please refer to [RFC2960] section 622 6.4.1). An endpoint MUST NOT add new parameters to this chunk, it 623 MUST be the same (including its serial number) as the last ASCONF 624 sent. 626 B5) Restart the T-4 RTO timer. Note if a different destination is 627 selected, then the RTO used will be that of the new destination 628 address. 630 Note: That the the total number of re-transmissions is limited by B2 631 above. If the maximum is reached the association will fail and enter 632 a CLOSED state (see [RFC2960] section 6.4.1 for details). 634 4.1.1 Congestion Control of ASCONF Chunks 635 In defining the ASCONF chunk transfer procedures it is essential 636 that these transfers MUST NOT cause congestion within the network. 637 To achieve this we place these restrictions on the transfer of 638 ASCONF chunks: 640 R1) One and only one ASCONF Chunk MAY be in transit and 641 unacknowledged at any one time. If a sender, after sending a ASCONF 642 chunk, decides it needs to transfer another ASCONF Chunk, it MUST 643 wait until the ASCONF-ACK Chunk returns from the previous ASCONF 644 Chunk before sending a subsequent ASCONF. Note this restriction 645 binds each side, so at any time two ASCONF may be in-transit on any 646 given association (one sent from each endpoint). 648 R2) A ASCONF MUST NOT be sent if there is no room in the current 649 cwnd. If there is room in the cwnd of the destination network the 650 Chunk may be sent regardless of the value of rwnd. 652 R3) A ASCONF may be bundled with any other Chunk type except other 653 ASCONF chunks. 655 R4) A ASCONF-ACK may be bundled with any other Chunk type except 656 other ASCONF-ACK's. 658 R5) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP 659 state except ESTABLISHED. 661 R6) An ASCONF and respective ASCONF-ACK MUST NOT be larger than the 662 path MTU of the destination. 664 If the sender of a ASCONF chunk receives a Operational Error 665 indicating that the ASCONF chunk type is not understood, then the 666 sender MUST not send subsequent ASCONF chunks to the peer. The 667 endpoint should also inform the upper level application that the 668 peer endpoint does not support any of the extensions detailed in this 669 document. 671 4.2 Upon reception of a ASCONF Chunk. 673 When an endpoint receives a ASCONF chunk from the remote peer it 674 should perform the following: 676 C1) Compare the value of the serial number to the value the endpoint 677 stored in a new association variable 'Peer-Serial-Number'. This 678 value MUST be initialized to the Initial TSN value minus 1. 680 C2) If the value found in the serial number is equal to the the 681 ('Peer-Serial-Number' + 1), the endpoint should: 683 V1) Process the TLV's contained within the Chunk performing the 684 appropriate actions as indicated by each TLV type. The TLV's MUST 685 be processed in order within the Chunk. In other words if the sender 686 puts 3 TLV's in one chunk the first TLV (the one closest to the 687 Chunk Header) in the Chunk MUST be processed first. The next TLV in 688 the chunk (the middle one) would be processed second and finally the 689 last TLV in the Chunk would be processed last. 691 V2) In processing the chunk, the receiver should build a response 692 message with the appropriate error TLV's, as specified in the 693 Parameter type bits for any ASCONF Parameter it does not understand. 694 To indicate an unrecognized parameter, parameter type 8 as defined 695 in in the INIT-ACK in 3.3.3 of [RFC2960] should be used. It may also 696 use the response to carry rejections for other reasons such as 697 resource shortages etc using the Error Cause TLV and an appropriate 698 error condition. 700 Note: a positive response is implied if no error is indicated by the 701 sender. 703 V3) All error responses must copy the ASCONF-Request Correlation ID 704 field received in the ASCONF, from the TLV being responded to, into 705 the ASCONF-Request Correlation ID field. The ASCONF-Request 706 Correlation ID always precedes the request TLV. 708 V4) After processing the entire Chunk, it MUST send all TLV's for 709 both unrecognized parameters and any other status TLV's inside the 710 ASCONF-ACK chunk that acknowledges the arrival and processing of the 711 ASCONF Chunk. 713 V5) Update the 'Peer-Serial-Number' to the value found in the serial 714 number field. 716 C3) If the value found in the serial number is equal to the value 717 stored in the 'Peer-Serial-Number', the endpoint should: 719 X1) Parse the ASCONF Chunk TLV's but the endpoint MUST not take any 720 action on the TLV's parsed (since it has already performed these 721 actions). 723 X2) Build a response message with the appropriate response TLV's 724 as specified in the ASCONF Parameter type bits, for any 725 parameter it does not understand or could not process. 727 X3) After parsing the entire Chunk, it MUST send any response 728 TLV errors and status with a ASCONF-ACK chunk acknowledging the 729 arrival and processing of the ASCONF Chunk. 731 X4) The endpoint MUST NOT update its 'Peer-Serial-Number'. 733 IMPLEMENTATION NOTE: As an optimization a receiver may wish to save 734 the last ASCONF-ACK for some predetermined period of time and 735 instead of re-processing the ASCONF (with the same serial number) it 736 may just re-transmit the ASCONF-ACK. It may wish to use the arrival 737 of a new serial number to discard the previously saved ASCONF-ACK or 738 any other means it may choose to expire the saved ASCONF-ACK. 740 C4) Otherwise, the ASCONF chunk is discarded since it must be either 741 a stale packet or from an attacker. A receiver of such a packet MAY 742 log the event for security purposes. 744 C5) In both cases C2 and C3 the ASCONF-ACK MUST be sent back to the 745 source address contained in the IP header of the ASCONF being 746 responded to. 748 4.3 General rules for address manipulation 750 When building TLV parameters for the ASCONF Chunk that 751 will add or delete IP addresses the following rules should be 752 applied: 754 D1) When adding an IP address to an association, the IP address is 755 NOT considered fully added to the association until the ASCONF-ACK 756 arrives. This means that until such time as the ASCONF containing 757 the add is acknowledged the sender MUST NOT use the new IP address 758 as a source for ANY SCTP packet. The receiver of the add IP address 759 request may use the address has a destination immediately. 761 D2) After the ASCONF-ACK of an IP address add arrives, the endpoint 762 MAY begin using the added IP address as a source address. 764 D3) If an endpoint receives an Error Cause TLV indicating that the 765 IP address Add, IP address Deletion, or Set Primary IP Address 766 parameters was not understood, the endpoint MUST consider the 767 operation failed and MUST NOT attempt to send any subsequent Add, 768 Delete or Set Primary requests to the peer. 770 D4) When deleting an IP address from an association, the IP address 771 MUST be considered a valid destination address for the reception of 772 SCTP packets until the ASCONF-ACK arrives and MUST NOT be used has a 773 source address for any subsequent packets. This means that any 774 datagrams that arrive before the ASCONF-ACK destined to the IP address 775 being deleted MUST be considered part of the current 776 association. One special consideration is that ABORT chunks arriving 777 destined to the IP address being deleted MUST be ignored (see 778 Section 4.3.1 for further details). 780 D5) An endpoint MUST NOT delete its last remaining IP address from an 781 association. In other words if an endpoint is NOT multi-homed it 782 MUST NOT use the delete IP address. Or if an endpoint sends multiple 783 requests to delete IP addresses it MUST NOT delete all of the IP 784 addresses that the peer has listed for the requester. 786 D6) An endpoint MUST NOT set a source address for an SCTP packet 787 holding the ASCONF chunk to be the same as an address being deleted 788 by the ASCONF chunk. 790 D7) If a request is received to delete the last remaining IP address 791 of a peer endpoint, the receiver MUST send an Error Cause TLV with 792 the error cause set to the new error code 'Request to delete last IP 793 remaingin address'. The requested delete MUST NOT be performed or 794 acted upon, other than to send the ASCONF-ACK. 796 D8) If a request is received to delete an IP address which is also 797 the source address of the IP packet which contained the ASCONF 798 chunk, the receiver MUST reject this request. To reject the request 799 the receiver MUST send an Error Cause TLV set to the new error code 800 "Request to Delete Source IP Address" (unless Rule D5 has also been 801 violated, in which case the error code 'Request to delete last 802 remaining IP address' is sent). 804 D9) If an endpoint receives an ADD IP address request and does not 805 have the local resources to add this new address to the association, 806 it MUST return an Error Cause TLV set to the new error code 807 "Operation Refused due to Resource Shortage". 809 D10) If an endpoint receives an 'Out of Resource' error in response 810 to its request to ADD an IP address to an association, it must 811 either ABORT the association or not consider the address part of the 812 association. In other words if the endpoint does not ABORT the 813 association, it must consider the add attempt failed and NOT use 814 this address and treat SCTP packets destined to the address as Out 815 Of The Blue packets. 817 D11) When an endpoint receiving a ASCONF to add an IP address sends 818 an 'Out of Resource' in its response, it MUST also fail any 819 subsequent add or delete requests bundled in the ASCONF. The 820 receiver MUST NOT reject an ADD and then accept a subsequent DELETE 821 of an IP address in the same ASCONF chunk. In other words, once a 822 receiver begins failing any ADD or DELETE request, it must fail all 823 subsequent ADD or DELETE requests contained in that single ASCONF. 825 D12) When an endpoint receives a request to delete an IP address 826 that is the current primary address, it is an implementation 827 decision as to how that endpoint chooses the new primary address. 829 D13) When an endpoint receives a valid request to DELETE an IP 830 address the endpoint MUST consider the address no longer as part of 831 the association. It MUST NOT send SCTP packets for the association 832 to that address and it MUST treat subsequent packets received from 833 that address as Out Of The Blue. 835 During the time interval between sending out the ASCONF and 836 receiving the ASCONF-ACK it MAY be possible to receive DATA chunks 837 out of order. The following examples illustrate these problems: 839 Endpoint-A Endpoint-Z 840 ---------- ---------- 841 ASCONF[Add-IP:X]------------------------------> 842 /--ASCONF-ACK 843 / 844 /--------/---New DATA: 845 / / Destination 846 <-------------------/ / IP:X 847 / 848 <--------------------------/ 850 In the above example we see a new IP address (X) being added to 851 the Endpoint-A. However due to packet re-ordering in the network 852 a new DATA chunk is sent and arrives at Endpoint-A before 853 the ASCONF-ACK confirming the add of the address to the association. 855 A similar problem exists with the deletion of an IP address as 856 follows: 858 Endpoint-A Endpoint-Z 859 ---------- ---------- 860 /------------New DATA: 861 / Destination 862 / IP:X 863 ASCONF [DEL-IP:X]---------/----------------> 864 <-----------------/------------------ASCONF-ACK 865 / 866 / 867 <-------------/ 869 In this example we see a DATA chunk destined to the IP:X (which is 870 about to be deleted) arriving after the deletion is complete. 871 For the ADD case an endpoint SHOULD consider the newly adding IP 872 address valid for the association to receive data from during the 873 interval when awaiting the ASCONF-ACK. The endpoint MUST NOT source 874 data from this new address until the ASCONF-ACK arrives but it may 875 receive out of order data as illustrated and MUST NOT treat this 876 data as an OOTB datagram (please see [RFC2960] section 8.4). It MAY 877 drop the data silently or it MAY consider it part of the association 878 but it MUST NOT respond with an ABORT. 880 For the DELETE case, an endpoint MAY respond to the late arriving DATA 881 packet as an OOTB datagram or it MAY hold the deleting IP address for a 882 small period of time as still valid. If it treats the DATA packet as 883 an OOTB the peer will silently discard the ABORT (since by the time 884 the ABORT is sent the peer will have removed the IP address from this 885 association). If the endpoint elects to hold the IP address valid for 886 a period of time, it MUST NOT hold it valid longer than 2 RTO 887 intervals for the destination being removed. 889 4.3.1 A special case for OOTB ABORT chunks 891 Another case worth mentioning is illustrated below: 893 Endpoint-A Endpoint-Z 894 ---------- ---------- 896 New DATA:------------\ 897 Source IP:X \ 898 \ 899 ASCONF-REQ[DEL-IP:X]----\------------------> 900 \ /---------ASCONF-ACK 901 \ / 902 \----/-----------> OOTB 904 (Ignored <---------------------/-------------ABORT 905 by rule D4) / 906 <---------------------/ 908 For this case, during the deletion of an IP address, an 909 Abort MUST be ignored if the destination address of the 910 Abort message is that of the destination being deleted. 912 4.4 Setting of the primary address 914 A sender of this option may elect to send this combined with 915 a deletion or addition of an address. A sender SHOULD only send 916 a set primary request to an address that is already considered 917 part of the association. In other words if a sender combines 918 a set primary with an add of a new IP address the set primary 919 will be discarded unless the add request is to be processed 920 BEFORE the set primary (i.e. it preceeds the set primary). 922 A request to set primary MAY also appear in a INIT or INIT-ACK 923 chunk. This can give a hint to the peer endpoint as to which 924 of its addresses the sender of the INIT or INIT-ACK would like 925 to be used as the primary address. 927 The request to set an address as the primary path is an option the 928 receiver MAY perform. It is considered a hint to the receiver of the 929 best destination address to use in sending SCTP packets (in the 930 requester's view). It is possible that the receiver may have other 931 knowledge that it may act upon and NOT set the specified address as 932 primary. If a request arrives that asks the receiver to set an 933 address as primary that does not exist, the receiver should NOT 934 honor the request, leaving its existing primary address unchanged. 936 4.5 Steam Flow Limit Procedures 938 A stream in SCTP is an uni-directional logical channel established 939 from one to another associated SCTP endpoint, within which all user 940 messages are delivered in sequence except for those submitted to the 941 un-ordered delivery service which may arrive out of sequence. Since 942 each stream is uni-directional and no feedback mechanism exists to 943 limit a sender, it is possible for one unique stream to monopolize 944 all of the transport level receiver window space. The mechanism 945 defined here attempts to alleviate this problem by allowing the 946 receiver side to communicate to the sender a limit on how much 947 outstanding data may be sent within a particular stream. 949 The procedures defined here are broken down into two sides: 951 o The stream receiver side or peer requesting the limit. And, 953 o the stream sender side or peer that MUST honor the limit request. 955 The receivers side is mainly involved with sending the request to 956 the peer. The senders side is where the actual limitations and flow 957 limit will occur. Note in section 4.5.1 the stream receiver is the 958 endpoint that sends the ASCONF message, in section 4.5.2 the sender 959 side is the endpoint that receives the ASCONF message. 961 4.5.1 Stream Receiver side procedures 963 The receiver side SCTP makes decisions on stream flow limit based on 964 upper layer input. Normally the upper layer makes a request to limit 965 all or a subset of the active streams that send data to it via an 966 API interface. How this decision is made is outside the scope of 967 this document. 969 Anytime flow limits are made known to the SCTP endpoint by the 970 application, the receiver side SHOULD create a ASCONF Chunk and 971 attach to it one or more stream flow limits with there respective 972 stream number. If the receiver wishes to remove all limits 973 (previously placed on a particular stream) it may do so by placing 974 the special value '0' in the 'Flow Limit' field. Once acknowledged 975 by the peer endpoint the receiver should consider the limit in 976 place. 978 Note that the parameter type field upper two bits dictates that any 979 parameter not understood should be skipped and reported to the 980 sender with an Operational Error. If an Operational Error is 981 received that indicates that the 'Stream Flow Limit Request' is not 982 understood, the sender of the limit request MUST not send subsequent 983 limit requests. The endpoint SHOULD also inform the upper level 984 application that the peer endpoint does not support this feature. 986 4.5.2 Stream Sender side procedures 988 When a 'Stream Flow Limit Request' is received the sender MUST 989 record each flow limit with its appropriate stream. 991 After a limit is set on a stream the sender MUST obey the following 992 rules when sending to the peer on that stream: 994 S1) When the upper layer application attempts to send to the peer on 995 a stream, check the number of outstanding bytes sent to that stream 996 (those TSN's in queue to be sent, which the cumulative TSN 997 Acknowledgment has not passed, on this stream) versus the limit set 998 for that stream (The last received limit for this stream is 999 henceforth termed the current limit). 1001 S2) If the number of outstanding bytes is greater than or equal to 1002 the current limit, the SCTP endpoint MUST reject the request and NOT 1003 queue the data for transmit. Instead it SHOULD return an error to 1004 the sending application. 1006 S3) If the number of outstanding bytes is less than the current 1007 limit, validate that the data to be sent plus the number of 1008 outstanding bytes is smaller than or equal to this limit. If the 1009 user data plus the number of outstanding bytes is smaller than or 1010 equal to the current limit accept the data for transmit and queue 1011 the user data (increasing the number of outstanding data bytes on 1012 this stream). If the user data plus the number of outstanding bytes 1013 is larger than the current limit for this stream, the SCTP endpoint 1014 MUST reject the request and NOT queue the data for transmit and 1015 instead SHOULD return an error to the application. 1017 S4) Any time a stream limit is updated to the value of 0, consider 1018 this indication to mean no limit is in effect for this stream. 1020 4.5.3 ULP considerations on the use of SCTP flow limit facility 1022 The effect of rule S3 in section 4.5.2 places a maximum size upon a 1023 sender. Once a limit is in effect, if the sending Upper Layer 1024 Protocol (ULP) wishes to send a message that is larger than that 1025 permitted by the imposed stream limit, the ULP will need to provide 1026 a mechanism for fragmentation and re-assembly. 1028 This ULP mechanism is in addition to any fragmentation and 1029 re-assembly that may be provided by SCTP. It is the sole 1030 responsibility of the ULP to handle the case of a single 1031 user message being larger than the stream flow limit, if 1032 applicable. 1034 5. Security Considerations 1036 The ADD/DELETE of an IP address to an existing association does 1037 provide an additional mechanism by which existing associations can 1038 be hijacked. Where the attacker is able to intercept and or alter 1039 the packets sent and received in an association the use of this 1040 feature MAY increase the ease at which an association may be 1041 overtaken. This threat SHOULD be considered when deploying a version 1042 of SCTP that use this feature. The IP Authentication Header 1043 [RFC2402] SHOULD be used when the threat environment requires 1044 stronger integrity protections, but does not require 1045 confidentiality. It should be noted that in the base SCTP 1046 specification [RFC2960], if an attacker is able to intercept and or 1047 alter packets, even without this feature it is possible to hijack an 1048 existing association, please refer to Section 11 of RFC2960. 1050 6. IANA considerations 1052 This document defines the following new SCTP parameters, chunks 1053 and errors: 1055 - Two new Chunk Types, 1056 - Six Parameter Types, and 1057 - Three new SCTP Error Causes. 1059 7. Acknowledgements 1061 The authors wish to thank Jon Berger, John Loughney, Ivan Rodriguez, 1062 Marshall Rose, and Chip Sharp for their invaluable comments. 1064 8. Authors' Addresses 1065 Randall R. Stewart Tel: +1-815-477-2127 1066 Cisco Systems, Inc. EMail: rrs@cisco.com 1067 8745 W. Higgins Road, Suite 200 1068 Chicago, Ill 60631 1069 USA 1071 Micheal A. Ramalho Tel: +1-732-809-0188 1072 Cisco Systems, Inc. EMail: mramalho@cisco.com 1073 1802 Rue de la Porte 1074 Wall Township, NJ 0719-3784 1076 Qiaobing Xie Tel: +1-847-632-3028 1077 Motorola, Inc. EMail: qxie1@email.mot.com 1078 1501 W. Shure Drive, #2309 1079 Arlington Heights, IL 60004 1080 USA 1082 Michael Tuexen Tel: +49-89-722-47210 1083 SIEMENS AG EMail: Michael.Tuexen@icn.siemens.de 1084 Hofmannstr. 51 1085 81359 Munich 1086 Germany 1088 Ian Rytina Tel: +61-3-9301-6164 1089 Ericsson Australia EMail:ian.rytina@ericsson.com 1090 37/360 Elizabeth Street 1091 Melbourne, Victoria 3000 1092 Australia 1094 Phil Conrad Tel: +1-XXX-XXX-XXXX 1095 Netlab Research Group Email conrad@joda.cis.temple.edu 1096 Dept. Of Computer & 1097 Information Sciences 1098 Temple University 1099 1805 N Broad St. 1100 Philadelphia, PA 19122 1101 USA 1103 9. References 1105 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1106 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 1107 and, V. Paxson, "Stream Control Transmission Protocol," RFC 1108 2960, October 2000. 1110 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1111 3", RFC 2026, October 1996. 1113 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1114 Requirement Levels", BCP 14, RFC 2119, March 1997. 1116 [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", RFC 1117 2402, November 1998. 1119 This Internet Draft expires in 6 months from May, 2001