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

Versions: 00 01

   <Working Group Name>                                  A. Kankkunen
   Internet Draft                                     Integral Access
   Document: <draft-kankkunen-vompls-fw-01.txt>
                                                               G. Ash
                                                                 AT&T

                                                              A. Chiu
                                                                 AT&T

                                                           J. Hopkins
                                                                Cisco

                                                          J. Jeffords
                                                      Integral Access

                                                       F. Le Faucheur
                                                                Cisco

                                                             B. Rosen
                                                              Marconi

                                                            D. Stacey
                                                      Nortel Networks

                                                          A. Yelundur
                                                                  NEC

                                                            L. Berger
                                                      LabN Consulting


                        VoIP over MPLS Framework

                    draft-kankkunen-vompls-fw-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 [1].

   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


 Kankkunen et al.        Expires January 2001                 [Page 1]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




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


Abstract

   This document provides a Framework for using MPLS as one
   underlying technology alternative for transporting VoIP based
   public voice services.

   The document defines a reference model for VoIP over MPLS, defines
   some specific applications for VoIP over MPLS and identifies
   potential further standardization work that is necessary to
   support these applications. The annexes of the document discuss
   the types of requirements that voice services set on the under
   laying transport infrastructure.

   Editor's Note:

   This document is an early and incomplete version.  It is being
   published to facilitate discussion prior to the Pittsburgh IETF.
   It is expected that the draft will need to be revised and expanded
   based on the results of the discussion.

   Discussion related to this document will take place on the
   vompls@lists.integralaccess.com mailing list.  To subscribe send
   mail to vompls-request@lists.integralaccess.com with "subscribe"
   in the message body.  An archive is available at
   http://sonic.sparklist.com/scripts/lyris.pl?enter=vompls.


Table of Contents

   1.        Abbreviations and Acronyms..............................4
   2.        Introduction............................................5
   2.1.      Background and motivation...............................7
   2.2.      Brief Introduction to MPLS..............................7
   3.        VoMPLS Reference Model..................................8
   3.1.      Reference Model Components and their roles..............8
   3.1.1.    Call Agent.............................................11
   3.1.1.1.  Media Gateway Connection Control.......................11
   3.1.1.2.  Call processing........................................12
   3.1.1.3.  Management.............................................12
   3.1.2.    Media Gateways.........................................12
   3.1.3.    Media Inter-Working Function...........................13
   3.1.4.    Signaling Gateway......................................14
   3.1.5.    Signaling Inter-Working Function.......................14
   3.1.6.    Trunk Gateway..........................................15

Kankkunen et al.         Expires January 2001                 [Page 2]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   3.1.7.    Access Gateway.........................................15
   3.1.8.    Line Side Gateway......................................15
   3.1.9.    Integrated Access Device...............................15
   3.1.10.   Voice Terminals........................................15
   3.1.11.   VoMPLS Media Gateway...................................16
   3.1.12.   VoMPLS Signaling Gateway...............................16
   3.2.      Data Plane.............................................16
   3.3.      Control Plane..........................................17
   3.3.1.    Concept of IP QoS Bearer Control.......................18
   3.3.2.    Advertisement/Negotiation of Traffic Parameters and IP
             QoS Bearer Control requirement in Call Control.........18
   3.3.3.    Signaling for IP QoS Bearer Control Establishment......19
   3.3.3.1.  Scaling IP QoS Bearer Control with RSVP................21
   3.3.4.    Coordination between Call Control and IP QoS Bearer
             Control................................................22
   3.3.5.    Policy Based Control of VoMPLS Network Elements........23
   3.3.6.    Bearer Control for VoMPLS..............................23
   3.3.6.1.  Concept of VoMPLS Bearer Control.......................23
   3.3.6.2.  VoMPLS Bearer Control for Connectivity.................24
   3.3.6.3.  VoMPLS Bearer Control for QoS and Resource Reservation.24
   3.3.6.4.  VoMPLS Bearer Control for Compression/Multiplexing.....24
   3.3.7.    Aggregated MPLS Processing in the Core.................25
   4.        VoMPLS Applications....................................27
   4.1.      Trunking Between Gateways..............................27
   4.1.1.    Encapsulation Requirements for Efficient Multiplexed
             Trunk..................................................27
   4.2.      VoMPLS on Slow Links...................................27
   4.3.      Voice Traffic Engineering using MPLS...................28
   4.3.1.    Off-Line Voice traffic engineering Aspects.............28
   4.3.2.    Connection Admission and/or Connection Routing.........29
   4.3.3.    Dynamic Traffic Management.............................30
   4.4.      Providing End-to-end QoS for Voice Using MPLS..........30
   5.        Requirements for MPLS Signaling........................32
   5.1.      LDP and CR-LDP.........................................32
   5.2.      RSVP-TE................................................33
   6.        Requirements for Other Work............................33
   7.        Security Considerations................................33
   8.        Acknowledgements.......................................33
   9.        References.............................................33
   10.       Author's Addresses.....................................36
   ANNEX A - E-Model analysis of the VoIP over MPLS Reference Model.38
   A.1 Introduction.................................................38
   A.2 Deployment of VoMPLS within the Core Network.................39
   A.2.1 Scenario 1 - Effect of Multiple MPLS Domains...............39
   A.2.2 Scenario 2 - Analysis of VoMPLS and Typical DCME Practice..40
   A.2.3 Scenario 3 - Analysis of GSM, VoMPLS and Typical DCME
             Practice...............................................41
   A.2.4 VoMPLS Core Network Summary................................43

Kankkunen et al.         Expires January 2001                 [Page 3]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   A.3 Extending VoMPLS into the Access Network.....................43
   A.3.1 Scenario 4 - VoMPLS Access on USA to Japan.................43
   A.3.2 Scenario 5 Deployment of GSM and VoMPLS Access.............45
   A.3.3 VoMPLS Access Summary......................................45
   A.4 Effects of Voice Codecs in  the access network...............46
   A.4.1 Scenario 6 - Deployment of Codecs in one Access Leg (USA -
             Japan).................................................46
   A.4.2 Scenario 7 - Codec Deployment in both Access Legs (USA -
             Japan).................................................47
   A.4.3 Scenario 8 Codec Deployment and Mobile Access (USA -
             Australia).............................................47
   A.4.4 Voice Codec Summary........................................48
   A.5 Overall Conclusions..........................................48
   B.1 Voice Service Requirements...................................50
   B.1.1 Voice Encoding.............................................50
   B.1.2 Control of Echo............................................51
   B.1.2.1 Echo Control by Limiting Delay...........................51
   B.1.2.2 Echo Control by Deploying Echo Cancellers................51
   B.1.2.3 Network Architecture implications........................52
   B.1.3 End-to-end Delay and Delay Variation.......................53
   B.1.4 Packet Loss Ratio..........................................54
   B.1.5 Timing Accuracy............................................54
   B.1.6 Grade-of-service...........................................56
   B.1.7 Quality considerations pertaining to Session Management....57


1. Abbreviations and Acronyms

          AG             Access Gateway
          CA             Call Agent
          DS1            Digital Signal 1
          E1             2048kbit/s signal possibly with G.704
                         framing
          FIB            Forwarding Information Base
          IAD            Integrated Access Device
          ID             Internet Draft
          IP             Internet Protocol
          LSG            Line Side Gateway
          LSP            Label Switched Path
          MegacoP        Media Gateway Control Protocol (Different
                         than MGCP)
          MG             Media Gateway
          MGC            Media Gateway Controller
          MGCP           Media Gateway Control Protocol (Different
                         than MegacoP)
          MIWF           Media Inter Working Function
          MPLS           Multi Protocol Label Switching
          PABX           Private Automatic Branch Exchange

Kankkunen et al.         Expires January 2001                 [Page 4]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




          PDP            Policy Decision Point
          PSTN           Public Switched Telephone Network
          SG             Signaling Gateway
          SIP            Session Initiation Protocol
          SIWF           Signaling Inter Working Function
          SLA            Service Level Agreement
          SS7            Signaling System 7
          TBD            To Be Defined
          TDM            Time Division Multiplexing
          TG             Trunk Gateway
          VF             Voice Frequency
          VoIP           Voice over IP
          VoMPLS         VoIP over MPLS

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC-2119 [2].

