| |
| |
| |
| |
| |
| |
| Network Working Group L. Ong |
| Request for Comments: 3286 Ciena Corporation |
| Category: Informational J. Yoakum |
| Nortel Networks |
| May 2002 |
| |
| |
| An Introduction to the Stream Control Transmission Protocol (SCTP) |
| |
| Status of this Memo |
| |
| This memo provides information for the Internet community. It does |
| not specify an Internet standard of any kind. Distribution of this |
| memo is unlimited. |
| |
| Copyright Notice |
| |
| Copyright (C) The Internet Society (2002). All Rights Reserved. |
| |
| Abstract |
| |
| This document provides a high level introduction to the capabilities |
| supported by the Stream Control Transmission Protocol (SCTP). It is |
| intended as a guide for potential users of SCTP as a general purpose |
| transport protocol. |
| |
| 1. Introduction |
| |
| The Stream Control Transmission Protocol (SCTP) is a new IP transport |
| protocol, existing at an equivalent level with UDP (User Datagram |
| Protocol) and TCP (Transmission Control Protocol), which provide |
| transport layer functions to many Internet applications. SCTP has |
| been approved by the IETF as a Proposed Standard [1]. The error |
| check algorithm has since been modified [2]. Future changes and |
| updates will be reflected in the IETF RFC index. |
| |
| Like TCP, SCTP provides a reliable transport service, ensuring that |
| data is transported across the network without error and in sequence. |
| Like TCP, SCTP is a session-oriented mechanism, meaning that a |
| relationship is created between the endpoints of an SCTP association |
| prior to data being transmitted, and this relationship is maintained |
| until all data transmission has been successfully completed. |
| |
| Unlike TCP, SCTP provides a number of functions that are critical for |
| telephony signaling transport, and at the same time can potentially |
| benefit other applications needing transport with additional |
| performance and reliability. The original framework for the SCTP |
| definition is described in [3]. |
| |
| |
| |
| Ong & Yoakum Informational [Page 1] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| 2. Basic SCTP Features |
| |
| SCTP is a unicast protocol, and supports data exchange between |
| exactly 2 endpoints, although these may be represented by multiple IP |
| addresses. |
| |
| SCTP provides reliable transmission, detecting when data is |
| discarded, reordered, duplicated or corrupted, and retransmitting |
| damaged data as necessary. SCTP transmission is full duplex. |
| |
| SCTP is message oriented and supports framing of individual message |
| boundaries. In comparison, TCP is byte oriented and does not |
| preserve any implicit structure within a transmitted byte stream |
| without enhancement. |
| |
| SCTP is rate adaptive similar to TCP, and will scale back data |
| transfer to the prevailing load conditions in the network. It is |
| designed to behave cooperatively with TCP sessions attempting to use |
| the same bandwidth. |
| |
| 3. SCTP Multi-Streaming Feature |
| |
| The name Stream Control Transmission Protocol is derived from the |
| multi-streaming function provided by SCTP. This feature allows data |
| to be partitioned into multiple streams that have the property of |
| independently sequenced delivery, so that message loss in any one |
| stream will only initially affect delivery within that stream, and |
| not delivery in other streams. |
| |
| In contrast, TCP assumes a single stream of data and ensures that |
| delivery of that stream takes place with byte sequence preservation. |
| While this is desirable for delivery of a file or record, it causes |
| additional delay when message loss or sequence error occurs within |
| the network. When this happens, TCP must delay delivery of data |
| until the correct sequencing is restored, either by receipt of an |
| out-of-sequence message, or by retransmission of a lost message. |
| |
| For a number of applications, the characteristic of strict sequence |
| preservation is not truly necessary. In telephony signaling, it is |
| only necessary to maintain sequencing of messages that affect the |
| same resource (e.g., the same call, or the same channel). Other |
| messages are only loosely correlated and can be delivered without |
| having to maintain overall sequence integrity. |
| |
| Another example of possible use of multi-streaming is the delivery of |
| multimedia documents, such as a web page, when done over a single |
| session. Since multimedia documents consist of objects of different |
| sizes and types, multi-streaming allows transport of these components |
| |
| |
| |
| Ong & Yoakum Informational [Page 2] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| to be partially ordered rather than strictly ordered, and may result |
| in improved user perception of transport. |
| |
| At the same time, transport is done within a single SCTP association, |
| so that all streams are subjected to a common flow and congestion |
| control mechanism, reducing the overhead required at the transport |
| level. |
| |
| SCTP accomplishes multi-streaming by creating independence between |
| data transmission and data delivery. In particular, each payload |
| DATA "chunk" in the protocol uses two sets of sequence numbers, a |
| Transmission Sequence Number that governs the transmission of |
| messages and the detection of message loss, and the Stream ID/Stream |
| Sequence Number pair, which is used to determine the sequence of |
| delivery of received data. |
| |
| This independence of mechanisms allows the receiver to determine |
| immediately when a gap in the transmission sequence occurs (e.g., due |
| to message loss), and also whether or not messages received following |
| the gap are within an affected stream. If a message is received |
| within the affected stream, there will be a corresponding gap in the |
| Stream Sequence Number, while messages from other streams will not |
| show a gap. The receiver can therefore continue to deliver messages |
| to the unaffected streams while buffering messages in the affected |
| stream until retransmission occurs. |
| |
| 4. SCTP Multi-Homing Feature |
| |
| Another core feature of SCTP is multi-homing, or the ability for a |
| single SCTP endpoint to support multiple IP addresses. The benefit |
| of multi-homing is potentially greater survivability of the session |
| in the presence of network failures. In a conventional single-homed |
| session, the failure of a local LAN access can isolate the end |
| system, while failures within the core network can cause temporary |
| unavailability of transport until the IP routing protocols can |
| reconverge around the point of failure. Using multi-homed SCTP, |
| redundant LANs can be used to reinforce the local access, while |
| various options are possible in the core network to reduce the |
| dependency of failures for different addresses. Use of addresses |
| with different prefixes can force routing to go through different |
| carriers, for example, route-pinning techniques or even redundant |
| core networks can also be used if there is control over the network |
| architecture and protocols. |
| |
| In its current form, SCTP does not do load sharing, that is, multi- |
| homing is used for redundancy purposes only. A single address is |
| chosen as the "primary" address and is used as the destination for |
| all DATA chunks for normal transmission. Retransmitted DATA chunks |
| |
| |
| |
| Ong & Yoakum Informational [Page 3] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| use the alternate address(es) to improve the probability of reaching |
| the remote endpoint, while continued failure to send to the primary |
| address ultimately results in the decision to transmit all DATA |
| chunks to the alternate until heartbeats can reestablish the |
| reachability of the primary. |
| |
| To support multi-homing, SCTP endpoints exchange lists of addresses |
| during initiation of the association. Each endpoint must be able to |
| receive messages from any of the addresses associated with the remote |
| endpoint; in practice, certain operating systems may utilize |
| available source addresses in round robin fashion, in which case |
| receipt of messages from different source addresses will be the |
| normal case. A single port number is used across the entire address |
| list at an endpoint for a specific session. |
| |
| In order to reduce the potential for security issues, it is required |
| that some response messages be sent specifically to the source |
| address in the message that caused the response. For example, when |
| the server receives an INIT chunk from a client to initiate an SCTP |
| association, the server always sends the response INIT ACK chunk to |
| the source address that was in the IP header of the INIT. |
| |
| 5. Features of the SCTP Initiation Procedure |
| |
| The SCTP Initiation Procedure relies on a 4-message sequence, where |
| DATA can be included on the 3rd and 4th messages of the sequence, as |
| these messages are sent when the association has already been |
| validated. A "cookie" mechanism has been incorporated into the |
| sequence to guard against some types of denial of service attacks. |
| |
| 5.1 Cookie Mechanism |
| |
| The "cookie" mechanism guards specifically against a blind attacker |
| generating INIT chunks to try to overload the resources of an SCTP |
| server by causing it to use up memory and resources handling new INIT |
| requests. Rather than allocating memory for a Transmission Control |
| Block (TCB), the server instead creates a Cookie parameter with the |
| TCB information, together with a valid lifetime and a signature for |
| authentication, and sends this back in the INIT ACK. Since the INIT |
| ACK always goes back to the source address of the INIT, the blind |
| attacker will not get the Cookie. A valid SCTP client will get the |
| Cookie and return it in the COOKIE ECHO chunk, where the SCTP server |
| can validate the Cookie and use it to rebuild the TCB. Since the |
| server creates the Cookie, only it needs to know the format and |
| secret key, this is not exchanged with the client. |
| |
| |
| |
| |
| |
| |
| Ong & Yoakum Informational [Page 4] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| Otherwise, the SCTP Initiation Procedure follows many TCP |
| conventions, so that the endpoints exchange receiver windows, initial |
| sequence numbers, etc. In addition to this, the endpoints may |
| exchange address lists as discussed above, and also mutually confirm |
| the number of streams to be opened on each side. |
| |
| 5.2 INIT Collision Resolution |
| |
| Multi-homing adds to the potential that messages will be received out |
| of sequence or with different address pairs. This is a particular |
| concern during initiation of the association, where without |
| procedures for resolving the collision of messages, you may easily |
| end up with multiple parallel associations between the same |
| endpoints. To avoid this, SCTP incorporates a number of procedures |
| to resolve parallel initiation attempts into a single association. |
| |
| 6. SCTP DATA Exchange Features |
| |
| DATA chunk exchange in SCTP follows TCP's Selective ACK procedure. |
| Receipt of DATA chunks is acknowledged by sending SACK chunks, which |
| indicate not only the cumulative Transmission Sequence Number (TSN) |
| range received, but also any non-cumulative TSNs, implying gaps in |
| the received TSN sequence. Following TCP procedures, SACKs are sent |
| using the "delayed ack" method, normally one SACK per every other |
| received packet, but with an upper limit on the delay between SACKs |
| and an increase to once per received packet when there are gaps |
| detected. |
| |
| Flow and Congestion Control follow TCP algorithms. The advertised |
| receive window indicates buffer occupancy at the receiver, while a |
| per-path congestion window is maintained to manage the packets in |
| flight. Slow start, Congestion avoidance, Fast recovery and Fast |
| retransmit are incorporated into the procedures as described in RFC |
| 2581, with the one change being that the endpoints must manage the |
| conversion between bytes sent and received and TSNs sent and |
| received, since TSN is per chunk rather than per byte. |
| |
| The application can specify a lifetime for data to be transmitted, so |
| that if the lifetime has expired and the data has not yet been |
| transmitted, it can be discarded (e.g., time-sensitive signaling |
| messages). If the data has been transmitted, it must continue to be |
| delivered to avoid creating a hole in the TSN sequence. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Ong & Yoakum Informational [Page 5] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| 7. SCTP Shutdown Features |
| |
| SCTP Shutdown uses a 3-message procedure to allow graceful shutdown, |
| where each endpoint has confirmation of the DATA chunks received by |
| the remote endpoint prior to completion of the shutdown. An Abort |
| procedure is also provided for error cases when an immediate shutdown |
| must take place. |
| |
| Note that SCTP does not support the function of a "half-open" |
| connection as can occur in TCP, when one side indicates that it has |
| no more data to send, but the other side can continue to send data |
| indefinitely. SCTP assumes that once the shutdown procedure begins, |
| both sides will stop sending new data across the association, and |
| only need to clear up acknowledgements of previously sent data. |
| |
| 8. SCTP Message Format |
| |
| The SCTP Message includes a common header plus one or more chunks, |
| which can be control or data. The common header has source and |
| destination port numbers to allow multiplexing of different SCTP |
| associations at the same address, a 32-bit verification tag that |
| guards against insertion of an out-of-date or false message into the |
| SCTP association, and a 32-bit checksum (this has been modified to |
| use the CRC-32c polynomial [2]) for error detection. |
| |
| Each chunk includes chunk type, flag field, length and value. |
| Control chunks incorporate different flags and parameters depending |
| on the chunk type. DATA chunks in particular incorporate flags for |
| control of segmentation and reassembly, and parameters for the TSN, |
| Stream ID and Stream Sequence Number, and a Payload Protocol |
| Identifier. |
| |
| The Payload Protocol ID has been included for future flexibility. It |
| is envisioned that the functions of protocol identification and port |
| number multiplexing will not be as closely linked in the future as |
| they are in current usage. Payload Protocol ID will allow the |
| protocol being carried by SCTP to be identified independent of the |
| port numbers being used. |
| |
| The SCTP message format naturally allows support of bundling of |
| multiple DATA and control chunks in a single message, to improve |
| transport efficiency. Use of bundling is controllable by the |
| application, so that bundling of initial transmission can be |
| prohibited. Bundling will naturally occur on retransmission of DATA |
| chunks, to further reduce any chance of congestion. |
| |
| |
| |
| |
| |
| |
| Ong & Yoakum Informational [Page 6] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| 9. Error Handling |
| |
| 9.1 Retransmission |
| |
| Retransmission of DATA chunks occurs from either (a) timeout of the |
| retransmission timer; or (b) receipt of SACKs indicating the DATA |
| chunk has not been received. To reduce the potential for congestion, |
| the rate of retransmission of DATA chunks is limited. The |
| retransmission timeout (RTO) is adjusted based on estimates of the |
| round trip delay and backs off exponentially as message loss |
| increases. |
| |
| In an active association with fairly constant DATA transmission, |
| SACKs are more likely to cause retransmission than the timeout. To |
| reduce the chance of an unnecessary retransmission, a 4 SACK rule is |
| used, so that retransmission only occurs on receipt of the 4th SACK |
| that indicates that the chunk is missing. This is intended to avoid |
| retransmits due to normal occurrences such as packets received out of |
| sequence. |
| |
| 9.2 Path Failure |
| |
| A count is maintained of the number of retransmissions to a |
| particular destination address without successful acknowledgement. |
| When this count exceeds a configured maximum, the address is declared |
| inactive, notification is given to the application, and the SCTP |
| begins to use an alternate address for the sending of DATA chunks. |
| |
| Also, Heartbeat chunks are sent periodically to all idle destinations |
| (i.e., alternate addresses), and a counter is maintained on the |
| number of Heartbeats sent to an inactive destination without receipt |
| of a corresponding Heartbeat Ack. When this counter exceeds a |
| configured maximum, that destination address is also declared |
| inactive. |
| |
| Heartbeats continue to be sent to inactive destination addresses |
| until an Ack is received, at which point the address can be made |
| active again. The rate of sending Heartbeats is tied to the RTO |
| estimation plus an additional delay parameter that allows Heartbeat |
| traffic to be tailored according to the needs of the user |
| application. |
| |
| 9.3 Endpoint Failure |
| |
| A count is maintained across all destination addresses on the number |
| of retransmits or Heartbeats sent to the remote endpoint without a |
| successful Ack. When this exceeds a configured maximum, the endpoint |
| is declared unreachable, and the SCTP association is closed. |
| |
| |
| |
| Ong & Yoakum Informational [Page 7] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| 10. API |
| |
| The specification includes a model of the primitives exchanged |
| between the application and the SCTP layer, intended as informational |
| material rather than a formal API statement. A socket-based API is |
| being defined to simplify migration of TCP or UDP applications to the |
| use of SCTP. |
| |
| 11. Security Considerations |
| |
| In addition to the verification tag and cookie mechanisms, SCTP |
| specifies the use of IPSec if strong security and integrity |
| protection is required. The SCTP specification does not itself |
| define any new security protocols or procedures. |
| |
| Extensions to IPSec are under discussion to reduce the overhead |
| required to support multi-homing. Also, work is in progress on the |
| use of Transport Layer Security (TLS) over SCTP [4]. |
| |
| 12. Extensions |
| |
| The SCTP format allows new chunk types, flags and parameter fields to |
| be defined as extensions to the protocol. Any extensions must be |
| based on standard agreements within the IETF, as no vendor-specific |
| extensions are supported in the protocol. |
| |
| Chunk Type values are organized into four ranges to allow extensions |
| to be made with a pre-defined procedure for responding if a new Chunk |
| Type is not recognized at the remote endpoint. Responses include: |
| whole packet discard; packet discard with reporting; ignoring the |
| chunk; ignoring with reporting. Similar pre-defined responses are |
| specified for unrecognized Parameter Type values. |
| |
| Chunk Parameter Type values are in principle independent ranges for |
| each Chunk Type. In practice, the values defined in the SCTP |
| specification have been coordinated so that a particular parameter |
| type will have the same Chunk Parameter Type value across all Chunk |
| Types. Further experience will determine if this alignment needs to |
| be maintained or formalized. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Ong & Yoakum Informational [Page 8] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| 13. Informative References |
| |
| [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., |
| Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, |
| "Stream Control Transmission Protocol", RFC 2960, October 2000. |
| |
| [2] Stewart, Sharp, et. al., "SCTP Checksum Change", Work in |
| Progress. |
| |
| [3] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., |
| Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework |
| Architecture for Signaling Transport", RFC 2719, October 1999. |
| |
| [4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work in |
| Progress. |
| |
| 14. Authors' Addresses |
| |
| Lyndon Ong |
| Ciena Corporation |
| 10480 Ridgeview Drive |
| Cupertino, CA 95014 |
| |
| EMail: lyong@ciena.com |
| |
| |
| John Yoakum |
| Emerging Opportunities |
| Nortel Networks |
| |
| EMail: yoakum@nortelnetworks.com |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Ong & Yoakum Informational [Page 9] |
| |
| RFC 3286 SCTP Overview May 2002 |
| |
| |
| 15. Full Copyright Statement |
| |
| Copyright (C) The Internet Society (2002). All Rights Reserved. |
| |
| This document and translations of it may be copied and furnished to |
| others, and derivative works that comment on or otherwise explain it |
| or assist in its implementation may be prepared, copied, published |
| and distributed, in whole or in part, without restriction of any |
| kind, provided that the above copyright notice and this paragraph are |
| included on all such copies and derivative works. However, this |
| document itself may not be modified in any way, such as by removing |
| the copyright notice or references to the Internet Society or other |
| Internet organizations, except as needed for the purpose of |
| developing Internet standards in which case the procedures for |
| copyrights defined in the Internet Standards process must be |
| followed, or as required to translate it into languages other than |
| English. |
| |
| The limited permissions granted above are perpetual and will not be |
| revoked by the Internet Society or its successors or assigns. |
| |
| This document and the information contained herein is provided on an |
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
| |
| Acknowledgement |
| |
| Funding for the RFC Editor function is currently provided by the |
| Internet Society. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Ong & Yoakum Informational [Page 10] |
| |