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: [email protected] Visit us at: http://www.hssworld.com

Technical Note 3

PRIVATE & CONFIDENTIAL

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 Characteristics....................................................................................................13 SCTP usage in M2UA .......................................................................................................13 M2UA Overview .......................................................................................................................13 SCTP usage Characteristics....................................................................................................13 SCTP usage in IUA ...........................................................................................................14 IUA Overview ...........................................................................................................................14 SCTP usage Characteristics....................................................................................................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 Usage Guidelines.....................................................................................................................20

Chapter 5. SCTP usage in Diameter Protocol .................................................................................23 Diameter Overview............................................................................................................23 Reasons for using SCTP .........................................................................................................23 Usage Guidelines.....................................................................................................................24

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

Contents

4 Technical Note


Acronyms ..........................................................................................................................36

Chapter 10. About HSS........................................................................................................................37

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

Technical Note 5


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

Chapter 1: Introduction

6 Technical Note


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 boundary

No Yes Yes Transport Protocols supporting 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 Sequence Delivery

No No Yes This feature is only supported by SCTP 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


Technical Note 7


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 Features

No No Yes Present transport protocols has some 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

http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-09.txt


8 Technical Note


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.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-06.txt

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-07.txt

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpimpguide-08.txt

http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-00.txt

Technical Note 9


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.

Chapter 2: SCTP usage in SIGTRAN Protocol

10 Technical Note


Signaling Gateway

Media GatewayController

Media Gateway

MediaGateway

MediaGateway

SIGTRAN

MEGACOMEGACO

MGCP

RTP

IP Network

SS7

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.


Technical Note 11


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.


12 Technical Note


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.


Technical Note 13


SCTP usage Characteristics •= 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.

SCTP usage Characteristics •= 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


14 Technical Note


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.

SCTP usage Characteristics •= 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

Technical Note 15


Chapter 3

SCTP usage in MEGACO Protocol

Signaling Gateway

Media GatewayController

Media Gateway

MediaGateway

MediaGateway

SIGTRAN

MEGACOMEGACO

MGCP

RTP

SS7

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.

IP Network

Chapter 3: SCTP usage in MEGACO Protocol

16 Technical Note


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 SCTPOverviewProtocol messages may be transmitted over the Stream Control TransmissionProtocol (SCTP). In a transaction-oriented protocol like H.248, there arestill ways for transaction requests or responses to be lost, e.g., causedby entity/component failure. As such, it is recommended that entitiesusing SCTP transport implement application level timers for each request.Commands should be sent to the default port number, 2944 for text-encodedoperation or 2945 for binary-encoded operation. Responses must be sent tothe address and port from which the corresponding commands were sent exceptif the response is to a handoff or fail-over, in which case the proceduresof 11.5 apply). SCTP payload protocol identifier shall be 7.

Providing the At-Most-Once functionality

Chapter 3: SCTP usage in MEGACO Protocol

Technical Note 17


SCTP is designed to recover from transport losses or duplications, but lossof a transaction request or its reply may nonetheless be noted in realimplementations. In the absence of a timely response, H.248 may repeatcommands. Most H.248 commands are not idempotent. The state of the MGwould become unpredictable if, for example, Add commands were executedseveral times. To guard against such losses, it is recommended thatentities follow the procedures in H.248 Annex D.1.1 with two exceptionsa) LONG-TIMER shall not used,b) TransactionResponseAck parameter shall not be used.

Transaction identifiers and three way handshakea) 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 timersWith reliable non-duplicate delivery guaranteed by SCTP, application leveltimers are only used to guard against entity/component failure. Therefore,only simple timer mechanisms are required. The first retransmission of arequest can occur after a short interval. If additional retransmissions arerequired a longer time interval is recommended between the retransmissions.

Provisional responsesThe procedures in H.248 section 8.2.3 of this document apply. If an entityreceives a repetition of a transaction that is still being executed aTransactionPending should be sent.

Ordering of commandsSCTP provides both ordered and unordered reliable delivery, settable on aper-transaction basis. Therefore, H.248 can take advantage of the orderedcapability of SCTP. High priority transactions can get expedited treatmentby properly using unordered delivery. No special procedures are thereforerequired.

