Presentation is loading. Please wait.

Presentation is loading. Please wait.

Deployment of MPLS VPN in Large ISP Networks Luyuan Fang IP Network Architecture AT&T.

Similar presentations

Presentation on theme: "Deployment of MPLS VPN in Large ISP Networks Luyuan Fang IP Network Architecture AT&T."— Presentation transcript:

1 Deployment of MPLS VPN in Large ISP Networks Luyuan Fang IP Network Architecture AT&T

2 NANOG21, February 2001, Atlanta 2 Outline Requirements Associated with the Deployment of MPLS VPN in an ISP Network Strategy for the Incremental Deployment of MPLS VPN MPLS VPN - Implementation Options Carrier’s Carrier and Inter-provider Backbone VPN Deployment Issues and Future Work

3 NANOG21, February 2001, Atlanta 3 Requirements Associated with the Deployment of MPLS VPN in an ISP Network Preservation of network integrity the new service features must not entail the risk of degrading the reliability and availability of the existing network Scalability Scaleable to large number of provider-based VPN Network of network VPN services Carrier’s Carrier and Inter-provider backbone VPN Satisfaction of customers’ security requirements Proactive management and fast restoration in case of failure

4 NANOG21, February 2001, Atlanta 4 Strategy for the Incremental Deployment of MPLS VPN The steps described here are simplified for illustrative purposes The steps may not be followed in the exact order proposed in a production environment Different steps may also be taken simultaneously, depending on the business needs, feature availability, and interoperability

5 NANOG21, February 2001, Atlanta 5 Strategy for the Incremental Deployment of MPLS VPN (2) Step 1. Preparation: Extensive lab test: feature, regression, network integration Potential hardware and software upgrade on all routers (P’s - Provider backbone routers, and PE’s - Provider Edge routers) for supporting MPLS LDP, VPN, RSVP features Routing IGP - link state protocol, e.g. OSPF or IS-IS BGP - multiple BGP sessions for VPN PE routers

6 NANOG21, February 2001, Atlanta 6 Strategy for the Incremental Deployment of MPLS VPN (3) Step 2. Enable MPLS in the core Enable LDP on all backbone routers if possible MPLS TE may be enabled in certain areas as necessary The distribution and access routers may not be all MPLS enabled at this time

7 NANOG21, February 2001, Atlanta 7 Strategy for the Incremental Deployment of MPLS VPN (4) Step 3. Basic MPLS VPN connectivity with limited sites and limited number of VPN’s: Upgrade the hardware and software on the VPN PE routers only Enable LDP and VPN on the selected PE’s Step 4. Expand the MPLS VPN footprint Enable MPLS LDP in more (or all) router locations Enable VPN in additional PE routers as needed Step 5. MPLS VPN General Availability

8 NANOG21, February 2001, Atlanta 8 Strategy for the Incremental Deployment of MPLS VPN (5) Step 6. Inter-AS MPLS VPN and Carrier’s Carrier Interconnect different AS’s of the same provider providing MPLS VPN services Interconnect with international partners for Global reachability Provide VPN services to other ISP’s– Carrier’s Carrier VPN Step 7. QoS-enabled MPLS VPN Enable QoS features for the MPLS network, including VPN Using QoS VPN for potential VoIP, Video services

9 MPLS VPN - Implementation Options

10 NANOG21, February 2001, Atlanta 10 Configuration: IGP (e.g. OSPF, or IS-IS) routing in the core MPLS (e.g. LDP) enabled for all P and PE routers MP-iBGP fully meshed between PE’s VPN configured on VPN PE’s PE-CE can be e-BGP, OSPF, RIP or Static Setting up LSP through LDP, LSP path = IGP path - Simplicity Requires LDP interoperability; VPN/LDP inter-working No control on LSP, label failure on IGP path can cause VPN failure Case Study 1: VPN (PE) + LDP (P, PE) VPN A VPN B VPN A VPN B VPN LDP VPN LDP VPN LDP VPN P1 P2 P3 P4 P5 LSP - Label Switched Path PHP LDP PHP: Penultimate Hop Popping

11 NANOG21, February 2001, Atlanta 11 Requires RSVP TE tunnel, potentially across multi-OSPF areas Requires RSVP TE interoperability; VPN / TE inter-working End-to-end LSP control - better failure protection, fast re-route may be used VPN A VPN B VPN A VPN B VPN P1 P2 P3 P4 P5 TE VPNTE VPN TE VPN OSPF area 0 OSPF area 1 OSPF area 2 Configuration: Using RSVP TE Tunnel (PE-PE) to set up the LSP Set up back-up tunnel for failure protection IGP, BGP, VPN, and PE-CE link configuration as in Case 1 Case Study 2: VPN (PE) + RSVP TE Tunnel (PE-PE) PHP TE

12 NANOG21, February 2001, Atlanta 12 Configuration: LDP enabled on all routers, except P4 and P5 RSVP TE Tunnels used only in OSPF area 0 (P1-P3-P5), with back-up tunnel (P1-P2-P4-P5) Requires RSVP TE interoperability Requires VPN/LDP inter-working, LDP/TE inter-working Provides feasible solutions when cases 1 and 2 cannot be realized Case Study 3: VPN + LDP + RSVP TE Tunnel VPN A VPN B VPN A VPN B VPN P1 P2 P3 P4 P5 OSPF area 0 OSPF area 1 OSPF area 2 LDP VPN LDP VPN TE LDP VPN P3 PHP LDP PHP TE

