One document matched: draft-greene-ss7-arch-frame-00.txt
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.
| PAFTECH AB 2003-2026 | 2026-04-24 01:42:20 |