GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3286

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3286.txt · Last modified: 2002/05/22 20:59 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki