QoS Performance Evaluation in BGP/MPLS VPN

1 QoS Performance Evaluation in BGP/MPLS VPN M. C. Castro, N. A. Nassif and W. C. Borelli 1 Abstract-- The recent exponential growth of the Internet has encouraged more applications, users and services to be deployed. BGP/MPLS VPN is an emerging architecture that provides secure data forwarding through a shared network connecting sites geographically distributed. In spite of this, Quality of Service (QoS) mechanisms can be applied to provide traffic differentiation through resource reservation and packet prioritization. This paper describes a proposal for supporting QoS over Virtual Private Networks (VPNs) combining BGP/MPLS VPN and MPLS/DiffServ. Extensive computer simulation has been implemented with Opnet to work out multimedia traffic performance in terms of delay, jitter, throughput and packet loss under varying load conditions. A I. INTRODUCTION VPN interconnects multiple sites over shared infrastructure as well as providing the same access and security policies as a private network. VPN should enable customer sites to be flexibly connected. That is, depending on the requirements of the business, it should be possible to build extranets, intranets or access networks. A VPN should support arbitrary topology such as hub and spoke, full mesh, as well as providing network and data privacy and enabling opaque transport of VPN traffic across the SP network. It should also provide the Quality of Service (QoS) [2][4][5] that the business needs. Above all, a VPN must scale to several hundreds and thousands of sites and users. Therefore, the technology that is chosen to set up the VPN service must satisfy the requirements of privacy, flexibility, scalability and QoS. Traditionally, VPNs were set up using leased lines between customer sites or used tunneling and security software that ran on CPE (Customer Premises Equipment) devices. These technologies are not cost-effective solutions for small enterprises and do not scale well for large enterprises. Instead, customers can utilize the outsourcing potential of SP (Service Provider) services for cost savings and access to networking experience. It should not be necessary to install VPN appliances for providing authentication, encryption and tunneling, as these functions can be delegated to the service provider. A network-based VPN or Provider Provisioned VPN N. A. Nassif works at CPqD Telecom & IT Solutions, Campinas-SP, Brazil (e-mail: nadia@cpqd.com.br). M. C. Castro and W. C. Borelli are with the Department of Telematic, State University of Campinas, Campinas-SP, Brazil (e-mail: castro@dt.fee.unicamp.br and borelli@dt.fee.unicamp.br). (PPVPN) is a VPN built using the SP s backbone. This paper discusses BGP/MPLS VPN, also called RFC2547bis [1], which is one kind of PPVPN proposed by IETF. In this architecture, Border Gateway Protocol (BGP) [2][3] is used to exchange VPN routing information and MPLS is used to forward VPN traffic, allowing current work to focus on experimentation and analysis of QoS support over a VPN example under defined multimedia traffic (FTP, Video and Voice). The proposed architecture is implemented in a SP infrastructure and applies techniques of DiffServ [5] and MPLS [6]. Simulation results of delay, jitter, throughput and packet loss with this strategy are presented and discussed. II. BGP/MPLS VPN An BGP/MPLS VPN [1] is a VPN arquitecture described as a set of Customer Edge (CE) routers, each attached to one or more Provider Edge (PE) routers that are members of the provider network. The network also includes Provider Core (P) routers (Figure 1). In this model, only the PE routers maintain VPN membership and topology information. The CE routers take no active part in the MPLS protocol and use standard IP policies to exchange data and control information with other subscribers of their respective VPNs. PE routers delegate reachability information between VPN members by establishing BGP peer relationships only with other PE routers attached to members of the same VPNs. LSPs are established between BGP peers and may carry traffic associated with multiple VPNs. BGP/MPLS VPN can use overlapping address spaces as long as they do not use common sites. Figure 1. Arquitecture of Provider Provisioned VPN (BGP/MPLS VPN) Isolation of VPN traffic is achieved using multiple forwarding tables (VRF). Provider Edge (PE) routers maintain a separate default forwarding table that contains public Internet routes and several VRF tables that contain VPN routes. The CE and PE devices exchange VPN routing information using existing routing protocols such as Routing

