draft-ietf-sigtran-signalling-over-sctp-applic-08.txt   draft-ietf-sigtran-signalling-over-sctp-applic-09.txt 
INTERNET-DRAFT L. Coene(Ed) INTERNET-DRAFT L. Coene(Ed)
Internet Engineering Task Force Siemens Internet Engineering Task Force Siemens
Issued: March 2003 J. Pastor Issued: August 2003 J. Pastor
Expires: September 2003 Ericsson Expires: February 2004 Ericsson
Telephony Signalling Transport over SCTP applicability statement Telephony Signalling Transport over SCTP applicability statement
<draft-ietf-sigtran-signalling-over-sctp-applic-08.txt> <draft-ietf-sigtran-signalling-over-sctp-applic-09.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 1, line 32 skipping to change at page 1, line 32
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1ID-abstracts.txt http://www.ietf.org/ietf/1ID-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the applicability of the new protocols This document describes the applicability of the several protocols
developed under the signalling transport framework[RFC2719]. A developed under the signalling transport framework[RFC2719]. A
description of the main issues regarding the use of the Stream description of the main issues regarding the use of the Stream
Control Transmission Protocol (SCTP)[RFC2960] and each adaptation Control Transmission Protocol (SCTP)[RFC2960] and each adaptation
layer for transport of telephony signalling information over IP layer for transport of telephony signalling information over IP
infrastructure is explained. infrastructure is explained.
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
Table of contents Table of contents
Telephony signalling over SCTP Applicability statement ......... ii Telephony signalling over SCTP Applicability statement ......... ii
Chapter 1: Introduction ........................................ 3 Chapter 1: Introduction ........................................ 3
Chapter 1.1: Scope ..... ....................................... 3 Chapter 1.1: Scope ..... ....................................... 3
Chapter 1.2: Terminology ....................................... 3 Chapter 1.2: Terminology ....................................... 3
Chapter 1.3: Contributors ...................................... 4 Chapter 1.3: Contributors ...................................... 4
Chapter 2: SIGTRAN architecture ................................ 4 Chapter 2: SIGTRAN architecture ................................ 4
Chapter 2.1: Overview ......................................... 4 Chapter 2.1: Overview ......................................... 4
skipping to change at page 2, line 40 skipping to change at page 2, line 40
Chapter 4.1.3: DUA (DPNSS/DASS User adaptation) Layer .......... 13 Chapter 4.1.3: DUA (DPNSS/DASS User adaptation) Layer .......... 13
Chapter 4.2: Network Signalling ................................ 14 Chapter 4.2: Network Signalling ................................ 14
Chapter 4.2.1: MTP lvl3 over IP ................................ 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.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.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.1.3: Main difference between M2PA and M2UA ......... 16
Chapter 4.2.2: M3UA (SS7 MTP3 User Adaptation) Layer ........... 17 Chapter 4.2.2: M3UA (SS7 MTP3 User Adaptation) Layer ........... 17
Chapter 4.2.3: SUA (SS7 SCCP User Adaptation) Layer ............ 18 Chapter 4.2.3: SUA (SS7 SCCP User Adaptation) Layer ............ 18
Chapter 5: Security considerations ............................. 20 Chapter 5: Security considerations ............................. 20
Chapter 6: References and related work ......................... 20 Chapter 6: References and related work ......................... 20
Chapter 6.1: Informative References ............................ 20
Chapter 7: Acknowledgments ..................................... 21 Chapter 7: Acknowledgments ..................................... 21
Chapter 8: Author's address .................................... 22 Chapter 8: Author's address .................................... 22
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
1 INTRODUCTION 1 INTRODUCTION
This document intends to inform how to transport telephony This document is intended to describe how to transport telephony
signalling protocols, used in classic telephony systems, over IP signalling protocols, used in classic telephony systems, over IP
networks. The whole architecture is called SIGTRAN (Signalling networks. The whole architecture is called SIGTRAN (Signalling
Transport) as described in RFC2719 and is composed of a transport Transport) as described in RFC2719 and is composed of a transport
protocol(SCTP) and several User Adaptation layers(UAL). The protocol(SCTP) and several User Adaptation Layers(UAL). The
transport protocol SCTP has been been developed to fulfill the transport protocol SCTP has been developed to fulfill the stringent
stringent requirements that telephony signalling networks have. The requirements that telephony signalling networks have. The set of
set of User Adaptation layers have also been introduced to make it User Adaptation Layers has also been introduced to make it possible
possible that different signalling protocols can use the SCTP layer. for different signalling protocols to use the SCTP layer.
1.1 Scope 1.1 Scope
The scope of this document is to explain the way that user The scope of this document is the Sigtran user adaptation layers and
adaptation layers and SCTP protocols have to be used to transport SCTP protocols and how they are used to transport Telephony
Telephony signalling information over IP. signalling information over IP networks.
1.2 Terminology 1.2 Terminology
The following terms are commonly identified in related work: The following terms are commonly identified in related work:
Association: SCTP connection between two endpoints. Association: SCTP connection between two endpoints.
Stream: A uni-directional logical channel established within an Stream: A uni-directional logical channel established within an
association, within which all user messages are delivered in association, within which all user messages are delivered in
sequence except for those submitted to the unordered delivery sequence except for those submitted to the unordered delivery
skipping to change at page 4, line 5 skipping to change at page 4, line 5
UAL: User adaptation layer: the protocol that encapsulate the upper UAL: User adaptation layer: the protocol that encapsulate the upper
layer telephony signalling protocols that are to be transported over layer telephony signalling protocols that are to be transported over
SCTP/IP. SCTP/IP.
ISEP: IP signalling endpoint: a IP node that implements SCTP and a ISEP: IP signalling endpoint: a IP node that implements SCTP and a
User adapatation layer. User adapatation layer.
SP: signalling point SP: signalling point
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
1.3 Contributors 1.3 Contributors
The following people contributed to the document: L. Coene(Editor), The following people contributed to the document: L. Coene(Editor),
M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie,
M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong. M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong.
2 SIGTRAN architecture 2 SIGTRAN architecture
The SIGTRAN architecture describes the transport of signalling The SIGTRAN architecture describes the transport of signalling
skipping to change at page 4, line 38 skipping to change at page 4, line 38
|Stream Control Transmission Protocol| |Stream Control Transmission Protocol|
| (SCTP) | | (SCTP) |
+------------------------------------+ +------------------------------------+
| |
Internet Protocol (IPv4/IPv6) Internet Protocol (IPv4/IPv6)
Figure 1.1: Telephony signalling transport protocol stack Figure 1.1: Telephony signalling transport protocol stack
The components of the protocol stack are : The components of the protocol stack are :
(1) Adaptation modules are used when the telephony application needs (1) Adaptation modules used when the telephony application needs
to preserve an existing primitive interface. (e.g. management to preserve an existing primitive interface. (e.g. management
indications, data operation primitives, ... for a particular indications, data operation primitives, ... for a particular
user/application protocol). user/application protocol).
(2) SCTP, specially configured to meet the telephony application (2) SCTP, specially configured to meet the telephony application
performance requirements. performance requirements.
(3) The standard Internet Protocol. (3) The standard Internet Protocol.
The telephony signalling protocols to be transported can be: The telephony signalling protocols to be transported can be:
- SS7 MTP3 users: SCCP, ISUP, TUP... - SS7 MTP3 users: SCCP, ISUP, TUP...
- SS7 MTP2 users: MTP3 - SS7 MTP2 users: MTP3
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
- SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... - SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)...
- ISDN Q.921 users: Q.931 - ISDN Q.921 users: Q.931
- V5.2/DSS1 - V5.2/DSS1
- .... - ....
Every classic telephony protocol can have a corresponding UAL
developed.
The user adaptation layers(UALs) are a set of protocols that The user adaptation layers(UALs) are a set of protocols that
encapsulate a specific signalling protocol to be transported over encapsulate a specific signalling protocol to be transported over
SCTP. The adapation is done in a way that the upper signalling SCTP. The adapation is done in a way that the upper signalling
protocols that are relayed remain unaware that the lower layers are protocols that are relayed remain unaware that the lower layers are
different to the originail lower telephony signalling layers. In different to the originail lower telephony signalling layers. In
that sense, the upper interface of the user adapatation layers need that sense, the upper interface of the user adapatation layers need
to be the same as the upper layer interface to its original lower 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 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 related UAL used to transport the MTP user will have the same upper
interface as MTP has. interface as MTP has.
The Stream Control Transmission protocol was designed to fulfill the The Stream Control Transmission Protocol was designed to fulfill the
stringent transport requirements that classical signalling protocols stringent transport requirements that classical signalling protocols
have and is therefore the recommended transport protocol to use for have and is therefore the recommended transport protocol to use for
this purpose. this purpose.
The following functions are provided by SCTP: The following functions are provided by SCTP:
- Reliable Data Transfer - Reliable Data Transfer
- Multiple streams to help avoid head-of-line blocking - Multiple streams to help avoid head-of-line blocking
- Ordered and unordered data delivery on a per-stream basis - Ordered and unordered data delivery on a per-stream basis
- Bundling and fragmentation of user data - Bundling and fragmentation of user data
- Congestion and flow control - Congestion and flow control
- Support continuous monitoring of reachability - Support for continuous monitoring of reachability
- Graceful termination of association - Graceful termination of association
- Support of multi-homing for added reliability - Support of multi-homing for added reliability
- Protection against blind denial-of-service attacks - Protection against blind denial-of-service attacks
- Protection against blind masquerade attacks - Protection against blind masquerade attacks
SCTP is used as the transport protocol for telephony signalling SCTP is used as the transport protocol for telephony signalling
applications. Message boundaries are preserved during data applications. Message boundaries are preserved during data
transport by SCTP and so each UAL can specify its own message transport by SCTP and so each UAL can specify its own message
structure within the SCTP user data. The SCTP user data can be structure within the SCTP user data. The SCTP user data can be
Draft Telephony Signalling over SCTP AS March 2003
delivered by the order of transmission within a stream(in sequence delivered by the order of transmission within a stream(in sequence
delivery) or unordered. delivery) or unordered.
Draft Telephony Signalling over SCTP AS February 2004
SCTP can be used to provide redundancy at the SCTP can be used to provide redundancy at the
transport layer and below. Telephony applications needing this level transport layer and below. Telephony applications needing this level
of redundancy can make use of SCTP's multi-homing support. of redundancy can make use of SCTP's multi-homing support.
SCTP can be used for telephony applications where head-of-line SCTP can be used for telephony applications where head-of-line
blocking is a concern. Such an application should use multiple blocking is a concern. Such an application should use multiple
streams to provide independent ordering of telephony signalling streams to provide independent ordering of telephony signalling
messages. messages.
3 Issues for transporting telephony signalling over SCTP 3 Issues for transporting telephony signalling over SCTP
skipping to change at page 6, line 35 skipping to change at page 6, line 32
3.1 Congestion Control 3.1 Congestion Control
The basic mechanism of congestion control in SCTP have been The basic mechanism of congestion control in SCTP have been
described in [RFC2960]. SCTP congestion control sometimes conflicts described in [RFC2960]. SCTP congestion control sometimes conflicts
with the timing requirements of telephony signalling application with the timing requirements of telephony signalling application
messages which are transported by SCTP. During congestion, messages messages which are transported by SCTP. During congestion, messages
may be delayed by SCTP, thus sometimes violating the timing may be delayed by SCTP, thus sometimes violating the timing
requirements of those telephony applications. requirements of those telephony applications.
In an engineered network (e.g. a private intranet), in which network In an engineered network (e.g. a private intranet), in which network
capacity and maximum traffic are very well understood, some capacity and maximum traffic are very well controlled, some
telephony signalling applications may choose to relax the congestion telephony signalling applications may choose to relax the congestion
control rules of SCTP in order to satisfy the timing control rules of SCTP in order to satisfy the timing
requirements. In order to do this, they should employ their own requirements. In order to do this, they should employ their own
congestion control mechanisms. But this should be done without congestion control mechanisms. But this must be done without
destabilising the network, otherwise this would lead to potential destabilising the network, otherwise this would lead to potential
congestion collapse of the network. congestion collapse of the network.
Some telephony signalling applications may have their own congestion Some telephony signalling applications may have their own congestion
control and flow control techniques. These techniques may interact control and flow control techniques. These techniques may interact
with the congestion control procedures in SCTP. with the congestion control procedures in SCTP.
3.2 Detection of failures 3.2 Detection of failures
Telephony systems often must have no single point of failure in Telephony systems often must have no single point of failure in
operation. operation.
Draft Telephony Signalling over SCTP AS March 2003
The UAL must meet certain service availability and performance The UAL must meet certain service availability and performance
requirements according to the classical signalling layers they are requirements according to the classical signalling layers they are
Draft Telephony Signalling over SCTP AS February 2004
replacing. Those requirements may be specific for each UAL. replacing. Those requirements may be specific for each UAL.
For example, telephony systems are often required to be able to For example, telephony systems are often required to be able to
preserve stable calls during a component failure. Therefore error preserve stable calls during a component failure. Therefore error
situations at the transport layer and below must be detected quickly situations at the transport layer and below must be detected quickly
so that the UAL can take approriate steps to recover and preserve the so that the UAL can take approriate steps to recover and preserve the
calls. This poses special requirements on SCTP to discover calls. This poses special requirements on SCTP to discover
unreachablility of a destination address or a peer. unreachablility of a destination address or a peer.
3.2.1 Retransmission TimeOut (RTO) calculation 3.2.1 Retransmission TimeOut (RTO) calculation
skipping to change at page 8, line 5 skipping to change at page 8, line 5
HB.interval. It should be noted this might result in a higher traffic HB.interval. It should be noted this might result in a higher traffic
load. load.
3.2.3 Maximum number of retransmissions 3.2.3 Maximum number of retransmissions
Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters
to lower values will speed up both destination address and peer to lower values will speed up both destination address and peer
failure detection. However, if these values are set too low, the failure detection. However, if these values are set too low, the
probability of false fault detections might increase. probability of false fault detections might increase.
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
3.3 Shorten end-to-end message delay 3.3 Shorten end-to-end message delay
Telephony applications often require short end-to-end message Telephony applications often require short end-to-end message
delays. The method described in section 3.2.1 on lowering RTO may delays. The method described in section 3.2.1 on lowering RTO may
be considered. The different paths within a single association will be considered. The different paths within a single association will
have a different RTO, so using the path with the lowest RTO 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 lead to a shorter end-to-end message delay for the application
running on top of the UAL's. running on top of the UAL's.
skipping to change at page 9, line 5 skipping to change at page 8, line 47
There are UALs for both access signalling (DSS1) and trunk signalling There are UALs for both access signalling (DSS1) and trunk signalling
(SS7). A brief description of the standardized UALs follows in the (SS7). A brief description of the standardized UALs follows in the
next sub-sections. next sub-sections.
The delivery mechanism in the several UALs The delivery mechanism in the several UALs
- Supports seamless operation of UALs user peers over an IP - Supports seamless operation of UALs user peers over an IP
network connection. network connection.
Draft Telephony Signalling over SCTP AS March 2003
- Supports the interface boundary that the UAL user had with the - Supports the interface boundary that the UAL user had with the
traditional lower layer. traditional lower layer.
Draft Telephony Signalling over SCTP AS February 2004
- Supports management of SCTP transport associations and traffic - Supports management of SCTP transport associations and traffic
between SGs and ISEPs or two ISEPs between SGs and ISEPs or two ISEPs
- Supports asynchronous reporting of status changes to management. - Supports asynchronous reporting of status changes to management.
Signalling User Adaptation Layers have been developed for both: Signalling User Adaptation Layers have been developed for both:
Access and Trunk Telephony Signalling. They are defined as follows. Access and Trunk Telephony Signalling. They are defined as follows.
Access Signalling: This is the signalling that is needed between and Access Signalling: This is the signalling that is needed between and
access device and an exchange in the core network in order to access device and an exchange in the core network in order to
skipping to change at page 10, line 4 skipping to change at page 9, line 52
designed UALS are: designed UALS are:
- ISDN Q.921 Users: Q.931 - ISDN Q.921 Users: Q.931
- V5.2/DSS1 - V5.2/DSS1
- DPNSS/DASS2 - DPNSS/DASS2
- SS7 MTP3 Users: SCCP, ISUP, TUP - SS7 MTP3 Users: SCCP, ISUP, TUP
- SS7 MTP2 Users: MTP3 - SS7 MTP2 Users: MTP3
- SS7 SCCP Users: TCAP, RANAP, BSSAP, ... - SS7 SCCP Users: TCAP, RANAP, BSSAP, ...
Two main scenarios have been developed to use the different UALS for Two main scenarios have been developed to use the different UALS for
Draft Telephony Signalling over SCTP AS March 2003
IP Signalling Transport: IP Signalling Transport:
Draft Telephony Signalling over SCTP AS February 2004
(1) Intercommunication of traditional Signalling transport nodes and (1) Intercommunication of traditional Signalling transport nodes and
IP based nodes. IP based nodes.
Traditional Telephony Traditional Telephony
Telephony Signalling Telephony Signalling
********* Signalling ********** over IP ******** ********* Signalling ********** over IP ********
* SEP *----------------* SG *--------------* ISEP * * SEP *----------------* SG *--------------* ISEP *
********* ********** ******** ********* ********** ********
+-------+ +-------+ +-------+ +-------+
skipping to change at page 11, line 5 skipping to change at page 10, line 56
+-------+ +-------+ +-------+ +-------+
|SigProt| |SigProt| |SigProt| |SigProt|
+-------+ +-------+ +-------+ +-------+
| UAL | | UAL | | UAL | | UAL |
+-------+ +-------+ +-------+ +-------+
| SCTP | | SCTP | | SCTP | | SCTP |
+-------+ +-------+ +-------+ +-------+
| IP | | IP | | IP | | IP |
+-------+ +-------+ +-------+ +-------+
Draft Telephony Signalling over SCTP AS March 2003
This is also referred to as IPSP communication. IPSP stands for IP This is also referred to as IPSP communication. IPSP stands for IP
Draft Telephony Signalling over SCTP AS February 2004
Signalling Point and describes the role that the UAL plays on a Signalling Point and describes the role that the UAL plays on a
IP-based node. IP-based node.
The first scenario is applied for both types of signalling (access The first scenario is applied for both types of signalling (access
and trunk signalling). On the other hand the peer to peer basis can and trunk signalling). On the other hand the peer to peer basis can
only be used for trunk signalling. only be used for trunk signalling.
4.1 Access Signalling 4.1 Access Signalling
The SIGTRAN WG have developed UALs to transport the following Access The SIGTRAN WG have developed UALs to transport the following Access
skipping to change at page 12, line 5 skipping to change at page 11, line 58
+-----+ +-----+ +-----+ +-----+
|Q.931| (NIF) |Q.931| |Q.931| (NIF) |Q.931|
+-----+ +----------+ +-----+ +-----+ +----------+ +-----+
| | | | IUA| | IUA | | | | | IUA| | IUA |
| | | +----+ +-----+ | | | +----+ +-----+
|Q.921| |Q.921|SCTP| |SCTP | |Q.921| |Q.921|SCTP| |SCTP |
| | | +----+ +-----+ | | | +----+ +-----+
| | | | IP | | IP | | | | | IP | | IP |
+-----+ +-----+----+ +-----+ +-----+ +-----+----+ +-----+
Draft Telephony Signalling over SCTP AS March 2003
NIF - Nodal Interworking Function NIF - Nodal Interworking Function
Draft Telephony Signalling over SCTP AS February 2004
PBX - Private Branch Exchange PBX - Private Branch Exchange
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
IUA - ISDN User Adaptation Layer Protocol IUA - ISDN User Adaptation Layer Protocol
The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
is 9900. is 9900.
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
SCTP Payload Data chunk is "1". SCTP Payload Data chunk is "1".
4.1.2 V5UA over IP 4.1.2 V5UA over IP
UAL: V5UA (V5.2-User Adaptation) UAL: V5UA (V5.2-User Adaptation)
It is an extension from the IUA layer with the modifications needed V5UA is an extension from the IUA layer with the modifications needed
to support the differences between Q.921 / Q.931, and V5.2 layer 2 / to support the differences between Q.921 / Q.931, and V5.2 layer 2 /
layer 3. It supports analog telephone access, ISDN basic rate access layer 3. It supports analog telephone access, ISDN basic rate access
and ISDN primary rate access over a V5.2 interface. It is typically and ISDN primary rate access over a V5.2 interface. It is typically
implemented in an interworking scenario with SG. implemented in an interworking scenario with SG.
****** V5.2 ****** IP ******* ****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC * * AN *---------------* SG *--------------* MGC *
****** ****** ******* ****** ****** *******
+-----+ +-----+ +-----+ +-----+
skipping to change at page 13, line 5 skipping to change at page 12, line 49
+-----+ +-----+----+ +-----+ +-----+ +-----+----+ +-----+
AN - Access Network AN - Access Network
NIF - Nodal Interworking Function NIF - Nodal Interworking Function
LAPV5 - Link Access Protocol for the V5 channel LAPV5 - Link Access Protocol for the V5 channel
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
The SCTP (and UDP/TCP) Registered User Port Number Assignment for The SCTP (and UDP/TCP) Registered User Port Number Assignment for
V5UA is 5675. V5UA is 5675.
Draft Telephony Signalling over SCTP AS March 2003
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
Draft Telephony Signalling over SCTP AS February 2004
SCTP Payload Data chunk is "6". SCTP Payload Data chunk is "6".
4.1.3 DPNSS/DASS2 over IP 4.1.3 DPNSS/DASS2 over IP
UAL: DUA (DPNSS/DASS2 User Adaptation) UAL: DUA (DPNSS/DASS2 User Adaptation)
The DUA is built on top of IUA and defines the necessary extensions The DUA is built on top of IUA and defines the necessary extensions
to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private
Network Signalling System and DASS2 for Digital Access Signalling Network Signalling System and DASS2 for Digital Access Signalling
System No 2. System No 2.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
+-----+ +-----+----+ +-----+ +-----+ +-----+----+ +-----+
PBX - Private Branch eXchange PBX - Private Branch eXchange
NIF - Nodal Interworking function NIF - Nodal Interworking function
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
DUA - DPNSS User Adaptation Layer Protocol DUA - DPNSS User Adaptation Layer Protocol
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
SCTP Payload Data chunk is "10". SCTP Payload Data chunk is "10".
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
4.2 Network Signalling 4.2 Network Signalling
The SIGTRAN WG have developed UALs to transport the following SS7 The SIGTRAN WG have developed UALs to transport the following SS7
protocols: protocols:
- MTP2 Users: MTP3 - MTP2 Users: MTP3
- MTP3 Users: ISUP, TUP, SCCP - MTP3 Users: ISUP, TUP, SCCP
- SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ... - SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ...
skipping to change at page 14, line 31 skipping to change at page 14, line 31
- M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) - M2PA (SS7 MTP2-User Peer-to-Peer Adaptation)
4.2.1.1 M2UA (SS7 MTP2 User Adaptation) 4.2.1.1 M2UA (SS7 MTP2 User Adaptation)
M2UA protocol is typically used between a Signalling Gateway (SG) M2UA protocol is typically used between a Signalling Gateway (SG)
and Media Gateway Controller (MGC). The SG will terminate up to MTP and Media Gateway Controller (MGC). The SG will terminate up to MTP
Level 2 and the MGC will terminate MTP Level 3 and above. In other 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 words, the SG will transport MTP Level 3 messages over an IP network
to a MGC. to a MGC.
MTP3 and MTP3b are the the only SS7 MTP2 User protocols that is MTP3 and MTP3b are the only SS7 MTP2 User protocols that are
transported by this UAL. transported by this UAL.
The SG provides a interworking of transport functions with the IP The SG provides a interworking of transport functions with the IP
transport to transfer MTP2-User signalling messages with an transport to transfer MTP2-User signalling messages with an
Application Server (e.g. MGC) where the peer MTP2-User exists. Application Server (e.g. MGC) where the peer MTP2-User exists.
****** SS7 ****** IP ******* ****** SS7 ****** IP *******
*SEP *-----------* SG *-------------* MGC * *SEP *-----------* SG *-------------* MGC *
****** ****** ******* ****** ****** *******
skipping to change at page 15, line 5 skipping to change at page 14, line 55
|MTP3| |MTP3| |MTP3| |MTP3|
| | (NIF) | | | | (NIF) | |
+----+ +----+----+ +----+ +----+ +----+----+ +----+
| | | |M2UA| |M2UA| | | | |M2UA| |M2UA|
| | | +----+ +----+ | | | +----+ +----+
|MTP2| |MTP2|SCTP| |SCTP| |MTP2| |MTP2|SCTP| |SCTP|
| | | +----+ +----+ | | | +----+ +----+
| | | |IP | |IP | | | | |IP | |IP |
+----+ +---------+ +----+ +----+ +---------+ +----+
Draft Telephony Signalling over SCTP AS March 2003
MGC - Media Gateway Controler MGC - Media Gateway Controler
Draft Telephony Signalling over SCTP AS February 2004
SG - Signalling Gateway SG - Signalling Gateway
SEP - SS7 Signalling Endpoint SEP - SS7 Signalling Endpoint
NIF - Nodal Interworking Function NIF - Nodal Interworking Function
IP - Internet Protocol IP - Internet Protocol
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
The SCTP (and UDP/TCP) Registered User Port Number Assignment for The SCTP (and UDP/TCP) Registered User Port Number Assignment for
M2UA is 2904. M2UA is 2904.
The value assigned by IANA for the Payload Protocol Identifier in the The value assigned by IANA for the Payload Protocol Identifier in the
skipping to change at page 16, line 5 skipping to change at page 16, line 5
+------+ +------+ +------+ +------+
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
IP - Internet Protocol IP - Internet Protocol
IPSP - IP Signalling Point IPSP - IP Signalling Point
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
Connection of SS7 and IP nodes: Connection of SS7 and IP nodes:
******** SS7 *************** IP ******** ******** SS7 *************** IP ********
* SEP *--------* SG *--------* IPSP * * SEP *--------* SG *--------* IPSP *
******** *************** ******** ******** *************** ********
+------+ +------+ +------+ +------+
| TCAP | | TCAP | | TCAP | | TCAP |
+------+ +------+ +------+ +------+
skipping to change at page 17, line 5 skipping to change at page 17, line 5
4.2.1.3 Main differences between M2PA and M2UA: 4.2.1.3 Main differences between M2PA and M2UA:
a. M2PA: IPSP processes MTP3/MTP2 primitives. a. M2PA: IPSP processes MTP3/MTP2 primitives.
M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2 M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2
and the MGC's MTP3 (via the NIF) for processing. and the MGC's MTP3 (via the NIF) for processing.
b. M2PA: SG-IPSP connection is an SS7 link. b. M2PA: SG-IPSP connection is an SS7 link.
M2UA: SG-MGC connection is not an SS7 link. It is an M2UA: SG-MGC connection is not an SS7 link. It is an
extension of MTP to a remote entity. extension of MTP to a remote entity.
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
4.3 MTP lvl3-Users (ISUP, TUP, SCCP) over IP 4.3 MTP lvl3-Users (ISUP, TUP, SCCP) over IP
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:
skipping to change at page 18, line 5 skipping to change at page 18, line 5
+------| +------+-+------+ +------+ +------| +------+-+------+ +------+
| 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 March 2003 Draft Telephony Signalling over SCTP AS February 2004
Communication between two IP nodes: Communication between two IP nodes:
******** IP ******** ******** IP ********
* IPSP *----------* IPSP * * IPSP *----------* IPSP *
******** ******** ******** ********
+------+ +------+ +------+ +------+
|SCCP- | |SCCP- | |SCCP- | |SCCP- |
| User | | User | | User | | User |
skipping to change at page 18, line 40 skipping to change at page 18, line 40
The assigned payload protocol identifier for the SCTP DATA chunks is The assigned payload protocol identifier for the SCTP DATA chunks is
"3". "3".
4.4 SCCP-Users over IP 4.4 SCCP-Users over IP
UAL: SUA (SS7 SCCP User Adaptation) UAL: SUA (SS7 SCCP User Adaptation)
SUA protocol supports the transport of any SS7 SCCP-User signalling SUA protocol supports the transport of any SS7 SCCP-User signalling
such as MAP, INAP, SMS, BSSAP, RANAP over IP using the services of such as MAP, INAP, SMS, BSSAP, RANAP over IP using the services of
SCTP. Each of the applications using SUA have their own set of SCTP. Each of the applications using SUA has their own set of
timing requirements that can be found in their respective timing requirements that can be found in their respective
standards documents. standards documents.
Draft Telephony Signalling over SCTP AS March 2003
Possible configurations are showed in the pictures below. Possible configurations are showed in the pictures below.
Draft Telephony Signalling over SCTP AS February 2004
- Interconnection of SS7 and IP: - Interconnection of SS7 and IP:
******** *************** ******** ******** *************** ********
* SEP * IP * * IP * * * SEP * IP * * IP * *
* or *---------* SG *--------* ASP * * or *---------* SG *--------* ASP *
* STP * * * * * * STP * * * * *
******** *************** ******** ******** *************** ********
+------ +------+ +------ +------+
| SUAP | | SUAP | | SUAP | | SUAP |
skipping to change at page 20, line 5 skipping to change at page 20, line 5
| SCTP | | SCTP | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| IP | | IP | | IP | | IP |
+------+ +------+ +------+ +------+
IANA has registered SCTP Port Number 14001 for SUA. It is IANA has registered SCTP Port Number 14001 for SUA. It is
recommended that SGs use this SCTP port number for listening for new recommended that SGs use this SCTP port number for listening for new
connections. The payload protocol identifier for the SCTP DATA chunks connections. The payload protocol identifier for the SCTP DATA chunks
is "4". is "4".
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
5 Security considerations 5 Security considerations
UALs are designated to carry signalling messages for telephony UALs are designated to carry signalling messages for telephony
services. As such, UALs must involve the security needs of several services. As such, UALs must involve the security needs of several
parties: the end users of the services; the network providers and parties: the end users of the services; the network providers and
the applications involved. Additional requirements may come from the applications involved. Additional requirements may come from
local regulation. While having some overlapping security needs, any local regulation. While having some overlapping security needs, any
security solution should fulfill all of the different parties' security solution should fulfill all of the different parties'
needs. See specific Security considerations in each UAL technical needs. See specific Security considerations in each UAL technical
specification. specification for details.
SCTP only tries to increase the availability of a network. SCTP does SCTP only tries to increase the availability of a network. SCTP does
not contain any protocol mechanisms which are directly related to not contain any protocol mechanisms which are directly related to
communication security, i.e. user message authentication, integrity communication security, i.e. user message authentication, integrity
or confidentiality functions. For such features, it depends on or confidentiality functions. For such features, it depends on
security protocols. In the field of system security, SCTP includes security protocols. In the field of system security, SCTP includes
mechanisms for reducing the risk of blind denial-of-service attacks mechanisms for reducing the risk of blind denial-of-service attacks
as it is described in section 11 in RFC2960. as it is described in section 11 in RFC2960.
This document does not add any new components to the protocols This document does not add any new components to the protocols
included in the discussion. For secure use of the SIGTRAN protocols included in the discussion. For secure use of the SIGTRAN protocols
the readers should go through the "Security Considerations for the readers should go through the "Security Considerations for
SIGTRAN protocols" [RFCSIGSEC]). According to that document, the use SIGTRAN protocols" [RFCSIGSEC]). According to that document, the use
of the IPsec is the main recommendation to secure SIGTRAN protocols of the IPsec is the main requirement to secure SIGTRAN protocols
in the Internet, but TLS is also considered as a perfectly valid in the Internet, but TLS is also considered as a perfectly valid
option to be used in certain scenarios. Recomendations of usage are option to be used in certain scenarios. Recomendations of usage are
also included. also included.
6 References and related work 6 References and related work
6.1 Informative References
[RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , ,
Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang,
L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960, L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960,
October 2000. October 2000.
[RF3257] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, [RF3257] Coene, L., "Stream Control Transmission Protocol
R. R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., Applicability statement", RFC3257, April 2002.
"Stream Control Transmission Protocol Applicability statement",
RFC3257, April 2002.
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
[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., Sharp, C., "Framework
Architecture for Signalling Transport", RFC2719, October 1999. Architecture for Signalling Transport", RFC2719, October 1999.
[RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G., [RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G.,
"ISDN Q.921-User Adaptation Layer", RFC3057, February 2001. "ISDN Q.921-User Adaptation Layer", RFC3057, February 2001.
[RFC3331] Morneault, K., Dantu, R., Sidebottom, G., George, T., [RFC3331] Morneault, K., Dantu, R., Sidebottom, G., George, T.,
Bidulock, B., Heitz , J., "Signaling System 7 (SS7) Message Transfer Bidulock, B., Heitz , J., "Signaling System 7 (SS7) Message Transfer
Part (MTP) 2 - User Adaptation Layer", RFC3331, September 2002. Part (MTP) 2 - User Adaptation Layer", RFC3331, September 2002.
[RFC3332] Sidebottom, G., Pastor-Balbas, J., Rytina, I., Mousseau, [RFC3332] Sidebottom, G., Pastor-Balbas, J., Rytina, I., Mousseau,
G., Ong, L., Schwarzbauer, H.J., Gradischnig, K., Morneault, K., G., Ong, L., Schwarzbauer, H.J., Gradischnig, K., Morneault, K.,
Kalla, M., Glaude, N., Bidulock, B., Loughney, J., "SS7 MTP3-User Kalla, M., Glaude, N., Bidulock, B., Loughney, J., "SS7 MTP3-User
Adaptation Layer (M3UA)", RFC3332, September 2002. Adaptation Layer (M3UA)", RFC3332, September 2002.
[RFCzzzz] Loughney, J., Sidebottom, G., Mousseau, G., Lorusso, S., [RFCzzzz] Loughney, J., Sidebottom, G., Mousseau, G., Lorusso, S.,
Coene, L., Verwimp, G., Keller, J., Escobar, F., Sully, W., Furniss, Coene, L., Verwimp, G., Keller, J., Escobar, F., Sully, W., Furniss,
S., Bidulock, B.,"SS7 SCCP-User Adaptation Layer (SUA)", RFCzzzz, S., Bidulock, B.,"SS7 SCCP-User Adaptation Layer (SUA)", RFCzzzz,
May 2002. Sept 2003.
[RFCwwww] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J., [RFCwwww] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J.,
Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer Adaptation Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer Adaptation
Layer", RFCwwww, June 2002. Layer", RFCwwww, Sept 2003.
[RFCqqqq] Weilandt, E., Khanchandani, N., Rao, S.,"V5.2-User [RFCqqqq] Weilandt, E., Khanchandani, N., Rao, S.,"V5.2-User
Adaptation Layer (V5UA)", RFCqqqq, June 2002 Adaptation Layer (V5UA)", RFCqqqq, Sept 2003
[RFCtttt] Vydyam, A., Mukundan, R., Mangalpally, N., Morneault, [RFCtttt] Vydyam, A., Mukundan, R., Mangalpally, N., Morneault,
K.,"DPNSS/DASS 2 extensions to the IUA protocol", RFCtttt, August K.,"DPNSS/DASS 2 extensions to the IUA protocol", RFCtttt, Sept
2002. 2003.
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999. Network Path Properties", Proc. SIGCOMM'99, 1999.
[RFCSIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J.,"Security [RFCSIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J.,"Security
Considerations for SIGTRAN Protocols", Considerations for SIGTRAN Protocols",
draft-ietf-sigtran-security-00.txt, work in progress draft-ietf-sigtran-security-03.txt, work in progress, Sept 2003
7 Acknowledgments 7 Acknowledgments
This document was initially developed by a design team consisting of This document was initially developed by a design team consisting of
Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart,
Draft Telephony Signalling over SCTP AS March 2003 Draft Telephony Signalling over SCTP AS February 2004
Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart,
Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas
Jungmaier, Gery Verwimp and Lyndon Ong. Jungmaier, Gery Verwimp and Lyndon Ong.
The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor,
G. Sidebottom, K. Morneault, T. George, M. Stillman, B. Bidulock G. Sidebottom, K. Morneault, T. George, M. Stillman, B. Bidulock
and many others for their invaluable comments. and many others for their invaluable comments.
8 Author's Address 8 Author's Addresses
Lode Coene Phone: +32-14-252081 Lode Coene Phone: +32-14-252081
Siemens Atea EMail: lode.coene@siemens.com Siemens Atea EMail: lode.coene@siemens.com
Atealaan 34 Atealaan 34
B-2200 Herentals B-2200 Herentals
Belgium Belgium
Javier Pastor-Balbas Phone: +34-91-3393819 Javier Pastor-Balbas Phone: +34-91-3393819
Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com- Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com-
C/ Retama 1 C/ Retama 1
skipping to change at page 23, line 5 skipping to change at page 22, line 49
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns. be revoked by the Internet Society or its successors or assigns.
Draft Telephony Signalling over SCTP AS March 2003
This document and the information contained herein is provided on This document and the information contained herein is provided on
Draft Telephony Signalling over SCTP AS February 2004
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- -
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/