SCTP Applications

SCTP Applications
Stream Control Transmission Protocol (SCTP) is

a transport layer protocol that runs over Internet
Protocol (IP).
SCTP, which is considered a next generation

transport protocol, has all the features of existing
IP transport protocols like TCP/UDP and supports
more features. Many applications have started
using SCTP for these new features.
This application note discusses existing SCTP

applications and their reasons for using SCTP.
TECHNICAL NOTE
©2003 Hughes Software Systems Ltd.

 2003 Hughes Software Systems Ltd. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means, electronic or
otherwise, including photocopying, reprinting, or recording, for any purpose, without the express written
permission of Hughes Software Systems Ltd.
DISCLAIMER
Information in this document is subject to change without notice and should not be construed as a
commitment on the part of Hughes Software Systems. Hughes Software Systems does not assume
any responsibility or make any warranty against errors that may appear in this document and disclaims
any implied warranty of merchantability or fitness for a particular purpose.
Hughes Software Systems Ltd.

Plot 31, Electronic City
Sector 18, Gurgaon – 122015
Haryana (INDIA)
Tel: +91-124-2346666/2455555
Fax: +91-124-2342415/2342810
E-mail: info@hssworld.com
Visit us at: http://www.hssworld.com
Contents
Chapter 1. Introduction ....................................................................................................................... 5

Scope .................................................................................................................................. 5
Background ......................................................................................................................... 5
Chapter 2. SCTP usage in SIGTRAN Protocol .................................................................................. 9
SIGTRAN Overview ............................................................................................................ 9
SCTP usage in M3UA ....................................................................................................... 11
M3UA Overview .......................................................................................................................11
SCTP usage Characteristics....................................................................................................12
SCTP usage in M2PA ....................................................................................................... 12
M2PA Overview .......................................................................................................................12
SCTP Usage Characteristics ...................................................................................................12
SCTP usage in SUA.......................................................................................................... 12
SUA Overview..........................................................................................................................12
SCTP usage in M2UA ....................................................................................................... 13
M2UA Overview .......................................................................................................................13
SCTP usage in IUA ........................................................................................................... 14
IUA Overview ...........................................................................................................................14
Chapter 3. SCTP usage in MEGACO Protocol ................................................................................ 15
MEGACO Overview .......................................................................................................... 15
Reasons for using SCTP in MEGACO.....................................................................................16
Usage Guidelines.....................................................................................................................16
Chapter 4. SCTP usage in SIP Protocol........................................................................................... 19
SIP Overview..................................................................................................................... 19
Reasons for using SCTP .........................................................................................................19
Chapter 5. SCTP usage in Diameter Protocol ................................................................................. 23
Diameter Overview............................................................................................................ 23
Reasons for using SCTP .........................................................................................................23
Chapter 6. SCTP usage as Inter Process Communication (IPC) Mechanism.............................. 27
IPC Overview .................................................................................................................... 27
Sample IPC Application Description ........................................................................................27
Chapter 7. Application using Partially Reliable Transport Service of SCTP ............................... 31
Partial Reliability Overview................................................................................................ 31
Media Streaming Application ............................................................................................ 32
Chapter 8. SCTP Replacing TCP in Internet Browsers .................................................................. 33
Chapter 9. Reference ......................................................................................................................... 35

