Quality of Service for Next Generation Voice Over IP Networks

Transcription

1 MSF Technical Report Quality of Service for Next Generation Voice Over IP Networks Author: Chris Gallon Company: Fujitsu Contact: February, 2003

2 ABSTRACT This white paper is part of series of white papers that will be published by the MSF in The series of white papers explore the issues motivating the MSF 2003 work plan. The white papers also discuss the solution space within which the MSF will work and identify a proposed work programme for The end goal of the 2003 work programme will be a second Global MSF Interoperability (GMI2004) event. This white paper outlines the issues surrounding quality of service for VoIP networks and proposes a high level solution framework that provides a starting point from which toll quality VoIP networks can be built. It identifies a work programme that will be followed by the MSF technical committees as they seek to refine the solution. DISCLAIMER The following is a technical report of the Multiservice Switching Forum. The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and the Multiservice Switching Forum is not responsible for any errors or omissions. The Multiservice Switching Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything contained herein to the contrary, neither the Multiservice Switching Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind whether based on theories of tort, contract, warranty, strict liability or otherwise, shall be assumed or incurred by the Multiservice Switching Forum, its member companies, or the publisher as a result of reliance upon or use by any party of any information contained in this publication. All liability for any implied or express warranty of merchantability or fitness for a particular purpose, or any other warranty, is hereby disclaimed. For addition information contact: Multiservice Switching Forum California Street, Suite 307, Fremont, CA (510) (510) (fax) info@msforum.org Copyright Multiservice Switching Forum 2003 Page 2 of 17

3 1 The MSF approach to IP QoS for voice networks This white paper outlines the issues surrounding quality of service for pure VoIP networks. It presents a high level solution framework that acts as a starting point from which toll quality, PSTN scale, VoIP networks can be built. It identifies a work programme that will be followed by the MSF technical committees as they seek to refine the solution. The goal of the MSF is to promote multi-vendor interoperability as part of a drive to accelerate the deployment of next generation networks and by addressing the problem of Voice over IP quality of service the MSF is tackling a significant barrier to the widespread deployment of VoIP networks. The MSF will seek to produce a number of detailed Implementation Agreements to assist vendors and operators in deploying interoperable solutions and will look to develop these further into detailed test plans so that the MSF approach can be validated against real equipment. To this end the MSF will look to adopt pragmatic solutions in order to maximise the chances for early interoperability. The MSF welcomes feedback and comment and encourages interested parties to get involved in this work programme. Information about the MSF and membership options can be found on the MSF website 2 The role of voice in next generation networks The worldwide growth in broadband access has led to an expansion of IP and ATM infrastructure so that it is now possible to envisage converged next generation networks where voice, video and data services are provided over a single network infrastructure. This has led to two major drivers for providing such voice services each of which must be considered when designing end to end next generation voice solutions. PSTN evolution. Existing network operators are looking to migrate their legacy PSTN platforms onto the new networks. This migration is driven by the cost savings offered by integrated voice and data networks, the additional revenue that can be gained from the new services such networks can support, and the impending obsolescence of their installed narrowband switches. Triple play networks. New entrant operators who are looking to provide a compelling package including fast internet and video/tv services also look to provide a PSTN replacement voice service. The need for voice support for such operators is driven partly by the need to offer a service bundle but primarily by the fact that voice services offer excellent margins and return on investment for these operators. In order to adequately support the requirements of these types of voice deployments a next generation network must be capable of supporting a service that is equivalent to the existing PSTN in terms of availability and reliability. Furthermore these networks must be capable of carrying voice services even under heavy load and in such a way that while the number of voice calls carried may be reduced, the integrity of the voice calls that are carried is maintained, in even the most extreme circumstances. Page 3 of 17

