Internet Engineering Task Force
INTERNET-DRAFT                                                  Authors
Transport Working Group                     Lyndon Ong
Category: Informational Ong, Nortel Networks
February  1999
Category: Informational             Ian Rytina Rytina, Miguel Garcia, Ericsson
April  1999              HannsJuergen Schwarzbauer, Lode Coene, Siemens
Expires: September November 1999                                        Ericsson                      Huai-an Paul Lin, Telcordia
                                                     Imre Juhasz, Telia
                                                  Matt Holdrege, Ascend
                                              Chip Sharp, Cisco Systems

         Architectural Framework for Signaling Transport
           < draft-ietf-sigtran-framework-arch-00.txt draft-ietf-sigtran-framework-arch-01.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

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories, see Directories can be accessed at
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 Controllers.  It identifies interfaces where
signaling transport may be used. used and the functional and performance
requirements that apply from existing Switched Circuit Network (SCN)
signaling protocols.

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt      draft-ietf-sigtran-framework-arch-01.txt         [2]

Table of Contents

1. Introduction..............................................3 Introduction..............................................2
1.1 Overview.................................................3 Overview.................................................2
1.2 Terminology..............................................3 Terminology..............................................2
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 Control................6
2.4  CAS Backhaul............................................7
2.5  Architecture for Database Access........................8
3. Protocol Architecture.....................................8 Architecture.....................................9
3.1. SS7 access for Media Gateway Control....................8 Control....................9
3.2. Q.931 Access to MGC.....................................9 MGC....................................10
3.3. SS7 Access to IP/SCP...................................10
3.4. SG to SG...............................................10 SG...............................................11
4. Functional Requirements..................................11 Requirements..................................13
5. Management...............................................12 Management...............................................16
6. Security.................................................12 Security.................................................17
7. Acknowledgements.........................................12 Abbreviations............................................17
8. References...............................................12 Acknowledgements.........................................18
9. References...............................................18
Authors' Addresses..........................................12

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt Contact Information................................19

1. Introduction

1.1 Overview

This document defines an architecture framework for transport of
message-based signaling
information protocols over IP. IP networks.  The scope of
this work includes definition of encapsulation methods, end-to-end
protocol mechanisms and use of existing IP capabilities to support
the functional and performance requirements for signaling transport.

The framework portion describes the relationships between functional
and physical entities used in signaling transport, including the
framework for control of Media Gateways Gateways, and identifies other scenarios where
signaling transport may be required.

The architecture is based on [1]. requirements portion describes functional and performance
requirements for signaling transport such as flow control, in-sequence
delivery and other functions that may be required for specific SCN
signaling protocols.

1.2 Terminology

The following are general terms are used in this document:

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [3]

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.

Common Transport Protocol (CTP):

CTP is the transport layer protocol, which provides the interface
for signaling transport across and within IP networks. CTP refers
to both the transport function and the adaptation function (required
to provide the SCN protocols with the same interface that exists
towards the lower layers today).

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)
SS7 MTP Level 3 and Global System for Mobile Communication (GSM). SS7 Application/User parts.

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.  For signaling transport purposes, the MGC serves as a possible
termination and origination point for SCN application protocols, such
as SS7 ISDN User Part and Q.931/DSS1.

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.

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt

Signaling Interworking Gateway (SIG):

An SG which interworks both upper and lower layer MG (e.g., signaling information,
for example, interworking of ISUP/MTP and H.225/IP. backhaul).

The following are terms for physical entities relating to signaling
transport in a distributed gateway model:

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [4]

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  One example is a database or central office. office switch.

Signal Transfer Point (STP):

This is a node in an SS7 network that routes signaling messages based on
their destination address point code in the SS7 network

1.3  Scope

Signaling transport focuses on provides 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

Signaling transport may shall be useful, as described
in greater detail in following sections.  One example is transport of used for transporting SCN signaling
between a Signaling Gateway Unit and Media Gateway Controller Unit.
Other examples include
Signaling transport may also be used for transport of facility-associated SCN message-based
signaling between a Media Gateway Unit and Media Gateway Controller
Unit, between dispersed Media Gateway Controller Units, and transport of
signaling between two
Signaling Gateway Units connection connecting signaling endpoints in the SCN.