References ........................................................................................................................ 35
PRIVATE & CONFIDENTIAL
Technical Note 3
Contents
Acronyms .......................................................................................................................... 36
Chapter 10. About HSS........................................................................................................................ 37
Chapter 11. Contact HSS..................................................................................................................... 39
4 Technical Note
Chapter 1
Introduction
Scope
Stream Control Transmission Protocol (SCTP) is a connection-oriented Transport Layer
protocol that provides reliable data transfer service to its users in an Internet Protocol (IP)
Network. SCTP is considered a next-generation Transport Layer protocol. Transport
Control Protocol (TCP and User Datagram Protocol (UDP are existing Transport Layer
protocols. While SCTP provides all the features that TCP and UDP have, it has some
additional useful features as well. Many applications use SCTP today. This note discusses
some of the existing SCTP Applications, and why they use SCTP.
Background
SCTP was developed by the SIGTRAN working group of the Internet Engineering Task
Force (IETF) for Signaling Transport in the IP network. This was driven by the need for
Signaling Transport features that were not present in existing transport layer protocols
(TCP/ UDP). So, the SIGTRAN working group defined a new transport protocol with
these new features required for Signaling Transport. Table 1, compares SCTP features
with those of TCP and UDP.
From Table 1, it is apparent that features like Multi-Streaming, Multi-homing, Bundling,

Reliable without In Sequence Delivery, and Advanced Security are new features provided
by SCTP. The feature for preserving message boundary was also not present in the
reliable transport protocol (TCP) and was an addition in SCTP. The base RFC (RFC
2960) for SCTP with these features was published in October 2000.
After initial development by the SIGTRAN working group, the responsibilities for
supporting the subsequent extensions and enhancements were passed on to the Transport
Area Working Group (TWG) of the IETF. TWG is responsible for maintaining transport
Technical Note 5
Chapter 1: Introduction
layers protocols like TCP and UDP. The adoption of SCTP by TWG is one indication of
SCTP being targeted as a general-purpose transport protocol by the Internet Community
rather than a protocol that is suited only for SIGTRAN application.
Table 1: Feature Comparison
Feature Name TCP UDP SCTP Feature Description
Connection Oriented Yes No Yes A Connection setup with the peer side is
required for user message transport.
Connection Oriented protocols has
connection setup phase, data transfer
phase and connection termination
phase.
Reliable Transport Yes No Yes Protocol provides reliable delivery of
application message. This is typically
achieved by protocols by storing the
user messages locally for
retransmission) till the user messages
are successfully delivered to the peer
side.
Preserve Message No Yes Yes Transport Protocols supporting
boundary preserving of application messages
ensure that at the receiving side exactly
same message is delivered to the
receiving application. In case this feature
is not provided by the Transport protocol
application is required to build this,
which has a performance impact.
TCP is a stream-based protocol and
hence does not preserve Message
boundary.
In Sequence Delivery Yes No Yes All user messages are delivered to the
peer side application in the same
sequence in which those were delivered
by originating application.
Reliable without In No No Yes This feature is only supported by SCTP
Sequence Delivery protocol. It allows applications to use the
reliable delivery option without needing a
strictly in sequence delivery. It means
SCTP at receiving side would pass
messages to the application in the order
they arrive.
Checksum Yes Yes Yes To detect corruption of packet within the
IP network, originating side transport
protocol sends the checksum field with
each packet and the receiving side uses
this field to determine if the packet was
received correctly.
Path MTU Discovery Yes No Yes Multiple types of link layers can be
present between two Internet hosts
running Transport layer and each of
6 Technical Note
Feature Name TCP UDP SCTP Feature Description

these link types can have different value
of MTU (Maximum Transmission Unit)
value. Path MTU discovery procedure
detects the minimum MTU of all the links
in a path.
Congestion Control Yes No Yes Congestion Control procedure enable
the transport layer protocol to determine
the congestion status of the network
before sending any packet in the
network.
Multiple streams No No Yes To avoid head of the line blocking
problem of a TCP connection, SCTP
introduced concept of multiple stream.
SCTP supports sequencing of user
messages within each stream.
Multi-homing support No No Yes Supporting more than one IP address at
both sides (originating and Terminating)
of the connection is called multi-homing.
SCTP supports seamless switchover
from failed IP address to other IP
address while data transfer is ongoing.
Bundling No No Yes Combining of multiple messages in the
single IP packet before sending in the
network is called bundling. Bundling
works on the principle that choosing
packet sizes close to path MTU7
increases the network efficiency.
SCTP supports bundling of user and
control messages.
Advanced Security No No Yes Present transport protocols has some
Features known security problems like Denial of
Service (DOS) attacks. SCTP
overcomes these shortcomings by
adding procedures for the same.
The Internet community is very actively following SCTP protocol and work related to
extension of SCTP is ongoing in the IETF TWG working Group. Active participation of
Internet community in defining the following wide range of SCTP extensions provides
another indication of generic acceptance of SCTP protocol.
1. Management Interface Base (MIB) Support: This specifications intended to
standardize the management interface of SCTP.
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-09.txt
Technical Note 7
2. Socket Interface Support: One of the key reason for popularity of TCP and UDP
protocols was standardization of the application interface. This allowed application
written on one platform (Vendor) to work seamlessly on other platforms (Vendor).
In order to provide same flexibility to applications this extension specification
intends to standardize the application interface. To allow the existing UDP and TCP
applications to move to SCTP with minimum changes, this specifications defines
two types of interfaces, one of them is based on TCP model and is based on UDP
model. The current
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-06.txt
3. Dynamic IP address Changes: Base SCTP protocol (RFC 2960) allows IP addresses
to be exchanged during association setup time. Dynamic changes
(Addition/Deletion) in IP addresses of an Active association are not allowed in Base
SCTP Protocol. This extension specification allows such dynamic changes in active
SCTP association.
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-07.txt
4. SCTP implementation Guide: Wide spread usage of SCTP has resulted in a lot of
Editorial and Technical feedback on the SCTP Base Protocol. All the changes that
are accepted by the Authors are captured in this document. People implementing
SCTP can use this document for determining corrections over base SCTP protocol.
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt
5. Partial Reliability Extension: SCTP supports reliable delivery of User messages to

the peer side. Some applications are experimenting with the usage of partial
reliability approach. For the same the following draft defines the procedure that can
be used by SCTP implementations to provide per user message partial reliability
support
http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-00.txt
The rest of this note captures various SCTP applications and their reasons for using
SCTP.
8 Technical Note
Chapter 2
SCTP usage in SIGTRAN Protocol
SIGTRAN Overview
Most current Telecommunication Systems worldwide are based on circuit switched
technology where resources are dedicated for the whole duration of the call. However, in
such systems, resources are not fully utilized. A need has been felt for some time to move
these networks to packet-switched technology, where resources could be used more
efficiently.
To move telecom networks to Internet Protocol (IP), the ETSI TIPHON working group
recommended a decomposed Switch Architecture. Owing to its decomposed nature, the
architecture has the potential to provide reliability and redundancy to Telecom Networks
on IP. This architecture defined three network nodes – namely the Media Gateway (MG),
Signaling Gateway (SG) and Media Gateway Controller (MGC).
All media streams terminate on the MG, which converts media streams from one protocol
to another (like from Standard G.711 in circuit switch networks to G.723/G.729 in IP
networks etc.) Similarly, the SG terminates common channel signaling from circuit
switched networks like Signaling System No. 7 (SS7) and Integrated Services Digital
Network (ISDN) signaling. After the signaling information terminates at the SG, the
same is adapted for the IP network and sent over IP to the MGC. The protocol suite being
developed to transport signaling information between SG and MGC is called SIGTRAN.
Technical Note 9
Chapter 2: SCTP usage in SIGTRAN Protocol
Signaling Gateway IP Network
Media
SIGTRAN Gateway
MGCP
Media Gateway
SS7 Controller RTP
MEGACO
MEGACO Media
Gateway
Media Gateway
Figure 1: SIGTRAN in Decomposed VoIP Gateway
The initial scope of the SIGTRAN protocol suite was to transport SS7 signaling
information over IP networks. With the adoption of IP as protocol for the core network in
3rd Generation (3G) wireless networks, the need for a similar protocol suite for signaling
transport was felt. SIGTRAN was chosen as the protocol suite for this requirement. The
network architecture in which SIGTRAN could be used in 3rd Generation Wireless
Networks are different from that used in the SG-MGC configuration recommended by
TIPHON. These include:
•= Two nodes, both on IP network should be able to talk to each other using SIGTRAN
as the underlying transport technology.
•= 3G Wireless nodes could have both, IP and SS7 interfaces. These nodes could
connect to some of the nodes using SS7 interfaces, and to some of the nodes using
the IP interface.
The SIGTRAN Protocol suite was enhanced to add these functions.
10 Technical Note
Figure 2: SIGTRAN in Wireless Network
SCTP usage in M3UA
M3UA Overview
The Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation layer
(M3UA) is a protocol that supports the transport of SS7 MTP3 user signaling (e.g., ISUP
and SCCP messages) over IP using SCTP services also. A provision is made for protocol
elements that enable a seamless operation of MTP3-user peers in the SS7 and IP domains.
This protocol would be used between an SG and an MGC or IP-resident Database, or
between two IP-based applications. It is assumed that the SG receives SS7 signaling over
a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide
transport.
Technical Note 11
SCTP usage Characteristics

•= Each M3UA Signaling Process (ASP, SGP or IPSP) acts as an SCTP endpoint. Each
SCTP endpoint typically consists of multiple IP addresses.
•= There can only be one SCTP association between two same Signaling Processes.
•= M3UA is responsible for selecting the SCTP stream, keeping in mind the
sequencing and HOL requirements. Implementations typically do stream selection
based on SLS parameter.
•= M3UA Protocol reserves Stream ID 0 for protocol control messages and no user
data can flow on these streams.
•= M3UA always uses ordered message delivery.
SCTP usage in M2PA
M2PA Overview
The SS7 MTP2-User Peer-to-Peer Adaptation layer (M2PA) is a protocol that supports
the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3
signaling messages over Internet Protocol (IP) using SCTP services. This protocol would
be used between SS7 signaling points using the MTP Level 3 protocol. The SS7 signaling
points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport
of MTP Level 3 signaling messages.
SCTP Usage Characteristics

•= Each M2PA Signaling Link acts as an SCTP Endpoint typically consisting of
multiple IP addresses.
•= There is one SCTP association for one M2PA link between two M2PA nodes.
•= M2PA Links uses two SCTP streams, Stream 0 is used for Control messages and
Stream 1 is used for Data messages.
•= M2PA only uses the ordered message delivery.
SCTP usage in SUA
SUA Overview
The Signaling Connection Control Part User Adaptation layer (SUA) protocol is used to
transport any Signaling Connection Control Part-User signaling (e.g., Transaction
Capabilities Protocol, Radio Access Network Application Protocol, etc.) over IP using
SCTP. The protocol should be modular and symmetric, to allow it to work in diverse
architectures, such as a Signaling Gateway to IP Signaling Endpoint architecture as well
as a peer-to-peer IP Signaling Endpoint architecture. Protocol elements are added to
allow operation between peers in the SS7 and IP domains.
12 Technical Note

•= Each SUA Signaling Process (ASP, SGP or IPSP) acts as an SCTP endpoint. Each
SCTP endpoint typically consists of multiple IP addresses.
•= There can only be one SCTP association between a pair of Signaling Processes
•= SUA is responsible for selecting the SCTP stream keeping in mind the sequencing
and HOL requirements. Implementations typically do stream selection based on
Sequence Control parameter for Connection less service and based on number of
Active Connections on Local/Peer Signaling Process for Connection Oriented
Service.
•= SUA Protocol reserves Stream ID 0 for protocol control messages and no user data
can flow on these streams.
•= SUA Protocol uses unordered delivery for connectionless class 0 service. Ordered
delivery is used for the rest of the messages.
SCTP usage in M2UA
M2UA Overview
The SS7 MTP2-User Adaptation layer (M2UA) is a protocol for backhauling SS7 MTP2
user signaling messages over IP using SCTP. This protocol would be used between a
Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the
SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer
Part (MTP) to provide transport. The Signaling Gateway would act as a Signaling Link
Terminal.

•= Both ASP and SGP act as SCTP endpoint. Each SCTP endpoint typically consists of
multiple IP addresses.
•= There can only be one SCTP association between ASP and SGP.
•= M2UA is responsible for selecting the SCTP stream keeping in mind the sequencing
and HOL requirements. Implementations typically do stream selection by sending
all messages for a MTP2 link on a same SCTP stream.
•= M2UA Protocol reserves Stream ID 0 for protocol Control messages and no user
data can flow on these streams.
•= M2UA Protocol uses only ordered delivery
Technical Note 13
SCTP usage in IUA
IUA Overview
The ISDN Q.921-User Adaptation layer protocol is defined for backhauling ISDN Q.921
user messages over IP using SCTP. This protocol would be used between an SG and
MGC. It is assumed that the SG receives ISDN signaling over a standard ISDN interface.

•= Both ASP and SG Nodes acts as an SCTP endpoint. Each SCTP endpoint typically
consists of multiple IP addresses.
•= There can only be one SCTP association between ASP and SG.
•= IUA is responsible for selecting the SCTP stream keeping in mind the sequencing
and HOL requirements. Implementations typically do stream selection by sending
all messages for a data link over the same SCTP stream.
•= IAU Protocol reserves Stream ID 0 for protocol Control messages and no user data
can flow on these streams.
•= IUA protocol uses only ordered delivery
14 Technical Note
Chapter 3
SCTP usage in MEGACO Protocol
IP Network
Signaling Gateway
SIGTRAN
Media
MGCP Gateway
Media Gateway
SS7 Controller
MEGACO
MEGACO
Media
RTP Gateway
Media Gateway
Figure 3: MEGACO Network Diagram
MEGACO Overview
Voice over IP (VoIP) technology is a fast emerging technology for transporting media
over packet data networks. This parallel development of VoIP technology in different
parts of the world, have resulted in the co-existence of different protocols, defined for
communication between the various components of the ETSI TIPHON decomposed
gateway architecture, viz., Media Gateway and the Media Gateway Controller.
Technical Note 15
Chapter 3: SCTP usage in MEGACO Protocol
Figure 3 shows three major components of the Packet Network in the form of a public
data network. The signaling gateway (SG) functions as an interface between the media
gateway controller (MGC) for signaling to the SS7 network, the media gateway controller
functions as the call controller and the media gateway acts as an interface for the media
part of the call. The protocol that governs the information flow, as designated by the
reference point between MG and MGC, is designated as MEGACO. MEGACO protocol
was initially developed by IETF, but the same was later adopted by ITU-T. ITU-T
document number H.248 defines the MEGACO standard.
Reasons for using SCTP in MEGACO

MEGACO supports multiple lower layer transport layers protocols like TCP, UDP,
MTP3, M3UA and SCTP. MEGACO protocol discusses the exploitation of the following
features
1. Ordered and Unordered Delivery: The MEGACO protocol recommends using
ordered delivery for all transactions and unordered delivery for high priority
transaction. The use of unordered delivery is recommended so that high-priority
transactions can take advantage of potential preferential treatment of unordered
messages by SCTP implementations.
2. Multiple Stream: The MEGACO protocol recommends using different streams for
unrelated transactions. The same stream should only be used for transactions related
to the same context.
3. Retransmission Timers: Since SCTP provides reliable delivery, the MEGACO
protocol recommends running timers only for Entity failures.
Usage Guidelines
Annex H of ITU-T MEGACO specification document H.248 describes the use of SCTP
by MEGACO. Following is a relevant extract from Annex H of H.248. This text can be
used as a guideline for incorporating SCTP support in MEGACO implementations.
Annex H: Transport over SCTP

Overview
Protocol messages may be transmitted over the Stream Control Transmission
Protocol (SCTP). In a transaction-oriented protocol like H.248, there are
still ways for transaction requests or responses to be lost, e.g., caused
by entity/component failure. As such, it is recommended that entities
using SCTP transport implement application level timers for each request.
Commands should be sent to the default port number, 2944 for text-encoded
operation or 2945 for binary-encoded operation. Responses must be sent to
the address and port from which the corresponding commands were sent except
if the response is to a handoff or fail-over, in which case the procedures
of 11.5 apply). SCTP payload protocol identifier shall be 7.
Providing the At-Most-Once functionality
16 Technical Note
Chapter 3: SCTP usage in MEGACO Protocol
SCTP is designed to recover from transport losses or duplications, but loss