2 Information Protocol (RIP), OSPF and BGP. Routes learned are installed in the corresponding VRF table(s) based on the routing protocol s decision process. At the PE device, the VPN routes, that were determined from the attached CE devices, are installed in VRF tables and the PE devices must exchange these routes with other PE devices. Multiprotocol BGP (MP-BGP) [3] is used to distribute VPN routes to other PE devices across the SP network. Since VPNs can use overlapping address spaces, BGP may determine routes to destinations with the same address prefix. The concept of Label Stacking (known as hierarchy of labels) is used when building BGP/MPLS VPN. The ingress router appends two labels to a packet belonging to a VPN. The inner label specifies the egress port at the SP egress router (the link toward the destination sub-network of the VPN) and the outer label is being used to forward the packet toward the egress router. With MP-BGP, the ingress router works out the inner label information, and the outer label data is gained by MPLS signaling protocols such as CR-LDP [7] or RSVP-TE [8]. The egress router pops both labels. One of the benefits of using BGP/MPLS VPN is that the SP backbone does not need any protocol software upgrades and can function as it is. This is because the P routers are not VPN aware. The VPN routes are exchanged between PE devices and the P routers are unaware of these routes. However, this means that VPN traffic must be forwarded opaquely across the SP backbone and that the VPN traffic must be tunneled across the network. This is achieved by setting up MPLS tunnels between the PE devices. III. SUPPORT OF QOS FOR VPN The provision of Quality of Service (QoS) is an intrinsic part of emerging services centered on provider-provisioned VPNs (PPVPNs). One solution to provide QoS functionality to BGP/MPLS VPNs is to implement an MPLS/DiffServ interoperation at the core of network. MPLS and DiffServ [9] can be applied together as they have some similar features that permit them to be interoperable. Both technologies perform packet classification only in the ingress edge router (LER), considering that both consider aggregated classes of traffic: MPLS with FECs and DiffServ with PHBs. Short fixed length labels are used in both networks, which are called MPLS labels in MPLS networks and DSCPs in DiffServ networks. Routers in the core network treat the packets according to these tags and the DSCP of a packet determines the behaviors of the nodes regarding scheduling mechanisms and queuing management. This typically defines the priority and the drop precedence of the packets. The MPLS label of a packet determines the path the packet takes and the packet is routed based on its label. Traffic Engineering [9] can be performed by assigning certain labels to paths with certain characteristics. Therefore, by combining both approaches, it is possible to specify the paths that the packets take and their behaviors in the queues of different routers. The IETF has proposed two ways in which MPLS and DiffServ interoperates [4]. In one model, the DSCP in the IP header is copied onto the EXP field of the MPLS shim header and appropriated packet treatment is given based on the value contained in the EXP field (E-LSP). In another model, an MPLS signaling protocol like LDP or RSVP-TE is used to signal labels per class per IP source destination pair (L-LSP). The experiment employed the techniques described in the first model, E-LSP. And our mapping of PHB to EXP is depicted at Table I. TABLE I EXP PHB MAPPING EXP PHB WFQ Weights 0 5 1 AF21 10 2 AF22 10 3 AF31 15 4 AF32 15 5 AF41 25 6 AF42 25 7 EF 55 IV. SIMULATED SCENARIO A. Scenario 1: BGP/MPLS VPN Scenario This section presents the BGP/MPLS VPN Scenario and its configuration, which is the base for the other simulations built for testing the QoS mechanisms into VPN. The simulated network is illustrated in Figure 2 that represents a service provider with two VPN clients. Each VPN client has two site locations. All links are full duplex and are configured as follows: Links between routers 3600A, 3600B and 3600D are 6,5 Mbps, others links between routers are 10Mbps and links between servers/workstations and routers are 10BaseT. Figure 2 : Opnet Simulated Network Topology Three applications (FTP, Video and VoIP) were configured according to the parameters presented in Table II, III and IV. FTP and Video traffic flows only from servers to clients and VoIP traffic flows between the servers and clients.