Signaling transport will be defined in such a way as to support
encapsulation and carriage of a variety of SCN 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.

Since the focus function being provided is on transparent transport, the following items will be
areas are considered outside the scope of the signaling transport work:

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [5]

- definition of the call control SCN protocols themselves
- definition of protocol conversion for call control, signaling interworking 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,
  mediation/interworking, as this is transparent to the transport
  function.

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
       +-------|-------+                      +-----|--------+
               |                                    |
      Signaling|gateway                    Signaling|gateway (opt)
               O                                    O
               |                                    |
       +-------|-------+                      +-----|--------+
       |       |       |    MGC-MGC signaling                      |     |        |
       |      [MGC] <--+--------O-------------+--> [MGC]     |
       |       |       |                      |     |        |
       |       |       |                      |     |        |
       +-------|-------+                      +-----|--------+
       Gateway | controller                 Gateway | Controller controller (opt)
               O                                    O
               |                                    |
       +-------|-------+                      +-----|--------+
 Media |       |       |                      |     |        |
<-IMT--+---->[MG] Media
<------+---->[MG]  <---+-----RTP stream-------+-> [MG]  <----+-IMT----->
       |  <----+-------->
 stream|               |                      |              | stream
       +---------------+                      +--------------+
       Media gateway                           Media gateway

Notes:
- IMT stands for Inter-Machine Trunk

       Figure 1: Gateway Sigtran Functional Model

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [6]

As discussed above, the interfaces pertaining to signaling transport
include SG to MGC, SG to SG and may potentially include MGC to MGC or
MG to MGC as well.

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. IP, Voice over ATM, Network Access Servers, etc.  No
recommendation is made as to functional distribution and other
implementations are possible.

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 interswitch trunk and
controls the trunk based on the control signaling it receives from the
MGC.  Depending on
implementation, As shown below in case (a), the SG and SG, MGC and MG
may be implemented in separate devices physical units, or co-located.

An alternative as in case (c) is (b), the
MGC and MG may be implemented in a single physical unit.

In alternative case (c), a facility-associated SS7 F-link, where the signaling link is
facility-associated, and is terminated
by the same device (i.e., the MG) MGU) that terminates the intermachine interswitch trunk.
In this case, the SG function is co-located with the MG function, as shown in Figure 2.

In the latter case, the
below, and signaling messages are "backhauled" transport is used to the MGC for
call processing, using "backhaul" control signaling transport functionality. to
the MGCU.

Note: SS7 links may also be terminated directly on the MGCU by
cross-connecting at the physical level before or at the MGU.

         SGU
        +--------+
SS7<------>[SG]  |
(ISUP)  |   |    |
        +---|----+
         ST |                SGU                       MGCU
        +---|----+           +--------+                +--------+
        | [MGC]  |      SS7---->[SG]  |                | [MGC]  |
        |   |    |           |   |    |                |  | |   |
        +---|----+           +---|----+                +--|-|---+
       MGCU |                 ST |                        | |
            |                    |                     ST | |
  Media +---|----+     Media +---|----+                +--|-|---+
IMT------->[MG]
   ------->[MG]  |      IMT-->[MG/MGC]|      ----->[MG/MGC]|      SS7 F-link-->[SG]| link-->[SG]|   |
 stream |        |    stream |        |        IMT ------>       Media------> [MG] |
        +--------+           +--------+       stream   +--------+
        MGU                  MGU                       MGU

         (a)                     (b)                      (c)
Notes: ST = Signaling Transport used to carry SCN signaling

                 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
multiple physical entities to support scaling 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.

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt

               SGU                                 MGCU
             +---------+                         +---------+
             |         |ST|         |          ST             |         |
             |  [SG 2]------>[MGC]  [SG2]------------------------------>[MGC]  |
             |   ^ ^   |                         |         |
             +---|-|---+                         +---------+
                 | |
             +----|----+  +----|----+
                 | |             ST
               ST| +--------------------------------+
                 |                                  |
                 |                                  |
        SS7      +----|------------|--+  +---|----------+             SS7  +----|---------+
   -----------> [SG 1] [SG1]       |        -----------> [SG1]       |
    media    |              |         media    |              |
   ------------------->[MG] |
   ------------------------->[MG]        ------------------->[MG] |
             +--------------------+
    stream   +--------------+         stream   +--------------+
              MGU                                MGU

            Figure 3: Multiple SG Case

