A. Kankkunen Internet Draft Integral Access Document: 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, , 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 , November 1999, work in progress. 15 V. Gurbani, "Accessing IN Services from SIP Networks," Internet Draft , 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]