4 3 Quality of Service requirements for Voice over IP The subject of Quality of Service for IP networks is one that has received a huge amount of attention in recent years. This has led to competing IP QoS solutions being developed. It is not the intention of the MSF to evaluate IP QoS solutions in the context of all possible types of IP traffic. The MSF is currently only concerned with an evaluation of the best mechanisms to solve the problem of supporting a voice service over an IP network. To this end it is important to consider the characteristics of a toll quality voice service, and what this means in terms of any IP QoS mechanism. In general any toll quality voice service requires the following performance. 1. Once a call has been accepted by call control and resources allocated to it the call should be carried to completion with the required voice quality. 2. Established calls must be protected from network disturbances as far as physically possible. One implication of this requirement, when applied to a connectionless IP network, is that stable calls must not be adversely affected by sudden loads caused by the re-routing of traffic from other parts of the network. 3. The network must be capable of supporting very high levels of call setup attempts. Existing narrowband exchanges may support millions of busy hour call attempts and a VoIP network must be able to support comparable volumes. 4. In the event of focussed overload, calls that cannot be carried must be rejected without degrading the call carrying capacity of the network. The PSTN and thus any replacement IP network will occasionally be subjected to very high volumes of calls far beyond that which can be carried (TV and radio phone-in competitions or ticket sales for major events are prime drivers for this sort of overload), any resource reservation mechanisms must be able to deal effectively with this type of event. 5. Mechanisms must be available to ensure that emergency calls and high priority calls receive preferential treatment. Emergency calls in particular i.e. 911 and 112 often have specific regulatory requirements for their handling that must be met by the network operator. 6. Call setup latency must be comparable to the existing network. The resource reservation mechanisms chosen must not introduce delays that mean the user notices a worse setup time on a packet network than they would on a traditional TDM network. 7. The network must be secure from denial of service attacks and spoofing. For example, only the call that has been allocated the resource must be able to use it and when the call is released the resource must again be available to the network. 8. Some networks may require the support for call pre-emption. In certain cases it may be required for a network to de-allocate resources that have been reserved for an existing call and re-allocate them to a new call. The legacy PSTN network supports all of these requirements today using TDM narrowband switches. Additionally some network operators have migrated their TDM voice platforms onto ATM which is a relatively straight forward evolution because ATM is both connection oriented and rich in quality of service features. Where VoIP is considered, however, the underlying network is very different and it poses a number of challenges to operators wishing to support a toll quality voice service; a typical VoIP deployment is shown in figure 1. Page 4 of 17

5 Figure 1 An example VoIP network This network architecture has the following key points Customer Premises Equipment is deployed at the edge of the network and provides the customer s access to the IP network. This equipment may be owned by the network operator but because it exists in insecure premises it is not to be trusted. The edge router acts as the boundary between networks. This router plays a key role in any network since it must police incoming customer flows and provide additional security mechanisms to prevent the misuse of network resources by customers. In terms of security issues the interface between the access network and the core network is of particular concern. The call agent is located in the provider's network and provides call control functions. Network operators in general interconnect at the call control layer, in this case each network operator has at least one call agent and offers a call control interface over the interconnect (e.g. SIP). The MSF does not preclude the support of other types of interconnect (for example interconnection at the transport layer).. Multimedia terminals such as PCs or SIP phones connect directly to the IP network without requiring media adaptation. Existing PSTN customers may be migrated onto the next generation network using line side access gateways (which replace class V exchanges ) or using trunking gateways (which replace class IV exchanges). Subscriber gateways (also known as Residential gateways) may be used where there is a requirement to support legacy black phones over the IP network. The residential gateway provides media adaptation between the analogue phone on the customer side and the packet network on the network side. In order to understand why VoIP provides such a challenge it is interesting to compare the pure VoIP case, where a call is initiated or terminated on a SIP client with the VoIP access gateway case where a call is initiated or terminated on a narrowband phone. Page 5 of 17

6 Customer access type Network characteristics Black phone and access gateway SIP client (pure VoIP) Access Network Dedicated copper line to the gateway. Guaranteed always available bandwidth Shared WAN link into the provider's network. No nailed up bandwidth, must share the link with other voice calls and probably other traffic types, Core Network Customer identity IP core network with appropriate quality of service mechanisms Easily verifiable, connected to the end of a known physical line. such as video and data. IP core network with appropriate quality of service mechanisms The terminal could be anybody capable of accessing the network via the customers premises, they may or may not be authorised to do so. Requires security mechanisms to verify identity and authorisation. Traffic Spoofing risks None. High to low depending on the access network. Shared access networks such as cable and mobile are vulnerable to spoofing attacks, point-to-point access networks such as DSL or metro ethernet much less so. Denial of Service risks None. High. Customer has access to both the edge router and the call server. Appropriate security measures are required. It is clear that a end-to-end VoIP solution poses many more problems to security and QoS than the alternative solutions such as residential, access or trunking gateways. Therefore it follows that any QoS and security solution that works well for an end-to-end VoIP solution can be deployed in a simplified form for the other access solutions. Therefore this paper will concentrate on providing a QoS solution for an end-to-end VoIP call where a SIP terminal is connected to the network via an edge router. Because this white paper is focussed specifically on QoS it is not intended to address the issues of verifying the customer identity or denial of service attacks since these are purely security issues. This paper will however consider the risks associated with traffic spoofing and how they might be tackled since any mechanism must be tightly bound to the QoS solution. Page 6 of 17