3 TABLE II FTP APPLICATION PARAMETERS SET FTP Table Command Mix (Get/Total) 100% Inter-Request Time (sec) File Size (bytes) exponential(1) pareto(83333.33,1.5) TABLE III VIDEO APPLICATION PARAMETERS SET Video Conferencing Table Frame Interarrival Time (sec) constant(0.1) Frame Size (bytes) exponential(15625) TABLE IV VOICE APPLICATION PARAMETERS SET VoIP Table Silence Length (sec) exponential(0.65) Talk Spurt Length (sec) exponential(0.352) Encoder Scheme GSM (silence) Voice Frames per Packet 1 These configured application definitions generate a FTP traffic load of 2.0 Mbps, Video Conferencing traffic load of 1.5 Mbps and VoIP traffic load of 20Kbps in each VPN Client. Routers implement FIFO (First In First Out) queuing mechanism using 1MByte buffer interfaces. To see how different VPN Client traffics with different priorities impact each other, all traffic of VPN Client 1 started at the beginning of the simulation and VPN Client 2 traffic started during the simulation time, with Video and VoIP traffic starting fifteen minutes later and FTP traffic starting after a thirty minute period. B. Scenario 2: Combining MPLS with DiffServ The purpose of this scenario is to show that by combining Differentiated Services with MPLS, the Quality of Service may be improved. This scenario is an evolution of the BGP/MPLS VPN Scenario. The following briefly describes the steps involved in associating QoS at BGP/MPLS VPN Scenario: The IP Type of Service (ToS) for a packet is set within the application. So, FTP, Video and Voice Applications were set as illustrated in Table V below. Router interfaces were set to implement WFQ queuing scheme as shown at Table I. Mapping between DSCP and EXP field, according to Table I was set in the LSRs. TABLE V PER HOP BEHAVIOUR CONFIGURATION Application PHB FTP_1 AF21 VPN Client 1 Video_1 AF41 Voice_1 EF FTP_2 VPN Client 2 Video_2 Voice_2 C. Scenario 3: Improving Results with Traffic Engineering Here, the goal is to show that the throughput can be improved for the traffic from each site by using MPLS/DiffServ and Traffic Engineering. This applies the same features as Scenario 2 but with a minimum bandwidth constraint for LSP establishment, which is configured to the value below: VPN Client 1 4.0 Mbps VPN Client 2 4.0 Mbps V. SIMULATION RESULTS Simulations results presented in this section was obtained by Opnet 2 and compare the behaviors of FTP download response time, Video Conferencing packet end-to-end delay, VoIP packet end-to-end delay, Video Conferencing jitter and VoIP jitter of VPN Clients; for each one of the previous exposed scenarios. In the first two scenarios, BGP/MPLS VPN and Combining MPLS with DiffServ, all VPN Client traffic is transmitted over the same path, from the router 3600D directly to the router 3600A, as shown in the left graph of Figure 3. Therefore, in Scenario 3, Improving Results with Traffic Engineering, the minimum bandwidth constraint applied for each LSP forced the VPN Client 2 Traffic travels from 3600D to router 3600B via the 3600A router, as shown in the right graph of Figure 3. It happens because the available bandwidth was too low on the path directly connecting 3600D to 3600B. Figure 3 : Througput Results Figure 4, 5 and 6 show the FTP, Video and VoIP delay results for each VPN Client (VPN Client 1 in the left graphs and VPN Client 2 on the right). As expected, the FTP, Video and VoIP traffic of VPN 2 Opnet Simulator purchased by CPqD Telecom & IT Solution

4 Client 1 have better results in comparison with traffic of VPN Client 2. In Scenario 1, BGP/MPLS VPN, all traffic from VPN Client 1 was degraded with the insertion of VPN Client 2 traffic due to both clients sharing the same network resource. Without any QoS mechanism, there is no protection among the applications and VPN Client traffic. In Scenario 2, Combining MPLS with DiffServ, using WFQ queuing scheme queues are created for each PHB. Four queues are served through a round robin mechanism; both prioritising the VoIP and Video traffic of VPN Client 1 and sharing the network resources with FTP traffic of VPN Client 1 and all traffic of VPN Client 2. As VPN Client 1 traffic has higher priority their results are better in comparison with VPN Client 2. At the same time, results are improved as a classification is made (MPLS with DiffServ Scenario) and traffic engineering is implemented (Improving Results with Traffic Engineering). degraded by other traffic with a higher priority. Figure 7: Video Conferencing Jitter Figure 8: VoIP Jitter Figure 4: FTP Download Response Time Figure 5: Video Conferencing Packet End-to-End Delay As shown in Figure 9, there has been significant packet loss in Scenarios 1 and 2. In Scenario 1, using FIFO queuing scheme, packets were discarded without any criterion. However, in Scenario 2, using WFQ, each queue is served with protection (WFQ prevents one queue from being damaged by another, where a service time, which is priority proportional, is guaranteed for each queue) so it can be seen that packet loss occurs at Queue 0 in Interface 7 connecting routers 3600D and 3600A, as shown in the right graph of Figure 9. By analyzing the simulations in Figure 3, traffic of passes through this queue, so traffic of VPN Client 2, with a lower priority, is discarded. In Scenario 3 the traffic engineering that is implemented allows new links to be explored now, increasing the overall network throughput and ultimately guaranteeing the optimum scenario delay results. Figure 6: VoIP Packet End-to-End Delay Figure 7 and 8 show that Video and VoIP jitter values were high at VPN Client 2 traffic. This happens because they are Figure 9: Packet Loss

