Stream Control Transmission Protocol

From Wikipedia, the free encyclopedia

The five-layer TCP/IP model
5. Application layer

DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · RTP · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS (and SSL) · SDP · SOAP · GTP · STUN · NTP · (more)
4. Transport layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
3. Network/internet layer
IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · IPsec · ARP · RARP · RIP · ICMP · ICMPv6 · IGMP · (more)
2. Data link layer
802.11 (WLAN) · 802.16 · Wi-Fi · WiMAX · ATM · DTM · Token ring · Ethernet · FDDI · Frame Relay · GPRS · EVDO · HSPA · HDLC · PPP · PPTP · L2TP · ISDN · ARCnet · LLTD · (more)
1. Physical layer
Ethernet physical layer · RS-232 · SONET/SDH · G.709 · Optical fiber · Coaxial cable · Twisted pair · (more)
This box: view • talk • edit

In the field of computer networking, the IETF Signaling Transport (SIGTRAN) working group defined the Stream Control Transmission Protocol (SCTP) as a transport layer protocol in 2000. RFC 4960 defines the protocol, with RFC 3286 providing an introductory text.

As a transport protocol, SCTP operates analogously to TCP or UDP. Indeed it provides some similar services as TCP—ensuring reliable, in-sequence transport of messages with congestion control. (In the absence of native SCTP support, it may sometimes be desirable to tunnel SCTP over UDP.)

Contents

[edit] Message-based multi-streaming

Whereas TCP transports a byte-stream, SCTP can transport multiple message-streams. All bytes sent in a TCP connection must be delivered in that order, which requires that a byte transmitted first must safely arrive at the destination before a second byte can be processed even if the second byte manages to arrive first. If an arbitrary number of bytes are sent in one step and later some more bytes are sent, these bytes will be received in order, but the receiver can not distinguish which bytes were sent in which step. SCTP in contrast, conserves message boundaries by operating on whole messages instead of single bytes. That means if one message of several related bytes of information is sent in one step, exactly that message is received in one step.

The term "multi-streaming" refers to the capability of SCTP to transmit several independent streams of messages in parallel. For example, transmitting two images in an HTTP application in parallel over the same SCTP association. You might think of multi-streaming as bundling several TCP-connections in one SCTP-association operating with messages instead of bytes.

TCP ensures the correct order of bytes in the stream by conceptually assigning a sequence number to each byte sent and ordering these bytes based on that sequence number when they arrive. SCTP, on the other hand, assigns different sequence numbers to messages sent in a stream. This allows independent ordering of messages in different streams. However, message ordering is optional in SCTP. If the user application so desires, messages will be processed in the order they are received instead of the order they were sent, should these differ.

Signaling in Public Switched Telephone Networks requires message-based delivery. Multi-Streaming also provides an advantage when used to transport PSTN services. If an SCTP connection is set up to carry, say, ten phone calls with one call per stream, then if a single message is lost in only one phone call, the other nine calls will not be affected. To handle ten phone calls in TCP, some form of multiplexing would be required to put all ten phone calls into a single byte-stream. If a single packet for phone call #3 is lost then all packets after that could not be processed until the missing bytes are retransmitted, thus causing unnecessary delays in the other calls.

[edit] Benefits

Benefits of SCTP include:

  • Multihoming support, where one (or both) endpoints of a connection can consist of more than one IP address, enabling transparent fail-over between redundant network paths.
  • Delivery of data in chunks within independent streams - this eliminates unnecessary head-of-line blocking, as opposed to TCP byte-stream delivery.
  • Path Selection and Monitoring - Selects a "primary" data transmission path and tests the connectivity of the transmission path.
  • Validation and Acknowledgment mechanisms - Protects against flooding attacks and provides notification of duplicated or missing data chunks.
  • Improved error detection suitable for jumbo Ethernet frames.

The designers of SCTP originally intended it for the transport of telephony (SS7) protocols over IP, with the goal of duplicating some of the reliability attributes of the SS7 signaling network in IP. This IETF effort is known as SIGTRAN. In the meantime, other uses have been proposed, for example the Diameter protocol and Reliable server pooling ("RSerPool").

[edit] Motivations

Transmission Control Protocol (TCP) has provided the primary means to transfer data across the Internet in a reliable way. However, TCP has imposed limitations on several applications. From RFC 4960:

  • TCP provides both reliable data transfer and strict order-of- transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay.
  • The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time.
  • The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts.
  • TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks.

All these limitations affect the performance of IP over public switched telephone networks.

[edit] Comparison between transport layers

Feature Name UDP TCP SCTP
Connection oriented No Yes Yes
Reliable transport No Yes Yes
Preserve message boundary Yes No Yes
Ordered delivery No Yes Yes
Unordered delivery Yes No Yes
Data checksum Yes Yes Yes
Checksum size (bits) 16 16 32
Path MTU No Yes Yes
Congestion control No Yes Yes
Multiple streams No No Yes
Multi-homing support No No Yes
Bundling / Nagle No Yes Yes

[edit] Implementations

The following operating systems implement SCTP:

Various third-party implementations implement SCTP for other operating systems.

FreeBSD is the reference implementation of SCTP.

Userspace library:

[edit] Packet structure

Bits Bits 0 - 7 8 - 15 16 - 23 24 - 31
+0 Source port Destination port
32 Verification tag
64 Checksum
96 Chunk 1 type Chunk 1 flags Chunk 1 length
128 Chunk 1 data
… …
… Chunk N type Chunk N flags Chunk N length
… Chunk N data
Main article: SCTP packet structure

SCTP packets have a simpler basic structure than TCP or UDP packets. Each consists of two basic sections:

  1. The common header, which occupies the first 12 bytes and is highlighted in blue, and
  2. The data chunks, which occupy the remaining portion of the packet. The first chunk is highlighted in green, and the last of N chunks (Chunk N) is highlighted in red.

Each chunk has a type identifier that is one byte long yielding, at most, 255 different chunk types. RFC 4960 defines a list of chunk types and there are currently 15 types defined. The remainder of the chunk is a two byte length (maximum size of 65,535 bytes) and the data. If the chunk does not form a multiple of 4 bytes (i.e., the length is not a multiple of 4) then it is implicitly padded with zeros which are not included in the chunk length.

[edit] See also

[edit] External links

[edit] RFCs

  • RFC 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
  • RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
  • RFC 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
  • RFC 4960 Stream Control Transmission Protocol
  • RFC 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
  • RFC 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
  • RFC 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
  • RFC 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
  • RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
  • RFC 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
  • RFC 3436 Transport Layer Security over Stream Control Transmission Protocol
  • RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change (Obsoleted by RFC 4960)
  • RFC 3286 An Introduction to the Stream Control Transmission Protocol
  • RFC 3257 Stream Control Transmission Protocol Applicability Statement
  • RFC 2960 Stream Control Transmission Protocol (Updated by RFC 3309 and obsoleted by RFC 4960)