of a transaction request or its reply may nonetheless be noted in real
implementations. In the absence of a timely response, H.248 may repeat
commands. Most H.248 commands are not idempotent. The state of the MG
would become unpredictable if, for example, Add commands were executed
several times. To guard against such losses, it is recommended that
entities follow the procedures in H.248 Annex D.1.1 with two exceptions
a) LONG-TIMER shall not used,
b) TransactionResponseAck parameter shall not be used.
Transaction identifiers and three way handshake

a) Transaction identifiers: Section D.1.2.1 of H.248 is recommended.
b) Three-way handshake: Section D.1.2.2 of H.248 is not applicable.
Computing retransmission timers

With reliable non-duplicate delivery guaranteed by SCTP, application level
timers are only used to guard against entity/component failure. Therefore,
only simple timer mechanisms are required. The first retransmission of a
request can occur after a short interval. If additional retransmissions are
required a longer time interval is recommended between the retransmissions.
Provisional responses
The procedures in H.248 section 8.2.3 of this document apply. If an entity
receives a repetition of a transaction that is still being executed a
TransactionPending should be sent.
Ordering of commands
SCTP provides both ordered and unordered reliable delivery, settable on a
per-transaction basis. Therefore, H.248 can take advantage of the ordered
capability of SCTP. High priority transactions can get expedited treatment
by properly using unordered delivery. No special procedures are therefore
required.
Stream independence
SCTP can provide up to 65536 unidirectional streams in each direction of an
MGC-MG association. SCTP transmits messages and processes received messages
in one stream independent to the order or status of messages in any other
streams. H.248 may avoid head-of-line blocking by transmitting unrelated
transactions on different streams. Reliability is still provided. Ordering
of messages is available per-stream. It is recommended that transactions
related to one context be transported over the same stream.
Technical Note 17
Chapter 4
SCTP usage in SIP Protocol
SIP Overview
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol
for creating, modifying and terminating sessions with one or more participants. These
sessions include Internet multimedia conferences, Internet telephone calls and multimedia
distribution. Members in a session can communicate via multicast or via a mesh of
unicast relations, or a combination of these. SIP invitations used to create sessions carry
session descriptions, which allow participants to agree on a set of compatible media
types. SIP supports user mobility by proxying and redirecting requests to the user's
current location. Users can register their current location. SIP is not tied to any particular
conference control protocol. SIP is designed to be independent of the lower-layer
transport protocol and can be extended with additional capabilities.
Reasons for using SCTP