In this configuration, there may be more than one MGU handling
facility associated signaling (i.e. more than one containing it's
own SG function), and only a single SGU. It will therefore be
possible to transport one SS7 layer between SG1 and SG2, and
another SS7 layer between SG2 and MGC. For example, SG1 could
transport MTP3 to SG2, and SG2 could transport ISUP to MGC.

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.

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [8]

         MGCU
         +-------------+
         |    [MGC]    |
         |     | |     |
         +-----|-|-----+
               | |
               | O device control
               | |
      Q.931/ST O |
               | |
         +-----|-|-----+
         |     | |     |
Q.931-->[SG]|
   Q.931---->[SG]|     |
D-Chan|
  signals|       |     |
         |       |     |
B-Chan---->[MG]
Media---->[MG]   |
stream   |             |
         +-------------+
         MGU

     Figure 3: 4: 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).

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt

2.5  Architecture for Database Access

Transaction Capabilities (TCAP or TC) (TCAP) is the application part within SS7
that is used for non-circuit-related signaling such as database access.
TCAP/TC signaling.

TCAP 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 a Service Control Point (SCP) in 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) SCP to an SS7 network element

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [9]

A basic functional model for TCAP/TC TCAP over IP is shown in Figure 4.

                         +--------------+
                         | ISEP/Database| IP SCP       |
                         +--|----|------+
                            |    |
         SGU                |    |                SGU
        +--------------+    |    |    +--------------+
        |              |   /    /    |    |    |              |
SS7<--------->[SG] -------/    / ---------+    |    |     [SG]<---------> SS7
(TCAP)  |      |       |      /         |    |      |       |
        +------|-------+     /         |    +------|-------+
               |        ____/                 |           |
               O       /    +------------+           O
       MGCU    |      /    |                        | MGCU
       +-------|-----/-+
       +-------|----|--+               +-----|--------+
       |       |    /    |  |               |     |        |
       |      [MGC]    |               |    [MGC]     |
       |       |       |               |     |        |
       +-------|-------+               +-----|--------+
               |                             |
       +-------|----------+
       +-------|-------+               +-----|------+
 Media |       |       |               |     |      |
<-IMT-------->[MG]<---------RTP stream----->[MG]<--------IMT-->
       | Media
<------+---->[MG]  <---+--RTP stream---+--> [MG]  <-+-------->
 stream|               |               |            |
       +------------------+ stream
       +---------------+               +------------+
       MGU                             MGU

Notes: IMT is Inter-Machine Trunk

                 Figure 4: 5: TCAP Signaling over IP

3. Protocol Architecture

3.1. SS7 access for Media Gateway Control

This section provides a series of examples of protocol architecture
for signaling transport
supporting SS7 access for the use of Signaling Transport Common Transport Protocol (CTP).

3.1. SS7 access for Media Gateway Control

This section provides a protocol architecture for signaling transport
supporting SS7 access for Media Gateway Control.

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt

******   SS7  ******* SS7  ******     IP     *******
*SEP *--------* STP *------* SG *------------* MGC * SG*------------* MGC*
******        *******      ******            *******

+----+                                       +-----+
|ISUP|                                       | ISUP|
+----+        +-----+      +---------+       +-----+
|MTP |        |MTP  |      |MTP | CTP|       | CTP |
+    +        +     +      +    +----+       +-----+
|    |        |     |      |    | UDP|       | UDP |
|    |        |     |      |    | TCP|       | TCP |
+    +        +     +      +    +----+       +-----+
|    |        |     |      |    | IP |       | IP  |
+----+        +-----+      +---------+       +-----+

CO - Telco Central Office
INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [10]

STP - Signal Transfer Point
SG    SEP - Signaling Gateway
MGC End Point
SG - Media Signaling Gateway Controller         CTP - Common Transport Protocol

Note: Choice of UDP vs. TCP not yet decided.
MGC - Media Gateway Controller

            Figure 6: SS7 Access to MGC

3.2. Q.931 Access to MGC

This section provides a protocol architecture for signaling transport
supporting ISDN point-to-point access (Q.931) for Media Gateway Control.