7 4 QoS solutions for VoIP There are various mechanisms that can be used to provide quality of service for IP networks and it is not possible to consider every solution here. Therefore it is proposed to examine the most likely candidates for solving the VoIP QoS problem specifically the following solutions need to be considered. Integrated Services (Intserv) Differentiated Services (Diffserv) MPLS Traffic Engineering (MPLS-TE). 4.1 Integrated Services (Intserv) The integrated services, or Intserv, method of providing quality of service is to use a protocol for explicitly reserving bandwidth on a per flow basis. This protocol is the internet reservation protocol, or RSVP. The Intserv architecture and the application of RSVP is described in IETF RFC2210. It is important to distinguish between RSVP itself and Intserv. RSVP is a signalling mechanism that is used to realise the intserv architecture. It is possible to use RSVP for other reasons, one example is RSVP-TE where it is used to facilitate traffic engineering for MPLS networks, another example is aggregate RSVP that is proposed for realising dynamic Diffserv service agreements. When used as part of Intserv RSVP provides a method for a user to request a particular quality of service for a session, in effect this reserves the bandwidth throughout the network for the duration of the session. In the case of a voice session the sender of the voice flow (a SIP client) would send an RSVP path message through the network to the user (the intended receiver). Each node along the path identifies that the Path message signifies a new RSVP session and checks its resources before sending on (a possibly modified) path message. Each Intserv capable node along the path is required to store a soft state for the session and RSVP path refreshes must be sent periodically through the network to hold a particular reservation. Once the Path message reaches the user, the traffic parameters contained within the path message are checked and if the user can support such a session, or wishes to modify the session, an RSVP reservation message is sent back through the network to the sender. Since RSVP reservations are uni-directional this process would have to be carried out in two directions for a bidirectional voice circuit to be established. Although IP networks are connectionless networks, RSVP provides a mechanism to ensure that the reservation message returns by the same route as the path messages, although this route through the network may change over the duration of a session. Each router along the RSVP route checks the RSVP reservation message against its available resources and determines whether it can support the reservation request. If it is able to meet the request then the reservation message is sent onwards towards the sender of the data, otherwise an explict path tear message can be sent clearing the reservation. Once established an Intserv session must be maintained by each router along the path of the session. RSVP Path and Reservation messages must be sent periodically (the IETF recommends once every 30 seconds) along the path of the session (refresh messages) in order to prevent the soft state timing out in the routers. A given session persists until either it is explicitly torn down or until no refresh messages have been received within a given time period in which case the soft state in the routers times out. 4.2 Differentiated Services (Diffserv) The Diffserv approach to providing QoS support differs fundamentally from Intserv in that it does not refer to a specific protocol for providing quality of service but rather an architectural framework Page 7 of 17