SIP Protocol can run over TCP, UDP and SCTP. Following are the motivations for using
SCTP as transport layer.
1. Multiple Stream for HOL: SCTP usage specification recommends using SCTP
streams to SIP Transaction Mapping. One advantage because of which protocol
recommends using multiple streams is to avoid HOL Blocking. Usage of multiple
streams for HOL is Mandatory.
2. SCTP Stream as Transaction Identification: SCTP usage specification recommends

SCTP stream Id to be used as mechanism for Transaction Identification. The usage
of stream ID as Transaction Identification mechanism is very inexpensive (in terms
of processing overheads), but since using this mechanism has interoperability issues
with implementations not supporting the same at receiving side, usage of same is
Technical Note 19
Chapter 4: SCTP usage in SIP Protocol
OPTIONAL for SIP implementations. SIP implementations not using this

mechanism are encourages to use stream ID zero and unordered delivery.
Usage Guidelines
SIP (Session Initiation Protocol) can run over multiple transport layer protocols that
include UDP and TCP. SIP extension draft (draft-ietf-sip-sctp-03.txt) proposes to add the
support of SCTP being used as transport layer by SIP protocol. Following is the extract
from the above draft that describes the usage of SCTP by SIP protocol.
Introduction - Usage of SCTP by SIP

SCTP is a new protocol which provides several features that may prove
beneficial for transport between SIP entities which exchange a large amount
of messages, including gateways and proxies. As SIP is transport
independent, support of SCTP is a relatively straightforward process,
nearly identical to support for TCP. Usage of SCTP requires no additional
headers or syntax in SIP. Below we show an example of a SIP URL with a
transport parameter and an example of a via header. In both examples SCTP
is the transport protocol.
sip:Bob.Johnson@example.com;transport=sctp
Via: SIP/2.0/SCTP ws1234.example.com:5060.
Rules for sending a request over SCTP are identical to TCP. The only
difference is that an SCTP sender has to choose a particular stream within
an association in order to send the request. Note that no SCTP identifier
needs to be defined for SIP messages. Therefore, the Payload Protocol
Identifier in SCTP DATA chunks transporting SIP messages MUST be set to
zero. The SIP transport layers of both peers are responsible to manage the
persistent SCTP connection between them. On the sender side the core or a
client (or server) transaction generates a request (or response) and passes
it to the transport layer. The transport sends the request to the peer's
transaction layer. The peer's transaction layer is responsible of
delivering the incoming request (or response) to the proper existing server
(or client) transaction. If no server (or client) transaction exists for
the incoming message the transport layer passes the request (or response)
to the core, which may decide to construct a new server (or client)
transaction. The mapping of SIP transactions into SCTP stream IDs serves
two purposes
a)Avoid Head Of the Line (HOL) blocking,
b)Provide a lightweight mechanism to perform transaction identification.
This allows an efficient delivery of incoming SIP messages from the SIP
transport layer to the client or server transaction the message belongs to.
The former is REQUIRED whereas the latter is RECOMMENDED.
20 Technical Note
Chapter 4: SCTP usage in SIP Protocol
This document describes how to achieve both goals. We believe that using
stream IDs to demultiplex incoming traffic is a useful mechanism to
implement highly efficient SIP proxies and gateways. However, we too
believe that it is essential that a SIP entity that is not stream ID aware
can interoperate with any other implementation. That is why this feature is
optional, and so, the second bullet is RECOMMENDED and not REQUIRED.
Mapping of SIP Transactions into Streams

