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 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 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 (contd)

• Key differences between VPN and Public network
  services ?
• At a minimum, each VPNs traffic should not be
  seen/accessed by the other VPNs users
• Additional encryption MAY BE used to protect the
  privacy of each VPNs traffic
• Ideally, each VPN should not be aware of the
  existence of the other VPNs
• In practice, ones traffic load may affect the
  others service quality, esp. in Best-Effort type
  of VPN service
• gt 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 (contd)

• 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
• gt point-to-point service
• gt 2 endpoints within a VPN gt 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 CEs gt 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 PEs gt 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 CEs
• The VPN topology is configured and maintained by
  the CEs
• The provider network is VPN unaware it only
  provides a set of data pipes among the
  participating CEs
• Provider-Based VPNs
• The Tunnels are terminated at the PEs
• The network provider is responsible for the
  configuration/ maintenance of the VPN
• gt as a valued added service of a public network
  service provider
• Some service providers also offer to manage
  customers CE-based VPN device gt
  architecturally, its 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 (gt
  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 (contd)
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-Komp
  ella, 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 (contd)

• 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 (contd)

• VPN Identification, VPN endpoint auto-discovery
  to maintain/resolve/distribute the binding
  between
• a VPN,
• its set of endpoints and
• the IP addresses of the hosting PEs
• 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 (contd)

• 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
• gt IP-over-LAN-Service (IPLS) proposal,
  Idraft-Shah

19
Key Functional Blocks for IP-based PPVPNs (contd)

• 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 (contd)

• 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 PEs
• Aggregation of Inner-tunnels into Outer Tunnels
  using MPLS label stacking
• gt P devices unaware of existence of Inner
  tunnels
• gt 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
23
Key Functional Blocks for IP-based PPVPNs (contd)

• 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
Provider Network Supporting L2PPVPN
Customer or Other Ethernet Access Network
Customer or Other Ethernet Access Network
MPLS-Domain
Single Customer VLAN Domain
25
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
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 VPNs per Service Provider Network
• No. of VPNs per-Customers
• No. of Sites (VPN-endpoints) per VPN
• No. of End-hosts per VPN gt Routing (L3) Vs.
  Bridging (L2) Solution
• Reliability, Fault-Tolerance, QoS, SLA concerns
• Diversity of existing Protocols within the
  Enterprise
• Pure IP shop gt L3VPN Solution
• Dominantly IP, but still need to support Legacy
  protocols, IPX, SNA, Appletalk, etc gt L2VPN
  Solution

28
How to choose among various VPN Technologies
?(contd)

• 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(contd)

• 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