13 NANOG21, February 2001, Atlanta 13 ISP A backbone provides VPN services to ISP B Case 1. ISP B may not run MPLS in its network Case 2. ISP B may run MPLS (LDP) in its network Case 3. ISP B may run MPLS VPN in its network - Hierarchical VPN’s ISP B - Site Y ISP B’s Customers PE2 ISP A Carrier Backbone ISP B - Site X ISP B’s Customers CE2 CE1PE1 ASBR1, RR ASBR2, RR iBGP MP- iBGP LDP VPN B VPN A VPN B LDP VPN A VPN B LDP VPN A VPN B LDP VPN B LDP VPN A VPN B LDP VPN B Carrier’s Carrier VPN Case 3 Carrier’s Carrier VPN

14 NANOG21, February 2001, Atlanta 14 Carrier’s Carrier VPN (2) MPLS (LDP) used between PE and CE in all three cases PE-CE routing: OSPF/RIP/Static Security mechanism needed for label “spoofing” prevention iBGP sessions between ISP B sites Use Route Reflectors to improve scalability ISP A distributes ISP B’s internal routes through MPLS-VPN only ISP B’s external routes advertised to all ISP B site through ISP B’s Route Reflector iBGP session

15 NANOG21, February 2001, Atlanta 15 Inter-Providers Backbone VPN Customers have sites connected to different AS’s or ISP’s PE-ASBR’s connect the two AS’s E-BGP sessions for VPN-IPv4 single VPN label, no LDP label no VRF assigned, based on policy agreed by the two ISP’s (AS’s) Route reflectors reflect VPN-IPv4 internal routes within its AS Security, scalability, policies between ISP’s PE-ASBR1 PE-ASBR2 AS B CE1CE2 PE1 PE2 RR-ARR-B LDP VPN B LDP VPN A LDP VPN A VPN AB AS A MP- eBGP MP- iBGP

16 NANOG21, February 2001, Atlanta 16 MPLS VPN Deployment Issues MPLS Feature availability VPN, LDP, RSVP, CR-LDP: individually, and Inter- working amongst subsets of these Coping with reality of feature availability Multi-vendor inter-operability Required in an heterogeneous IP network Deployment strategy Partially enable MPLS vs. Fully enable MPLS in the entire IP backbone TE tunnels, use only as needed vs. fully meshed QoS VPN: map VPN into guaranteed bandwidth tunnels with class of service

17 NANOG21, February 2001, Atlanta 17 MPLS VPN Deployment Issues (2) Scalability The use of Route Reflectors Performance impact on PE’s needs to be measured Carrier of Carriers and Inter-AS backbone Load sharing between PE-CE links Assign different RDs to different sites vs. single RD for each VPN Security One VPN’s route does not exist in other non- connected VPN’s VRF or the global routing table FR/ATM equivalent security - more study needed

18 NANOG21, February 2001, Atlanta 18 MPLS VPN Network Management Available MIBs today LSR MIB, LDP MIB, VPN MIB, MBGP MIB, RSVP TE MIB, FTN MIB,… Configuration and Provisioning Auto-provisioning tools needed for large scale VPN deployment

19 NANOG21, February 2001, Atlanta 19 MPLS VPN Network Management (2) Performance All MPLS features impact on performance, including basic VPN on PE routers, and need to be studied More study needed for VPN supporting QoS Network performance: delay, jitter, loss, throughput, availability Element performance: utilization Security management Authentication, control access, monitoring

20 NANOG21, February 2001, Atlanta 20 Traffic Management/Engineering Characterize traffic for VPN’s Profiling, correlation, and optimization Fault management Monitoring and troubleshooting VPN failure detection and recovery MPLS VPN Network Management (3) PE1 PE3 P1 P3 P2 P4 PE2 PE4 CE1 VPN A X CE2 VPN A Y Example: Config: LDP in the core for all P and PE router; IGP: OSPF; iBGP full mesh between PE’s LSP: OSPF shortest path: PE1-P1-P3-P4-PE2; no TE tunnels. Failure: All links and nodes are up, but P3 label switching fails, LSP breaks, VPN fails. Solution need: PE1 and PE2 need to to be notified of the LSP failure; LSP needs to be re-established through recovery mechanism, restore VPN

21 NANOG21, February 2001, Atlanta 21 Summary Incremental deployment of BGP/MPLS VPN in IP backbone is feasible Implementation alternatives and examples illustrated here are being experimented with through lab testing Deployment Challenges Feature availability Interoperability Manageability

22 NANOG21, February 2001, Atlanta 22 Summary (2) Future work Resolve open issues on scalability, load sharing, and security Better understand service deployment and management

23 Thank You Luyuan Fang Principal Technical Staff Member IP Network Architecture AT&T

Download ppt "Deployment of MPLS VPN in Large ISP Networks Luyuan Fang IP Network Architecture AT&T."

Similar presentations

Ads by Google