A SIP entity needs to relate incoming SIP messages to existing client and
server transactions. On the client side incoming responses need to be
delivered to the client transaction that generated the request.
On the server side: ACKs for non-2xx final responses need to be delivered
to the INVITE server transaction that generated the response. The core
needs to relate incoming CANCEL requests to existing server transactions.
Note that retransmissions of a request are never received over a reliable
transport such as SCTP. In order to match a particular SIP message with an
existing client or server transaction it is necessary to compute the
transaction identifier of the message. The transaction identifier consists
of the To, From, Call-ID, Cseq and topmost Via header fields. The use of
SCTP stream IDs as lightweight transaction identifiers saves parsing these
headers every time a new SIP message arrives. If a SIP entity chooses not
to use SCTP stream IDs as lightweight transaction identifiers it MUST send
every request and every response it generates using the SCTP stream ID zero
with the "unordered" flag set. A SIP entity that decides to use stream IDs
to identify particular transactions MUST follow the rules described below
Size of the stream ID space

The SCTP stream identifier is a 16-bit field. Since stream zero and stream
2**16-1 cannot be used as transaction identifiers there are 2**15-1 = 32767
available stream IDs. A SIP proxy handling 333 requests per second (1.2
million Busy Hour Call attempts) would only run out of stream IDs if it
only handled INVITE transactions and if every transaction lasted more than
98 seconds (INVITE transactions typically last much less than that). Non-
INVITE transactions typically last less than INVITE transactions (16
seconds maximum using default timers), so a proxy can handle a larger
number of non-INVITE transactions. This calculation show that the stream ID
space is large enough even for proxies handling heavy traffic loads. And
even if a proxy did eventually run out of stream IDs, stream zero is always
available for the excess of traffic.
Technical Note 21
Chapter 5
SCTP usage in Diameter Protocol
Diameter Overview
The Diameter base protocol is intended to provide an Authentication, Authorization and
Accounting (AAA) framework for applications such as network access or IP mobility.
Diameter is also intended to work in local Authentication, Authorization and Accounting
and roaming situations. Diameter base Protocol specifies the message format, transport,
error reporting, accounting and security services to be used by all Diameter applications.
The Diameter base application needs to be supported by all Diameter implementations.
Reasons for using SCTP

1. Slow Failure: In case TCP connection is used, fail-over time is very slow. SCTP
supports path failure detection and automatic switchover to another path in case of
path failure. In case all the paths fails, SCTP notifies the same to application within
a configurable time.
2. Use of Multiple Streams: AAA Transport profile document (RFC 3539)

recommends using multiple SCTP streams for avoiding HOL Blocking. Usage of
stream ID as identifying information is prohibited.
3. Congestion Control/Congestion Avoidance: This is needed for effectively using the

network resources.
The current version of the DIAMETER protocol (draft-ietf-aaa-diameter-17.txt) allows
DIAMETER to run over both TCP and SCTP. It also recommends that in future
DIAMETER should only run over SCTP. The 3GPP forum has mandated that
DIAMETER should only run over SCTP.
Technical Note 23
Chapter 5: SCTP usage in Diameter Protocol
Usage Guidelines
AAA Transport Profile document (RFC 3539) discusses the various aspects of transport
from the point of view of AAA protocols. This document also provides recommendation
on using the Transport protocols. Following extract from the RFC 3529 can be used as
guideline by Diameter implementations incorporating SCTP support.
Transport Mappings
AAA Servers MUST support TCP and SCTP. AAA clients SHOULD support SCTP,
but MUST support TCP if SCTP is not available. As support for SCTP
improves, it is possible that SCTP support will be required on clients at
some point in the future. AAA agents inherit all the obligations of
Servers with respect to transport support.
Use of Nagle Algorithm

