7 Network Working Group L. Ong
8 Request for Comments: 3286 Ciena Corporation
9 Category: Informational J. Yoakum
14 An Introduction to the Stream Control Transmission Protocol (SCTP)
18 This memo provides information for the Internet community. It does
19 not specify an Internet standard of any kind. Distribution of this
24 Copyright (C) The Internet Society (2002). All Rights Reserved.
28 This document provides a high level introduction to the capabilities
29 supported by the Stream Control Transmission Protocol (SCTP). It is
30 intended as a guide for potential users of SCTP as a general purpose
35 The Stream Control Transmission Protocol (SCTP) is a new IP transport
36 protocol, existing at an equivalent level with UDP (User Datagram
37 Protocol) and TCP (Transmission Control Protocol), which provide
38 transport layer functions to many Internet applications. SCTP has
39 been approved by the IETF as a Proposed Standard [1]. The error
40 check algorithm has since been modified [2]. Future changes and
41 updates will be reflected in the IETF RFC index.
43 Like TCP, SCTP provides a reliable transport service, ensuring that
44 data is transported across the network without error and in sequence.
45 Like TCP, SCTP is a session-oriented mechanism, meaning that a
46 relationship is created between the endpoints of an SCTP association
47 prior to data being transmitted, and this relationship is maintained
48 until all data transmission has been successfully completed.
50 Unlike TCP, SCTP provides a number of functions that are critical for
51 telephony signaling transport, and at the same time can potentially
52 benefit other applications needing transport with additional
53 performance and reliability. The original framework for the SCTP
54 definition is described in [3].
58 Ong & Yoakum Informational [Page 1]
60 RFC 3286 SCTP Overview May 2002
63 2. Basic SCTP Features
65 SCTP is a unicast protocol, and supports data exchange between
66 exactly 2 endpoints, although these may be represented by multiple IP
69 SCTP provides reliable transmission, detecting when data is
70 discarded, reordered, duplicated or corrupted, and retransmitting
71 damaged data as necessary. SCTP transmission is full duplex.
73 SCTP is message oriented and supports framing of individual message
74 boundaries. In comparison, TCP is byte oriented and does not
75 preserve any implicit structure within a transmitted byte stream
78 SCTP is rate adaptive similar to TCP, and will scale back data
79 transfer to the prevailing load conditions in the network. It is
80 designed to behave cooperatively with TCP sessions attempting to use
83 3. SCTP Multi-Streaming Feature
85 The name Stream Control Transmission Protocol is derived from the
86 multi-streaming function provided by SCTP. This feature allows data
87 to be partitioned into multiple streams that have the property of
88 independently sequenced delivery, so that message loss in any one
89 stream will only initially affect delivery within that stream, and
90 not delivery in other streams.
92 In contrast, TCP assumes a single stream of data and ensures that
93 delivery of that stream takes place with byte sequence preservation.
94 While this is desirable for delivery of a file or record, it causes
95 additional delay when message loss or sequence error occurs within
96 the network. When this happens, TCP must delay delivery of data
97 until the correct sequencing is restored, either by receipt of an
98 out-of-sequence message, or by retransmission of a lost message.
100 For a number of applications, the characteristic of strict sequence
101 preservation is not truly necessary. In telephony signaling, it is
102 only necessary to maintain sequencing of messages that affect the
103 same resource (e.g., the same call, or the same channel). Other
104 messages are only loosely correlated and can be delivered without
105 having to maintain overall sequence integrity.
107 Another example of possible use of multi-streaming is the delivery of
108 multimedia documents, such as a web page, when done over a single
109 session. Since multimedia documents consist of objects of different
110 sizes and types, multi-streaming allows transport of these components
114 Ong & Yoakum Informational [Page 2]
116 RFC 3286 SCTP Overview May 2002
119 to be partially ordered rather than strictly ordered, and may result
120 in improved user perception of transport.
122 At the same time, transport is done within a single SCTP association,
123 so that all streams are subjected to a common flow and congestion
124 control mechanism, reducing the overhead required at the transport
127 SCTP accomplishes multi-streaming by creating independence between
128 data transmission and data delivery. In particular, each payload
129 DATA "chunk" in the protocol uses two sets of sequence numbers, a
130 Transmission Sequence Number that governs the transmission of
131 messages and the detection of message loss, and the Stream ID/Stream
132 Sequence Number pair, which is used to determine the sequence of
133 delivery of received data.
135 This independence of mechanisms allows the receiver to determine
136 immediately when a gap in the transmission sequence occurs (e.g., due
137 to message loss), and also whether or not messages received following
138 the gap are within an affected stream. If a message is received
139 within the affected stream, there will be a corresponding gap in the
140 Stream Sequence Number, while messages from other streams will not
141 show a gap. The receiver can therefore continue to deliver messages
142 to the unaffected streams while buffering messages in the affected
143 stream until retransmission occurs.
145 4. SCTP Multi-Homing Feature
147 Another core feature of SCTP is multi-homing, or the ability for a
148 single SCTP endpoint to support multiple IP addresses. The benefit
149 of multi-homing is potentially greater survivability of the session
150 in the presence of network failures. In a conventional single-homed
151 session, the failure of a local LAN access can isolate the end
152 system, while failures within the core network can cause temporary
153 unavailability of transport until the IP routing protocols can
154 reconverge around the point of failure. Using multi-homed SCTP,
155 redundant LANs can be used to reinforce the local access, while
156 various options are possible in the core network to reduce the
157 dependency of failures for different addresses. Use of addresses
158 with different prefixes can force routing to go through different
159 carriers, for example, route-pinning techniques or even redundant
160 core networks can also be used if there is control over the network
161 architecture and protocols.
163 In its current form, SCTP does not do load sharing, that is, multi-
164 homing is used for redundancy purposes only. A single address is
165 chosen as the "primary" address and is used as the destination for
166 all DATA chunks for normal transmission. Retransmitted DATA chunks
170 Ong & Yoakum Informational [Page 3]
172 RFC 3286 SCTP Overview May 2002
175 use the alternate address(es) to improve the probability of reaching
176 the remote endpoint, while continued failure to send to the primary
177 address ultimately results in the decision to transmit all DATA
178 chunks to the alternate until heartbeats can reestablish the
179 reachability of the primary.
181 To support multi-homing, SCTP endpoints exchange lists of addresses
182 during initiation of the association. Each endpoint must be able to
183 receive messages from any of the addresses associated with the remote
184 endpoint; in practice, certain operating systems may utilize
185 available source addresses in round robin fashion, in which case
186 receipt of messages from different source addresses will be the
187 normal case. A single port number is used across the entire address
188 list at an endpoint for a specific session.
190 In order to reduce the potential for security issues, it is required
191 that some response messages be sent specifically to the source
192 address in the message that caused the response. For example, when
193 the server receives an INIT chunk from a client to initiate an SCTP
194 association, the server always sends the response INIT ACK chunk to
195 the source address that was in the IP header of the INIT.
197 5. Features of the SCTP Initiation Procedure
199 The SCTP Initiation Procedure relies on a 4-message sequence, where
200 DATA can be included on the 3rd and 4th messages of the sequence, as
201 these messages are sent when the association has already been
202 validated. A "cookie" mechanism has been incorporated into the
203 sequence to guard against some types of denial of service attacks.
207 The "cookie" mechanism guards specifically against a blind attacker
208 generating INIT chunks to try to overload the resources of an SCTP
209 server by causing it to use up memory and resources handling new INIT
210 requests. Rather than allocating memory for a Transmission Control
211 Block (TCB), the server instead creates a Cookie parameter with the
212 TCB information, together with a valid lifetime and a signature for
213 authentication, and sends this back in the INIT ACK. Since the INIT
214 ACK always goes back to the source address of the INIT, the blind
215 attacker will not get the Cookie. A valid SCTP client will get the
216 Cookie and return it in the COOKIE ECHO chunk, where the SCTP server
217 can validate the Cookie and use it to rebuild the TCB. Since the
218 server creates the Cookie, only it needs to know the format and
219 secret key, this is not exchanged with the client.
226 Ong & Yoakum Informational [Page 4]
228 RFC 3286 SCTP Overview May 2002
231 Otherwise, the SCTP Initiation Procedure follows many TCP
232 conventions, so that the endpoints exchange receiver windows, initial
233 sequence numbers, etc. In addition to this, the endpoints may
234 exchange address lists as discussed above, and also mutually confirm
235 the number of streams to be opened on each side.
237 5.2 INIT Collision Resolution
239 Multi-homing adds to the potential that messages will be received out
240 of sequence or with different address pairs. This is a particular
241 concern during initiation of the association, where without
242 procedures for resolving the collision of messages, you may easily
243 end up with multiple parallel associations between the same
244 endpoints. To avoid this, SCTP incorporates a number of procedures
245 to resolve parallel initiation attempts into a single association.
247 6. SCTP DATA Exchange Features
249 DATA chunk exchange in SCTP follows TCP's Selective ACK procedure.
250 Receipt of DATA chunks is acknowledged by sending SACK chunks, which
251 indicate not only the cumulative Transmission Sequence Number (TSN)
252 range received, but also any non-cumulative TSNs, implying gaps in
253 the received TSN sequence. Following TCP procedures, SACKs are sent
254 using the "delayed ack" method, normally one SACK per every other
255 received packet, but with an upper limit on the delay between SACKs
256 and an increase to once per received packet when there are gaps
259 Flow and Congestion Control follow TCP algorithms. The advertised
260 receive window indicates buffer occupancy at the receiver, while a
261 per-path congestion window is maintained to manage the packets in
262 flight. Slow start, Congestion avoidance, Fast recovery and Fast
263 retransmit are incorporated into the procedures as described in RFC
264 2581, with the one change being that the endpoints must manage the
265 conversion between bytes sent and received and TSNs sent and
266 received, since TSN is per chunk rather than per byte.
268 The application can specify a lifetime for data to be transmitted, so
269 that if the lifetime has expired and the data has not yet been
270 transmitted, it can be discarded (e.g., time-sensitive signaling
271 messages). If the data has been transmitted, it must continue to be
272 delivered to avoid creating a hole in the TSN sequence.
282 Ong & Yoakum Informational [Page 5]
284 RFC 3286 SCTP Overview May 2002
287 7. SCTP Shutdown Features
289 SCTP Shutdown uses a 3-message procedure to allow graceful shutdown,
290 where each endpoint has confirmation of the DATA chunks received by
291 the remote endpoint prior to completion of the shutdown. An Abort
292 procedure is also provided for error cases when an immediate shutdown
295 Note that SCTP does not support the function of a "half-open"
296 connection as can occur in TCP, when one side indicates that it has
297 no more data to send, but the other side can continue to send data
298 indefinitely. SCTP assumes that once the shutdown procedure begins,
299 both sides will stop sending new data across the association, and
300 only need to clear up acknowledgements of previously sent data.
302 8. SCTP Message Format
304 The SCTP Message includes a common header plus one or more chunks,
305 which can be control or data. The common header has source and
306 destination port numbers to allow multiplexing of different SCTP
307 associations at the same address, a 32-bit verification tag that
308 guards against insertion of an out-of-date or false message into the
309 SCTP association, and a 32-bit checksum (this has been modified to
310 use the CRC-32c polynomial [2]) for error detection.
312 Each chunk includes chunk type, flag field, length and value.
313 Control chunks incorporate different flags and parameters depending
314 on the chunk type. DATA chunks in particular incorporate flags for
315 control of segmentation and reassembly, and parameters for the TSN,
316 Stream ID and Stream Sequence Number, and a Payload Protocol
319 The Payload Protocol ID has been included for future flexibility. It
320 is envisioned that the functions of protocol identification and port
321 number multiplexing will not be as closely linked in the future as
322 they are in current usage. Payload Protocol ID will allow the
323 protocol being carried by SCTP to be identified independent of the
324 port numbers being used.
326 The SCTP message format naturally allows support of bundling of
327 multiple DATA and control chunks in a single message, to improve
328 transport efficiency. Use of bundling is controllable by the
329 application, so that bundling of initial transmission can be
330 prohibited. Bundling will naturally occur on retransmission of DATA
331 chunks, to further reduce any chance of congestion.
338 Ong & Yoakum Informational [Page 6]
340 RFC 3286 SCTP Overview May 2002
347 Retransmission of DATA chunks occurs from either (a) timeout of the
348 retransmission timer; or (b) receipt of SACKs indicating the DATA
349 chunk has not been received. To reduce the potential for congestion,
350 the rate of retransmission of DATA chunks is limited. The
351 retransmission timeout (RTO) is adjusted based on estimates of the
352 round trip delay and backs off exponentially as message loss
355 In an active association with fairly constant DATA transmission,
356 SACKs are more likely to cause retransmission than the timeout. To
357 reduce the chance of an unnecessary retransmission, a 4 SACK rule is
358 used, so that retransmission only occurs on receipt of the 4th SACK
359 that indicates that the chunk is missing. This is intended to avoid
360 retransmits due to normal occurrences such as packets received out of
365 A count is maintained of the number of retransmissions to a
366 particular destination address without successful acknowledgement.
367 When this count exceeds a configured maximum, the address is declared
368 inactive, notification is given to the application, and the SCTP
369 begins to use an alternate address for the sending of DATA chunks.
371 Also, Heartbeat chunks are sent periodically to all idle destinations
372 (i.e., alternate addresses), and a counter is maintained on the
373 number of Heartbeats sent to an inactive destination without receipt
374 of a corresponding Heartbeat Ack. When this counter exceeds a
375 configured maximum, that destination address is also declared
378 Heartbeats continue to be sent to inactive destination addresses
379 until an Ack is received, at which point the address can be made
380 active again. The rate of sending Heartbeats is tied to the RTO
381 estimation plus an additional delay parameter that allows Heartbeat
382 traffic to be tailored according to the needs of the user
387 A count is maintained across all destination addresses on the number
388 of retransmits or Heartbeats sent to the remote endpoint without a
389 successful Ack. When this exceeds a configured maximum, the endpoint
390 is declared unreachable, and the SCTP association is closed.
394 Ong & Yoakum Informational [Page 7]
396 RFC 3286 SCTP Overview May 2002
401 The specification includes a model of the primitives exchanged
402 between the application and the SCTP layer, intended as informational
403 material rather than a formal API statement. A socket-based API is
404 being defined to simplify migration of TCP or UDP applications to the
407 11. Security Considerations
409 In addition to the verification tag and cookie mechanisms, SCTP
410 specifies the use of IPSec if strong security and integrity
411 protection is required. The SCTP specification does not itself
412 define any new security protocols or procedures.
414 Extensions to IPSec are under discussion to reduce the overhead
415 required to support multi-homing. Also, work is in progress on the
416 use of Transport Layer Security (TLS) over SCTP [4].
420 The SCTP format allows new chunk types, flags and parameter fields to
421 be defined as extensions to the protocol. Any extensions must be
422 based on standard agreements within the IETF, as no vendor-specific
423 extensions are supported in the protocol.
425 Chunk Type values are organized into four ranges to allow extensions
426 to be made with a pre-defined procedure for responding if a new Chunk
427 Type is not recognized at the remote endpoint. Responses include:
428 whole packet discard; packet discard with reporting; ignoring the
429 chunk; ignoring with reporting. Similar pre-defined responses are
430 specified for unrecognized Parameter Type values.
432 Chunk Parameter Type values are in principle independent ranges for
433 each Chunk Type. In practice, the values defined in the SCTP
434 specification have been coordinated so that a particular parameter
435 type will have the same Chunk Parameter Type value across all Chunk
436 Types. Further experience will determine if this alignment needs to
437 be maintained or formalized.
450 Ong & Yoakum Informational [Page 8]
452 RFC 3286 SCTP Overview May 2002
455 13. Informative References
457 [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H.,
458 Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
459 "Stream Control Transmission Protocol", RFC 2960, October 2000.
461 [2] Stewart, Sharp, et. al., "SCTP Checksum Change", Work in
464 [3] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
465 Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework
466 Architecture for Signaling Transport", RFC 2719, October 1999.
468 [4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work in
471 14. Authors' Addresses
475 10480 Ridgeview Drive
478 EMail: lyong@ciena.com
482 Emerging Opportunities
485 EMail: yoakum@nortelnetworks.com
506 Ong & Yoakum Informational [Page 9]
508 RFC 3286 SCTP Overview May 2002
511 15. Full Copyright Statement
513 Copyright (C) The Internet Society (2002). All Rights Reserved.
515 This document and translations of it may be copied and furnished to
516 others, and derivative works that comment on or otherwise explain it
517 or assist in its implementation may be prepared, copied, published
518 and distributed, in whole or in part, without restriction of any
519 kind, provided that the above copyright notice and this paragraph are
520 included on all such copies and derivative works. However, this
521 document itself may not be modified in any way, such as by removing
522 the copyright notice or references to the Internet Society or other
523 Internet organizations, except as needed for the purpose of
524 developing Internet standards in which case the procedures for
525 copyrights defined in the Internet Standards process must be
526 followed, or as required to translate it into languages other than
529 The limited permissions granted above are perpetual and will not be
530 revoked by the Internet Society or its successors or assigns.
532 This document and the information contained herein is provided on an
533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
541 Funding for the RFC Editor function is currently provided by the
562 Ong & Yoakum Informational [Page 10]