Provider Provisioned Virtual Private Networks

1. Provider Provisioned Virtual Private Networks Wing C. Lau Performance Analysis Department Bell Labs, Lucent Technologies Holmdel, New Jersey Dec. 6. 2002

2. Outline • VPN • What is a VPN ? • Terminology • VPN Taxonomy • Evolution of VPN Technologies • IP/MPLS-based PPVPNs • Motivation • Basic Building Blocks • Requirements/ Selection Criteria • Technical Challenges / Future Directions

3. VPN Concepts • What is a Virtual Private Network ? • Use a Shared publicNetwork Infrastructure to emulate Private network facilities for a (Enterprise) Customer • A Single (Enterprise) customer can have multiple VPNs, each corresponds to a different community of interest, e.g. • a different group of end-users/ departments, • a VPN per external business partner, i.e. Extranet ; • A end-host (user) may participate in multiple VPNs simultaneously

4. VPN as a Community of Interest Customer A Site 4 The provider network Customer A Site 1 Community RED Customer A Site 3 Community RED Community YELLOW Customer B Site 3 Customer B Site 1 Community GREEN Community BLUE Customer A Site 2 Customer B Site 2 Community YELLOW (VPN Endpoint D_yellow) Community RED (VPN Endpoint D_red) Community BLUE (VPN Endpoint B_blue) Community GREEN (VPN Endpoint B_green) Customer A access point Customer B access point

5. VPN Concepts (cont’d) • Key differences between VPN and Public network services ? • At a minimum, each VPN’s traffic should not be seen/accessed by the other VPNs’ users ; • Additional encryption MAY BE used to protect the privacy of each VPN’s traffic • Ideally, each VPN should not be aware of the existence of the other VPNs ; • In practice, one’s traffic load may affect the other’s service quality, esp. in Best-Effort type of VPN service ; => Can be fixed by QoS-support in the Shared network infrastructure • Customers can freely choose their private network address space, e.g. VLAN-tag, private IP addresses, private MAC addresses • Need extra construct to handle possible collision of private network address space from different customers

6. Terminology CE Customer Edge device Customer A Site 4 PE Provider Edge device The provider network CE Customer A Site 1 P Provider core device Community RED CE PE PE Customer A Site 3 Community RED P PE CE P Community YELLOW Customer B Site 3 PE P Customer B Site 1 PE CE CE Community GREEN Community BLUE Customer A Site 2 Customer B Site 2 CE CE Community YELLOW (VPN Endpoint D_yellow) Community RED (VPN Endpoint D_red) Community BLUE (VPN Endpoint B_blue) Community GREEN (VPN Endpoint B_green)

7. VPN Concepts (cont’d) • A VPN consists of: • Two or More VPN endpoints connected by • A set of communication “tunnels” which pass through a public network • a VPN which comprises of 2 endpoints only => point-to-point service ; • > 2 endpoints within a VPN => multipoint service ;

8. CE-based Vs. Provider-Based VPNs Customer A Site 2 CE Customer A Site 1 Community RED CE PE PE Tunnel(s) terminated At CE’s => CE-based VPN Community RED P P PE P The provider network Customer B Site 1 PE CE Community BLUE Customer B Site 2 CE Tunnel(s) terminated At PE’s => Provider-based VPN Community BLUE

9. CE-based Vs. Provider-Based VPNs • Depending on the location of the endpoints of the tunnel, a VPN can be classified as: • CE-Based VPNs • The Tunnels are terminated at the CE’s • The VPN topology is configured and maintained by the CE’s • The provider network is VPN unaware ; it only provides a set of data pipes among the participating CE’s • Provider-Based VPNs • The Tunnels are terminated at the PE’s • The network provider is responsible for the configuration/ maintenance of the VPN => as a valued added service of a public network service provider • Some service providers also offer to manage customer’s CE-based VPN device => architecturally, it’s still a CE-based VPN • IETF Working Group in Provider Provisioned VPN covers both Provider-Based and CE-based VPNs

