QoS Performance Evaluation in BGP/MPLS VPN

1QoS Performance Evaluation inBGP/MPLS VPNM. C. Castro, N. A. Nassif and W. C. Borelli1Abstract-- The recent exponential growth of the Internet hasencouraged more applications, users and services to be deployed.BGP/MPLS VPN is an emerging architecture that providessecure data forwarding through a shared network connectingsites geographically distributed. In spite of this, Quality of Service(QoS) mechanisms can be applied to provide trafficdifferentiation through resource reservation and packetprioritization. This paper describes a proposal for supportingQoS over Virtual Private Networks (VPNs) combiningBGP/MPLS VPN and MPLS/DiffServ. Extensive computersimulation has been implemented with Opnet to work outmultimedia traffic performance in terms of delay, jitter,throughput and packet loss under varying load conditions.AI. INTRODUCTIONVPN interconnects multiple sites over sharedinfrastructure as well as providing the same access andsecurity policies as a private network.VPN should enable customer sites to be flexibly connected.That is, depending on the requirements of the business, itshould be possible to build extranets, intranets or accessnetworks. A VPN should support arbitrary topology such ashub and spoke, full mesh, as well as providing network anddata privacy and enabling opaque transport of VPN trafficacross the SP network. It should also provide the Quality ofService (QoS) [2][4][5] that the business needs. Above all, aVPN must scale to several hundreds and thousands of sites andusers. Therefore, the technology that is chosen to set up theVPN service must satisfy the requirements of privacy,flexibility, scalability and QoS.Traditionally, VPNs were set up using leased lines betweencustomer sites or used tunneling and security software that ranon CPE (Customer Premises Equipment) devices. Thesetechnologies are not cost-effective solutions for smallenterprises and do not scale well for large enterprises. Instead,customers can utilize the outsourcing potential of SP (ServiceProvider) services for cost savings and access to networkingexperience. It should not be necessary to install VPNappliances for providing authentication, encryption andtunneling, as these functions can be delegated to the serviceprovider. A network-based VPN or Provider Provisioned VPNN. 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 calledRFC2547bis [1], which is one kind of PPVPN proposed byIETF. In this architecture, Border Gateway Protocol (BGP)[2][3] is used to exchange VPN routing information andMPLS is used to forward VPN traffic, allowing current workto focus on experimentation and analysis of QoS support overa VPN example under defined multimedia traffic (FTP, Videoand Voice). The proposed architecture is implemented in a SPinfrastructure and applies techniques of DiffServ [5] andMPLS [6]. Simulation results of delay, jitter, throughput andpacket loss with this strategy are presented and discussed.II. BGP/MPLS VPNAn BGP/MPLS VPN [1] is a VPN arquitecture describedas a set of Customer Edge (CE) routers, each attached to oneor more Provider Edge (PE) routers that are members of theprovider network. The network also includes Provider Core(P) routers (Figure 1). In this model, only the PE routersmaintain VPN membership and topology information. The CErouters take no active part in the MPLS protocol and usestandard IP policies to exchange data and control informationwith other subscribers of their respective VPNs. PE routersdelegate reachability information between VPN members byestablishing BGP peer relationships only with other PE routersattached to members of the same VPNs. LSPs are establishedbetween BGP peers and may carry traffic associated withmultiple VPNs. BGP/MPLS VPN can use overlappingaddress 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 multipleforwarding tables (VRF). Provider Edge (PE) routers maintaina separate default forwarding table that contains publicInternet routes and several VRF tables that contain VPNroutes. The CE and PE devices exchange VPN routinginformation using existing routing protocols such as Routing

