[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
INTERNET DRAFT                                      Fernando Cuervo
Category: Standards Track                              Nancy Greene
Title: <draft-greene-ss7-arch-frame-00.txt> Nortel(Northern Telecom)
Date: July 1998                                       Matt Holdrege

Expires: January 1999                         Ascend Communications
                                                         Lyndon Ong
                                                       Bay Networks
                                                  Christian Huitema
                                                           Bellcore

    SS7-Internet Interworking - Architectural Framework
          <draft-greene-ss7-arch-frame-01.txt>

Status of this Memo

This document is an Internet-Draft.  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 entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

This document describes an architectural framework for SS7-Internet
interworking, onto which existing protocols and future protocols in this
space can be mapped. It also provides an ordering of importance for the
standardization of these protocols.

Table of Contents

1.0 Introduction
2.0 Terminology
3.0 Base Configurations
3.1 A Reference Architecture
3.2 Dial-up Access Configuration
3.2.1 SS7 Dial-Up Access Configuration
3.2.2 Alternate Architecture for SS7 Dial-Up Access Configuration
3.2.3 Comparing Approaches
3.3 VoIP Transit Configuration
3.4 ISUP and TCAP Signalling over IP
3.5 Transport of SS7 Signalling (ISUP+TCAP) over IP
4.0 Next Steps
5.0 References and related work
6.0 Authors


1.0 Introduction

This architecture document covers subject terminology and defines at a high
level a set of individual scenarios for SS7-Internet interworking. These
scenarios include dial-up internet access, Voice over IP transit, and
transport
of SS7 signaling over IP. It then proposes a series of steps for
standardization.


2.0 Terminology

The following functions are commonly identified in related work [4,5]:

Call Controller:
A Call Controller introduces an open interface between a
Signalling Gateway and a Signalling Agent/Media Gateway Controller, allowing
the
Signalling Agent to access the SS7 network through multiple redundant
interfaces, e.g. the classic "quad" configuration of SS7 networks. A Call
Controller encompasses both a Signalling Agent and a Media Gateway
Controller.

Media Gateway (MG):
A MG terminates PSTN facilities (trunks, loops), packetizes the media stream
for
IP, if it is not already packetized, and delivers packetized traffic to the
IP network. Examples of MGs are NAS (Network Access Servers) and VoIP
gateways. The NAS and VoIP functions may or may not be combined in one
gateway.

Media Gateway Controller (MC):
An MG handles the registration and management of resources at the MG.  The
MC
may have the ability to authorize resource usage based on local policy, for
example, based on the attributes of both the end-user and the ISP. NAS
Controllers [5], for instance, provide MC functionality.

Network Access Server (NAS) Controller:
A NAS Controller allocates and deallocates resources according to some
resource
policy. A NAS Controller may control many NAS. It may share a server
platform



with Authentication/Authorization/Accounting (AAA) server
functions and/or
proxies to other AAA Servers. A NAS Controller encompasses both a Signalling

Gateway and a Media Gateway Controller.

Service Control Point (SCP):
This is a node in an SS7 network that provides centralized service logic and

data, such as call routing information.

Signal Transfer Point (STP):
This is a node in an SS7 network that routes signalling messages based on
their
destination address in the SS7 network


Signalling Agent (SA):
An SA realizes the signalling mediation function within the IP network, for
instance, for MG-to-MG, MG-to-SG, and SG-to-SG interworking. A "Call Agent"
in [4] includes an instance of an SA.

Signalling Gateway (SG):
An SG is a signalling agent that receives/sends PSTN native signalling at
the
edge of the IP network. The SG function may relay, translate or terminate
SS7
signaling in an SS7-Internet Gateway.

Other Servers (OS):
Other servers provide address translations, feature information,
authentication
services. IN-SCPs and RADIUS servers are instances of OS.


Depending on the document, the functions MG, MC, SA, SG and OS are grouped
into
nodes such as an SS7 Gateway, NAS Controller, Call Controller, Call Agent,
VoIP
gateway or NAS as discussed below.


3.0 Base Configurations

SS7-Internet interworking today covers dial-up access and VoIP applications.

This section presents base configurations that serve to illustrate the open
interfaces in the architecture, labeled by ----O----- in the figures below.

The figures also illustrate possible groupings of the functions enumerated
above, and propose an ordering of importance for standardization of the
protocols (the ordering of the figures implies an ordering of importance).

Currently several schemes are proposed for communication between a SG, MC,
and
MG. To allow these different functions to be encompassed in boxes that can
communicate even when the boxes are manufactured by different companies,
standard protocols are required. The sooner this occurs, the better. Thus,
the
highest priority of work should be to standardize the protocol for PSTN
native
signalling between the SG and MC/MG functions (section 3.2). However, there
are
other areas of work that may be addressed. These are covered in sections
3.3,
3.4 and 3.5.


3.1 A Reference Architecture
                PSTN                    IP Network           PSTN
                                         +----+
 +---+                                   |IP  |
 |SCP|     . . . . . . . . .      . . . .|database.       . . . . . . .
 +---+\    .               .      .      +----+   .       .           .
       \   .+---+          .      .               .       .           .
        \---|STP|------SS7--------. [SG]     [SG] .---------          .
           .+---+          .      . [MC]     [MC] .       .           .
           .               .      .               .       .           .
           .  +---+        .      .               .       .           .
           .  |CO |---------------. [MG]     [MG] .---------          .
           . /+---+        .      .               .       . . . . . .\.
 |----------/. . . . . . . .      . . . .+-----+. .                  /\
/\                                       |IP   |              telephone
telephone                                |phone|
                                         +-----+
Notes:
- SG, MC, and MG are functions that can be arranged in many ways with the IP

network. For example, [SG] and [MC] can be an SS7 gateway and/or NAS
controller,
co-located or separate, and [MC] on its own can be a call controller, and
[MG]
can be a Network Access Server (NAS) or VoIP Gateway
- IP database is any database accessible over IP
- CO is a central office, or PSTN switch,
- communication between MGs and SG/MCs may depend on whether the
communication
is for dial-up access or VoIP

                        Figure 1: Reference Architecture

Signaling System 7 (SS7) networking is the primary means used in the PSTN
for
control of circuit-switched connections and value added PSTN services such
as
freephone (800/888) number translation, calling card validation and
Intelligent
Network services. An architecture that includes a Signalling Gateway
provides a
scalable method of supporting interworking between SS7 network elements and
Internet elements such as a Network Access Server (NAS), or media gateway.
By
accessing the telecom network with SS7, data network elements fit cleanly
into
the telecom network infrastructure as peer switches and control points and
can
exchange information with telecom network elements for cleaner routing and
treatment of connections. [12, 13] provide more information on SS7.

The initial application of SS7 interconnection is to allow Internet access
points such as a media gateway to appear to the telecom network as a peer
telecom switch, for purposes of terminating calls for dial-up Internet
access.
Future applications include allowing exchange of information between more
general nodes within PSTN and Internet, such as a PSTN SCP and an Internet
telephony service (VoIP), or a PSTN switch and an Internet information
server,
such as a directory.


3.2 Dial-up Access Configuration

3.2.1 SS7 Dial-Up Access Configuration

Figure 2 is a simplified description of an SS7 dial-up access configuration.

Details related to end-user authentication have been left out for the sake
of
clarity.

          +--------------+
          |              |
--SS7--------> [SG/MC]   |
          |      |       |
          |      |       | SS7 Signalling Gateway/
          +------|----- -+ NAS Controller
                 |
                 O
                 |
                 |
          +------|--------+
          |      +----[SA]|
          |      |        |
          |    ([MC])     |
          |      |        |
 ---IP/dial-up->[MG] -----IP/tunnel-- >
          |      |        |
          |[SA-tunnel sig]|
          |               |
          +---------------+ NAS

Figure 2: SS7 dial-up access configuration

The architecture in figure 2 has one open interface. Today, two alternatives
for
this protocol are represented by products in the industry. On one hand,
[1,2,3]
advocate an architecture in which some of the MC resource management
function
resides in the NAS, and some MC functions such as registration reside in the

Signaling Gateway.  [1,2,3] propose a Q.931-based protocol for the interface

between Signaling Gateway and NAS. On the other hand, [5] integrates the
entire
MC function in the SG, and removes it from the MG.  [5] proposes the use of
DIAMETER [6,7,8,9,10,11] extensions for the open interface.

A typical call flow for figure 2 would be the following.  An SS7 message
arrives
at the SG/MC from the PSTN, initiating call setup.  The SG/MC translates
this
into notification to the NAS SA of the call request and the trunk to be used
for
the incoming call.   The NAS MG then terminates the media stream arriving on
the
trunk and packetizes the data for the IP network.  The NAS determines the IP

destination for the data, either through internal means or from information
that
the SG/MC provides.


3.2.2 Alternate Architecture for SS7 Dial-Up Access Configuration

An alternate architecture (figure 3) is to separate the NAS controller and
Signalling Agent functions from the Signalling Gateway and to place them in
a
Call Controller.

          +--------------+
          |              |
--SS7--------> [SG]      |
          |      |       |
          |      |       | SS7 Signalling Gateway
          +------|----- -+
                 |
                 O
                 |
          +------|-------+
          |      |       |
          |   [SA/MC]    |
          |      |       | Call Controller/
          |      |       | NAS Controller
          +------|----- -+
                 |
                 O
                 |
          +------|--------+
          |      |        |
          |    ([MC])     |
          |      |        |
 ---IP/dial-up->[MG] -----IP/tunnel-- >
          |               |
          +---------------+ NAS

   Figure 3: SS7 dial-up access configuration, with a separate call
controller

This alternate architecture is assumed in [4]. It presents two open
interfaces,
one between the Signalling Gateway and the Call Controller, and a second one

between the Call Controller and the NAS.  An open interface between SG and
SA
allows an SA to access the SS7 network through multiple redundant
interfaces,
e.g. the classic "quad" configurations of SS7 networks.

3.2.3 Comparing Approaches

While the highest priority of work should be to standardize the protocol for

PSTN native signalling between SG and MC/MG functions, discussion should
take
into account the other functions in the architecture that are required to
provide working services. The three approaches identified above can be
compared
as follows:

1- Q.931+ extensions [1,2,3] follow a standard protocol for call signalling
messaging and add new messages for resource control, configuration, and SS7
maintenance procedures such as busying of trunks and channels, graceful and
abrupt shutdown of trunks, and continuity testing.

2- Use of a protocol framework such as Diameter with resource control
extensions
[6,7,8,9,10,11], or a similar suite of protocols [IPDC-TAC internet-draft -
to be provided], adds generic support of other functions such as security,
end-user authentication extensions, dynamic association of SG and MC to MGs,

etc.

3- Use of an open interface between SG and SA, based for example on some
form of
transport of ISUP over IP, combined with the protocol proposed in [4],
allows
to concentrate all call-state in a Call Controller, enables calls to survive

the failure of an individual SG, and provides for compatibility with VoIP
solutions.


3.3 VoIP Transit Configuration

VoIP transit adds new requirements to the architecture. For example, there
will
be more than one VoIP gateway involved in a call, and possibly even more
than
one call controller or equivalent. One approach is that documented in [4].

Figure 4 is a simplified description of a VoIP transit application as found
in
[4]. This configuration shows a potential open interface between the
Signalling
Gateway and a Call Controller. This may not be necessary if the Call
Controller
and SS7 Gateway are implemented in one system.

Note that a Call Controller interworks with a second VoIP MG to complete a
call,
and this may or not be through a second Call Controller (see section 3.4).

In fact, the architecture described here is just one of perhaps many that
could
be used to provide VoIP transit.

     SS7 gateway
        +--------------+
        |              |
SS7<--------->[SG]     |
(ISUP)  |      |       |
        |      |       |
        +------|-------+
    ISUP/IP or |
    internal   O
               |
               |
call controller|
       +-------|-------+
       |      [SA]     |
       |       |       |
       |      [MC]     |
       |       | \     |
       +-------|--\----+
               |   \
               O    \-----------O-------------\
               |                              |
       +-------|----------+       +-----------|-----+
       |       |          |       |           |     |
       |       |          |       |           |     |
<-IMT------->[MG]<---------RTP stream------>[MG]<-------IMT----->
       |       |          |       |           |     |
       |   [SA-user sig]  |       |  [SA-user sig]  |
       |                  |       |                 |
       +------------------+       +-----------------+
       originating VoIP gateway   terminating VoIP gateway

Notes:
- IMT is Inter-Machine Trunk

          Figure 4: VoIP Transit Configuration

The call flow for figure 4 is similar to that for figure 2. For VoIP
however,
the Call Controller has the extra work of finding and then alerting the
terminating VoIP gateway of the call.


3.4 ISUP and TCAP Signalling over IP

In this section, scenarios involving both SS7 TCAP (Transaction
Capabilities)
and ISUP (ISDN User Part) signaling over IP are described.

TCAP signaling within IP networks may be used for access to a database.  In
the
VoIP case the database could be available from the Call Controller. In a NAS

dial-up access case, it could be available from the Signalling Gateway/NAS
Controller. Alternatively, the Signaling Gateway may provide access from SS7

network systems to an IP database (terminating TCAP), or may provide access
to
SS7 network databases from an IP system (originating TCAP), subject to
services
supported by the SS7 network.

ISUP signaling within IP networks may be used in the context of VoIP.  If
more
than one Call Controller is used by an implementation of VoIP, then an open
interface between Call Controllers needs to be considered. This interface
could
be supported by extensions to SS7 ISUP (ISDN User Part) protocol, carried
over
IP (see section 3.5). However, non-SS7 protocols such as H.323 (ITU-T SG16)
and
SIP (IETF mmusic) may also apply to this interface. See figure 5.

                         +--------------+
               SS7 ----->| SCP-Database |
            (TCAP)/      +--|-----------+
                 /          |
   SS7 gateway   O          |              SS7 gateway
        +--------|-----+    |         +--------------+
        |        v     |    |         |              |
SS7<---------->[SG]    |    |         |     [SG]<---------> SS7
(ISUP)  |      |  \    |    O         |      |       |    (ISUP)
        |      |   |   |    |         |      |       |
        +------|---|---+    |         +------|-------+
    ISUP/IP or |   |       /                 |
    internal   |   |      /                  |
               O   O TCAP/                   O
originating    |   | IP /                    | terminating
call controller|   |   /                     | call controller
       +-------|--/---/+               +-----|--------+
       |      [SA]---/ | ISUP+/IP or   |    [SA]      |
       |       |  \----------O-------------/ |        |
       |      [MC]     |intergatekeeper|    [MC]      |
       |       |       | protocol      |     |        |
       +-------|-------+               +-----|--------+
               O                             O
               |                             |
       +-------|----------+       +----------|------+
       |       |          |       |          |      |
       |       |          |       |          |      |
<-IMT-------->[MG]<---------RTP stream----->[MG]<--------IMT-->
       |       |          |       |          |      |
       |   [SA-user sig]  |       |  [SA-user sig]  |
       |                  |       |                 |
       +------------------+       +-----------------+
       originating VoIP gateway   terminating VoIP gateway

Notes:
- IMT is Inter-Machine Trunk

  Figure 5: ISUP/TCAP Signalling over IP in a particular VoIP
        Transit Configuration with >1 Call Controller


3.5 Transport of SS7 Signalling (ISUP+TCAP) over IP

SS7 utilizes its own message transport protocol and has defined performance
requirements.  Supporting SS7 signaling at the SS7 Gateway or within IP
networks
requires transport of signaling over IP.


4.0 Next Steps

This document provides a framework to identify the open interfaces that are
relevant to introduce useful services that have SS7-Internet interworking as
a
major component. From the ordering of the figures in section 3, it proposes
an
ordering of importance for standardization of the protocols.

The goal of an SS7-Internet working group would be to decide which protocols
are
to be standardized, with what priority, and the functionality necessary in
each
protocol.


5.0 References and related work

[1] R. Dalias, J. Matousek, L. Ong, "Bay Networks SS7-Internet Gateway
Architecture", draft-ong-ss7-internet-gateway-01.txt, May 1998, work in
progress

[2] J. Matousek, L. Ong, "Bay Networks SS7-Internet Access Signaling
Protocol",
draft-long-ss7-signal-00.txt, June 1998, work in progress

[3] M. Holdrege, "The Reliable Signaling Gateway Control Protocol",
draft-rfced-
info-holdrege-00.txt, June 1998, work in progress

[4] M. Arango, C. Huitema, Simple Gateway Control Protocol (SGCP), draft-
huitema-sgcp-v1-00.txt, May 1998, work in progress

[5] F. Cuervo, N. Greene, "Best Current Practice for Modem Outsourcing",
draft-
greene-nasreq-00.txt, March 1998, work in progress

[6] P. R. Calhoun, G. Zorn, P. Pan, "Diameter Framework Document", draft-
calhoun-diameter-framework-00.txt, May 1998, work in progress

[7] P. R. Calhoun, A. Rubens, "Diameter Base Protocol",
draft-calhoun-diameter-
03.txt, April 1998, work in progress

[8] P. R. Calhoun, N. Greene, "Diameter Resource Management Extensions",
draft-
calhoun-diameter-res-mgmt-01.txt, May 1998, work in progress

[9] N. Greene, F. Cuervo, "Diameter SS7 Session Setup Extensions",
draft-greene-
diameter-ss7-session-00.txt, July 1998, work in progress

 [10] P. R. Calhoun, W. Bulley, "Diameter User Authentication Extensions",
draft-
calhoun-diameter-authent-03.txt, April 1998, work in progress

[11] S. A. Vakil, P. R. Calhoun, "Diameter IP Security Policy extensions",
draft-calhoun-diameter-ipsec-policy-00.txt, March 1998, work in progress

[12] ITU-T Recommendation Q.700, "Introduction to CCITT Signalling System
No.
7", March, 1993

[13] ITU-T Recommendation Q.1600, "Signalling System No.7 - Interaction
between
ISUP and INAP", September, 1997

[IPDC-TAC internet-draft] - to be provided


6.0 Authors

    Fernando Cuervo
    Nortel
    Ottawa, ON, Canada
    Phone: 613-763-4628
    Email: cuervo@nortel.ca

    Nancy Greene
    Nortel
    Ottawa, ON, Canada
    Phone: 613-763-9789
    Email: ngreene@nortel.ca

    Matt Holdrege
    Ascend Communications
    1701 Harbor Bay Pkwy
    Alameda, CA 94502
    Phone: 510-769-6001
    Email: matt@ascend.com

    Christian Huitema
    Bellcore
    445 South Street, 1J236B
    Morristown, NJ 07960
    Email: huitema@bellcore.com

    Lyndon Ong
    Bay Networks, Inc.
    4401 Gt America Pkwy
    Santa Clara, CA 95052
    Email: long@baynetworks.com


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.