MEGACO Working Group Matt Holdrege (Liaison) Internet Draft Multiservice Switching Forum February 1999 Media Control Group Multiservice Switching Forum requirements input to MEGACO Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works. 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). Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document serves as input into the IETF MEGACO requirements process. It includes requirements as input by MSF members and refined by the MSF Media Control group. Disclaimer: This is a representation of the preliminary requirements generated by the Multiservice Switching Forum/Media Control Working Group. This document has been approved by the Working Group for liaison distribution to the IETF. However, this document in no way binds any of the member organizations to the ideas presented. It should also be noted that this work is incomplete and a draft. It is being submitted now to meet the MEGACO WG timelines. The MSF will revisit this work in the future and may add, change or delete its requirements. Holdrege [Page 1] I-D MSF requirements input to MEGACO February 1999 Introduction The Multiservice Switching Forum (http://www.msforum.org) has the following mission: To define... (1) an architecture that separates the control and user/data plane aspects of an ATM-capable Multiservice Switching System and establishes a framework which can be easily extended to support new user/data plane and control functions. (2) a set of open intra-switch interfaces and promote implementation agreements for these interfaces that allow service providers to deploy ATM-capable Multiservice Switching Systems composed of best- of-breed components from multiple vendors. These requirements are for narrow-band call control over packet/cell networks. In the future, other multimedia requirements may be defined. These requirements address connection establishment and tear-down, together with such parameters associated with those calls to be used for call accounting, call QoS monitoring etc. Furthermore these requirements address such management information as to allow a Media Gateway Controller to identify available resources. These are not stand-alone requirements, but instead addititive to draft-ietf- megaco-reqs-01.txt It is assumed that the protocol that these requirements address will not be a general purpose management protocol. Connectivity Requirements Connect: The Protocol shall support requests for multi-media connections from circuit to packet for IP and vice versa Connect: The Protocol shall support requests for multi-media connections from circuit to packet for ATM and vice versa. Connect: The Protocol shall support requests for multi-media connections from circuit to packet for FR and vice versa. Connect: The Protocol shall support requests for connections of circuit to circuit. Connect: The Protocol shall support requests for multi-media connections from all packet to packet combinations for IP, ATM and FR Connect: The protocol shall allow the specification of bearer plane on a call by call basis since a MG may support more than one bearer plane e.g Frame Relay, IP, etc. Connect: The Protocol shall allow for the de-coupling of creation/deletion of the narrow-band connection from the creation/deletion of the underlying VCC. Connect: The Protocol shall allow connections to be added/removed to/from a call during the call. Connect: The protocol shall allow for efficient disconnection of all connections associated with a physical port or VCC. As an example, this could aggregate disconnections across a broadband circuit which experienced a physical error. The narrow-band connection established using this Protocol, may be carried over a VCC, which may be a: * PVC or SPVC, * an SVC established on demand, either by the MGC itself or by a broker acting on its behalf or * an SVC originated as required by the local MG, or by the remote end to the local MG through UNI or PNNI signalling. Connect: The protocol shall be able to refer to an existing VCC as The physical interface + Virtual Path Identifier (VPI) + Virtual Circuit Identifier (VCI). Where the VCC is locally established (SVCs signalled by the Gateway through UNI or PNNI signalling or similar), the VCC must be indirectly referred to in terms which are of significance to both ends of the VCC. i.e. a global name or the ATM address of the ATM devices at each end of the VCC. However, it is possible/ probable that there may be several VCCs between a given pair of ATM devices. Therefore the ATM address pair must be further resolved by a VCC identifier unambiguous within the context of the ATM address pair. Connect: The Protocol shall be able to refer to a VCC as the Remote GW ATM End System Address + VCCI. Connect: The Protocol shall allow the VCCI to be selected by the MG or imposed on the MG. Connect: All ATM addressing variants (e.g.NSAP & E.164) SHALL be supported within the Protocol. Connect: The protocol SHALL allow ATM transport parameters and Quality of Service parameters to be passed to the MG. Connect: Where a VCC is required to be established on a per narrow- band call basis, the Protocol SHOULD allow all necessary information to be passed in 1 message. Connect: The protocol shall allow for the MG to report cause codes for success or failure of the lower layer connection setup. Connect: The protocol shall allow for the MG to report cause codes for abnormal failure of lower layer connections e.g. TDM circuit failure, ATM VCC failure. Connect: The protocol shall allow for the MG to report Usage Parameter Control (UPC) events. Adaptation The Protocol shall allow the possible adaptations of an ATM capable Gateway: Adapt: The protocol shall allow for Media adaptation for circuit to ATM connections (e.g. analog loop to G.729/AAL2/ATM) Adapt: The protocol shall allow for Media trans-adaptation for packet-to-ATM or ATM-ATM connections (e.g. G.723/RTP/UDP/IP to G.726/AAL2/ATM) Adapt: The protocol shall allow for ATM trans-adaptation only (no media adaptation) e.g. for switching voice streams between IP and AAL2/ATM or between AAL2/ATM links. Adapt: The protocol shall allow AAL parameters to be passed to the MG. AAL2 In AAL2 multiple narrow-band calls may be mapped to a single VCC. These calls are differentiated within each VCC by a AAL2 channel identifier. An AAL2 connection may span more than 1 VCC and transit AAL2 switching devices. ATMF standards are working on an end-to-end AAL2 connection identifier as part of the AAL2 signalling set. Adapt: The Protocol SHALL allow for unambiguous binding of a narrow band call to an AAL2 connection identifier within the specified VCC. Adapt: The Protocol SHALL allow the AAL2 connection identifier to be selected by the MG or imposed on the MG Adapt: The Protocol SHOULD allow AAL2 channel identifier (cid) instead of AAL2 connection identifier Adapt: The protocol shall allow for the AAL2 voice profile to be imposed or negotiated before the start of the connection. AAL2 allows for variable length packets and varying packet rates, with multiple codecs possible within a given profile. Thus a given call may upgrade or downgrade the codec within the lifetime of the call. Idle channels may generate zero bandwidth. Thus an AAL2 VCC may vary in bandwidth and possibly exceed its contract. Congestion controls within a gateway may react to congestion by modifying codec rates/types. Adapt: The Protocol shall allow for the MGC to instruct the MG of how individual narrow-band calls behave under congestion. AAL5 We have no contribution on this point. Reporting Report: The protocol shall allow for the MGC to gain accounting capabilities from the MG via polling or registration. Accounting information may be passed via the control protocol, or by some other means. The Protocol should specify what is included and when it is reported. Report: The Protocol shall allow for the following accounting parameters to be transported from the MG to the MGC: Bandwidth/QoS requested and received Absolute time of connection startup and teardown Types of resources used such as echo cancellers, codecs, receivers, silence suppression, etc. and the duration of utilization of these resources Packet/Cell count including dropped packets/cells during phase. Report: The Protocol shall allow for any accounting parameters shall be passed to the MGC as required by the MGC. This may include: At the end of a call When polled by the MGC At time intervals as specified by the MGC At unit usage thresholds as specified by the MGC Report: The protocol SHOULD allow any end-of-call statistics to show loss/restoration of underlying VCC within the calls duration, together with duration of loss. Report: The protocol SHOULD allow notification, as requested by MGC, of any congestion avoidance actionstaken by the MG. ATM VCCs may be considered as resources under the control of the MGC. Report: The Protocol shall allow for ATM VCCs to be audited by the MGC. Report: The Protocol shall allow for changes in status of ATM VCCs to be notified as requested by the MGC. Report: The protocol shall allow the MGC to query the resource & endpoint availability. Resources may include VCC's, & DSP's. VCCs may be up or down. Endpoints may be connection-free, connected or unavailable. Functionality: Function: The protocol shall allow a command precedence to allow priority messages to supercede non-priority messages. Function: The protocol shall allow an MGC to reserve a bearer, and specify a route for it through the network. Report: The protocol shall allow for the MG to detect and notify as required events in the audio stream. e.g., voice/silence detection. Report: The protocol shall allow the request and notification of mid-call trigger events. Function: The protocol shall transport audio normalization levels as a setup parameter. E.g conference bridging. Function: The protocol call setup shall allow for a priority marking to flag a given connection as having a higher priority. Function: The protocol shall allow user configurable extensions/profiles/attributes. Function: The Protocol shall allow the recovery or redistribution of traffic without call/packet loss. Quality of Service: QoS: The protocol shall allow the MGC to specify QoS thresholds, and the MG to notify the MGC of threshold crossing events.. QoS: The protocol shall allow the MGC to modify QoS parameters after the connection is established. Author's Address Matt Holdrege Ascend Communications 1701 Harbor Bay Parkway Alameda, CA 94502 USA matt@ascend.com