******    ISDN      *********     IP     *******
* SP EP *--------------* MG/SG SG/MG *------------* MGC *
******              *********            *******

+----+                                   +-----+
|Q931|                                   | Q931|
+----+              +---------+          +-----+
|Q921|              |Q921| CTP|          | CTP |
+    +              +    +----+          +-----+
|    |              |    | UDP|          | UDP |
|    |              |    | TCP|          | TCP |
+    +              +    +----+          +-----+
|    |              |    | IP |          | IP  |
+----+              +---------+          +-----+

MG/SG - Media Gateway with SG function for backhaul
SP
EP - ISDN Signaling End Point

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt

              Figure 7: ISDN Access

3.3. SS7 Access to IP/SCP

This section identifies provides a protocol architecture for database
access, for example providing signaling between an two IN
nodes or two mobile network nodes. There are a number of
scenarios for the protocol stacks and the functionality
contained in the CTP, depending on the SS7 SEP application.

In the diagrams, SS7 Application Part (S7AP) is used for
generality to cover all Application Parts (e.g. MAP, IS-41,
INAP, etc). Depending on the protocol being transported, S7AP may or
may not include TCAP. The interface to the SS7 layer below
S7AP can be either the TC-user interface or the SCCP-user
interface.

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [11]

Figure 8a shows the scenario where SCCP is the signaling
protocol being transported between the SG and an IP domain SEP (ISEP). Signaling
Endpoint (ISEP), that is, an IP destination supporting some
SS7 application protocols.

******   SS7  ******* SS7  ******     IP      *******
*SEP *--------* STP *------* SG *-------------* ISEP*
******        *******      ******             *******

+-----+                                       +-----+
|S7AP |                                       |S7AP |
+-----+                                       +-----+      +---------+       +-----+
|SCCP*|        |SCCP*|
|SCCP |   SCCP*                                       |SCCP |       |SCCP*|
+-----+        +-----+      +---------+       +-----+
|MTP  |        |MTP  |      |MTP | CTP| |CTP |
+     +        +     +      +    +----+       +-----+
|     |        |     |      |    | UDP|       |UDP  |
|     |        |     |      |    | TCP|       |TCP       |CTP  |
+     +        +     +      +    +----+       +-----+
|     |        |     |      |    | IP |       |IP   |
+-----+        +-----+      +---------+       +-----+

*Note: may or may not be present depending on application

 Figure 8a: SS7 Application Part (S7AP) is used for generality.

3.4. SG Access to SG

This section identifies a protocol architecture IP node - SCCP being transported

Figure 8b shows the scenario where S7AP is the signaling
protocol being transported between SG and ISEP. Depending on
the usage case, S7AP may or may not include TCAP, which implies
that CTP must be able to support both the TC-user and the
SCCP-user interfaces.

******   SS7  ******* SS7  ******     IP      *******
*SEP *--------* STP *------* SG *-------------* ISEP*
******        *******      ******             *******

+-----+                                       +-----+
|S7AP |                                       |S7AP |
+-----+                     +----+----+       +-----+
|SCCP |                     |SCCP|    |       |     |
+-----+        +-----+      +----|CTP |       |CTP  |
|MTP  |        |MTP  |      |MTP |    |       |     |
+     +        +     +      +    +----+       +-----+
|     |        |     |      |    |IP  |       |IP   |
+-----+        +-----+      +---------+       +-----+

 Figure 8b: SS7 Access to IP node - S7AP being transported

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.

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [12]

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. 3.

The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly
for transport within the SS7 network, for example, ISUP.

In this scenario, there are two different usage cases of CTP,
one which transports MTP3 signaling, the other which transports
ISUP signaling.

******  SS7  ******   IP     ******  IP   ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
******       ******          ******       ******

+----+                                    +----+
|S7UP|                                    |S7UP|
+----+                     +----+----+    +----+
|MTP3|                     |MTP3|CTP                     |MTP3|    |    |    |CTP    |
+----+    +---------+      +---------|      +----+
|MTP2|    |MTP2| CTP|    |CTP |
|MTP2|    |MTP2|CTP |      |CTP |    |    |    |
+    +    +    +----+      +----+----+    +----+
|    |    |    |    |    |    | UDP|      |UDP |UDP |    |UDP |
|    |    |    | TCP|      |TCP |TCP |    |TCP |
|    |    |    |----|      |----|----|    |----|
|    |    |    | IP |      |   IP    | IP |    | IP |
+----+    +----+----+      +----+----+    +----+