The Nagle algorithm is not used with SCTP.
Multiple Connections
AAA protocols SHOULD use only a single persistent connection between a AAA
client and a AAA agent or server. They SHOULD provide for pipelining of
requests, so that more than one request can be in progress at a time. In
order to minimize use of inactive connections in roaming situations, a AAA
client or agent MAY bring down a connection to a AAA agent or server if the
connection has been unutilized (discounting the watchdog) for a certain
period of time. This MUST NOT be less than BRINGDOWN_INTERVAL (5 minutes).
While a AAA client/agent SHOULD only use a single persistent connection to
a given AAA agent or server, it MAY have connections to multiple AAA agents
or servers. AAA client/agent connected to multiple agents/servers can treat
them as primary/secondary or LOADSHARE.
Application Layer Watchdog

In order to enable AAA implementations to more quickly detect transport and
application-layer failures, AAA protocols MUST support an application layer
watchdog message. The application layer watchdog message enables failover
from a peer that has failed, either because it is unreachable or because
its applications functions have failed. This is distinct from the purpose
of the SCTP heartbeat, which is to enable failover between interfaces. The
SCTP heartbeat may enable a failover to another path to reach the same
server, but does not address the situation where the server system or the
application service has failed. Therefore both mechanisms MAY be used
together. For further Details please refer to section 3.4.1 of RFC 3539.
Invalidation of Transport Parameter Estimates

To address this issue for SCTP, AAA implementations SHOULD use SCTP
heartbeats. [RFC2960] states that heartbeats should be enabled by default,
with an interval of 30 seconds. If this interval proves to be too long to
resolve this issue, AAA implementations MAY reduce the heartbeat interval.
Head of Line Blocking – Using SCTP Streams

Each AAA node SHOULD distribute its messages evenly across the range of
SCTP streams that it and its peer have agreed upon. (A lost message in one
24 Technical Note
Chapter 5: SCTP usage in Diameter Protocol
stream will not cause any other streams to block.) A trivial and effective
implementation of this simply increments a counter for the stream ID to
send on. When the counter reaches the maximum number of streams for the
association, it resets to 0. AAA peers MUST be able to accept messages on
any stream. Note that streams are used *solely* to prevent head-of-the-
line blocking. All identifying information is carried within the Diameter
payload. Messages distributed across multiple streams may not be received
in the order they are sent.
SCTP peers can allocate up to 65535 streams for an association. The cost
for idle streams may or may not be zero, depending on the implementation,
and the cost for non-idle streams is always greater than 0. So
administrators may wish to limit the number of possible streams on their
diameter nodes according to the resources of a particular node. On a
Diameter client, the number of streams may be determined by the maximum
number of peak users on the NAS. If a stream is available per user, then
this should be sufficient to prevent head-of-line Blocking. On a Diameter
proxy, the number of streams may be determined by the maximum number of
peak sessions in progress from that proxy to each downstream AAA server.
Technical Note 25
Chapter 6
SCTP usage as Inter Process Communication (IPC)

Mechanism
IPC Overview
All operating systems support multi-processing, which allows applications to
simultaneously run more than one process. Most of today’s application software exploit
this feature by dividing their functionality into multiple processes. Since these processes
need to communicate to each other to pass information elements, a communication
mechanism is needed for these processes to talk to each other. This communication
mechanism is called Inter Process Communication (IPC).
The selection of IPC mechanism is a key aspect of any software architecture. If the two
processes are running on the same UNIX machine, the IPC mechanism includes Message
Queues, Shared Memory, Unix Domain Sockets etc. But if the application is distributed
and processes can run across machines, transport layer protocols like UDP and TCP are
chosen as IPC mechanisms. SCTP has been found suitable by many applications for their
IPC needs because of support of features like reliable data transfer, multi-homing and
updated congestion mechanism features. Some applications have chosen SCTP over TCP,
finding it more suitable.
Sample IPC Application Description

High Availability (HA) Platform. System Using HA Platform for providing the
Redundancy of the application is shown in Figure 4.
Technical Note 27
Chapter 6: SCTP usage as Inter Process Communication (IPC) Mechanism
HA App1 HA App 2 HA App 1 HA App 1 HA App 2 HA App 3

(Active) (Standby) (Standby) (Standby) (Standby) (Standby)
HA Platform HA Platform
Node 1 Node 2
SCTP SCTP
Data Network
Figure 4: SCTP as IPC Sample Application - HA Platform
Figure 4 shows two nodes (Node1 and Node2) using the services of HA platform to
provide redundancy to applications running on these nodes. Multiple applications (shown
as HA appl1, HA app2 and HA app3) are running on these nodes. Only one of the
application instances is active, and there can be one or more standby instance. The HA
platform controls which is the active instance and which one is standby. The HA platform
monitors the health of applications and, if it detects failure of the active application, it
controls which standby instance should become active.
HA platform uses SCTP because of its reliability, updated congestion mechanism, and
multi-homing feature. The following points explain the benefits of the same for the HA
platform.
1. The HA platform design expects a reliable transport protocol underneath and hence
no application level recovery mechanisms are defined.
2. At the time of switchover, the HA platform is required to update the standby side
with the state of Active side. This requires a a lot of data to be transferred in a short
time. Since SCTP has incorporated all congestion-handling related procedures like
Selective Acknowledgement, Congestion Avoidance, Slow Start, Fast Retransmit,
Fast Recovery, etc, SCTP implementation is better equipped to handle peak data
transfer in different network topologies.
28 Technical Note
Chapter 6: SCTP usage as Inter Process Communication (IPC) Mechanism
3. The multi-homing feature of SCTP keeps the two HA platforms connected to each
other even after the failure of one or more paths. It is recommended that while using
the HA platform the two nodes connect to each other using a dual LAN.
Technical Note 29
Chapter 7
Application using Partially Reliable Transport Service of

SCTP
Partial Reliability Overview

