QoS Performance Evaluation in BGP/MPLS VPN

More documents

Recommendations

Info

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.
Page 1 and 2: 1QoS Performance Evaluation inBGP/M
Page 3: 3TABLE IIFTP APPLICATION PARAMETERS

QoS Performance Evaluation in BGP/MPLS VPN

Create successful ePaper yourself

Delete template?

Save as template?