draft-ietf-sigtran-framework-arch-01.txt   draft-ietf-sigtran-framework-arch-02.txt 
Internet Engineering Task Force Internet Engineering Task Force
INTERNET-DRAFT Authors INTERNET-DRAFT Authors
Transport Working Group Lyndon Ong, Nortel Networks Transport Working Group Lyndon Ong, Nortel Networks
Category: Informational Ian Rytina, Miguel Garcia, Ericsson Category: Informational Ian Rytina, Miguel Garcia, Ericsson
April 1999 HannsJuergen Schwarzbauer, Lode Coene, Siemens June 1999 HannsJuergen Schwarzbauer, Lode Coene, Siemens
Expires: November 1999 Huai-an Paul Lin, Telcordia Expires: January 2000 Huai-an Paul Lin, Telcordia
Imre Juhasz, Telia Imre Juhasz, Telia
Matt Holdrege, Ascend Matt Holdrege, Ascend
Chip Sharp, Cisco Systems Chip Sharp, Cisco Systems
Architectural Framework for Signaling Transport Architectural Framework for Signaling Transport
< draft-ietf-sigtran-framework-arch-01.txt > < draft-ietf-sigtran-framework-arch-02.txt >
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Internet-Drafts are with all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at line 44 skipping to change at page 2, line 5
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.
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [2]
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..............................................2
1.3 Scope...................................................4 1.3 Scope...................................................4
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.................5 2.2 SS7 Interworking for Connection Control.................6
2.3 ISDN Interworking for Connection Control................6 2.3 ISDN Interworking for Connection Control................8
2.4 CAS Backhaul............................................7 2.4 Architecture for Database Access........................9
2.5 Architecture for Database Access........................8 3. Protocol Architecture....................................10
3. Protocol Architecture.....................................9 3.1. Signaling Transport Components.........................10
3.1. SS7 access for Media Gateway Control....................9 3.2. SS7 access for Media Gateway Control...................11
3.2. Q.931 Access to MGC....................................10 3.3. Q.931 Access to MGC....................................12
3.3. SS7 Access to IP/SCP...................................10 3.4. SS7 Access to IP/SCP...................................12
3.4. SG to SG...............................................11 3.5. SG to SG...............................................13
4. Functional Requirements..................................13 4. Functional Requirements..................................15
5. Management...............................................16 5. Management...............................................18
6. Security.................................................17 6. Security.................................................18
7. Abbreviations............................................17 7. Abbreviations............................................20
8. Acknowledgements.........................................18 8. Acknowledgements.........................................20
9. References...............................................18 9. References...............................................20
Authors' Contact Information................................19 Authors' Contact Information................................21
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.
skipping to change at line 95 skipping to change at page 3, line 5
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-sequence
delivery and other functions that may be required for specific SCN delivery and other functions that may be required for specific SCN
signaling protocols. 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:
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [3]
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 interface for
the associated data stream (i.e., the MGU) back to the the associated data stream (i.e., SG function in the MGU) back to the
point of call processing (i.e., the MGCU), if this is not local. point of call processing (i.e., the MGCU), if this is not local.
Common Transport Protocol (CTP): Signaling Transport (SIG):
CTP is the transport layer protocol, which provides the interface SIG refers to signaling transport, which provides the interface
for signaling transport across and within IP networks. CTP refers for signaling transport across and within IP networks. SIG includes
to both the transport function and the adaptation function (required a set of functions supplementing a standard IP transport
to provide the SCN protocols with the same interface that exists protocol to provide the SCN protocol being transported with the same
towards the lower layers today). service interface that is provided by its SCN lower layer.
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 within
channelized bearers of pre-defined sizes. Examples include Public channelized bearers of pre-defined sizes. Examples include Public
Switched Telephone Networks (PSTNs) and Public Land Mobile Networks Switched Telephone Networks (PSTNs) and Public Land Mobile Networks
(PLMNs). Examples of signaling protocols used in SCN include Q.931, (PLMNs). Examples of signaling protocols used in SCN include Q.931,
SS7 MTP Level 3 and SS7 Application/User parts. 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
skipping to change at line 148 skipping to change at page 4, line 5
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 at
the edge of the IP network. The SG function may relay, translate or 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 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 also be co-resident with the MG function to process SCN signaling associated
with line or trunk terminations controlled by the MG (e.g., signaling backhaul). 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:
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [4]
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 may
contain other functions, esp. an SG function for handling facility- contain other functions, esp. an SG function for handling facility-
associated signaling. 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.
skipping to change at line 187 skipping to change at page 4, line 42
signaling protocols over IP networks. The scope of this work includes signaling protocols over IP networks. The scope of this work includes
definition of encapsulation methods, end-to-end protocol mechanisms and definition of encapsulation methods, end-to-end protocol mechanisms and
use of IP capabilities to support the functional and performance use of IP capabilities to support the functional and performance
requirements for signaling. 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 two
Signaling Gateway Units connecting signaling endpoints in the SCN. Signaling Gateway Units connecting signaling endpoints or signal
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 defined in such a way as to be independent of any protocol is defined in such a way as to be independent of any SCN protocol
translation functions taking place within the Signaling Gateway Unit or translation functions taking place at the endpoints of the signaling
Media Gateway Unit, since its function is limited to the transport of transport, since its function is limited to the transport of
the protocol. the SCN protocol.
Since the function being provided is transparent transport, the following Since the function being provided is transparent transport, the following
areas are considered outside the scope of the signaling transport work: areas are considered outside the scope of the signaling transport work:
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [5]
- 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 - in - specification of the functions taking place within the SGU or MGU
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
within the SGU or MGU are also considered out of scope,
such as determination of the destination IP address for signaling,
or specific procedures for assessing the performance of the transport
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 out the functions of SG, MGC and MG. This model may be 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 implemented in a number of ways, with functions implemented in separate
devices or combined in single physical units. devices or combined in single physical units.
skipping to change at line 249 skipping to change at page 6, line 31
| | | |
+-------|-------+ +-----|--------+ +-------|-------+ +-----|--------+
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
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [6]
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 and may potentially include MGC to MGC or include SG to MGC, SG to SG and may potentially include MGC to MGC or
MG to MGC as well. MG to MGC as well.
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 in
physical entities as used for interworking of SS7 and IP networks for physical entities as used for interworking of SS7 and IP networks for
Voice over IP, Voice over ATM, Network Access Servers, etc. No Voice over IP, Voice over ATM, Network Access Servers, etc. No
recommendation is made as to functional distribution and other recommendation is made as to functional distribution and other
skipping to change at line 303 skipping to change at page 7, line 37
------->[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 Notes: ST = Signaling Transport used to carry SCN signaling
Figure 2: Example Implementations Figure 2: Example Implementations
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [7]
In some implementations, the function of the SG may be divided into In some implementations, the function of the SG may be divided into
multiple physical entities to support scaling and addressing concerns. multiple physical entities to support scaling, signaling network
Thus, Signaling Transport can be used between SGs as well as from SG management and addressing concerns. Thus, Signaling Transport can be
to MGC. This is shown in Figure 3 below. 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| +--------------------------------+
skipping to change at line 346 skipping to change at page 9, line 5
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. Where
Q.931 is then transported to the MGC for call processing, signaling 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 transport would be used between the SG function and MGC. This is shown
in Figure 3 below. in Figure 3 below.
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [8]
MGCU MGCU
+-------------+ +-------------+
| [MGC] | | [MGC] |
| | | | | | | |
+-----|-|-----+ +-----|-|-----+
| | | |
| O device control | O device control
| | | |
Q.931/ST O | Q.931/ST O |
| | | |
skipping to change at line 382 skipping to change at page 9, line 39
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 between
entities in the SS7 domain and the IP domain, such as: entities in the SS7 domain and the IP domain, such as:
- access from an SS7 network to a Service Control Point (SCP) in IP - access from an SS7 network to a Service Control Point (SCP) in IP
- access from an SS7 network to an MGC - access from an SS7 network to an MGC
- access from an MGC to an SS7 network element - access from an MGC to an SS7 network element
- access from an IP SCP to an SS7 network element - access from an IP SCP to an SS7 network element
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [9] A basic functional model for TCAP over IP is shown in Figure 5.
A basic functional model for TCAP over IP is shown in Figure 4.
+--------------+ +--------------+
| IP SCP | | IP SCP |
+--|----|------+ +--|----|------+
| | | |
SGU | | SGU SGU | | SGU
+--------------+ | | +--------------+ +--------------+ | | +--------------+
| | | | | | | | | | | |
SS7<--------->[SG] ---------+ | | [SG]<---------> SS7 SS7<--------->[SG] ---------+ | | [SG]<---------> SS7
(TCAP) | | | | | | | (TCAP) | | | | | | |
skipping to change at line 417 skipping to change at page 10, line 36
<------+---->[MG] <---+--RTP stream---+--> [MG] <-+--------> <------+---->[MG] <---+--RTP stream---+--> [MG] <-+-------->
stream| | | | stream stream| | | | stream
+---------------+ +------------+ +---------------+ +------------+
MGU MGU MGU MGU
Figure 5: TCAP Signaling over IP 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 Common Transport Protocol (CTP). for the use of Signaling Transport (SIG).
3.1. SS7 access for Media Gateway Control 3.1 Signaling Transport Components
Signaling Transport in the protocol architecture figures below is
assumed to consist of three components (see Figure 6):
1) an adaptation sub-layer that supports specific primitives, e.g.,
management indications, required by a particular SCN signaling
application protocol.
2) a Common Signaling Transport Protocol that supports a common set
of reliable transport functions for signaling transport.
3) a standard IP transport protocol provided by the operating system.
+-- +--------------------------------+
| | SCN adaptation module |
| +--------------------------------+
| |
S | +--------------------------------+
I | | Common Signaling Transport |
G | +--------------------------------+
| |
| +--------------------------------+
| | standard IP transport (UDP) |
+-- +--------------------------------+
Figure 6: Signaling Transport Components
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 | CTP| | CTP | |MTP | |MTP | |MTP | SIG| | SIG |
+ + + + + +----+ +-----+ + + + + + +----+ +-----+
| | | | | | IP | | IP | | | | | | | IP | | IP |
+----+ +-----+ +---------+ +-----+ +----+ +-----+ +---------+ +-----+
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [10]
STP - Signal Transfer Point SEP - Signaling End Point STP - Signal Transfer Point SEP - Signaling End Point
SG - Signaling Gateway CTP - Common Transport Protocol SG - Signaling Gateway SIG - Signaling Transport
MGC - Media Gateway Controller MGC - Media Gateway Controller
Figure 6: SS7 Access to MGC Figure 7: SS7 Access to MGC
3.2. 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| CTP| | CTP | |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 7: ISDN Access Figure 8: ISDN Access
3.3. 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, for example providing signaling between two IN access, for example providing signaling between two IN
nodes or two mobile network nodes. There are a number of nodes or two mobile network nodes. There are a number of
scenarios for the protocol stacks and the functionality scenarios for the protocol stacks and the functionality
contained in the CTP, depending on the SS7 application. contained in the SIG, depending on the SS7 application.
In the diagrams, SS7 Application Part (S7AP) is used for In the diagrams, SS7 Application Part (S7AP) is used for
generality to cover all Application Parts (e.g. MAP, IS-41, generality to cover all Application Parts (e.g. MAP, IS-41,
INAP, etc). Depending on the protocol being transported, S7AP may or INAP, etc). Depending on the protocol being transported, S7AP may or
may not include TCAP. The interface to the SS7 layer below may not include TCAP. The interface to the SS7 layer below
S7AP can be either the TC-user interface or the SCCP-user S7AP can be either the TC-user interface or the SCCP-user
interface. interface.
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [11] Figure 9a shows the scenario where SCCP is the signaling
Figure 8a shows the scenario where SCCP is the signaling
protocol being transported between the SG and an IP Signaling protocol being transported between the SG and an IP Signaling
Endpoint (ISEP), that is, an IP destination supporting some Endpoint (ISEP), 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 |CTP | |CTP | |MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+ + + + + + +----+ +-----+
| | | | | | IP | |IP | | | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+ +-----+ +-----+ +---------+ +-----+
Figure 8a: SS7 Access to IP node - SCCP being transported Figure 9a: SS7 Access to IP node - SCCP being transported
Figure 8b shows the scenario where S7AP is the signaling Figure 9b shows the scenario where S7AP is the signaling
protocol being transported between SG and ISEP. Depending on protocol being transported between SG and ISEP. Depending on
the usage case, S7AP may or may not include TCAP, which implies the protocol being transported, S7AP may or may not include TCAP,
that CTP must be able to support both the TC-user and the which implies that SIG must be able to support both the TC-user
SCCP-user interfaces. and the SCCP-user interfaces.
****** SS7 ******* SS7 ****** IP ******* ****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP* *SEP *--------* STP *------* SG *-------------* ISEP*
****** ******* ****** ******* ****** ******* ****** *******
+-----+ +-----+ +-----+ +-----+
|S7AP | |S7AP | |S7AP | |S7AP |
+-----+ +----+----+ +-----+ +-----+ +----+----+ +-----+
|SCCP | |SCCP| | | | |SCCP | |SCCP| | | |
+-----+ +-----+ +----|CTP | |CTP | +-----+ +-----+ +----|SIG | |SIG |
|MTP | |MTP | |MTP | | | | |MTP | |MTP | |MTP | | | |
+ + + + + +----+ +-----+ + + + + + +----+ +-----+
| | | | | |IP | |IP | | | | | | |IP | |IP |
+-----+ +-----+ +---------+ +-----+ +-----+ +-----+ +---------+ +-----+
Figure 8b: SS7 Access to IP node - S7AP being transported Figure 9b: SS7 Access to IP node - S7AP being transported
3.4. 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 signaling transport directly between two SGs. network, using signaling transport directly between two SGs.
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [12]
The following figure describes protocol architecture for a The following figure describes protocol architecture for a
scenario with two SGs providing different levels of function scenario with two SGs providing different levels of function
for interworking of SS7 and IP. This corresponds to the scenario for interworking 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 CTP, In this scenario, there are two different usage cases of SIG,
one which transports MTP3 signaling, the other which transports one which transports MTP3 signaling, the other which transports
ISUP signaling. ISUP signaling.
****** SS7 ****** IP ****** IP ****** ****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC * *SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ****** ****** ****** ****** ******
+----+ +----+ +----+ +----+
|S7UP| |S7UP| |S7UP| |S7UP|
+----+ +----+----+ +----+ +----+ +----+----+ +----+
|MTP3| |MTP3| | | | |MTP3| |MTP3| | | |
+----+ +---------+ +----+ CTP| |CTP | +----+ +---------+ +----+ SIG| |SIG |
|MTP2| |MTP2|CTP | |CTP | | | | |MTP2| |MTP2|SIG | |SIG | | | |
+ + + +----+ +----+----+ +----+ + + + +----+ +----+----+ +----+
| | | | IP | | IP | | IP | | | | | IP | | IP | | IP |
+----+ +----+----+ +----+----+ +----+ +----+ +----+----+ +----+----+ +----+
S7UP - SS7 User Part S7UP - SS7 User Part
Figure 9: 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 interworking for transport of SS7 upper layer SS7-IP interworking for transport of SS7 upper layer
signaling across an IP network, where the endpoints are signaling across an IP 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| CTP| |CTP |MTP2| | MTP2| |MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2|
+ + + +----+ +----+ + + + + + + +----+ +----+ + + +
| | | | IP | | IP | | | | | | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+ +----+ +----+----+ +----+----+ +-----+
Figure 10: SG to SG Case 2 Figure 11: SG to SG Case 2
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [13]
4. Functional Requirements 4. Functional Requirements
Signaling transport provides for the transport of native SCN protocol Signaling transport provides for the transport of native SCN protocol
messages over a packet switched network. messages over a packet switched network.
Signaling transport shall: Signaling transport shall:
1) Transport of a variety of SCN protocol types, such as the application 1) Transport of a variety of SCN protocol types, such as the application
and user parts of SS7 (including MTP Level 3, ISUP, SCCP, TCAP, MAP, INAP, 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). 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 2) Provide a means to identify the particular SCN protocol being
transported. transported.
3) Provide a common base protocol defining header formats, security 3) Provide a common base protocol defining header formats, security
extensions and procedures for signaling transport, and support extensions and procedures for signaling transport, and support
extensions as necessary to add individual SCN protocols if and when extensions as necessary to add individual SCN protocols if and when
required. required.
4) In conjunction with the underlying network protocol (IP) and transport 4) In conjunction with the underlying network protocol (IP), provide the relevant functionality as defined by the appropriate SCN lower layer.
protocol (CTP), provide the relevant functionality as defined
by the appropriate SCN lower layer.
Relevant functionality may include (according to the protocol being Relevant functionality may include (according to the protocol being
transported): transported):
- flow control - flow control
- in sequence delivery of signaling messages within a control stream - in sequence delivery of signaling messages within a control stream
- logical identification of the entities on which the signaling messages - logical identification of the entities on which the signaling messages
originate or terminate originate or terminate
- logical identification of the physical interface controlled by the - logical identification of the physical interface controlled by the
signaling message signaling message
- error detection - error detection
- recovery from failure of components in the transit path - recovery from failure of components in the transit path
- retransmission and other error correcting methods - retransmission and other error correcting methods
- detection of unavailability of peer entities. - detection of unavailability of peer entities.
For example: For example:
- if the native SCN protocol is ISUP or SCCP, the relevant functionality - if the native SCN protocol is ISUP or SCCP, the relevant functionality
provided by MTP2/3 shall be provided. provided by MTP2/3 shall be provided.
- if the native SCN protocol is TCAP, the relevant functionality - if the native SCN protocol is TCAP, the relevant functionality
provided by SCCP and MTP 2/3 shall be supported. provided by SCCP connectionless classes and MTP 2/3 shall be supported.
- if the native SCN protocol is Q.931, the relevant functionality - if the native SCN protocol is Q.931, the relevant functionality
provided by Q.921 shall be supported. provided by Q.921 shall be supported.
- if the native SCN protocol is MTP3, the relevant functionality of MTP2 - if the native SCN protocol is MTP3, the relevant functionality of MTP2
shall be supported. shall be supported.
5) Support the ability to multiplex several higher layer SCN sessions on 5) Support the ability to multiplex several higher layer SCN sessions on
one underlying signaling transport session. This allows, for example, one underlying signaling transport session. This allows, for example,
several DSS1 D-Channel sessions to be carried in one signaling several DSS1 D-Channel sessions to be carried in one signaling
transport session. transport session.
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [14]
In general, in-sequence delivery is required for signaling messages In general, in-sequence delivery is required for signaling messages
within a single control stream, but is not necessarily required within a single control stream, but is not necessarily required
for messages that belong to different control streams. The protocol for messages that belong to different control streams. The protocol
should if possible take advantage of this property to avoid blocking should if possible take advantage of this property to avoid blocking
delivery of messages in one control stream due to sequence error within delivery of messages in one control stream due to sequence error within
another control stream. However, the SG will not be required to process another control stream. The protocol should also allow the SG to send
the SCN application protocol in order to identify control streams. different control streams to different destination ports if desired.
6) Be able to transport complete messages of greater length than the 6) Be able to transport complete messages of greater length than the
underlying SCN segmentation/reassembly limitations. For example, underlying SCN segmentation/reassembly limitations. For example,
signaling transport should not be constrained by the length limitations signaling transport should not be constrained by the length limitations
defined for SS7 lower layer protocol (e.g. 272 bytes in the case of defined for SS7 lower layer protocol (e.g. 272 bytes in the case of
narrowband SS7) but should be capable of carrying longer messages narrowband SS7) but should be capable of carrying longer messages
without requiring segmentation. without requiring segmentation.
7) Allow for a range of suitably robust security schemes to protect 7) Allow for a range of suitably robust security schemes to protect
signaling information being carried across networks. For example, signaling information being carried across networks. For example,
signaling transport shall be able to operate over proxyable sessions, signaling transport shall be able to operate over proxyable sessions,
and be able to be transported through firewalls. and be able to be transported through firewalls.
8) Provide for congestion avoidance on the Internet, by supporting 8) Provide for congestion avoidance on the Internet, by supporting
appropriate controls on signaling traffic generation (including appropriate controls on signaling traffic generation (including
signaling generated in SCN) and reaction to network congestion. 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 messaged 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 likely to result in adverse and undesirable signaling and call is 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 of MTP Level 3 network management messages. The requirements transport of MTP Level 3 network management messages. The requirements
given here are only applicable if all MTP Level 3 messages are to be given 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 to 1200 ms when terrestrial signaling links are used. This 500 to 1200 ms. This value includes round trip time and processing
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 of
error procedures for specific timers, e.g., timer T4 of ITU-T error procedures for specific timers, e.g., timer T4 of ITU-T
Recommendation Q.704. 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 of
MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7]. MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7].
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [15]
- 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-sequence
(including duplicated messages) due to transport failure (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
skipping to change at line 719 skipping to change at page 17, line 34
- 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
[Lin].
ISUP Message Delay - Protocol Timer Requirements ISUP Message Delay - Protocol Timer Requirements
- to be provided. - one example of ISUP timer requirements is the Continuity Test
procedure, which requires that a tone generated at the sending
end be returned from the receiving end within 2 seconds of
sending an IAM indicating continuity test. This implies that
one way signaling message transport, plus accompanying nodal
functions need to be accomplished within 2 seconds.
ISUP Message Delay - End-to-End Requirements ISUP Message Delay - End-to-End Requirements
- to be provided. - the requirement for end-to-end call setup delay in ISUP is
that 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
timer value, users will generally expect faster response time.
TCAP Requirements - End-to-End Requirements TCAP Requirements - Delay Requirements
- to be provided. - TCAP does not itself define a set of delay requirements. Some
work has been done [Lin2] to identify application-based delay
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 length is used for a number of procedures, esp. A timer of this length is used for a number of procedures, esp.
RELEASE/RELEASE COMPLETE and CONNECT/CONNECT ACK where RELEASE/RELEASE COMPLETE and CONNECT/CONNECT ACK where
excessive delay may result in management action on the excessive delay may result in management action on the
channel, or release of a call being set up. Note: while this channel, or release of a call being set up. Note: while this
value is indicated by protocol timer specifications, faster value is indicated by protocol timer specifications, faster
response time is normally expected by the user. response time is normally 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 case of loss of the data link, pending re-establishment. in case of loss of the data link, pending re-establishment.
The related ETSI documents specify a maximum value of 4 seconds The 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.
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [16]
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
skipping to change at line 803 skipping to change at page 19, line 34
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 above
mentioned requirements. It defines the two protocols AH and ESP mentioned requirements. It defines the two protocols AH and ESP
respectively that respectively that
essentially provide data integrity and data essentially provide data integrity and data
confidentiality services. confidentiality services.
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [17]
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 In Transport mode IPSEC protects the higher layer protocol data
portion of an IP packet, while in Tunnel mode a complete IP packet portion of an IP packet, while in Tunnel mode a complete IP packet
is encapsulated in a secure IP tunnel. is encapsulated in a secure IP tunnel.
If the CTP embeds any IP addresses outside of the SA/DA in the IP If the SIG embeds any IP addresses outside of the SA/DA in the IP
header, passage through a NAT function will cause problems. The same header, passage through a NAT function will cause problems. The same
is true for using IPsec in general, unless an IPsec ready RSIP is true for using IPsec in general, unless an IPsec ready RSIP
function is used as described in draft-ietf-nat-terminology-02.txt. 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 The use of IPSEC does not hamper the use of TCP or UDP as the
underlying basis of CTP. If automated distribution of keys is underlying basis of SIG. If automated distribution of keys is
required the IKE protocol (RFC[2409]) can be applied. required the IKE protocol (RFC[2409]) can be applied.
- SSL, TLS ([RFC2246]): - SSL, TLS ([RFC2246]):
SSL and TLS also provide appropriate security services but operate on SSL and TLS also provide appropriate security services but operate on
top of TCP/IP only. top of TCP/IP only.
It is not required to define new security mechanisms in CTP, as the It is not required to define new security mechanisms in SIG, as the
use of currently available mechanisms is sufficient to provide the use of currently available mechanisms is sufficient to provide the
necessary security. It is recommended that IPSEC or some equivalent necessary security. It is recommended that IPSEC or some equivalent
method be used, especially when transporting SCN signaling over method be used, especially when transporting SCN signaling over
public Internet. public Internet.
7. Abbreviations 7. Abbreviations
CAS Channel-Associated Signaling CAS Channel-Associated Signaling
CTP Common Transport Protocol
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
SS7 Signaling System No. 7 SS7 Signaling System No. 7
TCAP Signaling System 7 Transaction Capabilities Part TCAP Signaling System 7 Transaction Capabilities Part
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [18]
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 Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom Al Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom
for their valuable comments and suggestions. for their valuable comments and suggestions.
9. References 9. References
[NAT] IP Network Address Translator (NAT) Terminology and Considerations [NAT] IP Network Address Translator (NAT) Terminology and Considerations
<draft-ietf-nat-terminology-02.txt>, P. Srisurech and M. Holdrege, April <draft-ietf-nat-terminology-02.txt>, P. Srisuresh and M. Holdrege, April
1999, work in progress. 1999, work in progress.
[PSS1/QSIG] ECMA Standard ECMA-143 -Inter-Exchange Signalling Procedures [PSS1/QSIG] ECMA Standard ECMA-143 -Inter-Exchange Signalling Procedures
and Protocol (QSIG-BC) and Protocol (QSIG-BC)
[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 layer 3
specification (5/98) specification (5/98)
[SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7 [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 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of SS7
[T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1) [T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1)
- Layer 3 Signaling Specification for Circuit-Switched Bearer Services - Layer 3 Signaling Specification for Circuit-Switched Bearer Services
[Lin] Performance Requirements for Signaling in Internet Telephony, <draft-seth-sigtran-req-00.txt>, H. Lin, T. Seth, et al, work in progress.
[Lin2] Performance Requirements for TCAP Signaling in Internet Telephony, <draft-ietf-sigtran-tcap-perf-req-00.txt>, H. Lin, et al, work in progress.
Authors' Contact Information Authors' Contact Information
Lyndon Ong Ian Rytina Lyndon Ong Ian Rytina
Nortel Networks Ericsson Australia Nortel Networks Ericsson Australia
4401 Great America Parkway 37/360 Elizabeth Street 4401 Great America Parkway 37/360 Elizabeth Street
Santa Clara, CA 95054, USA Melbourne, Victoria 3000, Australia Santa Clara, CA 95054, USA Melbourne, Victoria 3000, Australia
long@nortelnetworks.com ian.rytina@ericsson.com long@nortelnetworks.com ian.rytina@ericsson.com
Matt Holdrege Lode Coene Matt Holdrege Lode Coene
Ascend Communications Siemens Atea Ascend Communications Siemens Atea
skipping to change at line 909 skipping to change at page 21, line 42
Retama 7 7025 Kit Creek Road Retama 7 7025 Kit Creek Road
28005 Madrid, Spain Res Triangle Pk, NC 27709, USA 28005 Madrid, Spain Res Triangle Pk, NC 27709, USA
Miguel.A.Garcia@ericsson.com chsharp@cisco.com Miguel.A.Garcia@ericsson.com chsharp@cisco.com
Imre Juhasz Haui-an Paul Lin Imre Juhasz Haui-an Paul Lin
Telia Telcordia Technologies Telia Telcordia Technologies
Sweden Piscataway, NJ, USA Sweden Piscataway, NJ, USA
imre.i.juhasz@telia.se hlin@research.telcordia.com imre.i.juhasz@telia.se hlin@research.telcordia.com
Hanns Juergen Schwarzbauer Hanns Juergen Schwarzbauer
Siemens AG SIEMENS AG
Munich, Germany Hofmannstr. 51
HannsJuergen.Schwarzbauer@ICN.SIEMENS.DE 81359 Munich, Germany
HannsJuergen.Schwarzbauer@icn.siemens.de
INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01. txt [19]
 End of changes. 

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