[Search] [txt|pdf|bibtex] [Tracker] [Email] [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-00.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]:

1-media gateway (MG): terminates PSTN facilities (trunks, loops), packetizes
the
media stream for IP 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.

2-media gateway controller (MC): 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.

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

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

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

Depending on the document, these functions 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).


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


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.

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


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

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