An Introduction to the Stream Control Transmission Protocol (SCTP)
RFC 3286

Document Type RFC - Informational (May 2002; No errata)
Was draft-ong-sigtran-sctpover (individual in tsv area)
Authors John Yoakum  , Lyndon Ong 
Last updated 2015-10-14
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3286 (Informational)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Scott Bradner
IESG note Responsible: RFC Editor
Send notices to <>
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.


   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

   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.
Show full document text