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 public Network 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 B Site 1 Community BLUE Community YELLOW (VPN Endpoint D_yellow) Community RED (VPN Endpoint D_red) Customer A Site 2 Community BLUE (VPN Endpoint B_blue) Customer B Site 2 Community GREEN (VPN Endpoint B_green) Customer B Site 3 Community GREEN Customer A Site 3 Community YELLOW Customer A Site 1 Community RED Customer A Site 4 Community RED Customer A access point Customer B access point The provider network

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 Customer B Site 1 Community BLUE Community YELLOW (VPN Endpoint D_yellow) Community RED (VPN Endpoint D_red) Customer A Site 2 Community BLUE (VPN Endpoint B_blue) Customer B Site 2 Community GREEN (VPN Endpoint B_green) Customer B Site 3 Community GREEN Customer A Site 3 Community YELLOW Customer A Site 1 Community RED Customer A Site 4 Community RED Customer Edge device The provider network PE P P P CE PE P Provider Edge device Provider core device

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 B Site 1 Community BLUE Customer A Site 2 Community BLUE Customer B Site 2 Customer A Site 1 Community RED Community RED The provider network PE P P P CE Tunnel(s) terminated At CE’s => CE-based VPN Tunnel(s) terminated At PE’s => Provider-based VPN

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) CE-based Provider-based Layer 2 VPNLayer 3 VPN CE device managed By Provider RFC2547bis: BGP/MPLS VPN Idraft-Knight: Virtual Router Idraft-Martini Idraft-KKompella IPLS: Idraft-Shah VPLS: Idraft-Lasserre-VKompella ATM LANE PPP, IPSec Tunnel mode MPOA, L2TP RFC1577 Classical IP-over-ATM PPTP Remote Half-bridges in Customer Premises Idraft-Declercq: BGP/IPsec VPN

13. Evolution of VPN technologies 1 st Generation: CE-based VPNs built on mesh of private lines leased from the Network Service Provider 2 nd Generation: CE-based VPNs built on Frame Relay/ATM VCs provided by public packet switched data networks 3 rd Generation: Service providers offer service to manage customer router used in CE-based VPNs 4 th Generation: Service Providers offer Provider-based L3 VPNs using IP/MPLS technologies per RFC 2547bis or the Virtual Router approach 5 th 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) Provider Network VR-1 VR-2 SPVR VR-1 VR-2 SPVR VPN-1 Sites VPN-2 Sites VPN-2 Sites VPN-1 Sites VPN-1 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. 2-Level of Nested Tunnels Community BLUE (Bulk) Community BLUE (Bulk) Community YELLOW Different TOS Community YELLOW Different TOS Community GREEN (Bulk) Community GREEN (Bulk) Community GREEN (Bulk) Outer (Tunneling) Mesh Per Type of Service Community Blue Connectivity Outer Mesh Community Yellow Community Yellow Connectivity Community Green Connectivity

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 Tagged Customer Ethernet over MPLS Customer Ethernet Frames over Ethernet Frames User Enet VLAN User Enet VLAN User Enet VLAN MPLS-Domain User Enet VLAN User Enet VLAN User Enet User Enet User Enet User Enet User Enet User Enet User Enet OR MPLS Enet Provider Network Supporting L2PPVPN Customer or Other Ethernet Access Network Customer or Other Ethernet Access Network VC Label Tunnel Label Enet Single Customer VLAN Domain

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

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

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(N 2 ) 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 ;