Stream independenceSCTP can provide up to 65536 unidirectional streams in each direction of anMGC-MG association. SCTP transmits messages and processes received messagesin one stream independent to the order or status of messages in any otherstreams. H.248 may avoid head-of-line blocking by transmitting unrelatedtransactions on different streams. Reliability is still provided. Orderingof messages is available per-stream. It is recommended that transactionsrelated to one context be transported over the same stream.

Technical Note 19


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

Chapter 4: SCTP usage in SIP Protocol

20 Technical Note


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 SIPSCTP is a new protocol which provides several features that may provebeneficial for transport between SIP entities which exchange a large amountof messages, including gateways and proxies. As SIP is transportindependent, support of SCTP is a relatively straightforward process,nearly identical to support for TCP. Usage of SCTP requires no additionalheaders or syntax in SIP. Below we show an example of a SIP URL with atransport parameter and an example of a via header. In both examples SCTPis the transport protocol.

sip:[email protected];transport=sctpVia: SIP/2.0/SCTP ws1234.example.com:5060.Rules for sending a request over SCTP are identical to TCP. The onlydifference is that an SCTP sender has to choose a particular stream withinan association in order to send the request. Note that no SCTP identifierneeds to be defined for SIP messages. Therefore, the Payload ProtocolIdentifier in SCTP DATA chunks transporting SIP messages MUST be set tozero. The SIP transport layers of both peers are responsible to manage thepersistent SCTP connection between them. On the sender side the core or aclient (or server) transaction generates a request (or response) and passesit to the transport layer. The transport sends the request to the peer'stransaction layer. The peer's transaction layer is responsible ofdelivering the incoming request (or response) to the proper existing server(or client) transaction. If no server (or client) transaction exists forthe 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 servestwo purposesa)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 SIPtransport layer to the client or server transaction the message belongs to.The former is REQUIRED whereas the latter is RECOMMENDED.

Chapter 4: SCTP usage in SIP Protocol

Technical Note 21


This document describes how to achieve both goals. We believe that usingstream IDs to demultiplex incoming traffic is a useful mechanism toimplement highly efficient SIP proxies and gateways. However, we toobelieve that it is essential that a SIP entity that is not stream ID awarecan interoperate with any other implementation. That is why this feature isoptional, and so, the second bullet is RECOMMENDED and not REQUIRED.

Mapping of SIP Transactions into StreamsA SIP entity needs to relate incoming SIP messages to existing client andserver transactions. On the client side incoming responses need to bedelivered to the client transaction that generated the request.On the server side: ACKs for non-2xx final responses need to be deliveredto the INVITE server transaction that generated the response. The coreneeds to relate incoming CANCEL requests to existing server transactions.Note that retransmissions of a request are never received over a reliabletransport such as SCTP. In order to match a particular SIP message with anexisting client or server transaction it is necessary to compute thetransaction identifier of the message. The transaction identifier consistsof the To, From, Call-ID, Cseq and topmost Via header fields. The use ofSCTP stream IDs as lightweight transaction identifiers saves parsing theseheaders every time a new SIP message arrives. If a SIP entity chooses notto use SCTP stream IDs as lightweight transaction identifiers it MUST sendevery request and every response it generates using the SCTP stream ID zerowith the "unordered" flag set. A SIP entity that decides to use stream IDsto identify particular transactions MUST follow the rules described below

Size of the stream ID spaceThe SCTP stream identifier is a 16-bit field. Since stream zero and stream2**16-1 cannot be used as transaction identifiers there are 2**15-1 = 32767available stream IDs. A SIP proxy handling 333 requests per second (1.2million Busy Hour Call attempts) would only run out of stream IDs if itonly handled INVITE transactions and if every transaction lasted more than98 seconds (INVITE transactions typically last much less than that). Non-INVITE transactions typically last less than INVITE transactions (16seconds maximum using default timers), so a proxy can handle a largernumber of non-INVITE transactions. This calculation show that the stream IDspace is large enough even for proxies handling heavy traffic loads. Andeven if a proxy did eventually run out of stream IDs, stream zero is alwaysavailable for the excess of traffic.

Technical Note 23


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.

Chapter 5: SCTP usage in Diameter Protocol

24 Technical Note


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 MappingsAAA Servers MUST support TCP and SCTP. AAA clients SHOULD support SCTP,but MUST support TCP if SCTP is not available. As support for SCTPimproves, it is possible that SCTP support will be required on clients atsome point in the future. AAA agents inherit all the obligations ofServers with respect to transport support.