5 VI. CONCLUSION The interoperation of MPLS and DiffServ has many benefits, mainly when Traffic Engineering is implemented. One benefit is the possibility of providing end-to-end QoS through different network domains. Used with DiffServ, MPLS can apply traffic differentiation, mapping the DSCP into the EXP field from MPLS header. The main benefit of MPLS is to provide traffic engineering and resource reservation. In Scenario 3, Improving Results with Traffic Engineering, the VPN Client 2 traffic was established in a different path from the shortest path chosen by the conventional routing protocol. Using alternatives paths, the use of network resources can be optimized and the traffic load can be distributed over many paths. The application performance can thus increase, being forwarded over a path with reserved resources. By combining MPLS with DiffServ, advantages can be increased further. VPN Clients traffic can be forwarded through a pre-determined path with resource reservation. Otherwise, if congestion is present, the complementary technique of DiffServ can be used to give priority to the critical applications. Notice that the most difficult task is to identify which are the most critical applications and to define which service class must be assigned to each application. In this paper VoIP and Video of VPN Client 1 were considered the most important applications due to their real time requirements and client necessity. In a congestion situation they received a better treatment from the network guaranteeing short delay and jitter. On the other hand, results show that the less priority classes with fewer resources reserved do not improve the readings. [13] J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian: Applicability Statement for Traffic Engineering with MPLS, RFC 3346, August 2002. VII. REFERENCES [1] E. C. Rosen and Y. Rekhter, BGP/MPLS IP VPNs, draft-ietf-l3vpnrfc2547bis-01.txt, September 2003. [2] J. Zeng and N. Ansari, Toward IP Virtual Private Network Quality of Service: A Service Provider Perspective, IEEE Communications Magazine, pp. 113-119, Apr. 2003. [3] Y. Rekhter and T. Li: A Border Gateway Protocol 4 (BGP-4), RFC1771, March 1995. [4] P. Zhang and R. Kantola, Building MPLS VPNs with QoS Routing Capability, Interworking 2000, pp. 292-301, 2000. [5] H. Lee, J. Hwang, B. Kang and K. Jun, End-To-End QoS Architecture for VPNs: MPLS VPN Deployment in a Backbone Network presented at International Workshop on Parallel Processing, Toronto, Canada, 2000. [6] T. Bates, Y. Rekhter, R. Chandra, D. Katz: Multiprotocol Extensions for BGP-4, RFC2858, June 2000. [7] F. L. Faucheur, B. Davie, S. Davari, P. Vaananen: MPLS Support of Differentiated Services, RFC 3270, May 2002. [8] S. Blake, D. Black, M. Carlson, E. Davies: An Architecture for Differentiated Services. RFC 2475, December 1998. [9] R. Prabagaran and J. B. Evans, Experience with Class of Service (CoS) Translations in IP/MPLS Networks, presented at 26th Annual IEEE Conference on Local Computer Networks (LCN 2001), November 2001, Tampa, Florida, USA. [10] E. Rosen, A. Viswanathan, R. Callon: Multiprotocol Label Switching Architecture, RFC3031, January 2001. [11] B. Jamoussi, L. Andersson, R. Callon and R. Dantu: Constraint-Based LSP Setup using LDP, RFC3212, January 2002. [12] D. Awduche, L. Berger, T. Li, V. Srinivasan and G. Swallow: RSVP- TE: Extensions to RSVP for LSP Tunnels, RFC3209, December 2001.