A. Kankkunen Internet Draft Integral Access Document: G. Ash AT&T J. Hopkins Fujitsu B. Rosen Marconi D. Stacey Nortel Networks A. Yelundur NEC L. Berger LabN Consulting Voice over MPLS Framework draft-kankkunen-vompls-fw-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document provides a Framework for using MPLS as the underlying technology for transporting IP based public voice services. Kankkunen et al. Expires September 2000 [Page 1]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 The document defines a reference model for Voice over MPLS, defines some specific applications for Voice 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 initial and incomplete version. It is being published to facilitate discussion prior to the Adelaide 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. Abstract 2. Abbreviations and Acronyms 3. Introduction 3.1 Background and motivation 3.2 Brief Introduction to MPLS 4. VoMPLS Reference Model 4.1 Reference Model Components and their roles 4.1.1 Call Agent 4.1.1.1 Media Gateway Connection Control 4.1.1.2 Call processing 4.1.1.3 Management 4.1.2 Media Gateways 4.1.3 Signaling Gateway 4.1.4 Trunk Gateway 4.1.5 Access Gateway 4.1.6 Line Side Gateway 4.1.7 Integrated Access Device 4.1.8 Voice Terminals 4.2 Data Plane 4.3 Control Plane 5. VoMPLS Applications 5.1 Trunking Between Gateways 5.1.1 Encapsulation Requirements for Efficient Multiplexed Trunk 5.2 Circuit Emulation over MPLS 5.3 VoMPLS on Slow Links Kankkunen et al. Expires September 2000 [Page 2]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 5.4 Voice Traffic Engineering using MPLS 5.4.1 Off-Line Voice traffic engineering Aspects 5.4.2 Connection Admission and/or Connection Routing 5.4.3 Dynamic Traffic Management 5.5 Providing End-to-end QoS for Voice Using MPLS 6. Requirements for Call Control Protocols 6.1 Megaco/H.248 6.2 MGCP 6.3 SIP 6.4 H.323 6.5 Q.1901 (Bearer-independent call control) 7. Requirements for MPLS Signaling 7.1 LDP and CR-LDP 7.2 RSVP-TE 8. Requirements for Other Work 9. Security Considerations 10. Acknowledgements 11. References 12. Author's Addresses ANNEX A - E-Model analysis of the Voice over MPLS Reference Model A.1 Introduction A.2 Deployment of VoMPLS within the Core Network A.2.1 Scenario 1 - Effect of Multiple MPLS Domains A.2.2 Scenario 2 - Analysis of VoMPLS and Typical DCME Practice A.2.3 Scenario 3 Analysis of GSM, VoMPLS and Typical DCME Practice A.2.4 VoMPLS Core Network Summary A.3 Extending VoMPLS into the Access Network A.3.1 Scenario 4 - VoMPLS Access on USA to Japan A.3.2 Scenario 5 Deployment of GSM and VoMPLS Access A.3.3 VoMPLS Access Summary A.4 Effects of Voice Codecs in the access network A.4.1 Scenario 6 - Deployment of Codecs in one Access Leg (USA - Japan) A.4.2 Scenario 7 - Codec Deployment in both Access Legs (USA - Japan) A.4.3 Scenario 8 Codec Deployment and Mobile Access (USA - Australia) A.4.4 Voice Codec Summary A.5 Overall Conclusions ANNEX B - Service Requirements on VoMPLS B.1 Voice Service Requirements B.1.1 Voice Encoding B.1.2 Control of Echo B.1.2.1 Echo Control by Limiting Delay B.1.2.2 Echo Control by Deploying Echo Cancellers B.1.2.3 Network Architecture implications B.1.3 End-to-end Delay and Delay Variation B.1.4 Packet Loss Ratio Kankkunen et al. Expires September 2000 [Page 3]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 B.1.5 Timing Accuracy B.1.6 Grade-of-service B.1.7 Quality considerations pertaining to Session Management B.2 Circuit Emulation Service Requirements B.2.1 General Requirements B.2.1.1 Signals for circuit emulation B.2.1.2 Timing B.2.1.3 Applicability of Timing Options B.2.2 QoS Requirements for Circuit Emulation B.2.2.1 Jitter and Wander B.2.2.2 Delay B.2.2.3 Error Performance 2. 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) MPLS Multi Protocol Label Switching PABX Private Automatic Branch Exchange PSTN Public Switched Telephone Network SG Signaling Gateway SIP Session Initiation Protocol 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 Voice over MPLS Kankkunen et al. Expires September 2000 [Page 4]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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]. 3. Introduction The purpose of this draft is to provide a common reference point for the operation of voice over MPLS and to identify any needed related standardization work. Depending on the application, the voice encapsulation used in VoMPLS can be either voice/RTP/UDP/IP/MPLS or voice/TBD/MPLS, where TBD is a new efficient encapsulation which is to be defined as part of the VoMPLS work. The purpose of the TBD encapsulation 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 characteristic. Finally, LSPs should be able to be created with Circuit Emulation characteristics (Private Line facility emulation). 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. The technology should also be usable for growth and retrofit of existing voice, leased-line and other current service networks in order to achieve the multi-service objectives for next generation networks. This draft consists of three main sections: VoMPLS Reference Model, VoMPLS Applications and Definition of the required VoMPLS standardization work. Section 4 defines a reference model for VoMPLS. Section 5 defines applications where MPLS can be the enabling technology for supporting voice in an IP-infrastructure. Kankkunen et al. Expires September 2000 [Page 5]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 Sections 6 and 7 define the new VoMPLS related standardization that needs to take place in order to support the applications defined in Section 5 within the reference model of Section 4. 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. 3.1. Background and motivation MPLS is being introduced into IP networks to support Internet Traffic Engineering and other applications. The motivation for Voice over MPLS is to take advantage of this network capability to improve voice-over-packet service by: - using label-switched-paths as a bearer capability for packetized voice thereby providing more predictable, and even constrained QoS, - providing a more efficient transport mechanism for packetized-voice possibly using header compression or suppression, - reducing the complexity of multiple connection-control planes in multi-service networks by converging on the use of MPLS, - leveraging other advantages of MPLS, e.g. Layer 2 independence, integration with IP routing and addressing, etc. 3.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. Kankkunen et al. Expires September 2000 [Page 6]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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 [5], [6], [7], [16], [17] and [18]. 4. VoMPLS Reference Model +--+ +------------+ +--+ +---------------------+ |CA|-| |<--|TG|-->| | +--+ | | +--+ | | | | | | | IP/MPLS | +--+ | Circuit-Switched | +--+ | Network |<--|SG|-->| Network (e.g. PSTN)| |CA|-| | +--+ | | +--+ | | | | +------------+ +---------------------+ ^ ^ +---+ | | | |AG/| +---+ | +--->|IAD|<---+ |LSG| | +---+ | +---+ | | | MG=AG/IAD or TG | | +-------+ | | |IP/MPLS| | | |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 MPLS Reference Model 4.1. Reference Model Components and their roles The model used for VoMPLS 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 Kankkunen et al. Expires September 2000 [Page 7]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 function that converts a voice (or other media stream such as video) into a packet stream. 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. For VoMPLS, each gateway would have at least one MPLS interface. 4.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. 4.1.1.1 Media Gateway Connection Control 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 label switched path, 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. 4.1.1.2 Call processing Call processing in a Call Agent provides call control functions and may provide connection 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]). Kankkunen et al. Expires September 2000 [Page 8]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 Connection control establishes, modifies and releases logical connections between all reference model components. MPLS LDP [16], RSVP-TE [17] and CR-LDP [18] are examples of connection control protocols in a Voice over MPLS network, in which logical connectivity is provided by label switched paths. Connection control (bearer control in ITU-T terminology) is a subordinate activity, which may result from call control events such as receipt of setup message or on-hook/off-hook detection. 4.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 Voice over MPLS network components. 4.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 Voice over MPLS Media Gateway includes the following functions: - 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. Bearer connections are usually label switched paths, but fallback to connectionless IP is a requirement in order to handle cases where the peer-gateway is not MPLS-capable, is an IP voice- terminal, etc. 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. The MPLS Forwarding Information Base e.g. based on MPLS protocol exchanges defines the relationship between that IP address and a label. Two possible modes of operation are foreseen. (a) The MG is an MPLS signaling endpoint and can initiate LSP establishment using LDP, CR-LDP or RSVP-TE as required. (b) An NMS or some other off-line entity provisions a pool of label-switched-path trunks Kankkunen et al. Expires September 2000 [Page 9]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 on behalf of the MG and a FIB is downloaded to each Gateway. Multiplexed LSPs may be used to share an LSP with multiple media streams passing between (or through) two VoMPLS gateways. - 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 labeling/de-labeling packetized audio samples using the IP address and label indicated for the call by the Call Agent and FIB. The format of labeled voice packets is the subject of a subsequent draft [TBD]. 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. 4.1.3 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 Voice over MPLS 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 Kankkunen et al. Expires September 2000 [Page 10]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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 Gateways in VoMPLS systems are identical to, and use the same mechanisms as similar capability in VoIP systems. In particular, signaling protocols use IP transport (which may transit MPLS LSPs) such as UDP, TCP or SCTP[19]. 4.1.4 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 VoMPLS 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. 4.1.5 Access Gateway An Access Gateway (AG) is a type of Media Gateway intended to exist on the edge of a public MPLS network, and connect multiple subscriber circuits (such as PBXs) to a VoMPLS 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. 4.1.6 Line Side Gateway A Line-Side Gateway (LSG) is a type of media gateway designed to provide "emulated local loop" capability where a VoMPLS 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 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. 4.1.7 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 Kankkunen et al. Expires September 2000 [Page 11]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 an MPLS interface as an uplink to a public MPLS network that carries the voice and data. 4.1.8 Voice Terminals Voice terminals form the interface between the human user and the telecommunications infrastructure. 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. 4.2. Data Plane The data format for VoMPLS is defined in another document [TBD]. The requirements for the Data Plane are: - Provide a transparent path for VoIP bearers (RTP flows). - 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. - Provide an optional method to specify a "Circuit Emulation" LSP, which would provide a method to implement "Private Line" service. The data plane may be functionally broken down into - Kankkunen et al. Expires September 2000 [Page 12]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 - Voice Encoding [audio signals into digital format - G.711, 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] - Timing [] - 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] 4.3. Control Plane The control plane may be broken down into two entities - Bearer control & Call control. Bearer control protocols include LDP, CR- LDP & RSVP. Call control protocols include H.323, SIP and Q.1901. Joining the two, when Call Agents are physically separated from media gateways are media gateway control protocols such as Megaco and MGCP. 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. Bearer control relies to some extent on the information gathered by call control protocols to set-up LSP between edge routers or Voice gateways / IADs. CR-LDP & RSVP-TE signaling protocols may be used to set-up LSPs based on certain constraints like QoS requirements, traffic class type & resource class type. Voice Kankkunen et al. Expires September 2000 [Page 13]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 traffic engineering can also be accomplished by using CR-LDP & RSVP-TE by specifying the actual path to be taken by the LSP between voice gateways / IADs and may be different from the path calculated by routing protocols. A capability to signal use of VoMPLS stack (as opposed to ip/mpls stack) is needed, so that LSRs don't try and interpret the stack as IP and drop traffic, try to generate ICMP messages, etc. Similarly a way to signal multiplexing of Voice over MPLS and ip/mpls traffic on a single LSP using some multiplexing scheme is needed. The VoMPLS Control plane is IDENTICAL to a VoIP control plane with respect to call control (Call Agent) operation. The VoMPLS control plane for bearer control must provide the Call control function the ability to: - create a new LSP for VoMPLS - use an existing multiplexed LSP and create a new subchannel - specify the QoS to be applied to new LSP, or change the QoS on an existing LSP - specify the bandwidth to be allocated to a new LSP, or change the bandwidth on an existing LSP 5. VoMPLS Applications 5.1. Trunking Between Gateways MPLS LSPs can be used for providing the trunks between the various gateways defined in Section 4. 5.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. 5.2 Circuit Emulation over MPLS Kankkunen et al. Expires September 2000 [Page 14]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 Circuit emulation is the provision by the packet network of LSPs equivalent to circuits in the PSTN where no call handling functionality is used, i.e. no signaling termination and processing, call routing, or circuit switching. Some circuits in the PSTN may have restricted capabilities, e.g. speech only, but a packet network should emulate an unrestricted capability. 5.3. 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 mechanism of section 5.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]. 5.4 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. Kankkunen et al. Expires September 2000 [Page 15]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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. 5.4.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 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 Kankkunen et al. Expires September 2000 [Page 16]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 required. VoMPLS work may motivate some mechanisms but implementing such mechanisms is out of scope of the VoMPLS work. 5.4.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 Call Agent is aware of LSP usage, and tracks bandwidth consumption, either using admission control to restrict new calls, or signaling MGs to create new LSPs when bandwidth in an existing LSP is committed. VoMPLS systems where the MG tracks LSP usage is also possible, with the MG determining when new LSPs must be created, and informing the CA when it is unable to do so. 5.4.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 Kankkunen et al. Expires September 2000 [Page 17]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 - 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. 5.5 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 voice over MPLS reference connection is shown in Figure 2 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 consisting of access domains and core network domains. In Figure 2 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 voice over MPLS operation. Kankkunen et al. Expires September 2000 [Page 18]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 1 - End-to-End Reference Connection 6. Requirements for Call Control Protocols 6.1. Megaco/H.248 Kankkunen et al. Expires September 2000 [Page 19]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 A new bearer definition must be provided for Megaco in the form of an MPLS package, which would define an extension to SDP to describe an MPLS bearer, an addition to Annex C to describe an MPLS bearer, and a set of additional statistics appropriate to LSPs. 6.2. MGCP The extension to SDP defined in section 6.1 would constitute the required additions to MGCP to allow it to specify a VoMPLS bearer. 6.3 SIP The extension to SDP defined in section 6.1 would constitute the required additions to SIP to allow it to specify a VoMPLS bearer. An option tag must be defined and registered with IANA to allow a SIP element to discover the ability of the element to construct an LSP. 6.4 H.323 H.323 can take advantage of an IP/MPLS network between Media Gateways in two ways. (i) Establishing label switched paths between media gateways for the transport of media streams, and (ii) Use of a compressed voice/RTP/MPLS header format to improve transport efficiency. This format avoids the transport of full UDP/IP headers, which tend to be large relative to the size of audio codec samples. In a H.323 system, the Gatekeeper is the call control entity. Media streams are established in response to H.225 & H.245 signaling, with or without use of the H.323 fast start procedures. In the case of an IP/MPLS network, media stream establishment includes the use or establishment of a label-switched-path as bearer. Kankkunen et al. Expires September 2000 [Page 20]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 +----+ +-----+ +----+ |GK A| | GK B| |GK C| +----+ +-----+ +----+ | | | +-----+ +---------+ +-----+ Endpoint | | +----+ | | +----+ | | Endpoint A --| IP |--|GW X|--| IP/MPLS |--|GW Y|--| IP |-- B | Nwk | +----+ | Network | +----+ | Nwk | +-----+ +---------+ +-----+ Figure 3 Example H.323 network including MPLS LSP establishment without fast start In a H.323 system without faststart, the H.245 control channel is first established and control messages are explicitly addressed to the gateways. Following Capability Exchange & Master/Slave exchange phases, logical channels can be opened for the transport of media streams. MPLS-enabled gateways can use the information in these messages to establish label-switched-paths in support of media streams. Therefore MPLS capability should be determined during capability exchange. Extensions to H.245 Capability Exchange and OpenLogical Channel structures must be defined to allow negotiation and specification of a VoMPLS bearer. In the case of a decomposed H.323 system, the MGCP or H.248/megaco protocol extensions to support label- switched-path bearers are also needed. LSP establishment with fast start The H.323 fast connect procedure provides connection setup without waiting for H.245 control channel establishment. The procedure is initiated by inclusion of a fastStart element in the H.225.0 SETUP message, consisting of proposed options for the forward and reverse channels on the respective OpenLogicalChannel elements. An MPLS-capable Gateway may initiate the establishment of label- switched-paths in support of media streams. Extensions to H.245 Capability Exchange, fastStart elements and OpenLogical Channel structures must be defined to allow negotiation and specification of a VoMPLS bearer. In the case of a decomposed H.323 system, the MGCP or H.248/megaco protocol extensions to support label-switched-path bearers are also needed. 6.5 Q.1901 (Bearer-independent call control) Kankkunen et al. Expires September 2000 [Page 21]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 Q.1901 [13](previously known as Q.BICC) is a call control protocol from ITU-T SG11 to support the migration of the full range of public telephony services to a packet-based infrastructure. E.g. POTS, ISDN, mobility, 800/888/877-number toll-free, 900-number information services, CLASS, Centrix, ISDN BRI & PRI, Intelligent Network, Emergency/911, etc. to packet based networks, As such it is primarily of interest to existing operators of those services. Q.1901 is a derivation of ISUP [TBD]. Capability Set 1 supports ATM AAL1 & AAL2 as a connection/bearer network. Later versions will provide support for Internet Protocol bearer networks. In Q.1901 terminology, ISNs (equivalent to a Media Gateway and associated Call Agent) include a bearer control function (BCF-N) that can initiate (or use a pool of) connections/bearers to a peer ISN, possibly traversing intermediate Switching Nodes (SWN). The SWN nodes provide a switching function and may include a Bearer Control Relay Function (BCF-R) that establishes connectivity through the SWN and relays the bearer connection signaling request to the next SWN in order to complete edge-to-edge connection across the backbone. Call-control and bearer-control are co-ordinated with the aid of Bearer-Network Connection Identifiers (BNC-ID) and Bearer- Interworking Function Addresses (BIWF-Address). This information is carried as parameters in Q.1901 messages, as well as information on the 'Bearer Characteristics'. Q.1901 supports allocation of bearers both using a connection/bearer setup protocol and from a pool of reserved bearers. +--------+ +----------+ +----------+ +--------+ | ISDN-A | | ISN-A | | ISN-B | | ISDN-B | | | | | | | | | | | | +------+ | | +------+ | | | | |<->| |CSF-N | |<---CSF-R-->| |CSF-N | |<->| | | TDM | + +------+ | | +------+ | | TDM | | Switch | | | | (SWN) | | | | Switch | | | | +------+ | +------| + +------+ | | | | | | |BCF-N | | |BCF-R | | |BCF-N | | | | | | | +------+ | +------+ | +------+ | | | | | | |fabric| | |fabric| | |fabric| | | | | | | +------+ | +------+ | +------+ | | | +--------+ +----------+ | | +----------+ +--------+ | | | | | | | | +---------+ +------+ +-----+ +---------+ Figure 4 Q.1901 Reference Architecture (abbreviated) Kankkunen et al. Expires September 2000 [Page 22]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 Q.1901 is readily applicable to IP bearer networks. In this case the ISN consists of Trunk Gateway and associated Call Agent that is capable of instructing the Trunk Gateway of the IP address of the peer ISN. No bearer control protocol is required (IP is connectionless), so the SWN function can be realized by routers. +--------+ +----------+ +----------+ +--------+ | ISDN-A | | ISN-A | | ISN-B | | ISDN-B | | | | (=TG+CA) | | (=TG+CA) | | | | | | +------+ | Q.1901 | +------+ | | | | |<->| |CAgent| |<---------->| |CAgent| |<->| | | TDM | + +------+ | | +------+ | | TDM | | Switch | | | | (LSR) | | | | Switch | | | | +------+ | +------| + +------+ | | | | | | |MPLS-E| | |MPLS-C| | |MPLS-E| | | | | | | +------+ | +------+ | +------+ | | | | | | |fabric| | |fabric| | |fabric| | | | | | | +------+ | +------+ | +------+ | | | +--------+ +----------+ | | +----------+ +--------+ | | | | | | | | +---------+ +------+ +-----+ +---------+ Figure 5 Q.1901 Call Control & MPLS bearer network Q.1901 is readily applicable to MPLS bearer networks. In this case the ISN consists of Trunk Gateway and an associated Call Agent capable of instructing the Trunk Gateway of the BIWF of the peer ISN, and possibly other parameters that can be used by CR- LDP/RSVP-TE. Core label switch routers realize the SWN function. The Trunk Gateway acts as LDP/CR-LDP/RSVP-TE signaling end-point, either to establish a Label-Switched-Path per-call or to establish trunks between Gateways that can support multiple simultaneous calls. In the latter case a multiplexing identifier (similar to AAL2 CID) can be used on the LSP to identify individual multiplexed voice connections within the trunk. Extensions to Q.1901 are required to support MPLS Label Switched Paths as bearers. In particular: - - BNC Characteristics: MPLS LSP should be supported as a bearer type - BIWF Address: An IPv4 or IPv6 address must be usable to identify the address of the connection control processing function in a peer Call Agent / Media Gateway Controller, i.e. the address for MPLS signaling exchanges. - Bearer Network Connection Identifier: MPLS Label values (plus Voice over MPLS multiplexing identifiers when appropriate) Kankkunen et al. Expires September 2000 [Page 23]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 must be usable as BNC-ID. Note that BNC-ID is currently restricted to 4-octets. (Note: Q.1901 CS1 is designed to use the existing MTP signaling network as transport, or an MTP3b-based ATM-based signaling network. If Q.1901 is to operate over an IP signaling transport e.g. between Call Agents and Signaling Gateways, then an appropriate application-layer framing protocol (signaling transport converter) is required. SCTP is already identified as a candidate signaling transport protocol for use on IP networks (in CS2), as is SSCOP-multi-link.) 7. Requirements for MPLS Signaling 7.1. LDP and CR-LDP TBD 7.2. RSVP-TE TBD 8. Requirements for Other Work 9. Security Considerations 10. Acknowledgements 11. 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 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 "A Framework for Multiprotocol Label Switching", R. Callon et al., work in progress, , September 1999 6 "Multiprotocol Label Switching Architecture", Eric C. Rosen et al., work in progress, draft-ietf-mpls-arch-06.txt, August 1999 Kankkunen et al. Expires September 2000 [Page 24]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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-berger-mpls-hdr-comp-00.txt, January 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-04.txt, September 1999 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 Kankkunen et al. Expires September 2000 [Page 25]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 12. Author's Addresses Gerald R. (Jerry) Ash AT&T Labs Room MT E3-3C37 200 Laurel Avenue Middletown, NJ 07748 USA John Hopkins Fujitsu 2 Longwalk Road, Stockley Park, Uxbridge, Middlesex. UB11 1AB, UK. Email: J.Hopkins@fujitsu.co.uk Antti Kankkunen Integral Access 6 Omni Way Chelmsford MA, 01824 USA 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 September 2000 [Page 26]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 ANNEX A - E-Model analysis of the Voice 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 'satisified' 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 September 2000 [Page 27]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 28]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 29]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 30]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 figure 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: - MSF 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 September 2000 [Page 31]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 32]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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. A.3.2 Scenario 5 Deployment of GSM and VoMPLS Access Kankkunen et al. Expires September 2000 [Page 33]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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. A.4 Effects of Voice Codecs in the access network Kankkunen et al. Expires September 2000 [Page 34]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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 September 2000 [Page 35]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 Kankkunen et al. Expires September 2000 [Page 36]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 codec impairment factor (Ie) of 5 is assumed based on the 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 September 2000 [Page 37]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 38]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 other cases (wireless), low bit rate compression may be used. Kankkunen et al. Expires September 2000 [Page 39]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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 deployed. This is the case for domestic calls in many small countries and for local calls in larger countries. Kankkunen et al. Expires September 2000 [Page 40]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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 introduces to increase the TELR must be accommodated (i.e. it must Kankkunen et al. Expires September 2000 [Page 41]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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. Effectively this process imposes an additional connection delay Kankkunen et al. Expires September 2000 [Page 42]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 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 September 2000 [Page 43]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 44]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 45]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 September 2000 [Page 46]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 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 B.2 Circuit Emulation Service Requirements This section covers generic circuit emulation service requirements. These same considerations would apply in any packet network and this section has nothing specific to VoMPLS. B.2.1 General Requirements The objective of circuit emulation is to carry a constant bit rate traffic signal between originating and destination points without loss or modification whatever the content of the signal. In general nothing would be known about the content other than the bit rate, its timing, and possibly the phase of an 8 kHz frame boundary. This capability shall be optional. B.2.1.1 Signals for circuit emulation Circuits to be emulated consist of those capable of carrying the signals listed below. - Basic rate 64 kbit/s with 8 kHz (octet) structure; - basic rate 64 kbit/s with 8 kHz (octet) structure plus channel associated signaling (CAS) bit channels ABCD E1 - 4x500 bit/s, - DS1 4x333 bit/s, J2 1x1000 bit/s (A only); multiple basic rate Px64 kbit/s with 8 kHz frame structure, where P=2-30, e.g. P= 2, 6, 24, or 30 in ITU-T I.231 (128 kbit/s, H0 - 384 kbit/s, H11 - 1536 kbit/s, H12 - 1920 kbit/s). Kankkunen et al. Expires September 2000 [Page 47]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 Primary rate signals, optionally with transmission frequency tolerance: - DS1, 1544 kbit/s (+/-32ppm), - E1, 2048 kbit/s (+/-50ppm), - J2, 6312 kbit/s (+/-30ppm), Higher order PDH signals, with transmission frequency tolerance: - E3, 34368 kbit/s (+/-20ppm), - DS3, 44736 kbit/s (+/-20ppm), - E4, 139264 kbit/s (+/-15ppm)? Consideration might be given to SDH signals. SDH carriers, with transmission frequency tolerance: - STM-0, 51840 kbit/s (+/-20ppm), - STM-1, 155520 kbit/s (+/-20ppm). SDH Virtual Containers, with 2 kHz multiframe or 8 kHz frame structure, and frequency offset indicated by associated AU-n or TU-n pointer movements: - VC-11, 104 octets per 4-frame multiframe, - VC-12, 140 octets per 4-frame multiframe, - VC-2, 428 octets per 4-frame multiframe, - VC-3, 765 octets per frame, - VC-4, 2349 octets per frame. B.2.1.2 Timing There are two options for timing, asynchronous and synchronous. Since the packet network is intrinsically asynchronous it should always be possible to transmit traffic data from the TDM domain over the packet network at whatever bit rate it arrives at. It is at the destination interworking function that the choice of timing option affects what timing functions are used. Synchronous timing assumes that the signal at the originating point is timed by the network clock. At the destination end the clock is not recovered as such: the outgoing signal is timed by the local network clock. Any discrepancy between this and the clock at the originating end is compensated for by introducing 8 kHz frame slips, i.e. loss or gain of 125 us of traffic on each channel, as necessary. Kankkunen et al. Expires September 2000 [Page 48]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 With asynchronous timing the signals are assumed only to be within the relevant standard transmission frequency tolerance. At the destination end a clock recovery function determines the clock rate from the arriving packet stream. Every bit received is forwarded to the outgoing signal - no slips are introduced. The clock rate may be recovered directly from the information rate in the packet stream (this is typically related to packet rate for constant packet size), termed adaptive clock recovery (ACR). Alternatively, supplementary information may be carried, e.g. time stamps, for use in conjunction with the local network clock. The latter option should provide better control of jitter and wander; however, the overriding principle is that every bit is forwarded (no slips), and so ACR may have to be invoked on occasion in circumstances of plesiochronously operating originating and destination network clocks. B.2.1.3 Applicability of Timing Options For basic rate 64 kbit/s and Px64 kbit/s circuits only synchronous operation is applicable. For primary rate signals which carry 64 kbit/s channels in an 8 kHz frame structure synchronous or asynchronous operation is possible depending on the source timing. Signals at primary rate, however, may alternatively have asynchronous data within the 8 kHz frame structure (e.g. ATM on PDH in G.804) or may be carrying traffic without 8 kHz framing at all. In such applications any slips associated with synchronous operation that were needed to compensate for timing frequency offsets would cause an arbitrary loss or insertion of 125 us of data bits. This would result in a resynchronization procedure downstream; that is to say a much greater disturbance than to a G.711 speech channel. In TDM networks such primary rate circuits would be routed only as asynchronous traffic in the transport network (PDH or SDH) and therefore would never be subject to slips. (For paths within the same timing domain slips would not normally occur. However, under fault conditions of the synchronization network the slip rate could be very much greater than that with normal operation between domains with plesiochronous PRCs.) Hence in these applications of primary rate circuits asynchronous clock recovery in the interworking function is preferable to synchronous operation, even if the originating signal timing were known to be network clock derived. The default timing option for primary rate signals in general should therefore be asynchronous operation. Kankkunen et al. Expires September 2000 [Page 49]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 For emulation of higher order PDH circuits, these signals contain asynchronously multiplexed data and typically have framing which is not at 8 kHz. Slips that could be necessary with synchronous operation will similarly result in resynchronization downstream but in this case typically at more than one hierarchical level. Hence asynchronous clock recovery in the interworking function is preferable to synchronous operation, even if the originating signal timing were known to be network clock derived. Higher order PDH signals are typically timed by free running oscillators: in this case asynchronous operation at the interworking function is essential. SDH carriers, while having 8 kHz framing also have data which is effectively asynchronously multiplexed by the use of pointers. Slips could result in pointer errors. Hence asynchronous clock recovery in the interworking function is again preferable. Similarly, for SDH virtual containers their timing should be transferred transparently at the destination by regenerating pointer movements in the relevant AU-n or TU-n pointer. B.2.2 QoS Requirements for Circuit Emulation B.2.2.1 Jitter and Wander Timing recovery with asynchronous operation should achieve control of jitter and wander to within the limits for hierarchical interfaces set out in ITU-T G.823 for the ETSI PDH hierarchy signals, Telcordia GR-499/GR-1244/GR-253 for ANSI PDH hierarchy or SONET signals, and G.825 for SDH signals. These limits are set to prevent slips occurring at primary rate interfaces due to jitter and wander. NB it unlikely to be possible to meet these limits (for wander) using purely ACR in the presence of likely packet delay variation (PDV). For this reason circuit emulation over a packet network cannot be used to carry a circuit which is itself used to convey network timing. To avoid the problems of pure ACR an asynchronous clock recovery mechanism might be explored for MPLS which would have equivalent performance to the synchronous residual time stamp (SRTS) in ATM. In principle the requirements for jitter transfer function set out in the various recommendations for PDH multiplexers and in G.958 for SDH regenerators would be applicable across the packet Kankkunen et al. Expires September 2000 [Page 50]  Internet Draft draft-kankkunen-vompls-fw-00.txt March 2000 network; in practice, any jitter input from the TDM domain will be swamped by the effect of PDV, and hence the jitter reducers used to filter out PDV to meet G.823/4/5 will certainly be well within such jitter transfer function requirements. B.2.2.2 Delay The delay for the emulated circuit needs be within the budget for overall delay requirement for the service being carried. B.2.2.3 Error Performance For basic rate 64 kbit/s and Px64 kbit/s circuits the specifications in ITU-T G.821 apply. For circuits at or above primary rate the specifications in ITU-T G.826 apply. 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 implmentation 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 September 2000 [Page 51]