Performance Analysis of VoIP over BGP/MPLS VPN Technology Ibrahim S. I. Alsukayti, Timothy J. Dennis School of Computer Science and Electronic Engineering University of Essex Colchester, United Kingdom
[email protected],,
[email protected] [email protected] Chris Edwards School of Computing and Communications Lancaster University Lancaster, United Kingdom
[email protected]
Abstract — This paper investigates the performance of VoIP over
a BGP/MPLS VPN network from two different aspects. The first aspect investigates the impact on VoIP performance of the VPN tunneling process. This is based on a comparison of VoIP performance over a BGP/MPLS VPN network with its performance over an MPLS network, with particular regard to different QoS parameters, principally delay, jitter and throughput. The second aspect is a study of the most common VoIP codecs, namely, G.711, G.723.1 and G.729A over the BGP/MPLS VPN network. This is based on investigating different implementations of such codecs with respect to the packetization interval time in order to identify the optimal codec that efficiently balances between acceptable end-to-end delay and high bandwidth efficiency.The OPNET Modeler was used to create a VoIP-BGP/MPLS VPN simulation model for carrying out different scenarios. The results show that the BGP/MPLS VPN network has a positive impact on VoIP performance in comparison with its performance over an MPLS network. It also concludes that, following different implementations of the VoIP codecs, G.729A is the best codec for the VoIP-BGP/MPLS VPN network as it efficiently balances between bandwidth efficiencyand low end-to-end delay. Keywords- VoIP; MPLS; BGP/MPLS VPN.
I. INTRODUCTION There is a growing interest among service providers in deploying converged IP networks. It provides a cost-effective, flexible and efficient solution for both customers and service providers. A single connection can be used by a customer for data and voice communications which are transported by a service provider usinga single IP -based network. However, this has raised the issue of security in voice communications since shared public networks are used. Many techniques have been used for tackling this issue, of which the use of a Virtual Private Network (VPN) is one of the most widely adopted. It allows businesses to connect remote sites and users within a
ISBN: 978-1-902560-25-0 © 2011 PGNet
single private secured network. The most recently emerging VPN approach is using the BGP/MPLS VPN technology. It combines the advantage of the robust Multiprotocol Label Switching (MPLS) technology with the security features of a VPN. This enables service providers to use their MPLS network for offering a VPN service capable of securely delivering different styles of traffic including voice traffic. Implementing Voice over IP (VoIP) over such an efficient and secure network ensures a high level of security and pr ivacy for VoIP communication. However, VoIP has time-sensitive traffic exhibiting bounded Quality of Service (QoS) requirements, such as low delay, jitter and packet loss. It is important to ensure that the addition of more processes on VoIP traffic does not degrade these QoS parameters. In the scenario here, the transport of VoIP traffic over the BGP/MPLS VPN network means each packet is delivered into a secure VPN tunnel. For some VoIP codecs, this means that 100 packets need to be tunneled per second leading to more processing delays, which may affect VoIP quality. It is therefore important to ensure that the MPLS VPN processes have acceptable impact on VoIP p erformance. Another important factor for consideration is the choice of the codec for VoIP communication. The most common VoIP codecs are G.711, G.723.1 and G.729A, which operate at different bit rates.They also vary in their encoding-decoding delay, which contributes to the overall end-to-end delay and, consequently, to the VoIP QoS. Moreover, each codec can be implemented with different packetization interval times i.e. a different number of frames per packet. The more the frames added to a VoIP packet the better the bandwidth is utilized, but the greater the packetization delay. Therefore, the impact of selecting the number of frames to be inserted into each VoIP packet packet for each codec is an important important aspect to be addressed addressed when deploying VoIP over the BGP/MPLS VPN network.
The rest of the paper is structured as follows. Section II and III provide background about VoIP and BGP/MPLS VPN technologyrespectively. Then, section IV describes the VoIPBGP/MPLS VPN simulation model, and the configurations of the different scenarios examined using this model. This is followed by section V which presents and discuses the results of these scenarios. Finally, section VI concludes the paper. II. V O IP T ECHNOLOGY A. VoIP Transport System Different network functions are required for delivering VoIP traffic over data networks. These functions include call signaling and control and media transport [1]. Different signaling protocols are used, with the common ones being H.323 and Session Initiation Protocol (SIP). These protocols are used to setup, control and terminate a VoIP call session [2] [3]. Once a session is established, voice stream is transported using two transport protocols, namely Real-Time Protocol (RTP) and User Datagram Protocol (UDP) over IP. Whereas UDP provides a connectionless service suitable for real-time transmission, RTP provides a means for carrying real-time details such as packet sequence and time-stamping [4]. B. VoIP Codecs RTP and UDP are used to carry voice signals that are digitally encoded. This means that each voice signal is converted from its analog form into a digital form at the transmitter device. The analog signal is firstly sampled based on a sampling rate of 8 KHz, and then a quantization process takes place in which each sample is represented by 8 or 16 bits. Next, the output is encoded according to many factors: the compression rate and the framing time or the frames length. Finally, one or more of these frames are encapsulated into an RTP/UDP/IP packet for transmission over the network. All these processes are accomplished by one of various audio codecs, each of which uses a different algorithm [5]. Table I shows some features of the most common codecs: G.711, G.723.1 and G.729, and how they vary in many aspects such as bit rate, encoding algorithm and coding delay. TABLE I.
VOIP CODECS CHARACTERISTICS [5] PacketIP Packets Payload Packet Bit rate ization per Size Size (kbps) Interval Second (bytes) (ms) (bytes)
ITU-T Codec
Algorithm
Codec Delay (ms)
G.711
PCM
0.375
64
10
100
80
120
G.729A
ACELP
35
8
10
100
10
50
G.723.1
CSACELP
97.5
5,3
30
33
20
60
Table I shows that G.711 is a high bit rate codec, operating at a bit rate of 64 Kb/s whereas G.723.1 and G.729A operate at low bit rates of 5.3 and 8 Kb/s respectively. This is because G.711 uses the basic Pulse Code Modulation (PCM) algorithm. On the other hand, complex algorithms are used by G.723.1 and G.729A for compressing the bit rate resulting in encoding delays higher than for the basic PCM algorithm.
C. QoS Requirements of VoIP Ensuring high voice call quality over the “best effort” IP network is the key challenge in delivering VoIP traffic. QoS for VoIP is defined using different parameters, with the common ones being end-to-end delay, jitter and packet loss. End-to-end delay consists of end-system and network delay.The end-system delay occurs due tothe encoding and decoding delay and de-jitter buffering delay.The network delay is mainly caused by the propagation and queuing delay at network devices [5]. A one-way end-to-end delay of 150ms is the recommended delay value defined by the G114 recommendation of the International Telecommunication Union (ITU-T) [6]. It also considers a delay of 400ms is the maximum acceptable value. However, the recommendation also shows a measurement of user satisfaction against the acceptable end-toend delay. It shows that after a delay of about 260 ms, there will be unsatisfied users because the delay starts to be noticeable. In this paper, an end-to-end delay of 260 ms is considered to be the maximum acceptable delay. The end-to-end delay variation between two consecutive packets is called jitter. A jitter of less than 50ms is considered to be acceptable for high quality VoIP calls [7].Packet loss occurs in the network due to many factors such as congestion network failure. It is also caused by end systems when the de jitter buffer is overloaded. In reference [8], the author points out that a packet loss rate of up to 10% is tolerable for high bit rate codecs such as G.711 whereas 5% is considered to be the acceptable limit for low bit rate codecs such as G.729A. III. BGP/MPLS VPN NETWORK TECHNOLOGY A. BGP/MPLS VPN Architecture MPLS enhances different network capabilities providing a fast forwarding mechanism, traffic engineering and fast failure recovery. It also enables service providers to implement VPN connections over the MPLS network [9]. This MPLS VPN is based on a VPN tunneling mechanism. VPN traffic is tunneled into a pre-established Label Switched Path (LSP) across the MPLS core network. This is done using the MPLS Label Stacking mechanism which provides a means to encapsulate more than one label into a packet [10].An MPLS VPN can be implemented as a layer 2 or layer 3 VPN [11].An MPLS layer 3 VPN is defined in RFC 2547 by the Internet Engineering Task Force (IETF) and is known as BGP/MPLS VPN. It is a scalable peer-to-peer VPN, capable of isolating different VPN traffic allowing for more security to be ensured [10]. The BGP/MPLS VPN network is constructed using multiple devices as shown in fig. 1. It consists of three distinct routers, namely Customer Edge (CE), Provider Edge (PE) and Provider (P) routers. The CE router is the edge of a customer VPN site and runs only an IP routing protocol and has no MPLS forwarding capability. It is directly connected to the PE router at the edge of the MPLS core network. The PE router is an MPLS router capable of receiving, labeling and forwarding IP packets into VPN tunnels to be transported across the core network. The P router is located at the core and has no direct link to the CEs, and does not exchange VPN routing information. Instead, it connects PE routers with each other in order for them to communicate this information [10] [12].
IV. SIMULATION SCENARIOS
Figure 1. BGP/MPLS VPN Architecture [12]
In addition to the global routing table, PE routers create a distinct routing table called the VPN Routing Forwarding (VRF) table for each VPN. This table allows VPN isolation as well as address overlapping. Routing information of a VPN received from its CE router is stored into its associated VRF table at the PE router [10]. As shown in figure 1, routing information of VPNA received from CE router of site1 is stored in the VRF of VPNA. This information is exchanged between the PE routers connected to sites of the same VPN. This is accomplished using an extension to the BGP protocol called Multiprotocol BGP (MP-BGP)to carry extra information added to each route at the VRF table as follows [10]: 1. A 64 bit number called theRoute Distinguisher (RD) is integrated with the 32 bit IP address of each route to form a unique addressing scheme called a VPN-IPv4 address, consisting of a 96 bit address. 2. An extended BGP community attribute value of 64 bits called Route Target (RT) is assigned to each route. It is used by PE routers to install the advertised VPN routes into the correct VRF table by matching the RT value.
Firstly, a BGP/MPLS VPN network model was designed as shown in figure 2. The topology of the model consists of a service provider MPLS core network, providing a VPN service for a customer network of two remote sites. The core network has a number of P core routers and two PE routers between which the VPN tunnels are created. Each VPN site has one CE router connected directly to a PE router. Each VPN site operates a SIP-based VoIP network. OPNET Modeler was used to simulate the BGP/MPLS VPN network model described above using different predefined MPLS VPN objects available in OPNET. Table II lists these objects and describes some of their configurations. Additionally, a VRF table needs to be created at each PE router and associated with the interface connected to the CE router. Fig.3 shows a VRF table created and named VPN_10at each PE router. It also shows other attributes set for this table including the Route Distinguisher (RD) and the Route Target (RT) which are attached to each advertised route. A value of 100:10 is configured for the RD to be used for forming the unique VPN-IPv4 address. The same value of 100:10 is set for the RT for both export and import routes to install the advertised route into the VPN_10 VRF table. In order for the PE routers to run the MP-BGP, the VPNIPv4 address family was added to the BGP address families after enabling the BGP protocol. This is shown in Fig.4 where VPNv4 and IPv4 address families are added and the IPv4 address family is associated with the VRF VPN_10.
3. The MPLS VPN label assigned for each VPN site. B. VOI P deployment over B GP/MPL S VPN
In general, voice traffic can be delivered over MPLS networks using two approaches: voice over IP over MPLS (VoIPoMPLS) and voice over MPLS (VoMPLS). In the former approach, voice traffic is carried within IP packets to then be delivered across the MPLS network whereas the latter implies that voice traffic is carried directly over the MPLS network. Although both approaches share the same aspects related to MPLS technology, they vary in some aspects such as bandwidth utilization [13].That is, a VoMPLS packet only has a 4 byte MPLS header whereas each VoIPoMPLS packet has at least a 40 byte RTP/UDP/IP header plus the 4 byte MPLS header. In addition to this there is another 4 byte MPLS header when VPN tunnels are established over the MPLS network [14]. This would result in high overhead leading to inefficient bandwidth utilization when a low bit rate VoIP codec is used. VoIP performance can be affected by such large overheads when more concurrent calls are connected.
Figure 2. BGP/MPLS VPN Simulation Model
TABLE II.
BGP/MPLS VPN COMPONENTS AND CONFIGURATIONS Routing Protocol
MPLS Signaling Protocol
Component
OPNET Object
PE
ethernet2_slip8_ler
P
ethernet2_slip8_ler
CE
ethernet4_slip8_gwy
Static
-
CE-PE link
PPP_DS3 (44.736 Mbps)
-
-
-
-
-
-
PE-P link PE-PE tunnel
PPP_SONET_OC3 (148.61 Mbps) MPLS_ELSP_DYNAMIC
Static, BGP, OSPF and MPLS OSPF and MPLS
RSVP RSVP
Once the VoIP application and profile have been defined and configured, the next step is to configure the SIP clients to run them. Then, the SIP UAC Service (User Agent Client Service) needs to be enabled in each SIP client . It is also necessary for each SIP UAC (caller) to specify the Proxy Server Address to which SIP requests are sent.
Figure 3. VRF Table Configurations
Figure 5. Simulation Model of Task 1
Figure 4. MP-BGP Configurations
This BGP/MPLS VPN simulation model was then used to carry out two different sets of scenarios in order to accomplish two main tasks. The first task is to assess the impact on VoIP performance of MPLS VPN tunneling. This was achieved by contrasting VoIP performance over an MPLS network with its performance over the BGP/MPLS VPN model with respect to different parameters, mainly delay and jitter. The second is to evaluate the most efficient implementation of the VoIP codecs (G.711, G.723.1 and G.729A) that can be utilized over the BGP/MPLS VPN network model, and efficiently balance between low end-to-end delay and bandwidth efficiency.For each task, Different SIP-based VoIP networks are created and added to each VPN site as described in the following sections.
A. Simul ation M odel and Scenar ios of Task 1:
For task 1, three subnets containing one SIP proxy server and numbers of SIP clients and servers are created at each site, as shown in fig. 5, for generating a high number of simultaneous calls across the core network.Furthermore, two objects were added and configured to allow SIP clients and servers to run VoIP. These are the Application Config and Profile Config objects. The Application Config object provides predefined applications such as VoIP with configurable parameters. The key VoIP parameters used for this simulation are the Encoder Scheme set to G.729; Voice Frame per Packet set to 1 and Signaling Protocol set to SIP. On the other hand, the Profile Config object defines the behavior of the application regarding the start and end time and repeatability. It is set to run the VoIP application after 180 seconds from the start of the simulation, to last until its end time which is 10 minutes. It is also configured to add more calls every 60 seconds.
After that, two scenarios were carried out to accomplish the first task. The first one is to analyze VoIP performance over the MPLS VPN model. The same model created and described so far is used with no further configurations. The second scenario is to run VoIP over an MPLS network using the same model topology without VPN connections. B. Simul ation M odel and Scenar ios of Task 2:
For the second task, a basic SIP-based VoIP network is added to the BGP/MPLS VPN simulation model, and is implemented at each VPN site. It consists of one SIP UAC in one site and a SIP UAS in addition to a SIP proxy server in the other as shown infig. 5. This is because this task only aims to provide guidelines in terms of the appropriate VoIP codec. Since this task is to study the codecs G.711, G.723.1 and G.729A when different numbers of frames per packet are implemented, 10 scenarios were carried out for each codec. Accordingly, some parameters of the Application Config and Profile Config objects were modified. For each scenario of each codec the parameter Voice Frames per Packet is firstly configured with 1 frame and then increased by 1 for each of the next scenarios. The Encoder Scheme parameter is also modified to the required codec. V. RESULTS AND DISCUSSION A. I mpact of M PLS VPN tunneling on VoI P perf ormance
VoIP packets are subject to more processes when tunneled into aVPN tunnel across the MPLS core network. However, as fig.6 shows, the MPLS VPN tunneling processes have a positive impact on VoIP performance when compared with its performance over the MPLS network model. The end-to-end delay experienced by VoIP calls over the MPLS VPN network(190 ms) is 10 ms lower than they are over the MPLS network (200 ms). The reason behind this is related to the mapping process performed at the edge routersof the MPLS network. That is, each packet should be mapped to a Forwarding Equivalence Class (FEC) in order to be sent over the correct LSP, whereas it is pre-mapped to its VPN tunnel in the MPLS VPN model.
Furthermore, fig.7 shows that jitter is very low in both implementations when compared to the acceptable jitter (less than 50ms). However, it also shows that lower jitter in the MPLS VPN model occurs when compared to that in the MPLS model. It can be also observed that jitter increases in the MPLS model more than it does in the MPLS VPN model when more simultaneous VoIP calls are established. In addition, another important VoIP performance metric is the call setup time required by SIP signalling protocol. Fig.8 shows the results of this metric for both scenarios. It is clear that it is lower in the VoIP-MPLS VPN model than in the VoIPMPLS model, by a difference of more than 20ms.
B. The Optimal VoIP Codec for BGP/MPLS VPN Network The main factors to be considered when investigating the optimal codec for VoIP communications are the end-to-end delay and bandwidth efficiency. The selected codec should be capable of balancing between both factorsefficiently. It is important to firstly examine the end-to-end delay of all the VoIP codec implementations since improving bandwidth efficiency is restricted by the maximum acceptable delay (260ms as agreed for this research). Fig.9 shows that in all of the implementations, the G.711 and G.729A calls experience the same delay, while the G.723.1 calls experience a higher delay. Fig.9 also shows that implementing G.723.1 with more than 1 frame per packet would resulted in unacceptable delay, whereas both G.711 and G.729A can be implemented with up to 5 frames per packet allowing bandwidth utilisation to be optimized. The investigation, therefore, is performed on the first five implementations of G.711 and G.729A, and the first implementation of G.723.
Figure 6. End-to-End Delay of both MPLS and MPLS VPN Model
Figure 9. End-to-End Delay of Different Implementations of the Codecs
Figure 7. Jitter of both MPLS and MPLS VPN Model
Figure 8. Call Setup Time of both MPLS and MPLS VPN Model
To examine bandwidth efficiency for the acceptable implementations of the three codecs, it is important to consider two main factors, the number of simultaneous calls that can be carried out and the overhead ratio of VoIP traffic at the MPLS core network. Fig.10 shows that G.711 allows fewer VoIP calls to be simultaneously carried out over a 1 Mb link than G.729A. This is due to the fact that G.711 is more bandwidth-demanding than G.729A that is they operate at different bit rates of 64 and 8 kb /s respectively. Consequently, the voice payload would occupy a high percentage of a G.711-VoIP packet size resulting in a low overhead ratio, whereas the opposite is true for G.729A, as shown in fig.11. However, this factor can be dismissed, as the more simultaneous calls over the network of good call quality the higher the customer satisfaction will be. Therefore, G.729A and G.711 provide the same high call quality with respect to end-to-end delay, but G.729A is more efficient, allowing more concurrent VoIP calls than G.711 for VoIP over BGP/MPLS VPN networks. On the other hand, the only acceptable implementation of the G.723.1 codec is 1 frame per packet. When this is compared with the G.729A implementations, as seen in fig.9, it
becomes evident that the calls of the third implementation of G.729A, of 3 frames per packet, have the same delay as the calls of the acceptable implementation of G.723.1. Looking at bandwidth efficiency, Fig.10 shows that 10 more concurrent calls were performed with G.723.1 than with G.729A of 3 frames per packet whereas G.723.1 causes higher overhead of 10% (fig. 11). However, bandwidth efficiency can be further improved by G.729A when it is implemented with 4 and 5 frames per packet. This is shown in fig.10 where the number of simultaneous G.729A-VoIP calls can be increased to 60 calls per 1 Mb link and the overhead ratio decreases to about 53%, while maintaining an acceptable delay (i.e. lower than 260ms). Therefore, implementing VoIP over BGP/MPLS VPN networks using the G.729A codec allows a high number of concurrent calls which have a maximum delay that is lower than the 260ms borderline defined by this study. It can be implemented with up to 5 frames per packet, providing more options for balancing between low end-to-end delay on the one hand and bandwidth efficiency on the other.
VI . CONCLUSION Deploying VoIP over the BGP/MPLS VPN network model combines the advantage of both robust MPLS technology and the security of a VPN solution. Running VoIP over such network model also gave interesting results when compared with the results of running the same VoIP traffic over the MPLS network model. It was clear that the BGP/MPLS VPN network model has a positive impact on VoIP performance when contrasted with its performance over the MPLS model.VoIP calls experience lower end-to-end delay and jitter over the BGP/MPLS VPN network. The study of different implementations of the VoIP codec G.711, G.723.1 and G.729A - over the BGP/MPLS VPN network model showed that G.711 and G.729A can be implemented with up to 5 frames per packet, allowing bandwidth efficiency to be more optimized. On the other hand, implementing G.723.1 with more than one frame per packet resulted in an unacceptable delay of more than 260ms. The study also showed that G.729A is the most efficient VoIP codec to be implemented over the BGP/MPLS VPN network model. It allows a high number of simultaneous calls to be supported, with an acceptable end-to-end delay of less than 260ms. G.729A-VoIP implementations with up to five frames per packet efficiently balance between low end-to-end delay on the one hand, and bandwidth efficiency on the other. R EFERENCES [1] S. Brunner and A. Ali, “Voice over IP 101: understanding VoIP networks”, Juniper Networks, white paper, Aug 2004. [2] “Recommendation H.323: Packet-based multimedia communication systems”, ITU-T Geneva, Switzerland, Feb. 1998. [3] J. Rosenberg et al., “SIP: Session Initiation Protocol,” Internet Engineering Task Force (IETF), RFC 3261, June 2002. [4] J. Davidson and J. Peters, Voice over IP Fundamentals. Indianapolis: Cisco Press, 2000. [5] J. Evans, and C. Filsfils, Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Francisco: Morgan Kaufmann, 2007.
Figure 10. Number of Simultaneous Calls per 1 Mb Link
[6] “Recommendation G.114: One-Way Tr ansmission Time”, ITU-T, May 2000. [7] R. Dimova, G. Georgiev, and Z. Stanchev, “Performance Analysis of QoS Parameters for Voice over IP Applications in a LAN Segment,” International Scientific Conference Computer Science, 2008. [8] S. P. Mehta, “Comparative Study of Techniques to minimize packet loss in VoIP,” 2005. [Online]. Available: http://www.rh.edu/~rhb/cs_seminar_2005/SessionB3/mehta.pdf . [Accessed: June 13, 2010]. [9] E. C. Rosen, A. Viswanathan, and R. Callon, “Multiprotocol Label Switching Architecture,” Internet Engineering Task Force (IETF), RFC 3031, Jan. 2001. [10] E. C. Rosen, and Y. Rakhter, “BGP/MPLS VPNs,” Internet Engineering Task Force (IETF), RFC 2547, Mar. 1999. [11] A. Abdelhalim, “IP/MPLS-Based VPNs: Layer-3 vs. Layer-2,” Foundry Networks, white paper, 2002. [12] C. Semeria, “RFC 2547bis: BGP/MPLS VPN Fundamentals,” Juniper Networks, white paper, Mar. 2001. [13] D. Minoli, Voice over MPLS: Planning and Designing Networks . New York: McGraw-Hill Telecom, May 2002.
Figure 11. Overhead Ratio of the Acceptable Codecs Implementations
[14] D. Wright, “Voice over MPLS Compared to Voice over Other Packet Transport Technologies,” IEEE Communications Magazine, vol. 40, pp. 124-132, Nov. 2002.
