Zumara News

SCTP support is available as a system option


We have implemented an option for support of the stream control transmission protocol (SCTP) on our Zumara VoIP software based test solution. SCTP is a transport protocol which sits above IP and offers many advantages over the familiar TCP and UDP transport protocols particularly for users who wish to achieve carrier-grade VoIP network design. Our first release was developed in response to operator demand and will also allow SCTP to be used with SIP-i and SIP-t.

Future enhancements may include the use of SCTP with H.323 and with signalling protocols such as those shown below. Please contact us to discuss your requirements.

  • [RFC3332] SS7 MTP3 users: SCCP, ISUP, TUP...
  • [RFC3331] SS7 MTP2 users: MTP3
  • [RFC3868] SS7 SCCP users: RANAP, MAP(+TCAP), INAP (+TCAP)..
  • [RFC3057] ISDN Q.921 users: ISDN Q.931
  • [RFC3807] V5.2 / DSS1
Protocol trace

Zumara SCTP...

  • SCTP offers many advantages over TCP or UDP for Web based applications.
  • Zumara versatility allows user selection of the transport protocol.
  • With Zumara, SCTP may be selected to transport SIP-I using National ISUP variants.
  • SCTP capability enhances the Zumara protocol test system.

Quick Links

SCTP Offers Distinct Advantages over TCP and UDP
SCTP Background
Main Problems in the use of TCP

Advantages of SCTP
Comparison of SCTP, TCP and UDP

SCTP Offers Distinct Advantages over TCP and UDP

TCP (transmission control protocol) is connection oriented [RFC793] and ensures a reliable error-free delivery of data packets. When multiple packets are being sent, it ensures that all of them arrive at the destination and are presented in the correct order for the application.
UDP (user datagram protocol) is a simpler connectionless protocol [RFC768] aimed mainly at one-shot transactions, where a packet is sent and a response received. It does not include sequencing and re-transmission functions.
SCTP (stream control transmission protocol) is an end-to-end transport protocol [RFC2960]. It provides services therefore unavailable from either of the workhorse transport protocols TCP or UDP and this document is intended to highlight the benefits of using SCTP.  
SCTP endpoint is a logical sender or receiver of SCTP packets. An SCTP endpoint is a combination of one or more IP addresses and a port number and SCTP allows an endpoint to have multiple IP addresses. This allows an endpoint to be "multihomed" or spread over several physical platforms. This is an important concept because it provides fault tolerance in the network which is critical when trying to achieve carrier grade performance. Although SCTP can have multiple IP addresses it can only use one port number thus the same port number is applicable to each IP address. The combined IP addresses and port number are known as the 'transport address' and a given transport address may only apply to one SCTP endpoint. It is true to say however that one SCTP endpoint may have several transport addresses.
Association SCTP works by establishing a relationship between SCTP endpoints where such a relationship is known as an 'association' and is defined by the SCTP endpoints involved and the current protocol state. An association must be established before applications at two endpoints can communicate. The association may be terminated in error situations or once communication is complete. The upper-layer applications are not aware of such associations, they are blind to the fact that signalling is being carried by something other than standard MTP (message transfer part). The task of instigating an SCTP association falls to the appropriate adaptation layer.
Packets and chunks SCTP sits over IP and when SCTP wants to send a piece of information to the remote end it sends what is known as an SCTP packet to IP which routes the packet to the destination. The SCTP packet consists of a common header and a number of chunks. The common header includes the source and destination port numbers which when combined with the source and destination IP addresses, uniquely identify the endpoints. The header also includes a verification tag used to validate the sender of the packet.

An IP packet being passed from one network node to another

The diagram above shows how an IP packet would appear when being passed from one network node to another. The application data itself is passed down to the transport layer where a TCP, UDP or SCTP header is applied. This combination is passed to the network layer where an IP header is applied. The packet is then passed down to the datalink layer where it is packaged in to the frame structure for transmission. At the destination end, each layer extracts its own header information and passes the remainder to the layer above until the destination application receives only the original data.

SCTP Background

TCP and UDP have been used for more than 20 years but do not offer the speed and reliability required of a transport protocol used to carry signaling. In 1998 an IETF working group (SIGTRAN) was formed to design a mechanism for reliably transporting call control signaling over the Internet. SIGTRAN's goal was to create an IP complement to the telephone switching’s SS#7 network. UDP was already considered unsuitable due to it's unreliability and SCTP was developed to overcome problems associated with TCP as described below.

Two Main Problem Areas in the use of TCP

* Head of line blocking - TCP preserves the order of messages and therefore messages arriving later are delayed within the destination end's transport layer buffers until earlier lost messages are re-transmitted and received. For call control signaling, the delay on later messages can cause critical call control timers to expire resulting in call setup failures.

* Multihoming - TCP binds a single point of attachment at either endpoint which is not suitable for multihoming where a host uses multiple points of attachment for redundancy purposes. With multihoming, a host does not want to wait as long as several minutes to communicate critical messages to its peer communication endpoint and for call control signaling, such a delay is unacceptable when alternative paths exists.

