draft-ietf-sigtran-framework-arch-03.txt   rfc2719.txt 
Internet Engineering Task Force
INTERNET-DRAFT Authors
Transport Working Group Lyndon Ong, Nortel Networks
Category: Informational Ian Rytina, Miguel Garcia, Ericsson
June 1999 HannsJuergen Schwarzbauer, Lode Coene, Siemens
Expires: January 2000 Huai-an Paul Lin, Telcordia
Imre Juhasz, Telia
Matt Holdrege, Ascend
Chip Sharp, Cisco Systems
Framework Architecture for Signaling Transport Network Working Group L. Ong
< draft-ietf-sigtran-framework-arch-03.txt > Request for Comments: 2719 Nortel Networks
Category: Informational I. Rytina
M. Garcia
Ericsson
H. Schwarzbauer
L. Coene
Siemens
H. Lin
Telcordia
I. Juhasz
Telia
M. Holdrege
Lucent
C. Sharp
Cisco Systems
October 1999
Framework Architecture for Signaling Transport
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This memo provides information for the Internet community. It does
with all provisions of Section 10 of RFC2026. Internet-Drafts are not specify an Internet standard of any kind. Distribution of this
working documents of the Internet Engineering Task Force (IETF), its memo is unlimited.
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
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 (1999). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines an architecture framework and functional This document defines an architecture framework and functional
requirements for transport of signaling information over IP. The requirements for transport of signaling information over IP. The
framework describes relationships between functional and physical framework describes relationships between functional and physical
entities exchanging signaling information, such as Signaling Gateways entities exchanging signaling information, such as Signaling Gateways
and Media Gateway Controllers. It identifies interfaces where and Media Gateway Controllers. It identifies interfaces where
signaling transport may be used and the functional and performance signaling transport may be used and the functional and performance
requirements that apply from existing Switched Circuit Network (SCN) requirements that apply from existing Switched Circuit Network (SCN)
signaling protocols. signaling protocols.
Table of Contents Table of Contents
1. Introduction..............................................2 1. Introduction..................................................2
1.1 Overview.................................................2 1.1 Overview.....................................................2
1.2 Terminology..............................................2 1.2 Terminology..................................................3
1.3 Scope...................................................4 1.3 Scope.......................................................5
2. Signaling Transport Architecture.........................5 2. Signaling Transport Architecture.............................5
2.1 Gateway Component Functions.............................5 2.1 Gateway Component Functions.................................5
2.2 SS7 Interworking for Connection Control.................6 2.2 SS7 Interworking for Connection Control.....................6
2.3 ISDN Interworking for Connection Control................8 2.3 ISDN Interworking for Connection Control....................8
2.4 Architecture for Database Access........................9 2.4 Architecture for Database Access............................9
3. Protocol Architecture....................................10 3. Protocol Architecture........................................10
3.1. Signaling Transport Components.........................10 3.1 Signaling Transport Components..............................10
3.2. SS7 access for Media Gateway Control...................11 3.2 SS7 access for Media Gateway Control........................11
3.3. Q.931 Access to MGC....................................12 3.3 Q.931 Access to MGC.........................................12
3.4. SS7 Access to IP/SCP...................................12 3.4 SS7 Access to IP/SCP........................................12
3.5. SG to SG...............................................13 3.5 SG to SG....................................................14
4. Functional Requirements..................................15 4. Functional Requirements......................................15
5. Management...............................................18 4.1 Transport of SCN Signaling Protocols........................15
6. Security.................................................18 4.2 Performance of SCN Signaling Protocols......................17
7. Abbreviations............................................20 4.2.1 SS7 MTP Requirements......................................17
8. Acknowledgements.........................................20 4.2.2 SS7 MTP Level 3 Requirements..............................17
9. References...............................................20 4.2.3 SS7 User Part Requirements................................18
Authors' Contact Information................................21 4.2.4 ISDN Signaling Requirements...............................18
5. Management...................................................19
6. Security Considerations......................................19
6.1 Security Requirements.......................................19
6.2 Security Mechanisms Currently Available in IP Networks......20
7. Abbreviations................................................21
8. Acknowledgements.............................................21
9. References...................................................21
Authors' Addresses..............................................22
Full Copyright Statement........................................24
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
This document defines an architecture framework for transport of This document defines an architecture framework for transport of
message-based signaling protocols over IP networks. The scope of message-based signaling protocols over IP networks. The scope of
this work includes definition of encapsulation methods, end-to-end this work includes definition of encapsulation methods, end-to-end
protocol mechanisms and use of existing IP capabilities to support protocol mechanisms and use of existing IP capabilities to support
the functional and performance requirements for signaling transport. the functional and performance requirements for signaling transport.
The framework portion describes the relationships between functional The framework portion describes the relationships between functional
and physical entities used in signaling transport, including the and physical entities used in signaling transport, including the
framework for control of Media Gateways, and other scenarios where framework for control of Media Gateways, and other scenarios where
signaling transport may be required. signaling transport may be required.
The requirements portion describes functional and performance The requirements portion describes functional and performance
requirements for signaling transport such as flow control, in-sequence requirements for signaling transport such as flow control, in-
delivery and other functions that may be required for specific SCN sequence delivery and other functions that may be required for
signaling protocols. specific SCN signaling protocols.
1.2 Terminology 1.2 Terminology
The following are general terms are used in this document: The following are general terms are used in this document:
Backhaul: Backhaul:
Backhaul refers to the transport of signaling from the point of interface for Backhaul refers to the transport of signaling from the point of
the associated data stream (i.e., SG function in the MGU) back to the interface for the associated data stream (i.e., SG function in the
point of call processing (i.e., the MGCU), if this is not local. MGU) back to the point of call processing (i.e., the MGCU), if this
is not local.
Signaling Transport (SIG): Signaling Transport (SIG):
SIG refers to a protocol stack for transport of SCN signaling protocols SIG refers to a protocol stack for transport of SCN signaling
over an IP network. It will support standard primitives to interface protocols over an IP network. It will support standard primitives to
with an unmodified SCN signaling application being transported, and interface with an unmodified SCN signaling application being
supplements a standard IP transport protocol underneath with functions transported, and supplements a standard IP transport protocol
designed to meet transport requirements for SCN signaling. underneath with functions designed to meet transport requirements for
SCN signaling.
Switched Circuit Network (SCN): Switched Circuit Network (SCN):
The term SCN is used to refer to a network that carries traffic within The term SCN is used to refer to a network that carries traffic
channelized bearers of pre-defined sizes. Examples include Public within channelized bearers of pre-defined sizes. Examples include
Switched Telephone Networks (PSTNs) and Public Land Mobile Networks Public Switched Telephone Networks (PSTNs) and Public Land Mobile
(PLMNs). Examples of signaling protocols used in SCN include Q.931, Networks (PLMNs). Examples of signaling protocols used in SCN
SS7 MTP Level 3 and SS7 Application/User parts. include Q.931, SS7 MTP Level 3 and SS7 Application/User parts.
The following are terms for functional entities relating to signaling The following are terms for functional entities relating to signaling
transport in a distributed gateway model. transport in a distributed gateway model.
Media Gateway (MG): Media Gateway (MG):
A MG terminates SCN media streams, packetizes the media data,, if it A MG terminates SCN media streams, packetizes the media data,, if it
is not already packetized, and delivers packetized traffic to the is not already packetized, and delivers packetized traffic to the
packet network. It performs these functions in reverse order for media packet network. It performs these functions in reverse order for
streams flowing from the packet network to the SCN. media streams flowing from the packet network to the SCN.
Media Gateway Controller (MGC): Media Gateway Controller (MGC):
An MGC handles the registration and management of resources at the MG. An MGC handles the registration and management of resources at the
The MGC may have the ability to authorize resource usage based on local MG. The MGC may have the ability to authorize resource usage based on
policy. For signaling transport purposes, the MGC serves as a possible local policy. For signaling transport purposes, the MGC serves as a
termination and origination point for SCN application protocols, such possible termination and origination point for SCN application
as SS7 ISDN User Part and Q.931/DSS1. protocols, such as SS7 ISDN User Part and Q.931/DSS1.
Signaling Gateway (SG): Signaling Gateway (SG):
An SG is a signaling agent that receives/sends SCN native signaling at An SG is a signaling agent that receives/sends SCN native signaling
the edge of the IP network. The SG function may relay, translate or at the edge of the IP network. The SG function may relay, translate
terminate SS7 signaling in an SS7-Internet Gateway. The SG function may or terminate SS7 signaling in an SS7-Internet Gateway. The SG
also be co-resident with the MG function to process SCN signaling associated function may also be co-resident with the MG function to process SCN
with line or trunk terminations controlled by the MG (e.g., signaling backhaul). signaling associated with line or trunk terminations controlled by
the MG (e.g., signaling backhaul).
The following are terms for physical entities relating to signaling The following are terms for physical entities relating to signaling
transport in a distributed gateway model: transport in a distributed gateway model:
Media Gateway Unit (MGU) Media Gateway Unit (MGU)
An MG-Unit is a physical entity that contains the MG function. It may An MG-Unit is a physical entity that contains the MG function. It
contain other functions, esp. an SG function for handling facility- may contain other functions, esp. an SG function for handling
associated signaling. facility-associated signaling.
Media Gateway Control Unit (MGCU) Media Gateway Control Unit (MGCU)
An MGC-Unit is a physical entity containing the MGC function. An MGC-Unit is a physical entity containing the MGC function.
Signaling Gateway Unit (SGU) Signaling Gateway Unit (SGU)
An SG-Unit is a physical entity containing the SG function. An SG-Unit is a physical entity containing the SG function.
Signaling End Point (SEP): Signaling End Point (SEP):
This is a node in an SS7 network that originates or terminates signaling This is a node in an SS7 network that originates or terminates
messages. One example is a central office switch. signaling messages. One example is a central office switch.
Signal Transfer Point (STP): Signal Transfer Point (STP):
This is a node in an SS7 network that routes signaling messages based on This is a node in an SS7 network that routes signaling messages based
their destination point code in the SS7 network on their destination point code in the SS7 network.
1.3 Scope 1.3 Scope
Signaling transport provides transparent transport of message-based Signaling transport provides transparent transport of message-based
signaling protocols over IP networks. The scope of this work includes signaling protocols over IP networks. The scope of this work
definition of encapsulation methods, end-to-end protocol mechanisms and includes definition of encapsulation methods, end-to-end protocol
use of IP capabilities to support the functional and performance mechanisms and use of IP capabilities to support the functional and
requirements for signaling. performance requirements for signaling.
Signaling transport shall be used for transporting SCN signaling Signaling transport shall be used for transporting SCN signaling
between a Signaling Gateway Unit and Media Gateway Controller Unit. between a Signaling Gateway Unit and Media Gateway Controller Unit.
Signaling transport may also be used for transport of message-based Signaling transport may also be used for transport of message-based
signaling between a Media Gateway Unit and Media Gateway Controller signaling between a Media Gateway Unit and Media Gateway Controller
Unit, between dispersed Media Gateway Controller Units, and between two Unit, between dispersed Media Gateway Controller Units, and between
Signaling Gateway Units connecting signaling endpoints or signal two Signaling Gateway Units connecting signaling endpoints or signal
transfer points in the SCN. transfer points in the SCN.
Signaling transport will be defined in such a way as to support Signaling transport will be defined in such a way as to support
encapsulation and carriage of a variety of SCN protocols. It encapsulation and carriage of a variety of SCN protocols. It is
is defined in such a way as to be independent of any SCN protocol defined in such a way as to be independent of any SCN protocol
translation functions taking place at the endpoints of the signaling translation functions taking place at the endpoints of the signaling
transport, since its function is limited to the transport of transport, since its function is limited to the transport of the SCN
the SCN protocol. protocol.
Since the function being provided is transparent transport, the following Since the function being provided is transparent transport, the
areas are considered outside the scope of the signaling transport work: following areas are considered outside the scope of the signaling
transport work:
- definition of the SCN protocols themselves - definition of the SCN protocols themselves.
- signaling interworking such as conversion from Channel Associated - signaling interworking such as conversion from Channel Associated
Signaling (CAS) to message signaling protocols Signaling (CAS) to message signaling protocols.
- specification of the functions taking place within the SGU or MGU - specification of the functions taking place within the SGU or MGU
- in particular, this work does not address whether the SGU provides - in particular, this work does not address whether the SGU provides
mediation/interworking, as this is transparent to the transport mediation/interworking, as this is transparent to the transport
function. function.
- similarly, some management and addressing functions taking place - similarly, some management and addressing functions taking place
within the SGU or MGU are also considered out of scope, within the SGU or MGU are also considered out of scope, such as
such as determination of the destination IP address for signaling, determination of the destination IP address for signaling, or
or specific procedures for assessing the performance of the transport specific procedures for assessing the performance of the transport
session (i.e., testing and proving functions). session (i.e., testing and proving functions).
2. Signaling Transport Architecture 2. Signaling Transport Architecture
2.1 Gateway Component Functions 2.1 Gateway Component Functions
Figure 1 defines a commonly defined functional model Figure 1 defines a commonly defined functional model that separates
that separates out the functions of SG, MGC and MG. This model may be out the functions of SG, MGC and MG. This model may be implemented
implemented in a number of ways, with functions implemented in separate in a number of ways, with functions implemented in separate devices
devices or combined in single physical units. or combined in single physical units.
Where physical separation exists between functional entities, Signaling Where physical separation exists between functional entities,
Transport can be applied to ensure that SCN signaling information is Signaling Transport can be applied to ensure that SCN signaling
transported between entities with the required functionality and information is transported between entities with the required
performance. functionality and performance.
+---------------+ +--------------+ +---------------+ +--------------+
| | | | | | | |
SCN<-------->[SG] <--+---------O------------+--> [SG] <------> SCN SCN<-------->[SG] <--+---------O------------+--> [SG] <------> SCN
signal | | | | | | signal signal | | | | | | signal
+-------|-------+ +-----|--------+ +-------|-------+ +-----|--------+
Signaling|gateway Signaling|gateway (opt) Signaling|gateway Signaling|gateway (opt)
O O O O
| | | |
+-------|-------+ +-----|--------+ +-------|-------+ +-----|--------+
| | | | | | | | | | | |
| [MGC] <--+--------O-------------+--> [MGC] | | [MGC] <--+--------O-------------+--> [MGC] |
| | | | | | | | | | | |
| | | | | | | | | | | |
+-------|-------+ +-----|--------+ +-------|-------+ +-----|--------+
Gateway | controller Gateway | controller (opt) Gateway | controller Gateway | controller (opt)
O O O O
| | | |
+-------|-------+ +-----|--------+ +-------|-------+ +-----|--------+
Media | | | | | | Media Media | | | | | | Media
<------+---->[MG] <---+-----RTP stream-------+-> [MG] <----+--------> <------+---->[MG] <---+-----RTP stream-------+-> [MG] <----+-------->
stream| | | | stream stream| | | | stream
+---------------+ +--------------+ +---------------+ +--------------+
Media gateway Media gateway Media gateway Media gateway
Figure 1: Sigtran Functional Model Figure 1: Sigtran Functional Model
As discussed above, the interfaces pertaining to signaling transport As discussed above, the interfaces pertaining to signaling transport
include SG to MGC, SG to SG. Signaling transport may potentially be include SG to MGC, SG to SG. Signaling transport may potentially be
applied to the MGC to MGC or MG to MGC interfaces as well, depending applied to the MGC to MGC or MG to MGC interfaces as well, depending
on requirements for transport of the associated signaling protocol. on requirements for transport of the associated signaling protocol.
2.2 SS7 Interworking for Connection Control 2.2 SS7 Interworking for Connection Control
Figure 2 below shows some example implementations of these functions in Figure 2 below shows some example implementations of these functions
physical entities as used for interworking of SS7 and IP networks for in physical entities as used for interworking of SS7 and IP networks
Voice over IP, Voice over ATM, Network Access Servers, etc. No for Voice over IP, Voice over ATM, Network Access Servers, etc. No
recommendation is made as to functional distribution and many other recommendation is made as to functional distribution and many other
examples are possible but are not shown to be concise. The use of examples are possible but are not shown to be concise. The use of
signaling transport is independent of the implementation. signaling transport is independent of the implementation.
For interworking with SS7-controlled SCN networks, the SG terminates the For interworking with SS7-controlled SCN networks, the SG terminates
SS7 link and transfers the signaling information to the MGC using the SS7 link and transfers the signaling information to the MGC using
signaling transport. The MG terminates the interswitch trunk and signaling transport. The MG terminates the interswitch trunk and
controls the trunk based on the control signaling it receives from the controls the trunk based on the control signaling it receives from
MGC. As shown below in case (a), the SG, MGC and MG the MGC. As shown below in case (a), the SG, MGC and MG may be
may be implemented in separate physical units, or as in case (b), the implemented in separate physical units, or as in case (b), the MGC
MGC and MG may be implemented in a single physical unit. and MG may be implemented in a single physical unit.
In alternative case (c), a facility-associated SS7 link is terminated In alternative case (c), a facility-associated SS7 link is terminated
by the same device (i.e., the MGU) that terminates the interswitch trunk. by the same device (i.e., the MGU) that terminates the interswitch
In this case, the SG function is co-located with the MG function, as shown trunk. In this case, the SG function is co-located with the MG
below, and signaling transport is used to "backhaul" control signaling to function, as shown below, and signaling transport is used to
the MGCU. "backhaul" control signaling to the MGCU.
Note: SS7 links may also be terminated directly on the MGCU by Note: SS7 links may also be terminated directly on the MGCU by
cross-connecting at the physical level before or at the MGU. cross-connecting at the physical level before or at the MGU.
SGU SGU
+--------+ +--------+
SS7<------>[SG] | SS7<------>[SG] |
(ISUP) | | | (ISUP) | | |
+---|----+ +---|----+
ST | SGU MGCU ST | SGU MGCU
+---|----+ +--------+ +--------+ +---|----+ +--------+ +--------+
| [MGC] | SS7---->[SG] | | [MGC] | | [MGC] | SS7---->[SG] | | [MGC] |
| | | | | | | | | | | | | | | | | | | |
+---|----+ +---|----+ +--|-|---+ +---|----+ +---|----+ +--|-|---+
MGCU | ST | | | MGCU | ST | | |
| | ST | | | | ST | |
Media +---|----+ Media +---|----+ +--|-|---+ Media +---|----+ Media +---|----+ +--|-|---+
------->[MG] | ----->[MG/MGC]| SS7 link-->[SG]| | ------->[MG] | ----->[MG/MGC]| SS7 link-->[SG]| |
stream | | stream | | Media------> [MG] | stream | | stream | | Media------> [MG] |
+--------+ +--------+ stream +--------+ +--------+ +--------+ stream +--------+
MGU MGU MGU MGU MGU MGU
(a) (b) (c) (a) (b) (c)
Notes: ST = Signaling Transport used to carry SCN signaling
Figure 2: Example Implementations Notes: ST = Signaling Transport used to carry SCN signaling
In some implementations, the function of the SG may be divided into Figure 2: Example Implementations
multiple physical entities to support scaling, signaling network
management and addressing concerns. Thus, Signaling Transport can be In some implementations, the function of the SG may be divided into
used between SGs as well as from SG to MGC. This is shown in Figure 3 multiple physical entities to support scaling, signaling network
below. management and addressing concerns. Thus, Signaling Transport can be
used between SGs as well as from SG to MGC. This is shown in Figure 3
below.
SGU MGCU SGU MGCU
+---------+ +---------+ +---------+ +---------+
| | ST | | | | ST | |
| [SG2]------------------------------>[MGC] | | [SG2]------------------------------>[MGC] |
| ^ ^ | | | | ^ ^ | | |
+---|-|---+ +---------+ +---|-|---+ +---------+
| | | |
| | ST | | ST
ST| +--------------------------------+ ST| +--------------------------------+
| | | |
| | | |
SS7 +---|----------+ SS7 +----|---------+ SS7 +---|----------+ SS7 +----|---------+
-----------> [SG1] | -----------> [SG1] | -----------> [SG1] | -----------> [SG1] |
media | | media | | media | | media | |
------------------->[MG] | ------------------->[MG] | ------------------->[MG] | ------------------->[MG] |
stream +--------------+ stream +--------------+ stream +--------------+ stream +--------------+
MGU MGU MGU MGU
Figure 3: Multiple SG Case Figure 3: Multiple SG Case
In this configuration, there may be more than one MGU handling In this configuration, there may be more than one MGU handling
facility associated signaling (i.e. more than one containing it's facility associated signaling (i.e. more than one containing it's own
own SG function), and only a single SGU. It will therefore be SG function), and only a single SGU. It will therefore be possible to
possible to transport one SS7 layer between SG1 and SG2, and transport one SS7 layer between SG1 and SG2, and another SS7 layer
another SS7 layer between SG2 and MGC. For example, SG1 could between SG2 and MGC. For example, SG1 could transport MTP3 to SG2,
transport MTP3 to SG2, and SG2 could transport ISUP to MGC. and SG2 could transport ISUP to MGC.
2.3 ISDN Interworking for Connection Control 2.3 ISDN Interworking for Connection Control
In ISDN access signaling, the signaling channel is carried along with In ISDN access signaling, the signaling channel is carried along with
data channels, so that the SG function for handling Q.931 signaling data channels, so that the SG function for handling Q.931 signaling
is co-located with the MG function for handling the data stream. Where is co-located with the MG function for handling the data stream.
Q.931 is then transported to the MGC for call processing, signaling Where Q.931 is then transported to the MGC for call processing,
transport would be used between the SG function and MGC. This is shown signaling transport would be used between the SG function and MGC.
in Figure 3 below. This is shown in Figure 3 below.
MGCU MGCU
+-------------+ +-------------+
| [MGC] | | [MGC] |
| | | | | | | |
+-----|-|-----+ +-----|-|-----+
| | | |
| O device control | O device control
| | | |
Q.931/ST O | Q.931/ST O |
| | | |
+-----|-|-----+ +-----|-|-----+
| | | | | | | |
Q.931---->[SG]| | Q.931---->[SG]| |
signals| | | signals| | |
| | | | | |
Media---->[MG] | Media---->[MG] |
stream | | stream | |
+-------------+ +-------------+
MGU MGU
Figure 4: Q.931 transport model Figure 4: Q.931 transport model
2.4 Architecture for Database Access 2.4 Architecture for Database Access
Transaction Capabilities (TCAP) is the application part within SS7 Transaction Capabilities (TCAP) is the application part within SS7
that is used for non-circuit-related signaling. that is used for non-circuit-related signaling.
TCAP signaling within IP networks may be used for cross-access between TCAP signaling within IP networks may be used for cross-access
entities in the SS7 domain and the IP domain, such as, for example: between entities in the SS7 domain and the IP domain, such as, for
- access from an SS7 network to a Service Control Point (SCP) in IP example:
- access from an SS7 network to an MGC
- access from an MGC to an SS7 network element
- access from an IP SCP to an SS7 network element
A basic functional model for TCAP over IP is shown in Figure 5. - access from an SS7 network to a Service Control Point (SCP) in IP.
- access from an SS7 network to an MGC.
- access from an MGC to an SS7 network element.
- access from an IP SCP to an SS7 network element.
+--------------+ A basic functional model for TCAP over IP is shown in Figure 5.
| IP SCP |
+--|----|------+
| |
SGU | | SGU
+--------------+ | | +--------------+
| | | | | |
SS7<--------->[SG] ---------+ | | [SG]<---------> SS7
(TCAP) | | | | | | |
+------|-------+ | +------|-------+
| | |
O +------------+ O
MGCU | | | MGCU
+-------|----|--+ +-----|--------+
| | | | | | |
| [MGC] | | [MGC] |
| | | | | |
+-------|-------+ +-----|--------+
| |
+-------|-------+ +-----|------+
Media | | | | | | Media
<------+---->[MG] <---+--RTP stream---+--> [MG] <-+-------->
stream| | | | stream
+---------------+ +------------+
MGU MGU
Figure 5: TCAP Signaling over IP +--------------+
| IP SCP |
+--|----|------+
| |
SGU | | SGU
+--------------+ | | +--------------+
| | | | | |
SS7<--------->[SG] ---------+ | | [SG]<---------> SS7
(TCAP) | | | | | | |
+------|-------+ | +------|-------+
| | |
O +------------+ O
MGCU | | | MGCU
+-------|----|--+ +-----|--------+
| | | | | | |
| [MGC] | | [MGC] |
| | | | | |
+-------|-------+ +-----|--------+
| |
+-------|-------+ +-----|------+
Media | | | | | | Media
<------+---->[MG] <---+--RTP stream---+--> [MG] <-+-------->
stream| | | | stream
+---------------+ +------------+
MGU MGU
Figure 5: TCAP Signaling over IP
3. Protocol Architecture 3. Protocol Architecture
This section provides a series of examples of protocol architecture This section provides a series of examples of protocol architecture
for the use of Signaling Transport (SIG). for the use of Signaling Transport (SIG).
3.1 Signaling Transport Components 3.1 Signaling Transport Components
Signaling Transport in the protocol architecture figures below is Signaling Transport in the protocol architecture figures below is
assumed to consist of three components (see Figure 6): assumed to consist of three components (see Figure 6):
1) an adaptation sub-layer that supports specific primitives, e.g., 1) an adaptation sub-layer that supports specific primitives, e.g.,
management indications, required by a particular SCN signaling management indications, required by a particular SCN signaling
application protocol. application protocol.
2) a Common Signaling Transport Protocol that supports a common set 2) a Common Signaling Transport Protocol that supports a common set
of reliable transport functions for signaling transport. of reliable transport functions for signaling transport.
3) a standard, unmodified IP transport protocol. 3) a standard, unmodified IP transport protocol.
+-- +--------------------------------+ +-- +--------------------------------+
| | SCN adaptation module | | | SCN adaptation module |
| +--------------------------------+ | +--------------------------------+
| | | |
S | +--------------------------------+ S | +--------------------------------+
I | | Common Signaling Transport | I | | Common Signaling Transport |
G | +--------------------------------+ G | +--------------------------------+
| | | |
| +--------------------------------+ | +--------------------------------+
| | standard IP transport | | | standard IP transport |
+-- +--------------------------------+ +-- +--------------------------------+
Figure 6: Signaling Transport Components Figure 6: Signaling Transport Components
3.2. SS7 access for Media Gateway Control 3.2. SS7 access for Media Gateway Control
This section provides a protocol architecture for signaling transport This section provides a protocol architecture for signaling transport
supporting SS7 access for Media Gateway Control. supporting SS7 access for Media Gateway Control.
****** SS7 ******* SS7 ****** IP ******* ****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *------------* MGC * *SEP *--------* STP *------* SG *------------* MGC *
****** ******* ****** ******* ****** ******* ****** *******
+----+ +-----+ +----+ +-----+
|ISUP| | ISUP| |ISUP| | ISUP|
+----+ +-----+ +---------+ +-----+ +----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP | SIG| | SIG | |MTP | |MTP | |MTP | SIG| | SIG |
|L1-3| |L1-3 | |L1-3+----+ +-----+ |L1-3| |L1-3 | |L1-3+----+ +-----+
| | | | | | IP | | IP | | | | | | | IP | | IP |
+----+ +-----+ +---------+ +-----+ +----+ +-----+ +---------+ +-----+
STP - Signal Transfer Point SEP - Signaling End Point STP - Signal Transfer Point SEP - Signaling End Point
SG - Signaling Gateway SIG - Signaling Transport SG - Signaling Gateway SIG - Signaling Transport
MGC - Media Gateway Controller MGC - Media Gateway Controller
Figure 7: SS7 Access to MGC Figure 7: SS7 Access to MGC
3.3. Q.931 Access to MGC 3.3. Q.931 Access to MGC
This section provides a protocol architecture for signaling transport This section provides a protocol architecture for signaling transport
supporting ISDN point-to-point access (Q.931) for Media Gateway Control. supporting ISDN point-to-point access (Q.931) for Media Gateway
Control.
****** ISDN ********* IP ******* ****** ISDN ********* IP *******
* EP *--------------* SG/MG *------------* MGC * * EP *--------------* SG/MG *------------* MGC *
****** ********* ******* ****** ********* *******
+----+ +-----+ +----+ +-----+
|Q931| | Q931| |Q931| | Q931|
+----+ +---------+ +-----+ +----+ +---------+ +-----+
|Q921| |Q921| SIG| | SIG | |Q921| |Q921| SIG| | SIG |
+ + + +----+ +-----+ + + + +----+ +-----+
| | | | IP | | IP | | | | | IP | | IP |
+----+ +---------+ +-----+ +----+ +---------+ +-----+
MG/SG - Media Gateway with SG function for backhaul MG/SG - Media Gateway with SG function for backhaul
EP - ISDN End Point EP - ISDN End Point
Figure 8: ISDN Access Figure 8: ISDN Access
3.4. SS7 Access to IP/SCP 3.4. SS7 Access to IP/SCP
This section provides a protocol architecture for database This section provides a protocol architecture for database access,
access, for example providing signaling between two IN for example providing signaling between two IN nodes or two mobile
nodes or two mobile network nodes. There are a number of network nodes. There are a number of scenarios for the protocol
scenarios for the protocol stacks and the functionality stacks and the functionality contained in the SIG, depending on the
contained in the SIG, depending on the SS7 application. SS7 application.
In the diagrams, SS7 Application Part (S7AP) is used for In the diagrams, SS7 Application Part (S7AP) is used for generality
generality to cover all Application Parts (e.g. MAP, IS-41, to cover all Application Parts (e.g. MAP, IS-41, INAP, etc).
INAP, etc). Depending on the protocol being transported, S7AP may or Depending on the protocol being transported, S7AP may or may not
may not include TCAP. The interface to the SS7 layer below include TCAP. The interface to the SS7 layer below S7AP can be either
S7AP can be either the TC-user interface or the SCCP-user the TC-user interface or the SCCP-user interface.
interface.
Figure 9a shows the scenario where SCCP is the signaling Figure 9a shows the scenario where SCCP is the signaling protocol
protocol being transported between the SG and an IP Signaling being transported between the SG and an IP Signaling Endpoint (ISEP),
Endpoint (ISEP), that is, an IP destination supporting some that is, an IP destination supporting some SS7 application protocols.
SS7 application protocols.
****** SS7 ******* SS7 ****** IP ******* ****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP* *SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** ******* ****** ******* ****** *******
+-----+ +-----+ +-----+ +-----+
|S7AP | |S7AP | |S7AP | |S7AP |
+-----+ +-----+ +-----+ +-----+
|SCCP | |SCCP | |SCCP | |SCCP |
+-----+ +-----+ +---------+ +-----+ +-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SIG | |SIG | |MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+ + + + + + +----+ +-----+
| | | | | | IP | |IP | | | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+ +-----+ +-----+ +---------+ +-----+
Figure 9a: SS7 Access to IP node - SCCP being transported Figure 9a: SS7 Access to IP node - SCCP being transported
Figure 9b shows the scenario where S7AP is the signaling Figure 9b shows the scenario where S7AP is the signaling protocol
protocol being transported between SG and ISEP. Depending on being transported between SG and ISEP. Depending on the protocol
the protocol being transported, S7AP may or may not include TCAP, being transported, S7AP may or may not include TCAP, which implies
which implies that SIG must be able to support both the TC-user that SIG must be able to support both the TC-user and the SCCP-user
and the SCCP-user interfaces. interfaces.
****** SS7 ******* SS7 ****** IP ******* ****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP* *SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** ******* ****** ******* ****** *******
+-----+ +-----+ +-----+ +-----+
|S7AP | |S7AP | |S7AP | |S7AP |
+-----+ +----+----+ +-----+ +-----+ +----+----+ +-----+
|SCCP | |SCCP| | | | |SCCP | |SCCP| | | |
+-----+ +-----+ +----|SIG | |SIG | +-----+ +-----+ +----|SIG | |SIG |
|MTP | |MTP | |MTP | | | | |MTP | |MTP | |MTP | | | |
+ + + + + +----+ +-----+ + + + + + +----+ +-----+
| | | | | |IP | |IP | | | | | | |IP | |IP |
+-----+ +-----+ +---------+ +-----+ +-----+ +-----+ +---------+ +-----+
Figure 9b: SS7 Access to IP node - S7AP being transported Figure 9b: SS7 Access to IP node - S7AP being transported
3.5. SG to SG 3.5. SG to SG
This section identifies a protocol architecture for support of This section identifies a protocol architecture for support of
signaling between two endpoints in an SCN signaling signaling between two endpoints in an SCN signaling network, using
network, using signaling transport directly between two SGs. signaling transport directly between two SGs.
The following figure describes protocol architecture for a The following figure describes protocol architecture for a scenario
scenario with two SGs providing different levels of function with two SGs providing different levels of function for interworking
for interworking of SS7 and IP. This corresponds to the scenario of SS7 and IP. This corresponds to the scenario given in Figure 3.
given in Figure 3.
The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly
for transport within the SS7 network, for example, ISUP. for transport within the SS7 network, for example, ISUP.
In this scenario, there are two different usage cases of SIG, In this scenario, there are two different usage cases of SIG, one
one which transports MTP3 signaling, the other which transports which transports MTP3 signaling, the other which transports ISUP
ISUP signaling. signaling.
****** SS7 ****** IP ****** IP ****** ****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC * *SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ****** ****** ****** ****** ******
+----+ +----+ +----+ +----+
|S7UP| |S7UP| |S7UP| |S7UP|
+----+ +----+----+ +----+ +----+ +----+----+ +----+
|MTP3| |MTP3| | | | |MTP3| |MTP3| | | |
+----+ +---------+ +----+ SIG| |SIG | +----+ +---------+ +----+ SIG| |SIG |
|MTP2| |MTP2|SIG | |SIG | | | | |MTP2| |MTP2|SIG | |SIG | | | |
+ + + +----+ +----+----+ +----+ + + + +----+ +----+----+ +----+
| | | | IP | | IP | | IP | | | | | IP | | IP | | IP |
+----+ +----+----+ +----+----+ +----+ +----+ +----+----+ +----+----+ +----+
S7UP - SS7 User Part S7UP - SS7 User Part
Figure 10: SG to SG Case 1 Figure 10: SG to SG Case 1
The following figure describes a more generic use of The following figure describes a more generic use of SS7-IP
SS7-IP interworking for transport of SS7 upper layer interworking for transport of SS7 upper layer signaling across an IP
signaling across an IP network, where the endpoints are network, where the endpoints are both SS7 SEPs.
both SS7 SEPs.
****** SS7 ****** IP ****** SS7 ****** ****** SS7 ****** IP ****** SS7 ******
*SEP *--------* SG *-----------* SG *--------*SEP * *SEP *--------* SG *-----------* SG *--------*SEP *
****** ****** ****** ****** ****** ****** ****** ******
+----+ +-----+ +----+ +-----+
|S7UP| | S7UP| |S7UP| | S7UP|
+----+ +-----+ +----+ +-----+
|MTP3| | MTP3| |MTP3| | MTP3|
+----+ +---------+ +---------+ +-----+ +----+ +---------+ +---------+ +-----+
|MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2| |MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2|
+ + + +----+ +----+ + + + + + + +----+ +----+ + + +
| | | | IP | | IP | | | | | | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+ +----+ +----+----+ +----+----+ +-----+
Figure 11: SG to SG Case 2 Figure 11: SG to SG Case 2
4. Functional Requirements 4. Functional Requirements
Signaling transport provides for the transport of native SCN protocol 4.1 Transport of SCN Signaling Protocols
messages over a packet switched network.
Signaling transport shall: Signaling transport provides for the transport of native SCN protocol
messages over a packet switched network.
1) Transport of a variety of SCN protocol types, such as the application Signaling transport shall:
and user parts of SS7 (including MTP Level 3, ISUP, SCCP, TCAP, MAP, INAP,
IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols (i.e. Q.931 and QSIG).
2) Provide a means to identify the particular SCN protocol being 1) Transport of a variety of SCN protocol types, such as the
transported. application and user parts of SS7 (including MTP Level 3, ISUP, SCCP,
TCAP, MAP, INAP, IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols
(i.e. Q.931 and QSIG).
3) Provide a common base protocol defining header formats, security 2) Provide a means to identify the particular SCN protocol being
extensions and procedures for signaling transport, and support transported.
extensions as necessary to add individual SCN protocols if and when
required.
4) In conjunction with the underlying network protocol (IP), provide the relevant functionality as defined by the appropriate SCN lower layer. 3) Provide a common base protocol defining header formats, security
extensions and procedures for signaling transport, and support
extensions as necessary to add individual SCN protocols if and when
required.
Relevant functionality may include (according to the protocol being 4) In conjunction with the underlying network protocol (IP), provide
transported): the relevant functionality as defined by the appropriate SCN lower
layer.
- flow control Relevant functionality may include (according to the protocol being
- in sequence delivery of signaling messages within a control stream transported):
- logical identification of the entities on which the signaling messages
originate or terminate
- logical identification of the physical interface controlled by the
signaling message
- error detection
- recovery from failure of components in the transit path
- retransmission and other error correcting methods
- detection of unavailability of peer entities.
For example: - flow control
- in sequence delivery of signaling messages within a control stream
- logical identification of the entities on which the signaling
messages originate or terminate
- logical identification of the physical interface controlled by the
signaling message
- error detection
- recovery from failure of components in the transit path
- retransmission and other error correcting methods
- detection of unavailability of peer entities.
- if the native SCN protocol is ISUP or SCCP, the relevant functionality For example:
provided by MTP2/3 shall be provided.
- if the native SCN protocol is TCAP, the relevant functionality
provided by SCCP connectionless classes and MTP 2/3 shall be supported.
- if the native SCN protocol is Q.931, the relevant functionality
provided by Q.921 shall be supported.
- if the native SCN protocol is MTP3, the relevant functionality of MTP2
shall be supported.
5) Support the ability to multiplex several higher layer SCN sessions on - if the native SCN protocol is ISUP or SCCP, the relevant
one underlying signaling transport session. This allows, for example, functionality provided by MTP2/3 shall be provided.
several DSS1 D-Channel sessions to be carried in one signaling - if the native SCN protocol is TCAP, the relevant functionality
transport session. provided by SCCP connectionless classes and MTP 2/3 shall be
supported.
- if the native SCN protocol is Q.931, the relevant functionality
provided by Q.921 shall be supported.
- if the native SCN protocol is MTP3, the relevant functionality of
MTP2 shall be supported.
In general, in-sequence delivery is required for signaling messages 5) Support the ability to multiplex several higher layer SCN sessions
within a single control stream, but is not necessarily required on one underlying signaling transport session. This allows, for
for messages that belong to different control streams. The protocol example, several DSS1 D-Channel sessions to be carried in one
should if possible take advantage of this property to avoid blocking signaling transport session.
delivery of messages in one control stream due to sequence error within
another control stream. The protocol should also allow the SG to send
different control streams to different destination ports if desired.
6) Be able to transport complete messages of greater length than the In general, in-sequence delivery is required for signaling messages
underlying SCN segmentation/reassembly limitations. For example, within a single control stream, but is not necessarily required for
signaling transport should not be constrained by the length limitations messages that belong to different control streams. The protocol
defined for SS7 lower layer protocol (e.g. 272 bytes in the case of should if possible take advantage of this property to avoid blocking
narrowband SS7) but should be capable of carrying longer messages delivery of messages in one control stream due to sequence error
without requiring segmentation. within another control stream. The protocol should also allow the SG
to send different control streams to different destination ports if
desired.
7) Allow for a range of suitably robust security schemes to protect 6) Be able to transport complete messages of greater length than the
signaling information being carried across networks. For example, underlying SCN segmentation/reassembly limitations. For example,
signaling transport shall be able to operate over proxyable sessions, signaling transport should not be constrained by the length
and be able to be transported through firewalls. limitations defined for SS7 lower layer protocol (e.g. 272 bytes in
the case of narrowband SS7) but should be capable of carrying longer
messages without requiring segmentation.
8) Provide for congestion avoidance on the Internet, by supporting 7) Allow for a range of suitably robust security schemes to protect
appropriate controls on signaling traffic generation (including signaling information being carried across networks. For example,
signaling generated in SCN) and reaction to network congestion. signaling transport shall be able to operate over proxyable sessions,
and be able to be transported through firewalls.
8) Provide for congestion avoidance on the Internet, by supporting
appropriate controls on signaling traffic generation (including
signaling generated in SCN) and reaction to network congestion.
4.2 Performance of SCN Signaling Protocols 4.2 Performance of SCN Signaling Protocols
This section provides basic values regarding performance requirements This section provides basic values regarding performance requirements
of key SCN protocols to be transported. Currently only message-based of key SCN protocols to be transported. Currently only message-based
SCN protocols are considered. Failure to meet these requirements SCN protocols are considered. Failure to meet these requirements is
is likely to result in adverse and undesirable signaling and call likely to result in adverse and undesirable signaling and call
behavior. behavior.
4.2.1 SS7 MTP requirements 4.2.1 SS7 MTP requirements
The performance requirements below have been specified for The performance requirements below have been specified for transport
transport of MTP Level 3 network management messages. The requirements of MTP Level 3 network management messages. The requirements given
given here are only applicable if all MTP Level 3 messages are to be here are only applicable if all MTP Level 3 messages are to be
transported over the IP network. transported over the IP network.
- Message Delay - Message Delay
- MTP Level 3 peer-to-peer procedures require response within - MTP Level 3 peer-to-peer procedures require response within 500
500 to 1200 ms. This value includes round trip time and processing to 1200 ms. This value includes round trip time and processing
at the remote end. at the remote end.
Failure to meet this limitation will result in the initiation of Failure to meet this limitation will result in the initiation
error procedures for specific timers, e.g., timer T4 of ITU-T of error procedures for specific timers, e.g., timer T4 of
Recommendation Q.704. ITU-T Recommendation Q.704.
4.2.2 SS7 MTP Level 3 requirements 4.2.2 SS7 MTP Level 3 requirements
The performance requirements below have been specified for transport of The performance requirements below have been specified for transport
MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7]. of MTP Level 3 user part messages as part of ITU-T SS7
Recommendations [SS7].
- Message Loss - Message Loss
- no more than 1 in 10E+7 messages will be lost due to transport - no more than 1 in 10E+7 messages will be lost due to transport
failure failure
- Sequence Error - Sequence Error
- no more than 1 in 10E+10 messages will be delivered out-of-sequence - no more than 1 in 10E+10 messages will be delivered out-of-
(including duplicated messages) due to transport failure sequence (including duplicated messages) due to transport
failure
- Message Errors - Message Errors
- no more than 1 in 10E+10 messages will contain an error that is - no more than 1 in 10E+10 messages will contain an error that is
undetected by the transport protocol (requirement is 10E+9 for undetected by the transport protocol (requirement is 10E+9 for
ANSI specifications) ANSI specifications)
- Availability - Availability
- availability of any signaling route set is 99.9998% or better, - availability of any signaling route set is 99.9998% or better,
i.e., downtime 10 min/year or less. A signaling route set is i.e., downtime 10 min/year or less. A signaling route set is
the complete set of allowed signaling paths from a given the complete set of allowed signaling paths from a given
signaling point towards a specific destination. signaling point towards a specific destination.
- Message length (payload accepted from SS7 user parts) - Message length (payload accepted from SS7 user parts)
- 272 bytes for narrowband SS7, 4091 bytes for broadband SS7 - 272 bytes for narrowband SS7, 4091 bytes for broadband SS7
4.2.3 SS7 User Part Requirements 4.2.3 SS7 User Part Requirements
More detailed analysis of SS7 User Part Requirements can be found in More detailed analysis of SS7 User Part Requirements can be found in
[Lin]. [Lin].
ISUP Message Delay - Protocol Timer Requirements ISUP Message Delay - Protocol Timer Requirements
- one example of ISUP timer requirements is the Continuity Test - one example of ISUP timer requirements is the Continuity Test
procedure, which requires that a tone generated at the sending procedure, which requires that a tone generated at the sending
end be returned from the receiving end within 2 seconds of end be returned from the receiving end within 2 seconds of
sending an IAM indicating continuity test. This implies that sending an IAM indicating continuity test. This implies that
one way signaling message transport, plus accompanying nodal one way signaling message transport, plus accompanying nodal
functions need to be accomplished within 2 seconds. functions need to be accomplished within 2 seconds.
ISUP Message Delay - End-to-End Requirements ISUP Message Delay - End-to-End Requirements
- the requirement for end-to-end call setup delay in ISUP is - the requirement for end-to-end call setup delay in ISUP is that
that an end-to-end response message be received within 20-30 seconds an end-to-end response message be received within 20-30 seconds
of the sending of the IAM. Note: while this is the protocol guard of the sending of the IAM. Note: while this is the protocol
timer value, users will generally expect faster response time. guard timer value, users will generally expect faster response
time.
TCAP Requirements - Delay Requirements TCAP Requirements - Delay Requirements
- TCAP does not itself define a set of delay requirements. Some - TCAP does not itself define a set of delay requirements. Some
work has been done [Lin2] to identify application-based delay work has been done [Lin2] to identify application-based delay
requirements for TCAP applications. requirements for TCAP applications.
4.2.4 ISDN Signaling Requirements 4.2.4 ISDN Signaling Requirements
Q.931 Message Delay Q.931 Message Delay
- round-trip delay should not exceed 4 seconds. - round-trip delay should not exceed 4 seconds. A Timer of this
A timer of this length is used for a number of procedures, esp. length is used for a number of procedures, esp. RELASE/RELEASE
RELEASE/RELEASE COMPLETE and CONNECT/CONNECT ACK where COMPLETE and CONNECT/CONNECT ACK where excessive delay may
excessive delay may result in management action on the result in management action on the channel, or release of a
channel, or release of a call being set up. Note: while this call being set up. Note: while this value is indicated by
value is indicated by protocol timer specifications, faster protocol timer specifications, faster response time is normally
response time is normally expected by the user. expected by the user.
- 12 sec. timer (T309) is used to maintain an active call - 12 sec. timer (T309) is used to maintain an active call in
in case of loss of the data link, pending re-establishment. case of loss of the data link, pending re-establishment. The
The related ETSI documents specify a maximum value of 4 seconds related ETSI documents specify a maximum value of 4 seconds
while ANSI specifications [T1.607] default to 90 seconds. while ANSI specifications [T1.607] default to 90 seconds.
5. Management 5. Management
Operations, Administration & Management (OA&M) of IP networks or SCN Operations, Administration & Management (OA&M) of IP networks or SCN
networks is outside the scope of SIGTRAN. Examples of OA&M include networks is outside the scope of SIGTRAN. Examples of OA&M include
legacy telephony management systems or IETF SNMP managers. OA&M legacy telephony management systems or IETF SNMP managers. OA&M
implementors and users should be aware of the functional interactions implementors and users should be aware of the functional interactions
of the SG, MGC and MG and the physical units they occupy. of the SG, MGC and MG and the physical units they occupy.
6. Security 6. Security Considerations
6.1 Security requirements 6.1 Security Requirements
When SCN related signaling is transported over an IP network When SCN related signaling is transported over an IP network two
two possible network scenarios can be distinguished: possible network scenarios can be distinguished:
- Signaling transported only within an Intranet; - Signaling transported only within an Intranet;
Security measures are applied at the discretion of the network Security measures are applied at the discretion of the network
owner. owner.
- Signaling transported, at least to some extent, in the public - Signaling transported, at least to some extent, in the public
Internet; Internet;
The public Internet should be regarded generally as an "insecure" The public Internet should be regarded generally as an "insecure"
network and usage of security measures is required. network and usage of security measures is required.
Generally security comprises several aspects Generally security comprises several aspects
- Authentication: - Authentication:
It is required to ensure that the information is sent to/from a known It is required to ensure that the information is sent to/from a
and trusted partner. known and trusted partner.
- Integrity: - Integrity:
It is required to ensure that the information hasn't been modified It is required to ensure that the information hasn't been modified
while in transit. while in transit.
- Confidentiality: - Confidentiality:
It might be sometimes required to ensure that the transported It might be sometimes required to ensure that the transported
information is encrypted to avoid illegal use. information is encrypted to avoid illegal use.
- Availability: - Availability:
It is required that the communicating endpoints remain in It is required that the communicating endpoints remain in service
service for authorized use even if under attack. for authorized use even if under attack.
6.2 Security mechanisms currently available in IP networks 6.2 Security Mechanisms Currently Available in IP Networks
Several security mechanisms are currently available for use in IP networks. Several security mechanisms are currently available for use in IP
networks.
- IPSEC ([RFC2401]): - IPSEC ([RFC2401]):
IPSEC provides security services at the IP layer that address the above IPSEC provides security services at the IP layer that address the
mentioned requirements. It defines the two protocols AH and ESP above mentioned requirements. It defines the two protocols AH and
respectively that ESP respectively that essentially provide data integrity and data
essentially provide data integrity and data confidentiality services.
confidentiality services.
The ESP mechanism can be used in two different modes: The ESP mechanism can be used in two different modes:
- Transport mode; - Transport mode;
- Tunnel mode. - Tunnel mode.
In Transport mode IPSEC protects the higher layer protocol data
portion of an IP packet, while in Tunnel mode a complete IP packet
is encapsulated in a secure IP tunnel.
If the SIG embeds any IP addresses outside of the SA/DA in the IP In Transport mode IPSEC protects the higher layer protocol data
header, passage through a NAT function will cause problems. The same portion of an IP packet, while in Tunnel mode a complete IP packet is
is true for using IPsec in general, unless an IPsec ready RSIP encapsulated in a secure IP tunnel.
function is used as described in draft-ietf-nat-terminology-02.txt.
The use of IPSEC does not hamper the use of TCP or UDP as the If the SIG embeds any IP addresses outside of the SA/DA in the IP
underlying basis of SIG. If automated distribution of keys is header, passage through a NAT function will cause problems. The same
required the IKE protocol (RFC[2409]) can be applied. is true for using IPsec in general, unless an IPsec ready RSIP
function is used as described in RFC 2663 [NAT].
- SSL, TLS ([RFC2246]): The use of IPSEC does not hamper the use of TCP or UDP as the
SSL and TLS also provide appropriate security services but operate on underlying basis of SIG. If automated distribution of keys is
top of TCP/IP only. required the IKE protocol ([RFC2409]) can be applied.
It is not required to define new security mechanisms in SIG, as the - SSL, TLS ([RFC2246]):
use of currently available mechanisms is sufficient to provide the SSL and TLS also provide appropriate security services but operate
necessary security. It is recommended that IPSEC or some equivalent on top of TCP/IP only.
method be used, especially when transporting SCN signaling over
public Internet. It is not required to define new security mechanisms in SIG, as the
use of currently available mechanisms is sufficient to provide the
necessary security. It is recommended that IPSEC or some equivalent
method be used, especially when transporting SCN signaling over
public Internet.
7. Abbreviations 7. Abbreviations
CAS Channel-Associated Signaling CAS Channel-Associated Signaling
DSS1 Digital Subscriber Signaling DSS1 Digital Subscriber Signaling
INAP Intelligent Network Application Part INAP Intelligent Network Application Part
ISEP IP Signaling End Point ISEP IP Signaling End Point
ISUP Signaling System 7 ISDN User Part ISUP Signaling System 7 ISDN User Part
MAP Mobile Application Part MAP Mobile Application Part
MG Media Gateway MG Media Gateway
MGU Media Gateway Unit MGU Media Gateway Unit
MGC Media Gateway Controller MGC Media Gateway Controller
MGCU Media Gateway Controller Unit MGCU Media Gateway Controller Unit
MTP Signaling System 7 Message Transfer Part MTP Signaling System 7 Message Transfer Part
PLMN Public Land Mobile Network PLMN Public Land Mobile Network
PSTN Public Switched Telephone Network PSTN Public Switched Telephone Network
S7AP SS7 Application Part S7AP SS7 Application Part
S7UP SS7 User Part S7UP SS7 User Part
SCCP SS7 Signaling Connection Control Part SCCP SS7 Signaling Connection Control Part
SCN Switched Circuit Network SCN Switched Circuit Network
SEP Signaling End Point SEP Signaling End Point
SG Signaling Gateway SG Signaling Gateway
SIG Signaling Transport protocol stack SIG Signaling Transport protocol stack
SS7 Signaling System No. 7 SS7 Signaling System No. 7
TCAP Signaling System 7 Transaction Capabilities Part TCAP Signaling System 7 Transaction Capabilities Part
8. Acknowledgements 8. Acknowledgements
The authors would like to thank K. Chong, I. Elliott, Ian Spiers, The authors would like to thank K. Chong, I. Elliott, Ian Spiers, Al
Al Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom for
for their valuable comments and suggestions. their valuable comments and suggestions.
9. References 9. References
[NAT] IP Network Address Translator (NAT) Terminology and Considerations [NAT] Srisuresh P. and M. Holdrege, "IP Network Address
<draft-ietf-nat-terminology-02.txt>, P. Srisuresh and M. Holdrege, April Translator (NAT) Terminology and Considerations", RFC
1999, work in progress. 2663, August 1999.
[PSS1/QSIG] ECMA Standard ECMA-143 -Inter-Exchange Signalling Procedures [PSS1/QSIG] ISO/IEC 11572 Ed. 2 (1997-06), "Information technology
and Protocol (QSIG-BC) - Telecommunications and information exchange between
systems - Private Integrated Services Network - Circuit
mode bearer services - Inter-exchange signalling
procedures and protocol"
[Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface layer 3 [Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface
specification (5/98) layer 3 specification (5/98)
[SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7
[SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of SS7 [SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7
[T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1) [SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of
- Layer 3 Signaling Specification for Circuit-Switched Bearer Services SS7
[Lin] Performance Requirements for Signaling in Internet Telephony, <draft-seth-sigtran-req-00.txt>, H. Lin, T. Seth, et al, work in progress. [T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System
Number 1 (DSS1) - Layer 3 Signaling Specification for
Circuit-Switched Bearer Services
[Lin2] Performance Requirements for TCAP Signaling in Internet Telephony, <draft-ietf-sigtran-tcap-perf-req-00.txt>, H. Lin, et al, work in progress. [Lin] Lin, H., Seth, T., et al., "Performance Requirements for
Signaling in Internet Telephony", Work in Progress.
Authors' Contact Information [Lin2] Lin, H., et al., "Performance Requirements for TCAP
Signaling in Internet Telephony", Work in Progress.
Lyndon Ong Ian Rytina [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
Nortel Networks Ericsson Australia RFC 2246, January 1999.
4401 Great America Parkway 37/360 Elizabeth Street
Santa Clara, CA 95054, USA Melbourne, Victoria 3000, Australia
long@nortelnetworks.com ian.rytina@ericsson.com
Matt Holdrege Lode Coene [RFC2409] Harkins, D. and C. Carrel, "The Internet Key Exchange
Ascend Communications Siemens Atea (IKE)", RFC 2409, November 1998.
1701 Harbor Bay Parkway Atealaan 34
Alameda, CA 94502 USA Herentals, Belgium
matt@ascend.com lode.coene@ntnet.atea.be
Miguel-Angel Garcia Chip Sharp [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Ericsson Espana Cisco Systems Internet Protocol", RFC 2401, November 1998.
Retama 7 7025 Kit Creek Road
28005 Madrid, Spain Res Triangle Pk, NC 27709, USA
Miguel.A.Garcia@ericsson.com chsharp@cisco.com
Imre Juhasz Haui-an Paul Lin Authors' Addresses
Telia Telcordia Technologies
Sweden Piscataway, NJ, USA
imre.i.juhasz@telia.se hlin@research.telcordia.com
HannsJuergen Schwarzbauer Lyndon Ong
SIEMENS AG Nortel Networks
Hofmannstr. 51 4401 Great America Parkway
81359 Munich, Germany Santa Clara, CA 95054, USA
HannsJuergen.Schwarzbauer@icn.siemens.de
EMail: long@nortelnetworks.com
Ian Rytina
Ericsson Australia
37/360 Elizabeth Street
Melbourne, Victoria 3000, Australia
EMail: ian.rytina@ericsson.com
Matt Holdrege
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502 USA
EMail: holdrege@lucent.com
Lode Coene
Siemens Atea
Atealaan 34
Herentals, Belgium
EMail: lode.coene@siemens.atea.be
Miguel-Angel Garcia
Ericsson Espana
Retama 7
28005 Madrid, Spain
EMail: Miguel.A.Garcia@ericsson.com
Chip Sharp
Cisco Systems
7025 Kit Creek Road
Res Triangle Pk, NC 27709, USA
EMail: chsharp@cisco.com
Imre Juhasz
Telia
Sweden
EMail: imre.i.juhasz@telia.se
Haui-an Paul Lin
Telcordia Technologies
Piscataway, NJ, USA
EMail: hlin@research.telcordia.com
HannsJuergen Schwarzbauer
SIEMENS AG
Hofmannstr. 51
81359 Munich, Germany
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the 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 be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 169 change blocks. 
675 lines changed or deleted 697 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/