2Information Protocol (RIP), OSPF and BGP. Routes learnedare installed in the corresponding VRF table(s) based on therouting protocol’s decision process. At the PE device, theVPN routes, that were determined from the attached CEdevices, are installed in VRF tables and the PE devices mustexchange these routes with other PE devices. MultiprotocolBGP (MP-BGP) [3] is used to distribute VPN routes to otherPE devices across the SP network. Since VPNs can useoverlapping address spaces, BGP may determine routes todestinations with the same address prefix.The concept of Label Stacking (known as hierarchy oflabels) is used when building BGP/MPLS VPN. The ingressrouter appends two labels to a packet belonging to a VPN. Theinner label specifies the egress port at the SP egress router (thelink toward the destination sub-network of the VPN) and theouter label is being used to forward the packet toward theegress router. With MP-BGP, the ingress router works out theinner label information, and the outer label data is gained byMPLS 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 SPbackbone does not need any protocol software upgrades andcan function as it is. This is because the P routers are not VPNaware. The VPN routes are exchanged between PE devicesand the P routers are unaware of these routes. However, thismeans that VPN traffic must be forwarded opaquely across theSP backbone and that the VPN traffic must be tunneled acrossthe network. This is achieved by setting up MPLS tunnelsbetween the PE devices.III. SUPPORT OF QOS FOR VPNThe provision of Quality of Service (QoS) is an intrinsicpart of emerging services centered on provider-provisionedVPNs (PPVPNs). One solution to provide QoS functionality toBGP/MPLS VPNs is to implement an MPLS/DiffServinteroperation at the core of network.MPLS and DiffServ [9] can be applied together as theyhave some similar features that permit them to beinteroperable. Both technologies perform packet classificationonly in the ingress edge router (LER), considering that bothconsider aggregated classes of traffic: MPLS with FECs andDiffServ with PHBs.Short fixed length labels are used in both networks, whichare called MPLS labels in MPLS networks and DSCPs inDiffServ networks. Routers in the core network treat thepackets according to these tags and the DSCP of a packetdetermines the behaviors of the nodes regarding schedulingmechanisms and queuing management. This typically definesthe priority and the drop precedence of the packets.The MPLS label of a packet determines the path the packettakes and the packet is routed based on its label. TrafficEngineering [9] can be performed by assigning certain labelsto paths with certain characteristics. Therefore, by combiningboth approaches, it is possible to specify the paths that thepackets take and their behaviors in the queues of differentrouters.The IETF has proposed two ways in which MPLS andDiffServ interoperates [4]. In one model, the DSCP in the IPheader is copied onto the EXP field of the MPLS shim headerand appropriated packet treatment is given based on the valuecontained in the EXP field (E-LSP).In another model, an MPLS signaling protocol like LDP orRSVP-TE is used to signal labels per class per IP sourcedestination pair (L-LSP).The experiment employed the techniques described in thefirst model, E-LSP. And our mapping of PHB to EXP isdepicted at Table I.TABLE IEXP – PHB MAPPINGEXP PHB WFQ Weights0 AF11 51 AF21 102 AF22 103 AF31 154 AF32 155 AF41 256 AF42 257 EF 55IV. SIMULATED SCENARIOA. Scenario 1: BGP/MPLS VPN ScenarioThis section presents the BGP/MPLS VPN Scenario and itsconfiguration, which is the base for the other simulations builtfor testing the QoS mechanisms into VPN.The simulated network is illustrated in Figure 2 thatrepresents a service provider with two VPN clients. Each VPNclient has two site locations. All links are full duplex and areconfigured as follows:Links between routers 3600A, 3600B and 3600D are 6,5Mbps, others links between routers are 10Mbps and linksbetween servers/workstations and routers are 10BaseT.Figure 2 : Opnet Simulated Network TopologyThree applications (FTP, Video and VoIP) were configuredaccording to the parameters presented in Table II, III and IV.FTP and Video traffic flows only from servers to clients andVoIP traffic flows between the servers and clients.