There are two types of Transport Protocols that provide transport services to applications
in an IP network. One type of transport protocol, called Reliable Transport protocols,
ensure reliable delivery of application messages. Reliable transport protocols are
persistent in nature (i.e. they keep re-transmitting the messages until they are delivered
reliably to the peer end). The other type of transport protocol, called Unreliable Transport
protocols, do not guarantee reliable delivery of application messages. These are best
effort protocols (i.e. they only send the message once and the message may and may not
be delivered depending on the network conditions).
Some applications (predominantly real time applications) require a service that is a

combination of reliable and unreliable transport protocols. In real time applications, the
criticality of messages vary with time. For example, if the delivery of a message is
delayed beyond a given interval, it is best not to deliver the same. But within this time,
transport protocol should be persistent in delivering this message. Each user message may
have different criticality. and hence Applications may therefore wish to specify this
criticality to the transport protocol at the time of delivery of each user message.
To cater to the above and similar requirements, the TWG working group of IETF is
working on the definition of the partial reliable extension of SCTP Protocol. This
extension document allows applications to specify the degree of reliability that is required
for each user message.
Technical Note 31
Chapter 7: Application using Partially Reliable Transport Service of SCTP
Media Streaming Application

There is some ongoing research using the usage the SCTP Partial Reliable Extension
draft in voice and video streaming applications. RTP would run over SCTP rather than on
UDP and application would specify the degree of reliability with each message.
The MPEG-4 standard encodes a video stream in 3 different frames, “I”, “P” and “B”,
where the P and B frames depend on the “I” frame. Losing an “I” frame is especially bad.
Some experiments were conducted to observe the difference in behaviors when UDP is
used as the transport protocol, and when the Partial Reliability features of the SCTP is
used. These tests were conducted in congested conditions in the network and SCTP
partial reliability service was used for selectively retransmission of “I” frames. These
experiments show that performance may be improved by using the partial reliable SCTP.
Please see the following links for further details
http://www.gufi.org/~molter/papers/mpeg4sctp-molteni-villari-2002-10-24.pdf
http://www.gufi.org/~molter/papers/mpeg4sctp-slides-molteni-villari/index.html
32 Technical Note
Chapter 8
SCTP Replacing TCP in Internet Browsers
Current Internet browsers use TCP as transport protocol. These browsers can move to
SCTP to exploit some of its advanced features like multi-streaming. This would allow
browsers to use a different stream for independent data transfers. For example, if there are
two picture objets to be downloaded from the server for a page, the browser can use
different streams to transport the same. This would mean that displaying the first picture
would not be delayed because of the other. To achieve the same functionality in TCP, the
browsers need to open multiple TCP associations between the same hosts. This has a
much greater overhead in term of memory requirements.
Figure 5 shows a PC connected to a web server using an access router. SCTP is used as a
transport protocol in this case.
Access Router
Web
Server
SCTP over IP
SCTP over IP PC
Figure 5: SCTP in Web Browsers
Please see www.sctp.org for further details.
Technical Note 33
Chapter 9
Reference
References
1. Stream Control Transmission Protocol <RFC 2960>
2. Stream Control Transmission Protocol (SCTP) Management Information Base using
SMIv2 work in Progress <draft-ietf-sigtran-sctp-mib-10.txt>.
3. Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Socket
work in progress <draft-ietf-tsvwg-sctpsocket-06.txt>
4. Stream Control Transmission Protocol (SCTP) Implementer's Guide work in
progress < draft-ietf-tsvwg-sctpimpguide-08.txt>
5. Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
work in progress < draft-ietf-tsvwg-addip-sctp-07.txt >
6. Stream Control Transmission Protocol (SCTP) Partial Reliability Extension work in
progress < draft-ietf-tsvwg-prsctp-00.txt>
7. Stream Control Transmission Protocol (SCTP) Checksum Change < RFC 3309>
8. ITU-T MEGACO Protocol Specifications <H.248>
9. SIP: Session Initiation Protocol <RFC 2543>
10. The Stream Control Transmission Protocol as a Transport for the Session Initiation
Protocol work in progress <draft-ietf-sip-sctp-03.txt>
11. Diameter Base Protocol work in progress < draft-ietf-aaa-diameter-17.txt>
12. Authentication, Authorization and Accounting (AAA) Transport Profile <RFC
3539>
13. SCTP Web page www.sctp.org
14. Media Streaming using Partial Reliable SCTP
http://www.gufi.org/~molter/papers/mpeg4sctp-molteni-villari-2002-10-24.pdf
Technical Note 35
Chapter 9: Reference
Acronyms
Acronym Expansion
AAA Authentication, Authorization and Accounting
ASP Application Server Process
ETSI European Telecommunications Standards Institute
IETF Internet Engineering Task Force
IP Internet Protocol
M2PA MTP-2 Peer to Peer Adaptation Layer
M2UA MTP-2 User Adaptation Layer
M3UA MTP-3 User Adaptation Layer
MPEG Motion Pictures Expert Group
MTP-2 Message Transfer Part Layer 2
MTP3 Message Transfer Part Layer 3
RFC Request for Comments
SCTP Stream Control Transport Protocol
SG Signaling Gateway
SGP Signaling Gateway Process
SIGTRAN Signaling transport
SS7 Signaling System 7
SUA SCCP User Adaptation
SLS Signaling Link Selection
TIPHON Telecommunications and Internet Protocol
Harmonization over Networks
VoIP Voice Over Internet Protocol
36 Technical Note
Chapter 9: Hughes Software Systems: A global leader
Hughes Software Systems: A global leader
Hughes Software Systems (HSS) is the global leader in the convergence marketplace, providing
solutions for Voice over Packet, SS7, Broadband and Wireless. More than 200 customers worldwide
are using technology solutions from HSS. HSS offers both licensable technologies and outsourcing
services to meet its customers’ needs.
HSS constantly invests in building new technology and expertise, with a cherished customer base
consisting of global leaders such as Avaya, ADC Telecommunications, Alcatel, Coppercom,
Convergys, ip.access, Cisco, Ericsson, Veraz Networks, Italtel, Lucent Technologies, Marconi
Corporation, Motorola, NEC Corporation, NTT Commware, Nokia Networks, OKI, Santera Systems,
Sylantro Systems and more.
With a constant emphasis on evolution, HSS is a member of and an active participant in industry
forums such as IETF, 3GPP, International Softswitch Consortium, National Convergence Alliance,
SIP Forum, and ITU-T.
Incorporated in 1991, HSS is an ISO 9001certified company, assessed at SEI-CMMI Level 5.
HSS has global operations as part of the Hughes group, and has more than 2100 employees
worldwide. HSS has offices in the US, the UK, Germany, Japan and India. HSS is represented through
its distribution channels in China, Taiwan, Korea, Japan, Australia, New Zealand and Brazil, with
development centers in New Delhi and Bangalore in India, and Nuremberg in Germany.
HSS’ Comprehensive Solutions

