H.GCP and Megaco
Roni Even
Roni_e at ACCORD.CO.IL
Sun Mar 28 12:39:19 EST 1999
Attached are two notes giving the outcome of a review of requirements at the
Megaco meeting two weeks ago. I'm sorry I didn't sent this material out to
the SG 16 list earlier. I also attach a set of ATM-related requirements
which the Multi-Service Switching Forum (MSF) provided to Megaco.
It's important that we determine whether Q. 14/16 and Megaco have the same
view of requirements. I've asked Glen Freundlich for time to probe the
issue on tomorrow's H.GCP conference call. The dialogue can continue by
E-mail. In the end, I hope we can determine a core set of requirements
agreed by both groups, plus, if necessary, additional separately-documented
requirements which are specific to one group or the other.
<<Megaco Requirements>> <<Requirements Part II>>
<<draft-ietf-megaco-msf-reqs-00.txt>>
Tom Taylor
E-mail: taylor at nortelnetworks.com (internally Tom-PT Taylor)
Tel.: +1 613 765 4167 (internally 395-4167)
This is frequently forwarded to my residence.
-------------- next part --------------
An embedded message was scrubbed...
From: "Taylor, Tom-PT [CAR:5V00-I:EXCH]" <taylor at americasm01.nt.com>
Subject: Megaco Requirements
Date: Tue, 16 Mar 1999 23:31:27 -0600
Size: 8225
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19990328/48e8abfa/attachment-0002.eml>
-------------- next part --------------
An embedded message was scrubbed...
From: "Taylor, Tom-PT [CAR:5V00-I:EXCH]" <taylor at americasm01.nt.com>
Subject: Requirements Part II
Date: Tue, 16 Mar 1999 23:38:20 -0600
Size: 7479
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19990328/48e8abfa/attachment-0003.eml>
-------------- next part --------------
MEGACO Working Group Matt Holdrege (Liaison)
Internet Draft Multiservice Switching Forum
February 1999 Media Control Group
Multiservice Switching Forum requirements input to MEGACO
<draft-ietf-megaco-msf-reqs-00.txt>
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 at ascend.com
More information about the sg16-avd
mailing list