Internet DRAFT - draft-cuervo-navdec-mg-arch
draft-cuervo-navdec-mg-arch
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
<draft-cuervo-navdec-mg-arch-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 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, <draft-
greene-ss7-arch-frame-01.txt>, July 1998.
[2] Arango, Dugan, Elliot, Huitema, Pickett, "Media Gateway Control
Protocol (MGCP) ", Internet-Draft, <draft-Huitema-MGCP-v0r1-
00.txt>, October 1998.
[3] Janssen, Frystyk Nielsen, Spreitzer, "HTTP-ng Architectural
Model", Internet-Draft, <draft-frystyk-httpng-arch-00.txt>,
August 1998.
Cuervo, Gibbs expires May 1999 [Page 11]
