[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

MEGACO Working Group                            Matt Holdrege (Liaison)
Internet Draft                             Multiservice Switching Forum
April 1999                                          Media Control Group

       Multiservice Switching Forum requirements input to MEGACO
                  <draft-ietf-megaco-msf-reqs-01.txt>

Status of this Memo


        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

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.

Introduction



Holdrege                                                        [Page 1]

I-D                MSF requirements input to MEGACO           April 1999


    The Multiservice Switching Forum (http://www.msforum.org) has the
    following mission:

    (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.



Holdrege                                                        [Page 2]

I-D                MSF requirements input to MEGACO           April 1999


    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




Holdrege                                                        [Page 3]

I-D                MSF requirements input to MEGACO           April 1999


    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



Holdrege                                                        [Page 4]

I-D                MSF requirements input to MEGACO           April 1999


    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



Holdrege                                                        [Page 5]
I-D                MSF requirements input to MEGACO           April 1999


    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


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/