INTERNET-DRAFT        draft-ietf-sigtran-framework-arch-00.txt

S7UP - SS7 User Part

              Figure 9: SG to SG Case 1

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 |    |    |     |
+----+        +----+----+     +----+----+    +-----+

              Figure 10: SG to SG Case 2

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [13]

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 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 an identifier for a means to identify the particular SCN protocol being
transported.

3) Provide a common base protocol defining header formats, security
extensions and generic requirements procedures 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), (CTP), 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 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
- load sharing over multiple signaling transport sessions error detection
- recovery from failure of components in the transit path
- retransmission and other error correcting methods
- information on detection of unavailability of peer entities.

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. supported.
- if the native SCN protocol is Q.931, the relevant functionality
  provided by Q.921 shall be provided. supported.
- if the native SCN protocol is MTP3, the relevant functionality of MTP2
  shall be provided. supported.

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.

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [14]

In general, in-sequence delivery is required for signaling messages
within a single control stream, but is not necessarily required
for messages that belong to different control streams.  The protocol
should if possible take advantage of this property to avoid blocking
delivery of messages in one control stream due to sequence error within
another control stream.  However, the SG will not be required to process
the SCN application protocol in order to identify control streams.

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

4.2 Performance of SCN Signaling Protocols

This section provides basic values regarding performance requirements
of key SCN protocols to thank K. Chong, I. Elliott, M. Holdrege, C. Sharp,
C. Huitema, I. Rytina be transported. Currently only messaged based
SCN protocols are considered.  Failure to meet these requirements
is likely to result in adverse and G. Sidebottom undesirable signaling and call
behavior.

4.2.1 SS7 MTP requirements

The performance requirements below have been specified for their comments
transport of MTP Level 3 network management messages. The requirements
given here are only applicable if all MTP Level 3 messages are to be
transported over the IP network.

- Message Delay
  -  MTP Level 3 peer-to-peer procedures require response within
     500 to 1200 ms when terrestrial signaling links are used.  This
     value includes round trip time and suggestions.

8. References

[1] F. Cuervo, N. Greene, et al, "SS7-Internet Interworking processing at the remote end.
     Failure to meet this limitation will result in the initiation of
     error procedures for specific timers, e.g., timer T4 of ITU-T
     Recommendation Q.704.

4.2.2 SS7 MTP Level 3 requirements

The performance requirements below have been specified for transport of
MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7].

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [15]

- Architectural
Framework" <draft-greene-ss7-arch-frame-01.txt>,  July 1998, work Message Loss
  - no more than 1 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 10E+7 messages will be lost due to transport
    failure

- Sequence Error
  - no more than 1 in 10E+10 messages will be delivered out-of-sequence
    (including duplicated messages) due to transport failure

- Message Errors
  - no more than 1 in 10E+10 messages will contain an error that is
    undetected by the transport protocol (requirement is 10E+9 for
    ANSI specifications)

- Availability
  - availability of any signaling route set is 99.9998% or better,
    i.e., downtime 10 min/year or less.  A signaling route set is
    the complete set of allowed signaling paths from a given
    signaling point towards a specific destination.

- Message length (payload accepted from SS7 user parts)
  - 272 bytes for narrowband SS7, 4091 bytes for broadband SS7

4.2.3 SS7 User Part Requirements

  ISUP Message Delay - Protocol Timer Requirements

  - to be provided.

  ISUP Message Delay - End-to-End Requirements

  - to be provided.

  TCAP Requirements - End-to-End Requirements

  - to be provided.

4.2.4 ISDN Signaling Requirements

  Q.931 Message Delay

  - round-trip delay should not exceed 4 seconds.
    A timer of this length is used for a number of procedures, esp.
    RELEASE/RELEASE COMPLETE and CONNECT/CONNECT ACK where
    excessive delay may result in management action on the
    channel, or release of a call being set up.  Note: while this
    value is indicated by protocol timer specifications, faster
    response time is normally expected by the user.

  - 12 sec. timer (T309) is used to maintain an active call
    in case of loss of the data link, pending re-establishment.
    The related ETSI documents specify a maximum value of 4 seconds
    while ANSI specifications [T1.607] default to 90 seconds.

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [16]