Use of Nagle AlgorithmThe Nagle algorithm is not used with SCTP.

Multiple ConnectionsAAA protocols SHOULD use only a single persistent connection between a AAAclient and a AAA agent or server. They SHOULD provide for pipelining ofrequests, so that more than one request can be in progress at a time. Inorder to minimize use of inactive connections in roaming situations, a AAAclient or agent MAY bring down a connection to a AAA agent or server if theconnection has been unutilized (discounting the watchdog) for a certainperiod of time. This MUST NOT be less than BRINGDOWN_INTERVAL (5 minutes).While a AAA client/agent SHOULD only use a single persistent connection toa given AAA agent or server, it MAY have connections to multiple AAA agentsor servers. AAA client/agent connected to multiple agents/servers can treatthem as primary/secondary or LOADSHARE.

Application Layer WatchdogIn order to enable AAA implementations to more quickly detect transport andapplication-layer failures, AAA protocols MUST support an application layerwatchdog message. The application layer watchdog message enables failoverfrom a peer that has failed, either because it is unreachable or becauseits applications functions have failed. This is distinct from the purposeof the SCTP heartbeat, which is to enable failover between interfaces. TheSCTP heartbeat may enable a failover to another path to reach the sameserver, but does not address the situation where the server system or theapplication service has failed. Therefore both mechanisms MAY be usedtogether. For further Details please refer to section 3.4.1 of RFC 3539.

Invalidation of Transport Parameter EstimatesTo address this issue for SCTP, AAA implementations SHOULD use SCTPheartbeats. [RFC2960] states that heartbeats should be enabled by default,with an interval of 30 seconds. If this interval proves to be too long toresolve this issue, AAA implementations MAY reduce the heartbeat interval.

Head of Line Blocking – Using SCTP StreamsEach AAA node SHOULD distribute its messages evenly across the range ofSCTP streams that it and its peer have agreed upon. (A lost message in one

Chapter 5: SCTP usage in Diameter Protocol

Technical Note 25


stream will not cause any other streams to block.) A trivial and effectiveimplementation of this simply increments a counter for the stream ID tosend on. When the counter reaches the maximum number of streams for theassociation, it resets to 0. AAA peers MUST be able to accept messages onany stream. Note that streams are used *solely* to prevent head-of-the-line blocking. All identifying information is carried within the Diameterpayload. Messages distributed across multiple streams may not be receivedin the order they are sent.SCTP peers can allocate up to 65535 streams for an association. The costfor idle streams may or may not be zero, depending on the implementation,and the cost for non-idle streams is always greater than 0. Soadministrators may wish to limit the number of possible streams on theirdiameter nodes according to the resources of a particular node. On aDiameter client, the number of streams may be determined by the maximumnumber of peak users on the NAS. If a stream is available per user, thenthis should be sufficient to prevent head-of-line Blocking. On a Diameterproxy, the number of streams may be determined by the maximum number ofpeak sessions in progress from that proxy to each downstream AAA server.

Technical Note 27


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.

Chapter 6: SCTP usage as Inter Process Communication (IPC) Mechanism

28 Technical Note


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.

Data Network

HA App1 (Active)

HA App 2 (Standby)

HA App 1 (Standby)

HA App 1 (Standby)

HA App 2 (Standby)

HA App 3 (Standby)

HA Platform

Node 1 Node 2

HA Platform

SCTP SCTP

Chapter 6: SCTP usage as Inter Process Communication (IPC) Mechanism

Technical Note 29


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 31


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.

Chapter 7: Application using Partially Reliable Transport Service of SCTP

32 Technical Note


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


http://www.gufi.org/~molter/papers/mpeg4sctp-slides-molteni-villari/index.html

Technical Note 33


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.

PC

WebServer

Access Router

SCTP over IP

SCTP over IP

Figure 5: SCTP in Web Browsers

Please see www.sctp.org for further details.

http://www.sctp.org/

Technical Note 35


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


Chapter 9: Reference

36 Technical Note


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

Chapter 9: Hughes Software Systems: A global leader

Technical Note 37


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

Chapter 9: Hughes Software Systems: A global leader

38 Technical Note


•= 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.

Chapter 9: Contact HSS

Technical Note 39


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 : [email protected] You can visit us at http://www.hssworld.com

mailto:[email protected]

http://www.hssworld.com/

sctp applications

Documents