3TABLE IIFTP APPLICATION PARAMETERS SETFTP TableCommand Mix (Get/Total) 100%Inter-Request Time (sec)File Size (bytes)exponential(1)pareto(83333.33,1.5)Type of Service Best Effort (0)TABLE IIIVIDEO APPLICATION PARAMETERS SETVideo Conferencing TableFrame Interarrival Time (sec) constant(0.1)Frame Size (bytes)exponential(15625)Type of Service Best Effort (0)TABLE IVVOICE APPLICATION PARAMETERS SETVoIP TableSilence Length (sec) exponential(0.65)Talk Spurt Length (sec) exponential(0.352)Encoder Scheme GSM (silence)Voice Frames per Packet 1Type of Service Best Effort (0)These configured application definitions generate a FTPtraffic load of 2.0 Mbps, Video Conferencing traffic load of1.5 Mbps and VoIP traffic load of 20Kbps in each VPNClient.Routers implement FIFO (First In First Out) queuingmechanism using 1MByte buffer interfaces.To see how different VPN Client traffics with differentpriorities impact each other, all traffic of VPN Client 1 startedat the beginning of the simulation and VPN Client 2 trafficstarted during the simulation time, with Video and VoIP trafficstarting fifteen minutes later and FTP traffic starting after athirty minute period.B. Scenario 2: Combining MPLS with DiffServThe purpose of this scenario is to show that by combiningDifferentiated Services with MPLS, the Quality of Servicemay be improved. This scenario is an evolution of theBGP/MPLS VPN Scenario.The following briefly describes the steps involved inassociating QoS at BGP/MPLS VPN Scenario:• The IP Type of Service (ToS) for a packet is set withinthe application. So, FTP, Video and VoiceApplications were set as illustrated in Table V below.• Router interfaces were set to implement WFQ queuingscheme as shown at Table I.• Mapping between DSCP and EXP field, according toTable I was set in the LSRs.TABLE VPER HOP BEHAVIOUR CONFIGURATIONApplication PHBFTP_1AF21VPN Client 1 Video_1AF41Voice_1EFFTP_2AF11VPN Client 2 Video_2AF11Voice_2AF11C. Scenario 3: Improving Results with Traffic EngineeringHere, the goal is to show that the throughput can beimproved for the traffic from each site by usingMPLS/DiffServ and Traffic Engineering. This applies thesame features as Scenario 2 but with a minimum bandwidthconstraint for LSP establishment, which is configured to thevalue below:• VPN Client 1 – 4.0 Mbps• VPN Client 2 – 4.0 MbpsV. SIMULATION RESULTSSimulations results presented in this section was obtainedby Opnet 2 and compare the behaviors of FTP downloadresponse time, Video Conferencing packet end-to-end delay,VoIP packet end-to-end delay, Video Conferencing jitter andVoIP jitter of VPN Clients; for each one of the previousexposed scenarios.In the first two scenarios, BGP/MPLS VPN and CombiningMPLS with DiffServ, all VPN Client traffic is transmitted overthe same path, from the router 3600D directly to the router3600A, as shown in the left graph of Figure 3.Therefore, in Scenario 3, Improving Results with TrafficEngineering, the minimum bandwidth constraint applied foreach LSP forced the VPN Client 2 Traffic travels from 3600Dto router 3600B via the 3600A router, as shown in the rightgraph of Figure 3. It happens because the available bandwidthwas too low on the path directly connecting 3600D to 3600B.Figure 3 : Througput ResultsFigure 4, 5 and 6 show the FTP, Video and VoIP delayresults for each VPN Client (VPN Client 1 in the left graphsand VPN Client 2 on the right).As expected, the FTP, Video and VoIP traffic of VPN2 Opnet Simulator purchased by CPqD Telecom & IT Solution