5. Management

Operations, Administration & Management (OA&M) of IP networks or SCN
networks is outside the scope of SIGTRAN. Examples of OA&M include
legacy telephony management systems or IETF SNMP managers. OA&M
implementors and users should be aware of the functional interactions
of the SG, MGC and MG and the physical units they occupy.

6. Security

6.1 Security requirements

When SCN related signaling is transported over an IP network
two possible network scenarios can be distinguished:

- Signaling transported only within an Intranet;
    Security measures are applied at the discretion of the network
    owner.

- Signaling transported, at least to some extent, in the public
  Internet;
    The public Internet should be regarded generally as an "insecure"
     network and usage of security measures is  required.

Generally security comprises several aspects

- Authentication:
    It is required to ensure that the information is sent to/from a known
    and trusted partner.

- Integrity:
    It is required to ensure that the information hasn't been modified
    while in transit.

- Confidentiality:
    It might be sometimes required to ensure that the transported
    information is encrypted to avoid illegal use.

- Availability:
    It is required that the communicating endpoints remain in
    service for authorized use even if under attack.

6.2 Security mechanisms currently available in IP networks

Several security mechanisms are currently available for use in IP networks.

- IPSEC ([RFC2401]):
    IPSEC provides security services at the IP layer that address the above
    mentioned requirements. It defines the two protocols AH and ESP
    respectively that
    essentially provide data integrity and data
    confidentiality services.

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [17]

    The ESP mechanism can be used in two different modes:
      - Transport 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 CTP embeds any IP addresses outside of the SA/DA in the IP
    header, passage through a NAT function will cause problems. The same
    is true for using IPsec in general, unless an IPsec ready RSIP
    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
    underlying basis of CTP.  If automated distribution of keys is
    required the IKE protocol (RFC[2409]) can be applied.

- SSL, TLS ([RFC2246]):
    SSL and TLS also provide appropriate security services but operate on
    top of TCP/IP only.

It is not required to define new security mechanisms in CTP, 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

CAS   Channel-Associated Signaling
CTP   Common Transport Protocol
DSS1  Digital Subscriber Signaling
INAP  Intelligent Network Application Part
ISEP  IP Signaling End Point
ISUP  Signaling System 7 ISDN User Part
MAP   Mobile Application Part
MG    Media Gateway
MGU   Media Gateway Unit
MGC   Media Gateway Controller
MGCU  Media Gateway Controller Unit
MTP   Signaling System 7 Message Transfer Part
PLMN  Public Land Mobile Network
PSTN  Public Switched Telephone Network
S7AP  SS7 Application Part
S7UP  SS7 User Part
SCCP  SS7 Signaling Connection Control Part
SCN   Switched Circuit Network
SEP   Signaling End Point
SG    Signaling Gateway
SS7   Signaling System No. 7
TCAP  Signaling System 7 Transaction Capabilities Part

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01.txt         [18]

8. Acknowledgements

The authors would like to thank K. Chong, I. Elliott, Ian Spiers,
Al Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom
for their valuable comments and suggestions.

9. References

[NAT] IP Network Address Translator (NAT) Terminology and Considerations
<draft-ietf-nat-terminology-02.txt>, P. Srisurech and M. Holdrege, April
1999, work in progress.

[PSS1/QSIG] ECMA Standard ECMA-143 -Inter-Exchange Signalling Procedures
and Protocol (QSIG-BC)

[Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface 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

[T1.607]  ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1)
 - Layer 3 Signaling Specification for Circuit-Switched Bearer Services

Authors' Contact Information

Lyndon Ong                        Ian Rytina
Nortel Networks                   Ericsson Australia
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
Ascend Communications             Siemens Atea
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
Ericsson Espana                   Cisco Systems
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
Telia                             Telcordia Technologies
Sweden                            Piscataway, NJ, USA
imre.i.juhasz@telia.se            hlin@research.telcordia.com

Hanns Juergen Schwarzbauer
Siemens AG
Munich, Germany
HannsJuergen.Schwarzbauer@ICN.SIEMENS.DE

INTERNET-DRAFT      draft-ietf-sigtran-framework-arch-01. txt         [19]