8 designed to facilitate QoS. The Diffserv architecture is described in IETF RFC2474 and updated in RFC3260. Diffserv proposes that QoS should be provided by the setting and enforcing of policy within a network to provide a set of Service Level Specifications (SLS) between networks (or customers and networks), effectively service level agreements (SLA). The key features of the Diffserv architecture are as follows. The network is divided into one or more Diffserv domains. Sources and sinks of traffic outside of the Diffserv domain are considered customers and would typically have an appropriate Service Level Specification that defined how much traffic and of what type they could pass into, and receive from the Diffserv domain. It is important to note that these sources may not be individual users but could be an entire network. The edge of the diffserv domain is made up of Diffserv boundary routers. A Diffserv boundary router performs traffic classification and traffic conditioning and policing. It must provide functions for admission control, policy enforcement. In general it is the purpose of the Diffserv boundary router to maintain the integrity of the Diffserv network, to enforce service level specifications and to shape and mark traffic for transport across the remainder of the Diffserv domain. Unlike Intserv, Diffserv QoS functions are not applied to a single flow from a customer. Diffserv classifies traffic into a series of classes (otherwise known as per hop behaviours) and applies the same treatment to all traffic within a class. The core of a diffserv domain is made up of Diffserv core routers. Diffserv core routers are intended to concentrate solely on traffic handling, processing each packet based on how the packet was marked at the Diffserv Boundary. In order to facilitate QoS Diffserv core routers are likely to have a number of traffic queues available corresponding to Diffserv classes. Diffserv defines a mechanism whereby competing services and levels of traffic priority within a particular service are handled by core routers so as to guarantee the Service Level Specifications associated with each service can be met. Because Diffserv is an architecture rather than a complete solution, supplementary elements must be added to the solution in order for it to be suitable for supporting a voice service. A key aspect of this is admission control and one way of providing it is to deploy bandwidth managers within the network. The term bandwidth manager is one that is often used but rarely well defined. Within the context of an MSF network a bandwidth manager is considered to be an entity that receives requests for bandwidth from applications, compares requests with the state of the underlying network and either accepts or rejects the requests. Of course a bandwidth manager may be made as simple or as complex as required by a network and may vary in complexity from a device that simply counts sessions to one that understands the underlying network in detail and is capable of reserving and tearing down network resources dynamically. One of the benefits of deploying a bandwidth manager is that it greatly aids network scalability because it acts as a QoS aggregation function, reserving capacity from the underlying network in bulk and then admitting individual flows to that capacity. This is important because it means the bandwidth manager can make an instant decision about a new session without consulting the many routers that will carry the traffic. However care must be taken when defining the role of a bandwidth manager not to require it to have too detailed a view of network topology or to require all bandwidth requests to be handled by a single entity. The former approach leads to duplication of topology information and the latter approach creates a bottleneck that will limit scalability. 4.3 MPLS Traffic Engineering (MPLS-TE) MPLS traffic engineering extends the capabilities of MPLS to incorporate quality of service and as such provides a potentially useful tool to a network operator looking to support voice services. MPLS can be used inside a network to setup label switched paths between ingress and egress points in the network, in effect this creates tunnels down which appropriately tagged traffic flows. By assigning a Page 8 of 17

9 bandwidth to the label switched path on establishment it is possible to ensure that traffic being carried over a label switched path is guaranteed to be delivered to the egress point provided that the total traffic admitted to the label switched path does not exceed the bandwidth allocated to it. This is a useful tool for IP networks carrying voice as it allows what effectively is an aggregate reservation between two points down which many individual flows can be carried without requiring the explicit reservation of resources for each individual flow. Furthermore this aggregate reservation can be varied with time to allow for fluctuating traffic flows in a network and when combined with MPLS fast re-routing it allows for a resilient network to be created where even significant network failures have very limited impact on the traffic being carried by a particular label switched path. Further information about MPLS can be found in IETF RFC3031, Multiprotocol Label Switching Architecture and IETF RFC3270, Multiprotocol Label Switching Support of Differentiated Services. 4.4 Currently Defined Solutions for VoIP QoS The MSF does not exist in isolation from the rest of the industry and as such has always attempted to re-use existing solutions to problems where they are applicable. The approach that is being taken to addressing the IP QoS issues follows this broad principle and so it is important to take some time to look at whether other industry bodies have proposed a suitable solution for the problem. Currently two important industry bodies have looked to address IP QoS in detail, specifically the PacketCable organisation that defines solutions for cable operators and the Third Generation Partnership Project (3GPP) that is looking to define a solution for broadband mobile networks. The PacketCable specifications are one of the most comprehensive set of specifications available today for the support of voice over IP. While the specifications are limited in scope, being focussed on cable networks, many of the principles set out are applicable to the multiservice networks that the MSF is focussed on. As part of this effort PacketCable have produced their Dynamic Quality Of Service Specification (PKT-SP-DQOS I ). The key features of the PacketCable solution are summarised here as they would apply to the architecture shown in figure 1. Access to the core network is controlled by a call server which instructs the edge router to permit individual flows. The edge router is responsible for policing an individual flow according to the session information provided by the call server. Traffic flows that have not been authorised by the call server will not be granted resources by the edge router. Resources are allocated by a two stage process, reserve and commit. Resources are reserved as part of the call setup process but are only committed once the bearer path has been switched through. A reserved resource may be used for best effort traffic prior to a commit but may not be used for higher quality guaranteed traffic until it is released from the reservation. PacketCable have defined a protocol based on COPS between the call server and the edge router to control the allocation of network resources. They allow (but do not require) the use of RSVP to reserve resources in the access networks. The decision of the 3rd Generation Partnership Project to base next generation mobile networks on IP as well as ATM means that they have had to address the issue of guaranteeing QoS in an extremely resource constrained access network (i.e. over a radio link). The 3GPP end-to-end QoS concept is described in 3GPP TS and contains the following key features as they would apply to the architecture shown in figure 1. Access to the network is controlled by the call server which instructs the edge router to permit individual flows. The call server generates an authorisation token that is passed to the client. This is used during the bearer setup in the access network to ensure that the flow has been authorised by the call server. Page 9 of 17