10. VPN Taxonomy • CE-based Vs. PE-based VPNs • Type of Customer payload carried by the VPN: • Layer 2 VPNs provide Layer 2 connectivity among VPN endpoints, e.g. carry customer Ethernet frames, Vs. • Layer 3 VPNs provide Layer 3 connectivity among VPN endpoints, e.g. carry customer IP packets ; • Type of the Provider Network • Conventional IP, IP/MPLS, ATM, Frame Relay, SONET/SDH, Telephone network • Type of Tunneling protocols/Technologies • IPSec Tunnel, L2TP, PPTP, MPLS-LSP, ATM-VP/VC, Frame Relay VC, SONET/SDH VT, PPP/Dial-up • Point-to-point, 2-site VPN Vs. Multiple-point (> 2 sites) VPN: • Address learning/ Routing info distribution may not be necessary for point-to-point service • E.g. for L2VPN: Idraft-Martini Vs. Idraft-Lasserre-VKompella,

11. Layer 2 Vs. Layer 3 VPNs: • Depending on the type of customer payload, a VPN can be classified as L2 or L3 VPNs: • Examples of L2VPN: • ATM LAN Emulation (LANE), • Ethernet over MPLS (Idraft-Martini, Idraft-KKompella, VPLS: Idraft-Lasserre-VKompella, IPLS: Idraft-Shah) • Examples of L3VPN: • RFC 1577: Classical IP over ATM • IPSec Tunneling mode • RFC 2547: BGP/MPLS-based VPNs • Idraft-Declercq: BGP/IPSec VPNs • Idraft-Knight: Virtual Router Based VPNs

12. VPN Taxonomy (cont’d) Layer 2 VPN Layer 3 VPN PPP, IPSec Tunnel mode Remote Half-bridges in Customer Premises CE-based PPTP CE device managed By Provider MPOA, L2TP RFC1577 Classical IP-over-ATM ATM LANE Idraft-Martini RFC2547bis: BGP/MPLS VPN Provider-based Idraft-KKompella Idraft-Knight: Virtual Router VPLS: Idraft-Lasserre-VKompella Idraft-Declercq: BGP/IPsec VPN IPLS: Idraft-Shah

13. Evolution of VPN technologies • 1st Generation: CE-based VPNs built on mesh of private lines leased from the Network Service Provider • 2nd Generation: CE-based VPNs built on Frame Relay/ATM VCs provided by public packet switched data networks • 3rd Generation: Service providers offer service to manage customer router used in CE-based VPNs • 4th Generation: Service Providers offer Provider-based L3 VPNs using IP/MPLS technologies per RFC 2547bis or the Virtual Router approach • 5th Generation: Service Providers offer Provider-based p2p L2 VPNs using IP/MPLS technologies per Idraft-Martini ; Multiple-point L2 VPNs standards, e.g. VPLS: Idraft-Lasserre-Kompella, etc still ongoing ; • In parallel, mostly CE-based VPN solutions, e.g. PPP, PPTP, L2TP, IPSec tunneling, are used for Remote User Access/Dial-up Applications

14. Motivation for IP/MPLS-based PPVPNs • Take advantage of the Ubiquitous IP network • Adopt the “Everything-over-IP” strategy to • consolidate different network traffic, e.g. Frame Relay, ATM, public Internet access, VPN, Voice, etc, into a SINGLE Network Infrastructure per Service Provider (Vs. traditional Multiple Overlay Networks per provider) • Network Operation Cost Savings : • Reuse the IP network infrastructure to provide new Value-Added Services, e.g. PPVPN service • No one is making $$ by providing generic ISP/ public Internet Access ; • In 2002, ISP Traffic Vol. grows 80%, Revenue: FLAT • ISPs need to develop new Revenue Streams • IP-based Network Control/Signaling protocols, e.g. Routing, Network Management, Tunnel-Setup, are extended to support such Value-Added Services

15. Motivation for IP/MPLS-based PPVPNs (cont’d) • Leverage the Capability of MPLS to provide Traffic Engineering/ Quality-of-Service Support based on the IP infrastructure • Can go beyond Best-Effort services to support Service Level Agreements (SLA) • SLA is a critical Requirement for most Value-added and Mission-critical ($$) network Services • Bridging the Service-feature gap between ATM and IP-based networks

16. Key Functional Blocks for IP-based PPVPNs • VPN endpoint identification and Auto-Discovery • Distribution of VPN end-host reachability Info within the VPN • Establishment of Mesh of Tunnels • Define New Payload Encapsulation Schemes for various Tunnelling protocols/technologies

