draft-ietf-sigtran-signalling-over-sctp-applic-09.txt   rfc4166.txt 
INTERNET-DRAFT L. Coene(Ed) Network Working Group L. Coene
Internet Engineering Task Force Siemens Request for Comments: 4166 Siemens
Issued: August 2003 J. Pastor Category: Informational J. Pastor-Balbas
Expires: February 2004 Ericsson Ericsson
February 2006
Telephony Signalling Transport over SCTP applicability statement
<draft-ietf-sigtran-signalling-over-sctp-applic-09.txt>
Status of this Memo Telephony Signalling Transport over
Stream Control Transmission Protocol (SCTP) Applicability Statement
This document is an Internet-Draft and is in full conformance with Status of This Memo
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six This memo provides information for the Internet community. It does
months and may be updated, replaced, or obsoleted by other documents not specify an Internet standard of any kind. Distribution of this
at any time. It is inappropriate to use Internet-Drafts as memo is unlimited.
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1ID-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the applicability of the several protocols This document describes the applicability of the several protocols
developed under the signalling transport framework[RFC2719]. A developed under the signalling transport framework. A description of
description of the main issues regarding the use of the Stream the main issues regarding the use of the Stream Control Transmission
Control Transmission Protocol (SCTP)[RFC2960] and each adaptation Protocol (SCTP) and an explanation of each adaptation layer for
layer for transport of telephony signalling information over IP transport of telephony signalling information over IP infrastructure
infrastructure is explained. are given.
Draft Telephony Signalling over SCTP AS February 2004
Table of contents
Telephony signalling over SCTP Applicability statement ......... ii
Chapter 1: Introduction ........................................ 3
Chapter 1.1: Scope ..... ....................................... 3
Chapter 1.2: Terminology ....................................... 3
Chapter 1.3: Contributors ...................................... 4
Chapter 2: SIGTRAN architecture ................................ 4
Chapter 2.1: Overview ......................................... 4
Chapter 3: Issues for transporting Telephony signalling
information over SCTP .......................................... 6
Chapter 3.1: Congestion control ................................ 6
Chapter 3.2: Detection of failures ............................. 6
Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 7
Chapter 3.2.2: Heartbeat ....................................... 7
Chapter 3.2.3: Maximum Number of retransmissions ............... 7
Chapter 3.3: Shorten end-to-end message delay ................. 8
Chapter 3.4: Bundling considerations ........................... 8
Chapter 3.5: Stream Usage ...................................... 8
Chapter 4: User Adaptation Layers............................... 8
Chapter 4.1: Access Signalling.................................. 11
Chapter 4.1.1: IUA (ISDN Q.921 User Adaptation) ................ 11
Chapter 4.1.2: V5UA (V5.2-User Adaptation) Layer ............... 12
Chapter 4.1.3: DUA (DPNSS/DASS User adaptation) Layer .......... 13
Chapter 4.2: Network Signalling ................................ 14
Chapter 4.2.1: MTP lvl3 over IP ................................ 14
Chapter 4.2.1.1: M2UA (SS7 MTP2-User Adaptation) Layer ......... 14
Chapter 4.2.1.2: M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) .. 15
Chapter 4.2.1.3: Main difference between M2PA and M2UA ......... 16
Chapter 4.2.2: M3UA (SS7 MTP3 User Adaptation) Layer ........... 17
Chapter 4.2.3: SUA (SS7 SCCP User Adaptation) Layer ............ 18
Chapter 5: Security considerations ............................. 20
Chapter 6: References and related work ......................... 20
Chapter 6.1: Informative References ............................ 20
Chapter 7: Acknowledgments ..................................... 21
Chapter 8: Author's address .................................... 22
Draft Telephony Signalling over SCTP AS February 2004
1 INTRODUCTION
This document is intended to describe how to transport telephony
signalling protocols, used in classic telephony systems, over IP
networks. The whole architecture is called SIGTRAN (Signalling
Transport) as described in RFC2719 and is composed of a transport
protocol(SCTP) and several User Adaptation Layers(UAL). The
transport protocol SCTP has been developed to fulfill the stringent
requirements that telephony signalling networks have. The set of
User Adaptation Layers has also been introduced to make it possible
for different signalling protocols to use the SCTP layer.
1.1 Scope
The scope of this document is the Sigtran user adaptation layers and
SCTP protocols and how they are used to transport Telephony
signalling information over IP networks.
1.2 Terminology
The following terms are commonly identified in related work:
Association: SCTP connection between two endpoints.
Stream: A uni-directional logical channel established within an
association, within which all user messages are delivered in
sequence except for those submitted to the unordered delivery
service.
SPU: Signalling protocol user, the application on top of the User
adaptation layer.
CTSP: Classical Telephony Signalling protocol(examples: MTP level2,
MTP level 3, SCCP....).
UAL: User adaptation layer: the protocol that encapsulate the upper
layer telephony signalling protocols that are to be transported over
SCTP/IP.
ISEP: IP signalling endpoint: a IP node that implements SCTP and a
User adapatation layer.
SP: signalling point
Draft Telephony Signalling over SCTP AS February 2004
1.3 Contributors
The following people contributed to the document: L. Coene(Editor),
M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie,
M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong.
2 SIGTRAN architecture
The SIGTRAN architecture describes the transport of signalling
information over IP infrastructure.
Telephony Signalling transport over IP normally uses the following
architecture:
Telephony Signalling Application
|
+------------------------------------+
| Signalling Adaptation Layers |
+------------------------------------+
|
+------------------------------------+
|Stream Control Transmission Protocol|
| (SCTP) |
+------------------------------------+
|
Internet Protocol (IPv4/IPv6)
Figure 1.1: Telephony signalling transport protocol stack
The components of the protocol stack are :
(1) Adaptation modules used when the telephony application needs
to preserve an existing primitive interface. (e.g. management
indications, data operation primitives, ... for a particular
user/application protocol).
(2) SCTP, specially configured to meet the telephony application
performance requirements.
(3) The standard Internet Protocol.
The telephony signalling protocols to be transported can be:
- SS7 MTP3 users: SCCP, ISUP, TUP...
- SS7 MTP2 users: MTP3
Draft Telephony Signalling over SCTP AS February 2004 Table of Contents
- SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... 1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Terminology ................................................3
1.3. Contributors ...............................................3
2. SIGTRAN Architecture ............................................3
3. Issues for Transporting Telephony Signalling over SCTP ..........5
3.1. Congestion Control .........................................5
3.2. Detection of Failures ......................................6
3.2.1. Retransmission TimeOut (RTO) Calculation ............6
3.2.2. Heartbeat ...........................................7
3.2.3. Maximum Number of Retransmissions ...................7
3.3. Shorten End-to-End Message Delay ...........................7
3.4. Bundling Considerations ....................................7
3.5. Stream Usage ...............................................7
4. User Adaptation Layers ..........................................7
4.1. Access Signalling .........................................10
4.1.1. IUA (ISDN Q.921 User Adaptation) ...................10
4.1.2. V5UA (V5.2-User Adaptation) Layer ..................12
4.1.3. DUA (DPNSS/DASS User adaptation) Layer .............13
4.2. Network Signalling ........................................13
4.2.1. MTP lvl3 over IP ...................................14
4.2.2. M3UA (SS7 MTP3 User Adaptation) Layer ..............17
4.2.3. SUA (SS7 SCCP User Adaptation) Layer ...............18
5. Security Considerations ........................................20
6. Informative References .........................................20
- ISDN Q.921 users: Q.931 1. Introduction
- V5.2/DSS1 This document is intended to describe how to transport telephony
signalling protocols, used in classic telephony systems, over IP
networks. As described in [RFC2719], the whole architecture is
called SIGTRAN (Signalling Transport) and is composed of a transport
protocol (SCTP) and several User Adaptation Layers (UALs). The
transport protocol SCTP has been developed to fulfill the stringent
requirements of telephony signalling networks [RFC3257]. The set of
UALs has also been introduced to make it possible for different
signalling protocols to use the SCTP layer.
- .... 1.1. Scope
The user adaptation layers(UALs) are a set of protocols that The scope of this document is the SIGTRAN user adaptation layers and
encapsulate a specific signalling protocol to be transported over SCTP protocols and how they are used to transport telephony
SCTP. The adapation is done in a way that the upper signalling signalling information over IP networks.
protocols that are relayed remain unaware that the lower layers are
different to the originail lower telephony signalling layers. In
that sense, the upper interface of the user adapatation layers need
to be the same as the upper layer interface to its original lower
layer. If a MTP user is being relayed over the IP network, the
related UAL used to transport the MTP user will have the same upper
interface as MTP has.
The Stream Control Transmission Protocol was designed to fulfill the 1.2. Terminology
stringent transport requirements that classical signalling protocols
have and is therefore the recommended transport protocol to use for
this purpose.
The following functions are provided by SCTP: The following terms are commonly identified in related work:
- Reliable Data Transfer Association: SCTP connection between two endpoints.
- Multiple streams to help avoid head-of-line blocking Stream: A uni-directional logical channel established within an
association, within which all user messages are
delivered in sequence except for those submitted to the
unordered delivery service.
- Ordered and unordered data delivery on a per-stream basis SPU: Signalling protocol user, the application on top of the
User adaptation layer.
- Bundling and fragmentation of user data CTSP: Classical Telephony Signalling Protocol (examples
include: MTP level 2, MTP level 3, and SCCP).
- Congestion and flow control UAL: User Adaptation Layer, the protocol that encapsulates
the upper layer telephony signalling protocols that are
to be transported over SCTP/IP.
- Support for continuous monitoring of reachability ISEP: IP Signalling Endpoint, an IP node that implements SCTP
and a User adaptation layer.
- Graceful termination of association SP: Signalling Point.
- Support of multi-homing for added reliability 1.3. Contributors
- Protection against blind denial-of-service attacks The following people contributed to the document: L. Coene (Editor),
M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, M.
Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor, and L. Ong.
- Protection against blind masquerade attacks 2. SIGTRAN Architecture
SCTP is used as the transport protocol for telephony signalling The SIGTRAN architecture describes the transport of signalling
applications. Message boundaries are preserved during data information over IP infrastructure.
transport by SCTP and so each UAL can specify its own message
structure within the SCTP user data. The SCTP user data can be
delivered by the order of transmission within a stream(in sequence
delivery) or unordered.
Draft Telephony Signalling over SCTP AS February 2004 Telephony signalling transport over IP normally uses the following
architecture:
SCTP can be used to provide redundancy at the Telephony Signalling Protocol
transport layer and below. Telephony applications needing this level |
of redundancy can make use of SCTP's multi-homing support. +------------------------------------+
| User Adaptation Layers |
+------------------------------------+
|
+------------------------------------+
|Stream Control Transmission Protocol|
| (SCTP) |
+------------------------------------+
|
Internet Protocol (IPv4/IPv6)
SCTP can be used for telephony applications where head-of-line Figure 1: Telephony SIGnalling TRANsport Protocol Stack
blocking is a concern. Such an application should use multiple
streams to provide independent ordering of telephony signalling
messages.
3 Issues for transporting telephony signalling over SCTP The components of the protocol stack are:
Transport of telephony signalling requires special 1. Adaptation layers used when the telephony application needs to
considerations. In order to use SCTP, special care must be taken to preserve an existing primitive interface (e.g., management
meet the performance, timing and failure management requirements. indications or data operation primitives for a particular
user/application protocol).
2. SCTP, specially configured to meet the telephony application
performance requirements.
3. The standard Internet Protocol.
3.1 Congestion Control The telephony signalling protocols to be transported can be:
The basic mechanism of congestion control in SCTP have been o [RFC3332] SS7 MTP3 users: SCCP, ISUP, TUP...
described in [RFC2960]. SCTP congestion control sometimes conflicts o [RFC3331] SS7 MTP2 users: MTP3
with the timing requirements of telephony signalling application o [RFC3868] SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)...
messages which are transported by SCTP. During congestion, messages o [RFC3057] ISDN Q.921 users: Q.931
may be delayed by SCTP, thus sometimes violating the timing o [RFC3807] V5.2 / DSS1
requirements of those telephony applications. o ....
In an engineered network (e.g. a private intranet), in which network The user adaptation layers (UALs) are a set of protocols that
capacity and maximum traffic are very well controlled, some encapsulate a specific signalling protocol to be transported over
telephony signalling applications may choose to relax the congestion SCTP. The adaption is done in a way that the upper signalling
control rules of SCTP in order to satisfy the timing protocols, which are relayed, remain unaware that the lower layers
requirements. In order to do this, they should employ their own are different from the original lower telephony signalling layers.
congestion control mechanisms. But this must be done without In that sense, the upper interface of the user adaptation layers
destabilising the network, otherwise this would lead to potential needs to be the same as the upper layer interface is to its original
congestion collapse of the network. lower layer. If a MTP user is being relayed over the IP network, the
related UAL used to transport the MTP user will have the same upper
interface as MTP has.
Some telephony signalling applications may have their own congestion The Stream Control Transmission Protocol was designed to fulfill the
control and flow control techniques. These techniques may interact stringent transport requirements that classical signalling protocols
with the congestion control procedures in SCTP. have and is therefore the recommended transport protocol to use for
this purpose.
3.2 Detection of failures SCTP provides the following functions:
Telephony systems often must have no single point of failure in o Reliable Data Transfer
operation. o Multiple streams to help avoid head-of-line blocking
o Ordered and unordered data delivery on a per-stream basis
o Bundling and fragmentation of user data
o Congestion and flow control
o Support for continuous monitoring of reachability
o Graceful termination of association
o Support of multi-homing for added reliability
o Protection against blind denial-of-service attacks
o Protection against blind masquerade attacks
The UAL must meet certain service availability and performance SCTP is used as the transport protocol for telephony signalling
requirements according to the classical signalling layers they are applications. Message boundaries are preserved during data transport
by SCTP, so each UAL can specify its own message structure within the
SCTP user data. The SCTP user data can be delivered by the order of
transmission within a stream (in sequence delivery) or unordered.
Draft Telephony Signalling over SCTP AS February 2004 SCTP can be used to provide redundancy at the transport layer and
below. Telephony applications needing this level of redundancy can
make use of SCTP's multi-homing support.
replacing. Those requirements may be specific for each UAL. SCTP can be used for telephony applications where head-of-line
blocking is a concern. Such an application should use multiple
streams to provide independent ordering of telephony signalling
messages.
For example, telephony systems are often required to be able to 3. Issues for Transporting Telephony Signalling over SCTP
preserve stable calls during a component failure. Therefore error
situations at the transport layer and below must be detected quickly
so that the UAL can take approriate steps to recover and preserve the
calls. This poses special requirements on SCTP to discover
unreachablility of a destination address or a peer.
3.2.1 Retransmission TimeOut (RTO) calculation Transport of telephony signalling requires special considerations.
In order to use SCTP, an implementation must take special care to
meet the performance, timing, and failure management requirements.
The SCTP protocol parameter RTO.Min value has a direct impact on the 3.1. Congestion Control
calculation of the RTO itself. Some telephony applications want to
lower the value of the RTO.Min to less than 1 second. This would
allow the message sender to reach the maximum
number-of-retransmission threshold faster in the case of network
failures. However, lowering RTO.Min may have a negative impact on
network behaviour [ALLMAN99].
In some rare cases, telephony applications might not want to use the The basic mechanism of congestion control in SCTP has been described
exponential timer back-off concept in RTO calculation in order to in [RFC2960]. SCTP congestion control sometimes conflicts with the
speed up failure detection. The danger of doing this is that, when timing requirements of telephony signalling application messages
network congestion occurs, not backing off the timer may worsen the which are transported by SCTP. During congestion, messages may be
congestion situation. Therefore, this strategy should never be used delayed by SCTP, thus sometimes violating the timing requirements of
in public Internet. those telephony applications.
It should be noted that not using delayed SACK will also help faster In an engineered network (e.g., a private intranet), in which network
failure detection. capacity and maximum traffic are very well controlled, some telephony
signalling applications may choose to relax the congestion control
rules of SCTP in order to satisfy the timing requirements. In order
to do this, they should employ their own congestion control
mechanisms. This must be done without destabilizing the network;
otherwise, it would lead to potential congestion collapse of the
network.
3.2.2 Heartbeat Some telephony signalling applications may have their own congestion
control and flow control techniques. These techniques may interact
with the congestion control procedures in SCTP.
For faster detection of (un)availability of idle paths, the 3.2. Detection of Failures
telephony application may consider lowering the SCTP parameter
HB.interval. It should be noted this might result in a higher traffic
load.
3.2.3 Maximum number of retransmissions Often, telephony systems must have no single point of failure in
operation.
Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters The UAL must meet certain service availability and performance
to lower values will speed up both destination address and peer requirements according to the classical signalling layers they are
failure detection. However, if these values are set too low, the replacing. Those requirements may be specific for each UAL.
probability of false fault detections might increase.
Draft Telephony Signalling over SCTP AS February 2004 For example, telephony systems are often required to be able to
preserve stable calls during a component failure. Therefore, error
situations at the transport layer and below must be detected quickly
so that the UAL can take appropriate steps to recover and preserve
the calls. This poses special requirements on SCTP to discover
unreachability of a destination address or a peer.
3.3 Shorten end-to-end message delay 3.2.1. Retransmission TimeOut (RTO) Calculation
Telephony applications often require short end-to-end message The SCTP protocol parameter RTO.Min value has a direct impact on the
delays. The method described in section 3.2.1 on lowering RTO may calculation of the RTO itself. Some telephony applications want to
be considered. The different paths within a single association will lower the value of the RTO.Min to less than 1 second. This would
have a different RTO, so using the path with the lowest RTO will allow the message sender to reach the maximum
lead to a shorter end-to-end message delay for the application number-of-retransmission threshold faster in the case of network
running on top of the UAL's. failures. However, lowering RTO.Min may have a negative impact on
network behaviour [ALLMAN99].
3.4 Bundling considerations In some rare cases, telephony applications might not want to use the
exponential timer back-off concept in RTO calculation in order to
speed up failure detection. The danger of doing this is that, when
network congestion occurs, not backing off the timer may worsen the
congestion situation. Therefore, this strategy should never be used
on the public Internet.
Bundling small telephony signalling messages at transmission helps It should be noted that not using delayed SACK will also increase the
improve the bandwidth usage efficiency of the network. On the speed of failure detection.
downside, bundling may introduce additional delay to some of the
messages. This should be taken into consideration when end-to-end
delay is a concern.
3.5 Stream Usage 3.2.2. Heartbeat
Telephony signalling traffic is often composed of multiple, For faster detection of (un)availability of idle paths, the telephony
independent message sequences. It is highly desirable to transfer application may consider lowering the SCTP parameter HB.interval. It
those independent message sequences in separate SCTP streams. This should be noted this might result in a higher traffic load.
reduces the probability of head-of-line blocking in which the
retransmission of a lost message affects the delivery of other
messages not belonging to the same message sequence.
4. User Adaptation Layers 3.2.3. Maximum Number of Retransmissions
Users Adaptation Layers (UALs) are defined to encapsulate different Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters
signalling protocols in order to transport them over SCTP/IP to lower values will speed up both destination address and peer
failure detection. However, if these values are set too low, the
probability of false fault detections might increase.
There are UALs for both access signalling (DSS1) and trunk signalling 3.3. Shorten End-to-End Message Delay
(SS7). A brief description of the standardized UALs follows in the
next sub-sections.
The delivery mechanism in the several UALs Telephony applications often require short end-to-end message delays.
The method described in Section 3.2.1 for lowering RTO may be
considered. The different paths within a single association will
have a different RTO, so using the path with the lowest RTO will lead
to a shorter end-to-end message delay for the application running on
top of the UALs.
- Supports seamless operation of UALs user peers over an IP 3.4. Bundling Considerations
network connection.
- Supports the interface boundary that the UAL user had with the Bundling small telephony signalling messages at transmission helps
traditional lower layer. improve the bandwidth usage efficiency of the network. On the
downside, bundling may introduce additional delay to some of the
messages. This should be taken into consideration when end-to-end
delay is a concern.
Draft Telephony Signalling over SCTP AS February 2004 3.5. Stream Usage
- Supports management of SCTP transport associations and traffic Telephony signalling traffic is often composed of multiple,
between SGs and ISEPs or two ISEPs independent message sequences. It is highly desirable to transfer
those independent message sequences in separate SCTP streams. This
reduces the probability of head-of-line blocking in which the
retransmission of a lost message affects the delivery of other
messages not belonging to the same message sequence.
- Supports asynchronous reporting of status changes to management. 4. User Adaptation Layers
Signalling User Adaptation Layers have been developed for both: Users Adaptation Layers (UALs) are defined to encapsulate different
Access and Trunk Telephony Signalling. They are defined as follows. signalling protocols for transport over SCTP/IP.
Access Signalling: This is the signalling that is needed between and There are UALs for both access signalling (DSS1) and trunk signalling
access device and an exchange in the core network in order to (SS7). A brief description of the standardized UALs follows in the
establish, manage or release the voice or data call paths. There next sub-sections.
are several protocols that have been developed for this purpose.
Trunk Signalling: This is the signalling that is used between the The delivery mechanism in several UALs supports:
exchanges inside the core network in order to establish, manage or
release the voice or data call paths. The most common protocols
used for this purpose are known as the SS7 system that belongs to
the Common Channel Signalling (CCS) philosophy. The SS7 protocol
stack is depicted below:
+------+-----+-------+- -+-------+------+-----+------+ o Seamless operation of UALs user peers over an IP network
| | | | | | MAP | CAP | INAP | connection.
+ | + RANAP |...| BSSAP +-------------------+ o The interface boundary that the UAL user had with the traditional
| ISUP | TUP | | | | TCAP | lower layer.
+ | +---------------------------------------+ o Management of SCTP transport associations and traffic between SGs
| | | SCCP | and ISEPs or two ISEPs
+----------------------------------------------------+ o Asynchronous reporting of status changes to management.
| MTP3 |
+----------------------------------------------------+
| MTP2 |
+----------------------------------------------------+
| MTP1 |
+----------------------------------------------------+
The Telephony Signalling Protocols to be transported with the already Signalling User Adaptation Layers have been developed for both Access
designed UALS are: and Trunk Telephony Signalling. They are defined as follows.
- ISDN Q.921 Users: Q.931 Access Signalling: This is the signalling that is needed between an
- V5.2/DSS1 access device and an exchange in the core network in order to
- DPNSS/DASS2 establish, manage, or release the voice or data call paths. Several
- SS7 MTP3 Users: SCCP, ISUP, TUP protocols have been developed for this purpose.
- SS7 MTP2 Users: MTP3
- SS7 SCCP Users: TCAP, RANAP, BSSAP, ...
Two main scenarios have been developed to use the different UALS for Trunk Signalling: This is the signalling that is used between the
IP Signalling Transport: exchanges inside the core network in order to establish, manage, or
release the voice or data call paths. The most common protocols used
for this purpose are known as the SS7 system, which belongs to the
Common Channel Signalling (CCS) philosophy. The SS7 protocol stack
is depicted below:
Draft Telephony Signalling over SCTP AS February 2004 +------+-----+-------+- -+-------+------+-----+------+
| | | | | | MAP | CAP | INAP |
+ | + RANAP |...| BSSAP +-------------------+
| ISUP | TUP | | | | TCAP |
+ | +---------------------------------------+
| | | SCCP |
+----------------------------------------------------+
| MTP3 |
+----------------------------------------------------+
| MTP2 |
+----------------------------------------------------+
| MTP1 |
+----------------------------------------------------+
(1) Intercommunication of traditional Signalling transport nodes and Figure 2: SS7 Protocol Stack
IP based nodes.
Traditional Telephony The Telephony Signalling Protocols to be transported with the already
Telephony Signalling designed UALS are:
********* Signalling ********** over IP ********
* SEP *----------------* SG *--------------* ISEP *
********* ********** ********
+-------+ +-------+ o ISDN Q.921 Users: Q.931
|SigProt| |SigProt| o V5.2/DSS1
+-------+ +----+----+ +-------+ o DPNSS/DASS2 [RFC4129]
| | | |UAL | | UAL | o SS7 MTP3 Users: SCCP, ISUP, TUP
| | | +----+ +-------+ o SS7 MTP2 Users: MTP3
| TTST | |TTST|SCTP| | SCTP | o SS7 SCCP Users: TCAP, RANAP, BSSAP, ...
| | | +----+ +-------+
| | | | IP | | IP |
+-------+ +---------+ +-------+
SEP - Signalling Endpoint Two main scenarios have been developed to use the different UALS for
SG - Signalling Gateway IP Signalling Transport:
ISEP - IP Signalling Endpoint
SigProt - Signalling Protocol
TTSP - Traditional Telephony Signalling Protocol
UAL - User Adaptation Layer
SCTP - Stream Control Transport Protocol
It is also referred as SG to AS communication. AS is the name that 1. Intercommunication of traditional Signalling transport nodes and
UAL usually gives to the ISEP nodes. It stands for Application IP based nodes.
Server.
(2) Communication inside the IP network. Traditional Telephony
Telephony Signalling
********* Signalling ********** over IP ********
* SEP *----------------* SG *--------------* ISEP *
********* ********** ********
Telephony +-------+ +-------+
Signalling |SigProt| |SigProt|
********* over IP ********* +-------+ +----+----+ +-------+
* ISEP *------------------* ISEP * | | | |UAL | | UAL |
********* ********* | | | +----+ +-------+
| TTST | |TTST|SCTP| | SCTP |
| | | +----+ +-------+
| | | | IP | | IP |
+-------+ +---------+ +-------+
+-------+ +-------+ SEP - Signalling Endpoint
|SigProt| |SigProt| SG - Signalling Gateway
+-------+ +-------+ ISEP - IP Signalling Endpoint
| UAL | | UAL | SigProt - Signalling Protocol
+-------+ +-------+ TTSP - Traditional Telephony Signalling Protocol
| SCTP | | SCTP | UAL - User Adaptation Layer
+-------+ +-------+ SCTP - Stream Control Transport Protocol
| IP | | IP |
+-------+ +-------+
This is also referred to as IPSP communication. IPSP stands for IP Figure 3: General Architecture of SS7-IP Interworking
Draft Telephony Signalling over SCTP AS February 2004 This is also referred to as SG-to-AS communication. AS is the name
that UAL usually gives to the ISEP nodes. It stands for Application
Server.
Signalling Point and describes the role that the UAL plays on a 2. Communication inside the IP network.
IP-based node.
The first scenario is applied for both types of signalling (access Telephony
and trunk signalling). On the other hand the peer to peer basis can Signalling
only be used for trunk signalling. ********* over IP *********
* ISEP *------------------* ISEP *
********* *********
4.1 Access Signalling +-------+ +-------+
|SigProt| |SigProt|
+-------+ +-------+
| UAL | | UAL |
+-------+ +-------+
| SCTP | | SCTP |
+-------+ +-------+
| IP | | IP |
+-------+ +-------+
The SIGTRAN WG have developed UALs to transport the following Access Figure 4: General Architecture of Intra-IP Communication
Signalling protocols:
- ISDN Q.931 This is also referred to as IPSP communication. IPSP stands for IP
- V5.2 Signalling Point and describes the role that the UAL plays on an
- DPNSS/DASS2 IP-based node.
4.1.1 ISDN Q.931 over IP The first scenario is applied for both types of signalling (access
and trunk signalling). On the other hand, the peer-to-peer basis can
only be used for trunk signalling.
UAL: IUA (ISDN Q.921 User Adaptation) 4.1. Access Signalling
This document supports both ISDN Primary Rate Access (PRA) as well as The SIGTRAN WG has developed UALs to transport the following Access
Basic Rate Access (BRA) including the support for both point-to-point Signalling protocols:
and point-to-multipoint modes of communication. This support
includes Facility Associated Signalling (FAS), Non-Facility
Associated Signalling (NFAS) and NFAS with backup D channel.
It implements the client/server architecture. The default orientation o ISDN Q.931
is for the SG to take on the role of server while the ISEP is o V5.2
the client. The SCTP (and UDP/TCP) Registered User Port Number o DPNSS/DASS2
Assignment for IUA is 9900.
Examples of the upper layers to be transported are Q.931 and QSIG. 4.1.1. IUA (ISDN Q.921 User Adaptation)
The main scenario supported by this UAL is the SG to ISEP UAL: IUA (ISDN Q.921 User Adaptation)
communication where the ISEP role is typically played by a node
called an MGC, as defined in [RFC2719].
****** ISDN ****** IP ******* This document supports both ISDN Primary Rate Access (PRA) as well as
*PBX *---------------* SG *--------------* MGC * Basic Rate Access (BRA) including the support for both point-to-point
****** ****** ******* and point-to-multipoint modes of communication. This support
includes Facility Associated Signalling (FAS), Non-Facility
Associated Signalling (NFAS), and NFAS with backup D channel.
+-----+ +-----+ It implements the client/server architecture. The default
|Q.931| (NIF) |Q.931| orientation is for the SG to take on the role of server while the
+-----+ +----------+ +-----+ ISEP is the client. The SCTP (and UDP/TCP) Registered User Port
| | | | IUA| | IUA | Number Assignment for IUA is 9900.
| | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP | | IP |
+-----+ +-----+----+ +-----+
NIF - Nodal Interworking Function Examples of the upper layers to be transported are Q.931 and QSIG.
Draft Telephony Signalling over SCTP AS February 2004 The main scenario supported by this UAL is the SG-to-ISP
communication where the ISEP role is typically played by a node
called an MGC, as defined in [RFC2719].
PBX - Private Branch Exchange ****** ISDN ****** IP *******
SCTP - Stream Control Transmission Protocol *PBX *---------------* SG *--------------* MGC *
IUA - ISDN User Adaptation Layer Protocol ****** ****** *******
The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA +-----+ +-----+
is 9900. |Q.931| (NIF) |Q.931|
+-----+ +----------+ +-----+
| | | | IUA| | IUA |
| | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP | | IP |
+-----+ +-----+----+ +-----+
The value assigned by IANA for the Payload Protocol Identifier in the NIF - Nodal Interworking Function
SCTP Payload Data chunk is "1". PBX - Private Branch Exchange
SCTP - Stream Control Transmission Protocol
IUA - ISDN User Adaptation Layer Protocol
4.1.2 V5UA over IP Figure 5: ISDN-IP Interworking using IUA
UAL: V5UA (V5.2-User Adaptation) The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
is 9900.
V5UA is an extension from the IUA layer with the modifications needed The value assigned by IANA for the Payload Protocol Identifier in the
to support the differences between Q.921 / Q.931, and V5.2 layer 2 / SCTP Payload Data chunk is "1".
layer 3. It supports analog telephone access, ISDN basic rate access
and ISDN primary rate access over a V5.2 interface. It is typically
implemented in an interworking scenario with SG.
****** V5.2 ****** IP ******* 4.1.2. V5UA (V5.2-User Adaptation) Layer
* AN *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+ UAL: V5UA (V5.2-User Adaptation)
|V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+
| | | |V5UA| |V5UA |
| | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
AN - Access Network V5UA is an extension from the IUA layer with the modifications needed
NIF - Nodal Interworking Function to support the differences between Q.921/Q.931, and V5.2 layer
LAPV5 - Link Access Protocol for the V5 channel 2/layer 3. It supports analog telephone access, ISDN basic rate
SCTP - Stream Control Transmission Protocol access and ISDN primary rate access over a V5.2 interface. It is
typically implemented in an interworking scenario with SG.
The SCTP (and UDP/TCP) Registered User Port Number Assignment for ****** V5.2 ****** IP *******
V5UA is 5675. * AN *---------------* SG *--------------* MGC *
****** ****** *******
The value assigned by IANA for the Payload Protocol Identifier in the +-----+ +-----+
|V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+
| | | |V5UA| |V5UA |
| | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
Draft Telephony Signalling over SCTP AS February 2004 AN - Access Network
NIF - Nodal Interworking Function
LAPV5 - Link Access Protocol for the V5 channel
SCTP - Stream Control Transmission Protocol
SCTP Payload Data chunk is "6". Figure 6: V5.2-IP Interworking using V5UA
4.1.3 DPNSS/DASS2 over IP The SCTP (and UDP/TCP) Registered User Port Number Assignment for
V5UA is 5675.
UAL: DUA (DPNSS/DASS2 User Adaptation) The value assigned by IANA for the Payload Protocol Identifier in the
SCTP Payload Data chunk is "6".
The DUA is built on top of IUA and defines the necessary extensions 4.1.3. DUA (DPNSS/DASS User adaptation) Layer
to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private
Network Signalling System and DASS2 for Digital Access Signalling
System No 2.
****** DPNSS ****** IP ******* UAL: DUA (DPNSS/DASS2 User Adaptation)
*PBX *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+ The DUA is built on top of IUA and defines the necessary extensions
|DPNSS| (NIF) |DPNSS| to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private
| L3 | | L3 | Network Signalling System and DASS2 for Digital Access Signalling
+-----+ +-----+----+ +-----+ System 2.
| | | | DUA| | DUA |
|DPNSS| |DPNSS+----+ +-----+
| L2 | | L2 |SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
PBX - Private Branch eXchange ****** DPNSS ****** IP *******
NIF - Nodal Interworking function *PBX *---------------* SG *--------------* MGC *
SCTP - Stream Control Transmission Protocol ****** ****** *******
DUA - DPNSS User Adaptation Layer Protocol
The value assigned by IANA for the Payload Protocol Identifier in the +-----+ +-----+
SCTP Payload Data chunk is "10". |DPNSS| (NIF) |DPNSS|
| L3 | | L3 |
+-----+ +-----+----+ +-----+
| | | | DUA| | DUA |
|DPNSS| |DPNSS+----+ +-----+
| L2 | | L2 |SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
Draft Telephony Signalling over SCTP AS February 2004 PBX - Private Branch eXchange
NIF - Nodal Interworking Function
SCTP - Stream Control Transmission Protocol
DUA - DPNSS User Adaptation Layer Protocol
4.2 Network Signalling Figure 7: DPNSS-IP Interworking using DUA
The SIGTRAN WG have developed UALs to transport the following SS7 The value assigned by IANA for the Payload Protocol Identifier in the
protocols: SCTP Payload Data chunk is "10". .
- MTP2 Users: MTP3 4.2. Network Signalling
- MTP3 Users: ISUP, TUP, SCCP
- SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ...
4.2.1 MTP lvl3 over IP The SIGTRAN WG has developed UALs to transport the following SS7
protocols:
UALs: o MTP2 Users: MTP3
o MTP3 Users: ISUP, TUP, SCCP
o SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ...
- M2UA (SS7 MTP2 User Adaptation) 4.2.1. MTP lvl3 over IP
- M2PA (SS7 MTP2-User Peer-to-Peer Adaptation)
4.2.1.1 M2UA (SS7 MTP2 User Adaptation) UALs:
M2UA protocol is typically used between a Signalling Gateway (SG) o M2UA (SS7 MTP2 User Adaptation [RFC3331])
and Media Gateway Controller (MGC). The SG will terminate up to MTP o M2PA (SS7 MTP2-User Peer-to-Peer Adaptation [RFC4165])
Level 2 and the MGC will terminate MTP Level 3 and above. In other
words, the SG will transport MTP Level 3 messages over an IP network
to a MGC.
MTP3 and MTP3b are the only SS7 MTP2 User protocols that are 4.2.1.1. M2UA (SS7 MTP2-User Adaptation) Layer
transported by this UAL.
The SG provides a interworking of transport functions with the IP M2UA protocol is typically used between a Signalling Gateway (SG) and
transport to transfer MTP2-User signalling messages with an Media Gateway Controller (MGC). The SG will terminate up to MTP
Application Server (e.g. MGC) where the peer MTP2-User exists. Level 2, and the MGC will terminate MTP Level 3 and above. In other
words, the SG will transport MTP Level 3 messages over an IP network
to an MGC.
****** SS7 ****** IP ******* MTP3 and MTP3b are the only SS7 MTP2 User protocols that are
*SEP *-----------* SG *-------------* MGC * transported by this UAL.
****** ****** *******
+----+ +----+ The SG provides an interworking of transport functions with the IP
|S7UP| |S7UP| transport to transfer MTP2-User signalling messages with an
+----+ +----+ Application Server (e.g., MGC) where the peer MTP2-User exists.
|MTP3| |MTP3|
| | (NIF) | |
+----+ +----+----+ +----+
| | | |M2UA| |M2UA|
| | | +----+ +----+
|MTP2| |MTP2|SCTP| |SCTP|
| | | +----+ +----+
| | | |IP | |IP |
+----+ +---------+ +----+
MGC - Media Gateway Controler ****** SS7 ****** IP *******
*SEP *-----------* SG *-------------* MGC *
****** ****** *******
Draft Telephony Signalling over SCTP AS February 2004 +----+ +----+
|S7UP| |S7UP|
+----+ +----+
|MTP3| |MTP3|
| | (NIF) | |
+----+ +----+----+ +----+
| | | |M2UA| |M2UA|
| | | +----+ +----+
|MTP2| |MTP2|SCTP| |SCTP|
| | | +----+ +----+
| | | |IP | |IP |
+----+ +---------+ +----+
SG - Signalling Gateway MGC - Media Gateway Controller
SEP - SS7 Signalling Endpoint SG - Signalling Gateway
NIF - Nodal Interworking Function SEP - SS7 Signalling Endpoint
IP - Internet Protocol NIF - Nodal Interworking Function
SCTP - Stream Control Transmission Protocol IP - Internet Protocol
SCTP - Stream Control Transmission Protocol
The SCTP (and UDP/TCP) Registered User Port Number Assignment for Figure 8: SS7-IP Interworking using M2UA
M2UA is 2904.
The value assigned by IANA for the Payload Protocol Identifier in the The SCTP (and UDP/TCP) Registered User Port Number Assignment for
SCTP Payload Data chunk is "2". M2UA is 2904.
4.2.1.2 M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) Layer The value assigned by IANA for the Payload Protocol Identifier in the
SCTP Payload Data chunk is "2".
M2PA protocol is used between SS7 Signalling Points employing the MTP 4.2.1.2. M2PA (SS7 MTP2-User Peer-to-Peer Adaptation)
Level 3 protocol. The SS7 Signalling Points may also use standard
SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level
3 signalling messages.
Both configurations: communication of SS7 and IP with SG and M2PA protocol is used between SS7 Signalling Points employing the MTP
communication between ISEPs are possible. Level 3 protocol. The SS7 Signalling Points may also use standard
SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level
3 signalling messages.
Communication between two IP nodes: Both configurations: communication of SS7 and IP with SG and
communication between ISEPs are possible.
******** IP ******** Connection of SS7 and IP nodes:
* IPSP *--------* IPSP *
******** ********
+------+ +------+ ******** SS7 *************** IP ********
| TCAP | | TCAP | * SEP *--------* SG *--------* IPSP *
+------+ +------+ ******** *************** ********
| SCCP | | SCCP |
+------+ +------+
| MTP3 | | MTP3 |
+------+ +------+
| M2PA | | M2PA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
IP - Internet Protocol +------+ +------+
IPSP - IP Signalling Point | TCAP | | TCAP |
SCTP - Stream Control Transmission Protocol +------+ +------+
| SCCP | | SCCP |
+------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+
| | | | M2PA | | M2PA |
| | | +------+ +------+
| MTP2 | | MTP2 | SCTP | | SCTP |
| | | +------+ +------+
| | | | IP | | IP |
+------+ +------+------+ +------+
Draft Telephony Signalling over SCTP AS February 2004 SEP - SS7 Signalling Endpoint
Connection of SS7 and IP nodes: Figure 9: SS7-IP Interworking with M2PA
******** SS7 *************** IP ******** Communication between two IP nodes:
* SEP *--------* SG *--------* IPSP *
******** *************** ********
+------+ +------+ ******** IP ********
| TCAP | | TCAP | * IPSP *--------* IPSP *
+------+ +------+ ******** ********
| SCCP | | SCCP |
+------+ +-------------+ +------+
| MTP3 | | MTP3 | | MTP3 |
+------+ +------+------+ +------+
| | | | M2PA | | M2PA |
| | | +------+ +------+
| MTP2 | | MTP2 | SCTP | | SCTP |
| | | +------+ +------+
| | | | IP | | IP |
+------+ +------+------+ +------+
SEP - SS7 Signalling Endpoint +------+ +------+
| TCAP | | TCAP |
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| MTP3 | | MTP3 |
+------+ +------+
| M2PA | | M2PA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
These figures are only an example. Other configurations are possible. IP - Internet Protocol
For example, IPSPs without traditional SS7 links could use the IPSP - IP Signalling Point
protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network SCTP - Stream Control Transmission Protocol
with all IP links.
Another example is that two SGs could be connected over an IP network Figure 10: Intra-IP Communication using M2PA
to form an SG mated pair similar to the way STPs are provisioned in
traditional SS7 networks.
The SCTP (and UDP/TCP) Registered User Port Number Assignment for These figures are only an example. Other configurations are
M2PA is 3565. possible. For example, IPSPs without traditional SS7 links could use
the protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a
network with all IP links.
The value assigned by IANA for the Payload Protocol Identifier in the Another example is that two SGs could be connected over an IP network
SCTP Payload Data chunk is "5". to form an SG mated pair, similar to the way STPs are provisioned in
traditional SS7 networks.
4.2.1.3 Main differences between M2PA and M2UA: The SCTP (and UDP/TCP) Registered User Port Number Assignment for
M2PA is 3565.
a. M2PA: IPSP processes MTP3/MTP2 primitives. The value assigned by IANA for the Payload Protocol Identifier in the
M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2 SCTP Payload Data chunk is "5".
and the MGC's MTP3 (via the NIF) for processing.
b. M2PA: SG-IPSP connection is an SS7 link. 4.2.1.3. Main Differences between M2PA and M2UA
M2UA: SG-MGC connection is not an SS7 link. It is an
extension of MTP to a remote entity.
Draft Telephony Signalling over SCTP AS February 2004 o M2PA: IPSP processes MTP3/MTP2 primitives.
o M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
and the MGC's MTP3 (via the NIF) for processing.
o M2PA: SG-IPSP connection is an SS7 link.
o M2UA: SG-MGC connection is not an SS7 link. It is an extension of
MTP to a remote entity.
4.3 MTP lvl3-Users (ISUP, TUP, SCCP) over IP 4.2.2. M3UA (SS7 MTP3 User Adaptation) Layer
UAL: M3UA (SS7 MTP3 User Adaptation) UAL: M3UA (SS7 MTP3 User Adaptation)
M3UA protocol supports the transport of any SS7 MTP3-User signalling M3UA protocol supports the transport of any SS7 MTP3-User signalling
such as TUP, ISUP and SCCP over IP using the services of SCTP. such as TUP, ISUP, and SCCP over IP using the services of SCTP.
Interconnection of SS7 and IP nodes: Interconnection of SS7 and IP nodes:
******** SS7 ***************** IP ******** ******** SS7 ***************** IP ********
* SEP *---------* SGP *--------* ASP * * SEP *---------* SGP *--------* ASP *
******** ***************** ******** ******** ***************** ********
+------+ +---------------+ +------+ +------+ +---------------+ +------+
| ISUP | | (NIF) | | ISUP | | ISUP | | (NIF) | | ISUP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA | | MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+-+------+ +------+ +------| +------+-+------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP | | MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP | | L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
SEP - SS7 Signalling End Point SEP - SS7 Signalling End Point
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
NIF - Nodal Interworking Function NIF - Nodal Interworking Function
Draft Telephony Signalling over SCTP AS February 2004 Figure 11: SS7-IP Interworking using M3UA
Communication between two IP nodes: Communication between two IP nodes:
******** IP ******** ******** IP ********
* IPSP *----------* IPSP * * IPSP *----------* IPSP *
******** ******** ******** ********
+------+ +------+ +------+ +------+
|SCCP- | |SCCP- | |SCCP- | |SCCP- |
| User | | User | | User | | User |
+------+ +------+ +------+ +------+
| SCCP | | SCCP | | SCCP | | SCCP |
+------+ +------+ +------+ +------+
| M3UA | | M3UA | | M3UA | | M3UA |
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
M3UA uses a client-server architecture. It is recommended that the Figure 12: Intra-IP Communication using M3UA
ISEP acts as the client and initiate the SCTP assocaitions with the
SG. The port reserved by IANA is 2905. This is the port upon which
the SG should listen for possible client connections.
The assigned payload protocol identifier for the SCTP DATA chunks is M3UA uses a client-server architecture. It is recommended that the
"3". ISEP acts as the client and initiate the SCTP associations with the
SG. The port reserved by IANA is 2905. This is the port upon which
the SG should listen for possible client connections.
4.4 SCCP-Users over IP The assigned payload protocol identifier for the SCTP DATA chunks is
"3".
UAL: SUA (SS7 SCCP User Adaptation) 4.2.3. SUA (SS7 SCCP User Adaptation) Layer
SUA protocol supports the transport of any SS7 SCCP-User signalling UAL: SUA (SS7 SCCP User Adaptation)
such as MAP, INAP, SMS, BSSAP, RANAP over IP using the services of
SCTP. Each of the applications using SUA has their own set of
timing requirements that can be found in their respective
standards documents.
Possible configurations are showed in the pictures below. SUA protocol supports the transport of any SS7 SCCP-User signalling
such as MAP, INAP, SMS, BSSAP, or RANAP over IP using the services of
SCTP. Each of the applications using SUA has its own set of timing
requirements that can be found in its respective standards documents.
Draft Telephony Signalling over SCTP AS February 2004 Possible configurations are showed in the pictures below.
- Interconnection of SS7 and IP: - Interconnection of SS7 and IP:
******** *************** ******** ******** *************** ********
* SEP * IP * * IP * * * SEP * SS7 * * IP * *
* or *---------* SG *--------* ASP * * or *---------* SG *--------* ASP *
* STP * * * * * * STP * * * * *
******** *************** ******** ******** *************** ********
+------ +------+ +------ +------+
| SUAP | | SUAP | | SUAP | | SUAP |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA | | SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
| | | | | | | | | | | | | |
| MTP3 | | MTP3 | SCTP | | SCTP | | MTP3 | | MTP3 | SCTP | | SCTP |
| | | | | | | | | | | | | |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
| MTP2 | | MTP2 | IP | | IP | | MTP2 | | MTP2 | IP | | IP |
+------+ +------+------+ +------+ +------+ +------+------+ +------+
SUAP - SCCP/SUA User Protocol (TCAP, for example) SUAP - SCCP/SUA User Protocol (TCAP, for example)
STP - SS7 Signalling Transfer Point STP - SS7 Signalling Transfer Point
- IP Node to IP Node communication: Figure 13: SS7-IP Interworking using SUA
******** ******** - IP Node to IP Node communication:
* * IP * *
* IPSP *--------* IPSP *
* * * *
******** ********
+------+ +------+ ******** ********
| SUAP | | SUAP | * * IP * *
+------+ +------+ * IPSP *--------* IPSP *
| SUA | | SUA | * * * *
+------+ +------+ ******** ********
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
IANA has registered SCTP Port Number 14001 for SUA. It is +------+ +------+
recommended that SGs use this SCTP port number for listening for new | SUAP | | SUAP |
connections. The payload protocol identifier for the SCTP DATA chunks +------+ +------+
is "4". | SUA | | SUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
Draft Telephony Signalling over SCTP AS February 2004 Figure 14: Intra-IP Communication using SUA
5 Security considerations IANA has registered SCTP Port Number 14001 for SUA. It is
recommended that SGs use this SCTP port number for listening for new
connections. The payload protocol identifier for the SCTP DATA
chunks is "4".
UALs are designated to carry signalling messages for telephony 5. Security Considerations
services. As such, UALs must involve the security needs of several
parties: the end users of the services; the network providers and
the applications involved. Additional requirements may come from
local regulation. While having some overlapping security needs, any
security solution should fulfill all of the different parties'
needs. See specific Security considerations in each UAL technical
specification for details.
SCTP only tries to increase the availability of a network. SCTP does UALs are designated to carry signalling messages for telephony
not contain any protocol mechanisms which are directly related to services. As such, UALs must involve the security needs of several
communication security, i.e. user message authentication, integrity parties: the end users of the services, the network providers, and
or confidentiality functions. For such features, it depends on the applications involved. Additional requirements may come from
security protocols. In the field of system security, SCTP includes local regulation. Although some security needs overlap, any security
mechanisms for reducing the risk of blind denial-of-service attacks solution should fulfill all the different parties' needs. See
as it is described in section 11 in RFC2960. specific Security Considerations in each UAL Technical specification
for details (for general security principles of SIGTRAN, see
[RFC3788]).
This document does not add any new components to the protocols SCTP only tries to increase the availability of a network. SCTP does
included in the discussion. For secure use of the SIGTRAN protocols not contain any protocol mechanisms directly related to communication
the readers should go through the "Security Considerations for security, i.e., user message authentication, integrity, or
SIGTRAN protocols" [RFCSIGSEC]). According to that document, the use confidentiality functions. For such features, SCTP depends on
of the IPsec is the main requirement to secure SIGTRAN protocols security protocols. In the field of system security, SCTP includes
in the Internet, but TLS is also considered as a perfectly valid mechanisms for reducing the risk of blind denial-of-service attacks
option to be used in certain scenarios. Recomendations of usage are as described in Section 11 of [RFC2960].
also included.
6 References and related work This document does not add any new components to the protocols
included in the discussion. For secure use of the SIGTRAN protocols,
readers should go through the "Security Considerations for SIGTRAN
Protocols" [RFC3788]). According to that document, the use of the
IPsec is the main requirement to secure SIGTRAN protocols in the
Internet, but Transport Layer Security (TLS) is also considered a
perfectly valid option for use in certain scenarios (see [RFC3436]
for more information on using TLS with SCTP). Recommendations of
usage are also included.
6.1 Informative References 6. Informative References
[RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , [ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End
Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, Network Path Properties", Proc. SIGCOMM'99, 1999.
L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960,
October 2000.
[RF3257] Coene, L., "Stream Control Transmission Protocol [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Applicability statement", RFC3257, April 2002. Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
Draft Telephony Signalling over SCTP AS February 2004 [RFC3257] Coene, L., "Stream Control Transmission Protocol
Applicability Statement", RFC 3257, April 2002.
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp,
Architecture for Signalling Transport", RFC2719, October 1999. "Framework Architecture for Signaling Transport", RFC
2719, October 1999.
[RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G., [RFC3057] Morneault, K., Rengasami, S., Kalla, M., and G.
"ISDN Q.921-User Adaptation Layer", RFC3057, February 2001. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057,
February 2001.
[RFC3331] Morneault, K., Dantu, R., Sidebottom, G., George, T., [RFC3331] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B.,
Bidulock, B., Heitz , J., "Signaling System 7 (SS7) Message Transfer and J. Heitz, "Signaling System 7 (SS7) Message Transfer
Part (MTP) 2 - User Adaptation Layer", RFC3331, September 2002. Part 2 (MTP2) - User Adaptation Layer", RFC 3331,
September 2002.
[RFC3332] Sidebottom, G., Pastor-Balbas, J., Rytina, I., Mousseau, [RFC3332] Sidebottom, G., Morneault, K., and J. Pastor-Balbas,
G., Ong, L., Schwarzbauer, H.J., Gradischnig, K., Morneault, K., "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)
Kalla, M., Glaude, N., Bidulock, B., Loughney, J., "SS7 MTP3-User - User Adaptation Layer (M3UA)", RFC 3332, September
Adaptation Layer (M3UA)", RFC3332, September 2002. 2002.
[RFCzzzz] Loughney, J., Sidebottom, G., Mousseau, G., Lorusso, S., [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Coene, L., Verwimp, G., Keller, J., Escobar, F., Sully, W., Furniss, Layer Security over Stream Control Transmission
S., Bidulock, B.,"SS7 SCCP-User Adaptation Layer (SUA)", RFCzzzz, Protocol", RFC 3436, December 2002.
Sept 2003.
[RFCwwww] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J., [RFC3868] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G.,
Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer Adaptation Keller, J., and B. Bidulock, "Signalling Connection
Layer", RFCwwww, Sept 2003. Control Part User Adaptation Layer (SUA)", RFC 3868,
October 2004.
[RFCqqqq] Weilandt, E., Khanchandani, N., Rao, S.,"V5.2-User [RFC4165] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J.,
Adaptation Layer (V5UA)", RFCqqqq, Sept 2003 Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer
Adaptation Layer", RFC 4165, September 2005.
[RFCtttt] Vydyam, A., Mukundan, R., Mangalpally, N., Morneault, [RFC3807] Weilandt, E., Khanchandani, N., and S. Rao, "V5.2-User
K.,"DPNSS/DASS 2 extensions to the IUA protocol", RFCtttt, Sept Adaptation Layer (V5UA)", RFC 3807, June 2004.
2003.
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End [RFC4129] Mukundan, R., Morneault, K., and N. Mangalpally, "Digital
Network Path Properties", Proc. SIGCOMM'99, 1999. Private Network Signaling System (DPNSS)/Digital Access
Signaling System 2 (DASS 2) Extensions to the IUA
Protocol", RFC 4129, September 2005.
[RFCSIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J.,"Security [RFC3788] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
Considerations for SIGTRAN Protocols", Considerations for Signaling Transport (SIGTRAN)
draft-ietf-sigtran-security-03.txt, work in progress, Sept 2003 Protocols", RFC 3788, June 2004.
7 Acknowledgments Authors' Addresses
This document was initially developed by a design team consisting of Lode Coene
Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, Siemens
Atealaan 34
Herentals B-2200
Belgium
Draft Telephony Signalling over SCTP AS February 2004 Phone: +32-14-252081
EMail: lode.coene@siemens.com
Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas Javier Pastor-Balbas
Jungmaier, Gery Verwimp and Lyndon Ong. Ericsson
Via de los Poblados 13
Madrid 28033
Spain
The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, Phone: +34 91 339 1397
G. Sidebottom, K. Morneault, T. George, M. Stillman, B. Bidulock EMail: J.Javier.Pastor@ericsson.com
and many others for their invaluable comments.
8 Author's Addresses Full Copyright Statement
Lode Coene Phone: +32-14-252081 Copyright (C) The Internet Society (2006).
Siemens Atea EMail: lode.coene@siemens.com
Atealaan 34
B-2200 Herentals
Belgium
Javier Pastor-Balbas Phone: +34-91-3393819 This document is subject to the rights, licenses and restrictions
Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com- contained in BCP 78, and except as set forth therein, the authors
C/ Retama 1 retain all their rights.
28045 Madrid
Spain
Full Copyright Statement This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2003). All Rights Reserved. Intellectual Property
This document and translations of it may be copied and furnished The IETF takes no position regarding the validity or scope of any
to others, and derivative works that comment on or otherwise Intellectual Property Rights or other rights that might be claimed to
explain it or assist in its implementation may be prepared, pertain to the implementation or use of the technology described in
copied, published and distributed, in whole or in part, without this document or the extent to which any license under such rights
restriction of any kind, provided that the above copyright notice might or might not be available; nor does it represent that it has
and this paragraph are included on all such copies and derivative made any independent effort to identify any such rights. Information
works. However, this document itself may not be modified in any on the procedures with respect to rights in RFC documents can be
way, such as by removing the copyright notice or references to the found in BCP 78 and BCP 79.
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not Copies of IPR disclosures made to the IETF Secretariat and any
be revoked by the Internet Society or its successors or assigns. assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
This document and the information contained herein is provided on The IETF invites any interested party to bring to its attention any
Draft Telephony Signalling over SCTP AS February 2004 copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET Acknowledgement
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 217 change blocks. 
791 lines changed or deleted 744 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/