10 The edge router is responsible for policing an individual flow according to the session information provided by the call server. Traffic flows that have not been authorised by the call server will not be granted resources by the edge router. 3GPP have defined a COPS interface between the call server and the edge router. 3GPP require that the edge router support Diffserv boundary functions and allow (but do not require) the use of RSVP for resource reservation. 3GPP support a two stage mechanism for resource reservation, a resource authorisation phase and a resource commit phase. As can be seen these two organisations have chosen to adopt broadly similar approaches to providing IP QoS for voice services. The challenge for the MSF is to define a solution for multi-service networks that builds on these approaches and that will provide the best possibility of multi-vendor interoperability and early deployment. Page 10 of 17

11 5 A solution framework for VoIP Quality of Service Given the difficulties with respect to scalability and security that any VoIP QoS solution faces and given the currently available tool set for solving such a problem it is possible to draw a number of conclusions. 1. The IETF Intserv architecture is not suitable for the support of large scale VoIP QoS. The high volumes of call attempts that will be required to be supported by any voice network means that the use of Intserv would place an unacceptable burden on the edge and core routers. The MSF recognises that it may be necessary to interface with access networks that support Intserv and in these cases RSVP should be passed transparently through the MSF network. 2. The Diffserv architecture should be used to provide QoS by deploying Diffserv boundary functions at the edge of the network and providing suitable mechanisms to control the admission of individual flows into the network. 3. Within the core network QoS mechanisms should be provided that guarantee service but that do not require knowledge of individual user flows. There are a number of suitable technologies, of which MPLS-TE is the most promising, however alternative solutions such as aggregated RSVP and ATM may also be applicable in some networks. 4. To enhance scalability and to allow call control functions to be abstracted from the underlying network bandwidth managers should be deployed. Bandwidth managers act as an interface between the call control functions and the network specific bearer functions. 5. In order to support full PSTN equivalence a two stage resource reservation model should be applied with resources being reserved on initial call setup and committed at the point where a bearer is established. These broad conclusions lead to the following solution framework for a pure VoIP call. IF-1 Call Agent / SIP Proxy IF-6 To peer Call Agent IF-2 IF-3 Bandwidth Manager IF-5 IF-3 To peer Bandwidth Manager SIP Terminal CPE Router Media Flows Edge Router DS Boundary IF-4 IF-4 DS Core router IF-4 Edge Router DS Boundary Other access or core networks Figure 2 VoIP QoS Architecture A key point to note about this architecture is that the use of the Diffserv QoS mechanisms require the ingress and egress points of voice traffic into the network to be clearly identified by the call agent otherwise no decisions can be made regarding available network capacity. This is a slightly different approach to that taken by the traditional SIP model whereby the call agent does not have any knowledge of the voice path taken and the resources can be reserved using per flow RSVP messages. In order to scale this solution the MSF model provides for interfaces within networks and between networks at the call control layer. This implies that where one network hands off traffic to another two call agents must pass SIP signalling between them and both call agents must make decisions regarding Page 11 of 17