17. Key Functional Blocks for IP-based PPVPNs (cont’d) • VPN Identification, VPN endpoint auto-discovery to maintain/resolve/distribute the binding between • a VPN, • it’s set of endpoints and • the IP addresses of the hosting PE’s based on extensions of either: • Domain Name Service (DNS) protocol or • Border Gateway Protocol (BGP) or • Label Distribution Protocol (LDP) in MPLS

18. Key Functional Blocks for IP-based PPVPNs (cont’d) • Distribution of VPN end-hosts reachability info: • L2 PPVPNs, e.g., Virtual Private LAN Service (VPLS) need to distribute/learn Customer VLAN/MAC addresses residing behind each VPN endpoint by either: • Generalizing the Self-learning Bridge concept to learn/bind Customer VLAN/MAC addresses with VPN endpoint (identified by Inner Tunnel Label) • Extensions of LDP to explicity distribute/ withdraw such binding Info • The learning/distribution task can be simplified if ONLY allows Routers (instead of endhosts or L2 Switches) to connect to the L2 PPVPN directly => IP-over-LAN-Service (IPLS) proposal, Idraft-Shah

19. Key Functional Blocks for IP-based PPVPNs (cont’d) Distribution of VPN end-hosts reachability info: • L3 PPVPNs need to distribute Customer (possibly private) IP network prefixes within each VPN • The Piggyback model: • Use only ONE instance of Routing Protocol to distribute Routing Info for ALL VPNs served by the Provider Networks e.g. In RFC2547bis, this done by extending BGP, so-called MP-BGP: • Use the notion of “Route Distinguisher” to resolve possible collision of Private IP network prefixes/addresses among different VPN • Use the notion of “Route Target” to extend the BGP-community concept to control to distribution of private network prefixes only to the members of the VPN • The Virtual Router model

20. VR-based L3 PPVPNs (Idraft-Knight) VPN-1 Sites VPN-1 Sites Provider Network VPN-1 Sites VR-1 VR-1 SPVR SPVR VR-2 VR-2 VPN-2 Sites VPN-2 Sites • Within every hosting PE, a logical copy of router, aka Virtual Router, is created for each VPN • Each VPN runs its own instance of routing protocol among its member VRs to distribute/exchange per VPN reachability Info • VRs within a VPN can be connected by • L2 data links or Other tunnels, e.g. IP-in-IP, MPLS • Multiple VRs can be connected to the Provider Network through the use of a single “service provider virtual router” SPVR

21. Key Functional Blocks for IP-based PPVPNs (cont’d) • Setting up the Mesh of Tunnels: • To enhance scalability, 2-level Nested Tunnels are used: • Full mesh of Outer Tunnels among all PEs within a Provider Network, one mesh per Type-of-Service • Full-mesh of per-VPN Inner Tunnels , aka VC-LSP, among endpoints of a VPN hosted by the PE’s • Aggregation of Inner-tunnels into Outer Tunnels using MPLS label stacking => P devices unaware of existence of Inner tunnels => improved scalability • Use RSVP-TE to setup Outer PE-to-PE tunnels • Use extensions of • BGP (e.g. RFC2547bis, Idraft-KKompella) or • LDP (e.g. Idraft-Martini) to setup per-VPN Inner Tunnels

22. Community YELLOW Different TOS Community YELLOW Different TOS Community GREEN (Bulk) Community BLUE (Bulk) Community GREEN (Bulk) Community GREEN (Bulk) Outer (Tunneling) Mesh Per Type of Service Community BLUE (Bulk) Outer Mesh Community Yellow Community Blue Connectivity Community Yellow Connectivity Community Green Connectivity 2-Level of Nested Tunnels

23. Key Functional Blocks for IP-based PPVPNs (cont’d) • Define New Encapsulation Schemes: • IETF PWE3 (Pseudo Wire Emulation Edge to Edge) Working Group to define encapsulation scheme for using: IP, L2TP and MPLS tunnels to carry payload • ATM • Frame-Relay • SONET/SDH • Other TDM frames e.g. Idraft-Martini covers: • Ethernet-over-MPLS • ATM-over-MPLS • Frame-Relay-over-MPLS • PPP-over-MPLS • HDLC-over-MPLS • For L3 PPVPN uses IP-over-MPLS encapsulation