SCTP offers a solution to head of line blocking by allowing an un-ordered reliable message delivery service where it is assumed that the application already provides ordering and does not want TCP's overhead and performance penalty just to preserve order.

SCTP also offers a solution to multihoming by allowing each of the two endpoints to specify multiple points of attachment. Having multiple points of attachment allows data to be automatically sent to alternate addresses when failures occur and most importantly, without the application(s) even knowing that lower level failures have occurred. Such fault tolerance is unavailable with TCP which binds each endpoint to a single point of attachment (interface). Should either endpoint interface or the link to the interface fail, all TCP connections bound to that interface would need to timeout and abort thus forcing the application(s) to re-establish the connection(s) and accurately pick up from where the abandoned connection(s) left off.

Other Advantages of SCTP

Multistreaming SCTP supports multiple, independent logical streams of messages within an SCTP association. Each message sent over SCTP association is assigned to a particular stream. All data within a stream is delivered in order with respect to other data in that stream and data in different streams have no order constraints. SCTP's resulting parallel ordered streams provide a specific instance of 'partial ordered' delivery. It is SCTP's multistreaming service that circumvents the head-of-line blocking system problems. Multistreaming has been found to facilitate the use of FTP over multiple lines, say for system backup or mirror site downloads. Multistreaming is also useful for applications wishing to multiplex related but independent data streams (e.g. video, voice, text) over a single end-to-end association rather than multiple TCP connections, one for each stream.
Message Orientation In TCP data sent between two endpoints is a stream of bytes. If necessary, an application must provide message framing. In SCTP, message boundaries are preserved. If an application sends a 100 byte message, the destination application will receive a 100 byte message in one piece. UDP provides such a message-oriented service but without the reliability of SCTP.
Extensibility A TCP byte is limited to 40 bytes for options but SCTP bytes may be extended by using Tag-Length-Value (TLV) fields. Embedded within STCP's TLV structures are compatibility handling procedures to preserve interoperability when one endpoint supports a more advanced feature set than the other.
Heartbeat/Keep-Alive SCTP uses a default keep-alive function. Regular heartbeats ensure reachability of a peer address, and help to maintain a Round Trip Time (RTT) estimate for each alternate address.
Message Time-to-Live SCTP provides an option to specify a time to live for each message. This feature allows the source application to specify how long the transmitted message will remain useful. If the time expires before the message can be reliably communicated to the destination, the source SCTP entity can stop trying effectively allowing it to skip or undo a message. This is known as 'partial reliability' which may be of interest to the mobile community and the online gaming community where the current location or environment status may vary. In this situation bandwidth may be preserved by discarding stale data to improve service in the face of loss or congestion.
Syn cookies SCTP uses a four way handshake with a signed cookie. The receiver of a new SCTP association setup does not reserve any resources until after the initiator proves it is at the IP address that it claims to be while setting up the association. Syn cookies are thus preventing IP spoofing for the known denial of service attack named SYN flooding [RFC2827].
Stronger checksum A 32-bit end-to-end Adler 32-checksum (CRC32C) is used for SCTP which is much stronger than the 16-bit ones-compliment sum used by TCP and UDP. This provides stronger verification that a message passes from end-to-end without errors going undetected.
Advanced TCP services recent advances in TCP such as SACK [RFC2018], Appropriate Byte Counting [RFC3465] and Explicit Congestion Notification [RFC3168] have been built in to SCTP rather than added to ensure that these features are present unlike some versions of TCP.


In summary, SCTP offers several advantages the most important being SCTP's head of line blocking avoidance, multistreaming of boundary preserved messages and multihoming's added fault tolerance at the application level. This makes SCTP much more suitable for supporting carrier-grade telephone signaling over the Internet as well as other message-oriented applications. Online banking, stock market transaction and other such applications will benefit greatly from SCTP's support for multihoming.

Multihoming can reduce the widespread routing table growth with applications where redundancy is critical. Organizations that move their mission critical applications to SCTP can take advantage of multihoming and not cross-advertise routes effectively creating host routes in IP routing tables. The use of SCTP would therefore yield a significant reduction in the current size of Internet routing tables. SCTP also facilitates the move from IPv4 to IPv6 by simultaneously spanning both and the wider implications of SCTP's "dual stack" nature are as yet undetermined.

Comparison Between the Features offered by SCTP, TCP and UDP

Connection-oriented Yes Yes No
Full duplex Yes Yes Yes
Reliable data transfer Yes Yes No
Ordered data delivery Yes No Yes
Unordered data delivery Yes Yes No
Flow control Yes Yes No
Congestion Control Yes Yes No
ECN Capable Yes Yes No
Selective ACK's Yes Opt No
Message boundaries preserved Yes No Yes
Path MTU discovery Yes Yes No
App. PDU fragmentation Yes Yes No
App. PDU bundling Yes Yes No
Multistreaming Yes No No
Multihoming Yes No No
SYN flood protection Yes No N/A
Allow half closed connections No Yes N/A
Reachability check Yes Yes No
Pseudo header for checksum No Yes Yes
Time wait state for VTAG for 4-tuple N/A