12 the physical ingress and egress points of the traffic. This approach means that SIP signalling within and between MSF networks in some ways resembles the flows seen in the traditional PSTN with signalling passing through a number of call control functions which then allocate the traffic to the underlying network bearers. The MSF notes that this model is also very similar in behaviour to that chosen by the ITU-T when defining their Bearer Independent Call Control (BICC) solution. The MSF does not preclude inter network communications from taking place entirely at the transport layer but notes that the nature of Erlang means that there are strict limits to the scalability of such an approach. This approach is to a large extent dictated by the nature of Diffserv SLAs and although it departs slightly from the classical SIP end-to-end model it is still able to take advantage of the capabilities of SIP as a multi-media session control protocol. One benefit of defining clear inter-connects between networks and interfacing at the call control layer is that this will allow carriers to re-use their existing PSTN business models and processes while still being able to realise new revenue earning multi-media services. The functions of each of the core network components in providing QoS in this MSF architecture is described below: Call Agent - The call agent is responsible for providing the call control functions and identifying the originating and terminating points within the network. It must also provide secure mechanisms to identify the user. Bandwidth Manager - The bandwidth manager is responsible for providing the required QoS from the network. It is responsible for the setting up and tearing down of bandwidth within the network and for controlling the access of individual calls to this bandwidth. It is responsible for installing the appropriate policy in edge routers to police the media flows on a per call basis. Within any network there may be a number of bandwidth managers, however each bandwidth manager has sole responsibility for the aggregate bearers that it has created and is the sole arbiter as to whether a call may have access to the reserved bandwidth. Edge router - The edge router provides Diffserv boundary functions and applies the appropriate policy to individual media flows under the direction of the bandwidth manager. The Edge router must contain security functions to ensure that only authorised flows are allowed access to the network resources. Core router - The core routers are responsible for passing traffic through the network in large volumes whilst providing Diffserv core functions. In practice this means supporting a separate internal traffic queue per Diffserv class. The MSF is not directly concerned with defining the behaviour of the access network because it recognises that MSF networks must operate with a variety of such networks, including cable networks, ethernet access networks and ATM based DSL access networks. In order to interoperate successfully with an MSF core network the access network must provide a mechanism for guaranteeing QoS. This may be achieved in a number of ways, for example by using Intserv, Diffserv or by deploying hybrid ATM IP solutions (such as those outlined by the FS-VDSL organisation). An essential component of the access network solution is the CPE as it provides key policing and shaping functions for traffic flowing towards the core network. 5.1 Interface descriptions One of the key work items that the MSF undertakes is to define implementation agreements for protocols between components of the Multi Service Network. As such it is important to consider each of the interfaces defined in figure 2, to understand the primitives that must flow over the interfaces and to try and identify candidate protocols for the interfaces. It is the role of the MSF technical committee to analyse the interfaces further, chose an appropriate protocol and produce the final implementation agreements. Page 12 of 17

13 5.1.1 Interface IF-1 IF-1 between the SIP client and the call server is primarily used for call setup signalling and as such SIP is clearly the appropriate protocol. Bandwidth requirements (and hence QoS requirements) will be passed between client and network as part of the SDP encapsulated within the SIP protocol Interface IF-2 IF-2 between the call server and the bandwidth manager is provided to enable the call control functions of the call agent to be decoupled from the specific bandwidth management functions that are closely tied to the underlying network implementation. It is recognised that not all implementations will wish to open this interface. The interface must support the following capabilities. Allow the call control function to reserve bandwidth between two known end points of the operators network. Enable call control to instruct the bandwidth manager when to commit and release the bandwidth. Allow call control to signal the priority of the request to allow the support of services such as 911 and call pre-emption services. Allow the bandwidth manager to inform call control of bearer termination due to network failure. There are a number of candidate protocols that could be chosen to provide this functionality including SIP, COPS and H.248. The MSF technical committee will analyse the requirements of IF-2 in detail and identify a suitable protocol Interface IF-3 IF-3 between the bandwidth manager and the edge router is provided to allow the bandwidth manager to control the underlying boundary routers on a per call basis. Using this interface the bandwidth manager must reserve, release and commit bandwidth on the edge router and enable/disable access points for individual media flows. The bandwidth manager must be able to control the underlying network element in such a way that only flows that have been authorised by the call control server are allowed access to the network. Currently the most mature protocol in this space is the PacketCable COPS based Gate Control Protocol, however the MSF notes that ETSI TIPHON recommended the use of H.248 for this interface and other protocols may also be considered. The MSF technical committee will determine which protocol should be chosen for IF Interface IF-4 IF-4 between the bandwidth manager and the underlying network elements is provided to allow the bandwidth manager to set up and tear down aggregate bandwidth reservations across the network. The nature of this interface is highly dependent on the underlying network technology, for example for an MPLS network it might only be required to provide the interface between the bandwidth manager and the edge routers, however if the core network were based on ATM technology then interfaces might be required between the bandwidth manager and all of the switch routers in the network. Regardless of the network technology the interface must support the following capabilities. The bandwidth manager must be able to reserve bandwidth to a particular destination of a particular Diffserv QoS class. The bandwidth manager must be able to release bandwidth when it is no longer needed. Page 13 of 17

