idnits 2.17.1 draft-ietf-sigtran-sctp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 46) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 11 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 4684 has weird spacing: '...ontains a par...' == Line 4706 has weird spacing: '...mber of unack...' == Line 4843 has weird spacing: '... set to indic...' == Line 4876 has weird spacing: '... set to indic...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: This value represents the dedicated buffer space, in number of bytes, the sender of the INIT has reserved in association with this window. During the life of the association this buffer space SHOULD not be lessened (i.e. dedicated buffers taken away from this association); however, an endpoint MAY change the value of a_rwnd it sends in SACK chunks. == 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 'SHOULD not' in this paragraph: This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association this buffer space SHOULD not be lessened (i.e. dedicated buffers taken away from this association). == 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: After that, the endpoint MUST not change its state, the T1-init timer shall be left running and the corresponding TCB MUST NOT be destroyed. The normal procedures for handling State Cookies when a TCB exists will resolve the duplicate INITs to a single association. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2522' is mentioned on line 5685, but not defined == Missing Reference: 'RFC2104' is mentioned on line 5679, but not defined == Missing Reference: 'RFC2373' is mentioned on line 1169, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) == Missing Reference: 'ASSOCIATE' is mentioned on line 2128, but not defined == Missing Reference: 'SHUTDOWN' is mentioned on line 2161, but not defined == Missing Reference: 'ABORT' is mentioned on line 2122, but not defined == Missing Reference: 'RFC1750' is mentioned on line 5673, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Missing Reference: 'ALLMAN99' is mentioned on line 5666, but not defined == Missing Reference: 'FALL96' is mentioned on line 5669, but not defined == Missing Reference: 'SAVAGE99' is mentioned on line 5688, but not defined == Missing Reference: 'RFC2196' is mentioned on line 5682, but not defined == Missing Reference: 'RFC1950' is mentioned on line 5762, but not defined == Unused Reference: 'RFC1700' is defined on line 5624, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) Summary: 19 errors (**), 0 flaws (~~), 23 warnings (==), 3 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 Q. Xie 3 Motorola 4 K. Morneault 5 C. Sharp 6 Cisco 7 H. J. Schwarzbauer 8 Siemens 9 T. Taylor 10 Nortel Networks 11 I. Rytina 12 Ericsson 13 M. Kalla 14 Telcordia 15 L. Zhang 16 UCLA 17 V. Paxson 18 ACIRI 20 expires in six months June 16,2000 22 Stream Control Transmission Protocol 23 25 Status of This Memo 27 This document is an Internet-Draft and is in full conformance with all 28 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes the Stream Control Transmission Protocol 42 (SCTP). SCTP is designed to transport PSTN signaling messages over 43 IP networks, but is capable of broader applications. 45 SCTP is a reliable transport protocol operating on top of a 46 connectionless packet network such as IP. It offers the following 47 services to its users: 49 -- acknowledged error-free non-duplicated transfer of user data, 50 -- data fragmentation to conform to discovered path MTU size, 51 -- sequenced delivery of user messages within multiple streams, 52 with an option for order-of-arrival delivery of individual 53 user messages, 54 -- optional bundling of multiple user messages into a single SCTP 55 packet, and 56 -- network-level fault tolerance through supporting of multi-homing 57 at either or both ends of an association. 59 The design of SCTP includes appropriate congestion avoidance behavior 60 and resistance to flooding and masquerade attacks. 62 TABLE OF CONTENTS 64 1. Introduction.................................................. 5 65 1.1 Motivation.................................................. 5 66 1.2 Architectural View of SCTP.................................. 6 67 1.3 Functional View of SCTP..................................... 6 68 1.3.1 Association Startup and Takedown........................ 7 69 1.3.2 Sequenced Delivery within Streams....................... 8 70 1.3.3 User Data Fragmentation................................. 8 71 1.3.4 Acknowledgement and Congestion Avoidance................ 8 72 1.3.5 Chunk Bundling ......................................... 8 73 1.3.6 Packet Validation....................................... 9 74 1.3.7 Path Management......................................... 9 75 1.4 Key Terms................................................... 10 76 1.5 Abbreviations............................................... 12 77 1.6 Serial Number Arithmetic.................................... 13 78 2. Conventions.................................................... 13 79 3. SCTP packet Format............................................ 13 80 3.1 SCTP Common Header Field Descriptions....................... 14 81 3.2 Chunk Field Descriptions.................................... 15 82 3.2.1 Optional/Variable-length Parameter Format............... 17 83 3.3 SCTP Chunk Definitions...................................... 18 84 3.3.1 Payload Data (DATA)..................................... 18 85 3.3.2 Initiation (INIT)....................................... 20 86 3.3.2.1 Optional or Variable Length Parameters.............. 23 87 3.3.3 Initiation Acknowledgement (INIT ACK)................... 25 88 3.3.3.1 Optional or Variable Length Parameters.............. 28 89 3.3.4 Selective Acknowledgement (SACK)........................ 28 90 3.3.5 Heartbeat Request (HEARTBEAT)........................... 31 91 3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 32 92 3.3.7 Abort Association (ABORT)............................... 33 93 3.3.8 Shutdown Association (SHUTDOWN)......................... 34 94 3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 34 95 3.3.10 Operation Error (ERROR)................................ 35 96 3.3.10.1 Invalid Stream Identifier.......................... 36 97 3.3.10.2 Missing Mandatory Parameter........................ 36 98 3.3.10.3 Stale Cookie Error................................. 37 99 3.3.10.4 Out of Resource.................................... 37 100 3.3.10.5 Unresolvable Address............................... 38 101 3.3.10.6 Unrecognized Chunk Type............................ 38 102 3.3.10.7 Invalid Mandatory Parameter........................ 38 103 3.3.10.8 Unrecognized Parameters............................ 39 104 3.3.10.9 No User Data....................................... 39 105 3.3.10.10 Cookie Received While Shutting Down............... 39 106 3.3.11 Cookie Echo (COOKIE ECHO).............................. 40 107 3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 40 108 3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 41 109 4. SCTP Association State Diagram................................. 41 110 5. Association Initialization..................................... 44 111 5.1 Normal Establishment of an Association...................... 45 112 5.1.1 Handle Stream Parameters................................ 46 113 5.1.2 Handle Address Parameters............................... 47 114 5.1.3 Generating State Cookie................................. 48 115 5.1.4 State Cookie Processing................................. 49 116 5.1.5 State Cookie Authentication............................. 49 117 5.1.6 An Example of Normal Association Establishment.......... 50 118 5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO, 119 and COOKIE ACK.............................................. 51 120 5.2.1 Handle Duplicate INIT in COOKIE-WAIT 121 or COOKIE-ECHOED States................................. 52 122 5.2.2 Unexpected INIT in States Other than CLOSED, 123 COOKIE-ECHOED and COOKIE-WAIT........................... 52 124 5.2.3 Unexpected INIT ACK..................................... 53 125 5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 53 126 5.2.5 Handle Duplicate COOKIE ACK............................. 55 127 5.2.6 Handle Stale COOKIE Error............................... 55 129 5.3 Other Initialization Issues................................. 56 130 5.3.1 Selection of Tag Value.................................. 56 131 6. User Data Transfer............................................. 56 132 6.1 Transmission of DATA Chunks................................. 57 133 6.2 Acknowledgement on Reception of DATA Chunks................. 59 134 6.2.1 Tracking Peer's Receive Buffer Space.................... 61 135 6.3 Management Retransmission Timer............................. 62 136 6.3.1 RTO Calculation......................................... 63 137 6.3.2 Retransmission Timer Rules.............................. 64 138 6.3.3 Handle T3-rtx Expiration................................ 65 139 6.4 Multi-homed SCTP Endpoints.................................. 66 140 6.4.1 Failover from Inactive Destination Address.............. 66 141 6.5 Stream Identifier and Stream Sequence Number................ 67 142 6.6 Ordered and Unordered Delivery.............................. 67 143 6.7 Report Gaps in Received DATA TSNs........................... 68 144 6.8 Adler-32 Checksum Calculation............................... 69 145 6.9 Fragmentation............................................... 70 146 6.10 Bundling .................................................. 71 147 7. Congestion Control .......................................... 71 148 7.1 SCTP Differences from TCP Congestion Control................ 72 149 7.2 SCTP Slow-Start and Congestion Avoidance.................... 73 150 7.2.1 Slow-Start.............................................. 73 151 7.2.2 Congestion Avoidance.................................... 74 152 7.2.3 Congestion Control...................................... 75 153 7.2.4 Fast Retransmit on Gap Reports.......................... 75 154 7.3 Path MTU Discovery.......................................... 76 155 8. Fault Management.............................................. 77 156 8.1 Endpoint Failure Detection.................................. 77 157 8.2 Path Failure Detection...................................... 78 158 8.3 Path Heartbeat.............................................. 78 159 8.4 Handle "Out of the blue" Packets............................ 80 160 8.5 Verification Tag............................................ 81 161 8.5.1 Exceptions in Verification Tag Rules.................... 81 162 9. Termination of Association..................................... 82 163 9.1 Abort of an Association..................................... 82 164 9.2 Shutdown of an Association.................................. 83 165 10. Interface with Upper Layer.................................... 85 166 10.1 ULP-to-SCTP................................................ 85 167 10.2 SCTP-to-ULP................................................ 94 168 11. Security Considerations....................................... 97 169 11.1 Security Objectives........................................ 97 170 11.2 SCTP Responses To Potential Threats........................ 97 171 11.2.1 Countering Insider Attacks............................. 97 172 11.2.2 Protecting against Data Corruption in the Network...... 97 173 11.2.3 Protecting Confidentiality............................. 98 174 11.2.4 Protecting against Blind Denial of Service Attacks..... 98 175 11.2.4.1 Flooding........................................... 98 176 11.2.4.2 Masquerade......................................... 99 177 11.2.4.3 Improper Monopolization of Services................100 178 11.3 Protection against Fraud and Repudiation...................100 179 12. Recommended Transmission Control Block (TCB) Parameters.......101 180 12.1 Parameters necessary for the SCTP instance.................101 181 12.2 Parameters necessary per association (i.e. the TCB)........101 182 12.3 Per Transport Address Data.................................103 183 12.4 General Parameters Needed..................................104 184 13. IANA Consideration............................................104 185 13.1 IETF-defined Chunk Extension...............................104 186 13.2 IETF-defined Additional Error Causes.......................105 187 13.3 Payload Protocol Identifiers...............................105 188 14. Suggested SCTP Protocol Parameter Values......................106 189 15. Acknowledgements..............................................106 190 16. Authors' Addresses............................................106 191 17. References....................................................107 192 18. Bibliography..................................................108 193 Appendix A .......................................................109 194 Appendix B .......................................................110 196 1. Introduction 198 This section explains the reasoning behind the development of the 199 Stream Control Transmission Protocol (SCTP), the services it offers, 200 and the basic concepts needed to understand the detailed description 201 of the protocol. 203 1.1 Motivation 205 TCP [RFC793] has performed immense service as the primary means of 206 reliable data transfer in IP networks. However, an increasing number of 207 recent applications have found TCP too limiting, and have incorporated 208 their own reliable data transfer protocol on top of UDP [RFC768]. The 209 limitations which users have wished to bypass include the following: 211 -- TCP provides both reliable data transfer and strict order- 212 of-transmission delivery of data. Some applications need reliable 213 transfer without sequence maintenance, while others would be 214 satisfied with partial ordering of the data. In both of these 215 cases the head-of-line blocking offered by TCP causes 216 unnecessary delay. 218 -- The stream-oriented nature of TCP is often an inconvenience. 219 Applications must add their own record marking to delineate 220 their messages, and must make explicit use of the push facility 221 to ensure that a complete message is transferred in a 222 reasonable time. 224 -- The limited scope of TCP sockets complicates the task of 225 providing highly-available data transfer capability using 226 multi-homed hosts. 228 -- TCP is relatively vulnerable to denial of service attacks, 229 such as SYN attacks. 231 Transport of PSTN signaling across the IP network is an application 232 for which all of these limitations of TCP are relevant. While this 233 application directly motivated the development of SCTP, other 234 applications may find SCTP a good match to their requirements. 236 1.2 Architectural View of SCTP 238 SCTP is viewed as a layer between the SCTP user application ("SCTP 239 user" for short) and a connectionless packet network service such 240 as IP. The remainder of this document assumes SCTP runs on top of IP. 241 The basic service offered by SCTP is the reliable transfer of 242 user messages between peer SCTP users. It performs this service 243 within the context of an association between two SCTP endpoints. 244 Section 10 of this document sketches the API which should exist at the 245 boundary between the SCTP and the SCTP user layers. 247 SCTP is connection-oriented in nature, but the SCTP association is a 248 broader concept than the TCP connection. SCTP provides the means for 249 each SCTP endpoint (Section 1.4) to provide the other endpoint (during 250 association startup) with a list of transport addresses (i.e., multiple 251 IP addresses in combination with an SCTP port) through which that 252 endpoint can be reached and from which it will originate SCTP packets. 253 The association spans transfers over all of the possible 254 source/destination combinations which may be generated from each 255 endpoint's lists. 257 _____________ _____________ 258 | SCTP User | | SCTP User | 259 | Application | | Application | 260 |-------------| |-------------| 261 | SCTP | | SCTP | 262 | Transport | | Transport | 263 | Service | | Service | 264 |-------------| |-------------| 265 | |One or more ---- One or more| | 266 | IP Network |IP address \/ IP address| IP Network | 267 | Service |appearances /\ appearances| Service | 268 |_____________| ---- |_____________| 270 SCTP Node A |<-------- Network transport ------->| SCTP Node B 272 Figure 1: An SCTP Association 274 1.3 Functional View of SCTP 276 The SCTP transport service can be decomposed into a number of 277 functions. These are depicted in Figure 2 and explained in the 278 remainder of this section. 280 SCTP User Application 282 ..----------------------------------------------------- 283 .. _____________ ____________________ 284 | | | Sequenced delivery | 285 | Association | | within streams | 286 | | |____________________| 287 | startup | 288 ..| | ____________________________ 289 | and | | User Data Fragmentation | 290 | | |____________________________| 291 | takedown | 292 ..| | ____________________________ 293 | | | Acknowledgement | 294 | | | and | 295 | | | Congestion Avoidance | 296 ..| | |____________________________| 297 | | 298 | | ____________________________ 299 | | | Chunk Bundling | 300 | | |____________________________| 301 | | 302 | | ________________________________ 303 | | | Packet Validation | 304 | | |________________________________| 305 | | 306 | | ________________________________ 307 | | | Path Management | 308 |______________ |________________________________| 310 Figure 2: Functional View of the SCTP Transport Service 312 1.3.1 Association Startup and Takedown 314 An association is initiated by a request from the SCTP user (see the 315 description of the ASSOCIATE (or SEND) primitive in Section 10). 317 A cookie mechanism, similar to one described by Karn and Simpson in 318 [RFC2522], is employed during the initialization to provide protection 319 against security attacks. The cookie mechanism uses a four-way 320 handshake, the last two legs of which are allowed to carry user 321 data for fast setup. The startup sequence is described in Section 5 of 322 this document. 324 SCTP provides for graceful close (i.e., shutdown) of an active 325 association on request from the SCTP user. See the description of the 326 SHUTDOWN primitive in Section 10. SCTP also allows ungraceful close 327 (i.e., abort), either on request from the user (ABORT primitive) or as 328 a result of an error condition detected within the SCTP layer. Section 329 9 describes both the graceful and the ungraceful close procedures. 331 SCTP does not support a half-open state (like TCP) wherein one side 332 may continue sending data while the other end is closed. When either 333 endpoint performs a shutdown, the association on each peer will stop 334 accepting new data from its user and only deliver data in queue at the 335 time of the graceful close (see Section 9). 337 1.3.2 Sequenced Delivery within Streams 339 The term "stream" is used in SCTP to refer to a sequence of user 340 messages that are to be delivered to the upper-layer protocol in order 341 with respect to other messages within the same stream. This is in 342 contrast to its usage in TCP, where it refers to a sequence of bytes 343 (in this document a byte is assumed to be eight bits). 345 The SCTP user can specify at association startup time the number of 346 streams to be supported by the association. This number is negotiated 347 with the remote end (see Section 5.1.1). User messages are associated 348 with stream numbers (SEND, RECEIVE primitives, Section 10). Internally, 349 SCTP assigns a stream sequence number to each message passed to it by 350 the SCTP user. On the receiving side, SCTP ensures that messages are 351 delivered to the SCTP user in sequence within a given stream. However, 352 while one stream may be blocked waiting for the next in-sequence user 353 message, delivery from other streams may proceed. 355 SCTP provides a mechanism for bypassing the sequenced delivery 356 service. User messages sent using this mechanism are delivered to the 357 SCTP user as soon as they are received. 359 1.3.3 User Data Fragmentation 361 When needed, SCTP fragments user messages to ensure that the SCTP 362 packet passed to the lower layer conforms to the path MTU. On receipt, 363 fragments are reassembled into complete messages before being passed to 364 the SCTP user. 366 1.3.4 Acknowledgement and Congestion Avoidance 368 SCTP assigns a Transmission Sequence Number (TSN) to each user data 369 fragment or unfragmented message. The TSN is independent of any 370 stream sequence number assigned at the stream level. The receiving end 371 acknowledges all TSNs received, even if there are gaps in the 372 sequence. In this way, reliable delivery is kept functionally separate 373 from sequenced stream delivery. 375 The acknowledgement and congestion avoidance function is responsible 376 for packet retransmission when timely acknowledgement has not been 377 received. Packet retransmission is conditioned by congestion 378 avoidance procedures similar to those used for TCP. See Sections 6 379 and 7 for a detailed description of the protocol procedures associated 380 with this function. 382 1.3.5 Chunk Bundling 384 As described in Section 3, the SCTP packet as delivered to the lower 385 layer consists of a common header followed by one or more chunks. Each 386 chunk may contain either user data or SCTP control information. The 387 SCTP user has the option to request bundling of more than one user 388 messages into a single SCTP packet. The chunk bundling function of SCTP 389 is responsible for assembly of the complete SCTP packet and its 390 disassembly at the receiving end. 392 During times of congestion an SCTP implementation MAY still perform 393 bundling even if the user has requested that SCTP not bundle. The 394 user's disabling of bundling only affects SCTP implementations that may 395 delay a small period of time before transmission (to attempt to 396 encourage bundling). When the user layer disables bundling, this small 397 delay is prohibited but not bundling that is performed during 398 congestion or retransmission. 400 1.3.6 Packet Validation 402 A mandatory Verification Tag field and a 32 bit checksum field (see 403 Appendix B for a description of the Adler-32 checksum) are included in 404 the SCTP common header. The Verification Tag value is chosen by each 405 end of the association during association startup. Packets received 406 without the expected Verification Tag value are discarded, as a 407 protection against blind masquerade attacks and against stale SCTP 408 packets from a previous association. The Adler-32 checksum should be 409 set by the sender of each SCTP packet to provide additional protection 410 against data corruption in the network. The receiver of an SCTP packet 411 with an invalid Adler-32 checksum silently discards the packet. 413 1.3.7 Path Management 415 The sending SCTP user is able to manipulate the set of transport 416 addresses used as destinations for SCTP packets through the 417 primitives described in Section 10. The SCTP path management function 418 chooses the destination transport address for each outgoing SCTP 419 packet based on the SCTP user's instructions and the currently 420 perceived reachability status of the eligible destination set. 421 The path management function monitors reachability through heartbeats 422 when other packet traffic is inadequate to provide this information 423 and advises the SCTP user when reachability of any far-end transport 424 address changes. The path management function is also responsible for 425 reporting the eligible set of local transport addresses to the far end 426 during association startup, and for reporting the transport addresses 427 returned from the far end to the SCTP user. 429 At association start-up, a primary path is defined for each SCTP 430 endpoint, and is used for normal sending of SCTP packets. 432 On the receiving end, the path management is responsible for verifying 433 the existence of a valid SCTP association to which the inbound SCTP 434 packet belongs before passing it for further processing. 436 Note: Path Management and Packet Validation are done at the 437 same time, so although described separately above, in reality they 438 cannot be performed as separate items. 440 1.4 Key Terms 442 Some of the language used to describe SCTP has been introduced in the 443 previous sections. This section provides a consolidated list of the key 444 terms and their definitions. 446 o Active destination transport address: A transport address on a peer 447 endpoint which a transmitting endpoint considers available for 448 receiving user messages. 450 o Bundling: An optional multiplexing operation, whereby more than one 451 user message may be carried in the same SCTP packet. Each user 452 message occupies its own DATA chunk. 454 o Chunk: A unit of information within an SCTP packet, consisting of 455 a chunk header and chunk-specific content. 457 o Congestion Window (cwnd): An SCTP variable that limits the data, in 458 number of bytes, a sender can send to a particular destination 459 transport address before receiving an acknowledgement. 461 o Cumulative TSN Ack Point: The TSN of the last DATA chunk 462 acknowledged via the Cumulative TSN Ack field of a SACK. 464 o Idle destination address: An address that has not had user messages 465 sent to it within some length of time, normally the HEARTBEAT 466 interval or greater. 468 o Inactive destination transport address: An address which is 469 considered inactive due to errors and unavailable to transport user 470 messages. 472 o Message = user message: Data submitted to SCTP by the Upper Layer 473 Protocol (ULP). 475 o Message Authentication Code (MAC): An integrity check mechanism 476 based on cryptographic hash functions using a secret key. 477 Typically, message authentication codes are used between two 478 parties that share a secret key in order to validate information 479 transmitted between these parties. In SCTP it is used by an 480 endpoint to validate the State Cookie information that is 481 returned from the peer in the COOKIE ECHO chunk. The term "MAC" 482 has different meanings in different contexts. SCTP uses this 483 term with the same meaning as in [RFC2104]. 485 o Network Byte Order: Most significant byte first, a.k.a., Big Endian. 487 o Ordered Message: A user message that is delivered in order with 488 respect to all previous user messages sent within the stream the 489 message was sent on. 491 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 492 DATA chunk) that has been sent by the endpoint but for which it has 493 not yet received an acknowledgement. 495 o Path: The route taken by the SCTP packets sent by one SCTP 496 endpoint to a specific destination transport address of its peer 497 SCTP endpoint. Sending to different destination transport 498 addresses does not necessarily guarantee getting separate paths. 500 o Primary Path: The primary path is the destination and 501 source address that will be put into a packet outbound 502 to the peer endpoint by default. The definition includes 503 the source address since an implementation MAY wish to 504 specify both destination and source address to better 505 control the return path taken by reply chunks and on which 506 interface the packet is transmitted when the data sender 507 is multi-homed. 509 o Receiver Window (rwnd): An SCTP variable a data sender uses to store 510 the most recently calculated receiver window of its peer, in number 511 of bytes. This gives the sender an indication of the space available 512 in the receiver's inbound buffer. 514 o SCTP association: A protocol relationship between SCTP endpoints, 515 composed of the two SCTP endpoints and protocol state information 516 including Verification Tags and the currently active set of 517 Transmission Sequence Numbers (TSNs), etc. An association can be 518 uniquely identified by the transport addresses used by the endpoints 519 in the association. Two SCTP endpoints MUST NOT have more than one 520 SCTP association between them at any given time. 522 o SCTP endpoint: The logical sender/receiver of SCTP packets. On a 523 multi-homed host, an SCTP endpoint is represented to its peers as a 524 combination of a set of eligible destination transport addresses to 525 which SCTP packets can be sent and a set of eligible source 526 transport addresses from which SCTP packets can be received. 527 All transport addresses used by an SCTP endpoint must use the 528 same port number, but can use multiple IP addresses. 530 o SCTP packet (or packet): The unit of data delivery across the 531 interface between SCTP and the connectionless packet network (e.g., 532 IP). An SCTP packet includes the common SCTP header, possible SCTP 533 control chunks, and user data encapsulated within SCTP DATA chunks. 535 o SCTP user application (SCTP user): The logical higher-layer 536 application entity which uses the services of SCTP, also called 537 the Upper-layer Protocol (ULP). 539 o Slow Start Threshold (ssthresh): An SCTP variable. This is the 540 threshold which the endpoint will use to determine whether to 541 perform slow start or congestion avoidance on a particular 542 destination transport address. Ssthresh is in number of bytes. 544 o Stream: A uni-directional logical channel established from one to 545 another associated SCTP endpoint, within which all user messages 546 are delivered in sequence except for those submitted to the 547 unordered delivery service. 549 Note: The relationship between stream numbers in opposite 550 directions is strictly a matter of how the applications use 551 them. It is the responsibility of the SCTP user to create and 552 manage these correlations if they are so desired. 554 o Stream Sequence Number: A 16-bit sequence number used internally by 555 SCTP to assure sequenced delivery of the user messages within a 556 given stream. One stream sequence number is attached to each user 557 message. 559 o Transmission Control Block (TCB): An internal data structure 560 created by an SCTP endpoint for each of its existing SCTP 561 associations to other SCTP endpoints. TCB contains all the status 562 and operational information for the endpoint to maintain and manage 563 the corresponding association. 565 o Transmission Sequence Number (TSN): A 32-bit sequence number used 566 internally by SCTP. One TSN is attached to each chunk containing 567 user data to permit the receiving SCTP endpoint to acknowledge its 568 receipt and detect duplicate deliveries. 570 o Transport address: A Transport Address is traditionally defined by 571 Network Layer address, Transport Layer protocol and Transport Layer 572 port number. In the case of SCTP running over IP, a transport 573 address is defined by the combination of an IP address and an SCTP 574 port number (where SCTP is the Transport protocol). 576 o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated 577 DATA chunk) which has been received by the endpoint but for which an 578 acknowledgement has not yet been sent. Or in the opposite case, 579 for a packet that has been sent but no acknowledgement has 580 been received. 582 o Unordered Message: Unordered messages are "unordered" with respect 583 to any other message, this includes both other unordered messages 584 as well as other ordered messages. Unordered message might be 585 delivered prior to or later than ordered messages sent on the 586 same stream. 588 o User message: The unit of data delivery across the interface 589 between SCTP and its user. 591 1.5. Abbreviations 593 MAC - Message Authentication Code [RFC2104] 595 RTO - Retransmission Time-out 597 RTT - Round-trip Time 599 RTTVAR - Round-trip Time Variation 600 SCTP - Stream Control Transmission Protocol 602 SRTT - Smoothed RTT 604 TCB - Transmission Control Block 606 TLV - Type-Length-Value Coding Format 608 TSN - Transmission Sequence Number 610 ULP - Upper-layer Protocol 612 1.6 Serial Number Arithmetic 614 It is essential to remember that the actual Transmission Sequence 615 Number space is finite, though very large. This space ranges from 0 to 616 2**32 - 1. Since the space is finite, all arithmetic dealing with 617 Transmission Sequence Numbers must be performed modulo 2**32. This 618 unsigned Arithmetic preserves the relationship of sequence numbers as 619 they cycle From 2**32 - 1 to 0 again. There are some subtleties to 620 computer modulo arithmetic, so great care should be taken in 621 programming the comparison of such values. When referring to TSNs, the 622 symbol "=<" means "less than or equal"(modulo 2**32). 624 Comparisons and arithmetic on TSNs in this document SHOULD use Serial 625 Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32. 627 An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more 628 than 2**31 - 1 above the beginning TSN of its current send window. 629 Doing so will cause problems in comparing TSNs. 631 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 632 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 633 2*32 - 1 is TSN = 0. 635 Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number 636 Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. 638 All other arithmetic and comparisons in this document uses normal 639 arithmetic. 641 2. Conventions 643 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 644 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 645 they appear in this document, are to be interpreted as described in 646 [RFC2119]. 648 3. SCTP packet Format 650 An SCTP packet is composed of a common header and chunks. A chunk 651 contains either control information or user data. 653 The SCTP packet format is shown below: 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Common Header | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Chunk #1 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | ... | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Chunk #n | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Multiple chunks can be bundled into one SCTP packet up to 668 the MTU size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE 669 chunks. These chunks MUST NOT be bundled with any other chunk in a 670 packet. See Section 6.10 for more details on chunk bundling. 672 If a user data message doesn't fit into one SCTP packet it can be 673 fragmented into multiple chunks using the procedure defined in 674 Section 6.9. 676 All integer fields in an SCTP packet MUST be transmitted in 677 network byte order, unless otherwise stated. 679 3.1 SCTP Common Header Field Descriptions 681 SCTP Common Header Format 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Source Port Number | Destination Port Number | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Verification Tag | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Checksum | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Source Port Number: 16 bits (unsigned integer) 695 This is the SCTP senders port number. It can be used by the 696 receiver in combination with the source IP address, the 697 SCTP destination port and possibly the destination IP address 698 to identify the association to which this packet belongs. 700 Destination Port Number: 16 bits (unsigned integer) 702 This is the SCTP port number to which this packet is destined. The 703 receiving host will use this port number to de-multiplex the 704 SCTP packet to the correct receiving endpoint/application. 706 Verification Tag: 32 bits (unsigned integer) 708 The receiver of this packet uses the Verification Tag to validate 709 the sender of this SCTP packet. On transmit, the value of this 710 Verification Tag MUST be set to the value of the Initiate Tag 711 received from the peer endpoint during the association 712 initialization, with the following exceptions: 713 - A packet containing an INIT chunk MUST have a zero 714 Verification Tag. 715 - A packet containing a SHUTDOWN-COMPLETE chunk with the T-bit 716 set MUST have the Verification Tag copied from the packet 717 with the SHUTDOWN-ACK chunk. 718 - A packet containing an ABORT chunk may have the verification 719 tag copied from the packet which caused the ABORT to be sent. 720 For details see Section 8.4 and 8.5. 722 An INIT chunk MUST be the only chunk in the SCTP packet carrying it. 724 Checksum: 32 bits (unsigned integer) 726 This field contains the checksum of this SCTP packet. Its calculation 727 is discussed in Section 6.8. SCTP uses the Adler-32 algorithm as 728 described in Appendix B for calculating the checksum 730 3.2 Chunk Field Descriptions 732 The figure below illustrates the field format for the chunks to be 733 transmitted in the SCTP packet. Each chunk is formatted with a Chunk 734 Type field, a chunk-specific Flag field, a Chunk Length field, and a 735 Value field. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Chunk Type | Chunk Flags | Chunk Length | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 \ \ 743 / Chunk Value / 744 \ \ 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Chunk Type: 8 bits (unsigned integer) 749 This field identifies the type of information contained in the Chunk 750 Value field. It takes a value from 0 to 254. The value of 255 is 751 reserved for future use as an extension field. 753 The values of Chunk Types are defined as follows: 755 ID Value Chunk Type 756 ----- ---------- 757 0 - Payload Data (DATA) 758 1 - Initiation (INIT) 759 2 - Initiation Acknowledgement (INIT ACK) 760 3 - Selective Acknowledgement (SACK) 761 4 - Heartbeat Request (HEARTBEAT) 762 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 763 6 - Abort (ABORT) 764 7 - Shutdown (SHUTDOWN) 765 8 - Shutdown Acknowledgement (SHUTDOWN ACK) 766 9 - Operation Error (ERROR) 767 10 - State Cookie (COOKIE ECHO) 768 11 - Cookie Acknowledgement (COOKIE ACK) 769 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 770 13 - Reserved for Congestion Window Reduced (CWR) 771 14 - Shutdown Complete (SHUTDOWN COMPLETE) 772 15 to 63 - reserved by IETF 773 63 - IETF-defined Chunk Extensions 774 64 to 126 - reserved by IETF 775 127 - IETF-defined Chunk Extensions 776 128 to 190 - reserved by IETF 777 191 - IETF-defined Chunk Extensions 778 192 to 254 - reserved by IETF 779 255 - IETF-defined Chunk Extensions 781 Chunk Types are encoded such that the highest-order two bits 782 specify the action that must be taken if the processing 783 endpoint does not recognize the Chunk Type. 785 00 - Stop processing this SCTP packet and discard it, do NOT process any 786 further chunks within it. 788 01 - Stop processing this SCTP packet and discard it, do NOT process any 789 further chunks within it, and report in an Operation Error Chunk 790 using the 'Unrecognized Chunk Type' cause of error. 792 10 - Skip this chunk and continue processing. 794 11 - Skip this chunk and continue processing, but report in an 795 Operation Error Chunk using the 'Unrecognized Chunk Type' 796 cause of error. 798 Note: The ECNE and CWR chunk types are reserved for future use of 799 Explicit Congestion Notification (ECN). 801 Chunk Flags: 8 bits 803 The usage of these bits depends on the chunk type as given by the 804 Chunk Type. Unless otherwise specified, they are set to zero on 805 transmit and are ignored on receipt. 807 Chunk Length: 16 bits (unsigned integer) 808 This value represents the size of the chunk in bytes including the 809 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 810 Therefore, if the Chunk Value field is zero-length, the Length 811 field will be set to 4. The Chunk Length field does not count 812 any padding. 814 Chunk Value: variable length 816 The Chunk Value field contains the actual information to be 817 transferred in the chunk. The usage and format of this field is 818 dependent on the Chunk Type. 820 The total length of a chunk (including Type, Length and Value fields) 821 MUST be a multiple of 4 bytes. If the length of the chunk is not a 822 multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes 823 and this padding is NOT included in the chunk length field. The sender 824 should never pad with more than 3 bytes. The receiver MUST ignore the 825 padding bytes. 827 SCTP defined chunks are described in detail in Section 3.3. The 828 guidelines for IETF-defined chunk extensions can be found in Section 829 13.1 of this document. 831 3.2.1 Optional/Variable-length Parameter Format 833 Chunk values of SCTP control chunks consist of a chunk-type-specific 834 header of required fields, followed by zero or more parameters. The 835 optional and variable-length parameters contained in a chunk are 836 defined in a Type-Length-Value format as shown below. 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Parameter Type | Parameter Length | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 \ \ 844 / Parameter Value / 845 \ \ 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Chunk Parameter Type: 16 bits (unsigned integer) 850 The Type field is a 16 bit identifier of the type of parameter. It 851 takes a value of 0 to 65534. 853 The value of 65535 is reserved for IETF-defined extensions. 854 Values other than those defined in specific SCTP chunk 855 description are reserved for use by IETF. 857 Chunk Parameter Length: 16 bits (unsigned integer) 859 The Parameter Length field contains the size of the parameter in bytes, 860 including the Parameter Type, Parameter Length, and Parameter 861 Value fields. Thus, a parameter with a zero-length Parameter 862 Value field would have a Length field of 4. The Parameter Length 863 does not include any padding bytes. 865 Chunk Parameter Value: variable-length. 867 The Parameter Value field contains the actual information to be 868 transferred in the parameter. 870 The total length of a parameter (including Type, Parameter Length and 871 Value fields) MUST be a multiple of 4 bytes. If the length of the 872 parameter is not a multiple of 4 bytes, the sender pads the Parameter 873 at the end (i.e., after the Parameter Value field) with all zero 874 bytes. The length of the padding is NOT included in the parameter 875 length field. A sender should NEVER pad with more than 3 bytes. The 876 receiver MUST ignore the padding bytes. 878 The Parameter Types are encoded such that the highest-order two bits 879 specify the action that must be taken if the processing 880 endpoint does not recognize the Parameter Type. 882 00 - Stop processing this SCTP packet and discard it, do NOT process any 883 further chunks within it. 885 01 - Stop processing this SCTP packet and discard it, do NOT process any 886 further chunks within it, and report the unrecognized parameter in 887 an 'Unrecognized Parameter Type' (in either a Operational Error or 888 in the INIT ACK). 890 10 - Skip this parameter and continue processing. 892 11 - Skip this parameter and continue processing but report the 893 the unrecognized parameter in an 'Unrecognized Parameter Type' 894 (in either a Operational Error or in the INIT ACK). 896 The actual SCTP parameters are defined in the specific SCTP chunk 897 sections. The rules for IETF-defined parameter extensions are 898 defined in Section 13.2. 900 3.3 SCTP Chunk Definitions 902 This section defines the format of the different SCTP chunk types. 904 3.3.1 Payload Data (DATA) (0) 906 The following format MUST be used for the DATA chunk: 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Type = 0 | Reserved|U|B|E| Length | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | TSN | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Stream Identifier S | Stream Sequence Number n | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Payload Protocol Identifier | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 \ \ 920 / User Data (seq n of Stream S) / 921 \ \ 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 Reserved: 5 bits 925 Should be set to all '0's and ignored by the receiver. 927 U bit: 1 bit 928 The (U)nordered bit, if set to '1', indicates that this is an 929 unordered DATA chunk, and there is no Stream Sequence Number assigned 930 to this DATA chunk. Therefore, the receiver MUST ignore the Stream 931 Sequence Number field. 933 After re-assembly (if necessary), unordered DATA chunks MUST be 934 dispatched to the upper layer by the receiver without any attempt to 935 re-order. 937 If an unordered user message is fragmented, each fragment of the 938 message MUST have its U bit set to '1'. 940 B bit: 1 bit 942 The (B)eginning fragment bit, if set, indicates the first fragment of 943 a user message. 945 E bit: 1 bit 946 The (E)nding fragment bit, if set, indicates the last fragment of a 947 user message. 949 An unfragmented user message shall have both the B and E bits set 950 to '1'. Setting both B and E bits to '0' indicates a middle fragment of 951 a multi-fragment user message, as summarized in the following table: 953 B E Description 954 ============================================================ 955 | 1 0 | First piece of a fragmented user message | 956 +----------------------------------------------------------+ 957 | 0 0 | Middle piece of a fragmented user message | 958 +----------------------------------------------------------+ 959 | 0 1 | Last piece of a fragmented user message | 960 +----------------------------------------------------------+ 961 | 1 1 | Unfragmented Message | 962 ============================================================ 963 | Table 1: Fragment Description Flags | 964 ============================================================ 966 When a user message is fragmented into multiple chunks, the TSNs are 967 used by the receiver to reassemble the message. This means that the 968 TSNs for each fragment of a fragmented user message MUST be strictly 969 sequential. 971 Length: 16 bits (unsigned integer) 973 This field indicates the length of the DATA chunk in bytes from the 974 beginning of the type field to the end of the user data field 975 excluding any padding. A DATA chunk with no user data field will 976 have Length set to 16 (indicating 16 bytes). 978 TSN : 32 bits (unsigned integer) 980 This value represents the TSN for this DATA chunk. The valid range 981 of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 982 after reaching 4294967295. 984 Stream Identifier S: 16 bits (unsigned integer) 986 Identifies the stream to which the following user data belongs. 988 Stream Sequence Number n: 16 bits (unsigned integer) 990 This value represents the stream sequence number of the following 991 user data within the stream S. Valid range is 0 to 65535. 993 When a user message is fragmented by SCTP for transport, the 994 same stream sequence number MUST be carried in each of the fragments 995 of the message. 997 Payload Protocol Identifier: 32 bits (unsigned integer) 999 This value represents an application (or upper layer) specified 1000 protocol identifier. This value is passed to SCTP by its upper layer 1001 and sent to its peer. This identifier is not used by SCTP but can be 1002 used by certain network entities as well as the peer application to 1003 identify the type of information being carried in this DATA chunk. 1004 This field must be sent even in fragmented DATA chunks (to make 1005 sure it is available for agents in the middle of the network). 1007 The value 0 indicates no application identifier is specified by 1008 the upper layer for this payload data. 1010 User Data: variable length 1012 This is the payload user data. The implementation MUST pad the end 1013 of the data to a 4 byte boundary with all-zero bytes. Any padding 1014 MUST NOT be included in the length field. A sender MUST never add 1015 more than 3 bytes of padding. 1017 3.3.2 Initiation (INIT) (1) 1018 This chunk is used to initiate a SCTP association between two 1019 endpoints. The format of the INIT chunk is shown below: 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Type = 1 | Chunk Flags | Chunk Length | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Initiate Tag | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Advertised Receiver Window Credit (a_rwnd) | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Number of Outbound Streams | Number of Inbound Streams | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Initial TSN | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 \ \ 1035 / Optional/Variable-Length Parameters / 1036 \ \ 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 The INIT chunk contains the following parameters. Unless otherwise 1040 noted, each parameter MUST only be included once in the INIT chunk. 1042 Fixed Parameters Status 1043 ---------------------------------------------- 1044 Initiate Tag Mandatory 1045 Advertised Receiver Window Credit Mandatory 1046 Number of Outbound Streams Mandatory 1047 Number of Inbound Streams Mandatory 1048 Initial TSN Mandatory 1050 Variable Parameters Status Type Value 1051 ------------------------------------------------------------- 1052 IPv4 Address (Note 1) Optional 5 1053 IPv6 Address (Note 1) Optional 6 1054 Cookie Preservative Optional 9 1055 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 1056 Host Name Address (Note 3) Optional 11 1057 Supported Address Types (Note 4) Optional 12 1059 Note 1: The INIT chunks can contain multiple addresses that can be 1060 IPv4 and/or IPv6 in any combination. 1062 Note 2: The ECN capable field is reserved for future use of Explicit 1063 Congestion Notification. 1065 Note 3: An INIT chunk MUST NOT contain more than one Host Name address 1066 parameter. Moreover, the sender of the INIT MUST NOT combine any other 1067 address types with the Host Name address in the INIT. The receiver 1068 of INIT MUST ignore any other address types if the Host Name address 1069 parameter is present in the received INIT chunk. 1071 Note 4: This parameter, when present, specifies all the address types 1072 the sending endpoint can support. The absence of this parameter 1073 indicates that the sending endpoint can support any address type. 1075 The Chunk Flags field in INIT is reserved and all bits in it should be 1076 set to 0 by the sender and ignored by the receiver. The sequence of 1077 parameters within an INIT can be processed in any order. 1079 Initiate Tag: 32 bits (unsigned integer) 1081 The receiver of the INIT (the responding end) records the value of 1082 the Initiate Tag parameter. This value MUST be placed into the 1083 Verification Tag field of every SCTP packet that the receiver of the 1084 INIT transmits within this association. 1086 The Initiate Tag is allowed to have any value except 0. See 1087 Section 5.3.1 for more on the selection of the tag value. 1089 If the value of the Initiate Tag in a received INIT chunk is found 1090 to be 0, the receiver MUST treat it as an error and close 1091 the association by transmitting an ABORT. 1093 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) 1095 This value represents the dedicated buffer space, in number of 1096 bytes, the sender of the INIT has reserved in association with this 1097 window. During the life of the association this buffer space SHOULD 1098 not be lessened (i.e. dedicated buffers taken away from this 1099 association); however, an endpoint MAY change the value of a_rwnd 1100 it sends in SACK chunks. 1102 Number of Outbound Streams (OS): 16 bits (unsigned integer) 1104 Defines the number of outbound streams the sender of this INIT chunk 1105 wishes to create in this association. The value of 0 MUST NOT be 1106 used. 1108 Note: A receiver of an INIT with the OS value set to 0 SHOULD ABORT 1109 the association. 1111 Number of Inbound Streams (MIS) : 16 bits (unsigned integer) 1113 Defines the maximum number of streams the sender of this INIT chunk 1114 allows the peer end to create in this association. The value 0 MUST 1115 NOT be used. 1117 Note: There is no negotiation of the actual number of streams 1118 but instead the two endpoints will use the min(requested, 1119 offered). See Section 5.1.1 for details. 1121 Note: A receiver of an INIT with the MIS value of 0 SHOULD ABORT 1122 the association. 1124 Initial TSN (I-TSN) : 32 bits (unsigned integer) 1126 Defines the initial TSN that the sender will use. The valid range is 1127 from 0 to 4294967295. This field MAY be set to the value of the 1128 Initiate Tag field. 1130 3.3.2.1 Optional/Variable Length Parameters in INIT 1132 The following parameters follow the Type-Length-Value format as 1133 defined in Section 3.2.1. Any Type-Length-Value fields MUST come 1134 after the fixed-length fields defined in the previous section. 1136 IPv4 Address Parameter (5) 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Type = 5 | Length = 8 | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | IPv4 Address | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 IPv4 Address: 32 bits (unsigned integer) 1148 Contains an IPv4 address of the sending endpoint. It is binary 1149 encoded. 1151 IPv6 Address Parameter (6) 1153 0 1 2 3 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Type = 6 | Length = 20 | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | | 1159 | IPv6 Address | 1160 | | 1161 | | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 IPv6 Address: 128 bit (unsigned integer) 1166 Contains an IPv6 address of the sending endpoint. It is binary 1167 encoded. 1169 Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373] 1170 but should instead use an IPv4 Address Parameter for an IPv4 address. 1172 Combined with the Source Port Number in the SCTP common header, the 1173 value passed in an IPv4 or IPv6 Address parameter indicates a 1174 transport address the sender of the INIT will support for the 1175 association being initiated. That is, during the lifetime of this 1176 association, this IP address can appear in the source address field 1177 of an IP datagram sent from the sender of the INIT, and can be used 1178 as a destination address of an IP datagram sent from the receiver of 1179 the INIT. 1181 More than one IP Address parameter can be included in an INIT 1182 chunk when the INIT sender is multi-homed. Moreover, a multi-homed 1183 endpoint may have access to different types of network, thus more 1184 than one address type can be present in one INIT chunk, i.e., IPv4 1185 and IPv6 addresses are allowed in the same INIT chunk. 1187 If the INIT contains at least one IP Address parameter, then the 1188 source address of the IP datagram containing the INIT chunk and any 1189 additional address(es) provided within the INIT can be used as 1190 destinations by the endpoint receiving the INIT. If the INIT does 1191 not contain any IP Address parameters, the endpoint receiving the 1192 INIT MUST use the source address associated with the received IP 1193 datagram as its sole destination address for the association. 1195 Note that not using any IP address parameters in the INIT and INIT-ACK 1196 is an alternative to make an association more likely to work across 1197 a NAT box. 1199 Cookie Preservative (9) 1201 The sender of the INIT shall use this parameter to suggest to the 1202 receiver of the INIT for a longer life-span of the State Cookie. 1204 0 1 2 3 1205 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 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Type = 9 | Length = 8 | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | Suggested Cookie Life-span Increment (msec.) | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Suggested Cookie Life-span Increment: 32 bits (unsigned integer) 1214 This parameter indicates to the receiver how much increment in 1215 milliseconds the sender wishes the receiver to add to its default 1216 cookie life-span. 1218 This optional parameter should be added to the INIT chunk by the 1219 sender when it re-attempts establishing an association with a peer 1220 to which its previous attempt of establishing the association failed 1221 due to a stale cookie operation error. The receiver MAY choose to 1222 ignore the suggested cookie life-span increase for its own security 1223 reasons. 1225 Host Name Address (11) 1226 The sender of INIT uses this parameter to pass its Host Name (in 1227 place of its IP addresses) to its peer. The peer is responsible for 1228 resolving the name. Using this parameter might make it more likely 1229 for the association to work across a NAT box. 1231 0 1 2 3 1232 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 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Type = 11 | Length | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 / Host Name / 1237 \ \ 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 Host Name: variable length 1242 This field contains a host name in "host name syntax" per RFC1123 1243 Section 2.1 [RFC1123]. The method for resolving the host name is 1244 out of scope of SCTP. 1246 Note: At least one null terminator is included in the Host Name 1247 string and must be included in the length. 1249 Supported Address Types (12) 1251 The sender of INIT uses this parameter to list all the address types 1252 it can support. 1254 0 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Type = 12 | Length | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Address Type #1 | Address Type #2 | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | ...... 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 Address Type: 16 bits (unsigned integer) 1266 This is filled with the type value of the corresponding address 1267 TLV (e.g., IPv4 = 5, IPv6 = 6, Hostname = 11). 1269 3.3.3 Initiation Acknowledgement (INIT ACK) (2): 1271 The INIT ACK chunk is used to acknowledge the initiation of an SCTP 1272 association. 1274 The parameter part of INIT ACK is formatted similarly to the INIT 1275 chunk. It uses two extra variable parameters: The State Cookie 1276 and the Unrecognized Parameter: 1278 The format of the INIT ACK chunk is shown below: 1280 0 1 2 3 1281 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 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Type = 2 | Chunk Flags | Chunk Length | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Initiate Tag | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Advertised Receiver Window Credit | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Number of Outbound Streams | Number of Inbound Streams | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Initial TSN | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 \ \ 1294 / Optional/Variable-Length Parameters / 1295 \ \ 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Initiate Tag: 32 bits (unsigned integer) 1300 The receiver of the INIT ACK (the responding end) records the value 1301 of the Initiate Tag parameter. This value MUST be placed into the 1302 Verification Tag field of every SCTP packet that the INIT ACK 1303 receiver transmits within this association. 1305 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for 1306 more on the selection of the Initiate Tag value. 1308 If the value of the Initiate Tag in a received INIT ACK chunk is 1309 found to be 0, the receiver MUST treat it as an error and close the 1310 association by transmitting an ABORT. 1312 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) 1314 This value represents the dedicated buffer space, in number of 1315 bytes, the sender of the INIT ACK has reserved in association with 1316 this window. During the life of the association this buffer space 1317 SHOULD not be lessened (i.e. dedicated buffers taken away from this 1318 association). 1320 Number of Outbound Streams (OS): 16 bits (unsigned integer) 1322 Defines the number of outbound streams the sender of this INIT ACK 1323 chunk wishes to create in this association. The value of 0 MUST NOT 1324 be used. 1326 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy 1327 the association discarding its TCB. 1329 Number of Inbound Streams (MIS) : 16 bits (unsigned integer) 1331 Defines the maximum number of streams the sender of this INIT ACK 1332 chunk allows the peer end to create in this association. The value 0 1333 MUST NOT be used. 1335 Note: There is no negotiation of the actual number of streams but 1336 instead the two endpoints will use the min(requested, 1337 offered). See Section 5.1.1 for details. 1339 Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD destroy 1340 the association discarding its TCB. 1342 Initial TSN (I-TSN) : 32 bits (unsigned integer) 1344 Defines the initial TSN that the INIT-ACK sender will use. The valid 1345 range is from 0 to 4294967295. This field MAY be set to the value 1346 of the Initiate Tag field. 1348 Fixed Parameters Status 1349 ---------------------------------------------- 1350 Initiate Tag Mandatory 1351 Advertised Receiver Window Credit Mandatory 1352 Number of Outbound Streams Mandatory 1353 Number of Inbound Streams Mandatory 1354 Initial TSN Mandatory 1356 Variable Parameters Status Type Value 1357 ------------------------------------------------------------- 1358 State Cookie Mandatory 7 1359 IPv4 Address (Note 1) Optional 5 1360 IPv6 Address (Note 1) Optional 6 1361 Unrecognized Parameters Optional 8 1362 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 1363 Host Name Address (Note 3) Optional 11 1365 Note 1: The INIT ACK chunks can contain any number of IP address 1366 parameters that can be IPv4 and/or IPv6 in any combination. 1368 Note 2: The ECN capable field is reserved for future use of Explicit 1369 Congestion Notification. 1371 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name 1372 address parameter. Moreover, the sender of the INIT ACK MUST NOT 1373 combine any other address types with the Host Name address in the 1374 INIT ACK. The receiver of the INIT ACK MUST ignore any other 1375 address types if the Host Name address parameter is present. 1377 IMPLEMENTATION NOTE: An implementation MUST be prepared to receive 1378 a INIT ACK that is quite large (more than 1500 bytes) due to 1379 the variable size of the state cookie AND the variable address 1380 list. For example if a responder to the INIT has 1000 IPv4 1381 addresses it wishes to send, it would need at least 8,000 bytes 1382 to encode this in the INIT ACK. 1384 In combination with the Source Port carried in the SCTP common header, 1385 each IP Address parameter in the INIT ACK indicates to the receiver of 1386 the INIT ACK a valid transport address supported by the sender of the 1387 INIT ACK for the lifetime of the association being initiated. 1389 If the INIT ACK contains at least one IP Address parameter, then the 1390 source address of the IP datagram containing the INIT ACK and any 1391 additional address(es) provided within the INIT ACK may be used as 1392 destinations by the receiver of the INIT-ACK. If the INIT ACK does not 1393 contain any IP Address parameters, the receiver of the INIT-ACK MUST 1394 use the source address associated with the received IP datagram as its 1395 sole destination address for the association. 1397 The State Cookie and Unrecognized Parameters use the Type-Length- 1398 Value format as defined in Section 3.2.1 and are described below. The 1399 other fields are defined the same as their counterparts in the INIT 1400 chunk. 1402 3.3.3.1 Optional or Variable Length Parameters 1404 State Cookie 1405 Parameter Type Value: 7 1407 Parameter Length: variable size, depending on Size of Cookie 1409 Parameter Value: 1410 This parameter value MUST contain all the necessary state and 1411 parameter information required for the sender of this INIT ACK to 1412 create the association, along with Message Authentication Code 1413 (MAC). See Section 5.1.3 for details on State Cookie definition. 1415 Unrecognized Parameters: 1416 Parameter Type Value: 8 1418 Parameter Length: Variable Size. 1420 Parameter Value: 1421 This parameter is returned to the originator of the INIT chunk 1422 when the INIT contains an unrecognized parameter which has a value 1423 that indicates that it should be reported to the sender. This parameter 1424 value field will contain unrecognized parameters copied from 1425 the INIT chunk complete with Parameter Type, Length and Value fields. 1427 3.3.4 Selective Acknowledgement (SACK) (3): 1429 This chunk is sent to the peer endpoint to acknowledge received DATA 1430 chunks and to inform the peer endpoint of gaps in the received 1431 subsequences of DATA chunks as represented by their TSNs. 1433 The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver 1434 Window Credit (a_rwnd) parameters. 1436 By definition, the value of the Cumulative TSN Ack parameter is the 1437 last TSN received before a break in the sequence of received TSNs 1438 occurs; the next TSN value following this one has not yet been received 1439 at the endpoint sending the SACK. This parameter therefore acknowledges 1440 receipt of all TSNs less than or equal to its value. 1442 The handling of a_rwnd by the receiver of the SACK is discussed in 1443 detail in Section 6.2.1. 1445 The SACK also contains zero or more Gap Ack Blocks. Each 1446 Gap Ack Block acknowledges a subsequence of TSNs received following 1447 a break in the sequence of received TSNs. By definition, all TSNs 1448 acknowledged by Gap Ack Blocks are greater than the value of the 1449 Cumulative TSN Ack. 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Type = 3 |Chunk Flags | Chunk Length | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Cumulative TSN Ack | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Advertised Receiver Window Credit (a_rwnd) | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Gap Ack Block #1 Start | Gap Ack Block #1 End | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 / / 1465 \ ... \ 1466 / / 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Gap Ack Block #N Start | Gap Ack Block #N End | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Duplicate TSN 1 | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 / / 1473 \ ... \ 1474 / / 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Duplicate TSN X | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 Chunk Flags: 8 bits 1481 Set to all zeros on transmit and ignored on receipt. 1483 Cumulative TSN Ack: 32 bits (unsigned integer) 1485 This parameter contains the TSN of the last DATA chunk received in 1486 sequence before a gap. 1488 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) 1490 This field indicates the updated receive buffer space in bytes of 1491 the sender of this SACK, see Section 6.2.1 for details. 1493 Number of Gap Ack Blocks: 16 bits (unsigned integer) 1495 Indicates the number of Gap Ack Blocks included in this SACK. 1497 Number of Duplicate TSNs: 16 bit 1499 This field contains the number of duplicate TSNs the endpoint 1500 has received. Each duplicate TSN is listed following the Gap Ack 1501 Block list. 1503 Gap Ack Blocks: 1505 These fields contain the Gap Ack Blocks. They are repeated for each 1506 Gap Ack Block up to the number of Gap Ack Blocks defined in the 1507 Number of Gap Ack Blocks field. All DATA chunks with TSNs greater 1508 than or equal to (Cumulative TSN Ack + Gap Ack Block Start) and less 1509 than or equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap 1510 Ack Block are assumed to have been received correctly. 1512 Gap Ack Block Start: 16 bits (unsigned integer) 1514 Indicates the Start offset TSN for this Gap Ack Block. To calculate 1515 the actual TSN number the Cumulative TSN Ack is added to this 1516 offset number. This calculated TSN identifies the first TSN in this 1517 Gap Ack Block that has been received. 1519 Gap Ack Block End: 16 bits (unsigned integer) 1521 Indicates the End offset TSN for this Gap Ack Block. To calculate the 1522 actual TSN number the Cumulative TSN Ack is added to this 1523 offset number. This calculated TSN identifies the TSN of the last 1524 DATA chunk received in this Gap Ack Block. 1526 For example, assume the receiver has the following DATA chunks newly 1527 arrived at the time when it decides to send a Selective ACK, 1529 ---------- 1530 | TSN=17 | 1531 ---------- 1532 | | <- still missing 1533 ---------- 1534 | TSN=15 | 1535 ---------- 1536 | TSN=14 | 1537 ---------- 1538 | | <- still missing 1539 ---------- 1540 | TSN=12 | 1541 ---------- 1542 | TSN=11 | 1543 ---------- 1544 | TSN=10 | 1545 ---------- 1547 then, the parameter part of the SACK MUST be constructed as 1548 follows (assuming the new a_rwnd is set to 4660 by the sender): 1550 +--------------------------------+ 1551 | Cumulative TSN Ack = 12 | 1552 +--------------------------------+ 1553 | a_rwnd = 4660 | 1554 +----------------+---------------+ 1555 | num of block=2 | num of dup=0 | 1556 +----------------+---------------+ 1557 |block #1 strt=2 |block #1 end=3 | 1558 +----------------+---------------+ 1559 |block #2 strt=5 |block #2 end=5 | 1560 +----------------+---------------+ 1562 Duplicate TSN: 32 bits (unsigned integer) 1564 Indicates the number of times a TSN was received in duplicate since 1565 the last SACK was sent. Every time a receiver gets a duplicate TSN 1566 (before sending the SACK) it adds it to the list of duplicates. The 1567 duplicate count is re-initialized to zero after sending each SACK. 1569 For example, if a receiver were to get the TSN 19 three times 1570 it would list 19 twice in the outbound SACK. After sending the 1571 SACK if it received yet one more TSN 19 it would list 19 as a 1572 duplicate once in the next outgoing SACK. 1574 3.3.5 Heartbeat Request (HEARTBEAT) (4): 1576 An endpoint should send this chunk to its peer endpoint to probe the 1577 reachability of a particular destination transport address defined in 1578 the present association. 1580 The parameter field contains the Heartbeat Information which is a 1581 variable length opaque data structure understood only by the sender. 1583 0 1 2 3 1584 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 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Type = 4 | Chunk Flags | Heartbeat Length | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 \ \ 1589 / Heartbeat Information TLV (Variable-Length) / 1590 \ \ 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 Chunk Flags: 8 bits 1594 Set to zero on transmit and ignored on receipt. 1596 Heartbeat Length: 16 bits (unsigned integer) 1598 Set to the size of the chunk in bytes, including the chunk header 1599 and the Heartbeat Information field. 1601 Heartbeat Information: variable length 1603 Defined as a variable-length parameter using the format described in 1604 Section 3.2.1, i.e.: 1606 Variable Parameters Status Type Value 1607 ------------------------------------------------------------- 1608 Heartbeat Info Mandatory 1 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Heartbeat Info Type=1 | HB Info Length | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 / Sender-specific Heartbeat Info / 1616 \ \ 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 The Sender-specific Heartbeat Info field should normally include 1620 information about the senders current time when this HEARTBEAT 1621 chunk is sent and the destination transport address to which this 1622 HEARTBEAT is sent (see Section 8.3). 1624 3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK) (5): 1626 An endpoint should send this chunk to its peer endpoint as a response 1627 to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always 1628 sent to the source IP address of the IP datagram containing the 1629 HEARTBEAT chunk to which this ack is responding. 1631 The parameter field contains a variable length opaque data structure. 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Type = 5 | Chunk Flags | Heartbeat Ack Length | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 \ \ 1639 / Heartbeat Information TLV (Variable-Length) / 1640 \ \ 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 Chunk Flags: 8 bits 1644 Set to zero on transmit and ignored on receipt. 1646 Heartbeat Ack Length: 16 bits (unsigned integer) 1648 Set to the size of the chunk in bytes, including the chunk header 1649 and the Heartbeat Information field. 1651 Heartbeat Information: variable length 1653 This field MUST contain the Heartbeat Information parameter of 1654 the Heartbeat Request to which this Heartbeat Acknowledgement is 1655 responding. 1657 Variable Parameters Status Type Value 1658 ------------------------------------------------------------- 1659 Heartbeat Info Mandatory 1 1661 3.3.7 Abort Association (ABORT) (6): 1663 The ABORT chunk is sent to the peer of an association to close the 1664 association. The ABORT chunk may contain Cause Parameters to inform 1665 the receiver the reason of the abort. DATA chunks MUST NOT be bundled 1666 with ABORT. Control chunks (except for INIT, INIT ACK and SHUTDOWN 1667 COMPLETE) MAY be bundled with an ABORT but they MUST be placed before 1668 the ABORT in the SCTP packet, or they will be ignored by the receiver. 1670 If an endpoint receives an ABORT with a format error or for an 1671 association that doesn't exist, it MUST silently discard it. 1672 Moreover, under any circumstances, an endpoint that receives an ABORT 1673 MUST NOT respond to that ABORT by sending an ABORT of its own. 1675 0 1 2 3 1676 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 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Type = 6 |Reserved |T| Length | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 \ \ 1681 / zero or more Error Causes / 1682 \ \ 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 Chunk Flags: 8 bits 1687 Reserved: 7 bits 1688 Set to 0 on transmit and ignored on receipt. 1690 T bit: 1 bit 1691 The T bit is set to 0 if the sender had a TCB that it destroyed. If 1692 the sender did NOT have a TCB it should set this bit to 1. 1694 Note: Special rules apply to this chunk for verification, please 1695 see Section 8.5.1 for details. 1697 Length: 16 bits (unsigned integer) 1699 Set to the size of the chunk in bytes, including the chunk header 1700 and all the Error Cause fields present. 1702 See Section 3.3.10 for Error Cause definitions. 1704 3.3.8 Shutdown Association (SHUTDOWN) (7): 1706 An endpoint in an association MUST use this chunk to initiate a 1707 graceful close of the association with its peer. This chunk has 1708 the following format. 1710 0 1 2 3 1711 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 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Type = 7 | Chunk Flags | Length = 8 | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | Cumulative TSN Ack | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 Chunk Flags: 8 bits 1720 Set to zero on transmit and ignored on receipt. 1722 Length: 16 bits (unsigned integer) 1723 Indicates the length of the parameter. Set to 8. 1725 Cumulative TSN Ack: 32 bits (unsigned integer) 1727 This parameter contains the TSN of the last chunk received in 1728 sequence before any gaps. 1730 Note: Since the SHUTDOWN message does not contain Gap Ack Blocks, it 1731 cannot be used to acknowledge TSNs received out of order. In a SACK, 1732 lack of Gap Ack Blocks that were previously included indicates that 1733 the data receiver reneged on the associated DATA chunks. Since 1734 SHUTDOWN does not contain Gap Ack Blocks, the receiver of the 1735 SHUTDOWN shouldn't interpret the lack of a Gap Ack Block as a renege. 1736 (see Section 6.2 for information on reneging) 1738 3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK) (8): 1740 This chunk MUST be used to acknowledge the receipt of the SHUTDOWN 1741 chunk at the completion of the shutdown process, see Section 9.2 for 1742 details. 1744 The SHUTDOWN ACK chunk has no parameters. 1746 0 1 2 3 1747 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 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Type = 8 |Chunk Flags | Length = 4 | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 Chunk Flags: 8 bits 1755 Set to zero on transmit and ignored on receipt. 1757 3.3.10 Operation Error (ERROR) (9): 1759 An endpoint sends this chunk to its peer endpoint to notify it of 1760 certain error conditions. It contains one or more error causes. An 1761 Operation Error is not considered fatal in and of itself, but may be 1762 used with an ABORT chunk to report a fatal condition. It has the 1763 following parameters: 1765 0 1 2 3 1766 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 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Type = 9 | Chunk Flags | Length | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 \ \ 1771 / one or more Error Causes / 1772 \ \ 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 Chunk Flags: 8 bits 1777 Set to zero on transmit and ignored on receipt. 1779 Length: 16 bits (unsigned integer) 1781 Set to the size of the chunk in bytes, including the chunk header 1782 and all the Error Cause fields present. 1784 Error causes are defined as variable-length parameters using the 1785 format described in 3.2.1, i.e.: 1787 0 1 2 3 1788 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 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Cause Code | Cause Length | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 / Cause-specific Information / 1793 \ \ 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 Cause Code: 16 bits (unsigned integer) 1798 Defines the type of error conditions being reported. 1800 Cause Code 1801 Value Cause Code 1802 --------- ---------------- 1803 1 Invalid Stream Identifier 1804 2 Missing Mandatory Parameter 1805 3 Stale Cookie Error 1806 4 Out of Resource 1807 5 Unresolvable Address 1808 6 Unrecognized Chunk Type 1809 7 Invalid Mandatory Parameter 1810 8 Unrecognized Parameters 1811 9 No User Data 1812 10 Cookie Received While Shutting Down 1814 Cause Length: 16 bits (unsigned integer) 1816 Set to the size of the parameter in bytes, including the Cause Code, 1817 Cause Length, and Cause-Specific Information fields 1819 Cause-specific Information: variable length 1821 This field carries the details of the error condition. 1823 Sections 3.3.10.1 - 3.3.10.8 define error causes for SCTP. Guidelines 1824 for the IETF to define new error cause values are discussed in Section 1825 13.3. 1827 3.3.10.1 Invalid Stream Identifier (1) 1829 Cause of error 1830 --------------- 1831 Invalid Stream Identifier: Indicates endpoint received a DATA chunk 1832 sent to a nonexistent stream. 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Cause Code=1 | Cause Length=8 | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Stream Identifier | (Reserved) | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 Stream Identifier: 16 bits (unsigned integer) 1841 Contains the Stream Identifier of the DATA chunk received in 1842 error. 1844 Reserved: 16 bits 1845 This field is reserved. It is set to all 0's on transmit and 1846 Ignored on receipt. 1848 3.3.10.2 Missing Mandatory Parameter (2) 1850 Cause of error 1851 --------------- 1852 Missing Mandatory Parameter: Indicates that one or more 1853 mandatory TLV parameters are missing in a received INIT or INIT ACK. 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Cause Code=2 | Cause Length=8+N*2 | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Number of missing params=N | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Missing Param Type #1 | Missing Param Type #2 | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Missing Param Type #N-1 | Missing Param Type #N | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 Number of Missing params: 32 bits (unsigned integer) 1867 This field contains the number of parameters contained in the 1868 Cause-specific Information field. 1870 Missing Param Type: 16 bits (unsigned integer) 1872 This field contains a mandatory parameter that was missing in the 1873 INIT or INIT ACK message. This field contains the complete 1874 Parameter, including Type, Length and Value fields. 1876 3.3.10.3 Stale Cookie Error (3) 1878 Cause of error 1879 -------------- 1880 Stale Cookie Error: Indicates the receipt of a valid State Cookie 1881 that has expired. 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | Cause Code=3 | Cause Length=8 | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Measure of Staleness (usec.) | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 Measure of Staleness: 32 bits (unsigned integer) 1890 This field contains the difference, in microseconds, between 1891 The current time and the time the State Cookie expired. 1893 The sender of this error cause MAY choose to report how long past 1894 expiration the State Cookie is by including a non-zero value in the 1895 Measure of Staleness field. If the sender does not wish to provide 1896 this information it should set the Measure of Staleness field to the 1897 value of zero. 1899 3.3.10.4 Out of Resource (4) 1901 Cause of error 1902 --------------- 1903 Out of Resource: Indicates that the sender is out of resource. This 1904 is usually sent in combination with or within an ABORT. 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Cause Code=4 | Cause Length=4 | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 3.3.10.5 Unresolvable Address (5) 1912 Cause of error 1913 --------------- 1914 Unresolvable Address: Indicates that the sender is not able to 1915 resolve the specified address parameter (e.g., type of address is 1916 not supported by the sender). This is usually sent in combination 1917 with or within an ABORT. 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Cause Code=5 | Cause Length | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 / Unresolvable Address / 1923 \ \ 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 Unresolvable Address: variable length 1927 The unresolvable address field contains the complete Type, Length 1928 and Value of the address parameter (or Host Name parameter) that 1929 contains the unresolvable address or host name. 1931 3.3.10.6 Unrecognized Chunk Type (6) 1933 Cause of error 1934 --------------- 1935 Unrecognized Chunk Type: This error cause is returned to the 1936 originator of the chunk if the receiver does not understand 1937 the chunk and the upper bit of the 'Chunk Type' is set to one. 1939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 | Cause Code=6 | Cause Length | 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 / Unrecognized Chunk / 1943 \ \ 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 Unrecognized Chunk: variable length 1948 The Unrecognized Chunk field contains the unrecognized 1949 Chunk from the SCTP packet complete with Chunk Type, 1950 Chunk Flags and Chunk Length. 1952 3.3.10.7 Invalid Mandatory Parameter (7) 1954 Cause of error 1955 --------------- 1956 Invalid Mandatory Parameter: This error cause is returned to the 1957 originator of an INIT or INIT ACK chunk when one of the mandatory 1958 parameters is set to a invalid value. 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Cause Code=7 | Cause Length=4 | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 3.3.10.8 Unrecognized Parameters (8) 1966 Cause of error 1967 --------------- 1968 Unrecognized Parameters: This error cause is returned to the 1969 originator of the INIT ACK chunk if the receiver does not 1970 recognize one or more Optional TLV parameters in the INIT ACK chunk. 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Cause Code=8 | Cause Length | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 / Unrecognized Parameters / 1976 \ \ 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 Unrecognized Parameters: variable length 1980 The Unrecognized Parameters field contains the unrecognized 1981 parameters copied from the INIT ACK chunk complete with TLV. This 1982 error cause is normally contained in an ERROR chunk bundled with 1983 the COOKIE ECHO chunk when responding to the INIT ACK, when the 1984 sender of the COOKIE ECHO chunk wishes to report unrecognized 1985 parameters. 1987 3.3.10.9 No User Data (9) 1989 Cause of error 1990 --------------- 1991 No User Data: This error cause is returned to the 1992 originator of a DATA chunk if a received DATA chunk has no user data. 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Cause Code=9 | Cause Length=8 | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 / TSN value / 1998 \ \ 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 TSN value: 32 bits (+unsigned integer) 2002 The TSN value field contains the TSN of the DATA chunk received 2003 with no user data field. 2005 This cause code is normally returned in an ABORT chunk 2006 (see Section 6.2) 2008 3.3.10.10 Cookie Received While Shutting Down (10) 2010 Cause of error 2011 --------------- 2012 Cookie Received While Shutting Down: A COOKIE ECHO was received 2013 While the endpoint was in SHUTDOWN-ACK-SENT state. This error is 2014 usually returned in an ERROR chunk bundled with the retransmitted 2015 SHUTDOWN ACK. 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | Cause Code=10 | Cause Length=4 | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 3.3.11 Cookie Echo (COOKIE ECHO) (10): 2023 This chunk is used only during the initialization of an association. 2024 It is sent by the initiator of an association to its peer to complete 2025 the initialization process. This chunk MUST precede any DATA chunk 2026 sent within the association, but MAY be bundled with one or more DATA 2027 chunks in the same packet. 2029 0 1 2 3 2030 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 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Type = 10 |Chunk Flags | Length | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Cookie | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 Chunk Flags: 8 bit 2039 Set to zero on transmit and ignored on receipt. 2041 Length: 16 bits (unsigned integer) 2043 Set to the size of the chunk in bytes, including the 4 bytes of 2044 the chunk header and the size of the Cookie. 2046 Cookie: variable size 2048 This field must contain the exact cookie received in the 2049 State Cookie parameter from the previous INIT ACK. 2051 An implementation SHOULD make the cookie as small as possible 2052 to insure interoperability. 2054 3.3.12 Cookie Acknowledgement (COOKIE ACK) (11): 2056 This chunk is used only during the initialization of an association. 2057 It is used to acknowledge the receipt of a COOKIE ECHO chunk. This 2058 chunk MUST precede any DATA or SACK chunk sent within the association, 2059 but MAY be bundled with one or more DATA chunks or SACK chunk in the 2060 same SCTP packet. 2062 0 1 2 3 2063 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 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Type = 11 |Chunk Flags | Length = 4 | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 Chunk Flags: 8 bits 2070 Set to zero on transmit and ignored on receipt. 2072 3.3.13 Shutdown Complete (SHUTDOWN COMPLETE) (12): 2074 This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK 2075 chunk at the completion of the shutdown process, see Section 9.2 for 2076 details. 2078 The SHUTDOWN COMPLETE chunk has no parameters. 2080 0 1 2 3 2081 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 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | Type = 12 |Reserved |T| Length = 4 | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 Chunk Flags: 8 bits 2088 Reserved: 7 bits 2089 Set to 0 on transmit and ignored on receipt. 2091 T bit: 1 bit 2092 The T bit is set to 0 if the sender had a TCB that it destroyed. If 2093 the sender did NOT have a TCB it should set this bit to 1. 2095 Note: Special rules apply to this chunk for verification, please 2096 see Section 8.5.1 for details. 2098 4. SCTP Association State Diagram 2100 During the lifetime of an SCTP association, the SCTP endpoints association 2101 progress from one state to another in response to various events. The 2102 events that may potentially advance an association's state include: 2104 o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT], 2106 o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc. control 2107 chunks, or 2109 o Some timeout events. 2111 The state diagram in the figures below illustrates state changes, 2112 together with the causing events and resulting actions. Note that some 2113 of the error conditions are not shown in the state diagram. Full 2114 description of all special cases should be found in the text. 2116 Note: Chunk names are given in all capital letters, while parameter 2117 names have the first letter capitalized, e.g., COOKIE ECHO chunk type 2118 vs. State Cookie parameter. If more than one event/message can occur 2119 which causes a state transition it is labeled (A), (B) etc. 2121 ----- -------- (frm any state) 2122 / \ / rcv ABORT [ABORT] 2123 rcv INIT | | | ---------- or ---------- 2124 --------------- | v v delete TCB snd ABORT 2125 generate Cookie \ +---------+ delete TCB 2126 snd INIT ACK ---| CLOSED | 2127 +---------+ 2128 / \ [ASSOCIATE] 2129 / \ --------------- 2130 | | create TCB 2131 | | snd INIT 2132 | | strt init timer 2133 rcv valid | | 2134 COOKIE ECHO | v 2135 (1) ---------------- | +------------+ 2136 create TCB | | COOKIE-WAIT| (2) 2137 snd COOKIE ACK | +------------+ 2138 | | 2139 | | rcv INIT ACK 2140 | | ----------------- 2141 | | snd COOKIE ECHO 2142 | | stop init timer 2143 | | strt cookie timer 2144 | v 2145 | +--------------+ 2146 | | COOKIE-ECHOED| (3) 2147 | +--------------+ 2148 | | 2149 | | rcv COOKIE ACK 2150 | | ----------------- 2151 | | stop cookie timer 2152 v v 2153 +---------------+ 2154 | ESTABLISHED | 2155 +---------------+ 2157 (from the ESTABLISHED state only) 2158 | 2159 | 2160 /--------+--------\ 2161 [SHUTDOWN] / \ 2162 -------------------| | 2163 check outstanding | | 2164 DATA chunks | | 2165 v | 2166 +---------+ | 2167 |SHUTDOWN-| | rcv SHUTDOWN/check 2168 |PENDING | | outstanding DATA 2169 +---------+ | chunks 2170 | |------------------ 2171 No more outstanding | | 2172 ---------------------| | 2173 snd SHUTDOWN | | 2174 strt shutdown timer | | 2175 v v 2176 +---------+ +-----------+ 2177 (4) |SHUTDOWN-| | SHUTDOWN- | (5,6) 2178 |SENT | | RECEIVED | 2179 +---------+ +-----------+ 2180 | \ | 2181 (A) rcv SHUTDOWN ACK | \ | 2182 ----------------------| \ | 2183 stop shutdown timer | \rcv:SHUTDOWN | 2184 send SHUTDOWN COMPLETE| \ (B) | 2185 delete TCB | \ | 2186 | \ | No more outstanding 2187 | \ |----------------- 2188 | \ | send SHUTDOWN ACK 2189 (B)rcv SHUTDOWN | \ | strt shutdown timer 2190 ----------------------| \ | 2191 send SHUTDOWN ACK | \ | 2192 start shutdown timer | \ | 2193 move to SHUTDOWN- | \ | 2194 ACK-SENT | | | 2195 | v | 2196 | +-----------+ 2197 | | SHUTDOWN- | (7) 2198 | | ACK-SENT | 2199 | +-----------+ 2200 | | (C)rcv SHUTDOWN COMPLETE 2201 | |----------------- 2202 | | stop shutdown timer 2203 | | delete TCB 2204 | | 2205 | | (D)rcv SHUTDOWN ACK 2206 | |-------------- 2207 | | stop shutdown timer 2208 | | send SHUTDOWN COMPLETE 2209 | | delete TCB 2210 | | 2211 \ +---------+ / 2212 \-->| CLOSED |<--/ 2213 +---------+ 2215 Figure 3: State Transition Diagram of SCTP 2217 Notes: 2219 (1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., 2220 failed to pass the integrity check), the receiver MUST silently 2221 discard the packet. Or, if the received State Cookie is expired 2222 (see Section 5.1.5), the receiver MUST send back an ERROR chunk. 2223 In either case, the receiver stays in the CLOSED state. 2225 (2) If the T1-init timer expires, the endpoint MUST retransmit INIT 2226 and re-start the T1-init timer without changing state. This MUST be 2227 repeated up to 'Max.Init.Retransmits' times. After that, the 2228 endpoint MUST abort the initialization process and report the 2229 error to SCTP user. 2231 (3) If the T1-cookie timer expires, the endpoint MUST retransmit 2232 COOKIE ECHO and re-start the T1-cookie timer without changing 2233 state. This MUST be repeated up to 'Max.Init.Retransmits' 2234 times. After that, the endpoint MUST abort the initialization 2235 process and report the error to SCTP user. 2237 (4) In SHUTDOWN-SENT state the endpoint MUST acknowledge any received 2238 DATA chunks without delay. 2240 (5) In SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new 2241 send request from its SCTP user. 2243 (6) In SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit 2244 data and leave this state when all data inqueue is transmitted. 2246 (7 In SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new 2247 send request from its SCTP user. 2249 The CLOSED state is used to indicate that an association is not 2250 created (i.e., doesn't exist). 2252 5. Association Initialization 2254 Before the first data transmission can take place from one SCTP 2255 endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must 2256 complete an initialization process in order to set up an SCTP 2257 association between them. 2259 The SCTP user at an endpoint should use the ASSOCIATE primitive to 2260 initialize an SCTP association to another SCTP endpoint. 2262 IMPLEMENTATION NOTE: From an SCTP-user's point of view, an 2263 association may be implicitly opened, without an ASSOCIATE primitive 2264 (see 10.1 B) being invoked, by the initiating endpoint's sending of 2265 the first user data to the destination endpoint. The initiating SCTP 2266 will assume default values for all mandatory and optional parameters 2267 for the INIT/INIT ACK. 2269 Once the association is established, unidirectional streams are 2270 open for data transfer on both ends (see Section 5.1.1). 2272 5.1 Normal Establishment of an Association 2274 The initialization process consists of the following steps (assuming 2275 that SCTP endpoint "A" tries to set up an association with SCTP 2276 endpoint "Z" and "Z" accepts the new association): 2278 A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must 2279 provide its Verification Tag (Tag_A) in the Initiate Tag field. 2280 Tag_A SHOULD be a random number in the range of 1 to 4294967295 2281 (see 5.3.1 for Tag value selection). After sending the INIT, "A" 2282 starts the T1-init timer and enters the COOKIE-WAIT state. 2284 B) "Z" shall respond immediately with an INIT ACK chunk. The 2285 destination IP address of the INIT ACK MUST be set to the source 2286 IP address of the INIT to which this INIT ACK is responding. In 2287 the response, besides filling in other parameters, "Z" must set the 2288 Verification Tag field to Tag_A, and also provide its own 2289 Verification Tag (Tag_Z) in the Initiate Tag field. 2291 Moreover, "Z" MUST generate and send along with the INIT ACK a 2292 State Cookie. See Section 5.1.3 for State Cookie generation. 2294 Note: After sending out INIT ACK with the State Cookie parameter, 2295 "Z" MUST NOT allocate any resources, nor keep any states for the new 2296 association. Otherwise, "Z" will be vulnerable to resource attacks. 2298 C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1-init 2299 timer and leave COOKIE-WAIT state. "A" shall then send the State 2300 Cookie received in the INIT ACK chunk in a COOKIE ECHO chunk, start 2301 the T1-cookie timer, and enter the COOKIE-ECHOED state. 2303 Note: The COOKIE ECHO chunk can be bundled with any pending outbound 2304 DATA chunks, but it MUST be the first chunk in the packet and 2305 until the COOKIE ACK is returned the sender MUST NOT send any 2306 other packets to the peer. 2308 D) Upon reception of the COOKIE ECHO chunk, Endpoint "Z" will reply 2309 with a COOKIE ACK chunk after building a TCB and moving to 2310 the ESTABLISHED state. A COOKIE ACK chunk may be bundled with 2311 any pending DATA chunks (and/or SACK chunks), but the COOKIE ACK 2312 chunk MUST be the first chunk in the packet. 2314 IMPLEMENTATION NOTE: An implementation may choose to send the 2315 Communication Up notification to the SCTP user upon reception 2316 of a valid COOKIE ECHO chunk. 2318 E) Upon reception of the COOKIE ACK, endpoint "A" will move from the 2319 COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-cookie 2320 timer. It may also notify its ULP about the successful 2321 establishment of the association with a Communication Up 2322 notification (see Section 10). 2324 An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk. 2326 They MUST be the only chunks present in the SCTP packets that carry 2327 them. 2329 IMPLEMENTATION NOTE: In some cases (e.g., when the implementation 2330 doesn't control the source IP address that is used for transmitting), 2331 an endpoint might need to include in its INIT or INIT ACK all possible 2332 IP addresses from which packets to the peer could be transmitted. 2334 An endpoint MUST send the INIT ACK to the IP address from which it 2335 received the INIT. 2337 Note: T1-init timer and T1-cookie timer shall follow the same rules 2338 given in Section 6.3. 2340 If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but 2341 decides not to establish the new association due to missing mandatory 2342 parameters in the received INIT or INIT ACK, invalid parameter values, 2343 or lack of local resources, it MUST respond with an ABORT chunk. It 2344 SHOULD also specify the cause of abort, such as the type of the 2345 missing mandatory parameters, etc., by including the error cause 2346 parameters with the ABORT chunk. The Verification Tag field in the 2347 common header of the outbound SCTP packet containing the ABORT chunk 2348 MUST be set to the Initiate Tag value of the peer. 2350 After the reception of the first DATA chunk in an association 2351 the endpoint MUST immediately respond with a SACK to acknowledge 2352 the DATA chunk. Subsequent acknowledgements should be done as 2353 described in Section 6.2. 2355 When the TCB is created, each endpoint MUST set its internal Cumulative 2356 TSN Ack Point to the value of its transmitted Initial TSN minus one. 2358 IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally 2359 used as the key to find the TCB within an SCTP instance. 2361 5.1.1 Handle Stream Parameters 2363 In the INIT and INIT ACK chunks, the sender of the chunk shall 2364 indicate the number of outbound streams (OS) it wishes to have in the 2365 association, as well as the maximum inbound streams (MIS) it will 2366 accept from the other endpoint. 2368 After receiving the stream configuration information from the other 2369 side, each endpoint shall perform the following check: If the peer's 2370 MIS is less than the endpoint's OS, meaning that the peer is incapable 2371 of supporting all the outbound streams the endpoint wants to 2372 configure, the endpoint MUST either use MIS outbound streams, 2373 or abort the association and report to its upper layer the resources 2374 shortage at its peer. 2376 After the association is initialized, the valid outbound stream 2377 identifier range for either endpoint shall be 0 to 2378 min(local OS, remote MIS)-1. 2380 5.1.2 Handle Address Parameters 2382 During the association initialization, an endpoint shall use the 2383 following rules to discover and collect the destination transport 2384 address(es) of its peer. 2386 A) If there are no address parameters present in the received INIT 2387 or INIT ACK chunk, the endpoint shall take the source IP address 2388 from which the chunk arrives and record it, in combination with 2389 the SCTP source port number, as the only destination transport 2390 address for this peer. 2392 B) If there is a Host Name parameter present in the received INIT or 2393 INIT ACK chunk, the endpoint shall resolve that host name to a 2394 list of IP address(es) and derive the transport address(es) of this 2395 peer by combining the resolved IP address(es) with the SCTP source 2396 port. 2398 The endpoint MUST ignore any other IP address parameters if 2399 they are also present in the received INIT or INIT ACK chunk. 2401 The time at which the receiver of an INIT resolves the host 2402 name has potential security implications to SCTP. If the receiver of 2403 an INIT resolves the host name upon the reception of the chunk, and 2404 the mechanism the receiver uses to resolve the host name involves 2405 potential long delay (e.g. DNS query), the receiver may open itself 2406 up to resource attacks for the period of time while it is waiting for 2407 the name resolution results before it can build the State Cookie and 2408 release local resources. 2410 Therefore, in cases where the name translation involves potential 2411 long delay, the receiver of the INIT MUST postpone the name 2412 resolution till the reception of the COOKIE ECHO chunk from the 2413 peer. In such a case, the receiver of the INIT SHOULD build the 2414 State Cookie using the received Host Name (instead of destination 2415 transport addresses) and send the INIT ACK to the source IP 2416 address from which the INIT was received. 2418 The receiver of an INIT ACK shall always immediately attempt to 2419 resolve the name upon the reception of the chunk. 2421 The receiver of the INIT or INIT ACK MUST NOT send user data 2422 (piggy-backed or stand-alone) to its peer until the host name is 2423 successfully resolved. 2425 If the name resolution is not successful, the endpoint MUST 2426 immediately send an ABORT with "Unresolvable Address" error cause to 2427 its peer. The ABORT shall be sent to the source IP address from which 2428 the last peer packet was received. 2430 C) If there are only IPv4/IPv6 addresses present in the received 2431 INIT or INIT ACK chunk, the receiver shall derive and record all 2432 the transport address(es) from the received chunk AND the 2433 source IP address that sent the INIT or INIT ACK. The transport 2434 address(es) are derived by the combination of SCTP source port (from 2435 the common header) and the IP address parameter(s) carried in the 2436 INIT or INIT ACK chunk and the source IP address of the IP datagram. 2437 The receiver should use only these transport addresses as 2438 destination transport addresses when sending subsequent packets 2439 to its peer. 2441 After all transport addresses are derived from the INIT or INIT ACK 2442 chunk using the above rules, the endpoint shall select one of the 2443 transport addresses as the initial primary path. 2445 Note: The INIT-ACK MUST be sent to the source address of the INIT. 2447 The sender of INIT may include a 'Supported Address Types' 2448 parameter in the INIT to indicate what types of address are 2449 acceptable. When this parameter is present, the receiver of INIT 2450 (initiatee) MUST either use one of the address types indicated in the 2451 Supported Address Types parameter when responding to the INIT, or 2452 abort the association with an "Unresolvable Address" error cause if it 2453 is unwilling or incapable of using any of the address types indicated 2454 by its peer. 2456 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK 2457 fails to resolve the address parameter due to an unsupported type, 2458 it can abort the initiation process and then attempt a re-initiation 2459 by using a 'Supported Address Types' parameter in the new INIT to 2460 indicate what types of address it prefers. 2462 5.1.3 Generating State Cookie 2464 When sending an INIT ACK as a response to an INIT chunk, the sender 2465 of INIT ACK creates a State Cookie and sends it in the State Cookie 2466 parameter of the INIT ACK. Inside this State Cookie, the sender should 2467 include a MAC (see [RFC2104] for an example), a time stamp on when the 2468 State Cookie is created, and the lifespan of the State Cookie, along 2469 with all the information necessary for it to establish the association. 2471 The following steps SHOULD be taken to generate the State Cookie: 2473 1) Create an association TCB using information from both the received 2474 INIT and the outgoing INIT ACK chunk, 2476 2) In the TCB, set the creation time to the current time of day, and 2477 the lifespan to the protocol parameter 'Valid.Cookie.Life', 2479 3) Generate a MAC using the TCB and a secret key (see [RFC2104] for an 2480 example of generating a MAC), and 2482 4) Generate the State Cookie by combining the smallest amount of 2483 information needed to generate a TCB and the resultant MAC. 2485 After sending the INIT ACK with the State Cookie parameter, the sender 2486 SHOULD delete the TCB and any other local resource related to the new 2487 association, so as to prevent resource attacks. 2489 The hashing method used to generate the MAC is strictly a 2490 private matter for the receiver of the INIT chunk. The use of a MAC 2491 is mandatory to prevent denial of service attacks. The secret key 2492 SHOULD be random ([RFC1750] provides some information on randomness 2493 guidelines); it SHOULD be changed reasonably frequently, and the 2494 timestamp in the State Cookie MAY be used to determine which key should 2495 be used to verify the MAC. 2497 An implementation SHOULD make the cookie as small as possible to 2498 insure interoperability. 2500 5.1.4 State Cookie Processing 2502 When an endpoint receives an INIT ACK chunk with a State Cookie 2503 parameter, it MUST immediately send a COOKIE ECHO chunk to its peer 2504 with the received State Cookie. The sender MAY also add any pending 2505 DATA chunks to the packet after the COOKIE ECHO chunk. 2507 The endpoint shall also start the T1-cookie timer after sending out the 2508 COOKIE ECHO chunk. If the timer expires, the endpoint shall retransmit 2509 the COOKIE ECHO chunk and restart the T1-cookie timer. This is repeated 2510 until either a COOKIE ACK is received or 'Max.Init.Retransmits' is 2511 reached causing the peer endpoint to be marked unreachable (and thus 2512 the association enters the CLOSED state). 2514 5.1.5 State Cookie Authentication 2516 When an endpoint receives a COOKIE ECHO chunk from another endpoint 2517 with which it has no association, it shall take the following actions: 2519 1) Compute a MAC using the TCB data carried in the State 2520 Cookie and the secret key (note the timestamp in the State Cookie 2521 MAY be used to determine which secret key to use). Reference 2522 [RFC2104] can be used as a guideline for generating the MAC, 2524 2) Authenticate the State Cookie as one that it previously generated by 2525 comparing the computed MAC against the one carried in the 2526 State Cookie. If this comparison fails, the SCTP packet, including 2527 the COOKIE ECHO and any DATA chunks, should be silently discarded, 2529 3) Compare the creation timestamp in the State Cookie to the current 2530 local time. If the elapsed time is longer than the lifespan carried 2531 in the State Cookie, then the packet, including the COOKIE ECHO and 2532 any attached DATA chunks, SHOULD be discarded and the endpoint MUST 2533 transmit an ERROR chunk with a "Stale Cookie" error cause to the 2534 peer endpoint, 2536 4) If the State Cookie is valid, create an association to the sender of 2537 the COOKIE ECHO chunk with the information in the TCB data carried 2538 in the COOKIE ECHO, and enter the ESTABLISHED state, 2540 5) Send a COOKIE ACK chunk to the peer acknowledging reception of 2541 the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound 2542 DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first 2543 chunk in the SCTP packet. 2545 6) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO 2546 with a SACK (subsequent DATA chunk acknowledgement should follow the 2547 rules defined in Section 6.2). As mentioned in step 5), if the SACK 2548 is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in 2549 the SCTP packet. 2551 If a COOKIE ECHO is received from an endpoint with which the 2552 receiver of the COOKIE ECHO has an existing association, the procedures 2553 in Section 5.2 should be followed. 2555 5.1.6 An Example of Normal Association Establishment 2557 In the following example, "A" initiates the association and then sends 2558 a user message to "Z", then "Z" sends two user messages to "A" later 2559 (assuming no bundling or fragmentation occurs): 2561 Endpoint A Endpoint Z 2562 x 2563 {app sets association with Z} 2564 (build TCB) 2565 INIT [I-Tag=Tag_A 2566 & other info] --------\ 2567 (Start T1-init timer) \ 2568 (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) 2570 /--- INIT ACK [Veri Tag=Tag_A, 2571 / I-Tag=Tag_Z, 2572 (Cancel T1-init timer) <------/ Cookie_Z, & other info] 2573 (destroy temp TCB) 2574 COOKIE ECHO [Cookie_Z] ------\ 2575 (Start T1-init timer) \ 2576 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 2577 state) 2579 /---- COOKIE-ACK 2580 / 2581 (Cancel T1-init timer, <-----/ 2582 Enter ESTABLISHED state) 2583 ... 2584 {app sends 1st user data; strm 0} 2585 DATA [TSN=initial TSN_A 2586 Strm=0,Seq=1 & user data]--\ 2587 (Start T3-rtx timer) \ 2588 \-> 2590 /----- SACK [TSN Ack=init TSN_A,Block=0] 2591 (Cancel T3-rtx timer) <------/ 2592 ... 2594 ... 2595 {app sends 2 messages;strm 0} 2596 /---- DATA 2597 / [TSN=init TSN_Z 2598 <--/ Strm=0,Seq=1 & user data 1] 2599 SACK [TSN Ack=init TSN_Z, /---- DATA 2600 Block=0] --------\ / [TSN=init TSN_Z +1, 2601 \/ Strm=0,Seq=2 & user data 2] 2602 <------/\ 2603 \ 2604 \------> 2606 Figure 4: INITiation Example 2608 If the T1-init timer expires at "A" after the INIT or COOKIE ECHO 2609 chunks are sent, the same INIT or COOKIE ECHO chunk with the same 2610 Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and 2611 the timer restarted. This shall be repeated Max.Init.Retransmits times 2612 before "A" considers "Z" unreachable and reports the failure to its 2613 upper layer (and thus the association enters the CLOSED state). When 2614 retransmitting the INIT, the endpoint MUST follow the rules 2615 defined in 6.3 to determine the proper timer value. 2617 5.2 Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and 2618 COOKIE ACK 2620 During the lifetime of an association (in one of the possible 2621 states), an endpoint may receive from its peer endpoint one of the 2622 setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The 2623 receiver shall treat such a setup chunk as a duplicate and process it 2624 as described in this section. 2625 Note: An endpoint will not receive the chunk unless the chunk was 2626 sent to a SCTP transport address and is from a SCTP transport address 2627 associated with this endpoint. Therefore, the endpoint processes 2628 such a chunk as part of its current association. 2630 The following scenarios can cause duplicated or unexpected chunks: 2632 A) The peer has crashed without being detected, re-started 2633 itself and sent out a new INIT chunk trying to restore the 2634 association, 2636 B) Both sides are trying to initialize the association at about the 2637 same time, 2639 C) The chunk is from a stale packet that was used to establish 2640 the present association or a past association that is no 2641 longer in existence, 2643 D) The chunk is a false packet generated by an attacker, or 2645 E) The peer never received the COOKIE ACK and is retransmitting its 2646 COOKIE ECHO. 2648 The rules in the following sections shall be applied in order to 2649 identify and correctly handle these cases. 2651 5.2.1 INIT received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) 2653 This usually indicates an initialization collision, i.e., each 2654 endpoint is attempting, at about the same time, to establish an 2655 association with the other endpoint. 2657 Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an 2658 endpoint MUST respond with an INIT ACK using the same parameters it 2659 sent in its original INIT chunk (including its Verification Tag, 2660 unchanged). These original parameters are combined with those from the 2661 newly received INIT chunk. The endpoint shall also generate a State 2662 Cookie with the INIT ACK. The endpoint uses the parameters sent in its 2663 INIT to calculate the State Cookie. 2665 After that, the endpoint MUST not change its state, the T1-init 2666 timer shall be left running and the corresponding TCB MUST NOT be 2667 destroyed. The normal procedures for handling State Cookies when 2668 a TCB exists will resolve the duplicate INITs to a single association. 2670 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED and 2671 COOKIE-WAIT 2673 Unless otherwise stated, upon reception of an unexpected INIT for this 2674 association, the endpoint shall generate an INIT ACK with a State 2675 Cookie. In the outbound INIT ACK the endpoint MUST copy its current 2676 Verification Tag and Peers Verification tag into a reserved place 2677 within the state cookie. We shall refer to these locations as the 2678 Peers-Tie-Tag and the Local-Tie-Tag. The INIT ACK MUST contain a new 2679 Verification Tag (randomly generated see Section 5.3.1). Other 2680 parameters for the endpoint SHOULD be copied from the existing 2681 parameters of the association (e.g. number of outbound streams) into 2682 the INIT ACK and cookie. 2684 After sending out the INIT ACK, the endpoint shall take no further 2685 actions, i.e., the existing association, including its current state, 2686 and the corresponding TCB MUST NOT be changed. 2688 Note: Only when a TCB exists and the association is NOT in a 2689 COOKIE-ECHOED or COOKIE-WAIT state are the Tie-Tags populated. For a 2690 normal association INIT (i.e. the endpoint ARE in a COOKIE-ECHOED or 2691 COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no 2692 previous TCB existed). The INIT ACK and State Cookie are populated 2693 as specified in section 5.2.1. 2695 5.2.3 Unexpected INIT ACK 2697 If an INIT ACK is received by an endpoint in any state 2698 other than the COOKIE-WAIT state, the endpoint should discard 2699 the INIT ACK chunk. An unexpected INIT ACK usually indicates the 2700 processing of an old or duplicated INIT chunk. 2702 5.2.4 Handle a COOKIE ECHO when a TCB exists 2704 When a COOKIE ECHO chunk is received by an endpoint in any state for an 2705 existing association (i.e., not in the CLOSED state) the following 2706 rules shall be applied: 2708 1) Compute a MAC as described in Step 1 of Section 5.1.5, 2710 2) Authenticate the State Cookie as described in Step 2 of Section 2711 5.1.5 (this is case C or D above). 2713 3) Compare the timestamp in the State Cookie to the current time. If 2714 the State Cookie is older than the lifespan carried in the State 2715 Cookie and the Verification Tags contained in the State Cookie do 2716 not match the current association's Verification Tags, the packet, 2717 including the COOKIE ECHO and any DATA chunks, should be discarded. 2718 The endpoint also MUST transmit an ERROR chunk with a "Stale Cookie" 2719 error cause to the peer endpoint (this is case C or D above). 2721 If both Verification Tags in the State Cookie match the Verification 2722 Tags of the current association, consider the State Cookie valid 2723 (this is case E) even if the lifespan is exceeded. 2725 4) If the State Cookie proves to be valid, unpack the TCB into a 2726 temporary TCB. 2728 5) If the Verification Tags in the Temporary TCB match the 2729 Verification Tags in the existing TCB, the State Cookie is a 2730 duplicate cookie. A COOKIE ACK should be sent to the peer 2731 endpoint but no update should be made to the existing 2732 TCB (only the local Verification Tag needs to be compared if 2733 the peer's Verification Tag is not yet available). 2735 The endpoint doesn't leave the current state and all timers 2736 remain running. 2738 6) If either of the Verification Tags do NOT match, refer to the following 2739 table to determine the correct action to be taken. 2741 +------------+------------+---------------+--------------+-------------+ 2742 | Local Tag | Peers Tag | Local-Tie-Tag | Peers-Tie-Tag| Action/ | 2743 | | | | | Description | 2744 +------------+------------+---------------+--------------+-------------+ 2745 | X | X | M | M | (A) | 2746 +------------+------------+---------------+--------------+-------------+ 2747 | X | M | M | M | (B) | 2748 +------------+------------+---------------+--------------+-------------+ 2749 | X | M | M | X | (C) | 2750 +------------+------------+---------------+--------------+-------------+ 2751 | M | X | X | M | (D) | 2752 +------------+------------+---------------+--------------+-------------+ 2753 | M | X | M | M | (E) | 2754 +------------+------------+---------------+--------------+-------------+ 2755 | X | X | X | X | (F) | 2756 +======================================================================+ 2757 | Table 2: Handling of a Cookie when a TCB exists | 2758 +======================================================================+ 2760 Legend: 2761 X - Tag does not match the existing TCB 2762 M - Tag matches the existing TCB. 2764 Actions 2766 (A)In this case, the peer may have restarted. When the endpoint 2767 recognizes this potential 'restart', the existing session is 2768 treated the same as if it received an ABORT followed by a new 2769 Cookie Echo with the following exceptions: 2771 - Any SCTP Data Chunks MAY be retained (this is an implementation 2772 specific option). 2774 - A notification of RESTART SHOULD be sent to the ULP instead 2775 of a "COMMUNICATION LOST" notification. 2777 All the congestion control parameters (e.g., cwnd, ssthresh) related 2778 to this peer MUST be reset to their initial values (see Section 2779 6.2.1). 2781 After this the endpoint shall enter the ESTABLISHED state. 2783 If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes 2784 the peer has restarted (Action A), it MUST NOT setup a new 2785 association but instead resend the SHUTDOWN ACK and send an ERROR 2786 chunk with a "Cookie Received while Shutting Down" error cause to 2787 its peer. 2789 (B)In this case, both sides may be attempting to start an 2790 association at about the same time but the INIT-Ack of one side 2791 was lost, and the other side completed the INIT sequence. 2792 In this case, the endpoint MUST update the Local Verification 2793 Tag from the Cookie, stay in or move to the Established State, 2794 stop any init or cookie timers that may be running and 2795 send a Cookie Ack. 2797 (C)In this case, a software error may have occurred in the peer. The 2798 peer changed its Verification Tag while it was in the Cookie Sent 2799 state. The endpoint MAY stay in or move to the Established state, 2800 but it must stop any init or cookie timers that may be running, 2801 update its Verification Tag from the Cookie and send a 2802 Cookie Ack. 2804 (D)In this case, a software error may have occurred in the local 2805 endpoint. The Verification Tag has been changed when in 2806 the COOKIE-ECHOED state. The endpoint MAY stay in or enter the 2807 Established state but it MUST update its peers Verification 2808 Tag from the Cookie, stop any init or cookie timers that may 2809 be running and send a Cookie Ack. 2811 (E)In this case, both sides may be attempting to start an 2812 association at about the same time but the peer endpoint 2813 started its INIT after responding to the local endpoints 2814 INIT. Thus it picked a new Verification Tag not being aware 2815 of the previous Tag it had sent this endpoint. The endpoint 2816 should stay in or enter the Established state but it MUST update 2817 its peers Verification Tag from the Cookie, stop any init 2818 or cookie timers that may running and send a Cookie Ack. 2820 (F)In this case, an invalid cookie has been sent. The Cookie 2821 MUST be silently discarded. 2823 Note: The "peer's Verification Tag" is the tag received in the 2824 Initiate Tag field of the INIT or INIT ACK chunk. 2826 5.2.5 Handle Duplicate COOKIE-ACK. 2828 At any state other than COOKIE-ECHOED, an endpoint should silently 2829 discard a received COOKIE ACK chunk. 2831 5.2.6 Handle Stale COOKIE Error 2833 Receipt of an Operational ERROR chunk with a "Stale Cookie" error 2834 cause indicates one of a number of possible events: 2836 A) That the association failed to completely setup before the 2837 State Cookie issued by the sender was processed. 2839 B) An old State Cookie was processed after setup completed. 2841 C) An old State Cookie is received from someone that the receiver is 2842 not interested in having an association with and the ABORT 2843 chunk was lost. 2845 When processing an Operational ERROR chunk with a "Stale Cookie" error cause an 2846 endpoint should first examine if an association is in the process of 2847 being setup, i.e. the association is in the COOKIE-ECHOED state. In all 2848 cases if the association is NOT in the COOKIE-ECHOED state, the ERROR 2849 chunk should be silently discarded. 2851 If the association is in the COOKIE-ECHOED state, the endpoint may elect 2852 one of the following three alternatives. 2854 1) Send a new INIT chunk to the endpoint to generate a new State 2855 Cookie and re-attempt the setup procedure. 2857 2) Discard the TCB and report to the upper layer the inability to 2858 setup the association. 2860 3) Send a new INIT chunk to the endpoint, adding a Cookie 2861 Preservative parameter requesting an extension to the lifetime of 2862 the State Cookie. When calculating the time extension, an 2863 implementation SHOULD use the RTT information measured based on the 2864 previous COOKIE ECHO / ERROR exchange, and should add no more 2865 than 1 second beyond the measured RTT, due to long State Cookie 2866 lifetimes making the endpoint more subject to a replay attack. 2868 5.3 Other Initialization Issues 2870 5.3.1 Selection of Tag Value 2872 Initiate Tag values should be selected from the range of 1 to 2873 2**32 - 1. It is very important that the Initiate Tag value be 2874 randomized to help protect against "man in the middle" and "sequence 2875 number" attacks. The methods described in [RFC1750] can be used for 2876 the Initiate Tag randomization. Careful selection of Initiate Tags is 2877 also necessary to prevent old duplicate packets from previous 2878 associations being mistakenly processed as belonging to the current 2879 association. 2881 Moreover, the Verification Tag value used by either endpoint in a given 2882 association MUST NOT change during the lifetime of an 2883 association. A new Verification Tag value MUST be used each 2884 time the endpoint tears-down and then re-establishes an association to 2885 the same peer. 2887 6. User Data Transfer 2889 Data transfer MUST only happen in the ESTABLISHED, SHUTDOWN-PENDING, 2890 and SHUTDOWN-RECEIVED states. The only exception to this is that DATA 2891 chunks are allowed to be bundled with an outbound COOKIE ECHO chunk 2892 when in COOKIE-WAIT state. 2894 A SCTP receiver MUST be able to receive a minimum of 1500 bytes 2895 in one SCTP packet. This means that a SCTP endpoint MUST NOT 2896 indicate less than 1500 bytes in its Initial a_rwnd sent in the 2897 INIT or INIT ACK. 2899 For transmission efficiency, SCTP defines mechanisms for bundling of 2900 small user messages and fragmentation of large user messages. 2901 The following diagram depicts the flow of user messages through SCTP. 2903 In this section the term "data sender" refers to the endpoint that 2904 transmits a DATA chunk and the term "data receiver" refers to the 2905 endpoint that receives a DATA chunk. A data receiver will transmit 2906 SACK chunks. 2908 +--------------------------+ 2909 | User Messages | 2910 +--------------------------+ 2911 SCTP user ^ | 2912 ==================|==|======================================= 2913 | v (1) 2914 +------------------+ +--------------------+ 2915 | SCTP DATA Chunks | |SCTP Control Chunks | 2916 +------------------+ +--------------------+ 2917 ^ | ^ | 2918 | v (2) | v (2) 2919 +--------------------------+ 2920 | SCTP packets | 2921 +--------------------------+ 2922 SCTP ^ | 2923 ===========================|==|=========================== 2924 | v 2925 Connectionless Packet Transfer Service (e.g., IP) 2927 Notes: 2928 (1) When converting user messages into DATA chunks, an endpoint 2929 will fragment user messages larger than the current association 2930 path MTU into multiple DATA chunks. The data receiver will 2931 normally reassemble the fragmented message from DATA chunks 2932 before delivery to the user (see Section 6.9 for details). 2934 (2) Multiple DATA and control chunks may be bundled by the 2935 sender into a single SCTP packet for transmission, as long as 2936 the final size of the packet does not exceed the current path 2937 MTU. The receiver will unbundle the packet back into 2938 the original chunks. Control chunks MUST come before 2939 DATA chunks in the packet. 2941 Figure 5: Illustration of User Data Transfer 2943 The fragmentation and bundling mechanisms, as detailed in Sections 6.9 2944 and 6.10, are OPTIONAL to implement by the data sender, but they MUST 2945 be implemented by the data receiver, i.e., an endpoint MUST 2946 properly receive and process bundled or fragmented data. 2948 6.1 Transmission of DATA Chunks 2950 This document is specified as if there is a single retransmission 2951 timer per destination transport address, but implementations MAY have 2952 a retransmission timer for each DATA chunk. 2954 The following general rules MUST be applied by the data sender for 2955 transmission and/or retransmission of outbound DATA chunks: 2957 A) At any given time, the data sender MUST NOT transmit new data to any 2958 destination transport address if its peer's rwnd indicates that the 2959 peer has no buffer space (i.e. rwnd is 0, see Section 6.2.1). 2961 However, regardless of the value of rwnd (including if it is 0), 2962 the data sender can always have one DATA chunk in flight to the 2963 receiver if allowed by cwnd (see rule B below). This rule 2964 allows the sender to probe for a change in rwnd that the sender 2965 missed due to the SACK having been lost in transit from 2966 the data receiver to the data sender. 2968 B) At any given time, the sender MUST NOT transmit new data to a 2969 given transport address if it has cwnd or more bytes of data 2970 outstanding to that transport address. 2972 C) When the time comes for the sender to transmit, before sending 2973 new DATA chunks, the sender MUST first transmit any outstanding 2974 DATA chunks which are marked for retransmission (limited by the 2975 current cwnd). 2977 D) Then, the sender can send out as many new DATA chunks as Rule A and 2978 Rule B above allow. 2980 Multiple DATA chunks committed for transmission MAY be 2981 bundled in a single packet. Furthermore, DATA chunks being 2982 retransmitted MAY be bundled with new DATA chunks, as long as the 2983 resulting packet size does not exceed the path MTU. A ULP 2984 may request that no bundling is performed but this should only turn off 2985 any delays that a SCTP implementation may be using to increase 2986 bundling efficiency. It does not in itself stop all bundling 2987 from occurring (i.e. in case of congestion or retransmission). 2989 Before an endpoint transmits a DATA chunk, if any received DATA 2990 chunks have not been acknowledged (e.g., due to delayed ack), the 2991 sender should create a SACK and bundle it with the outbound DATA 2992 chunk, as long as the size of the final SCTP packet does not exceed 2993 the current MTU. See Section 6.2. 2995 IMPLEMENTATION NOTE: When the window is full (i.e., transmission is 2996 disallowed by Rule A and/or Rule B), the sender MAY still accept 2997 send requests from its upper layer, but MUST transmit no more DATA 2998 chunks until some or all of the outstanding DATA chunks are 2999 acknowledged and transmission is allowed by Rule A and Rule B 3000 again. 3002 Whenever a transmission or retransmission is made to any address, if 3003 the T3-rtx timer of that address is not currently running, the sender 3004 MUST start that timer. If the timer for that address is already 3005 running, the sender MUST restart the timer if the earliest 3006 (i.e., lowest TSN) outstanding DATA chunk sent to that address is being 3007 retransmitted. Otherwise, the data sender MUST NOT restart the timer. 3009 When starting or restarting the T3-rtx timer, the timer value must be 3010 adjusted according to the timer rules defined in Sections 6.3.2, 3011 and 6.3.3. 3013 Note: The data sender SHOULD NOT use a TSN that is more than 3014 2**31 - 1 above the beginning TSN of the current send window. 3016 6.2 Acknowledgement on Reception of DATA Chunks 3018 The SCTP endpoint MUST always acknowledge the reception of each valid 3019 DATA chunk. 3021 The guidelines on delayed acknowledgement algorithm specified in 3022 Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an 3023 acknowledgement SHOULD be generated for at least every second packet 3024 (not every second DATA chunk) received, and SHOULD be generated within 3025 200 ms of the arrival of any unacknowledged DATA chunk. In some 3026 situations it may be beneficial for an SCTP transmitter to be more 3027 conservative than the algorithms detailed in this document allow. 3028 However, an SCTP transmitter MUST NOT be more aggressive than the 3029 following algorithms allow. 3031 A SCTP receiver MUST NOT generate more than one SACK for every 3032 incoming packet, other than to update the offered window as the 3033 receiving application consumes new data. 3035 IMPLEMENTATION NOTE: The maximum delay for generating an 3036 acknowledgement may be configured by the SCTP administrator, either 3037 statically or dynamically, in order to meet the specific 3038 timing requirement of the protocol being carried. 3040 An implementation MUST NOT allow the maximum delay to be configured to 3041 be more than 500 ms. In other words an implementation MAY lower this 3042 value below 500ms but MUST NOT raise it above 500ms. 3044 Acknowledgements MUST be sent in SACK chunks unless shutdown was 3045 requested by the ULP in which case an endpoint MAY send an 3046 acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the 3047 reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk 3048 format. In particular, the SCTP endpoint MUST fill in the Cumulative 3049 TSN Ack field to indicate the latest sequential TSN (of a valid DATA 3050 chunk) it has received. Any received DATA chunks with TSN greater than 3051 the value in the Cumulative TSN Ack field SHOULD also be reported in 3052 the Gap Ack Block fields. 3054 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3055 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3056 chunk to acknowledge DATA chunks received out of order . 3058 When a packet arrives with duplicate DATA chunk(s) and with no new 3059 DATA chunk(s), the endpoint MUST immediately send a SACK with no 3060 delay. If a packet arrives with duplicate DATA chunk(s) bundled with 3061 new DATA chunks, the endpoint MAY immediately send a SACK. Normally 3062 receipt of duplicate DATA chunks will occur when the original SACK 3063 chunk was lost and the peer's RTO has expired. The duplicate TSN 3064 number(s) SHOULD be reported in the SACK as duplicate. 3066 When an endpoint receives a SACK, it MAY use the Duplicate TSN 3067 information to determine if SACK loss is occurring. Further use of 3068 this data is for future study. 3070 The data receiver is responsible for maintaining its receive buffers. 3071 The data receiver SHOULD notify the data sender in a timely manner of 3072 changes in its ability to receive data. How an implementation manages 3073 its receive buffers is dependent on many factors (e.g., Operating 3074 System, memory management system, amount of memory, etc.). However, 3075 the data sender strategy defined in Section 6.2.1 is based on the 3076 assumption of receiver operation similar to the following: 3078 A) At initialization of the association, the endpoint tells the 3079 peer how much receive buffer space it has allocated to the 3080 association in the INIT or INIT ACK. The endpoint sets a_rwnd 3081 to this value. 3083 B) As DATA chunks are received and buffered, decrement a_rwnd by 3084 the number of bytes received and buffered. This is, in effect, 3085 closing rwnd at the data sender and restricting the amount of 3086 data it can transmit. 3088 C) As DATA chunks are delivered to the ULP and released from the 3089 receive buffers, increment a_rwnd by the number of bytes 3090 delivered to the upper layer. This is, in effect, opening up 3091 rwnd on the data sender and allowing it to send more data. The 3092 data receiver SHOULD NOT increment a_rwnd unless it has released 3093 bytes from its receive buffer. For example, if the receiver is 3094 holding fragmented DATA chunks in a reassembly queue, it should 3095 not increment a_rwnd. 3097 D) When sending a SACK, the data receiver SHOULD place the 3098 current value of a_rwnd into the a_rwnd field. The data 3099 receiver SHOULD take into account that the data sender will not 3100 retransmit DATA chunks that are acked via the Cumulative TSN Ack 3101 (i.e., will drop from its retransmit queue). 3103 Under certain circumstances, the data receiver may need to drop 3104 DATA chunks that it has received but hasn't released from its receive 3105 buffers (i.e., delivered to the ULP). These DATA chunks may have 3106 been acked in Gap Ack Blocks. For example, the data receiver may be 3107 holding data in its receive buffers while reassembling a fragmented 3108 user message from its peer when it runs out of receive buffer space. 3109 It may drop these DATA chunks even though it has acknowledged them in 3110 Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT include 3111 them in Gap Ack Blocks in subsequent SACKs until they are received again 3112 via retransmission. In addition, the endpoint should take into account the 3113 dropped data when calculating its a_rwnd. 3115 An endpoint SHOULD NOT revoke a SACK and discard data. Only in extreme 3116 circumstance should an endpoint use this procedure (such as out of buffer 3117 space). The data receiver should take into account that dropping data that 3118 has been acked in Gap Ack Blocks can result in suboptimal retransmission 3119 strategies in the data sender and thus in suboptimal performance. 3121 The following example illustrates the use of delayed acknowledgements: 3123 Endpoint A Endpoint Z 3125 {App sends 3 messages; strm 0} 3126 DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed) 3127 (Start T3-rtx timer) 3129 DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack) 3130 /------- SACK [TSN Ack=8,block=0] 3131 (cancel T3-rtx timer) <-----/ 3132 ... 3133 ... 3135 DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed) 3136 (Start T3-rtx timer) 3137 ... 3138 {App sends 1 message; strm 1} 3139 (bundle SACK with DATA) 3140 /----- SACK [TSN Ack=9,block=0] \ 3141 / DATA [TSN=6,Strm=1,Seq=2] 3142 (cancel T3-rtx timer) <------/ (Start T3-rtx timer) 3144 (ack delayed) 3145 ... 3146 (send ack) 3147 SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer) 3149 Figure 5: Delayed Acknowledgment Example 3151 If an endpoint receives a DATA chunk with no user data (i.e., the 3152 Length field is set to 16) it MUST send an ABORT with error cause set 3153 to "No User Data". 3155 An endpoint SHOULD NOT send a DATA chunk with no user data part. 3157 6.2.1 Processing a Received SACK 3159 Each SACK an endpoint receives contains an a_rwnd value. This value 3160 represents the amount of buffer space the data receiver, at the time 3161 of transmitting the SACK, has left of its total receive buffer space (as 3162 specified in the INIT/INIT ACK). Using a_rwnd, Cumulative TSN Ack and Gap 3163 Ack Blocks, the data sender can develop a representation of the peer's 3164 receive buffer space. 3166 One of the problems the data sender must take into account when processing 3167 a SACK is that a SACK can be received out of order. That is, a SACK sent 3168 by the data receiver can pass an earlier SACK and be received first by the 3169 data sender. If a SACK is received out of order, the data sender can 3170 develop an incorrect view of the peer's receive buffer space. 3172 Since there is no explicit identifier that can be used to detect 3173 out-of-order SACKs, the data sender must use heuristics to determine if a 3174 SACK is new. 3176 An endpoint SHOULD use the following rules to calculate the rwnd, using the 3177 a_rwnd value, the Cumulative TSN Ack and Gap Ack Blocks in a received SACK. 3179 A) At the establishment of the association, the endpoint 3180 initializes the rwnd to the Advertised Receiver Window 3181 Credit (a_rwnd) the peer specified in the INIT or INIT ACK. 3183 B) Any time a DATA chunk is transmitted (or retransmitted) 3184 to a peer, the endpoint subtracts the data size of the 3185 chunk from the rwnd of that peer. 3187 C) Any time a DATA chunk is marked for retransmission (via 3188 either T3-rtx timer expiration (Section 6.3.3)or via fast 3189 retransmit (Section 7.2.4)), add the data size of 3190 those chunks to the rwnd. 3192 Note: If the implementation is maintaining a timer on each 3193 DATA chunk then only DATA chunks whose timer expired would 3194 be marked for retransmission. 3196 D) Any time a SACK arrives, the endpoint performs the following: 3198 i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, 3199 then drop the SACK. Since Cumulative TSN Ack is monotonically 3200 increasing, a SACK whose Cumulative TSN Ack is less than the 3201 Cumulative TSN Ack Point indicates an out-of-order SACK. 3203 ii) Set rwnd equal to the newly received a_rwnd minus the number 3204 of bytes still outstanding after processing the Cumulative TSN Ack 3205 and the Gap Ack Blocks. 3207 iii) If the SACK is missing a TSN that was previously 3208 acknowledged via a Gap Ack Block (e.g., the data receiver 3209 reneged on the data), then mark the corresponding DATA chunk 3210 as available for retransmit: Mark it as missing for fast 3211 retransmit as described in Section 7.2.4 and if no retransmit 3212 timer is running for the destination address to which the DATA 3213 chunk was originally transmitted, then T3-rtx is started for 3214 that destination address. 3216 6.3 Management of Retransmission Timer 3218 An SCTP endpoint uses a retransmission timer T3-rtx to ensure data 3219 delivery in the absence of any feedback from its peer. The duration of 3220 this timer is referred to as RTO (retransmission timeout). 3222 When an endpoint's peer is multi-homed, the endpoint will calculate a 3223 separate RTO for each different destination transport address of its 3224 peer endpoint. 3226 The computation and management of RTO in SCTP follows closely how 3227 TCP manages its retransmission timer. To compute the current RTO, an 3228 endpoint maintains two state variables per destination transport 3229 address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time 3230 variation). 3232 6.3.1 RTO Calculation 3234 The rules governing the computation of SRTT, RTTVAR, and RTO are 3235 as follows: 3237 C1) Until an RTT measurement has been made for a packet sent 3238 to the given destination transport address, set RTO to the 3239 protocol parameter 'RTO.Initial'. 3241 C2) When the first RTT measurement R is made, set SRTT <- R, 3242 RTTVAR <- R/2, and RTO <- SRTT + 4 * RTTVAR. 3244 C3) When a new RTT measurement R' is made, set 3246 RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| 3247 SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' 3249 Note: The value of SRTT used in the update to RTTVAR is its value 3250 before updating SRTT itself using the second assignment. 3252 After the computation, update RTO <- SRTT + 4 * RTTVAR. 3254 C4) When data is in flight and when allowed by rule C5 below, a new 3255 RTT measurement MUST be made each round trip. Furthermore, new RTT 3256 measurements SHOULD be made no more than once per round-trip for a 3257 given destination transport address. There are two reasons for this 3258 recommendation: First, it appears that measuring more frequently 3259 often does not in practice yield any significant benefit 3260 [ALLMAN99]; second, if measurements are made more often, then the 3261 values of RTO.Alpha and RTO.Beta in rule C3 above should be 3262 adjusted so that SRTT and RTTVAR still adjust to changes at roughly 3263 the same rate (in terms of how many round trips it takes them to 3264 reflect new values) as they would if making only one measurement 3265 per round-trip and using RTO.Alpha and RTO.Beta as given in rule 3266 C3. However, the exact nature of these adjustments remains a 3267 research issue. 3269 C5) Karn's algorithm: RTT measurements MUST NOT be made using 3270 packets that were retransmitted (and thus for which it is 3271 ambiguous whether the reply was for the first instance of the 3272 packet or a later instance). 3274 C6) Whenever RTO is computed, if it is less than RTO.Min seconds 3275 then it is rounded up to RTO.Min seconds. The reason for this 3276 rule is that RTOs that do not have a high minimum value are 3277 susceptible to unnecessary timeouts [ALLMAN99]. 3279 C7) A maximum value may be placed on RTO provided it is at least 3280 RTO.max seconds. 3282 There is no requirement for the clock granularity G used for computing 3283 RTT measurements and the different state variables, other than: 3285 G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust 3286 RTTVAR <- G. 3288 Experience [ALLMAN99] has shown that finer clock granularities 3289 (<= 100 msec) perform somewhat better than more coarse granularities. 3291 6.3.2 Retransmission Timer Rules 3293 The rules for managing the retransmission timer are as follows: 3295 R1) Every time a DATA chunk is sent to any address (including 3296 a retransmission), if the T3-rtx timer of that address is not 3297 running, start it running so that it will expire after the RTO of 3298 that address. The RTO used here is that obtained after any doubling 3299 due to previous T3-rtx timer expirations on the corresponding 3300 destination address as discussed in rule E2 below. 3302 R2) Whenever all outstanding data sent to an address have been 3303 acknowledged, turn off the T3-rtx timer of that address. 3305 R3) Whenever a SACK is received that acknowledges the DATA chunk with 3306 the earliest outstanding TSN for that address, restart T3-rtx timer 3307 for that address with its current RTO. 3309 (R4) Whenever a SACK is received missing a TSN that was previously acknowledged 3310 via a Gap Ack Block, start T3-rtx for the destination address to which 3311 the DATA chunk was originally transmitted if it is not already running. 3313 The following example shows the use of various timer rules (assuming 3314 the receiver uses delayed acks). 3316 Endpoint A Endpoint Z 3317 {App begins to send} 3318 Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed) 3319 (Start T3-rtx timer) 3320 {App sends 1 message; strm 1} 3321 (bundle ack with data) 3322 DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0] \ 3323 \ / DATA [TSN=6,Strm=1,Seq=2] 3324 \ / (Start T3-rtx timer) 3325 \ 3326 / \ 3327 (Re-start T3-rtx timer) <------/ \--> (ack delayed) 3328 (ack delayed) 3329 ... 3330 {send ack} 3331 SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer) 3332 .. 3333 (send ack) 3334 (Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0] 3336 Figure 6 - Timer Rule Examples 3338 6.3.3 Handle T3-rtx Expiration 3340 Whenever the retransmission timer T3-rtx expires for a destination 3341 address, do the following: 3343 E1) For the destination address for which the timer expires, adjust its 3344 ssthresh with rules defined in Section 7.2.3 and set the 3345 cwnd <- MTU. 3347 E2) For the destination address for which the timer expires, set 3348 RTO <- RTO * 2 ("back off the timer"). The maximum value discussed 3349 in rule C7 above (RTO.max) may be used to provide an upper bound 3350 to this doubling operation. 3352 E3) Determine how many of the earliest (i.e., lowest TSN) outstanding 3353 DATA chunks for the address for which the T3-rtx has expired will 3354 fit into a single packet, subject to the MTU constraint for the 3355 path corresponding to the destination transport address to which 3356 the retransmission is being sent (this may be different from the 3357 address for which the timer expires [see Section 6.4]). Call this 3358 value K. Bundle and retransmit those K DATA chunks in a single 3359 packet to the destination endpoint. 3361 E4) Start the retransmission timer T3-rtx on the destination address 3362 to which the retransmission is sent, if rule R1 above indicates to 3363 do so. The RTO to be used for starting T3-rtx should be the 3364 one for the destination address to which the retransmission is 3365 sent, which, when the receiver is multi-homed, may be different 3366 from the destination address for which the timer expired (see 3367 Section 6.4 below). 3369 After retransmitting, once a new RTT measurement is obtained 3370 (which can happen only when new data has been sent and acknowledged, 3371 per rule C5, or for a measurement made from a HEARTBEAT [see Section 3372 8.3]), the computation in rule C3 is performed, including the 3373 computation of RTO, which may result in "collapsing" RTO back down 3374 after it has been subject to doubling (rule E2). 3376 Note: Any DATA chunks that were sent to the address for which the 3377 T3-rtx timer expired but did not fit in one MTU (rule E3 above), 3378 should be marked for retransmission and sent as soon as cwnd allows 3379 (normally when a SACK arrives). 3381 The final rule for managing the retransmission timer concerns failover 3382 (see Section 6.4.1): 3384 F1) Whenever an endpoint switches from the current destination 3385 transport address to a different one, the current retransmission 3386 timers are left running. As soon as the endpoint transmits a packet 3387 containing DATA chunk(s) to the new transport address, start the 3388 timer on that transport address, using the RTO value of the 3389 destination address to which the data is being sent, if rule R1 3390 indicates to do so. 3392 6.4 Multi-homed SCTP Endpoints 3394 An SCTP endpoint is considered multi-homed if there are more than one 3395 transport address that can be used as a destination address to reach 3396 that endpoint. 3398 Moreover, the ULP of an endpoint shall select one of the multiple 3399 destination addresses of a multi-homed peer endpoint as the primary 3400 path (see Sections 5.1.2 and 10.1 for details). 3402 By default, an endpoint SHOULD always transmit to the primary 3403 path, unless the SCTP user explicitly specifies the destination 3404 transport address (and possibly source transport address) to use. 3406 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 3407 etc.) to the same destination transport address from which it received 3408 the DATA or control chunk to which it is replying. This rule should 3409 also be followed if the endpoint is bundling DATA chunks together 3410 with the reply chunk. 3412 However, when acknowledging multiple DATA chunks received in packets 3413 from different source addresses in a single SACK, the SACK chunk may be 3414 transmitted to one of the destination transport addresses from which 3415 the DATA or control chunks being acknowledged were received. 3417 When a receiver of a duplicate DATA chunk sends a SACK to a multi-homed 3418 endpoint it MAY be beneficial to vary the destination address and not 3419 use the source address of the DATA chunk. The reason being that 3420 receiving a duplicate from a multi-homed endpoint might indicate that 3421 the return path (as specified in the source address of the DATA chunk) 3422 for the SACK is broken. 3424 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 3425 retransmit a chunk to an active destination transport address that is 3426 different from the last destination address to which the DATA chunk was 3427 sent. 3429 Retransmissions do not affect the total outstanding data 3430 count. However, if the DATA chunk is retransmitted onto a different 3431 destination address, both the outstanding data counts on the new 3432 destination address and the old destination address to which the data 3433 chunk was last sent shall be adjusted accordingly. 3435 6.4.1 Failover from Inactive Destination Address 3436 Some of the transport addresses of a multi-homed SCTP endpoint may 3437 become inactive due to either the occurrence of certain error 3438 conditions (see Section 8.2) or adjustments from SCTP user. 3440 When there is outbound data to send and the primary path becomes 3441 inactive (e.g., due to failures), or where the SCTP user explicitly 3442 requests to send data to an inactive destination transport address, 3443 before reporting an error to its ULP, the SCTP endpoint should try to 3444 send the data to an alternate active destination transport address if 3445 one exists. 3447 When retransmitting data, if the endpoint is multi-homed, it should 3448 consider each source-destination address pair in its retransmission 3449 selection policy. When retransmitting the endpoint should attempt to 3450 pick the most divergent source-destination pair from the original 3451 source-destination pair to which the packet was transmitted. 3453 Note: Rules for picking the most divergent source-destination pair 3454 are an implementation decision and is not specified within this 3455 document. 3457 6.5 Stream Identifier and Stream Sequence Number 3459 Every DATA chunk MUST carry a valid stream identifier. If an endpoint 3460 receives a DATA chunk with an invalid stream identifier, it shall 3461 acknowledge the reception of the DATA chunk following the normal 3462 procedure, immediately send an ERROR chunk with cause set to "Invalid 3463 Stream Identifier" (see Section 3.3.10) and discard the DATA chunk. 3464 The endpoint may bundle the ERROR chunk in the same packet as the SACK 3465 as long as the ERROR follows the SACK. 3467 The stream sequence number in all the streams shall start from 0 3468 when the association is established. Also, when the stream sequence 3469 number reaches the value 65535 the next stream sequence number shall 3470 be set to 0. 3472 6.6 Ordered and Unordered Delivery 3474 Within a stream, an endpoint MUST deliver DATA chunks received with the 3475 U flag set to 0 to the upper layer according to the order of their 3476 stream sequence number. If DATA chunks arrive out of order of their 3477 stream sequence number, the endpoint MUST hold the received DATA chunks 3478 from delivery to the ULP until they are re-ordered. 3480 However, an SCTP endpoint can indicate that no ordered delivery is 3481 required for a particular DATA chunk transmitted within the stream by 3482 setting the U flag of the DATA chunk to 1. 3484 When an endpoint receives a DATA chunk with the U flag set to 1, it 3485 must bypass the ordering mechanism and immediately deliver the data to 3486 the upper layer (after re-assembly if the user data is fragmented by 3487 the data sender). 3489 This provides an effective way of transmitting "out-of-band" data in a 3490 given stream. Also, a stream can be used as an "unordered" stream by 3491 simply setting the U flag to 1 in all DATA chunks sent through that 3492 stream. 3494 IMPLEMENTATION NOTE: When sending an unordered DATA chunk, an 3495 implementation may choose to place the DATA chunk in an outbound 3496 packet that is at the head of the outbound transmission queue if 3497 possible. 3499 The 'Stream Sequence Number' field in a DATA chunk with U flag set to 1 3500 has no significance. The sender can fill it with arbitrary value, but 3501 the receiver MUST ignore the field. 3503 Note: When transmitting ordered and unordered data, an endpoint does 3504 not increment its Stream Sequence Number when transmitting a DATA 3505 chunk with U flag set to 1. 3507 6.7 Report Gaps in Received DATA TSNs 3509 Upon the reception of a new DATA chunk, an endpoint shall examine 3510 the continuity of the TSNs received. If the endpoint detects a gap 3511 in the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack 3512 Blocks immediately. The data receiver continues sending a SACK after 3513 receipt of each SCTP packet that doesn't fill the gap. 3515 Based on the Gap Ack Block from the received SACK, the endpoint 3516 can calculate the missing DATA chunks and make decisions on whether to 3517 retransmit them (see Section 6.2.1 for details). 3519 Multiple gaps can be reported in one single SACK (see Section 3.3.4). 3521 When its peer is multi-homed, the SCTP endpoint SHOULD always 3522 try to send the SACK to the same destination address from which the 3523 last DATA chunk was received. 3525 Upon the reception of a SACK, the endpoint MUST remove all DATA 3526 chunks which have been acknowledged by the SACK's Cumulative TSN Ack 3527 from its transmit queue. The endpoint MUST also treat all the DATA 3528 chunks with TSNs not included in the Gap Ack Blocks reported by the 3529 SACK as "missing". The number of "missing" reports for each outstanding 3530 DATA chunk MUST be recorded by the data sender in order to make 3531 retransmission decisions. See Section 7.2.4 for details. 3533 The following example shows the use of SACK to report a gap. 3535 Endpoint A Endpoint Z 3536 {App sends 3 messages; strm 0} 3537 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 3538 (Start T3-rtx timer) 3540 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 3541 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 3542 immediately send ack) 3543 /----- SACK [TSN Ack=6,Block=1, 3544 / Strt=2,End=2] 3545 <-----/ 3546 (remove 6 from out-queue, 3547 and mark 7 as "1" missing report) 3549 Figure 8 - Reporting a Gap using SACK 3551 The maximum number of Gap Ack Blocks that can be reported within a 3552 single SACK chunk is limited by the current path MTU. When a single 3553 SACK can not cover all the Gap Ack Blocks needed to be reported due to 3554 the MTU limitation, the endpoint MUST send only one SACK, reporting the 3555 Gap Ack Blocks from the lowest to highest TSNs, within the size limit 3556 set by the MTU, and leave the remaining highest TSN numbers 3557 unacknowledged. 3559 6.8 Adler-32 Checksum Calculation 3561 When sending an SCTP packet, the endpoint MUST strengthen the data 3562 integrity of the transmission by including the Adler-32 checksum 3563 value calculated on the packet, as described below. 3565 After the packet is constructed (containing the SCTP common header 3566 and one or more control or DATA chunks), the transmitter shall: 3568 1) Fill in the proper Verification Tag in the SCTP common header and 3569 initialize the checksum field to 0's. 3571 2) Calculate the Adler-32 checksum of the whole packet, including the 3572 SCTP common header and all the chunks. Refer to appendix B 3573 for details of the Adler-32 algorithm. And, 3575 3) Put the resultant value into the checksum field in the 3576 common header, and leave the rest of the bits unchanged. 3578 When an SCTP packet is received, the receiver MUST first check the 3579 Adler-32 checksum: 3581 1) Store the received Adler-32 checksum value aside, 3583 2) Replace the 32 bits of the checksum field in the received 3584 SCTP packet with all '0's and calculate an Adler-32 checksum 3585 value of the whole received packet. And, 3587 3) Verify that the calculated Adler-32 checksum is the same as the 3588 received Adler-32 checksum, If not, the receiver MUST treat the 3589 packet as an invalid SCTP packet. 3591 The default procedure for handling invalid SCTP packets is to 3592 silently discard them. 3594 6.9 Fragmentation and Reassembly 3596 An endpoint MAY support fragmentation when sending DATA chunks, but 3597 MUST support reassembly when receiving DATA chunks. If an endpoint 3598 supports fragmentation, it MUST fragment a user message if the size of 3599 the user message to be sent causes the outbound SCTP packet size to 3600 exceed the current MTU. If an implementation does not support 3601 fragmentation of outbound user messages, the endpoint must return an 3602 error to its upper layer and not attempt to send the user message. 3604 IMPLEMENTATION NOTE: In this error case, the Send primitive 3605 discussed in Section 10.1 would need to return an error to the upper 3606 layer. 3608 If its peer is multi-homed, the endpoint shall choose a 3609 size no larger than the association Path MTU. The association Path 3610 MTU is the smallest Path MTU of all destination addresses. 3612 Note: Once a message is fragmented it cannot be re-fragmented. 3613 Instead if the PMTU has been reduced, then IP fragmentation must be 3614 used. Please see Section 7.3 for details of PMTU discovery. 3616 When determining when to fragment, the SCTP implementation MUST take 3617 into account the SCTP packet header as well as the DATA chunk 3618 header(s). The implementation MUST also take into account the space 3619 required for a SACK chunk if bundling a SACK chunk with the DATA chunk. 3621 Fragmentation takes the following steps: 3623 1) The data sender MUST break the user message into a series of 3624 DATA chunks such that each chunk plus SCTP overhead fits into an IP 3625 datagram smaller than or equal to the association Path MTU. 3627 2) The transmitter MUST then assign, in sequence, a separate TSN to 3628 each of the DATA chunks in the series. The transmitter assigns the 3629 same SSN to each of the DATA chunks. If the user indicates that the 3630 user message is to be delivered using unordered delivery, then the U 3631 flag of each DATA chunk of the user message MUST be set to 1. 3633 3) The transmitter MUST also set the B/E bits of the first DATA chunk 3634 in the series to '10', the B/E bits of the last DATA chunk in the 3635 series to '01', and the B/E bits of all other DATA chunks in the 3636 series to '00'. 3638 An endpoint MUST recognize fragmented DATA chunks by examining the B/E 3639 bits in each of the received DATA chunks, and queue the fragmented DATA 3640 chunks for re-assembly. Once the user message is reassembled, SCTP 3641 shall pass the re-assembled user message to the specific stream for 3642 possible re-ordering and final dispatching. 3644 Note: If the data receiver runs out of buffer space while still 3645 waiting for more fragments to complete the re-assembly of the 3646 message, it should dispatch part of its inbound message through a 3647 partial delivery API (see Section 10), freeing some of its receive 3648 buffer space so that the rest of the message may be received. 3650 6.10 Bundling 3652 An endpoint bundles chunks by simply including multiple chunks in one 3653 outbound SCTP packet. The total size of the resultant IP datagram, 3654 including the SCTP packet and IP headers, MUST be less or equal to the 3655 current Path MTU. 3657 If its peer endpoint is multi-homed, the sending endpoint shall choose 3658 a size no larger than the latest MTU of the current primary path. 3660 When bundling control chunks with DATA chunks, an endpoint MUST place 3661 control chunks first in the outbound SCTP packet. The transmitter 3662 MUST transmit DATA chunks within a SCTP packet in increasing order of 3663 TSN. 3664 Note: Since control chunks must be placed first in a packet and 3665 since DATA chunks must be transmitted before SHUTDOWN or SHUTDOWN ACK 3666 chunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK 3667 chunks. 3669 Partial chunks MUST NOT be placed in an SCTP packet. 3671 An endpoint MUST process received chunks in their order in the packet. 3672 The receiver uses the chunk length field to determine the end of a 3673 chunk and beginning of the next chunk taking account of the fact that 3674 all chunks end on a 4 byte boundary. If the receiver detects a partial 3675 chunk, it MUST drop the chunk. 3677 An endpoint MUST NOT bundle INIT, INIT ACK or SHUTDOWN COMPLETE with 3678 any other chunks. 3680 7. Congestion control 3682 Congestion control is one of the basic functions in SCTP. 3683 For some applications, it may be likely that adequate resources will 3684 be allocated to SCTP traffic to assure prompt delivery of 3685 time-critical data - thus it would appear to be unlikely, during 3686 normal operations, that transmissions encounter severe congestion 3687 conditions. However SCTP must operate under adverse operational 3688 conditions, which can develop upon partial network failures or 3689 unexpected traffic surges. In such situations SCTP must follow correct 3690 congestion control steps to recover from congestion quickly in order 3691 to get data delivered as soon as possible. In the absence of network 3692 congestion, these preventive congestion control algorithms should show 3693 no impact on the protocol performance. 3695 IMPLEMENTATION NOTE: As far as its specific performance requirements 3696 are met, an implementation is always allowed to adopt a more 3697 conservative congestion control algorithm than the one defined 3698 below. 3700 The congestion control algorithms used by SCTP are based on 3701 [RFC2581]. This section describes how the algorithms defined in 3702 RFC2581 are adapted for use in SCTP. We first list differences in 3703 protocol designs between TCP and SCTP, and then describe SCTP's 3704 congestion control scheme. The description will use the same 3705 terminology as in TCP congestion control whenever appropriate. 3707 SCTP congestion control is always applied to the entire association, 3708 and NOT to individual streams. 3710 7.1 SCTP Differences from TCP Congestion control 3712 Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as the 3713 TCP SACK. TCP considers the information carried in the SACK as advisory 3714 information only. SCTP considers the information carried in the Gap Ack 3715 Blocks in the SACK chunk as advisory. In SCTP, any DATA chunk that has 3716 been acknowledged by SACK, including DATA that arrived at the receiving 3717 end out of order, are NOT considered fully delivered until the 3718 Cumulative TSN Ack Point passes the TSN of the DATA chunk (i.e., the 3719 DATA chunk has been acknowledged by the Cumulative TSN Ack field in the 3720 SACK). Consequently, the value of cwnd controls the amount of 3721 outstanding data, rather than (as in the case of non-SACK TCP) the 3722 upper bound between the highest acknowledged sequence number and the 3723 latest DATA chunk that can be sent within the congestion window. SCTP 3724 SACK leads to different implementations of fast-retransmit and fast- 3725 recovery than non-SACK TCP. As an example see [FALL96]. 3727 The biggest difference between SCTP and TCP, however, is multi-homing. 3728 SCTP is designed to establish robust communication associations 3729 between two endpoints each of which may be reachable by more than one 3730 transport address. Potentially different addresses may lead to 3731 different data paths between the two endpoints, thus ideally one may 3732 need a separate set of congestion control parameters for each of the 3733 paths. The treatment here of congestion control for multi-homed 3734 receivers is new with SCTP and may require refinement in the 3735 future. The current algorithms make the following assumptions: 3737 o The sender usually uses the same destination address until being 3738 instructed by the upper layer otherwise; however, SCTP may change to 3739 an alternate destination in the event an address is marked inactive 3740 (see Section 8.2). Also, SCTP may retransmit to a different 3741 transport address than the original transmission. 3743 o The sender keeps a separate congestion control parameter set for each 3744 of the destination addresses it can send to (NOT each 3745 source-destination pair but for each destination) . The parameters 3746 should decay if the address is not used for a long enough 3747 time period. 3749 o For each of the destination addresses, an endpoint does slow-start 3750 upon the first transmission to that address. 3752 Note: TCP guarantees in-sequence delivery of data to its upper-layer 3753 protocol within a single TCP session. This means that when TCP 3754 notices a gap in the received sequence number, it waits until 3755 the gap is filled before delivering the data that was received 3756 with sequence numbers higher than that of the missing data. On 3757 the other hand, SCTP can deliver data to its upper-layer 3758 protocol even if there is a gap in TSN if the Stream Sequence 3759 Numbers are in sequence for a particular stream (i.e., the 3760 missing DATA chunks are for a different stream) or if unordered 3761 delivery is indicated. Although this does not affect cwnd, it 3762 might affect rwnd calculation. 3764 7.2 SCTP Slow-Start and Congestion Avoidance 3766 The slow start and congestion avoidance algorithms MUST be used by an 3767 endpoint to control the amount of data being injected into the network. 3768 The congestion control in SCTP is employed in regard to the 3769 association, not to an individual stream. In some situations it 3770 may be beneficial for an SCTP sender to be more conservative than the 3771 algorithms allow; however, an SCTP sender MUST NOT be more aggressive 3772 than the following algorithms allow. 3774 Like TCP, an SCTP endpoint uses the following three control variables 3775 to regulate its transmission rate. 3777 o Receiver advertised window size (rwnd, in bytes), which is set by 3778 the receiver based on its available buffer space for incoming 3779 packets. 3781 Note: This variable is kept on the entire association. 3783 o Congestion control window (cwnd, in bytes), which is adjusted by 3784 the sender based on observed network conditions. 3786 Note: This variable is maintained on a per-destination address basis. 3788 o Slow-start threshold (ssthresh, in bytes), which is used by the 3789 sender to distinguish slow start and congestion avoidance phases. 3791 Note: This variable is maintained on a per-destination address basis. 3793 SCTP also requires one additional control variable, 3794 partial_bytes_acked, which is used during congestion avoidance phase to 3795 facilitate cwnd adjustment. 3797 Unlike TCP, an SCTP sender MUST keep a set of these control variables 3798 for EACH destination address of its peer (when its peer is multi- 3799 homed). 3801 7.2.1 Slow-Start 3803 Beginning data transmission into a network with unknown conditions or 3804 after a sufficiently long idle period requires SCTP to probe the 3805 network to determine the available capacity. The slow start algorithm 3806 is used for this purpose at the beginning of a transfer, or after 3807 repairing loss detected by the retransmission timer. 3809 o The initial cwnd before data transmission or after a sufficiently 3810 long idle period MUST be <= 2*MTU. 3812 o The initial cwnd after a retransmission timeout MUST be no more 3813 than 1*MTU. 3815 o The initial value of ssthresh MAY be arbitrarily high (for example, 3816 implementations MAY use the size of the receiver advertised window). 3818 o Whenever cwnd is greater than zero, the endpoint is allowed to have 3819 cwnd bytes of data outstanding on that transport address. 3821 o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use 3822 the slow start algorithm to increase cwnd (assuming the current 3823 congestion window is being fully utilized). If an incoming SACK 3824 advances the Cumulative TSN Ack Point, cwnd MUST be increased by at 3825 most the lesser of 1) the total size of the previously outstanding 3826 DATA chunk(s) acknowledged, and 2) the destination's path MTU. 3827 This protects against the ACK-Splitting attack outlined in 3828 [SAVAGE99]. 3830 In instances where its peer endpoint is multi-homed, if an endpoint 3831 receives a SACK that advances its Cumulative TSN Ack Point, then it 3832 should update its cwnd (or cwnds) apportioned to the destination 3833 addresses to which it transmitted the acknowledged data. However if 3834 the received SACK does not advance the Cumulative TSN Ack Point, the 3835 endpoint MUST NOT adjust the cwnd of any of the destination 3836 addresses. 3838 Because an endpoint's cwnd is not tied to its Cumulative TSN Ack 3839 Point, as duplicate SACKs come in, even though they may not advance 3840 the Cumulative TSN Ack Point an endpoint can still use them to clock 3841 out new data. That is, the data newly acknowledged by the SACK 3842 diminishes the amount of data now in flight to less than cwnd; and so 3843 the current, unchanged value of cwnd now allows new data to be sent. 3844 On the other hand, the increase of cwnd must be tied to the 3845 Cumulative TSN Ack Point advancement as specified above. Otherwise 3846 the duplicate SACKs will not only clock out new data, but also will 3847 adversely clock out more new data than what has just left the 3848 network, during a time of possible congestion. 3850 o When the endpoint does not transmit data on a given transport 3851 address, the cwnd of the transport address should be adjusted to 3852 max(cwnd/2, 2*MTU) per RTO. 3854 7.2.2 Congestion Avoidance 3856 When cwnd is greater than ssthresh, cwnd should be incremented 3857 by 1*MTU per RTT if the sender has cwnd or more bytes of data 3858 outstanding for the corresponding transport address. 3860 In practice an implementation can achieve this goal in the 3861 following way: 3863 o partial_bytes_acked is initialized to 0. 3865 o Whenever cwnd is greater than ssthresh, upon each SACK arrival that 3866 advances the Cumulative TSN Ack Point, increase partial_bytes_acked 3867 by the total number of bytes of all new chunks acknowledged in that 3868 SACK including chunks acknowledged by the new Cumulative TSN Ack and 3869 by Gap Ack Blocks. 3871 o When partial_bytes_acked is equal to or greater than cwnd and before 3872 the arrival of the SACK the sender had cwnd or more bytes of data 3873 outstanding (i.e., before arrival of the SACK, flightsize was greater 3874 than or equal to cwnd), increase cwnd by MTU, and reset 3875 partial_bytes_acked to (partial_bytes_acked - cwnd). 3877 o Same as in the slow start, when the sender does not transmit data on 3878 a given transport address, the cwnd of the transport address should 3879 be adjusted to max(cwnd / 2, 2*MTU) per RTO. 3881 o When all of the data transmitted by the sender has been acknowledged 3882 by the receiver, partial_bytes_acked is initialized to 0. 3884 7.2.3 Congestion Control 3886 Upon detection of packet losses from SACK (see Section 7.2.4), 3887 An endpoint should do the following: 3889 ssthresh = max(cwnd/2, 2*MTU) 3890 cwnd = ssthresh 3892 Basically, a packet loss causes cwnd to be cut in half. 3894 When the T3-rtx timer expires on an address, SCTP should perform 3895 slow start by: 3897 ssthresh = max(cwnd/2, 2*MTU) 3898 cwnd = 1*MTU 3900 and assure that no more than one DATA chunk will be in flight for that 3901 address until the endpoint receives acknowledgement for successful 3902 delivery of data to that address. 3904 7.2.4 Fast Retransmit on Gap Reports 3906 In the absence of data loss, an endpoint performs delayed 3907 acknowledgement. However, whenever an endpoint notices a hole in the 3908 arriving TSN sequence, it SHOULD start sending a SACK back every time 3909 a packet arrives carrying data until the hole is filled. 3911 Whenever an endpoint receives a SACK that indicates some TSN(s) 3912 missing, it SHOULD wait for 3 further miss indications (via subsequent 3913 SACK's) on the same TSN(s) before taking action with regard to Fast 3914 Retransmit. 3916 When the TSN(s) is reported as missing in the fourth consecutive SACK, 3917 the data sender shall: 3919 1) Mark the missing DATA chunk(s) for retransmission, 3921 2) Adjust the ssthresh and cwnd of the destination address(es) to which 3922 the missing DATA chunks were last sent, according to the formula 3923 described in Section 7.2.3. 3925 3) Determine how many of the earliest (i.e., lowest TSN) DATA 3926 chunks marked for retransmission will fit into a single packet, 3927 subject to constraint of the path MTU of the destination transport 3928 address to which the packet is being sent. Call this value K. 3929 Retransmit those K DATA chunks in a single packet. 3931 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 3932 outstanding TSN number sent to that address, or the endpoint is 3933 retransmitting the first outstanding DATA chunk sent to that 3934 address. 3936 Note: Before the above adjustments, if the received SACK also 3937 acknowledges new DATA chunks and advances the Cumulative TSN Ack 3938 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 3939 must be applied first. 3941 A straightforward implementation of the above keeps a counter for each 3942 TSN hole reported by a SACK. The counter increments for each 3943 consecutive SACK reporting the TSN hole. After reaching 4 and starting 3944 the fast retransmit procedure, the counter resets to 0. 3946 Because cwnd in SCTP indirectly bounds the number of outstanding 3947 TSN's, the effect of TCP fast-recovery is achieved automatically with 3948 no adjustment to the congestion control window size. 3950 7.3 Path MTU Discovery 3952 [RFC1191] specifies "Path MTU Discovery", whereby an endpoint 3953 maintains an estimate of the maximum transmission unit (MTU) along a 3954 given Internet path and refrains from sending packets along that path 3955 which exceed the MTU, other than occasional attempts to probe for a 3956 change in the Path MTU (PMTU). RFC 1191 is thorough in its discussion 3957 of the MTU discovery mechanism and strategies for determining the 3958 current end-to-end MTU setting as well as detecting changes in this 3959 value. [RFC1981] specifies the same mechanisms for IPv6. An SCTP 3960 sender using IPv6 MUST use Path MTU Discovery unless all packets are 3961 less than the minimum IPv6 MTU [RFC2460]. 3963 An endpoint SHOULD apply these techniques, and SHOULD do so on a 3964 per-destination-address basis. 3966 There are 4 ways in which SCTP differs from the description in RFC 1191 3967 of applying MTU discovery to TCP: 3969 1) SCTP associations can span multiple addresses. 3970 An endpoint MUST maintain separate MTU estimates for each 3971 destination address of its peer. 3973 2) Elsewhere in this document, when the term "MTU" is discussed, 3974 it refers to the MTU associated with the destination address 3975 corresponding to the context of the discussion. 3977 3) Unlike TCP, SCTP does not have a notion of "Maximum Segment 3978 Size". Accordingly, the MTU for each destination address 3979 SHOULD be initialized to a value no larger than the link MTU 3980 for the local interface to which packets for that remote 3981 destination address will be routed. 3983 4) Since data transmission in SCTP is naturally structured in 3984 terms of TSNs rather than bytes (as is the case for TCP), the 3985 discussion in Section 6.5 of RFC 1191 applies: When retransmitting 3986 an IP datagram to a remote address for which the IP datagram 3987 appears too large for the path MTU to that address, the IP datagram 3988 SHOULD be retransmitted without the DF bit set, allowing it to 3989 possibly be fragmented. Transmissions of new IP datagrams MUST have 3990 DF set. 3992 5) The sender should track an association PMTU which will be 3993 the smallest PMTU discovered for all of the peer's destination 3994 addresses. When fragmenting messages into multiple parts this 3995 association PMTU should be used to calculate the size of 3996 each fragment. This will allow retransmissions to be seamlessly 3997 sent to an alternate address without encountering IP fragmentation. 3999 Other than these differences, the discussion of TCP's use of MTU 4000 discovery in RFCs 1191 and 1981 applies to SCTP on a 4001 per-destination-address basis. 4003 Note: For IPv6 destination addresses the DF bit does not exist, 4004 instead the IP datagram must be fragmented as described in [RFC2460]. 4006 8. Fault Management 4008 8.1 Endpoint Failure Detection 4010 An endpoint shall keep a counter on the total number of consecutive 4011 retransmissions to its peer (including retransmissions to all the 4012 destination transport addresses of the peer if it is multi-homed). If 4013 the value of this counter exceeds the limit indicated in the protocol 4014 parameter 'Association.Max.Retrans', the endpoint shall consider the 4015 peer endpoint unreachable and shall stop transmitting any more data to 4016 it (and thus the association enters the CLOSED state). In addition, the 4017 endpoint shall report the failure to the upper layer, and optionally 4018 report back all outstanding user data remaining in its outbound queue. 4019 The association is automatically closed when the peer endpoint 4020 becomes unreachable. 4022 The counter shall be reset each time a DATA chunk sent to that peer 4023 endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT- 4024 ACK is received from the peer endpoint. 4026 8.2 Path Failure Detection 4028 When its peer endpoint is multi-homed, an endpoint should keep a error 4029 counter for each of the destination transport addresses of the peer 4030 endpoint. 4032 Each time the T3-rtx timer expires on any address, or when a HEARTBEAT 4033 sent to an idle address is not acknowledged within a RTO, the error 4034 counter of that destination address will be incremented. When the 4035 value in the error counter exceeds the protocol parameter 4036 'Path.Max.Retrans' of that destination address, the endpoint should 4037 mark the destination transport address as inactive, and a notification 4038 SHOULD be sent to the upper layer. 4040 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 4041 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 4042 clear the error counter of the destination transport address 4043 to which the DATA chunk was last sent (or HEARTBEAT was sent). When the 4044 peer endpoint is multi-homed and the last chunk sent to it was a 4045 retransmission to an alternate address, there exists an ambiguity as to 4046 whether or not the acknowledgement should be credited to the address of 4047 the last chunk sent. However, this ambiguity does not seem to bear any 4048 significant consequence to SCTP behavior. If this ambiguity is 4049 undesirable, the transmitter may choose not to clear the 4050 error counter if the last chunk sent was a retransmission. 4052 Note: When configuring the SCTP endpoint, the user should avoid 4053 having the value of 'Association.Max.Retrans' larger than the 4054 summation of the 'Path.Max.Retrans' of all the destination addresses 4055 for the remote endpoint. Otherwise, all the destination addresses may 4056 become inactive while the endpoint still considers the peer endpoint 4057 reachable. When this condition occurs, how the SCTP chooses to 4058 function is implementation specific. 4060 When the primary path is marked inactive (due to excessive 4061 retransmissions, for instance), the sender MAY automatically transmit 4062 new packets to an alternate destination address if one exists and is 4063 active. If more than one alternate address is active when the primary 4064 path is marked inactive only ONE transport address SHOULD be chosen 4065 and used as the new destination transport address. 4067 8.3 Path Heartbeat 4069 By default, an SCTP endpoint shall monitor the reachability of the 4070 idle destination transport address(es) of its peer by sending a 4071 HEARTBEAT chunk periodically to the destination transport 4072 address(es). 4074 A destination transport address is considered "idle" if no new chunk 4075 which can be used for updating path RTT (usually including first 4076 transmission DATA, INIT, COOKIE ECHO, HEARTBEAT etc.) and no 4077 HEARTBEAT has been sent to it within the current heartbeat period of 4078 that address. This applies to both active and inactive destination 4079 addresses. 4081 The upper layer can optionally initiate the following functions: 4083 A) Disable heartbeat on a specific destination transport address of a 4084 given association, 4085 B) Change the HB.interval, 4086 C) Re-enable heartbeat on a specific destination transport address of 4087 a given association, and, 4088 D) Request an on-demand HEARTBEAT on a specific destination transport 4089 address of a given association. 4091 The endpoint should increment the respective error counter 4092 of the destination transport address each time a HEARTBEAT is sent to 4093 that address and not acknowledged within one RTO. 4095 When the value of this counter reaches the protocol parameter 4096 'Path.Max.Retrans', the endpoint should mark the corresponding 4097 destination address as inactive if it is not so marked, and may also 4098 optionally report to the upper layer the change of reachability of 4099 this destination address. After this, the endpoint should continue 4100 HEARTBEAT on this destination address but should stop increasing the 4101 counter. 4103 The sender of the HEARTBEAT chunk should include in the Heartbeat 4104 Information field of the chunk the current time when the packet is 4105 sent out and the destination address to which the packet is sent. 4107 IMPLEMENTATION NOTE: An alternative implementation of the heartbeat 4108 mechanism that can be used is to increment the error counter 4109 variable every time a HEARTBEAT is sent to a destination. Whenever 4110 a HEARTBEAT ACK arrives, the sender SHOULD clear the 4111 error counter of the destination that the HEARTBEAT was 4112 sent to. This in effect would clear the previously stroked 4113 error (and any other error counts as well). 4115 The receiver of the HEARTBEAT should immediately respond with a 4116 HEARTBEAT ACK that contains the Heartbeat Information field copied 4117 from the received HEARTBEAT chunk. 4119 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 4120 should clear the error counter of the destination transport 4121 address to which the HEARTBEAT was sent, and mark the destination 4122 transport address as active if it is not so marked. The endpoint may 4123 optionally report to the upper layer when an inactive destination 4124 address is marked as active due to the reception of the latest 4125 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also 4126 clear the association overall error count as well (as defined 4127 in section 8.1). 4129 The receiver of the HEARTBEAT ACK should also perform an RTT 4130 measurement for that destination transport address using the time 4131 value carried in the HEARTBEAT ACK chunk. 4133 On an idle destination address that is allowed to heartbeat,a HEARTBEAT 4134 chunk is RECOMMENDED to be sent once per RTO of that destination 4135 address plus the protocol parameter 'HB.interval' , with 4136 jittering of +/- 50%, and exponential back-off of the RTO if the 4137 previous HEARTBEAT is unanswered. 4139 A primitive is provided for the SCTP user to change the HB.interval 4140 and turn on or off the heartbeat on a given destination address. The 4141 heartbeat interval set by the SCTP user is added to the RTO of that 4142 destination (including any exponential backoff). Only one heartbeat 4143 should be sent each time the heartbeat timer expires (if multiple 4144 destinations are idle). It is a implementation decision on how to 4145 choose which of the candidate idle destinations to heartbeat to (if 4146 more than one destination is idle). 4148 Note: When tuning the heartbeat interval, there is a side effect that 4149 SHOULD be taken into account. When this value is increased, i.e. the 4150 HEARTBEAT takes longer, the detection of lost ABORT messages takes 4151 longer as well. If a peer endpoint ABORTs the association for 4152 any reason and the ABORT chunk is lost, the local endpoint will only 4153 discover the lost ABORT by sending a DATA chunk or HEARTBEAT chunk 4154 (thus causing the peer to send another ABORT). This must be considered 4155 when tuning the HEARBEAT timer. If the HEARTBEAT is disabled only 4156 sending DATA to the association will discover a lost ABORT from the 4157 peer. 4159 8.4 Handle "Out of the blue" Packets 4161 An SCTP packet is called an "out of the blue" (OOTB) packet if it 4162 is correctly formed, i.e., passed the receiver's Adler-32 check (see 4163 Section 6.8), but the receiver is not able to identify the association 4164 to which this packet belongs. 4166 The receiver of an OOTB packet MUST do the following: 4168 1) If the OOTB packet is to or from a non-unicast address, silently 4169 discard the packet. Otherwise, 4171 2) If the OOTB packet contains an ABORT chunk, the receiver MUST 4172 silently discard the OOTB packet and take no further action. 4173 Otherwise, 4175 3) If the packet contains an INIT chunk with a Verification Tag set to 4176 '0', process it as described in Section 5.1. Otherwise, 4178 4) If the packet contains a COOKIE ECHO in the first chunk, process it 4179 as described in Section 5.1. Otherwise, 4181 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should 4182 respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. 4183 When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet 4184 must fill in the Verification Tag field of the outbound packet with 4185 the Verification Tag received in the SHUTDOWN ACK and set the 4186 T-bit in the Chunk Flags to indicate that no TCB was found. 4187 Otherwise, 4189 6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver 4190 should silently discard the packet and take no further action. 4191 Otherwise, 4193 7) The receiver should respond to the sender of the OOTB packet with 4194 an ABORT. When sending the ABORT, the receiver of the OOTB packet 4195 MUST fill in the Verification Tag field of the outbound packet 4196 with the value found in the Verification Tag field of the OOTB 4197 packet and set the T-bit in the Chunk Flags to indicate that no 4198 TCB was found. After sending this ABORT, the receiver of the 4199 OOTB packet shall discard the OOTB packet and take no further 4200 action. 4202 8.5 Verification Tag 4204 The Verification Tag rules defined in this section apply when sending 4205 or receiving SCTP packets which do not contain an INIT, SHUTDOWN 4206 COMPLETE, COOKIE ECHO (see Section 5.1) or ABORT chunk. The rules for 4207 sending and receiving SCTP packets containing one of these chunk types 4208 are discussed separately in Section 8.5.1. 4210 When sending an SCTP packet, the endpoint MUST fill in the Verification 4211 Tag field of the outbound packet with the tag value in the Initiate Tag 4212 parameter of the INIT or INIT ACK received from its peer. 4214 When receiving an SCTP packet, the endpoint MUST ensure that the 4215 value in the Verification Tag field of the received SCTP packet 4216 matches its own Tag. If the received Verification Tag value does not 4217 match the receiver's own tag value, the receiver shall silently 4218 discard the packet and shall not process it any further except for 4219 those cases listed in Section 8.5.1 below. 4221 8.5.1 Exceptions in Verification Tag Rules 4223 A) Rules for packet carrying INIT: 4225 - The sender MUST set the Verification Tag of the packet to 0. 4227 - When an endpoint receives an SCTP packet with the Verification Tag 4228 set to 0, it should verify that the packet contains only an INIT 4229 chunk. Otherwise, the receiver MUST silently discard the packet. 4231 B) Rules for packet carrying ABORT: 4233 - The endpoint shall always fill in the Verification Tag field of the 4234 outbound packet with the destination endpoint's tag value if it 4235 is known. 4237 - If the ABORT is sent in response to an OOTB packet, the endpoint 4238 MUST follow the procedure described in Section 8.4. 4240 - The receiver MUST accept the packet if the Verification Tag 4241 matches either its own tag, OR the tag of its peer. Otherwise, the 4242 receiver MUST silently discard the packet and take no further 4243 action. 4245 C) Rules for packet carrying SHUTDOWN COMPLETE: 4247 - When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN 4248 ACK has a TCB then the destination endpoint's tag MUST be used. Only 4249 where no TCB exists should the sender use the Verification Tag from 4250 the SHUTDOWN ACK. 4252 - The receiver of a SHUTDOWN COMPLETE shall accept the packet if the 4253 Verification Tag field of the packet matches its own tag OR it is 4254 set to its peer's tag and the T bit is set in the Chunk Flags. 4255 Otherwise, the receiver MUST silently discard the packet and take 4256 no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if 4257 it is not in the SHUTDOWN-ACK-SENT state. 4259 D) Rules for packet carrying a COOKIE ECHO 4261 - When sending a COOKIE ECHO, the endpoint MUST use the value of the 4262 Initial Tag received in the INIT ACK. 4264 - The receiver of a COOKIE ECHO follows the procedures in Section 5. 4266 9. Termination of Association 4268 An endpoint should terminate its association when it exits from 4269 service. An association can be terminated by either abort or 4270 shutdown. A abort of an association is abortive by definition in that 4271 any data pending on either end of the association is discarded and NOT 4272 delivered to the peer. A shutdown of an association is considered a 4273 graceful close where all data in queue by either endpoint is delivered 4274 to the respective peers. However, in the case of a shutdown, SCTP does 4275 not support a half-open state (like TCP) wherein one side may continue 4276 sending data while the other end is closed. When either endpoint 4277 performs a shutdown, the association on each peer will stop accepting 4278 new data from its user and only deliver data in queue at the time of 4279 sending or receiving the SHUTDOWN chunk. 4281 9.1 Abort of an Association 4283 When an endpoint decides to abort down an existing association, it 4284 shall send an ABORT chunk to its peer endpoint. The sender MUST fill 4285 in the peer's Verification Tag in the outbound packet and MUST NOT 4286 bundle any DATA chunk with the ABORT. 4288 An endpoint MUST NOT respond to any received packet that contains an 4289 ABORT chunk (also see Section 8.4). 4291 An endpoint receiving an ABORT shall apply the special Verification Tag 4292 check rules described in Section 8.5.1. 4294 After checking the Verification Tag, the receiving endpoint shall 4295 remove the association from its record, and shall report the 4296 termination to its upper layer. 4298 9.2 Shutdown of an Association 4300 Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an 4301 endpoint in an association can gracefully close the association. 4302 This will allow all outstanding DATA chunks from the peer of 4303 the shutdown initiator to be delivered before the association 4304 terminates. 4306 Upon receipt of the SHUTDOWN primitive from its upper layer, the 4307 endpoint enters SHUTDOWN-PENDING state and remains there until all 4308 outstanding TSNs have been acknowledged by its peer. The endpoint 4309 accepts no new data from its upper layer, but retransmits data to the 4310 far end if necessary to fill gaps. 4312 Once all its outstanding TSNs have been acknowledged, the endpoint 4313 shall send a SHUTDOWN chunk to its peer including in the Cumulative 4314 TSN Ack field the last sequential TSN it has received from the peer. 4315 It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT 4316 state. If the timer expires, the endpoint must re-send the SHUTDOWN 4317 with the updated last sequential TSN received from its peer. 4319 The rules in Section 6.3 MUST be followed to determine the proper timer 4320 value for T2-shutdown. To indicate any gaps in TSN, the endpoint may 4321 also bundle a SACK with the SHUTDOWN chunk in the same SCTP packet. 4323 An endpoint should limit the number of retransmissions of the SHUTDOWN 4324 chunk to the protocol parameter 'Association.Max.Retrans'. If this 4325 threshold is exceeded the endpoint should destroy the TCB and MUST 4326 report the peer endpoint unreachable to the upper layer (and thus the 4327 association enters the CLOSED state). The reception of any packet from 4328 its peer (i.e. as the peer sends all of its queued DATA chunks) should 4329 clear the endpoint's retransmission count and restart the T2-Shutdown 4330 timer, giving its peer ample opportunity to transmit all of its queued 4331 DATA chunks that have not yet been sent. 4333 Upon the reception of the SHUTDOWN, the peer endpoint shall 4334 - enter the SHUTDOWN-RECEIVED state, 4336 - stop accepting new data from its SCTP user 4338 - verify, by checking the Cumulative TSN Ack field of the chunk, that 4339 all its outstanding DATA chunks have been received by the SHUTDOWN 4340 sender. 4342 Once a endpoint as reached the SHUTDOWN-RECEIVED state it MUST NOT 4343 send a SHUTDOWN in response to a ULP request. 4345 If there are still outstanding DATA chunks left, the SHUTDOWN receiver 4346 shall continue to follow normal data transmission procedures defined in 4347 Section 6 until all outstanding DATA chunks are acknowledged; however, 4348 the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. 4350 While in SHUTDOWN-SENT state, the SHUTDOWN sender shall immediately 4351 respond to each received DATA chunk with a SACK and restart the 4352 T2-shutdown timer. 4354 If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall 4355 send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering 4356 the SHUTDOWN-ACK-SENT state. 4358 The sender of the SHUTDOWN ACK should limit the number of 4359 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 4360 'Association.Max.Retrans'. If this threshold is exceeded the endpoint 4361 should destroy the TCB and may report the peer endpoint unreachable to 4362 the upper layer (and thus the association enters the CLOSED state). 4364 Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop 4365 the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its 4366 peer, and remove all record of the association. 4368 An endpoint SHOULD assure that all its outstanding DATA chunks have 4369 been acknowledged before initiating the shutdown procedure. 4371 An endpoint should reject any new data request from its upper 4372 layer if it is in SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or 4373 SHUTDOWN-ACK-SENT state. 4375 If an endpoint is in SHUTDOWN-ACK-SENT state and receives an INIT chunk 4376 (e.g., if the SHUTDOWN COMPLETE was lost) with source and destination 4377 transport addresses (either in the IP addresses or in the INIT chunk) 4378 that belong to this association, it should discard the INIT chunk and 4379 retransmit the SHUTDOWN ACK chunk. 4380 Note: Receipt of an INIT with the same source and destination IP 4381 addresses as used in transport addresses assigned to an endpoint but 4382 with a different port number indicates the initialization of a 4383 separate association. 4385 The sender of the INIT should respond to the receipt of a SHUTDOWN-ACK 4386 with a stand-alone SHUTDOWN COMPLETE in an SCTP packet with the 4387 Verification Tag field of its common header set to the same tag that 4388 was received in the SHUTDOWN ACK packet. This is considered an Out of 4389 the Blue packet as defined in Section 8.4. The sender of the INIT lets 4390 T1-init continue running and remains in the COOKIE-WAIT state. Normal 4391 T1-init timer expiration will cause the INIT chunk to be retransmitted 4392 and thus start a new association. 4394 If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN chunk 4395 from its peer, the endpoint shall respond immediately with a SHUTDOWN 4396 ACK to its peer, and move into a SHUTDOWN-ACK-SENT state restarting its 4397 T2-shutdown timer. 4399 If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a 4400 SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a 4401 SHUTDOWN COMPLETE chunk to its peer, and remove all record of the 4402 association. 4404 10. Interface with Upper Layer 4406 The Upper Layer Protocols (ULP) shall request for services by passing 4407 primitives to SCTP and shall receive notifications from SCTP for 4408 various events. 4410 The primitives and notifications described in this section should be 4411 used as a guideline for implementing SCTP. The following functional 4412 description of ULP interface primitives is shown for illustrative 4413 purposes. Different SCTP implementations may have different ULP 4414 interfaces. However, all SCTPs must provide a certain minimum set of 4415 services to guarantee that all SCTP implementations can support the 4416 same protocol hierarchy. 4418 10.1 ULP-to-SCTP 4420 The following sections functionally characterize a ULP/SCTP interface. 4421 The notation used is similar to most procedure or function calls in 4422 high level languages. 4424 The ULP primitives described below specify the basic functions the 4425 SCTP must perform to support inter-process communication. Individual 4426 implementations must define their own exact format, and may provide 4427 combinations or subsets of the basic functions in single calls. 4429 A) Initialize 4431 Format: INITIALIZE ([local port], [local eligible address list]) 4432 -> local SCTP instance name 4434 This primitive allows SCTP to initialize its internal data structures 4435 and allocate necessary resources for setting up its operation 4436 environment. Once SCTP is initialized, ULP can communicate 4437 directly with other endpoints without re-invoking this primitive. 4439 SCTP will return a local SCTP instance name to the ULP. 4441 Mandatory attributes: 4443 None. 4445 Optional attributes: 4447 The following types of attributes may be passed along with the 4448 primitive: 4450 o local port - SCTP port number, if ULP wants it to be specified; 4452 o local eligible address list - An address list that the local SCTP 4453 endpoint should bind. By default, if an address list is not 4454 included, all IP addresses assigned to the host should be used by 4455 the local endpoint. 4457 IMPLEMENTATION NOTE: If this optional attribute is supported by an 4458 implementation, it will be the responsibility of the implementation 4459 to enforce that the IP source address field of any SCTP packets 4460 sent out by this endpoint contains one of the IP addresses 4461 indicated in the local eligible address list. 4463 B) Associate 4465 Format: ASSOCIATE(local SCTP instance name, destination transport addr, 4466 outbound stream count) 4467 -> association id [,destination transport addr list] [,outbound stream 4468 count] 4470 This primitive allows the upper layer to initiate an association to a 4471 specific peer endpoint. 4473 The peer endpoint shall be specified by one of the transport addresses 4474 which defines the endpoint (see Section 1.4). If the local SCTP 4475 instance has not been initialized, the ASSOCIATE is considered an 4476 error. 4478 An association id, which is a local handle to the SCTP association, 4479 will be returned on successful establishment of the association. If 4480 SCTP is not able to open an SCTP association with the peer endpoint, 4481 an error is returned. 4483 Other association parameters may be returned, including the complete 4484 destination transport addresses of the peer as well as the outbound 4485 stream count of the local endpoint. One of the transport address from 4486 the returned destination addresses will be selected by the local 4487 endpoint as default primary path for sending SCTP 4488 packets to this peer. The returned "destination transport addr 4489 list" can be used by the ULP to change the default primary path or to 4490 force sending a packet to a specific transport address. 4492 IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a 4493 blocking function call, the ASSOCIATE primitive can return 4494 association parameters in addition to the association id upon 4495 successful establishment. If ASSOCIATE primitive is implemented as a 4496 non-blocking call, only the association id shall be returned and 4497 association parameters shall be passed using the COMMUNICATION UP 4498 notification. 4500 Mandatory attributes: 4502 o local SCTP instance name - obtained from the INITIALIZE operation. 4504 o destination transport addr - specified as one of the transport 4505 addresses of the peer endpoint with which the association is to be 4506 established. 4508 o outbound stream count - the number of outbound streams the ULP 4509 would like to open towards this peer endpoint. 4511 Optional attributes: 4513 None. 4515 C) Shutdown 4517 Format: SHUTDOWN(association id) 4518 -> result 4520 Gracefully closes an association. Any locally queued user data 4521 will be delivered to the peer. The association will be terminated only 4522 after the peer acknowledges all the SCTP packets sent. A success code 4523 will be returned on successful termination of the association. If 4524 attempting to terminate the association results in a failure, an error 4525 code shall be returned. 4527 Mandatory attributes: 4529 o association id - local handle to the SCTP association 4531 Optional attributes: 4533 None. 4535 D) Close 4537 Format: ABORT(association id [, cause code]) 4538 -> result 4540 Ungracefully closes an association. Any locally queued user data 4541 will be discarded and an ABORT chunk is sent to the peer. A success 4542 code will be returned on successful abortion of the association. If 4543 attempting to abort the association results in a failure, an error 4544 code shall be returned. 4546 Mandatory attributes: 4548 o association id - local handle to the SCTP association 4550 Optional attributes: 4552 o cause code - reason of the abort to be passed to the peer. 4554 None. 4556 E) Send 4558 Format: SEND(association id, buffer address, byte count [,context] 4559 [,stream id] [,life time] [,destination transport address] 4560 [,unorder flag] [,no-bundle flag] [,payload protocol-id] ) 4561 -> result 4563 This is the main method to send user data via SCTP. 4565 Mandatory attributes: 4567 o association id - local handle to the SCTP association 4569 o buffer address - the location where the user message to be 4570 transmitted is stored; 4572 o byte count - The size of the user data in number of bytes; 4574 Optional attributes: 4576 o context - an optional 32 bit integer that will be carried in the 4577 sending failure notification to the ULP if the transportation of 4578 this User Message fails. 4580 o stream id - to indicate which stream to send the data on. If not 4581 specified, stream 0 will be used. 4583 o life time - specifies the life time of the user data. The user data 4584 will not be sent by SCTP after the life time expires. This 4585 parameter can be used to avoid efforts to transmit stale 4586 user messages. SCTP notifies the ULP if the data cannot be 4587 initiated to transport (i.e. sent to the destination via SCTP's 4588 send primitive) within the life time variable. However, the 4589 user data will be transmitted if SCTP has attempted to transmit a 4590 chunk before the life time expired. 4592 IMPLEMENTATION NOTE: In order to better support the data lifetime 4593 option, the transmitter may hold back the assigning of the TSN 4594 number to an outbound DATA chunk to the last moment. And, for 4595 implementation simplicity, once a TSN number has been assigned the 4596 sender should consider the send of this DATA chunk as committed, 4597 overriding any lifetime option attached to the DATA chunk. 4599 o destination transport address - specified as one of the destination 4600 transport addresses of the peer endpoint to which this packet 4601 should be sent. Whenever possible, SCTP should use this destination 4602 transport address for sending the packets, instead of the current 4603 primary path. 4605 o unorder flag - this flag, if present, indicates that the user 4606 would like the data delivered in an unordered fashion to the peer 4607 (i.e., the U flag is set to 1 on all DATA chunks carrying this 4608 message). 4610 o no-bundle flag - instructs SCTP not to bundle this user data with 4611 other outbound DATA chunks. SCTP MAY still bundle even when 4612 this flag is present, when faced with network congestion. 4614 o payload protocol-id - A 32 bit unsigned integer that is to be 4615 passed to the peer indicating the type of payload protocol data 4616 being transmitted. This value is passed as opaque data by SCTP. 4618 F) Set Primary 4620 Format: SETPRIMARY(association id, destination transport address, 4621 [source transport address] ) 4622 -> result 4624 Instructs the local SCTP to use the specified destination transport 4625 address as primary path for sending packets. 4627 The result of attempting this operation shall be returned. If the 4628 specified destination transport address is not present in the 4629 "destination transport address list" returned earlier in an associate 4630 command or communication up notification, an error shall be returned. 4632 Mandatory attributes: 4634 o association id - local handle to the SCTP association 4636 o destination transport address - specified as one of the transport 4637 addresses of the peer endpoint, which should be used as primary 4638 address for sending packets. This overrides the current primary 4639 address information maintained by the local SCTP endpoint. 4641 Optional attributes: 4643 o source transport address - optionally, some implementations may 4644 allow you to set the default source address placed in all 4645 outgoing IP datagrams. 4647 G) Receive 4649 Format: RECEIVE(association id, buffer address, buffer size 4650 [,stream id]) 4651 -> byte count [,transport address] [,stream id] [,stream sequence 4652 number] [,partial flag] [,delivery number] [,payload protocol-id] 4654 This primitive shall read the first user message in the SCTP in-queue 4655 into the buffer specified by ULP, if there is one available. The size 4656 of the message read, in bytes, will be returned. It may, depending on 4657 the specific implementation, also return other information such as the 4658 senders address, the stream id on which it is received, whether there 4659 are more messages available for retrieval, etc. For ordered messages, 4660 their stream sequence number may also be returned. 4662 Depending upon the implementation, if this primitive is invoked when 4663 no message is available the implementation should return an indication 4664 of this condition or should block the invoking process until data does 4665 become available. 4667 Mandatory attributes: 4669 o association id - local handle to the SCTP association 4671 o buffer address - the memory location indicated by the ULP to store 4672 the received message. 4674 o buffer size - the maximum size of data to be received, in bytes. 4676 Optional attributes: 4678 o stream id - to indicate which stream to receive the data on. 4680 o stream sequence number - the stream sequence number assigned by the 4681 sending SCTP peer. 4683 o partial flag - if this returned flag is set to 1, then this 4684 Receive contains a partial delivery of the whole message. When 4685 this flag is set, the stream id and stream sequence number MUST 4686 accompany this receive. When this flag is set to 0, it indicates 4687 that no more deliveries will be received for this stream sequence 4688 number. 4690 o payload protocol-id - A 32 bit unsigned integer that is received 4691 from the peer indicating the type of payload protocol of the 4692 received data. This value is passed as opaque data by SCTP. 4694 H) Status 4696 Format: STATUS(association id) 4697 -> status data 4699 This primitive should return a data block containing the following 4700 information: 4701 association connection state, 4702 destination transport address list, 4703 destination transport address reachability states, 4704 current receiver window size, 4705 current congestion window sizes, 4706 number of unacknowledged DATA chunks, 4707 number of DATA chunks pending receipt, 4708 primary path, 4709 most recent SRTT on primary path, 4710 RTO on primary path, 4711 SRTT and RTO on other destination addresses, etc. 4713 Mandatory attributes: 4715 o association id - local handle to the SCTP association 4717 Optional attributes: 4719 None. 4721 I) Change Heartbeat 4723 Format: CHANGEHEARTBEAT(association id, destination transport address, 4724 new state [,interval]) 4725 -> result 4727 Instructs the local endpoint to enable or disable heartbeat on the 4728 specified destination transport address. 4730 The result of attempting this operation shall be returned. 4732 Note: Even when enabled, heartbeat will not take place if the 4733 destination transport address is not idle. 4735 Mandatory attributes: 4737 o association id - local handle to the SCTP association 4739 o destination transport address - specified as one of the transport 4740 addresses of the peer endpoint. 4742 o new state - the new state of heartbeat for this destination 4743 transport address (either enabled or disabled). 4745 Optional attributes: 4747 o interval - if present, indicates the frequency of the heartbeat if 4748 this is to enable heartbeat on a destination transport 4749 address. Default interval is the RTO of the destination address. 4751 J) Request HeartBeat 4753 Format: REQUESTHEARTBEAT(association id, destination transport 4754 address) 4755 -> result 4757 Instructs the local endpoint to perform a HeartBeat on the specified 4758 destination transport address of the given association. The returned 4759 result should indicate whether the transmission of the HEARTBEAT 4760 chunk to the destination address is successful. 4762 Mandatory attributes: 4764 o association id - local handle to the SCTP association 4766 o destination transport address - the transport address of the 4767 association on which a heartbeat should be issued. 4769 K) Get SRTT Report 4770 Format: GETSRTTREPORT(association id, destination transport address) 4771 -> srtt result 4773 Instructs the local SCTP to report the current SRTT measurement on the 4774 specified destination transport address of the given association. The 4775 returned result can be an integer containing the most recent SRTT in 4776 milliseconds. 4778 Mandatory attributes: 4780 o association id - local handle to the SCTP association 4782 o destination transport address - the transport address of the 4783 association on which the SRTT measurement is to be reported. 4785 L) Set Failure Threshold 4787 Format: SETFAILURETHRESHOLD(association id, destination transport 4788 address, failure threshold) 4789 -> result 4791 This primitive allows the local SCTP to customize the reachability 4792 failure detection threshold 'Path.Max.Retrans' for the specified 4793 destination address. 4795 Mandatory attributes: 4797 o association id - local handle to the SCTP association 4799 o destination transport address - the transport address of the 4800 association on which the failure detection threshold is to be set. 4802 o failure threshold - the new value of 'Path.Max.Retrans' for the 4803 destination address. 4805 M) Set Protocol Parameters 4807 Format: SETPROTOCOLPARAMETERS(association id, [,destination transport 4808 address,] protocol parameter list) 4809 -> result 4811 This primitive allows the local SCTP to customize the protocol 4812 parameters. 4814 Mandatory attributes: 4816 o association id - local handle to the SCTP association 4818 o protocol parameter list - The specific names and values of the 4819 protocol parameters (e.g., Association.Max.Retrans [see Section 14]) 4820 that the SCTP user wishes to customize. 4822 Optional attributes: 4824 o destination transport address - some of the protocol parameters may 4825 be set on a per destination transport address basis. 4827 N) Receive unsent message 4829 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size 4830 [,stream id] [, stream sequence number] [,partial flag] 4831 [,payload protocol-id]) 4833 o data retrieval id - The identification passed to the ULP in the 4834 failure notification. 4836 o buffer address - the memory location indicated by the ULP to store 4837 the received message. 4839 o buffer size - the maximum size of data to be received, in bytes. 4841 Optional attributes: 4843 o stream id - this is a return value that is set to indicate 4844 which stream the data was sent to. 4846 o stream sequence number - this value is returned indicating 4847 the stream sequence number that was associated with the message. 4849 o partial flag - if this returned flag is set to 1, then this 4850 message is a partial delivery of the whole message. When 4851 this flag is set, the stream id and stream sequence number MUST 4852 accompany this receive. When this flag is set to 0, it indicates 4853 that no more deliveries will be received for this stream sequence 4854 number. 4856 o payload protocol-id - The 32 bit unsigned integer that was sent to 4857 be sent to the peer indicating the type of payload protocol of the 4858 received data. 4860 O) Receive unacknowledged message 4862 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, 4863 [,stream id] [, stream sequence number] [,partial flag] 4864 [,payload protocol-id]) 4866 o data retrieval id - The identification passed to the ULP in the 4867 failure notification. 4869 o buffer address - the memory location indicated by the ULP to store 4870 the received message. 4872 o buffer size - the maximum size of data to be received, in bytes. 4874 Optional attributes: 4876 o stream id - this is a return value that is set to indicate 4877 which stream the data was sent to. 4879 o stream sequence number - this value is returned indicating 4880 the stream sequence number that was associated with the message. 4882 o partial flag - if this returned flag is set to 1, then this 4883 message is a partial delivery of the whole message. When 4884 this flag is set, the stream id and stream sequence number MUST 4885 accompany this receive. When this flag is set to 0, it indicates 4886 that no more deliveries will be received for this stream sequence 4887 number. 4889 o payload protocol-id - The 32 bit unsigned integer that was sent to 4890 be sent to the peer indicating the type of payload protocol of the 4891 received data. 4893 P) Destroy SCTP instance 4895 Format: DESTROY(local SCTP instance name) 4897 o local SCTP instance name - this is the value that was 4898 passed to the application in the initialize primitive and 4899 it indicates which SCTP instance to be destroyed. 4901 10.2 SCTP-to-ULP 4903 It is assumed that the operating system or application environment 4904 provides a means for the SCTP to asynchronously signal the ULP 4905 process. When SCTP does signal an ULP process, certain information is 4906 passed to the ULP. 4908 IMPLEMENTATION NOTE: In some cases this may be done through a 4909 separate socket or error channel. 4911 A) DATA ARRIVE notification 4913 SCTP shall invoke this notification on the ULP when a user message is 4914 successfully received and ready for retrieval. 4916 The following may be optionally be passed with the notification: 4918 o association id - local handle to the SCTP association 4920 o stream id - to indicate which stream the data is received on. 4922 B) SEND FAILURE notification 4924 If a message can not be delivered SCTP shall invoke this notification 4925 on the ULP. 4927 The following may be optionally be passed with the notification: 4929 o association id - local handle to the SCTP association 4931 o data retrieval id - an identification used to retrieve 4932 unsent and unacknowledged data. 4934 o cause code - indicating the reason of the failure, e.g., size too 4935 large, message life-time expiration, etc. 4937 o context - optional information associated with this message (see 4938 D in Section 10.1). 4940 C) NETWORK STATUS CHANGE notification 4942 When a destination transport address is marked inactive (e.g., when 4943 SCTP detects a failure), or marked active (e.g., when SCTP detects a 4944 recovery), SCTP shall invoke this notification on the ULP. 4946 The following shall be passed with the notification: 4948 o association id - local handle to the SCTP association 4950 o destination transport address - This indicates the destination 4951 transport address of the peer endpoint affected by the change; 4953 o new-status - This indicates the new status. 4955 D) COMMUNICATION UP notification 4957 This notification is used when SCTP becomes ready to send or receive 4958 user messages, or when a lost communication to an endpoint is 4959 restored. 4961 IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a 4962 blocking function call, the association parameters are returned as a 4963 result of the ASSOCIATE primitive itself. In that case, 4964 COMMUNICATION UP notification is optional at the association 4965 initiator's side. 4967 The following shall be passed with the notification: 4969 o association id - local handle to the SCTP association 4971 o status - This indicates what type of event has occurred 4973 o destination transport address list - the complete set of transport 4974 addresses of the peer 4976 o outbound stream count - the maximum number of streams allowed to be 4977 used in this association by the ULP 4979 o inbound stream count - the number of streams the peer endpoint 4980 has requested with this association (this may not be the same 4981 number as 'outbound stream count'). 4983 E) COMMUNICATION LOST notification 4985 When SCTP loses communication to an endpoint completely (via 4986 Heartbeats) or detects that the endpoint has performed an abort 4987 operation, it shall invoke this notification on the ULP. 4989 The following shall be passed with the notification: 4991 o association id - local handle to the SCTP association 4993 o status - This indicates what type of event has occurred; 4994 The status may indicate a failure OR a normal 4995 termination event occurred in response to a 4996 shutdown or abort request. 4998 The following may be passed with the notification: 5000 o data retrieval id - an identification used to retrieve 5001 unsent and unacknowledged data. 5003 o last-acked - the TSN last acked by that peer endpoint; 5005 o last-sent - the TSN last sent to that peer endpoint; 5007 F) COMMUNICATION ERROR notification 5009 When SCTP receives an ERROR chunk from its peer and decides to notify 5010 its ULP, it can invoke this notification on the ULP. 5012 The following can be passed with the notification: 5014 o association id - local handle to the SCTP association 5016 o error info - this indicates the type of error and optionally some 5017 additional information received through the ERROR chunk. 5019 G) RESTART notification 5021 When SCTP detects that the peer has restarted, it may send 5022 this notification to its ULP. 5024 The following can be passed with the notification: 5026 o association id - local handle to the SCTP association 5028 H) SHUTDOWN COMPLETE notification 5030 When SCTP completes the shutdown procedures (section 9.2) this 5031 notification is passed to the upper layer. 5033 The following can be passed with the notification: 5035 o association id - local handle to the SCTP association 5037 11. Security Considerations 5039 11.1 Security Objectives 5041 As a common transport protocol designed to reliably carry time- 5042 sensitive user messages, such as billing or signaling messages for 5043 telephony services, between two networked endpoints, SCTP has the 5044 following security objectives. 5046 - availability of reliable and timely data transport services 5047 - integrity of the user-to-user information carried by SCTP 5049 11.2 SCTP Responses To Potential Threats 5051 SCTP may potentially be used in a wide variety of risk situations. It 5052 is important for operator(s) of systems running SCTP to analyze their 5053 particular situations and decide on the appropriate counter-measures. 5055 Operators of systems running SCTP should consult [RFC2196] for 5056 guidance in securing their site. 5058 11.2.1 Countering Insider Attacks 5060 The principles of [RFC2196] should be applied to minimize the risk of 5061 theft of information or sabotage by insiders. Such procedures include 5062 publication of security policies, control of access at the physical, 5063 software, and network levels, and separation of services. 5065 11.2.2 Protecting against Data Corruption in the Network 5067 Where the risk of undetected errors in datagrams delivered by the lower 5068 layer transport services is considered to be too great, additional 5069 integrity protection is required. If this additional protection were 5070 provided in the application-layer, the SCTP header would remain 5071 vulnerable to deliberate integrity attacks. While the existing SCTP 5072 mechanisms for detection of packet replays are considered sufficient 5073 for normal operation, stronger protections are needed to protect SCTP 5074 when the operating environment contains significant risk of deliberate 5075 attacks from a sophisticated adversary. 5077 In order to promote software code-reuse, to avoid re-inventing the 5078 wheel, and to avoid gratuitous complexity to SCTP, the IP 5079 Authentication Header [RFC2402] SHOULD be used when the threat 5080 environment requires stronger integrity protections, but does not 5081 require confidentiality. 5083 A widely implemented BSD Sockets API extension exists for applications 5084 to request IP security services, such as AH or ESP from an operating 5085 system kernel. Applications can use such an API to request AH whenever 5086 AH use is appropriate. 5088 11.2.3 Protecting Confidentiality 5090 In most cases, the risk of breach of confidentiality applies to the 5091 signaling data payload, not to the SCTP or lower-layer protocol 5092 overheads. If that is true, encryption of the SCTP user data only might 5093 be considered. As with the supplementary checksum service, user data 5094 encryption MAY be performed by the SCTP user application. Alternately, 5095 the user application MAY use an implementation-specific API to request 5096 that the IP Encapsulating Security Payload (ESP) [RFC2406] be used to 5097 provide confidentiality and integrity. 5099 Particularly for mobile users, the requirement for confidentiality 5100 might include the masking of IP addresses and ports. In this case ESP 5101 SHOULD be used instead of application-level confidentiality. If ESP is 5102 used to protect confidentiality of SCTP traffic, an ESP cryptographic 5103 transform that includes cryptographic integrity protection MUST be 5104 used, because if there is a confidentiality threat there will also be a 5105 strong integrity threat. 5107 Whenever ESP is in use, application-level encryption is not generally 5108 required. 5110 Regardless of where confidentiality is provided, the ISAKMP [RFC2408] 5111 and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key 5112 management. 5114 Operators should consult [RFC2401] for more information on the security 5115 services available at and immediately above the Internet Protocol 5116 layer. 5118 11.2.4 Protecting against Blind Denial of Service Attacks 5120 A blind attack is one where the attacker is unable to intercept or 5121 otherwise see the content of data flows passing to and from the target 5122 SCTP node. Blind denial of service attacks may take the form of 5123 flooding, masquerade, or improper monopolization of services. 5125 11.2.4.1 Flooding 5127 The objective of flooding is to cause loss of service and incorrect 5128 behavior at target systems through resource exhaustion, interference 5129 with legitimate transactions, and exploitation of buffer-related 5130 software bugs. Flooding may be directed either at the SCTP node or at 5131 resources in the intervening IP Access Links or the Internet. 5132 Where the latter entities are the target, flooding will manifest 5133 itself as loss of network services, including potentially the breach 5134 of any firewalls in place. 5136 In general, protection against flooding begins at the equipment 5137 design level, where it includes measures such as: 5139 - avoiding commitment of limited resources before determining that 5140 the request for service is legitimate 5142 - giving priority to completion of processing in progress over the 5143 acceptance of new work 5144 - identification and removal of duplicate or stale queued requests 5145 for service. 5146 - not responding to unexpected packets sent to non-unicast 5147 addresses. 5149 Network equipment should be capable of generating an alarm and log 5150 if a suspicious increase in traffic occurs. The log should provide 5151 information such as the identity of the incoming link and source 5152 address(es) used which will help the network or SCTP system operator 5153 to take protective measures. Procedures should be in place for the 5154 operator to act on such alarms if a clear pattern of abuse emerges. 5156 The design of SCTP is resistant to flooding attacks, particularly in 5157 its use of a four-way start-up handshake, its use of a cookie to 5158 defer commitment of resources at the responding SCTP node until the 5159 handshake is completed, and its use of a Verification Tag to prevent 5160 insertion of extraneous packets into the flow of an established 5161 association. 5163 The IP Authentication Header and Encapsulating Security Payload might 5164 be useful in reducing the risk of certain kinds of denial of service 5165 attacks." 5167 The use of the Host Name feature in the INIT chunk could be used to 5168 flood a target DNS server. A large backlog of DNS queries, resolving 5169 the Host Name received in the INIT chunk to IP addresses, could be 5170 accomplished by sending INIT's to multiple hosts in a given domain. 5171 In addition, an attacker could use the Host Name feature in an indirect 5172 attack on a third party by sending large numbers of INITs to random 5173 hosts containing the host name of the target. In addition to the 5174 strain on DNS resources, this could also result in large numbers of 5175 INIT ACKs being sent to the target. One method to protect against this 5176 type of attack is to verify that the IP addresses received from DNS 5177 include the source IP address of the original INIT. If the list of IP 5178 addresses received from DNS does not include the source IP address of 5179 the INIT, the endpoint MAY silently discard the INIT. This last option 5180 will not protect against the attack against the DNS. 5182 11.2.4.2 Masquerade 5184 Masquerade can be used to deny service in several ways: 5186 - by tying up resources at the target SCTP node to which the 5187 impersonated node has limited access. For example, the target node 5188 may by policy permit a maximum of one SCTP association with the 5189 impersonated SCTP node. The masquerading attacker may attempt to 5190 establish an association purporting to come from the impersonated 5191 node so that the latter cannot do so when it requires it. 5192 - by deliberately allowing the impersonation to be detected, 5193 thereby provoking counter-measures which cause the impersonated node 5194 to be locked out of the target SCTP node. 5196 - by interfering with an established association by inserting 5197 extraneous content such as a SHUTDOWN request. 5199 SCTP reduces the risk of masquerade attacks through IP spoofing by use 5200 of the four-way startup handshake. Because the initial exchange is 5201 memoryless, no lockout mechanism is triggered by masquerade attacks. 5202 In addition, the INIT ACK containing the State Cookie is transmitted 5203 back to the IP address from which it received the INIT. Thus the 5204 attacker would not receive the INIT ACK containing the State Cookie. 5205 SCTP protects against insertion of extraneous packets into the flow of 5206 an established association by use of the Verification Tag. 5208 Logging of received INIT requests and abnormalities such as 5209 unexpected INIT ACKs might be considered as a way to detect patterns 5210 of hostile activity. However, the potential usefulness of such 5211 logging must be weighed against the increased SCTP startup 5212 processing it implies, rendering the SCTP node more vulnerable to 5213 flooding attacks. Logging is pointless without the establishment of 5214 operating procedures to review and analyze the logs on a routine 5215 basis. 5217 11.2.4.3 Improper Monopolization of Services 5219 Attacks under this heading are performed openly and legitimately by 5220 the attacker. They are directed against fellow users of the target 5221 SCTP node or of the shared resources between the attacker and the 5222 target node. Possible attacks include the opening of a large number 5223 of associations between the attacker's node and the target, or 5224 transfer of large volumes of information within a legitimately- 5225 established association. 5227 Policy limits should be placed on the number of associations per 5228 adjoining SCTP node. SCTP user applications should be capable of 5229 detecting large volumes of illegitimate or "no-op" messages within a 5230 given association and either logging or terminating the association as 5231 a result, based on local policy. 5233 11.3 Protection against Fraud and Repudiation 5235 The objective of fraud is to obtain services without authorization 5236 and specifically without paying for them. In order to achieve this 5237 objective, the attacker must induce the SCTP user application at the 5238 target SCTP node to provide the desired service while accepting 5239 invalid billing data or failing to collect it. Repudiation is a 5240 related problem, since it may occur as a deliberate act of fraud or 5241 simply because the repudiating party kept inadequate records of 5242 service received. 5244 Potential fraudulent attacks include interception and misuse of 5245 authorizing information such as credit card numbers, blind 5246 masquerade and replay, and man-in-the middle attacks which modify 5247 the packets passing through a target SCTP association in real time. 5249 The interception attack is countered by the confidentiality measures 5250 discussed in Section 11.2.3 above. 5252 Section 11.2.4.2 describes how SCTP is resistant to blind masquerade 5253 attacks, as a result of the four-way startup handshake and the 5254 Verification Tag. The Verification Tag and TSN together are 5255 protections against blind replay attacks, where the replay is into an 5256 existing association. 5258 However, SCTP does not protect against man-in-the-middle attacks 5259 where the attacker is able to intercept and alter the packets sent 5260 and received in an association. Where a significant possibility of 5261 such attacks is seen to exist, or where possible repudiation is an 5262 issue, the use of the IPSEC AH service is recommended to ensure both 5263 the integrity and the authenticity of the SCTP packets passed. 5265 SCTP also provides no protection against attacks originating at or 5266 beyond the SCTP node and taking place within the context of an 5267 existing association. Prevention of such attacks should be covered 5268 by appropriate security policies at the host site, as discussed in 5269 Section 11.2.1. 5271 12. Recommended Transmission Control Block (TCB) Parameters 5273 This section details a recommended set of parameters that should 5274 be contained within the TCB for an implementation. This section is 5275 for illustrative purposes and should not be deemed as requirements 5276 on an implementation or as an exhaustive list of all parameters 5277 inside an SCTP TCB. Each implementation may need its own additional 5278 parameters for optimization. 5280 12.1 Parameters necessary for the SCTP instance 5282 Associations: A list of current associations and mappings to the 5283 data consumers for each association. This may be in 5284 the form of a hash table or other implementation 5285 dependent structure. The data consumers may be process 5286 identification information such as file descriptors, 5287 named pipe pointer, or table pointers dependent on how 5288 SCTP is implemented. 5290 Secret Key: A secret key used by this endpoint to compute the MAC. 5291 This SHOULD be a cryptographic quality random number with 5292 a sufficient length. Discussion in [RFC1750] can be 5293 helpful in selection of the key. 5295 Address List: The list of IP addresses that this instance has bound. 5296 This information is passed to one's peer(s) in INIT and 5297 INIT ACK chunks. 5299 SCTP Port: The local SCTP port number the endpoint is bound to. 5301 12.2 Parameters necessary per association (i.e. the TCB) 5302 Peer : Tag value to be sent in every packet and is received 5303 Verification: in the INIT or INIT ACK chunk. 5304 Tag : 5306 My : Tag expected in every inbound packet and sent in the 5307 Verification: INIT or INIT ACK chunk. 5308 Tag : 5310 State : A state variable indicating what state the association is 5311 : in, i.e. COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, 5312 : SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, 5313 : SHUTDOWN-ACK-SENT. 5315 Note: No "CLOSED" state is illustrated since if a 5316 association is "CLOSED" its TCB SHOULD be removed. 5318 Peer : A list of SCTP transport addresses that the peer is 5319 Transport : bound to. This information is derived from the INIT or 5320 Address : INIT ACK and is used to associate an inbound packet 5321 List : with a given association. Normally this information is 5322 : hashed or keyed for quick lookup and access of the TCB. 5324 Primary : This is the current primary destination transport 5325 Path : address of the peer endpoint. It may also specify a 5326 : source transport address on this endpoint. 5328 Overall : The overall association error count. 5329 Error Count : 5331 Overall : The threshold for this association that if the Overall 5332 Error : Error Count reaches will cause this association to be 5333 Threshold : torn down. 5335 Peer Rwnd : Current calculated value of the peer's rwnd. 5337 Next TSN : The next TSN number to be assigned to a new DATA chunk. 5338 : This is sent in the INIT or INIT ACK chunk to the peer 5339 : and incremented each time a DATA chunk is assigned a 5340 : TSN (normally just prior to transmit or during 5341 : fragmentation). 5343 Last Rcvd : This is the last TSN received in sequence. This value is 5344 TSN : set initially by taking the peer's Initial TSN, 5345 : received in the INIT or INIT ACK chunk, and 5346 : subtracting one from it. 5348 Mapping : An array of bits or bytes indicating which out of 5349 Array : order TSN's have been received (relative to the 5350 : Last Rcvd TSN). If no gaps exist, i.e. no out of order 5351 : packets have been received, this array will be set to all 5352 : zero. This structure may be in the form of a circular 5353 : buffer or bit array. 5355 Ack State : This flag indicates if the next received packet 5356 : is to be responded to with a SACK. This is initialized 5357 : to 0. When a packet is received it is incremented. 5358 : If this value reaches 2 or more, a SACK is sent and the 5359 : value is reset to 0. Note: This is used only when no DATA 5360 : chunks are received out of order. When DATA chunks are 5361 : out of order, SACK's are not delayed (see Section 6). 5363 Inbound : An array of structures to track the inbound streams. 5364 Streams : Normally including the next sequence number expected 5365 : and possibly the stream number. 5367 Outbound : An array of structures to track the outbound streams. 5368 Streams : Normally including the next sequence number to 5369 : be sent on the stream. 5371 Reasm Queue : A re-assembly queue. 5373 Local : The list of local IP addresses bound in to this 5374 Transport : association. 5375 Address : 5376 List : 5378 Association : The smallest PMTU discovered for all of the 5379 PMTU : peer's transport addresses. 5381 12.3 Per Transport Address Data 5383 For each destination transport address in the peer's address list 5384 derived from the INIT or INIT ACK chunk, a number of data elements 5385 needs to be maintained including: 5387 Error count : The current error count for this destination. 5389 Error : Current error threshold for this destination i.e. 5390 Threshold : what value marks the destination down if Error count 5391 : reaches this value. 5393 cwnd : The current congestion window. 5395 ssthresh : The current ssthresh value. 5397 RTO : The current retransmission timeout value. 5399 SRTT : The current smoothed round trip time. 5401 RTTVAR : The current RTT variation. 5403 partial : The tracking method for increase of cwnd when in 5404 bytes acked : congestion avoidance mode (see Section 6.2.2) 5406 state : The current state of this destination, i.e. DOWN, UP, 5407 : ALLOW-HB, NO-HEARTBEAT, etc. 5409 PMTU : The current known path MTU. 5411 Per : A timer used by each destination. 5412 Destination : 5413 Timer : 5415 RTO-Pending : A flag used to track if one of the DATA chunks sent to 5416 this address is currently being used to compute a RTT. If 5417 this flag is 0, the next DATA chunk sent to this 5418 destination should be used to compute a RTT and this flag 5419 should be set. Every time the RTT calculation 5420 completes (i.e. the DATA chunk is SACK'd) clear this flag. 5422 last-time : The time this destination was last sent to. This can be 5423 used : used to determine if a HEARTBEAT is needed. 5425 12.4 General Parameters Needed 5427 Out Queue : A queue of outbound DATA chunks. 5429 In Queue : A queue of inbound DATA chunks. 5431 13. IANA Consideration 5433 This protocol will require port reservation like TCP for the use of 5434 "well known" servers within the Internet. All current TCP ports shall 5435 be automatically reserved in the SCTP port address space. New requests 5436 should follow IANA's current mechanisms for TCP. 5438 This protocol may also be extended through IANA in three ways: 5439 -- through definition of additional chunk types, 5440 -- through definition of additional parameter types, or 5441 -- through definition of additional cause codes within 5442 ERROR chunks 5444 In the case where a particular ULP using SCTP desires to have its own 5445 ports, the ULP should be responsible for registering with IANA for 5446 getting its ports assigned. 5448 13.1 IETF-defined Chunk Extension 5450 The definition and use of new chunk types is an integral part of 5451 SCTP. Thus, new chunk types are assigned by IANA through an 5452 IETF Consensus action as defined in [RFC2434]. 5454 The documentation for a new chunk code type must include the following 5455 information: 5456 (a) A long and short name for the new chunk type; 5457 (b) A detailed description of the structure of the chunk, which MUST 5458 conform to the basic structure defined in Section 3.2; 5459 (c) A detailed definition and description of intended use of each field 5460 within the chunk, including the chunk flags if any; 5461 (d) A detailed procedural description of the use of the new chunk type 5462 within the operation of the protocol. 5464 The last chunk type (255) is reserved for future extension if 5465 necessary. 5467 13.2 IETF-defined Chunk Parameter Extension 5469 The assignment of new chunk parameter type codes is done through an 5470 IETF Consensus action as defined in [RFC2434]. Documentation of the 5471 chunk parameter MUST contain the following information: 5473 (a) Name of the parameter type. 5474 (b) Detailed description of the structure of the parameter field. This 5475 structure MUST conform to the general type-length-value format 5476 described in Section 3.2.1. 5477 (c) Detailed definition of each component of the parameter value. 5478 (d) Detailed description of the intended use of this parameter type, 5479 and an indication of whether and under what circumstances 5480 multiple instances of this parameter type may be found within the 5481 same chunk. 5483 13.3 IETF-defined Additional Error Causes 5485 Additional cause codes may be allocated in the range 11 to 65535 5486 through a Specification Required action as defined in [RFC2434]. 5487 Provided documentation must include the following information: 5489 (a) Name of the error condition. 5490 (b) Detailed description of the conditions under which an SCTP 5491 endpoint should issue an ERROR (or ABORT) with this cause code. 5492 (c) Expected action by the SCTP endpoint which receives an ERROR 5493 (or ABORT) chunk containing this cause code. 5494 (d) Detailed description of the structure and content of data fields 5495 which accompany this cause code. 5497 The initial word (32 bits) of a cause code parameter MUST conform to 5498 the format shown in Section 3.3.10, i.e.: 5499 -- first two bytes contain the cause code value 5500 -- last two bytes contain length of the Cause Parameter. 5502 13.3 Payload Protocol Identifiers 5504 Except for value 0 which is reserved by SCTP to indicate an 5505 unspecified payload protocol identifier in a DATA chunk, SCTP will 5506 not be responsible for standardizing or verifying any payload protocol 5507 identifiers; SCTP simply receives the identifier from the upper layer 5508 and carries it with the corresponding payload data. 5510 The upper layer, i.e., the SCTP user, SHOULD standardize any specific 5511 protocol identifier with IANA if it is so desired. The use of any 5512 specific payload protocol identifier is out of the scope of SCTP. 5514 14. Suggested SCTP Protocol Parameter Values 5516 The following protocol parameters are RECOMMENDED: 5518 RTO.Initial - 3 seconds 5519 RTO.Min - 1 second 5520 RTO.Max - 60 seconds 5521 RTO.Alpha - 1/8 5522 RTO.Beta - 1/4 5523 Valid.Cookie.Life - 60 seconds 5524 Association.Max.Retrans - 10 attempts 5525 Path.Max.Retrans - 5 attempts (per destination address) 5526 Max.Init.Retransmits - 8 attempts 5527 HB.interval - 30 seconds 5529 IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to 5530 customize some of these protocol parameters (see Section 10). 5532 Note: RTO.Min SHOULD be set as recommended above. 5534 15. Acknowledgements 5536 The authors wish to thank Mark Allman, R.J.Atkinson, Richard Band, 5537 Scott Bradner, Steve Bellovin, Ram Dantu, R. Ezhirpavai, Mike Fisk, 5538 Sally Floyd, Matt Holdrege, Henry Houh, Christian Huitema, Gary 5539 Lehecka, John Loughney, Daniel Luan, Thomas Narten, Erik Nordmark, 5540 Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno 5541 Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, 5542 A. Sankar, Greg Sidebottom, Brian Wyld, and many others for their 5543 invaluable comments. 5545 16. Authors' Addresses 5547 Randall R. Stewart Tel: +1-815-479-8536 5548 Motorola, Inc. EMail: rstewart@flashcom.net 5549 1501 W. Shure Drive, #2315 5550 Arlington Heights, IL 60004 5551 USA 5553 Qiaobing Xie Tel: +1-847-632-3028 5554 Motorola, Inc. EMail: qxie1@email.mot.com 5555 1501 W. Shure Drive, #2309 5556 Arlington Heights, IL 60004 5557 USA 5559 Ken Morneault Tel: +1-703-484-3323 5560 Cisco Systems Inc. EMail: kmorneau@cisco.com 5561 13615 Dulles Technology Drive 5562 Herndon, VA. 20171 5563 USA 5564 Chip Sharp Tel: +1-919-392-3121 5565 Cisco Systems Inc. EMail:chsharp@cisco.com 5566 7025 Kit Creek Road 5567 Research Triangle Park, NC 27709 5568 USA 5570 Hanns Juergen Schwarzbauer Tel: +49-89-722-24236 5571 SIEMENS AG 5572 Hofmannstr. 51 5573 81359 Munich 5574 Germany 5575 EMail: HannsJuergen.Schwarzbauer@icn.siemens.de 5577 Tom Taylor Tel: +1-613-736-0961 5578 Nortel Networks 5579 1852 Lorraine Ave. 5580 Ottawa, Ontario 5581 Canada K1H 6Z8 5582 EMail:taylor@nortelnetworks.com 5584 Ian Rytina Tel: +61-3-9301-6164 5585 Ericsson Australia EMail:ian.rytina@ericsson.com 5586 37/360 Elizabeth Street 5587 Melbourne, Victoria 3000 5588 Australia 5590 Malleswar Kalla Tel: +1-973-829-5212 5591 Telcordia Technologies 5592 MCC 1J211R 5593 445 South Street 5594 Morristown, NJ 07960 5595 USA 5596 EMail: kalla@research.telcordia.com 5598 Lixia Zhang Tel: +1-310-825-2695 5599 UCLA Computer Science Department EMail: lixia@cs.ucla.edu 5600 4531G Boelter Hall 5601 Los Angeles, CA 90095-1596 5602 USA 5604 Vern Paxson Tel: +1-510-642-4274 x 302 5605 ACIRI EMail: vern@aciri.org 5606 1947 Center St., Suite 600, 5607 Berkeley, CA 94704-1198 5608 USA 5610 17. References 5612 [RFC768] Postel, J. (ed.), "User Datagram Protocol", RFC 768, August 5613 1980. 5615 [RFC793] Postel, J. (ed.), "Transmission Control Protocol", RFC 793, 5616 September 1981. 5618 [RFC1123] Braden, R., "Requirements for Internet hosts - application 5619 and support.", RFC 1123, October 1989. 5621 [RFC1191] Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191, 5622 November 1990. 5624 [RFC1700] Reynolds, J., and Postel, J. (ed.), "Assigned Numbers", 5625 RFC 1700, 5627 [RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery 5628 for IP version 6", RFC 1981, August 1996. 5630 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", RFC 1982, 5631 August 1996. 5633 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 5634 RFC 2026, October 1996. 5636 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 5637 Requirement Levels", BCP 14, RFC 2119, March 1997. 5639 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the 5640 Internet Protocol", RFC 2401, November 1998. 5642 [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", 5643 RFC 2402, November 1998. 5645 [RFC2406] S. Kent, R. Atkinson., "IP Encapsulating Security Payload 5646 (ESP)." RFC-2406, November 1998. 5648 [RFC2408] D. Maughan, M. Schertler, M. Schneider, J. Turner., 5649 "Internet Security Association and Key Management Protocol" 5650 RFC 2408, November 1998. 5652 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 5653 RFC 2409, November 1998. 5655 [RFC2434] T. Narten, and H. Avestrand, "Guidelines for Writing an IANA 5656 Considerations Section in RFCs.", RFC2434, October 1998. 5658 [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 5659 6 (IPv6) Specification", RFC 2460, December 1998. 5661 [RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion 5662 Control", RFC 2581, April 1999. October 1994. 5664 18. Bibliography 5666 [ALLMAN99] Allman, M., and Paxson, V., "On Estimating End-to-End 5667 Network Path Properties", Proc. SIGCOMM'99, 1999. 5669 [FALL96] Fall, K., and Floyd, S., Simulation-based Comparisons of 5670 Tahoe, Reno, and SACK TCP, Computer Communications Review, 5671 V. 26 N. 3, July 1996, pp. 5-21. 5673 [RFC1750] Eastlake , D. (ed.), "Randomness Recommendations for 5674 Security", RFC 1750, December 1994. 5676 [RFC1950] Deutsch P., Gailly J-L., "ZLIB Compressed Data Format 5677 Specification version 3.3" , RFC1950, May 1996. 5679 [RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 5680 for Message Authentication", RFC 2104, March 1997. 5682 [RFC2196] Fraser, B. (ed.), "Site Security Handbook", RFC 2196, 5683 September 1997. 5685 [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management 5686 Protocol", RFC 2522, March 1999. 5688 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., 5689 "TCP Congestion Control with a Misbehaving Receiver", ACM 5690 Computer Communication Review, 29(5), October 1999. 5692 Appendix A: Explicit Congestion Notification 5694 ECN (Ramakrishnan, k., Floyd, S., "Explicit Congestion Notification", 5695 RFC 2481, January 1999) describes a proposed extension to IP that 5696 details a method to become aware of congestion outside of datagram 5697 loss. This is an optional feature that an implementation MAY choose to 5698 add to SCTP. This appendix details the minor differences implementers 5699 will need to be aware of if they choose to implement this feature. 5700 In general RFC 2481 should be followed with the following exceptions. 5702 Negotiation: 5704 RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages 5705 of a TCP connection. The sender of the SYN sets two bits in the 5706 TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning 5707 behind this is to assure both sides are truly ECN capable. For SCTP 5708 this is not necessary. To indicate that an endpoint is ECN capable 5709 an endpoint SHOULD add to the INIT and or INIT ACK chunk the TLV 5710 reserved for ECN. This TLV contains no parameters, and thus has 5711 the following format: 5713 0 1 2 3 5714 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 5715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5716 | Parameter Type = 32768 | Parameter Length = 4 | 5717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5719 ECN-Echo: 5721 RFC 2481 details a specific bit for a receiver to send back in its 5722 TCP acknowledgements to notify the sender of the Congestion Experienced 5723 (CE) bit having arrived from the network. For SCTP this same indication 5724 is made by including the ECNE chunk. This chunk contains one data 5725 element, i.e. the lowest TSN associated with the IP datagram marked 5726 with the CE bit, and looks as follows: 5728 0 1 2 3 5729 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 5730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5731 | Chunk Type=12 | Flags=00000000| Chunk Length = 8 | 5732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5733 | Lowest TSN Number | 5734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5736 Note: The ECNE is considered a Control chunk. 5738 CWR: 5740 RFC 2481 details a specific bit for a sender to send in the header of 5741 its next outbound TCP segment to indicate to its peer that it has 5742 reduced its congestion window. This is termed the CWR bit. For 5743 SCTP the same indication is made by including the CWR chunk. 5744 This chunk contains one data element, i.e. the TSN number that 5745 was sent in the ECN-Echo. This element represents the lowest 5746 TSN number in the datagram that was originally marked with the 5747 CE bit. 5749 0 1 2 3 5750 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 5751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5752 | Chunk Type=13 | Flags=00000000| Chunk Length = 8 | 5753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5754 | Lowest TSN Number | 5755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5757 Note: The CWR is considered a Control chunk. 5759 Appendix B Alder 32 bit checksum calculation 5761 The Adler-32 checksum calculation given in this appendix is copied from 5762 [RFC1950]. 5764 Adler-32 is composed of two sums accumulated per byte: s1 is the sum 5765 of all bytes, s2 is the sum of all s1 values. Both sums are done 5766 modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 5767 checksum is stored as s2*65536 + s1 in network byte order. 5769 The following C code computes the Adler-32 checksum of a data buffer. 5770 It is written for clarity, not for speed. The sample code is in the 5771 ANSI C programming language. Non C users may find it easier to read 5772 with these hints: 5774 & Bitwise AND operator. 5775 >> Bitwise right shift operator. When applied to an 5776 unsigned quantity, as here, right shift inserts zero bit(s) 5777 at the left. 5778 << Bitwise left shift operator. Left shift inserts zero 5779 bit(s) at the right. 5780 ++ "n++" increments the variable n. 5781 % modulo operator: a % b is the remainder of a divided by b. 5782 #define BASE 65521 /* largest prime smaller than 65536 */ 5783 /* 5784 Update a running Adler-32 checksum with the bytes buf[0..len-1] 5785 and return the updated checksum. The Adler-32 checksum should be 5786 initialized to 1. 5788 Usage example: 5790 unsigned long adler = 1L; 5792 while (read_buffer(buffer, length) != EOF) { 5793 adler = update_adler32(adler, buffer, length); 5794 } 5795 if (adler != original_adler) error(); 5796 */ 5797 unsigned long update_adler32(unsigned long adler, 5798 unsigned char *buf, int len) 5799 { 5800 unsigned long s1 = adler & 0xffff; 5801 unsigned long s2 = (adler >> 16) & 0xffff; 5802 int n; 5804 for (n = 0; n < len; n++) { 5805 s1 = (s1 + buf[n]) % BASE; 5806 s2 = (s2 + s1) % BASE; 5807 } 5808 return (s2 << 16) + s1; 5809 } 5811 /* Return the adler32 of the bytes buf[0..len-1] */ 5812 unsigned long adler32(unsigned char *buf, int len) 5813 { 5814 return update_adler32(1L, buf, len); 5815 }