Internet Engineering Task Force
INTERNET-DRAFT Authors
Transport Working Group Lyndon Ong
Category: Informational Nortel Networks
February 1999 Ian Rytina
Expires: September 1999 Ericsson
Architectural Framework for Signaling Transport
< draft-ietf-sigtran-framework-arch-00.txt >
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document defines an architecture framework and functional requirements
for transport of signaling information over IP. The framework describes
relationships between functional and physical entities exchanging signaling
information, such as Signaling Gateways and Media Gateway Controllers, and
identifies where signaling transport may be used.
Ong Informational [Page 1]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
Table of Contents
1. Introduction..............................................3
1.1 Overview.................................................3
1.2 Terminology..............................................3
1.3 Scope...................................................4
2. Signaling Transport Architecture.........................5
2.1 Gateway Component Functions.............................5
2.2 SS7 Interworking for Connection Control.................5
2.3 ISDN Interworking for Connection Control................7
2.4 CAS Backhaul............................................7
2.5 Architecture for Database Access........................8
3. Protocol Architecture.....................................8
3.1. SS7 access for Media Gateway Control....................8
3.2. Q.931 Access to MGC.....................................9
3.3. SS7 Access to IP/SCP...................................10
3.4. SG to SG...............................................10
4. Functional Requirements..................................11
5. Management...............................................12
6. Security.................................................12
7. Acknowledgements.........................................12
8. References...............................................12
Authors' Addresses..........................................12
Ong Informational [Page 2]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
1. Introduction
1.1 Overview
This document defines an architecture framework for transport of signaling
information over IP. The framework describes relationships between functional
and physical entities used for control of Media Gateways and identifies where
signaling transport may be required. The architecture is based on [1].
1.2 Terminology
The following are general terms are used in this document:
Backhaul:
Backhaul refers to the transport of signaling from the point of interface
for the associated data stream (i.e., the MGU) back to the point of call
processing (i.e., the MGCU), if this is not local.
Switched Circuit Network (SCN):
The term SCN is used to refer to a network that carries traffic within
channelized bearers of pre-defined sizes. Examples include Public Switched
Telephone Networks (PSTNs) and Public Land Mobile Networks (PLMNs). Examples
of signaling protocols used in SCN include Q.931, Signaling System 7 (SS7)
ISDN User Part (ISUP) and Global System for Mobile Communication (GSM).
The following are terms for functional entities relating to signaling
transport in a distributed gateway model.
Media Gateway (MG):
A MG terminates terminates SCN media streams, packetizes the media data,, if it
is not already packetized, and delivers packetized traffic to the packet network.
It performs these functions in reverse order for media streams flowing from the
packet network to the SCN.
Media Gateway Controller (MGC):
An MGC handles the registration and management of resources at the MG.
The MGC may have the ability to authorize resource usage based on local policy.
Signaling Gateway (SG):
An SG is a signaling agent [1,4] that receives/sends SCN native signaling at the edge
of the IP network. The SG function may relay, translate or terminate SS7
signaling in an SS7-Internet Gateway. The SG function may also be co-resident
with the MG function to process SCN signaling associated with line or trunk
terminations controlled by the MG.
Signaling Transport Gateway (STG):
An SG which transports upper layer signaling information over a
different underlying network; for example, ISUP over IP instead
of ISUP over lower SS7 layers. In this document, SG should be interpreted
as performing STG functions unless otherwise noted.
Ong Informational [Page 3]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
Signaling Interworking Gateway (SIG):
An SG which interworks both upper and lower layer signaling information,
for example, interworking of ISUP/MTP and H.225/IP.
The following are terms for physical entities relating to signaling
transport in a distributed gateway model:
Media Gateway Unit (MGU)
An MG-Unit is a physical entity that contains the MG function. It may
contain other functions, esp. an SG function for handling facility-
associated signaling.
Media Gateway Control Unit (MGCU)
An MGC-Unit is a physical entity containing the MGC function.
Signaling Gateway Unit (SGU)
An SG-Unit is a physical entity containing the SG function.
Signaling End Point (SEP):
This is a node in an SS7 network that originates or terminates signaling
messages. Examples include a database or central office.
Signal Transfer Point (STP):
This is a node in an SS7 network that routes signaling messages based on
their destination address in the SS7 network
1.3 Scope
Signaling transport focuses on transparent transport of message-based signaling
protocols over IP networks. The scope of this work includes definition of
encapsulation methods, end-to-end protocol mechanisms and use of IP capabilities
such as differentiated services to support the functional and performance
requirements for signaling.
There are several cases where signaling transport may be useful, as described
in greater detail in following sections. One example is transport of SCN
signaling between a Signaling Gateway Unit and Media Gateway Controller Unit.
Other examples include transport of facility-associated SCN signaling between
a Media Gateway Unit and Media Gateway Controller Unit, and transport of
signaling between two Signaling Gateway Units connection signaling endpoints
in the SCN.
Since the focus is on transport, the following items will be outside the scope
of the signaling transport work:
- definition of the call control protocols themselves
- definition of protocol conversion for call control, such as conversion from
Channel Associated Signaling (CAS) to message signaling protocols
- specification of the functions taking place within the SGU or MGU - in
particular, this work does not address whether the SGU provides STG or
SIG functions, as this is transparent to the transport function.
Ong Informational [Page 4]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
The signaling transport will be defined in such a way as to support
encapsulation and carriage of a variety of call control protocols. It
is defined in such a way as to be independent of any protocol translation
functions taking place within the Signaling Gateway Unit or Media Gateway
Unit, since its function is limited to the transport of the protocol.
2. Signaling Transport Architecture
2.1 Gateway Component Functions
Figure 1 defines a commonly defined functional model for the VoIP Gateway
that separates out the functions of SG, MGC and MG. This model may be
implemented in a number of ways, with functions implemented in separate
devices or combined in single physical units.
Where physical separation exists between functional entities, Signaling
Transport can be applied to ensure that SCN signaling information is
transported between entities with the required functionality and
performance.
Signaling gateway Signaling gateway (opt)
+---------------+ +--------------+
| | SG-SG transport | |
SCN<-------->[SG] <--+---------O------------+--> [SG] <------> SCN
signal | | | | | | signal
+-------|-------+ +-----|--------+
| |
O O
| |
+-------|-------+ +-----|--------+
| | | MGC-MGC signaling | | |
| [MGC] <--+--------O-------------+--> [MGC] |
| | | | | |
| | | | | |
+-------|-------+ +-----|--------+
Gateway | controller Gateway | Controller (opt)
O O
| |
+-------|-------+ +-----|--------+
| | | | | |
<-IMT--+---->[MG] <---+-----RTP stream-------+-> [MG] <----+-IMT----->
| | | |
+---------------+ +--------------+
Media gateway Media gateway
Notes:
- IMT stands for Inter-Machine Trunk
Figure 1: Gateway Functional Model
2.2 SS7 Interworking for Connection Control
Figure 2 below shows some example implementations of these functions in
physical entities as used for interworking of SS7 and IP networks for Voice
over IP. No recommendation is made as to functional distribution
and other implementations are possible.
Ong Informational [Page 5]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
For interworking with SS7-controlled SCN networks, the SG terminates the
SS7 link and transfers the signaling information to the MGC using signaling
transport. The MG terminates the intermachine trunk and controls the trunk
based on the control signaling it receives from the MGC. Depending on
implementation, the SG and MGC may be in separate devices or co-located.
An alternative case (c) is the SS7 F-link, where the signaling link is
facility-associated, and is terminated by the same device (i.e., the MG)
that terminates the intermachine trunk. In this case, the SG function is
co-located with the MG function, as shown in Figure 2.
In the latter case, the signaling messages are "backhauled" to the MGC for
call processing, using signaling transport functionality.
SGU
+--------+
SS7<------>[SG] |
(ISUP) | | |
+---|----+
ST | SGU MGCU
+---|----+ +--------+ +--------+
| [MGC] | SS7---->[SG] | | [MGC] |
| | | | | | | | | |
+---|----+ +---|----+ +--|-|---+
MGCU | ST | | |
| | ST | |
+---|----+ +---|----+ +--|-|---+
IMT------->[MG] | IMT-->[MG/MGC]| SS7 F-link-->[SG]| |
| | | | IMT ------> [MG] |
+--------+ +--------+ +--------+
MGU MGU MGU
(a) (b) (c)
Notes: ST = Signaling Transport used to carry SCN signaling
Figure 2: Example Implementations
In some implementations, the function of the SG may be divided into
multiple physical entities to support scaling and addressing concerns.
Signaling Transport can be used between SGs as well as from SG to MGC.
This is shown in Figure 3 below.
Ong Informational [Page 6]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
SGU MGCU
+---------+ +---------+
| |ST| |
| [SG 2]------>[MGC] |
| ^ | | | |
+----|----+ +----|----+
| |
ST | |
| |
SS7 +----|------------|--+
-----------> [SG 1] | |
| | |
------------------------->[MG] |
+--------------------+
MGU
Figure 3: Multiple SG Case
2.3 ISDN Interworking for Connection Control
In ISDN access signaling, the signaling channel is carried along with 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
Q.931 is then transported to the MGC for call processing, signaling transport
would be used between the SG function and MGC. This is shown in Figure 3 below.
MGCU
+-------------+
| [MGC] |
| | | |
+-----|-|-----+
| |
| O device control
| |
Q.931/ST O |
| |
+-----|-|-----+
| | | |
Q.931-->[SG]| |
D-Chan| | |
| | |
B-Chan---->[MG] |
| |
+-------------+
MGU
Figure 3: Q.931 transport model
2.4 CAS Backhaul
In the case of Channel Associated Signaling (CAS), the signaling is
carried coupled with the data stream, and as in the Q.931 case, the
SCN signaling gateway function (SG) is co-located with the media gateway
function (MG). It is assumed here that the CAS is converted to a packet-
based SCN signaling protocol and backhauled to the MGC using signaling
transport capabilities. (Need for this tbd with megaco group).
Ong Informational [Page 7]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
2.5 Architecture for Database Access
Transaction Capabilities (TCAP or TC) is the application part within SS7
that is used for non-circuit-related signaling such as database access.
TCAP/TC signaling within IP networks may be used for cross-access between
entities in the SS7 domain and the IP domain, such as:
- access from an SS7 network to an IP network database
- access from an SS7 network to an MGC
- access from an MGC to an SS7 network element
- access from an IP Signaling End Point (ISEP) to an SS7 network element
A basic functional model for TCAP/TC over IP is shown in Figure 4.
+--------------+
| ISEP/Database|
+--|----|------+
| |
SGU | | SGU
+--------------+ | | +--------------+
| | / / | |
SS7<--------->[SG] -------/ / | [SG]<---------> SS7
(TCAP) | | | / | | |
+------|-------+ / +------|-------+
| ____/ |
O / O
MGCU | / | MGCU
+-------|-----/-+ +-----|--------+
| | / | | | |
| [MGC] | | [MGC] |
| | | | | |
+-------|-------+ +-----|--------+
| |
+-------|----------+ +-----|------+
| | | | | |
<-IMT-------->[MG]<---------RTP stream----->[MG]<--------IMT-->
| | | |
+------------------+ +------------+
MGU MGU
Notes: IMT is Inter-Machine Trunk
Figure 4: TCAP Signaling over IP
3. Protocol Architecture
3.1. SS7 access for Media Gateway Control
This section provides a protocol architecture for signaling transport
supporting SS7 access for Media Gateway Control.
Ong Informational [Page 8]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *------------* MGC *
****** ******* ****** *******
+----+ +-----+
|ISUP| | ISUP|
+----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP | CTP| | CTP |
+ + + + + +----+ +-----+
| | | | | | UDP| | UDP |
| | | | | | TCP| | TCP |
+ + + + + +----+ +-----+
| | | | | | IP | | IP |
+----+ +-----+ +---------+ +-----+
CO - Telco Central Office
STP - Signal Transfer Point
SG - Signaling Gateway
MGC - Media Gateway Controller
CTP - Common Transport Protocol
Note: Choice of UDP vs. TCP not yet decided.
3.2. Q.931 Access to MGC
This section provides a protocol architecture for signaling transport
supporting ISDN access (Q.931) for Media Gateway Control.
****** ISDN ********* IP *******
* SP *--------------* MG/SG *------------* MGC *
****** ********* *******
+----+ +-----+
|Q931| | Q931|
+----+ +---------+ +-----+
|Q921| |Q921| CTP| | CTP |
+ + + +----+ +-----+
| | | | UDP| | UDP |
| | | | TCP| | TCP |
+ + + +----+ +-----+
| | | | IP | | IP |
+----+ +---------+ +-----+
MG/SG - Media Gateway with SG function for backhaul
SP - ISDN Signaling Point
Ong Informational [Page 9]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
3.3. SS7 Access to IP/SCP
This section identifies a protocol architecture for signaling
between an SS7 SEP and an IP domain SEP (ISEP).
****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** *******
+-----+ +-----+
|S7AP | |S7AP |
+-----+ +-----+ +---------+ +-----+
|SCCP*| |SCCP*| | SCCP* | |SCCP*|
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP | CTP| |CTP |
+ + + + + +----+ +-----+
| | | | | | UDP| |UDP |
| | | | | | TCP| |TCP |
+ + + + + +----+ +-----+
| | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+
*Note: may or may not be present depending on application
SS7 Application Part (S7AP) is used for generality.
3.4. SG to SG
This section identifies a protocol architecture for support of
signaling between two endpoints in an SCN signaling
network, using signaling transport directly between two SGs.
The following figure describes protocol architecture for a
scenario with two SGs providing different levels of function
for interworking of SS7 and IP. This corresponds to the scenario
given in Figure 3 above.
****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ******
+----+ +----+
|S7UP| |S7UP|
+----+ +----+----+ +----+
|MTP3| |MTP3|CTP | |CTP |
+----+ +---------+ +---------| +----+
|MTP2| |MTP2| CTP| |CTP | | | |
+ + + +----+ +----+ | | |
| | | | UDP| |UDP |UDP | |UDP |
| | | | TCP| |TCP |TCP | |TCP |
| | | |----| |----|----| |----|
| | | | IP | | IP | IP | | IP |
+----+ +----+----+ +----+----+ +----+
Ong Informational [Page 10]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
The following figure describes a more generic use of
SS7-IP interworking for transport of SS7 upper layer
signaling across an IP network, where the endpoints are
both SS7 SEPs.
****** SS7 ****** IP ****** SS7 ******
*SEP *--------* SG *-----------* SG *--------*SEP *
****** ****** ****** ******
+----+ +-----+
|S7UP| | S7UP|
+----+ +-----+
|MTP3| | MTP3|
+----+ +---------+ +---------+ +-----+
|MTP2| |MTP2| CTP| |CTP |MTP2| | MTP2|
+ + + +----+ +----+ + + +
| | | | UDP| |UDP | | | |
| | | | TCP| |TCP | | | |
| | | |----| |----| | | |
| | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+
4. Functional Requirements
Signaling transport provides for the transport of native SCN protocol
messages over a packet switched network.
Signaling transport shall:
1) Transport of a variety of SCN protocol types, such as the application
and user parts of SS7 (including ISUP, SCCP, TCAP, MAP, INAP, IS-41, etc.)
and layer 3 of the DSS1/PSS1 protocols (i.e. Q.931 and QSIG).
2) Provide an identifier for the particular SCN protocol being transported.
3) Provide a common base protocol defining header formats, security
extensions and generic requirements for signaling transport, and support
extensions as necessary to add individual SCN protocols if and when required.
4) In conjunction with the underlying network protocol (IP) and transport
protocol (TCP, UDP or other), provide the relevant functionality as defined
by the appropriate SCN lower layer.
Relevant functionality may include (according to the protocol being
transported):
- flow control
- in sequence delivery of signaling messages (tbd. if this is supported
across multiple SCN signaling sessions)
- logical identification of the entities on which the signaling messages
originate or terminate
- logical identification of the physical interface controlled by the
signaling message
- load sharing over multiple signaling transport sessions
- retransmission
- information on unavailability of peer entities.
Ong Informational [Page 11]
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-00.txt
For example:
- if the native SCN protocol is ISUP or SCCP, the relevant functionality
provided by MTP2/3 shall be provided.
- if the native SCN protocol is TCAP, the relevant functionality provided
by SCCP and MTP 2/3 shall be provided.
- if the native SCN protocol is Q.931, the relevant functionality provided
by Q.921 shall be provided.
- if the native SCN protocol is MTP3, the relevant functionality of MTP2
shall be provided.
5) Support the ability to multiplex several higher layer SCN sessions on
one underlying signaling transport session. This allows, for example, the
output of several DSS1 D-Channel sessions to be carried in one signaling
transport session.
6) Be able to transport complete messages of greater length than the
underlying SCN segmentation/reassembly limitations. For example, signaling
transport should not be constrained by the length 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.
7) Allow for a range of suitably robust security schemes to protect signaling
information being carried across networks. For example,
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.
5. Management
Tbd.
6. Security
Tbd.
7. Acknowledgements
The author would like to thank K. Chong, I. Elliott, M. Holdrege, C. Sharp,
C. Huitema, I. Rytina and G. Sidebottom for their comments and suggestions.
8. References
[1] F. Cuervo, N. Greene, et al, "SS7-Internet Interworking - Architectural
Framework" <draft-greene-ss7-arch-frame-01.txt>, July 1998, work in progress.
Authors' Addresses
Lyndon Ong Ian Rytina
Nortel Networks Ericsson Australia
4401 Great America Parkway 37/360 Elizabeth Street
Santa Clara, CA 95054 Melbourne, Victoria 3000, Australia
long@nortelnetworks.com ian.rytina@ericsson.com
Ong Informational [Page 12]
