INTERNET DRAFT Fernando Cuervo Category: Informational Graeme Gibbs Title: draft-cuervo-navdec-mg-arch-00.txt Nortel Networks Date: November 1998 Media Gateway Architecture: A Functional Model of the Media Gateway 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents a functional model of a Media Gateway. The model extends the functional model of the base architecture draft[1]. The model identifies the functions that the MG may expose to other functions of the architecture, namely, the Media Gateway Controller and the Signalling Gateway [1]. The objective of the model is to identify completeness of the protocol functions, flexibility to handle the optionality of functions and ensure that the protocol is not biased towards a particular implementation of the Media Gateway. Cuervo, Gibbs expires May 1999 [Page 1] INTERNET DRAFT November 1998 Table of Contents 1.0 Introduction 2.0 Principles of Operation and Functional Blocks 2.1 Scope of the model: One Model "fits most" 2.2 Use of the Functional Model 2.3 Functional Model and MG architecture 3.0 Detailed description of functional blocks 3.1 Endpoints 3.1.1 Media unit processing 3.1.2 Endpoint Associated Signalling 3.1.3 Other endpoint operations 3.1.4 Programmability 3.1.5 Resource State and Allocation 3.2 Connection Module 3.3 Internal Devices 3.4 Association Module 3.5 Signalling Agent 4.0 Functional Model Diagram 5.0 Application Programming Interface 5.1 Endpoint interfaces 5.2 Connection Module Interfaces 5.3 Internal Devices Interfaces 5.4 Association Module interfaces 5.5 Programming Module interfaces 5.6 Signalling Backhaul Module interfaces 6.0 References 1.0 Introduction This document presents a functional model of a Media Gateway. The model extends the functional model of the base architecture draft[1]. The model identifies the functions that the MG may expose to other functions of the architecture, namely, the Media Gateway Controller and the Signalling Gateway [1]. A Media Gateway hosts "endpoints" and "internal devices". Endpoints are, for instance, DS0's, ATM VCs and RTP ports. Endpoints exist in physical devices that connect the gateway to an access or transport network(e.g., SS7 trunk cards, ATM-Cards, ethernet cards, etc.). Devices, such as, IVR units, bridges, etc. could be classified as internal devices. Under the control of a Media Gateway Controller, the Media Gateway realises a "connection" between ANY two endpoints, possibly involving some internal devices. 2.0 Principles of Operation and Functional Blocks Cuervo, Gibbs expires May 1999 [Page 2] INTERNET DRAFT November 1998 A Media Gateway Controller (MC) instructs an MG to set up a connection between two of its endpoints (i.e., create an MG- connection). Although media conversion is the essence of the MG it is not necessary for every MG-connection to involve media conversion; an MG-connection may join two endpoints of the same type. The required media conversion depends on the media type supported by the endpoints. This apparently "simple mode of operation" is in practice more complex since, for instance: * certain types of endpoints have associated signalling capabilities (e.g., DTMF), * some endpoints perform maintenance functions (e.g., continuity tests), * the MC needs to know the state changes of endpoints (e.g., a trunk group going out of service), * the MG retains some control over the allocation and control of some endpoint resources (e.g., RTP port numbers). MGs may contain other resources that participate in the handling of a call (e.g., transcoders, conference bridges) or devices for inserting content into media streams (e.g., via IVR units), these resources are named "internal devices". MGs must also support system level functions, such as, establishing and maintaining associations to MCs, these functions are essential for MC redundancy and fail- over scenarios. Therefore, a MG is modelled by the following functional blocks: 1 endpoints: which are controllable and configurable in order to support a diversity of media conversion, maintenance and associated signalling functions. Endpoints are assumed to maintain their own state and, in some cases, manage their own resource name-space (e.g., available RTP ports or any other form of virtual endpoint). 2 internal devices: these resources provide services such as transcoding, conferencing, IVR units. 3 connection module: sets, deletes, modifies MG-connections, keeps MG- connection state. Endpoints and/or internal devices are connected by the connection module. 4 association module: handles association of the MG to its MCs. 5 signalling agent[1]: An SA realises a signalling mediation function within the IP network, for instance, MG-to-MG, MG-to- MC. Examples of SAs are SAs for user signalling and SAs for Cuervo, Gibbs expires May 1999 [Page 3] INTERNET DRAFT November 1998 intergateway trunks (ATM case). 2.1 Scope of the model: One Model "fits most" The term MG can denote several "classes" of network elements. The functional model should fit the wide range of applications of an MG. The examples below show that for different classes of MG, some functions will be more prominent than others, and in some cases functional blocks may even disappear. Let us consider two fairly different roles that an MG may assume: * a trunking gateway: services carried on telephone network SS7- trunks(e.g., voice, fax, data access) are transformed at the MG for carriage over a packet or cell network. * a residential gateway: the MG is an end-user CPE device, such as a cable modem. In the first example, the MG may host thousands of endpoints. We may also assume the endpoints will not have associated signalling capabilities (i.e., the SS7 signalling is directly handled by a Signalling Gateway). In a simple manner, the role of the MC is to configure, for instance, the "ingress-endpoint" to adapt to the service (i.e., voice, fax), to resolve the "egress-endpoint" and, consequently, set up the MG-connections. In the second example, the MG just hosts a few endpoints. The MC is concerned with the signalling associated to the endpoint (detecting on/off-hooks and collecting digits). Other functions such as realising the MG-connections may be performed with preprovisioned information. Endpoint maintenance and status may also be performed according to a simpler model (i.e., the MC may just need to know that the phone is off-hook). 2.2 Use of the Functional Model The Functional Model is a tool for specifying the semantics of the protocols used between the MC and MG (to be captured in 6.0). Different choices of protocol syntax and transport may result from, for instance, scalability, or networking constraints of a particular implementation. Nevertheless, at least one complete protocol specification is required to demonstrate that a "generally-agreed- upon" technology solution to the realisation of the API exists. By refining the MG into smaller functions it is easier to assess Cuervo, Gibbs expires May 1999 [Page 4] INTERNET DRAFT November 1998 whether a proposed protocol for MG control has the extensibility and modularity attributes that are required due to the wide range of applications of the MG. 2.3 Functional Model and MG architecture MGs can be architected in many different ways depending where the media conversions and transcoding (if required) are performed, the level of programmability of endpoints, how conferences are supported, and how associated signalling is treated. The functional model must not be biased towards a particular architecture. 3.0 Description of functional blocks The following sections refine each one of the functional blocks. 3.1 Endpoints There are different levels of abstraction for endpoints. For instance, an ATM endpoint may be specifically defined as physical port w, VPI x, VCI y or it may be abstracted as VCC identifier n. If that VCC were realised as an SVC and that VCC failed (for whatever reason) it could be re-instated on a different port/VPI/VCI (using UNI/PNNI) while retaining the same VCC identifier (n). Such behaviour could be automatic on the part of the MG and would not need intervention on part of controller to sort out network level changes. In a similar manner, one would not expect MC to control an IP gateway to explicitly route calls a particular way - one would leave this to local routing functions on the MG. The most critical functions of a MG take place in the endpoints: 1. media unit processing 2. associated signalling handling 3. maintenance 4. programmability 5. resource state and allocation. 3.1.1 Media unit processing Endpoints are viewed from "black box producer/consumer" perspective: "this endpoint produces/consumes complete packets with samples of size x, using compression algorithm y". This view does not indicate where in the MG the media conversion takes place. Examples of endpoint descriptions are: * EP1: a DS0 with a-µlaw, 3dB rx pads, echo canceller Cuervo, Gibbs expires May 1999 [Page 5] INTERNET DRAFT November 1998 on/off/controlled by tone reception, CAS functionality, etc. * EP2: a particular CID, in a particular VCC (or trunk group) using G.726/32kbps, silence suppression on, comfort tones off, fax demodulation disabled etc. From the EP1 and EP2 descriptions the MG would be able to infer the required media conversion and transcoding. In order to produce a complete media unit it might be necessary that the endpoint be provided with additional information, such as, "remote-endpoint information" (e.g., remote MG IP address and RTP port, AESA of remote MG). 3.1.2 Endpoint Associated Signalling Endpoints may have "endpoint associated signalling" (EAS). Examples of endpoints with EAS are PRI, MF trunks, SS7 trunks with associated signalling, DTMF, ATM Trunks, etc. There are two ways in which EAS can be handled: * signalling "backhaul": signalling is sent outside the MG for off-board processing. Signalling is assumed to be tunnelled by the Signalling Agent to another functional entity in the architecture. This is outside the scope of the MC-MG protocol. * signalling at the endpoint: the endpoint has (natively or through programming) signalling capabilities. For CAS/DTMF some signalling information must be carried between the MC and MG whether or not the MG interprets the call state. An endpoint with CAS/DTMF must report to the MC "signalling states" that the MC is interested in knowing. This can be done to any level of granularity, every single event could be reported by the endpoint, or a large number of events could be preprocessed before the MC needs to be notified. The MC may also indicate to the endpoint to perform actions (e.g., apply ringing, collect digits, accumulating and discarding events). An endpoint that terminates signalling makes easier for the MG to take on more functionality. For instance, an MG may select ATM trunks based on local information and policies. When the trunk is selected, the MG only needs to report the selected trunk to the MC. 3.1.3 Other endpoint operations Endpoints can also perform operations such as loopbacks or continuity tests. This can be stand alone maintenance operations or part of the EAS. It must be possible to make maintenance operations independent of other endpoint functions, for instance, some maintenance states should not affect the resources associated with the endpoint. 3.1.4 Programmability Cuervo, Gibbs expires May 1999 [Page 6] INTERNET DRAFT November 1998 Programmability is also used in a broad sense, it does not imply only the capability to download code into a device, but includes other means such as passing a URL, supplying parameters to an already loaded function, obtaining parameters from a profile or providing a digit-map [2], initiating a Daemon Interface [3]. Endpoints can be programmed for several reasons, programming an endpoint might be related to EAS handling, media conversion, local bandwidth management or maintenance functions. Programming may also fulfill functional requirements and architecture scalability. For instance, being able to program TDM interfaces to recognise fax modulation, data or voice is a functional requirement. Being able to accumulate signalling events or collect strings of digits is a scalability consideration. 3.1.5 Resource State and Allocation Endpoints keep and report their state upon request of the MC, they may also offer an interface for the MC to alter their state. Endpoints could be referred to through an appropriate naming schema (the endpoint name-space). For instance, endpoints may be assumed addressable either individually or in groups according to a hierarchical organisation within a physical interface. Allocation of values from the endpoint name-space could be either the responsibility of the MC or of the endpoint itself. 3.2 Connection Module An instance of the Connection module realises and tracks connections inside the MG (MG-connections). The connection module assigns connectionIds, manages its own name space, and reports on connection performance, QoS, etc. MG-connections may occur between any number and type of endpoints: * If the endpoints in a connection produce/consume the same types of media units or streams then the MG simply operates as a switch. * If the endpoints have dissimilar media units or streams then the MG must provide the appropriate media conversion functions, however, no assumption is made about where or how the media conversion is performed. MG-Connections are in general independent of the functions and state of the endpoints that they connect. Specific behaviours may be added to the connections, for instance, to delete a connection if an endpoint is put in maintenance state or goes out of service. Cuervo, Gibbs expires May 1999 [Page 7] INTERNET DRAFT November 1998 3.3 Internal Devices An MG-Connection may require resources for 3-way connection, transcoding or announcements. These resources are named "internal devices" if they are explicitly controlled by the MC. Internal devices are in many ways similar to endpoints. They may be programmable and interwork with other internal devices and endpoints via MG-connections. For that purpose, internal devices are modelled to have "virtual endpoints" (e.g., a bridge for 3-way call has 3 virtual endpoints). It is not necessary for an MG to be modelled as having internal devices, for instance, conference and announcement capabilities could be directly associated with and end point[2]. However, the more general approach of having a separate functional block should be preferred since it does not preclude implementations in which it is necessary to address other resources in the MG besides endpoints. Other models for internal devices might be possible. 3.4 Association Module The purpose of the Association Module is to establish and maintain a MC-MG association. This includes notifications regarding network element restart or reboots, detecting silent failures, enforcing flow control policies and handling fail-over scenarios. 3.5 Signalling Agent The signalling agent performs functions that relate to handling EAS. The most likely function is to tunnel signalling for a group of endpoints to another device. The signalling agent may also process signalling and therefore receive instructions for processing and notifying an MC of signalling events. There is a need to discuss whether the SA could be replaced by a more general definition of the SG. 4.0 Functional Model Diagram The figure below shows the complete functional model, which includes the functional blocks identified in section 2.0 and an additional block for programming functionality of both endpoints and internal devices. +---MG---------------------------------------------------------+ | | | +--------------------+ +--------------------+ | | | | | | | Cuervo, Gibbs expires May 1999 [Page 8] INTERNET DRAFT November 1998 | | programming | | association module | | | | | | | | | | | | | | | +--------------------+ +--------------------+ | | | | | +--------------------------------+ | | | | | | +--------------------+ +--------------------+ | | | | | | | | | endpoints | | internal devices | | | | | | | | | | | | | | | +---+----------------+ +--------------------+ | | | | | | | | | +--------------------+ | | | +-----+---+ | | | | | | | Sig | +-----| Connection |----+ | | |Agent[SA]| | Module | | | | | | | | | +---------+ | | | | +--------------------+ | | | +--------------------------------------------------------------+ Figure 1: Functional Model of a Media Gateway 5.0 Application Programming Interface This section lists the interfaces offered by each module. 5.1 Endpoint interfaces SetEndpointParameters(endpointId, parameterList | profileIdentifier ) ResetEndpoint(endpointId) [status, parameterList, connectionList] <-- EndpointAudit(endpointIdList, RequestedInfo) NotifyRequest(endpointId, eventDescriptor) 5.2 Connection Module Interfaces connectionId <-- CreateConnection(endpoint_list{endpoint1,endpoint2,...}, QoS) Cuervo, Gibbs expires May 1999 [Page 9] INTERNET DRAFT November 1998 DeleteConnection(connectionId | endpointId) ModifyConnection(connectionId, endpoint+, endpoint-,endpoint-swap, QoS) ReportConnections(endpointId) AuditConnection(connectionId) 5.3 Internal Devices Interfaces ResetIntDevice(deviceId) IntDeviceStatus(deviceId) EndpointId <-- GetEndpoint(deviceId) ReleaseEndpoint(deviceId, endpointId) 5.4 Association Module interfaces DefineEndpoint(EndpointId, ProtocolId) advertises that an endpoint is reachable over a particular TCP connection or protocol multiplexer InitiateAssociation/TerminateAssociation(MG_Id, MC_Id) Reboot(MG_Id, cause) FlowControl(MC_Id, messageRate, gap) Audit/Config(MG_Id) 5.5 Programming Module interfaces DownloadCode(MG_Id, codeFileName) BindCode(endpointId | deviceId, codeName) BindProfile(endpointId | deviceId, profileIdentifier) RemoteInvocation(endpointId | deviceId, procedure) 5.6 Signalling Backhaul Module interfaces EnableBackhaul(endpointId, SA_Id) Cuervo, Gibbs expires May 1999 [Page 10] INTERNET DRAFT November 1998 ModifyBackhaul(endpointId, SA_Id) DisableBackhaul_to(endpointId, SA_Id) 6.0 References [1] Cuervo, Greene, Holdrege, Ong, Huitema, "SS7-Internet Interworking - Architectural Framework", Internet-Draft, , July 1998. [2] Arango, Dugan, Elliot, Huitema, Pickett, "Media Gateway Control Protocol (MGCP) ", Internet-Draft, , October 1998. [3] Janssen, Frystyk Nielsen, Spreitzer, "HTTP-ng Architectural Model", Internet-Draft, , August 1998. Cuervo, Gibbs expires May 1999 [Page 11]