14 The underlying network elements must be able to inform the bandwidth manager of any changes affecting current reservations. The interface should allow this information to be passed upwards to the bandwidth manager immediately such an event takes place and the information should reach the bandwidth manager with the shortest possible delay. The exact protocol to be chosen for IF-4 is for further study and a number of candidate protocols will be evaluated to determine which would be most suitable Interface IF-5 IF-5 is an inter bandwidth manager interfaces for the cases where it is necessary for two bandwidth managers to communicate directly. There are two cases where bandwidth managers might be required to communicate with each other: Where a particular part of a service providers network is under the sole control of a single bandwidth manager and calls are required to transit through it. In the case of a so called transit network where two VoIP operators, each with call servers are interconnected by a third transport or transit network that has no call server. In this case each of the VoIP operators must reserve the required bandwidth from the transit network operator via IF-5 The following diagram shows an example of VoIP interconnect via a transit network. IF-1 Call Agent / SIP Proxy IF-6 IF-1 Call Agent / SIP Proxy CPE Router Edge Router DS Boundary IF-3 IF-2 Bandwidth Manager IP Network IF-3 Edge Router DS Boundary IF-5 Edge Router DS Boundary IF-3 Bandwidth Manager IP Network (transit) IF-3 IF-5 Edge Router DS Boundary Edge Router DS Boundary IF-3 IF-2 Bandwidth Manager IP Network IF-3 Edge Router DS Boundary Figure 3 Interconnect via a transit network The exact requirements for an inter bandwidth manager interface and how bandwidth managers interact is for further study by the MSF technical committee Interface IF-6 IF-6 between call agents is provided to enable peer to peer call control communication. The MSF has currently identified a SIP profile for this interface and the MSF Implementation Agreement is currently undergoing final ballot (MSF contribution Implementation Agreement for SIP Profile, for Voice over IP, between a line-side Media Gateway Controller and a Trunks Media Gateway Controller. ) 5.2 Putting it together, a high level example Given this broad framework an inevitable question is how would a toll quality VoIP call actually be set up. While it is beyond the scope of a white paper to provide a detailed set of call flows the following high level example is provided of a toll quality VoIP call for an MPLS based core network; it is assumed that near end ring-back tone is applied. Page 14 of 17

15 Figure 4 Example call setup with QoS Prior to the call attempt being made the bandwidth manager is assumed to have already allocated bandwidth to the MPLS tunnel between the chosen ingress and egress point. When the initial call attempt is made the following actions are taken: 1. The SIP client sends an invite message containing the session description which describes the bearer characteristics of the call. The call agent analyses the initial invite, verifies the identity of the user and authorises the call attempt. It may generate an authorisation token to verify that the call has been accepted by a valid call server, this is important in shared access networks such as cable or 3GPP networks but not a requirement for networks with dedicated point to point access (metro ethernet and DSL). The call agent determines the ingress point (edge router A) and egress point (edge router B) of the call into and out of the network and forwards the invite to the appropriate call agent in the next network. 2. The neighbouring call agent processes the call and determines that it is in a position to alert the called party. The neighbouring network reserves resources within itself and requests its upstream neighbour to start the reservation process by sending back a 183 Session Progress Message. This behaviour broadly follows that described in RFC 3312 Integration Of Resource Management And Session Initiation Protocol except that the reservation mechanism is Diffserv based and not RSVP. 3. The call agent requests bandwidth be reserved by the bandwidth manager between the two end points. 4. The bandwidth manager determines the physical network entities that will carry the traffic into and out of the network and requests that edge router A and B reserve capacity to carry the session in both the forwards and backwards direction. 5. The edge routers determine that they have sufficient internal resource to accept the media flows, reserve the resources and inform the bandwidth manager. At this stage although the edge routers and the bandwidth manager have set aside resource to handle the flows this resource can be re-used for best effort traffic. 6. The bandwidth manager informs the call agent that the required resources have been reserved in each direction. 7. The call agent might send the request to reserve resources further back into the access network by passing back the 183 session progress message, however in this case the access network uses other mechanisms for QoS (for example those used by ATM based DSL access networks) and so the access network bandwidth is already guaranteed. The call agent Page 15 of 17