HSS is the leading provider of outsourcing services and products to Network Equipment Providers
(NEP), worldwide.
Recognized globally as the leader in communications software, HSS offers the most comprehensive
range of full-spectrum software development services and enabling technologies.
NEPs across the world are facing the challenge of reducing costs and increasing profitability even as
the competitive landscape throws up more competition. They are addressing these challenges by:
•= Reducing costs by outsourcing software development and maintenance

•= Developing Next Generation Network elements on standard COTS hardware and off-the-shelf
software, or reusing current hardware platforms with off-the-shelf third-party software
HSS offers comprehensive software for building any of the following solutions:
•= Application Servers
•= Base Station Controllers
•= Call State Control Function (CSCF)
•= Charging Gateway Function (CGF)
•= Class 4 switches
Technical Note 37
Chapter 9: Hughes Software Systems: A global leader
•= Class 5 switches
•= Enhanced Service Platforms
•= Gateway GPRS Support Node (GGSN)
•= Home Location Register (HLR)
•= Intelligent Peripheral (IP)
•= IP-Centrex
•= IP-PBX
•= Media Gateway/ Media Servers
•= Mobile Switching Center (MSC)
•= Node B
•= Radio Network Controller (RNC)
•= Service Control Point (SCP)
•= Serving GPRS Support Node (SGSN)
•= SIP Server
•= Softswitch
•= Test and Measurement products
•= Wireless Softswitch
HSS offers you the unique benefit of licensing software products and carrying out customized
development. Alternatively, the products supplied by HSS can be enhanced and integrated by
customers’ teams as per their requirements.
38 Technical Note
Chapter 9: Contact HSS
Contact HSS
For more information, please contact HSS at:
United States +1-866-HSS-0247

(301)-212-7988
Europe
United Kingdom +44-208-6223859
Germany +49-89-83999-751
+49-172-410-9349
Japan +81-90-9370-9579
+81-90-3233-8891
India +91-124-2455151
Email : Info@hssworld.com
You can visit us at http://www.hssworld.com
Technical Note 39

SCTP Applications

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SCTP Applications

Uploaded by

Copyright:

Available Formats

SCTP Applications

Stream Control Transmission Protocol (SCTP) is

SCTP, which is considered a next generation

This application note discusses existing SCTP

©2003 Hughes Software Systems Ltd.

Hughes Software Systems Ltd.

Chapter 1. Introduction ....................................................................................................................... 5

Chapter 9. Reference ......................................................................................................................... 35

PRIVATE & CONFIDENTIAL

Chapter 11. Contact HSS..................................................................................................................... 39

PRIVATE & CONFIDENTIAL

From Table 1, it is apparent that features like Multi-Streaming, Multi-homing, Bundling,

PRIVATE & CONFIDENTIAL

PRIVATE & CONFIDENTIAL

Feature Name TCP UDP SCTP Feature Description

PRIVATE & CONFIDENTIAL

5. Partial Reliability Extension: SCTP supports reliable delivery of User messages to

PRIVATE & CONFIDENTIAL

SCTP usage in SIGTRAN Protocol

PRIVATE & CONFIDENTIAL

Signaling Gateway IP Network

Figure 1: SIGTRAN in Decomposed VoIP Gateway

PRIVATE & CONFIDENTIAL

Figure 2: SIGTRAN in Wireless Network

SCTP usage in M3UA

PRIVATE & CONFIDENTIAL

SCTP usage Characteristics

SCTP usage in M2PA

SCTP Usage Characteristics

SCTP usage in SUA

PRIVATE & CONFIDENTIAL

SCTP usage Characteristics

SCTP usage in M2UA

SCTP usage Characteristics

PRIVATE & CONFIDENTIAL

SCTP usage in IUA

SCTP usage Characteristics

PRIVATE & CONFIDENTIAL

SCTP usage in MEGACO Protocol

Figure 3: MEGACO Network Diagram

PRIVATE & CONFIDENTIAL

Reasons for using SCTP in MEGACO

Annex H: Transport over SCTP

Providing the At-Most-Once functionality

PRIVATE & CONFIDENTIAL

SCTP is designed to recover from transport losses or duplications, but loss

Transaction identifiers and three way handshake

Computing retransmission timers

PRIVATE & CONFIDENTIAL

SCTP usage in SIP Protocol

Reasons for using SCTP

2. SCTP Stream as Transaction Identification: SCTP usage specification recommends

PRIVATE & CONFIDENTIAL

OPTIONAL for SIP implementations. SIP implementations not using this

Introduction - Usage of SCTP by SIP

PRIVATE & CONFIDENTIAL

Mapping of SIP Transactions into Streams

Size of the stream ID space

PRIVATE & CONFIDENTIAL

SCTP usage in Diameter Protocol

Reasons for using SCTP

2. Use of Multiple Streams: AAA Transport profile document (RFC 3539)

3. Congestion Control/Congestion Avoidance: This is needed for effectively using the