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.