16 therefore knows that QoS has been setup end-to-end and sends an Update message to its neighbouring call agent confirming this. 8. The adjacent call agent receives the update messages indicating that resources have been reserved, which it acknowledges and then alerts the user, sending a 180 Ringing message back through the network. Sometime later the called party answers the call and a 200 Ok message is passed back. 9. On receiving the 200 Ok message the call agent requests the bandwidth manager commits the resources to the call. 10. The bandwidth manager instructs routers A and B to open the access points for the forwards and backwards media flows. This commits the resource to the call and means that the users now have a guaranteed path available through the network. 11. The edge routers inform the bandwidth manager that the flows have been granted access to the network. 12. The bandwidth manager informs the call server that the media flows have been granted access to the network the call is considered to be in progress and billing may start. Media streams carried when the call is in progress are marked by the edge routers with the appropriate Diffserv Code point, for voice these flows will in most cases be marked as EF (Expedited Forwarding) traffic. In an MPLS core network, as shown in this example, the media flows are admitted to the appropriate Label Switched Path (LSP) and the bandwidth manager ensures that no more flows are admitted than can be supported by that LSP. If during the course of a call physical changes in the network cause the bandwidth available to the LSP to be reduced then the bandwidth manager must be informed and it must tear down sufficient calls to ensure the new bandwidth limit for the LSP is not exceeded. If the bandwidth manager is forced to tear down active calls it must inform the call agent that the call has been terminated with the appropriate cause value. When the call is terminated it follows that the resources that have been allocated to the call must be released and returned to the pool. In order to achieve this the call agent instructs the bandwidth manager to release call resources on receiving a BYE message (if they have been previously reserved or committed). On receiving this instruction the bandwidth manager must update its state and also instruct the edge routers to release their resources and importantly to close the access points for the media flows. It is important to note that this process not only guarantees QoS for the call but it also provides a number of security features. In particular prior to point 11 in the process the two end users do not have access to any of the reserved capacity and so cannot try to set-up two half calls to avoid paying for the service. In addition by ensuring that access points for media flows are explicitly closed when a call terminates (i.e. when the call control layer and hence billing processes state that it has terminated) it prevents users re-establishing media flows to the same end points whilst bypassing call control and so a toll free call cannot be established. Of course there is nothing preventing the users from creating a best effort connection between the two end points however this will not be allocated any dedicated resource. Because of the nature of SIP, whereby a call can have many complex operations performed on it the MSF approach is only to reserve resources when a call agent is in a position to alert a subscriber, this approach mimics to an extent the solution chosen by feature rich private signalling systems. While this is a simple example, the issue of call setup, resource reservation and SIP interactions is a complex one which requires further investigation. In particular the MSF will consider the interactions with various types of SIP servers and service platforms and also what mechanisms might be provided to prevent unnecessary signalling in the case of severe network congestion. 5.3 Solution framework conclusions This solution framework provides a high level overview of how the necessary QoS for VoIP networks will be supported in an MSF network. By basing the solution on Diffserv for scalability and by paying close attention to the issues of security this framework provides a coherent and pragmatic basis on which to move forward. Furthermore this solution framework has the benefit of being based substantially on the approaches taken by PacketCable and 3GPP which will maximise the opportunity Page 16 of 17

17 for the vendor community to re-use existing solutions. This white paper acts as a starting point for the MSF technical committee as it seeks to produce the detailed Implementation Agreements that will assist vendors and operators in deploying QoS capable VoIP networks. 6 MSF QoS for VoIP work plan It is the ultimate aim of the MSF to demonstrate interoperable QoS capable VoIP networks that will scale to PSTN volumes of calls. In order to achieve this the following work programme has been adopted. 1. Validation of the end-to-end QoS architecture and further analysis of the functions required from an MSF bandwidth manager. 2. Identification of the protocols to be used on each of the QoS aware interfaces (IF-1, IF-2, IF-3 and IF-4, IF-5 and IF-6). 3. Creation of Implementation Agreements for each of these interfaces. 4. Creation of Interoperability test plans to prove the QoS solution. The outputs of this work plan will be the implementation agreements, the test plans and these will form the basis of a future MSF interoperability event. A first draft of the QoS architecture and solution framework was presented at the January 2003 MSF meeting in Orlando. 7 Glossary Class IV exchange Class V exchange COPS MPLS PSTN SIP A class 4 PSTN exchange is a trunk exchange that is used to aggregate traffic and provide efficient interconnection of class 5 exchanges. A class 5 PSTN exchange has directly connected subscribers. Common Open Policy Service. An IETF protocol used to allow elements responsible for setting policy (policy servers and call servers) to communicate with elements responsible for enforcing policy (IP routers and firewalls). Multi Protocol Label Switching. A mechanism by which end to end connections can be made across a connectionless IP cloud by allocating labels to traffic at the edge of the MPLS domain and switching packets within it based on the label values. Public Switched Telephone Service. Session Initiation Protocol. The IETF s next generation multi media call and service control protocol. Page 17 of 17