24. Encapsulation of Customer Ethernet Frames in a L2 PPVPN Untagged or Tagged Ethernet Untagged or TaggedCustomer Ethernet over MPLS Customer Ethernet Frames over Ethernet Frames User Enet User Enet User Enet User Enet User Enet User Enet VLAN VLAN VLAN VLAN VLAN VLAN MPLS MPLS OR Enet Enet User Enet User Enet User Enet User Enet User Enet User Enet MPLS MPLS VC Label Enet Enet Tunnel Label Customer or Other Ethernet Access Network Provider Network Supporting L2PPVPN Customer or Other Ethernet Access Network MPLS-Domain Single Customer VLAN Domain

25. PE PE PE PE Example of a L2 PPVPN (VPLS) 802.1q VLANs 802.1q VLANs Provider Network Customer LAN switch Customer A L2 Network, e.g. Ethernet Customer B L2 Network, e.g. Ethernet MPLS LSP MESH 2 MPLS LABELS per frame: Tunnel Label = Outer Label for delivery to dest. PE VC Label = Inner Label to identify L2VPN end-pts ; Customer A L2 Network, e.g. Ethernet Customer B L2 Network, e.g. Ethernet Ethernet Frames with or without VLAN tags

26. PE PE PE PE Example of a L3 PPVPN (RFC2547bis) Provider Network Customer Edge Router Customer A Network Customer B Network MPLS LSP MESH 2 MPLS LABELS per frame: Tunnel Label = Outer Label for delivery to dest. PE VC Label = Inner Label to identify L2VPN end-pts ; Customer A Network Customer B Network Customer IP packets carrying possibly Private IP addresses

27. How to choose among various VPN Technologies ? • Depends on Customer Needs/ Requirements, e.g. : • Scalability in terms of • No. of VPN’s per Service Provider Network • No. of VPN’s per-Customers • No. of Sites (VPN-endpoints) per VPN • No. of End-hosts per VPN => Routing (L3) Vs. Bridging (L2) Solution • Reliability, Fault-Tolerance, QoS, SLA concerns • Diversity of existing Protocols within the Enterprise: • Pure IP shop => L3VPN Solution • Dominantly IP, but still need to support Legacy protocols, IPX, SNA, Appletalk, etc => L2VPN Solution

28. How to choose among various VPN Technologies ?(cont’d) • Level of Data Security/Privacy, e.g. • Explicit Network-based Payload Encryption, e.g. IPSec tunnels Vs. • Rely on generic VPN Traffic protection/isolation provided by the Service Provider ; supplement with application-layer encryption, e.g. HTTPS, based on Individual end-user need ; • In-house Staff Expertise • Degree/Willingness of Customer to Outsource/ Release Control on Critical In-house Infrastructure to the Service Provider • No single Dominant VPN Technology of Choice !!

29. Challenges/Future Directions for PPVPNs • Provide True End-to-End QoS guarantees: • Existing solutions, e.g. RFC2547bis, idraft-Martini, VPLS, only provide QoS for the PE-to-PE tunnel ; • Lack of Resource Reservation at Inner Tunnel level. • Not truly end-to-end QoS like ATM ; • Dest. PE lacks binding info between Inner and Outer Tunnels within the PPVPNs • Interoperability for PPVPNs spanning across multiple Service Providers • Need Policy control on MPLS-LSP setup, resource allocation, peering agreements, end-to-end SLAs • Scalability of proposed PPVPN architectures: • Hierarchical PPVPN architectures to tackle O(N2) VPN-Mesh problem • Support of Truly Single-Sided Provisioning: • When a new VPN site is added to a VPN with N existing endpoints, operator only need to do provisioning on the new site, the rest N sites will be notified to update their configuration automatically.

30. Challenges/Future Directions for PPVPNs(cont’d) • Reliability/Fault-tolerance support • Go beyond MPLS-based fast-re-routing of Outer Tunnel, and Robust Restart for LDP, need to protect/cover all of the PPVPN related state-info within the PEs • Interoperability between Customer-based control protocols with Provider ones: • Dynamic CE-PE routing: • Support of Dynamic Routing protocol within the Customer Network which include a PPVPN as part of it, e.g. Backdoor problem of CE-based OSPF • Dynamic Routing over CE-based IPSec Tunneling solution ; • Interoperability with non-MPLS-based, e.g. ATM, non-MPLS-capable IP networks ; • Use the IP/MPLS network to carry ATM traffic • Exchange of Topological Info between MPLS-cloud and the ATM-cloud • Further Generalization to other transport technologies: • GMPLS for setup maintaining port-based/color-based PPVPN over optical transport networks ;