Provider Provisioned Virtual Private Networks

Wing C. LauPerformance Analysis Department

Bell Labs, Lucent TechnologiesHolmdel, New Jersey

Dec. 6. 2002

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

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

VPN as a Community of Interest

Customer BSite 1

Community BLUE

CommunityYELLOW(VPN Endpoint D_yellow)

CommunityRED(VPN Endpoint D_red)

Customer ASite 2

CommunityBLUE(VPN EndpointB_blue)

Customer B

Site 2

CommunityGREEN(VPN EndpointB_green)

Customer BSite 3

CommunityGREEN

Customer ASite 3

Community YELLOW

Customer ASite 1

Community RED

Customer A

Site 4

Community RED

Customer A access point

Customer B access point

The provider network

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

Terminology

Customer BSite 1

Community BLUE

CommunityYELLOW(VPN Endpoint D_yellow)

CommunityRED(VPN Endpoint D_red)

Customer ASite 2

CommunityBLUE(VPN EndpointB_blue)

Customer B

Site 2

CommunityGREEN(VPN EndpointB_green)

Customer BSite 3

CommunityGREEN

Customer ASite 3

Community YELLOW

Customer ASite 1

Community RED

Customer A

Site 4

Community RED

Customer Edge device

The provider network

PE PE

PE

PEPE

PP

P

CE

CE

CE

CECE

CE

CE

CE

PE

P

Provider Edge device

Provider core device

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 ;

CE-based Vs. Provider-Based VPNs

Customer BSite 1

Community BLUE

Customer ASite 2

CommunityBLUE

Customer B

Site 2

Customer ASite 1

Community RED

Community RED

The provider network

PEPE

PEPE

PP

P

CE

CE

CE

CE

Tunnel(s) terminatedAt CE’s => CE-based VPN

Tunnel(s) terminatedAt PE’s => Provider-based VPN

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

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,

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

VPN Taxonomy (cont’d)

CE-based

Provider-based

Layer 2 VPN Layer 3 VPN

CE device managedBy 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, L2TPRFC1577 Classical IP-over-ATM

PPTP Remote Half-bridges

in Customer Premises

Idraft-Declercq: BGP/IPsec VPN

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

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

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

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

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

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

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

VR-based L3 PPVPNs (Idraft-Knight)

Provider NetworkVR-1

VR-2SPVR

VR-1

VR-2

SPVR

VPN-1Sites

VPN-2Sites

VPN-2Sites

VPN-1Sites

VPN-1Sites

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

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

2-Level of Nested Tunnels

Community BLUE(Bulk)

Community BLUE(Bulk)

CommunityYELLOW

Different TOS

CommunityYELLOW

Different TOS

CommunityGREEN(Bulk)

CommunityGREEN(Bulk)

CommunityGREEN(Bulk)

Outer (Tunneling) Mesh Per Type of Service

Community Blue Connectivity

Outer Mesh Community Yellow

Community Yellow Connectivity

Community Green Connectivity

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

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

Untagged or Tagged Ethernet Untagged or TaggedCustomer Ethernet over MPLS Customer Ethernet Frames over Ethernet Frames

UserEnet

VLAN

UserEnet

VLAN

UserEnet

VLAN

MPLS-Domain

UserEnet

VLAN

UserEnet

VLANVLAN

UserEnet

UserEnet

UserEnet

UserEnet

UserEnet

UserEnet

UserEnet

ORMPLS MPLS

MPLSMPLS

Enet

Enet Enet

Provider NetworkSupporting L2PPVPN

Customer or Other Ethernet Access Network

Customer or OtherEthernet Access Network

VC Label

Tunnel Label

Enet

Single Customer VLAN Domain

Customer A L2 Network, e.g. Ethernet

Customer A L2 Network, e.g. Ethernet

PEPE

PE

Customer BL2 Network, e.g. Ethernet

Customer BL2 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

Customer A Network

Customer A Network

PEPE

PE

Customer BNetwork

Customer BNetwork

PE

CustomerIP 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 ANetwork

Customer ANetwork

Customer B Network

Customer B Network

Customer Edge Router

Provider Network

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

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 !!

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.

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 ;