4Client 1 have better results in comparison with traffic of VPNClient 2.In Scenario 1, BGP/MPLS VPN, all traffic from VPNClient 1 was degraded with the insertion of VPN Client 2traffic due to both clients sharing the same network resource.Without any QoS mechanism, there is no protection among theapplications and VPN Client traffic. In Scenario 2, CombiningMPLS with DiffServ, using WFQ queuing scheme queues arecreated for each PHB. Four queues are served through a roundrobin mechanism; both prioritising the VoIP and Video trafficof VPN Client 1 and sharing the network resources with FTPtraffic of VPN Client 1 and all traffic of VPN Client 2. AsVPN Client 1 traffic has higher priority their results are betterin comparison with VPN Client 2. At the same time, results areimproved as a classification is made (MPLS with DiffServScenario) and traffic engineering is implemented (ImprovingResults with Traffic Engineering).degraded by other traffic with a higher priority.Figure 7: Video Conferencing JitterFigure 8: VoIP JitterFigure 4: FTP Download Response TimeFigure 5: Video Conferencing Packet End-to-End DelayAs shown in Figure 9, there has been significant packet lossin Scenarios 1 and 2. In Scenario 1, using FIFO queuingscheme, packets were discarded without any criterion.However, in Scenario 2, using WFQ, each queue is servedwith protection (WFQ prevents one queue from beingdamaged by another, where a service time, which is priorityproportional, is guaranteed for each queue) so it can be seenthat packet loss occurs at Queue 0 in Interface 7 connectingrouters 3600D and 3600A, as shown in the right graph ofFigure 9. By analyzing the simulations in Figure 3, traffic ofAF11 passes through this queue, so traffic of VPN Client 2,with a lower priority, is discarded.In Scenario 3 the traffic engineering that is implementedallows new links to be explored now, increasing the overallnetwork throughput and ultimately guaranteeing the optimumscenario delay results.Figure 6: VoIP Packet End-to-End DelayFigure 7 and 8 show that Video and VoIP jitter values werehigh at VPN Client 2 traffic. This happens because they areFigure 9: Packet Loss

5VI. CONCLUSIONThe interoperation of MPLS and DiffServ has manybenefits, mainly when Traffic Engineering is implemented.One benefit is the possibility of providing end-to-end QoSthrough different network domains. Used with DiffServ,MPLS can apply traffic differentiation, mapping the DSCPinto the EXP field from MPLS header.The main benefit of MPLS is to provide traffic engineeringand resource reservation. In Scenario 3, Improving Resultswith Traffic Engineering, the VPN Client 2 traffic wasestablished in a different path from the shortest path chosen bythe conventional routing protocol. Using alternatives paths, theuse of network resources can be optimized and the traffic loadcan be distributed over many paths. The applicationperformance can thus increase, being forwarded over a pathwith reserved resources.By combining MPLS with DiffServ, advantages can beincreased further. VPN Clients traffic can be forwardedthrough a pre-determined path with resource reservation.Otherwise, if congestion is present, the complementarytechnique of DiffServ can be used to give priority to thecritical applications.Notice that the most difficult task is to identify which arethe most critical applications and to define which service classmust be assigned to each application. In this paper VoIP andVideo of VPN Client 1 were considered the most importantapplications due to their real time requirements and clientnecessity. In a congestion situation they received a bettertreatment from the network guaranteeing short delay and jitter.On the other hand, results show that the less priority classeswith 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”, RFC3346, 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 ofService: A Service Provider Perspective”, IEEE CommunicationsMagazine, 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 RoutingCapability”, Interworking 2000, pp. 292-301, 2000.[5] H. Lee, J. Hwang, B. Kang and K. Jun, “End-To-End QoS Architecturefor VPNs: MPLS VPN Deployment in a Backbone Network” presentedat International Workshop on Parallel Processing, Toronto, Canada,2000.[6] T. Bates, Y. Rekhter, R. Chandra, D. Katz: “Multiprotocol Extensionsfor BGP-4”, RFC2858, June 2000.[7] F. L. Faucheur, B. Davie, S. Davari, P. Vaananen: “MPLS Support ofDifferentiated Services”, RFC 3270, May 2002.[8] S. Blake, D. Black, M. Carlson, E. Davies: “ An Architecture forDifferentiated 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 IEEEConference on Local Computer Networks (LCN 2001), November 2001,Tampa, Florida, USA.[10] E. Rosen, A. Viswanathan, R. Callon: “Multiprotocol Label SwitchingArchitecture”, RFC3031, January 2001.[11] B. Jamoussi, L. Andersson, R. Callon and R. Dantu: “Constraint-BasedLSP 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.