2. Introduction

   The purpose of this draft is to provide a common reference point
   for the operation of voice over IP where MPLS is used in part or
   all of the IP network, and to identify any needed related
   standardization work.

   The voice encapsulation used in VoMPLS (In this document we refer
   to "VoIP over MPLS" as "VoMPLS") is voice/RTP/UDP/IP/MPLS. Header
   compression techniques can be used for making the transport of
   RTP/UDP/IP headers more efficient. Thus, VoIP over MPLS does not
   mean that the RTP/UPD/IP headers MUST be physically transmitted.
   The headers can be compressed, but must be "reconstructible" at
   the egress of the MPLS cloud. Such header compression has been
   adopted as a work item in the MPLS WG. (MPLS WG charter: "11.
   Specify standard protocols and procedures to enable header
   compression across a single link as well as across an LSP.")
   Possible header compression mechanisms are defined in [20, 8].

   The purpose of the header compression is to define a way to create
   LSPs that carry voice efficiently.  The basic format of packets in
   the LSP should be a compressed header form of IP/UDP/RTP, with
   trivial conversion to and from real IP/UDP/RTP.  Voice LSPs should
   optionally support multiplexing within the LSP (multiple channels
   per LSP), which should be a minor extension to this compressed
   header.

   LSPs should be able to be created with a constrained delay


Kankkunen et al.         Expires January 2001                 [Page 5]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   characteristic. Two different alternatives for providing this kind
   of QoS are presented.

   - One solution is to rely on IP QoS end-to-end. Where IP is
     transported over MPLS, the IP QoS is mapped to the MPLS QoS and
     MPLS features such as Traffic Engineering can be used over the
     MPLS cloud.

   - A second scenario is one where MPLS is used in both the access
     and collector portion of the network as well as the core. Under
     this scenario a QoS control mechanism that is MPLS aware is
     advantageous, utilizing MPLS TE to establish an optimal route
     across multiple (alternate) MPLS LSPs.

   One purpose of this effort is to enable Session Switched Services
   from IP terminals which achieve the same QoS characteristics for
   real-time media as is currently available on ISDN and B-ISDN
   networks.

   This draft consists of three main sections:  VoMPLS Reference
   Model (In this document we refer to "VoIP over MPLS" as "VoMPLS"),
   VoMPLS Applications and Definition of the required VoMPLS
   standardization work.

   Section 3 defines a reference model for VoMPLS.

   Section 4 defines applications where MPLS can be the enabling
   technology for supporting voice in an IP-infrastructure.

   Sections 5 and 6 define the new VoMPLS related standardization
   that needs to take place in order to support the applications
   defined in Section 4 within the reference model of Section 3.

   This document identifies new application specific requirements
   that are not addressed by existing work. These requirements
   include the following:
   - Service types for carrying voice services over Packet Networks
     should be defined. (This is not an MPLS specific issue.)
   - Explicit quantitative guidelines each service type sets on the
     parameters described in Annex B should be defined.
   - Identify how the quantitative guidelines are mapped to MPLS LSPs
     in both diff-serv and non-diff-serv environments.
   - Mechanisms for using MPLS for providing GoS required by the
     various service types need to be defined.
   - The reduction of header overhead and the support of efficient
     multiplexing of multiple voice calls over a single LSP.
   - The reduction of header overhead and the support of multiplexing
     using link level techniques.

Kankkunen et al.         Expires January 2001                 [Page 6]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





2.1. Background and motivation

   MPLS is being introduced into IP networks to support Internet
   Traffic Engineering and other applications. The motivation for
   VoIP over MPLS is to take advantage of these new  network
   capabilities, in the parts of the network where they are
   available, to improve voice-over-IP service by:
     -  using label-switched-paths as a bearer capability for VoIP
        thereby providing more predictable, and even constrained QoS,
     -  providing a more efficient transport mechanism for VoIP
        possibly using header compression or suppression,
     -  leveraging other advantages of MPLS, e.g. Layer 2
        independence, integration with IP routing and addressing,
        etc.

2.2. Brief Introduction to MPLS

   MPLS (Multi Protocol Label Switching) is an emerging standard,
   that provides a link layer independent transport framework for IP.
   MPLS runs over ATM, Frame Relay, Ethernet and point-to-point
   packet mode links.

   MPLS based networks use existing IP-mechanisms for addressing of
   elements and for routing of traffic. MPLS adds connection oriented
   capabilities to the connectionless IP-architecture.

   For more information please see [6], [7], [16], [17] and [18].





















Kankkunen et al.         Expires January 2001                 [Page 7]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





3. VoMPLS Reference Model

   The traditional VoIP reference model is presented in Figure 1.

   +--+ +------------+   +--+   +---------------------+
   |CA|-|            |<--|TG|-->|                     |
   +--+ |            |   +--+   |                     |
        |            |          |                     |
        |   IP       |   +--+   |   Circuit-Switched  |
   +--+ |   Network  |<--|SG|-->|  Network (e.g. PSTN)|
   |CA|-|            |   +--+   |                     |
   +--+ |            |          |                     |
        +------------+          +---------------------+
               ^    ^    +---+              |
               |    |    |AG/|            +---+
               |    +--->|IAD|<---+       |LSG|
               |         +---+    |       +---+
               |                  |         |         MG=AG/IAD, LSG
               |                  |     +-------+        or TG
               |                  |     |IP     |
               |                  |     |Network|
               |                  |     +-------+
               |                  |         |
               |                  |       +---+
               |                  |       |AG/|
               |                  |       |IAD|
               |                  |       +---+
               |                  |         |
          IP Terminals          Conventional Terminals
   (e.g. Workstation-phone,   (e.g. PABX, Analog Phone, Key
            IP_PBX)           System, ISDN TE, VF modem, FAX)

                   Figure 1 Voice over IP Reference Model


3.1. Reference Model Components and their roles

   The model used for VoIP is the "decomposed gateway", which
   separates call control functions into an entity known as a Call
   Agent (CA), and a Media Gateway (MG), which has the bearer, or
   voice/packet stream handling.  Call Agents and a media gateway can
   be physically realized in a single device, or they may be separate
   devices that communicate to each other using suitable  protocols
   (Megaco/H.248 or MGCP for example).  The Media Gateway is a
   function that converts a voice (or other media stream such as
   video) into a packet stream.


Kankkunen et al.         Expires January 2001                 [Page 8]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   There are many types of media gateways (Trunk Gateway, Access
   Gateway, etc.), differentiated by the number and type of
   interfaces they have.  There are no "rules" for categorizing a
   particular media gateway into one type or another, but the
   following sections define the Call Agent and several different
   kinds of gateways for expository purposes.

   The VoMPLS reference model (Figure 2) refines the definition of a
   MG and a SG to include a PSTN to IP inter-working function and an
   IP to MPLS inter-working function.

   The PSTN to IP inter-working function is implemented by a Media
   Gateway (MG) for bearer connections and a Signaling Gateway
   (SG) for signaling connections as it is in the VoIP Reference
   Model.

   The IP to MPLS inter-working function is implemented with a
   separate functional element. The IP to MPLS inter-working Function
   for Media Gateways is called the Media Inter-Working Function
   (MIWF). The IP to MPLS inter-working function for Signaling
   Gateways is called the Signaling Inter-Working Function (SIWF).




























Kankkunen et al.         Expires January 2001                 [Page 9]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





      +--+ +------------+   +------+(*)+--+   +---------------------+
      |CA|-|            |<->| MIWF |<->|TG|<->|                     |
      +--+ |            |   +------+   +--+   |                     |
           |   IP/MPLS  |   +------+(#)+--+   |   Circuit-Switched  |
      +--+ |   Network  |<->| SIWF |<->|SG|<->|  Network (e.g. PSTN)|
      |CA|-|            |   +------+   +--+   |                     |
      +--+ |            |                     |                     |
           +------------+                     +---------------------+
                ^ ^            +---+            |
                | | +------+(*)|AG/|          +---+
                | +>| MIWF |<->|IAD|<-+       |LSG|
                |   +------+   +---+  |       +---+
                |                     |         | (*)
                |                     |       +----+
                |                     |       |MIWF|
                |                     |       +----+
                |                     |         |
                |                     |     +-------+
                |                     |     |IP/MPLS|
                |                     |     |Network|
                |                     |     +-------+
                |                     |         |
                |                     |       +----+
                |                     |       |MIWF|
                |                     |       +----+
                |                     |         | (*)
                |                     |       +---+
                |                     |       |AG/|
                |                     |       |IAD|
                |                     |       +---+
                |                     |         |
            IP Terminals          Conventional Terminals
    (e.g. Workstation-phone,   (e.g. PABX, Analog Phone, Key
             IP_PBX)           System, ISDN TE, VF modem, FAX)

                 Figure 2 VoIP over MPLS Reference Model












Kankkunen et al.         Expires January 2001                [Page 10]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





   (*) The MG (TG, AG/IAD, LSG) and MIWF may be:
   - implemented in the same physical device in the case of a VoMPLS
     GW (Figure 3).

        +-----------------+
        | VoMPLS GW       |
        | +------+   +--+ |
        | | MIWF |<->|MG| |
        | +------+   +--+ |
        +-----------------+

        Figure 3: VoMPLS Gateway


   - implemented as separate devices in the case of a VoIP GW. The MG
     and MIWF are then connected via an IP internetwork (Figure 4).

         +------+   +------+   +-------------+
         | MIWF |<->|IP Net|<->|MG (VoIP GW) |
         +------+   +------+   +-------------+

        Figure 4: VoIP Gateway

   (#) In the same way the SG and SIWF may be:
   - implemented in the same physical device in the case of a VoMPLS
     SG.
   - implemented as separate devices in the case of a VoIP SG. The SG
     and SIWF are then connected via an IP internetwork.

   The VoMPLS reference model covers, in particular, the following
   situations:
   - all Media GWs are connected to an MPLS cloud
   - Some Media GWs are connected to an MPLS Cloud while other Media
     GWs are connected to a non-MPLS IP cloud
   - Media GWs are connected to an IP cloud which uses MPLS somewhere
     in the core.

3.1.1. Call Agent

   Call Agents (CA), sometimes called "Media Gateway Controllers",
   provide among other things basic call and connection control
   capabilities for Voice over IP/MPLS networks. These capabilities
   include media gateway (Trunk Gateway, Access Gateway, etc.)
   connection control, call processing and related management
   functions.

3.1.1.1. Media Gateway Connection Control

Kankkunen et al.         Expires January 2001                [Page 11]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





   Media Gateway Connection control allows a Call Agent to modify the
   state of a media gateway's resources, e.g. to connect two end-
   points via a bearer connection, connect an access line to a tone
   generator, detect events such as user on-hook/off-hook detection,
   etc. There is a master-slave relationship between Call Agent and
   Media Gateway. Megaco/H.248 [9] and MGCP [10] are examples of
   protocols that enable a Call Agent to control a media gateway.

3.1.1.2. Call processing

   Call processing in a Call Agent provides call control functions.
   Call control determines how telephony calls are established,
   modified and released. There is a peer-to-peer relationship
   between Call processing entities, such as other Call Agents, PSTN
   switches or IP-telephony appliances. Q.1901 [13], H.323 [11] and
   SIP [12] are examples of peer call control signaling protocols.
   Depending on the call control protocol and call model, basic call
   control may be supplemented by user or service features such as
   routing based on pre-subscribed carrier identification code, or
   upon information provided by a service agent, mobility agent or
   routing & translation server. Work is in progress also to
   integrate intelligent network (IN)based service logic and call
   control protocols (see, for example, [14,15]).


3.1.1.3. Management

   Management functions enable a Call Agent to alter the state of a
   call in response to network abnormalities such as congestion or
   failure of a network element (e.g. another Call Agent, Media
   Gateway or Signaling Gateway) or label switched path payload or
   signaling transport. It also allows the graceful startup or
   shutdown of VoIP over MPLS network components.

3.1.2. Media Gateways

   A Media Gateway (MG) forms the interface between the IP/MPLS
   packet network ("packet side"), and circuit-switched PSTN/ISDN/GSM
   networks or elements ("circuit side"), and adapts between the
   coding formats for voice, fax and voice-band data in the circuit
   side and packet side. Depending upon the traffic type, the Media
   Gateway may also perform signal quality enhancements (e.g. echo
   cancellation) and silence suppression. A Call Agent has exclusive
   control over one or more Media Gateways.

   The  Media Gateway includes the following functions:


Kankkunen et al.         Expires January 2001                [Page 12]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   -  Logical Connection Control: The MG receives instructions from
      the Call Agent to initiate the establishment or release of
      bearer connections to other media gateways. Optional QoS-
      parameters may be included in this instruction. The instruction
      to the MG indicates the mapping between circuit side ports and
      IP address of the peer-GW (or IP-endpoint) to be used for the
      call.
   -  Call Agent Interface: The MG has an IP-based interface to the
      Call Agent that is used for the exchange of media gateway
      control information. This interface may also support the back-
      haul transport of in-band signaling information received from
      the circuit side, as appropriate.
   -  Packetization/Depacketization: The MG packetizes audio signals
      from the circuit side for transmission on the packet network
      and performs the inverse depacketization function for traffic
      sent to the circuit side. Packetization/Depacketization
      involves encapsulating/decapsulating packetized audio samples
      using the IP address indicated for the call by the Call Agent.

   Depending upon implementation, the MG may also support other
   functions, e.g. data detection of fax and modem signals, echo
   cancellation, transcoding/audio-mixing, silence detection/comfort-
   noise generation, and buffering/traffic shaping for received audio
   packets. However these functions are beyond the scope of this
   draft.

3.1.3. Media Inter-Working Function

   The Media Inter-Working Function (MIWF) may be implemented in the
   same functional element as the Media Gateway, or it may be
   implemented as a separate functional element interconnected to the
   Media Gateway via an IP internetwork.

   The MIWF implements the functionality of an MPLS Edge Node [6]. It
   also performs inter-working between VoIP QoS bearer control and
   MPLS based QoS services.

   Where Diff-Serv mechanisms are used for the IP Bearer QoS,
    interworking with MPLS is specified in [21].

   Where QoS reservations are used through RSVP signaling,
   interworking with MPLS could be achieved in two modes:

   - without aggregation: one RSVP reservation maps to an MPLS LSP.

   - with aggregation: multiple RSVP reservations maps into a shared
     MPLS LSP. Such interworking is discussed further below in


Kankkunen et al.         Expires January 2001                [Page 13]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




     section 3.3.7 and combines operations of RSVP Aggregation [23]
     with the RSVP extensions for LSP set-up [17].

   Alternatively QoS reservations may be implemented via policy based
   control of MPLS as outlined in [24]. Such reservations may be
   either per session or aggregated.


3.1.4. Signaling Gateway

   With decomposed gateways, the physical interface for channel
   controlled signaling (such as SS7 messages and Q.931 messages) may
   not be in the same device as the logical terminating point for
   such signaling.  For ISDN, the interface may be in the media
   gateway.  For SS7, the interface may be in a separate box.  The
   Signaling Gateway provides a termination point for lower level
   protocols carrying such signaling channels, and may provide a
   packet interface to transport the higher layer signaling to the
   call agent, using, for example, SCTP. For ISDN, the SG might
   terminate Q.921.  For SS7 networks, the SG might terminate MTP2,
   or MTP3.  The call agent would terminate Q.931 or Q.761.

   The Signaling Gateway (SG) forms the interface for call/connection
   control information between the VoIP network and attached
   PSTN/ISDN/GSM networks. For example, an SS7 SG receives messages
   from an SS7-linkset and encapsulates the SS7 application parts
   (e.g. ISUP, TCAP, MAP, etc.) for delivery to the Call Agent. The
   SG must terminate and processes MTP2 and MTP3 if an SS7 interface
   is supported, e.g.  to either an STP Pair or SS7 end system
   (SSP/SCP). There is a master-slave relationship between a Call
   Agent and a (set of) Signaling Gateways. A SG is responsible for
   all signaling information relating to a (set of) Media Gateway(s).

   Signaling protocols use IP transport (which may transit MPLS LSPs)
   such as UDP, TCP or SCTP[19].


3.1.5. Signaling Inter-Working Function

   The SIWF may be implemented in the same functional element as the
   Signaling Gateway, or it may be implemented as a separate
   functional element interconnected to the Signaling Gateway via an
   IP internetwork.

   The Signaling Inter-Working Function implements the functionality
   of an MPLS Edge Node [6].



Kankkunen et al.         Expires January 2001                [Page 14]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




3.1.6. Trunk Gateway

   A Trunk Gateway (TG) is a type of Media Gateway, and is generally
   a large capacity gateway used to connect a PSTN network to a VoIP
   network.  The physical interface in a trunk gateway is a large
   number of E1/T1s or perhaps concatenated DS3/T3/E3 or OC-n ports
   intended to be connected to the trunk side of a Central Office.
   Signaling for TGs is generally via SS7 through an SG, but in some
   cases could use ISDN with the SG collocated in the TG.

3.1.7. Access Gateway

   An Access Gateway (AG) is a type of Media Gateway intended to
   exist on the edge of a public VoIP/MPLS network, and connect
   multiple subscriber circuits (such as PBXs) to a VoIP/MPLS
   network.  The physical interface in an Access Gateway would
   typically be a number of T1/E1s (possibly PRIs), large number of
   analog POTS interfaces or ISDN BRI interfaces.

3.1.8. Line Side Gateway

   A Line-Side Gateway (LSG) is a type of media gateway designed to
   provide "emulated local loop" capability where a VoIP/MPLS network
   provides voice circuit transport to the line side of a Central
   Office switch, the CO providing all call control.  In this
   application, the Call Agent may not exist (the LSPs or IP
   connections would be provisioned), or be very simple (providing
   transport of hook switch and ring for example).  The physical
   interface for a LSG would be a number of T1/E1s, or possibly an
   OC-3, using GR-303 or V5.2 signaling, with the SG collocated in
   the LSG.

3.1.9. Integrated Access Device

   An Integrated Access Device (IAD) is a device that includes the
   functions of a Media Gateway as well as additional data network
   capability, with the purpose of coalescing voice/video and data
   connectivity to a site through a single uplink (communications
   facility).  For example, an IAD may have an Ethernet interface to
   the site LAN and a T1/E1 interface to the site PBX, together with
   an IP interface as an uplink to a public VoIP/MPLS network that
   carries the voice and data.

3.1.10. Voice Terminals

   Voice terminals form the interface between the human user and the
   telecommunications infrastructure.


Kankkunen et al.         Expires January 2001                [Page 15]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   Traditional voice terminals for the PSTN/ISDN networks include
   analog phone, PBX, Key System, VF modem, Fax machines and ISDN
   terminals.

   In addition to being connected directly to an IAD or AG the voice
   terminals may be connected to a VoMPLS network via:
   - An conventional PBX through a interworking device such as an
     H.323 gateway
   - An IP PBX
   - A "Phone Hub", which would be a device with multiple analog or
     digital phone interfaces on one side and an Ethernet on the
     other side
   - A single port adapter, which has a single phone port and an
     Ethernet port
   - A telephone adapter to another device on the network such as a
     PC
   - An "IPPhone" (or "SIPPhone" or H.323 terminal), which is an end
     device with a native network interface.

   Phone Hubs, Single Port Adapters, IP-Phones and other devices may
   use external call agents.  H.323 gateway, IP PBXs and similar
   devices are combined Call Agent/Media Gateways.

3.1.11. VoMPLS Media Gateway

   A VoMPLS Media Gateway is an implementation of a Media Gateway and
   a Media Inter-Working Function in a single functional element. An
   implementation of a VoMPLS Media Gateway is not required to
   implement the protocols defined between the Media Gateway and the
   Media Inter-Working Function. A VoMPLS Media Gateway is required
   to implement the functionality of the Media Gateway and the Media
   Inter- Working Function.

3.1.12. VoMPLS Signaling Gateway

   A VoMPLS Signaling Gateway is an implementation of a Signaling
   Gateway and a Signaling Inter-Working Function in a single
   functional element. An implementation of a VoMPLS Signaling
   Gateway is not required to implement the protocols defined between
   the Signaling Gateway and the Signaling Inter-Working Function. A
   VoMPLS Signaling Gateway is required to implement the
   functionality of the Signaling Gateway and the Signaling Inter-
   Working Function.

3.2. Data Plane

   The requirements for the Data Plane are:
   -
     Provide a transparent path for VoIP bearers (RTP flows).

Kankkunen et al.         Expires January 2001                [Page 16]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   -
     Provide efficient transport of voice (header compression)
   -
     Provide an efficient method to implement a multiplexed LSP
   -
     Provide an optional method to specify delay characteristics
     across the network on a specific LSP, specifically, a way to
     specify the maximum delay and a bound on delay variation for an
     LSP.


   The data plane may be functionally broken down into -

   - Voice Encoding [audio signals into digital format - G.711,
     G.726, G.723.1, G.729, etc]

   - Packetization/De-packetization [converting the encoded voice
     into RTP/UDP/IP/MPLS packets & vice versa]

   - Compression [Compressing the RTP/UDP/IP/MPLS headers to reduce
     overhead or other alternative approaches such as suppression]

   - Multiplexing [Multiplexing many different voice circuits into
     one MPLS packet for Voice trunking application]

   - Echo Control [Reduce / cancel the echo generated by legacy PSTN
     systems]

   - Queues / Schedulers [Give priority to voice traffic wrt BE
     traffic multiplexed on the same output link]

   - Traffic Shapers [To reduce jitter & control burstiness nature of
     traffic]

   - Tone Generators & Receivers [Generation & detection of DTMF
     tones, continuity test tones & detection of modem tones]

3.3. Control Plane

   The Control Plane involved in VoIP and VoMPLS can be divided into
   two components:
   - the Call Control
   - the Bearer Control

   The Call Control is responsible for establishing, modifying and
   releasing telephony calls. Entities involved in Call Control may
   be communicating with protocols such as Q.1901, SIP, or H.323. In
   the `decomposed gateway model', Call Agents involved in the Call
   Control control the Gateways (GWs) via media gateway protocols
   such as MGCP or Megaco/H.248.


Kankkunen et al.         Expires January 2001                [Page 17]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   Call control must arrange for the (bearer) originating media
   gateway to obtain the address of the (bearer) terminating gateway.
   It must also determine, through negotiation if necessary, the
   processing functions the media gateway must apply to the media
   stream, such as codec choice, echo cancellation application, etc
   and inform its media gateway function of such treatment.
   The Bearer Control is responsible for establishing, modifying and
   releasing the logical connection between Gateways.

3.3.1. Concept of IP QoS Bearer Control

   When telephony services are transported over TDM or natively over
   layer 2 technologies such as ATM, the `bearer' is indeed a circuit
   or a logical connection. Thus with such transport technologies, no
   connectivity is available until the bearer is established. Also,
   all the connectivity attributes such as quality of service and
   resource reservations are established simultaneously with the
   bearer itself. Thus, in such environments Bearer Control is
   typically an atomic action establishing at the same time
   connectivity as well as all the connectivity attributes (eg QoS).

   When telephony services are transported over IP, the concept of
   bearer is perhaps less intuitive since default connectivity
   between Gateways is permanently available without requiring any
   explicit bearer establishment.

   Because default connectivity is permanently available, it has
   sometimes been incorrectly assumed that the concept of Bearer
   Control did not apply to VoIP.

   Where the default connectivity between Gateways is appropriate for
   transport of the telephony services, the Bearer Control role
   indeed reduces to nothing.

   However, the default connectivity can not always be assumed to be
   sufficient. We focus on environments where the service provider
   wants to guarantee adequate quality to (all or some) voice calls
   and thus wants to be able to reserve resources and obtain Quality
   of Service  above those always available through default
   connectivity. This resource reservation and QoS properties (above
   and beyond the default connectivity) need to be explicitly
   established by the Bearer Control entity. This resource
   reservation and QoS establishment is called the `IP QoS Bearer
   Control'.

3.3.2. Advertisement/Negotiation of Traffic Parameters and IP QoS
       Bearer Control requirement in Call Control


Kankkunen et al.         Expires January 2001                [Page 18]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   It is necessary for the call control protocol to include
   provisions for specifying the codec type, packetization period,
   and other parameters required to determine all the traffic
   parameters (eg token bucket profile) required for the IP QoS
   Bearer Control to establish the required reservation and QoS for
   the call. Existing call control protocols already include such
   provisions.

   It is useful for the Call Control protocols to be able to
   advertise the requirements associated with a given call in terms
   of `IP QoS Bearer Control' (eg. whether, for each direction, QoS
   reservation is mandatory, optional or not requested at all) for
   example in order to support different levels of quality for
   different calls. It may also be useful for the Call Control
   protocols  to allow negotiation of the `IP QoS Bearer Control'
   requirements (for example, if one of the party does not want to
   incur the charges associated with reservations).

   Ongoing work in the IETF is addressing Call Control protocol
   capability to advertise/negotiate the `IP QoS Bearer Control'
   requirements. One example of this is the SDP extensions defined in
   [25] in order to advertise pre-conditions for call establishment
   in terms of QoS reservation.

   Because megaco also makes use of SDP, we expect these SDP
   extensions defined for SIP to be also applicable to megaco.

3.3.3. Signaling for IP QoS Bearer Control Establishment

   Once a requirement for `IP QoS Bearer Control' (eg QoS
   reservation) has been determined through the mechanisms described
   in section 3.3.2, the Bearer Control protocol must enter in
   action.

   The QoS architecture for the Internet separates QoS signaling from
   application level signaling [26]. In agreement with [25], the
   authors of this paper feel that such QoS architecture is
   particularly applicable to support of public telephony services
   over a packetized infrastructure. This means that the `IP QoS
   Bearer Control' must remain separate from the Call Control:

   - `IP QoS Bearer Control' is performed by the Bearer Control
     entities which are logically separate from the Call Control
     entities.

   - `IP QoS Bearer Control' is to be performed through a network
     level protocol designed for network resource reservation and QoS
     signaling and which is separate from the Call Control protocol.

Kankkunen et al.         Expires January 2001                [Page 19]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





     However although logically separate the interaction between the
     two layers is important. Specifically it is necessary to ensure
     that bandwidth reservation occurs prior to called party alerting
     to avoid call defects in the case where the reservation
     mechanism fails due to insufficient resources.

   Benefits of this QoS architecture include:

   - alignment to natural layering: management of QoS reservations
     are fundamentally a network layer issue while Call Control
     entities are fundamentally application level devices (with no or
     limited natural network awareness)

   - avoids issues related to difference between bearer path and
     control path: Call Control entities are often located out of the
     bearer path which would make it difficult for them to perform
     QoS reservation on the bearer path.

   - common `IP QoS Bearer Control' solution for all Call Control:
     Because the Bearer Control protocol operates separately from the
     Call Control protocol, the same Bearer Control solution can be
     used by all the Call Control protocols (eg. SIP, H.323, Q.1901)
     as well as all the Media Gateway Control protocols
     (Megaco/H.248, MGCP,).

   - common `IP QoS Bearer Control' solution for all applications:
     Because the Bearer Control performs generic QoS reservation
     which are not specific to the voice application, the same Bearer
     Control solution can be used by other applications than
     telephony (eg video, multimedia).

   The IETF has defined a network level IP signaling protocol [26] as
   well as QoS services (such as Guaranteed Services [27] and
   Controlled Load [28]) which can be used as the `IP QoS Bearer
   Control' to achieve predictable/constrained QoS required for
   public telephony services over IP.

   The IETF has also defined a framework [29] and associated
   protocols (such as [30]) for policy based admission control
   applicable to environments where the resource-based admission
   control is performed through the RSVP protocol. Thus, where RSVP
   is used as the IP QoS Bearer Control protocol existing
   specifications define a way to enforce various policies for
   controlling resource access. As an example, such policies may be
   useful at network boundaries.



Kankkunen et al.         Expires January 2001                [Page 20]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   [31] specifies how RSVP can take into account the compression
   gains achieved through header compression performed locally on
   some hops. This allows accurate resource reservations even if
   different hops perform different compression schemes or no
   compression at all.

3.3.3.1. Scaling IP QoS Bearer Control with RSVP

   Much existing work in the IETF has provided various options to
   achieve carrier class scalability when RSVP is used as the IP QoS
   Bearer Control protocol at per-call level between VoIP GWs. The
   simplest option is to carry the per-call RSVP messages through an
   IP core network transparently, i.e., each core router does not
   process the RSVP messages, but simply forwards them to the next
   hop just as if they were regular IP packets. This approach relies
   on the core network having enough resources pre-provisioned to
   carry all calls.

   Another option is to use Int-Serv over Diff-Serv [32]. The
   attractiveness of this option is using Diff-Serv
   classification/scheduling complemented by RSVP signaling in the
   control plane to perform end-to-end admission control. This
   achieves considerable scalability improvement via aggregation of
   classification and scheduling states.

   In addition to using Diff-Serv classification/scheduling in the
   user plane for scalability improvement, one can scale further in
   the control plane via additional aggregation of reservation states
   by using RSVP reservation aggregation [23]. [23] specifies how to
   create aggregate reservations dynamically based on end-to-end per-
   flow reservations (per-call reservations in the VoIP case), and
   how to classify traffic for which the aggregate reservation
   applies. The approach also allows service providers to dynamically
   adjust the size of the aggregate reservations based on certain
   local policies and algorithms. Such policies and algorithms may
   include:

   1)  increase or decrease the size of the aggregate reservation by
      a fixed quantity based on the usage level of current
      reservation e.g., by comparing with some pre-configured upper
      and lower thresholds;

   2)  resize the aggregate reservation based on some trend line over
      certain period of time characterizing the speed of increase or
      decrease in call volume;




Kankkunen et al.         Expires January 2001                [Page 21]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   3)  determine the size of aggregate reservation based on a priori
      requirements that may be associated with a particular day in a
      week and time of day.

   Also, [23] allows recursive aggregation so that multiple levels of
   aggregation may be used if required.

   Given all the options described above, it shows that RSVP can be
   used as a scalable Bearer Control protocol for VoIP with
   predictable/constrained QoS over the connectionless
   infrastructure.

3.3.4. Coordination between Call Control and IP QoS Bearer Control

   One of the functions involved in the `IP QoS Bearer Control' is
   admission control of the requested reservation. If the network
   resources required to establish the requested QoS reservation are
   not available and cannot be reserved at least at one point in the
   network, the reservation will be rejected. This admission control
   can be seen as a `network level admission control'.

   Where consistent high quality voice service is required, as
   assumed in this document focusing on IP based public Voice
   services, it is essential that a voice call can be rejected
   (before the called party's phone even rings) if its quality (or
   the quality of already established calls) cannot be guaranteed. In
   other words, it is essential to be able to trade service
   degradation for service rejection.

   Consequently, the `network level admission control' must be
   translated into `voice admission control'. This is to be achieved
   by proper coordination between the `IP QoS Bearer Control'
   signaling and the Call Control signaling.

   Again, there is ongoing work on standardizing such coordination.
   Design goals for defining this coordination include telephony user
   expectations of behavior after phone is ringing, minimization of
   post dial delay, charging aspects, denial of services,...

   [33] provides a more detailed discussion on such coordination in
   the context of the Distributed Call Signaling (DCS) architecture.
   [25] provides an example of how SIP signaling can be coordinated
   with `IP QoS Bearer Control signaling'.

   As another example, [34] has been submitted into ITU SG16 defining
   how H.323 signaling with `Slow Start' can be coordinated with
   RSVP.


Kankkunen et al.         Expires January 2001                [Page 22]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




3.3.5. Policy Based Control of VoMPLS Network Elements

   One potential approach for controlling VoMPLS network elements to
   enable QoS and GoS guarantees to be made is via the emerging MPLS
   Policy model [24]. In this model abstract policy rules may be used
   to define and control the Quality of Service assigned to a
   particular session or groups of sessions.

   Available network resources are brokered by a management layer
   consisting of one or more Policy Decision Points (PDP) that
   effectively act as bandwidth brokers. The PDPs pass policy rules
   to the MPLS network elements that trigger the generation (or
   deletion) of LSPs. Such LSPs can be used as pre-provisioned
   aggregate traffic trunks thereby providing a mechanism for
   achieving GoS within a VoMPLS network.

   The control of individual sessions is achieved by adding or
   deleting associated filters to the aggregated LSPs. The PDPs
   perform a bandwidth broker function to determine whether the
   session may be accepted and if so its optimal route. To achieve
   scaling it may be advantageous to have this functionality
   distributed and therefore to have an inter-bandwidth broker
   signaling mechanism that is capable of passing LSP control
   information.

3.3.6. Bearer Control for VoMPLS

3.3.6.1. Concept of VoMPLS Bearer Control

   Let's consider a VoMPLS GW i.e. a GW which incorporates both the
   VoIP function and the IP/MPLS IWF, and thus is capable of
   transmitting packetised voice over MPLS.

   Before packetised voice can be transmitted over an MPLS Label
   Switched Path (LSP), the LSP must be established via a label
   binding protocol. Since we focus on environments where quality is
   to be guaranteed to voice calls, the LSP must be established with
   resource reservation and QoS attributes. The LSP may also be
   established along a path determined by Constraint Based Routing to
   meet these QoS attributes. Also, where Header Compression and
   multiplexing are performed over the LSP, the compression and
   multiplexing contexts must be established over the LSP.

   Thus, the VoMPLS Bearer Control function can be seen as
   responsible for establishment of:
   - connectivity (possibly with Constraint Based Routing)
   - QoS and resource reservation
   - compression/multiplexing context

Kankkunen et al.         Expires January 2001                [Page 23]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





3.3.6.2. VoMPLS Bearer Control for Connectivity

   RSVP [17] and CR-LDP [18] can be used as the Bearer Control
   protocol to perform LSP set-up and corresponding label binding.

   Where Constraint Based Routing is to be performed at the
   granularity of GW-to-GW-pair, Constraint Based Routing can be
   performed at LSP set-up so that RSVP or CR-LDP establish the LSP
   along the computed path.

   Where Fast Reroute is to be performed at the granularity of GW-to-
   GW-pair, Fast Reroute can be requested at LSP set-up by RSVP or
   CR-LDP.

3.3.6.3. VoMPLS Bearer Control for QoS and Resource Reservation

   Resource reservation and QoS establishment can also be performed
   by RSVP and CR-LDP. Clearly, they can be performed simultaneously
   with the LSP establishment (VoMPLS Bearer Control for
   Connectivity) and can use the same signaling messages simply
   augmented with the appropriate QoS-related Information Elements.

   The QoS Bearer Control function for VoMPLS is identical to the IP
   QoS Bearer Control discussed earlier for VoIP GWs. Consequently,
   all the ongoing work in the IETF pertaining to `IP QoS Bearer
   Control' for VoIP is applicable to VoMPLS as one possible
   approach. This includes:

   - solutions for advertisement and negotiation of Traffic
   Parameters and QoS Bearer Control requirement in Call Control
   protocols as discussed above in section 3.3.2.

   - solutions for QoS Bearer Control signaling as discussed above in
   section 3.3.3.

   - solutions for coordination between call control and QoS bearer
   Control as discussed above in section 3.3.4.


3.3.6.4. VoMPLS Bearer Control for Compression/Multiplexing

   Establishment of Compression and Multiplexing context is one
   aspect of VoMPLS Bearer Control. RSVP and CR-LDP may also be used
   to signal the corresponding information.

   As an example, details of how RSVP can be used to signal the
   compression and multiplexing context for the Simple Header

Kankkunen et al.         Expires January 2001                [Page 24]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   Compression are provided in [20]. We note then that all aspects of
   Bearer Control (connectivity, Constraint Based Routing, QoS and
   reservation, Compression and Multiplexing) can be performed
   simultaneously and with the same signaling messages simply
   carrying Information Elements for all aspects.

   As mentioned earlier, [31] specifies how RSVP can take into
   account the compression gains achieved through header compression
   performed locally on some hops. This allows accurate resource
   reservations even if different hops perform different compressions
   or no compression at all. The approach specified is easily
   extensible for new compression schemes through the definition of
   compression identifiers. We recommend that the corresponding
   compression identifiers be defined for the compression scheme(s)
   that may be defined for VoMPLS. This will ensure, where RSVP is
   used as the Bearer Control protocol, that accurate reservations
   are performed end-to-end even where these VoMPLS compression
   schemes are used on some hops only (eg. where the LSP does not
   span the entire GW-to-GW path)and where different compression
   schemes are used on different logical hops.

3.3.7. Aggregated MPLS Processing in the Core

   As discussed above in section 3.3.6.2, the VoMPLS Bearer Control
   entity can establish an MPLS Label Switched Path which can be used
   to transport one call or, assuming multiplexing is used, to
   transport all or any subset of the calls between a given pair of
   GWs. Advanced MPLS features may also be applied onto this LSP such
   as Constraint Based Routing and protection of the LSP via Fast-
   Restoration.

   From the MPLS Control Plane perspective, this results in :
   - RSVP or CR-LDP signaling processing and label binding at every
     MPLS hop for each GW-to-GW pair.
   - resource reservation and admission control at every MPLS hop for
     each GW-to-GW pair and every time the resource reservation is
     modified (eg. to adjust to varying number of calls on a GW-to-GW
     pair)
   - in case of failure, Fast Reroute at the relevant MPLS hops of
     all the affected GW-to-GW LSPs

   From the MPLS user plane perspective, this result in a different
   MPLS label cross-connect entry in the Label Forwarding Information
   Base established at every MPLS hop for every GW-to-GW pair.

   In brief, this involves full MPLS processing at every hop in the
   MPLS network at the granularity of GW-to-GW pair.


Kankkunen et al.         Expires January 2001                [Page 25]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   As the number of Gateways grow, this may represent a significant
   scaling burden which would not yield the most cost economical
   solution in all environments. Consequently, we propose one
   approach allowing MPLS processing purely on an aggregate basis in
   the MPLS core.

   This approach relies on RSVP reservation aggregation as defined in
   [23] and already mentioned above in section 3.3.3.1. Where RSVP is
   used by GWs as the Bearer Control protocol, the end-to-end GW-to-
   GW RSVP reservations can be aggregated when entering the
   aggregation region (ie the core) into a smaller number of fat
   aggregated reservations within the aggregation region. At the
   egress of the aggregation region, the aggregated reservations are
   broken out back into end-to-end GW-to-GW reservations. [23]
   specifies that an aggregated reservation may be instantiated as a
   tunnel of some sort and in particular as an MPLS Tunnel. In this
   context, we elect to instantiate every aggregate reservation as an
   MPLS Tunnel. Each MPLS tunnel is then used to transport all the
   calls associated with the multiple GW-to-GW reservations which are
   aggregated together through the aggregation region. As defined in
   [23], the classification and scheduling required in the core are
   purely Diff-Serv (as opposed to per-label
   classification/scheduling), retaining extremely high scalability
   properties for the user plane in the core.

   Exactly as in the non-MPLS context discussed in 3.3.3.1, very
   flexible and powerful policies and algorithms can be used by the
   service provider for establishing and controlling the sizing of
   the aggregated reservations.

   The MPLS Tunnels corresponding to aggregate reservations can be
   established via RSVP (or possibly CR-LDP after appropriate mapping
   is defined). Constraint Based Routing and Fast Restoration can
   also be applied to these MPLS Tunnels.

   Both from the MPLS Control Plane perspective as well as from the
   MPLS User Plane perspective, MPLS processing in the core is now
   performed at the granularity of the aggregate reservation instead
   of a the level of GW-to-GW. Yet, the benefits of MPLS such as
   Constraint Based Routing and Fast Reroute are offered to the
   transported telephony services; only they are achieved in the core
   on an aggregate basis.

   This approach is applicable for aggregation over an MPLS core
   regardless of whether GWs are connected to the core via MPLS or
   non-MPLS. For instance, this aggregation can be achieved with VoIP
   GWs having non-MPLS connectivity to the MPLS core. In that case, a
   natural (but not mandatory) location to perform the aggregation is

Kankkunen et al.         Expires January 2001                [Page 26]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   at the level of the MIWF ie. the MIWFs also act as Aggregators and
   Deaggregators as defined in [23]. Also, this aggregation can be
   achieved with VoMPLS GWs having full end-to-end MPLS connectivity.
   In that case, the Aggregators and Deaggregators are MPLS Label
   Switch Routers located closer into the core than the GWs.


4. VoMPLS Applications

4.1. Trunking Between Gateways

   MPLS LSPs can be used for providing the trunks between the various
   gateways defined in Section 3.

4.1.1. Encapsulation Requirements for Efficient Multiplexed Trunk

   Where a label edge router, or a gateway with built-in label edge
   router functionality can determine that multiple streams must pass
   on the same LSP to the same far end LER, then the streams can be
   optimized by using a multiplexing technique.  The VoMPLS
   multiplexing function shall provide an efficient means for
   supporting multiple streams on a single LSP which is trivially
   convertible into multiple individual IP/UDP/RTP streams by the far
   end LER.

   The multiplexing methods needs to provide an efficient voice
   encapsulation and a call identification mechanism.

4.2. VoMPLS on Slow Links

   Slow links are being used in the MPLS based access networks. These
   links are typically based on transmission over copper cables.

   The vast majority of access lines in the world are currently
   copper-based and this will not change in the near future.
   Therefore it is important to address the requirements of slow
   links in the VoMPLS specifications.

   Slow links introduce additional requirements concerning bandwidth
   efficiency and the control of voice latency.

   In most cases bandwidth in slow links is expensive and needs to be
   used in the most efficient way possible. Especially it is often
   desirable to avoid the overhead of carrying full IP, UDP and RTP
   headers with every voice packet.

   A simple method for compressing IP/UDP/RTP headers shall be
   specified.  The header compression mechanism and the multiplexing

Kankkunen et al.         Expires January 2001                [Page 27]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   mechanism of section 4.1.1 should be considered the same mechanism
   (i.e. the IP header compression could yield a short LSP specific
   channel identifier which permits multiple channels per LSP).
   Alternatively header compression can be applied at link level
   using the methods proposed in [8]. Also PPP-muxing can be used for
   reducing the overhead [3].

   The control of latency on slow links requires link level
   fragmentation of large data packets. The fragmentation is
   specified in RFC 2686 [4].

4.3. Voice Traffic Engineering using MPLS

   The goal of voice traffic engineering is to ensure that network
   resources can be efficiently deployed and utilised so that the
   network is able to support a planned group of users with a
   controlled/guaranteed (voice) performance. In essence voice
   traffic engineering may be summed up as providing QoS and GoS to a
   group of users at a reasonable (network) cost.

   Voice traffic engineering for VoMPLS will encompass forecasting,
   planning, dimensioning, network control and performance
   monitoring. It therefore spans both off-line analysis and on-line
   control, management and measurement. Broadly, voice traffic
   engineering may be broken down into three distinct layers
   (characterised by the temporal resolution at which they operate):

        1) Off-line voice traffic engineering.

        2) Connection admission and/or connection routing.

        3) Dynamic Traffic Management.

   The general requirements at each layer will be discussed in more
   detail below. Clearly in an optimal solution there is interaction
   between the stages - a fundamental requirement of performance
   measurement is to provide this necessary feedback.

4.3.1. Off-Line Voice traffic engineering Aspects

   The goal of off-line voice traffic engineering is to ensure that
   sufficient network resources are engineered together with a given
   set of policies and procedures such that the network is capable of
   delivering the GoS and QoS guarantees to the planned group of
   users.

   In traditional voice network planning the first stage in this
   process is to perform traffic analysis to determine the capacity

Kankkunen et al.         Expires January 2001                [Page 28]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   requirements for the voice traffic at busy hour. This then enables
   the network to be dimensioned and configured to support this load
   with a given blocking probability. Finally a set of policies and
   procedures should be defined to determine how the allocated
   network resources should be utilised. The policies should address
   key requirements including the mechanism whereby the voice GoS is
   maintained within a multi-service environment, definitions of
   routing mechanisms that should be applied to ensure efficient
   network utilisation, behaviour rules for overload and congestion
   management.

   Some operators may choose to use off line voice traffic
   engineering tools and techniques in a VoMPLS system, that are
   radically different from those in the PSTN. As an example, busy
   hour measurements may have little affect on pre-allocated LSPs in
   a VoMPLS network, as average rates may determine pre-allocated
   resources, with dynamically created LSPs absorbing traffic during
   busy periods. Policy metrics and control points in packet networks
   are typically very different from those in the PSTN, and thus new
   mechanisms, specific policies, and enforcement mechanisms will be
   required. VoMPLS work may motivate some mechanisms but
   implementing such mechanisms is out of scope of the VoMPLS work.

4.3.2. Connection Admission and/or Connection Routing

   Network performance will be fundamentally affected by the policies
   and procedures applied when establishing new sessions. At a
   minimum the following issues need to be addressed within a VoMPLS
   network:

        (i) New sessions should be routed such that the network
        resources are used in an efficient manner. This implies that
        the system needs to be capable of supporting traffic between
        the same two end points using multiple path alternatives.

        (ii) The QoS guarantees for existing voice connections should
        be unaffected when new sessions are established - at the
        limit this implies a requirement that new session requests
        should be rejected if insufficient network resources are
        available.

        (iii) The network should be resilient to mass calling events.
        This implies that call rejection should be performed at the
        edge of the network to avoid placing undue load onto the core
        network routers.

   The above requirements imply that VoMPLS systems should be
   constructed where the MIWF is aware of LSP usage, and tracks

Kankkunen et al.         Expires January 2001                [Page 29]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   bandwidth consumption, either using admission control to restrict
   new calls, or creating new LSPs when bandwidth in an existing LSP
   is committed.

4.3.3. Dynamic Traffic Management

   Dynamic traffic management refers to the set of procedures and
   policies that are applied to existing voice sessions to ensure
   that network congestion is minimised and controlled. The following
   functions will typically be performed at this layer:

     -  traffic buffering and queue management within MPLS routers to
        control delay (based on signaled QoS requirements, i.e., is
        not voice specific)
     -  traffic policing at key network ingress points to ensure
        session compliance to traffic contracts/SLAs
     -  traffic shaping at ingress points to minimise the resource
        requirements of traffic sources
     -  loss/late packet interpolation and jitter buffering at egress
        points to reconstitute the original real-time session stream
     -  traffic measurement for performance monitoring and congestion
        detection

   VoMPLS does not differ from other forms of Voice over data
   networks in its dynamic traffic management capabilities other than
   the fundamental properties MPLS provides.


4.4. Providing End-to-end QoS for Voice Using MPLS

   A key goal of the development of the VoMPLS specification will be
   to ensure that the reference architecture is capable of supporting
   end-to-end QoS and GoS.

   Defining new MPLS related signaling protocols is out of the scope
   of the VoMPLS work. VoMPLS work may motivate some extensions to
   the existing protocols as required.

   The initial goal is to define an end-to-end QoS architecture for
   single MPLS domain. This implies that it should be possible to set
   up LSPs with a bandwidth reservation and a bounded delay.
   A long term goal is to achieve end-to-end QoS across multiple MPLS
   domains. However, this will require considerable progress in the
   area of the generic MPLS specifications. A connectivity model and
   end-to-end VoIP over MPLS reference connection is shown in  Figure
   5 below. The model provides a framework for the control and
   signaling required to establish QoS capable sessions. The
   reference model illustrated is scalable to global proportion

Kankkunen et al.         Expires January 2001                [Page 30]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   consisting of access domains and core network domains. In Figure 5
   two core domains are shown, which might for example represent the
   two national operators involved in establishing an international
   session. The connectivity model may be devolved further to support
   multiple core MPLS domains. The access domains may be provided
   either by the ISDN (requiring a TDM to packet interworking
   function at the gateway to the core MPLS domain) or by an MPLS
   access network enabling full end-to-end VoIP over MPLS operation.









































Kankkunen et al.         Expires January 2001                [Page 31]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





                   Gateway               Gateway
                   +------+              +------+
                   |      |              |      |
   +--+   +------+ | +--+ |              | +--+ |
   |TE|---| ISDN |---|CC|------------------|CC|-----//--A
   +--+   |  or  | | +--+ |              | +--+ |
          | MPLS | |      |              |      |
          |Access| | +--+ | +--+   +--+  | +--+ |
          +------+ | |BC|---|BC|---|BC|----|BC|-----//--B
                   | +--+ | +--+   +--+  | +--+ |
                   |      |              |      |
                   +------+              +------+

                   \------------  --------------/
                                \/
                         MPLS Core Domain 1


                     Gateway               Gateway
                     +------+              +------+
                     |      |              |      |
                     | +--+ |              | +--+ |  +------+   +--+
             A---------|CC|------------------|CC|----| ISDN |---|TE|
                     | +--+ |              | +--+ |  |  or  |   +--+
                     |      |              |      |  | MPLS |
                     | +--+ | +--+   +--+  | +--+ |  |Access|
             B---------|BC|---|BC|---|BC|----|BC|----|      |
                     | +--+ | +--+   +--+  | +--+ |  +------+
                     |      |              |      |
                     +------+              +------+

                                \---------  ---------/
                                          \/
                                  MPLS Core Domain 2



   BC = Bearer Control
   CC = Call Control

               Figure 5 - End-to-End Reference Connection



5. Requirements for MPLS Signaling

5.1. LDP and CR-LDP


Kankkunen et al.         Expires January 2001                [Page 32]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





   TBD

5.2. RSVP-TE

   TBD



6. Requirements for Other Work

   This section should list the "standardization items" that are
   recommended for IETF and their associated requirements.

   a) identification of the work item
   b) the Section in the draft describing the item details,
   c) the WG where the work could be carried out

   Some possible items follow:

   i)   solutions for advertisement and negotiation of Traffic
        Parameters and QoS Bearer Control requirement in Call Control
        protocols. (TEWG item?)

   ii)  solutions for QoS Bearer Control signaling. (MPLS WG item?)

   iii) solutions for coordination between call control and QoS
        bearer Control. (SIP, MEGACO, MPLS, TEWG item?)

   iv)  identify requirements, protocol, guidelines for QoS/GoScall-
        control/bearer-control coordination mechanisms for VoMPLS
        (TEWG item)

   v)   support of voice Traffic Engineering/Constraint Based
        Routing? (TEWG item)


7. Security Considerations
8. Acknowledgements
9. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3",
      BCP 9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997


Kankkunen et al.         Expires January 2001                [Page 33]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   3  "PPP Multiplexed Frame Option", R. Pazhyannur et al., work in
      progress, <draft-ietf-pppext-pppmux-00.txt>, January 2000

   4  "The Multi-Class Extension to Multi-Link PPP", RFC 2686, C.
      Bormann. September 1999.

   5  null

   6  "Multiprotocol Label Switching Architecture", Eric C. Rosen et
      al., work in progress, draft-ietf-mpls-arch-06.txt, August 1999

   7  "MPLS Label Stack Encoding", Eric C. Rosen et al., work in
      progress, draft-ietf-mpls-label-encaps-07.txt, September 1999

   8  "MPLS/IP Header Compression", L. Berger et al., work in
      progress, draft-ietf-mpls-hdr-comp-00.txt, July 2000.

   9  "Megaco Protocol", F. Cuervo et al., work in progress, draft-
      ietf-megaco-protocol-07.txt, February 2000

   10 "Media Gateway Control Protocol (MGCP), Version 1.0", RFC 2705,
      M. Arango et al., October 1999

   11 "Packet-based multimedia communications systems", ITU-T
      Recommendation H.323, February 1998

   12 "Session Initiation Protocol (SIP)", RFC 2543, M. Handley et
      al., March 1999.

   13 "Bearer Independent Call Control", Draft ITU-T Recommendation
      Q.1901, (to be published)

   14 F. Haerens, "Intelligent Network Application Support of the
      SIP/SDP Architecture", Internet Draft <draft-haerens-sip-inap-
      00.txt>, November 1999, work in progress.

   15 V. Gurbani, "Accessing IN Services from SIP Networks," Internet
      Draft <draft-gurbani-iptel-sip-to-in-01.txt>, Internet
      Engineering Task Force, December 1999, work in progress.

   16 "LDP Specification", L. Andersson et al., work in progress,
      draft-ietf-mpls-ldp-06.txt, October 1999.

   17 "Extensions to RSVP for LSP Tunnels", D. Awduche et al., work
      in progress, draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, July 2000




Kankkunen et al.         Expires January 2001                [Page 34]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   18 "Constraint-Based LSP Setup using LDP", B. Jamoussi et al.,
      work in progress, draft-ietf-mpls-cr-ldp-03.txt, September
      1999.

   19 "Simple Control Transmission Protocol", R. Stewart et al., work
      in progress, draft-ietf-sigtran-sctp-06.txt, February 2000

   20 draft-swallow-mpls-simple-hdr-compress-00.txt, Simple Header
      Compression, Swallow et al., March 2000

   21 Le Faucheur et al., draft-ietf-mpls-diff-ext-04.txt, March
      2000.

   22 null

   23 draft-ietf-issll-rsvp-aggr-02.txt, `Aggregation of RSVP for
      IPv4 and IPv6 Reservations', Baker et al., March 2000.

   24 "Requirements for Policy Enabled MPLS", S Wright et al, draft-
      wright-policy-mpls-00.txt, March 2000.

   25 draft-manyfolks-sip-resource-00.txt, `Integration of Resource
      Management and SIP for IP Telephony', March 2000.

   26 RFC2205, `Resource ReSerVation Protocol (RSVP) --
      Version 1 Functional Specification', Braden et al.,
      September 1997.

   27 RFC2212, `Specification of Guaranteed Quality of Service',
      Shenker et al,  September 1997.

   28 RFC2211, `Specification of the Controlled-Load Network Element
      Service', Wroclawski, September 1997.

   29 RFC2753, `A Framework for Policy-based Admission Control',
      Yavatkar et al. , January 2000.

   30 RFC2748, `The COPS (Common Open Policy Service) Protocol',
      Durham et al., January 2000.

   31 draft-ietf-intserv-compress-02.txt, `Integrated Services in the
      Presence of Compressible Flows', Davie et al. , February 2000.

   32 draft-ietf-issll-diffserv-rsvp-04.txt, `A Framework For
      Integrated Services Operation Over Diffserv Networks', Bernet
      et al., March 2000.



Kankkunen et al.         Expires January 2001                [Page 35]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   33 draft-dscgroup-sip-arch-01.txt, `Architectural Considerations
      for Providing Carrier Class Telephony Services Utilizing SIP-
      based Distributed Call Control Mechanisms', March 2000

   34 ITU-T, SG16/Q13, Geneva, Feb 2000, Delayed Contribution,
      `Enhancement for Synchronising RSVP with Slow Start'.


10.     Author's Addresses

   Gerald R. (Jerry) Ash
   AT&T Labs
   Room MT E3-3C37
   200 Laurel Avenue
   Middletown, NJ 07748
   USA

   Angela Chiu
   AT&T Labs
   100 Schulz Dr., Rm 4-204,
   Red Bank, NJ 07701, USA
   Phone: +1 (732) 345-3441
   Email: alchiu@att.com


   John Hopkins
   Cisco Systems
   3 The Square,
   Stockley Park,
   Uxbridge, Middlesex. UB11 1BN
   United Kingdom
   tel: +44 208 734 3265
   email: johopkin@cisco.com


   Jason Jeffords
   Integral Access
   6 Omni Way
   Chelmsford MA, 01824
   USA
   Email: jjeffords@integralaccess.com


   Antti Kankkunen
   Integral Access
   6 Omni Way
   Chelmsford MA, 01824
   USA

Kankkunen et al.         Expires January 2001                [Page 36]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   Email: anttik@integralaccess.com

   Francois le Faucheur
   Cisco Systems, Inc.
   Les Lucioles - 291, rue Albert Caquot
   06560 Valbonne
   France
   E-mail: flefauch@cisco.com

   Brian Rosen
   Marconi
   1000 FORE Drive
   Warrendale, PA 15086
   USA
   Email: brosen@fore.com

   Dave Stacey
   Nortel Networks
   London Rd, Harlow, Essex, CM17 9NA, UK.
   Phone: +44 1279 402697
   Email: dajs@nortelnetworks.com

   Anil Yelundur
   NEC

   Lou Berger
   LabN Consulting, LLC
   Voice: +1 301 468 9228
   Email: lberger@labn.net




















Kankkunen et al.         Expires January 2001                [Page 37]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000






ANNEX A - E-Model analysis of the VoIP over MPLS Reference Model

A.1 Introduction

   The ITU-T standards for voice network QoS are defined in relation
   to a global reference connection, which is intended to represent
   the worst case international situation. Within this annex we take
   a PSTN call from Japan to east coast USA and a GSM call from
   Australia to east-coast USA as being representative of global
   reference connections having clear commercial significance.

   In this annex several scenarios will be presented to illustrate
   the requirements on VoMPLS deployments. The scenario analysis is
   split into three distinct parts. In the first part we analyse
   scenarios where the VoMPLS deployment is constrained to the core
   of the network; in the second part of the analysis we extend MPLS
   into the access network; and in the third part we analyse the
   impact of deploying differing voice encoding schemes.

   The scenarios are analysed using the ITU-T E-Model transport
   modelling method [G.107]. The E-Model allows multiple sources of
   impairment to be quantified and the overall impact assessed. The
   result is expressed as an R-Value which is a rating of the
   assessment that real users would express if subjected to the voice
   impairments. Equations to convert E-model ratings into other
   metrics e.g. MOS, %GoB, %PoW can be found in Annex B of G.107.
   Using the R-value the ITU G.109 defines 5 classes of speech
   transmission quality as illustrated in Table A.1 below. As a rule
   of thumb, wire-line connections on todays PSTN tend to fall in the
   'satisfied' or 'very 'satisfied categories' - and R-values below
   50 are 'not recommended'  for any connections.

   +------------------------------------------------------------+
   |    R-value range |  Rating | Users' Satisfaction           |
   |------------------|---------|-------------------------------|
   | 90 <= R < 100    | Best    | Very satisfied                |
   | 80 <= R < 90     | High    | Satisfied                     |
   | 70 <= R < 80     | Medium  | Some users dissatisfied       |
   | 60 <= R < 70     | Low     | Many users dissatisfied       |
   | 50 <= R < 60     | Poor    | Nearly all users dissatisfied |
   +------------------------------------------------------------+

   Table A.1 Definition of Categories of Speech Transmission Quality

   In this analysis we use the term 'intrinsic delay' to define the
   additional delay introduced by a VoMPLS domain over and above the

Kankkunen et al.         Expires January 2001                [Page 38]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   transmission delay - i.e. typically the intrinsic delay is the sum
   of any packetisation and buffering delays introduced by a packet
   network.

   Transmission delay is included within the analysis as a fixed
   delay based on transmission distance (evaluated based on SONET/SDH
   transmission rules).



A.2 Deployment of VoMPLS within the Core Network


A.2.1 Scenario 1 - Effect of Multiple MPLS Domains


   Figure A.1 illustrates the first reference connections considered.
   In the PSTN to PSTN connection two core VoMPLS network islands are
   traversed in both Japan and the USA. In the GSM to PSTN scenario
   one VoMPLS network island is traversed in Australia and two within
   the USA. Calls traversing the VoMPLS core networks interwork
   through the current PSTN.

   The analysis covers a range of intrinsic delays (from 10 ms to 100
   ms) and Packet Loss Ratios (PLR)(0% to 1%) for each VoMPLS domain.
   Each VoMPLS domain is assumed to have the same performance. It is
   assumed that the transmission delay corresponds to 1.5 times the
   greater circle distance between the two users.



                     Japan                    USA
               --------/\--------      --------/\--------
              /                  \    /                  \

              POTS--|MPLS|--|MPLS|----|MPLS|--|MPLS|--POTS
                                     /
                                    /
                                   /
            Mobile--|GSM|--|MPLS|--
             \                  /
              --------\/-------

                  Australia


   Figure A-1: Scenario 1 - Effect of multiple VoMPLS Core Domains


Kankkunen et al.         Expires January 2001                [Page 39]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   A number of further assumptions are made on the basis of best
   possible practice in order to separate the contribution of
   multiple networks from other sources of impairment, in particular:

        - DCME on the Japan to USA link is at full rate e.g. 32 kb/s
        G.726 and VoiceActivity Detection is not included.

       - The Australia to USA link is G.711 i.e. there is no DCME.

        - VoMPLS domains use G.711 with packet loss concealment
        algorithm employed.

        - GSM domain uses full rate codec and no Voice Activity
        Detection.

        - Wired PSTN phones are analogue with echo-cancellers
        employed.

   +--------------------------------------|
   |          |     | Intrinsic Delay(ms) |
   |Connection| PLR |  09 | 20 | 50 | 100 |
   +--------------------------------------|
   |PSTN-PSTN | 0%  |  79 | 74 | 61 | 48  |
   |PSTN-PSTN | 0.5%|  67 | 62 | 49 | 36  |
   |PSTN-PSTN | 1.0%|  59 | 54 | 41 | 29  |
   |GSM-PSTN  | 0%  |  60 | 56 | 47 | 37  |
   |GSM-PSTN  | 0.5%|  48 | 44 | 35 | 25  |
   |GSM-PSTN  | 1.0%|  40 | 36 | 27 | 17  |
   +--------------------------------------+

   Table A.2 R-Value Results for Scenario 1


   The results are presented in Table A.2. It can be seen that with
   an intrinsic delay of around 10 msec and 0% packet loss (per
   VoMPLS domain) then the PSTN case achieves a rating of near 80
   which is the normal target for PSTN. The equivalent delay and PLR
   for the GSM case achieves only 60 which is rated as poor quality
   in the E-Model. It can be seen that any significant relaxation of
   the intrinsic delay or PLR leads to operations with a rating of
   less than 50 which is outside recommended planning limits.

A.2.2 Scenario 2 - Analysis of VoMPLS and Typical DCME Practice

   In the second scenario considered the network is simplified to a
   single VoMPLS core network in both Japan and the USA but the DCME
   scenario is changed to show the impact of voice activity detection


Kankkunen et al.         Expires January 2001                [Page 40]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   and downspeeding. The deployment scenario is illustrated in figure
   A-2.



                  Japan                       USA
               -----/\------               ---/\----
              /             \             /         \

              POTS----|MPLS|---|DCME|----|MPLS|---POTS



   Figure A-2: Scenario 2 - Analysis of Core VoMPLS with DCME


   The following voice processing assumptions were used:
        - DCME on the Japan to USA link uses voice activity detection
        and includes the downspeeding of the G.728 coding to 12.8
        kb/s.
        - VoMPLS domains use G.711 with packet loss concealment.
        - Wired phones are analogue with echo-cancellers deployed.


   +---------------------------------------------------|
   |                       |     | Intrinsic Delay(ms) |
   |Connection             | PLR |  09 | 20 | 50 | 100 |
   +---------------------------------------------------|
   |DCME G.728 @ 16 kb/s   | 0%  |  82 | 81 | 76 | 64  |
   |DCME G.728 @ 16 kb/s   | 0.5%|  76 | 75 | 70 | 58  |
   |DCME G.728 @ 16 kb/s   | 1%  |  72 | 71 | 66 | 54  |
   |DCME G.728 @ 12.8 kb/s | 0%  |  69 | 68 | 63 | 51  |
   |DCME G.728 @ 12.8 kb/s | 0.5 |  63 | 62 | 57 | 45  |
   |DCME G.728 @ 12.8 kb/s | 1%  |  59 | 58 | 53 | 41  |
   +---------------------------------------------------+

   Table A.3 R-Value Results for Scenario 2

   The results are presented in table A.3. It can be seen that with
   DCME downspeeding (12.8 kb/s) an intrinsic delay of 9 ms and 0%
   packet loss is in the low quality range. Any significant
   relaxation would lead to poor quality or operation outside of
   planning limits.

A.2.3 Scenario 3 - Analysis of GSM, VoMPLS and Typical DCME Practice

   In this scenario the network is simplified to a single VoMPLS
   domain in Australia and another in the USA and the analysis covers

Kankkunen et al.         Expires January 2001                [Page 41]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   the impact of typical DCME practice. In this case only 0% packet
   loss is considered. Three DCME cases are considered, G.711 (i.e.
   no DCME) G.728 at 16 kb/s and G.728 with downspeeding to 12.8
   kb/s. The DCME equipment also includes voice activity detection.
   The deployment configuration for this scenario is shown in figure
   A.3 and the resultant E-model results shown in Table A.4



                     Australia                       USA
               --------/\--------                -----/\----
              /                  \              /           \

             Mobile--|GSM|--|MPLS|-----|DCME|-----|MPLS|--POTS


   Figure A-3: Scenario 3 - Deployment of VoMPLS Core Networks

   The voice processing assumptions are as follows:
        - VoMPLS domains use G.711 with packet loss concealment.
        - Wired phones are analogue with echo-cancellers deployed.

   +-------------------------------------------------------------|
   |                                 |     | Intrinsic Delay(ms) |
   |Connection                       | PLR |  09 | 20 | 50 | 100 |
   +-------------------------------------------------------------|
   |G.711 no DCME,GSM User           | 0%  |  65 | 62 | 55 | 45  |
   |G.711 no DCME,PSTN User          | 0%  |  63 | 59 | 51 | 40  |
   |G.728 @ 16kb/s DCME, GSM User    | 0%  |  54 | 51 | 45 | 36  |
   |G.728 @ 16kb/s DCME, PSTN User   | 0%  |  51 | 48 | 40 | 30  |
   |G.728 @ 12.8kb/s DCME, GSM User  | 0%  |  44 | 38 | 32 | 23  |
   |G.728 @ 12.8kb/s DCME, PSTN User | 0%  |  38 | 35 | 27 | 17  |
   +-------------------------------------------------------------+

   Table A.4 R-Value Results for Scenario 3


   The results of the analysis are presented in Table A.4. The GSM
   listener receives better QoS than the PSTN listener as a result of
   the asymmetrical operation of echo handling. Echo generated at the
   2-4 wire conversion in the PSTN side is removed by an echo
   canceller whereas the GSM side, being 4-wire throughout, relies on
   the terminal coupling loss achieved by the handset itself to
   control any acoustic echo. For this calculation a weighted
   terminal coupling loss of 46 dB is assumed for the terminal. It
   can be seen by inspection that it is difficult to provide
   acceptable QoS for GSM calls on Global Reference Connections. DCME
   is typical practice in this case.

Kankkunen et al.         Expires January 2001                [Page 42]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000






A.2.4 VoMPLS Core Network Summary

   The deployment of multiple VoMPLS islands interworking via the
   conventional PSTN will be a natural consequence of switch
   deployment practice. A carrier wishing to deploy VoMPLS as a PSTN
   solution would wish to continue normal investment to cope with
   growth and retiring obsolete equipment. This will lead to multiple
   VoMPLS islands within a single carriers' network as well as
   islands which arise due to calls which are routed through multiple
   operators. It is possible to deploy equipment intelligently and to
   plan routing to avoid excessive numbers of islands, but if
   deployment is driven by growth and obsolescence then the
   transition to a full VoMPLS solution will take 15 to 20 years,
   during which time multiple islands will be the normal situation.
   Solutions, which lead to retrofit requirements in order to solve
   QoS problems, are very unlikely to be cost effective. Therefore to
   enable operation with such network configurations it will be
   necessary for each VoMPLS core network domain to be able to
   achieve an intrinsic delay in the order of 10 ms and negligible
   packet loss.


A.3 Extending VoMPLS into the Access Network


   The following scenarios analyse the impact of extending VoMPLS
   into the access network.

A.3.1 Scenario 4 - VoMPLS Access on USA to Japan

   In this scenario the core network comprises 2 MPLS networks in USA
   plus 2 MPLS networks in Japan linked by sub cable which may have
   DCME employed.  The intrinsic delay within each core MPLS network
   is set to 10 ms delay and zero packet loss is assumed.  The
   encoding scheme used is G.711 throughout. Figure A.4 illustrates
   the deployments analysed. Four cases are considered:

       (A) MPLS access network each end,  full echo control, no DCME
       (B) MPLS access network each end,  no echo control, no DCME
       (C) MPLS access network one end; analogue PSTN other end, full
           echo control,  DCME  @32kb/s

       (D) MPLS access network one end; Analogue PSTN other end, full
           echo control, no DCME



Kankkunen et al.         Expires January 2001                [Page 43]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





                Case A & B:

    TE --|MPLS|---|MPLS|--|MPLS|---------|MPLS|--|MPLS|--|MPLS|--TE

   Dig.  Access    Core    Core SUB-cable Core    Core   Access  Dig



                Case C & D:

   TE --|CO|---|MPLS|--|MPLS|-----------|MPLS|--|MPLS|--|MPLS|--TE

   An   PSTN   Core    Core   SUB-cable  Core    Core   Access  Dig


   Figure A.4 Scenario 4 - Impact of VoMPLS Access Systems


   The results for the analysis are shown in Table A.5 which provides
   results for various access delays (per access domain). For cases A
   and  B the performance is symmetrical (digital terminals have
   identical performance) whereas for cases C and D the performance
   is slightly different at each end due to the different nominal
   loudness ratings of the analogue and digital terminals. The
   figures in the table refer to the listener at the analogue PSTN
   terminal - the performance at the digital terminal is slightly
   worse by about 5 points.


   Table A.5 R-Values for Scenario 4

   Delay - ms  |        10      20      50      100     150
   ------------|--------------------------------------------
   Case (A)    |        92.8    91.9    83.9    73.4    65.9
   Case (B)    |        80.8    77.9    67.9    54.0    44.3
   Case (C)    |        84.1    83.0    79.4    73.4    68.3
   Case (D)    |        93.6    93.0    90.2    84.2    75.8

   The results show that if the MPLS access delay is restricted to 50
   ms or below generally satisfactory results can be achieved for
   most scenarios.







Kankkunen et al.         Expires January 2001                [Page 44]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




A.3.2 Scenario 5 Deployment of GSM and VoMPLS Access

   In this scenario the core network comprises 2 MPLS networks in USA
   plus 1 MPLS network and a mobile network in Australia linked by
   sub cable which does not have DCME employed. Each core MPLS
   network has 10 ms intrinsic delay and zero packet loss.  Encoding
   G.711 throughout MPLS domains. Figure A.5 illustrates the
   deployments analysed. Five cases are considered:

   E - Mobile = GSM FR codec,  full echo control, no DCME
   F - Mobile = GSM FR codec, no echo control, no DCME
   G - Mobile = GSM EFR codec,  full echo control, no DCME
   H - Mobile = GSM EFR codec, no echo control, no DCME


   TE --|MPLS|---|MPLS|--|MPLS|-----------|MPLS|--|MPLS|--|GSM|--TE

   Dig   Access   Core    Core  SUB-cable   Core   Core   Access  Dig

   Figure A.5 Scenario 5 - VoMPLS Access with GSM


   The results from the E-model analysis are given in Table A.6.


   Table A.6 R-Values for Scenario 5


   Delay - ms   |       10      20      50      100     150
   -------------|-------------------------------------------
   Case (E)     |       73.3    72.7    69.8    63.7    58.1
   Case (F)     |       61.7    60.5    55.9    47.6    40.1
   Case (G)     |       88.3    87.7    84.8    78.7    73.1
   Case (H)     |       76.7    75.5    70.9    62.6    55.1

   Again the results show that MPLS access delays should be
   restricted to the order of 50 ms or below. The results also
   highlight the advantage of using the GSM EFR codec over the GSM FR
   codec and that even when working fully digital full echo control
   provides a measurable benefit.

A.3.3 VoMPLS Access Summary

   The scenarios show that for VoMPLS access systems the intrinsic
   delay should be kept to the order of 50 ms per access domain or
   below to achieve acceptable voice quality for the majority of
   connections.


Kankkunen et al.         Expires January 2001                [Page 45]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




A.4 Effects of Voice Codecs in  the access network

   In the final scenarios the impact of deploying voice codecs within
   the access network is considered.

A.4.1 Scenario 6 - Deployment of Codecs in one Access Leg (USA -
Japan)

   Again the core network comprises 2 MPLS networks in USA plus 2
   MPLS networks in Japan linked by sub cable which has no DCME
   employed.  Each core MPLS network has 10 ms intrinsic delay and
   zero packet loss.  Encoding is G.711 throughout the core network.
   A fixed delay of 50ms and zero packet loss is assumed in the
   access MPLS network. The configuration is illustrated in figure
   A.6.

   TE --|CO|---|MPLS|--|MPLS|-----------|MPLS|--|MPLS|--|MPLS|--TE

   An   PSTN    Core    Core  SUB-cable  Core    Core   Access  Dig
        (2ms)  (10ms)  (10ms)           (10ms)  (10ms)  (50ms) (var)


   Figure A.6 Scenario 6 - Effects of Codecs in one Access Leg

   The results for various voice codec deployments are presented in
   Table A.7 which provides the R-values as experienced by the user
   of the PSTN and the MPLS access system.

   Table A.7 - R-values for Scenario 6

   Connection                           |PSTN   |MPLS   |
   ------------------------------------------------------
   G.711 to G.711                       | 88.9  | 84.6  |
   G.711 to G.729A + VAD (8kb/s)        | 73.7  | 69.9  |
   G.711 to G.723A + VAD (6.3kb/s)      | 62.4  | 58.0  |
   G.711 to G.723A + VAD (5.3kb/s)      | 58.4  | 54.0  |
   G.711 to GSM-FR                      | 61.7  | 57.3  |
   G.711 to GSM-EFR                     | 76.7  | 72.3  |

   The results show asymmetrical performance due to the different
   nominal loudness ratings of the analogue and digital terminals.
   Generally acceptable performance is attained although the
   performance for the low bit rate G.723 coding scheme is marginal.
   In these examples since VoMPLS access is used for one leg of the
   connection only transcoding is performed once.




Kankkunen et al.         Expires January 2001                [Page 46]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




A.4.2 Scenario 7 - Codec Deployment in both Access Legs (USA - Japan)

   The deployment configuration for this scenario is as scenario 6
   with the exception that MPLS access systems are used at both ends.
   The configuration is illustrated in figure A.7. and the resultant
   R-values provided in Table A.8

   TE --|MPLS|---|MPLS|--|MPLS|---------|MPLS|--|MPLS|--|MPLS|--TE

   Dig   Access    Core    Core SUB-cable Core    Core   Access  Dig
  (var)  (50ms)   (10ms)  (10ms)         (10ms)  (10ms)  (50ms) (var)


   Figure A.7 Scenario 7 - Codec Deployment in Both Access Legs


   Table A.8 R-value Results for Scenario 7


   Connection                                   |R-value
   ------------------------------------------------------
   G.711 to G.711                               | 83.9  |
   G.729A+VAD to G.711 to G.729A+VAD (8.0kb/s)  | 54.2  |
   G.729A+VAD (8.0kb/s) tandem free operation   | 68.9  |
   G.723A+VAD to G.711 to G.723A+VAD (6.3kb/s)  | 36.2  |
   G.723A+VAD (6.3kb/s) tandem free operation   | 58.6  |
   GSM-FR to G.711 to GSM-FR                    | 31.7  |
   GSM-FR tandem free operation                 | 57.2  |
   GSM-EFR to G.711 to GSM-EFR                  | 61.7  |
   GSM-EFR tandem free operation                | 72.2  |


   The benefits of eliminating transcoding - tandem free operation
   (TFO) - can be clearly seen from these results. Further it can be
   seen that the performance attained by low bit rate G.723 is
   extremely poor when transcoding is performed at both access
   gateways.

A.4.3 Scenario 8 Codec Deployment and Mobile Access (USA - Australia)

   The core network comprises 2 MPLS networks in the USA plus 1 MPLS
   network and a mobile network in Australia linked by sub cable
   which does not have DCME employed.  Each core MPLS core network
   has 10 ms intrinsic delay and zero packet loss. The access network
   has 50ms delay and zero packet loss. Full echo control is
   employed. For the UMTS mobile network, a delay of 60ms and an
   codec impairment factor (Ie) of 5 is assumed based on the



Kankkunen et al.         Expires January 2001                [Page 47]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   predicted performance of the GSM AMR codec. The results are
   provided in table A.9


   TE --|MPLS|--|MPLS|--|MPLS|---------|MPLS|--|MPLS|--|UMTS|--TE

   Dig   Access   Core    Core SUB-cable Core    Core   Mobile  Dig
  (var)  (50ms)  (10ms)  (10ms)         (10ms)  (10ms)  (60ms) (var)


   Figure A.8 Scenario 8 - Codec Deployment and Mobile Access


   Table A.9 - Results for Scenario 8

   Connection                   | R-value
   ---------------------------------------
   UMTS to G.711                | 78.7
   UMTS to G.729A via G.711     | 63.9
   UMTS to G.723A via G.711     | 53.6
   UMTS to GSM-EFR              | 69.3
   UMTS to UMTS -
                - TFO           | 76.6

   Again these results highlight the significant benefit arising from
   the use of tandem free operation.


A.4.4 Voice Codec Summary

   The scenarios in this section highlight the critical impact that
   the voice coding scheme deployed in the access network will have
   on the overall voice quality. For international reference
   connections acceptable voice quality may not be attained with some
   of the very low bit rate codecs. The benefits of avoiding
   transcoding wherever possible can also clearly be seen.

A.5 Overall Conclusions

   The following key conclusions may be drawn from the study:

        For VoMPLS core networks, per domain the intrinsic delay
        should not exceed 10 ms and the packet loss should be
        negligible.

        When MPLS is extended to the access domain (in conjunction
        with the use of digital terminals) an additional 50 ms per
        access domain may be tolerated.


Kankkunen et al.         Expires January 2001                [Page 48]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




        Wherever possible codec compatibility between the end-
        terminals should be negotiated to avoid the requirement for
        transcoding.

        Where terminal compatibility cannot be achieved transcoding
        should be limited to one function per connection.

        Low bit rate G.723 coding should be avoided unless
        transcoderless operation can be attained.








































Kankkunen et al.         Expires January 2001                [Page 49]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000






   ANNEX B - Service Requirements on VoMPLS

B.1 Voice Service Requirements

   This section covers generic voice service requirements. These same
   considerations would apply in any voice network and this section
   has nothing specific to VoMPLS.

   Annex A provides one example of a quantitative approach to voice
   call quality assessment. This Annex is provided for information
   purposes only.

   The call quality as perceived by the end user of the VoMPLS
   service is influenced by a number of key factors including delay,
   packet loss (and its impact on bit error), voice encoding scheme
   (and associated compression rates), echo (and its control) and
   terminal quality. It is the complex interaction of these
   individual parameters that defines the overall speech quality
   experienced by the user.

   VoMPLS work should define one or more voice service types, the
   most obvious ones being a voice service which is comparable to the
   service provided by the existing PSTN or a voice service which is
   lower quality than the existing PSTN but could be provided at a
   lower cost. For each service type quantitative performance
   objectives for the parameters defined in this section need to be
   determined.


B.1.1 Voice Encoding

   The VoMPLS network should be capable of supporting a variety of
   voice encoding schemes (and associated voice compression rates)
   ranging from 64kb/s G.711 down to low-bit rate codecs such as
   G.723. The applicability of an individual voice encoding algorithm
   and associated voice compression rate is dependent on the
   particular network deployment.

   The impact of transcoding between voice encoding schemes must also
   be considered. Not only does transcoding potentially introduce
   delay but typically distortion as well - a key voice impairment
   factor. Whilst transcoding is sometimes an inevitable consequence
   of complicated networks, wherever possible it should be avoided.

   Specific codec choices are network, service, use, and terminal
   dependent.  In many cases, no compression will be used (G.711), in

Kankkunen et al.         Expires January 2001                [Page 50]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   other cases (wireless), low bit rate compression may be used.
   VoMPLS networks shall be capable of transporting traffic with a
   variety of codecs.


B.1.2 Control of Echo

   Echo is one of the most significant impairment factors experienced
   by the user. In traditional networks echo arises from acoustic
   coupling in the terminal and impedance mismatches within the
   hybrid devices that perform the 2 to 4 wire conversion (typically)
   at the local exchange. The effect that echo has on voice-quality
   increases non-linearly as the transmission delay increases. The
   transmission delay consists of the processing delay in network
   elements and the speed of light delay.

B.1.2.1 Echo Control by Limiting Delay

   Where the one way delay between talker and listener is below 25ms
   then the effects of echo can be controlled to within acceptable
   limits if the Talker Echo Loudness Rating (TELR) complies with ITU
   G.131 Figure 1. At the limiting delay of 25ms this corresponds to
   a TELR of 33dB, which is not attainable by normal telephone
   terminals especially on short lines. The telephony network
   overcomes this limitation by assuming average length subscriber
   lines and by including 6dB of loss in the four wire path (usually
   in the receive leg) at the local exchange. In the case of ISDN
   subscribers using 4 wire terminals it is achieved by specifying
   terminals with an echo return loss of greater than 40dB. If delay
   in a VoMPLS network can be controlled, and the delay through the
   system can be limited to 25 ms, then echo cancellation may not be
   required in all equipment.  It is desirable, therefore, that MPLS
   systems be capable of creating an LSP with controlled delay.

B.1.2.2 Echo Control by Deploying Echo Cancellers

   Where either the one way delay between talker and listener exceeds
   25ms, or, for one way delays below 25ms, the TELR does not meet
   the requirements of ITU G.131 figure 1, then echo cancellers
   complying with ITU G.165/G.168 are required.

   The end-to-end delay consists of the processing delays in network
   elements and the speed of light delay.

   Typically legacy TDM networks are designed so, that when it is
   known that the origination and termination ends are close enough
   to each other (less than 25ms delay), no echo cancellation is


Kankkunen et al.         Expires January 2001                [Page 51]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   deployed. This is the case for domestic calls in many small
   countries and for local calls in larger countries.

   Echo cancellers are deployed as half cancellers so that each unit
   only cancels echo in one direction. Each unit should be fitted as
   close to the point of echo as possible in order to reduce the tail
   length over which it must operate. The tail length is the round
   trip delay from the echo canceller to the point of echo plus an
   allowance for dispersion of the echo; such allowance would
   typically be 10ms.

   Echo Cancellers will typically be located in Media Gateway devices
   under the control of a Call Agent. Call processing in the Call
   Agent may analyze service type and accumulated delay to determine
   if activation of echo cancellation is appropriate for the call in
   question.

B.1.2.3 Network Architecture implications

   There are two main mechanisms which introduce echo in the PSTN,
   namely the 2-wire to 4-wire hybrid at the local exchange, and,
   with a lesser impact, the users telephone terminal. Where the PSTN
   extends 4-wire to the users terminal, i.e. ISDN, then echo due to
   the hybrid is eliminated, and that due to the terminal itself is
   controlled by specifying such digital terminals to have a TELR
   better than 40 dB. Where a 4-wire circuit taken to the customers
   premises is converted to 2-wire so that standard terminals may be
   used, then the hybrid has been moved from the local exchange to
   the line terminating equipment on the users premises and the
   situation as regards echo is essentially the same as for the
   normal PSTN.

   PSTN networks typically have rules which determine when the
   network deploys echo cancellation equipment.  Voice over packet
   networks typically have greater delay (due to packetization and
   other buffering mechanisms) than the equivalent PSTN equipment.
   Echo cancellation in packet networks which interface to the PSTN
   may have to employ additional echo cancellation equipment to
   compensate.

   The impact of a packetised form of transport to the user would
   depend upon whether this terminated on a 4-wire ’audio' unit or
   was converted to 2-wire and a standard terminal used.

   If a standard terminal is used, then the hybrid in the terminating
   equipment should be designed to produce a TELR of at least the 33
   dB encountered in the PSTN, remembering that the 2-wire line will
   be of very short length and that the 6dB loss which the PSTN

Kankkunen et al.         Expires January 2001                [Page 52]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   introduces to increase the TELR must be accommodated (i.e. it must
   either be present or the hybrid performance must be further
   increased by this amount).

   Termination by a 4-wire ’audio' unit would depend upon the echo
   performance of this unit. If it is a 4-wire terminal designed for
   ISDN, then there should be no significant echo. (This arrangement
   is analogous to GSM mobile networks which do not use any form of
   echo cancellation device to protect users on the fixed network
   from echo  even though the mobile network has added 100-150ms
   additional delay. They do however include half echo cancellers at
   the point of interconnect to the PSTN to protect the mobile user
   from echo produced by the PSTN).

   If however the audio unit was a speaker and microphone connected
   to a personal computer, then the TELR is uncontrollable because
   there is no control of the special positioning of the speakers and
   microphone, or the acoustics of the room, and it would become
   mandatory that provision be made locally for the control of echo
   (as it is with loudspeaker telephones).

   It should be noted that echo cancellation must be performed at a
   TDM point, i.e. it cannot be performed within the packetised
   domain and that there must be no suppression of silent periods in
   the path to and from the echo canceller to the source of the echo
   because such an arrangement produces a discontinuous echo function
   and the echo canceller would be unable to converge.



B.1.3 End-to-end Delay and Delay Variation

   A key component of the overall voice quality experienced by the
   user is the end-to-end delay. As a guideline the ITU [G.114]
   specifies that wherever possible, the one-way transmission delay
   for an international reference connection should be limited to 150
   ms.  It is important to stress that the international delay budget
   is under pressure and that the 150 ms target is already broken if,
   for example, satellite links or cellular access systems are
   deployed.

   In a packet based network the end-to-end delay is made up of fixed
   and variable delays; the fixed delays include packetisation delay
   and the transmission delay whilst the variable delay is imposed by
   statistical multiplexing (and hence queuing) at each (MPLS)
   router. For voice and other real-time media the variable delay
   must be filtered at the receiving terminal by an appropriate
   jitter buffer to reconstitute the original constant rate stream.

Kankkunen et al.         Expires January 2001                [Page 53]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   Effectively this process imposes an additional connection delay
   equal to the maximum packet delay variation (i.e. this fixed delay
   is set by the 'worst' statistical delay irrespective of its rate
   of occurrence).

   Thus packet delay variation should be minimised within the VoMPLS
   network to minimise the overall one way delay as well as reducing
   costs in the end-equipment by reducing the memory requirements for
   the jitter buffer. It is desirable that the MPLS network be able
   to create an LSP with a controlled delay variation.



B.1.4 Packet Loss Ratio


   Packet loss is a key voice impairment factor.

   For voice-band connections ITU-T G.821 specifies overall
   requirements for error performance in terms of errored seconds and
   severely errored seconds. Under this definition, for the majority
   of voice encoding schemes the loss of a single VoMPLS packet will
   cause at least a single severely errored second. ITU-T G.821
   specifies an end to end SES requirement of 1 in 10^-3 - this
   requirement is predominately driven by the demands of voice-band
   data (fax, modem). Speech impairment in packetized voice networks,
   on the other hand, can be unnoticeable with fairly high packet
   loss (as high as 5% in some cases). The relationship between SES
   and packet loss is not well known.

   In networks where it is important to pass voice, modem and/or fax
   data without degradation, techniques such as controlling packet
   loss may be employed. Alternatively demodulation, data pass
   through and remodulation of fax/modem calls may be employed to
   achieve such a goal.

B.1.5 Timing Accuracy

   When determining the timing accuracy for VoMPLS domains the
   following types of traffic must be considered: speech, voice band
   data, and circuit mode data.

   All speech traffic is obtained by the equivalent of sampling the
   analogue speech signal at a nominal 8 kHz and generating linear
   PCM. This can be companded to 64 kbit/s in accordance with ITU-T
   G.711, or it can be compressed to a lower bit rate either on a
   sample-by-sample basis (e.g. ADPCM G.726/7) or on a multiple
   sample basis to produce packets (e.g. various forms of CELP).

Kankkunen et al.         Expires January 2001                [Page 54]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





   Voice band data traffic is obtained by sampling the analogue modem
   signal, i.e. low rate data modulated onto defined frequency
   carrier signals, in the same way as for speech and companding to
   64 kbit/s using G.711. Except for very low data rates compression
   is not possible.

   In all cases, provided the traffic could be carried by the VoMPLS
   packet network directly from encoder to decoder, AND the decoder
   could work on the sample rate determined from the received
   traffic, then the encoder would only need to have a frequency
   tolerance sufficient to achieve the required analogue frequency
   response and to constrain the traffic data bandwidth; thus the
   VoMPLS packet network would have no particular frequency tolerance
   requirements. (Packet jitter including delay variation would still
   have to be constrained within buffer sizes, and measures such as
   sequence numbers would still be needed to maintain accurate
   determination of the transmitter sample rate under circumstances
   of packet loss.)

   All legacy voice equipment, however, will have been designed
   assuming a synchronous TDM network; so decoders may typically be
   designed to use a sample rate derived from the locally available
   network clock. Furthermore, the packet network will have to
   interwork for the foreseeable future with the existing synchronous
   TDM network. The principle characteristic of this existing network
   is that all basic rate 64 kbit/s signals are timed by the network
   clock, and thus multiplexing into primary rate signals E1, DS1, or
   J2 has been defined in ITU-T G.704 to be SYNCHRONOUS. The
   interface to the interworking equipment will in general be the in-
   station form of these primary rate signals or possibly the primary
   rate signals multiplexed into PDH or SDH higher order multiplex
   signals.

   Primary rate signals must be within the tolerances defined in ITU-
   T G.703, e.g. +/-50ppm for E1, to permit them to be carried in the
   PDH or SDH transport networks. These tolerances allow transport
   networks to carry primary rate signals from different networks
   timed by different network clocks, e.g. private networks as well
   as public networks between which there my be little or no service
   interworking. The result of interworking between networks at the
   extremes of these tolerances is frequent slips in which octets of
   each basic rate 64 kbit/s channel are dropped or alternatively
   repeated to compensate for the rate difference.

   For example the consequences of 50ppm offset = 1 slip every 2.5
   seconds are:


Kankkunen et al.         Expires January 2001                [Page 55]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




        -0- G.711 speech - loss/gain of 1 sample, a barely audible
        click,

        -0- G.726/727 ADPCM - as for G.711 speech,

        -0- for packet based speech codecs G.723, 728, 729 - packet
        error, i.e.  multiple sample loss, more annoying click;

        -0- voice band data - a slip produces a 125 us phase shift
        for modems up to 2.4 kbit/s - probably tolerated without
        error for modems above 2.4 kbit/s - error burst each slip
        probably leading to loss of synchronization and resultant
        retraining: result is intermittent transmission, down
        speeding if possible, or complete failure;

        -0- circuit mode data - packet loss ratio dependent of client
        layer packet size, e.g. 1 in 20 for packet size of 1000
        bytes.

   To permit satisfactory interworking without the above impairments,
   the slip rate should be constrained within the limits set out in
   ITU-T G.822. This could be possible by timing the packet network
   interworking equipment in the same way as existing synchronous TDM
   network equipment, that is in a synchronization network where
   timing is traceable to a primary reference clock (PRC) of which
   the accuracy is in accordance with ITU-T G.811.

   Within the same synchronization domain, where all equipment
   derives its timing from the same PRC, except under fault
   conditions the slip rate will be zero. When traversing boundaries
   between domains of different PRCs the operation will be
   plesiochronous: the accuracy of 10exp-11 of each PRC will ensure
   the slip rate is within the normal limit in G.822 of 1 slip per
   5.8 days over a 27000 km hypothetical reference link consisting of
   13 nodes.

   Some MPLS networks may not be designed to achieve synchronous
   timing, and thus slip buffers are required in such networks, and
   compression choices may be influenced by the lack of
   synchronization in the network.

B.1.6 Grade-of-service

   In traditional circuit switched networks a clear distinction can
   be drawn between Grade of Service and Quality of Service. Grade of
   Service defines blocking probabilities for new connections (and
   behaviour rules under network overload conditions) so that a
   network can be dimensioned to achieve an expected behaviour.

Kankkunen et al.         Expires January 2001                [Page 56]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000




   Quality of Service defines the voice intelligibility requirements
   for established connections; namely delay (and jitter), error
   rates, and voice call defects. It is important that both GoS and
   QoS are addressed equally when determining the architectural
   framework for VoMPLS networks.

   Much of the work so far undertaken on traffic engineering within
   IP networks has focussed on the development of QoS mechanisms.
   Whilst such mechanisms will ensure the intelligibility of
   established voice connections without an equivalent GoS framework
   no guarantees can be made to the blocking rate experienced during
   busy network periods. At the limit this may severely impact users'
   future willingness to use the network.

   Equally if one merely dimensions the network according to GoS
   requirements without providing explicit QoS mechanisms then any
   QoS 'guarantees' are only probabilistic and there remains the
   possibility of significant packet loss rate at localised
   congestion points within the network. In a statistically
   multiplexed network when such congestion occurs it will typically
   impact other connections traversing the congested routers and is
   not simply confined to those additional connections that caused
   the overload condition.

   Generally GoS is defined on a per service basis either through
   international specification or via peer agreements between network
   operators.

   Packet networks differ from the PSTN however in that they are
   designed to support multiple services. It is a requirement that
   per-service GoS can be provided despite the diverse traffic
   characteristics of (potentially competing) multiple alternate
   services. This implies that the network operator may need to be
   able to isolate (or control the allocation of) key resources
   within the network on a per-service basis. For example an operator
   could use multiple LSPs between two points in order to enable
   trunk provisioning and per-service dimensioning.

B.1.7 Quality considerations pertaining to Session Management

   There are a number of additional quality factors that users take
   for granted in today's circuit switched network. It is reasonable
   to anticipate that similar requirements should be placed onto some
   VoMPLS networks so that from a service perspective equivalent
   performance is maintained, where that is deemed necessary. These
   factors include:

     Session Setup Delay (sometimes referred to as "post dial delay")

Kankkunen et al.         Expires January 2001                [Page 57]


Internet Draft     draft-kankkunen-vompls-fw-01.txt          July 2000





     Session Availability - This refers to the ability (or in-
     ability) of the network to establish sessions due to outage
     events (nodal, sub-network or network).

     Session Defects - This refers to defects that occur to
     individual (or groups) of sessions. The defects may be caused by
     transient errors occurring within the network or may be due to
     architectural defects. Examples of session defects include:
        - misrouted sessions
        - dropped sessions
        - failure to maintain adequate billing records
        - alerting the end-user prior to establishing a connection
        and  then not being able to establish a connection
        - clipping the initial conversation (defined by the post
        pickup delay)
        - enabling theft of service by other users





Full Copyright Statement

   "Copyright (C) The Internet Society (2000). All Rights Reserved.
   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,
   copied, published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright notice
   and this paragraph are included on all such copies and derivative
   works. However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the
   Internet Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards
   process must be followed, or as required to translate it into."












Kankkunen et al.         Expires January 2001                [Page 58]


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