PWE + VPLS

Yaakov (J) Stein June 2006

Chief Scientist
RAD Data Communications
 Contents
 Interworking
 VPNs
 PWs
 TDM PWs
 Ethernet PWs
 Other PWs
 PWE control protocol
 L2VPNs
 LDP vs. BGP
 Provisioning VPLS
 Generalizations
 L3VPNs
Y(J)S PWE-VPLS Slide 2
Interworking

Y(J)S PWE-VPLS Slide 3

 Tunneling - interworking
mating different network protocols is called interworking

protocol converter goes by various names :

– interworking function (IWF)
– gateway (GW)

simplest case is network interworking

easily provided by tunneling

infrastructure
native network native
network network

Y(J)S PWE-VPLS Slide 4

 Tunneling - provider networks
users traditionally have private networks
they interconnect their sites using leased lines
– no contention with outside users
– guaranteed privacy
– complex and costly maintenance

customer leased line customer

network network

service providers (SPs) can provide virtual private networks

provided by (once again by) tunneling edge-to-edge

Y(J)S PWE-VPLS Slide 5

 Basic emulation by tunneling

customer customer
network physical link network

end to end
edge to edge

provider
network
customer customer
network network

emulated link

provider network edge provider network edge

Y(J)S PWE-VPLS Slide 6
 Interworking motivation
there are many different types of network traffic (voice, video, file-xfer, etc)
all types fall into one of three classes:
– Real-time constant bit-rate
– Real-time variable bit-rate
– Non-real-time (packet)

there are many different types of network (IP,ATM,FR,Eth,etc)

most were originally designed for a specific type of traffic

providers with one type of network infrastructure want to fully exploit it

they desire to carry all types of network traffic

Y(J)S PWE-VPLS Slide 7

 Service Interworking
Service interworking:
direct conversion between 2 native service formats

Native service Native

interworking
Service function Service
A B

Y(J)S PWE-VPLS Slide 8

VPNs

Y(J)S PWE-VPLS Slide 9

 Conventional Ethernet-IP model

Ethernet Ethernet
IP

conventional model:
 Ethernet is a LAN technology
– last 100m
– 10s of hosts
 IP is a WAN technology
– data transported in native IP
– different L2 technologies for last segment
modern Ethernet wants to be more

Y(J)S PWE-VPLS Slide 10

 Virtual Private Networks

service
provider
network

SPs want to offer customers site interconnect service

since the private networks are interconnected over

a public PSN
this results in a Virtual Private Network
unlike the traditional WAN architecture
the entire native packet/frame must be tunneled
Example: Transparent LAN Service (TLS)

Y(J)S PWE-VPLS Slide 11

 Basic (L2,L3)VPN model

customer physical link customer

network network

emulated link

Customer Provider Provider Customer

customer Edge Edge provider Edge Edge customer
network network network
(CE) (PE) (PE) (CE)

AC = Attachment Circuit AC = Attachment Circuit

provider network may be L3 (e.g. IP) or L2 (e.g. Ethernet)

Y(J)S PWE-VPLS Slide 12
 (L2,L3)VPN in more detail

C C C
C CE
CE
C C

customer 1 network P P P customer 2 network

PE PE
P P

C C C
C provider network CE
CE
C C
Key
C Customer router/switch
customer 2 network CE Customer Edge router/switch customer 1 network
P Provider router/switch
PE Provider Edge router/switch Y(J)S PWE-VPLS Slide 13
 L3 encapsulation
for simplicity, let’s think of an IP network :
the traditional architecture uses the following packet formats:

WAN
Eth hdr IP hdr payload Eth FCS Eth hdr IP hdr payload Eth FCS

WAN L2 hdr IP hdr payload

a VPN model (Ether-IP) uses the following packet formats:

WAN
Eth hdr IP hdr payload Eth FCS Eth hdr IP hdr payload Eth FCS

WAN L2 hdr IP hdr Eth hdr IP hdr payload Eth FCS*

Y(J)S PWE-VPLS Slide 14
 VPN Challenges
192.115.243.19 192.115.243.79

SP
network

192.115.243.19

Security
Private IP addresses
Multiple higher-layer protocols
SP resource requirements
Complex provider - customer relationship
Y(J)S PWE-VPLS Slide 15
 MPLS solves IP address problem
192.115.243.19

2 1
MPLS
network
1 MPLS label
192.115.243.19 IP header
payload

assume customers 1 and 2 use overlapping IP addresses

then C-routers have inconsistent tables
ingress PE-router pushes a label
P-routers see only MPLS label
P-routers don’t see IP addresses - no ambiguity
P-routers see only the MPLS label - not LAN IP addresses
PE routers know how to map CE LANs
Y(J)S PWE-VPLS Slide 16
 VPN types
 Legacy
– proprietary leased-line (not virtual)
– Frame Relay over E1/T1
– ATM over E1 or multiple-E1

 Pure IP
– IPSec tunnel
– L2TP tunnel

 MPLS L3VPN
– RFC4364 (ex 2547bis)

 MPLS L2VPN
– VPWS / VPLS
Y(J)S PWE-VPLS Slide 17
 Pseudowires

Pseudowire (PW): A mechanism that emulates the

essential attributes of a native service while transporting
over a packet switched network (PSN)

Y(J)S PWE-VPLS Slide 18

 Pseudowires

Packet Switched Network (PSN)

– network that forwards packets
– IPv4, IPv6, MPLS, Ethernet (although IETF does not touch)

a pseudowire (PW) is a mechanism to tunnel through a PSN

PWs are bidirectional (unlike MPLS LSPs)

PW architecture is an extension of VPN architecture

Y(J)S PWE-VPLS Slide 19

 Pseudowire Emulation
Edge to Edge

Customer
Edge
provider’s
(CE) PSN Customer
Edge
Customer
Edge Provider Provider (CE)
Edge Edge
(CE)
(PE) (PE) Customer
Customer Edge
native
Edge service
native PseudoWires (CE)
service
(CE) (PWs)
Y(J)S PWE-VPLS Slide 20
 Provider Network Architecture
provider network is composed of:
• Provider routers (P routers)
• Provider edge routers (PE routers)

P P
router router
PE PE
P
router native
native router router service
service
A tunnel P
may contain router
many PWs

Y(J)S PWE-VPLS Slide 21

 IETF PWE3 WG

In the Internet Area of the Internet Engineering Task Force

Native (layer 1,2) services :
 ATM (port mode, cell mode, AAL5-specific modes)
 FR
 Ethernet (DIX, 802.3, VLAN)
 TDM (SONET/SDH, E1, T1, E3, T3)
 …

Supported Packet Switched Networks (PSNs)

 IPv4
 IPv6
 MPLS
 L2TPv3
 (not Ethernet …)

Y(J)S PWE-VPLS Slide 22

 PWE3 WG Charter
 Edge-to-edge emulation and maintenance of PWs
– tunnel creation and placement out of scope
 Network interworking, not service interworking
 Must not exert controls on underlying PSN
– but diffserv, RSVP-TE can be used

 Use RTP when necessary

– for real-time functions, clock recovery

 Realize that emulation will not be perfect

– need applicability statement for each native service

 WG will produce the following documents

– requirements (RFC 3916), architecture (RFC 3985) documents
– control protocol definition
– service specific encapsulation documents for each native service

Y(J)S PWE-VPLS Slide 23

 MPLS
Much of the PWE work is focused on MPLS
 Emulated services have QoS and TE requirements
– IP is basically a “best effort” service
– diffserv and RSVP extensions not prevalent
– MPLS can provide TE guarantees
– RSVP-TE (CR-LDP) allows TE signaling
 IP provides no standard “bundle” multiplexing method
– UDP/TCP ports provide application multiplexing
– RTP uses ports in a nonstandard way
– L2TP includes a multiplexing mechanism
– MPLS label stack provides natural multiplexing method
– Using “inner labels” provides two layers of switching (like ATM VP/VC)

MPLS-f inner label outer label(s)

Dictionary: ITU-T interworking label transport label(s)
IETF PW label tunnel label(s) Y(J)S PWE-VPLS Slide 24
 Simple MPLS solution
CE
CE
ACs ACs
CE PE P P PE CE

CE CE

each customer network mapped to pair of (unidirectional) LSPs

supports various AC technologies
each native packet/frame encapsulated with MPLS label

scaling problem:
 requires large number of LSPs
 P-routers need to be aware of customer networks

Y(J)S PWE-VPLS Slide 25

 (Martini) Pseudowires

CE CE
ACs transport tunnel ACs
CE PE PE CE

CE CE
PWs are bidirectional

MPLS (outer) label

transport MPLS tunnel set up between PEs
PW (inner) label
multiple PWs may be set up inside tunnel
payload
Native packet/frame encapsulated with 2 labels

P-routers are unaware of individual customer networks

Y(J)S PWE-VPLS Slide 26

 PWE packet format

PSN / multiplexing

optional RTP header

optional control word (CW)

higher layers

payload

Y(J)S PWE-VPLS Slide 27

 Example formats
MPLS PSN

tunnel PW control
Payload
label(s) label word

L2TPv3 PSN

IP header (5*4 B)

session ID (4 B)

optional cookie (4 or 8 B)
control word (4 B)

payload
Y(J)S PWE-VPLS Slide 28
 PWE Control Word
0000 flags FRG Length Sequence Number
0000
– Identifies packet as PW (not IP)
– used to ensure ECMP mechanisms don’t interfere with proper functioning
– 0001 for PWE OAM (VCCV)
Flags (4 b)
– not all encapsulation define
– used to transport native service fault indications
FRG
– may be used to indicate payload fragmentation
 00 = unfragmented 01 = 1st fragment
 10 = last fragment 11 = intermediate fragment
Length (6 b)
– used when packet may be padded by L2
Sequence Number (16 b)
– used to detect packet loss / misordering
Y(J)S PWE-VPLS Slide 29
 Other Standards Bodies
 ITU-T SG13
– Y.1411, Y.1412, Y.1413, Y.1414, Y.1415, Y.1452,
Y.1453, X.84
 ITU-T SG15
– G.769, G.8261
 MFA Forum (MPLS – Frame Relay – ATM)
– TDM over MPLS using AAL1 IA 4.0
– I.366.2 over MPLS IA 5.0
– af-aic-0178

 MEF (Metro Ethernet Forum)

– MEF 8.0.0

Y(J)S PWE-VPLS Slide 30

TDM PWs

Y(J)S PWE-VPLS Slide 31

 TDMoIP Protocol Processing
TDM IP Packets IP Packets
TDM

PSN

Steps in TDMoIP
 The synchronous bit stream is segmented

 The TDM segments are adapted

 TDMoIP control word is prepended

 PSN (IP/MPLS) headers are prepended (encapsulation)

 Packets are transported over PSN to destination

 PSN headers are utilized and stripped

 Control word is checked, utilized and stripped

 TDM stream is reconstituted (using adaptation) and played out

Y(J)S PWE-VPLS Slide 32

 TDM Structure
handling of TDM depends on its structure
unstructured TDM (TDM = arbitrary stream of bits)
…
structured TDM
framed (8000 frames per second)
S S S
Y Y Y
N N N
C C C
channelized (single byte timeslots)

SYNC TS1 TS2 TS3 … signaling

bits
… TSn
(1 byte)
multiframed

frame frame frame … frame

multiframe Y(J)S PWE-VPLS Slide 33

 TDM transport types

Structure-agnostic transport (SAToP – RFC4553)

• for unstructured TDM
• even if there is structure, we ignore it
• simplest way of making payload
• OK if network is well-engineered

Structure-aware transport (TDMoIP, CESoPSN)

• take TDM structure into account
• must decide which level of structure (frame, multiframe, …)
• can overcome PSN impairments (PDV, packet loss, etc)

Y(J)S PWE-VPLS Slide 34

 Structure aware encapsulations

Structure-locked encapsulation (CESoPSN)

headers TDM structure TDM structure TDM structure TDM structure

Structure-indicated encapsulation (TDMoIP – AAL1 mode)

headers AAL1 subframe AAL1 subframe AAL1 subframe AAL1 subframe

Structure-reassembled encapsulation (TDMoIP – AAL2 mode)

headers AAL2 minicell AAL2 minicell AAL2 minicell AAL2 minicell

Y(J)S PWE-VPLS Slide 35

Ethernet PWs

Y(J)S PWE-VPLS Slide 36

 Ethernet limitations
Ethernet LAN is the most popular LAN
but Ethernet can not be made into a WAN

 Ethernet is limited in distance between stations

 Ethernet is limited in number of stations on segment
 Ethernet is inefficient in finding destination address
 Ethernet only prunes network topology, does not route

so the architecture that has emerged is Ethernet private networks

connected by public networks of other types (e.g. IP)

LAN LAN

WAN

Y(J)S PWE-VPLS Slide 37

 Traditional WAN architecture
this model is sensible when traffic contains a given higher layer
Ethernet header is removed at ingress and a new header added at egress

this model is not transparent Ethernet LAN interconnect

 Ethernet LANs with multiple higher layer packet types
(e.g. IPv4, IPv6, IPX, SNA, CLNP, etc.) can’t be interconnected
 raw L2 Ethernet frames can not be sent

the Ethernet layer is terminated at WAN ingress

the traffic is no longer Ethernet at all

Ethernet Ethernet

WAN

not Ethernet
Y(J)S PWE-VPLS Slide 38
 Tunneling Ethernet frames

users with multiple sites want to connect their LANs

so that all locations appear to be on the same LAN
this requires tunneling of all Ethernet L2 frames (not only IP)
between one LAN and another
the entire Ethernet frame needs to be preserved
(except perhaps the FCS which can be regenerated at egress)

Ethernet Ethernet
X

Ethernet inside X

Y(J)S PWE-VPLS Slide 39

 Ethernet over
HDLC/FR/ATM/SONET/SDH/PDH

Ethernet frames can be carried over various WANs

HDLC: not standardized, Cisco-HDLC

FR: RFC2427 / STD0055 (ex 1490)

ATM: RFC2684 / (ex 1483), LANE

SONET/SDH/PDH: PoS (RFC 2615 ex RFC1619),

LAPS (X.85/X.86), GFP (G.7041 )

entire Ethernet frame (or IP packet) is used as payload

Y(J)S PWE-VPLS Slide 40
 Ethernet PW (RFC 4448)
can transport tagged or untagged Ethernet frames
if tagged encapsulation can be “raw mode” or “tagged mode”
tagged mode processes SP tags

control word is optional

even if control word is used, sequence number if optional

standard mode – FCS is stripped and regenerated

FCS retention mode (not in 4448) allows retaining FCS

Y(J)S PWE-VPLS Slide 41

 Ethernet Pseudowire packet (MPLS)

tunnel PW control
Ethernet Frame
label label word

Ethernet Frame usually has FCS stripped

SP tag may also be stripped

optional control word

generation and processing of sequence number is optional

0000 reserved Sequence Number (16b)

Y(J)S PWE-VPLS Slide 42

Other PWs

Y(J)S PWE-VPLS Slide 43

 What other PW clients are there?

ATM (4 different modes)

frame relay
SONET/SDH
HDLC / PPP
Fiber channel
X.25
Generic
????

Y(J)S PWE-VPLS Slide 44

PWE control protocol

Y(J)S PWE-VPLS Slide 45

 PWE (Martini) control protocol
 PWE control protocol (RFC 4447) used to set up / configure PWs

 used only by PW end-points (PEs in standard model)

intermediate nodes (e.g. P routers) don’t participate or see

P P
PE PE
P P P
 based on LDP
– targeted LDP is used to communicate with opposite end-point
– 2 new FECs for PWs
– new TLVs added for PW-specific functionality
– associates two labels with PW

LDP will be discussed later

Y(J)S PWE-VPLS Slide 46
 PWE control
a PW is a bidirectional entity (two LSPs in opposite directions)
a PW connects two forwarders
2 different LDP TLVs can be used
– PWid FEC (128)
– Generalized ID FEC (129)

FEC 128
– both end-points of PW must be provisioned with a unique (32b) value
– each PW end-point independently initiates LSP set up
– LSPs bound together into a single PW

FEC 129
– used when autodiscovering PW end-points
– each end-point has attachment identifier (AI) …

Y(J)S PWE-VPLS Slide 47

 Generalized ID
for each forwarder we have a PE-unique Attachment Identifier (AI)
<PE, AI> must be globally unique
frequently useful to group a set of forwarders into a attachment group
where PWs may only be set up among members of a group
then Attachment Identifier (AI) consists of
– Attachment Group Identifier (AGI) (which is basically a VPN-id)
– Attachment Individual Identifier (AII)
the LSPs making up the (two directions of the) PW are
< PE1, (AGI, AII1), PE2, (AGI, AII2) > and
< PE2, (AGI, AII2), PE1, (AGI, AII1) >

we also need to define

– Source Attachment Identifier (SAI = AGI+SAII)
– Target Attachment Identifier (TAI = AGI+TAII)
receiving PE can map TAI uniquely to AC

Y(J)S PWE-VPLS Slide 48

PWE OAM

Y(J)S PWE-VPLS Slide 49

 VCCV

VC (old name for PW) connectivity verification

runs inside PW (same PW label) as an associated channel
differentiated by control word format (PWACH – RFC 4385)

0001 VER RES=0 Channel Type (0x21-IPv4 0x57-IPv6)

inside VCCV several different OAM mechanisms may be used:
– ICMP
– LSP ping
– BFD
– ???

Y(J)S PWE-VPLS Slide 50

Multisegment PW (MS-PW)

Y(J)S PWE-VPLS Slide 51

 Multiple PSN domains

P P P P
T-PE S-PE T-PE
P P P P P P

Single-Segment PW (SS-PW) requires PEs to see each other

when multiple PSN domains this may not be the case
Terminal-PEs interconnect via stitching-PE
PW label becomes a true MPLS label (switching, swapping)
when more than one S-PE
need to ensure that the 2 LSPs traverse the same one

Y(J)S PWE-VPLS Slide 52

L2VPNs

Y(J)S PWE-VPLS Slide 53

 VPWS

AC PE AC
CE PE CE

provider
network

Virtual Private Wire Service is a L2 point-to-point service

it emulates a wire supporting the Ethernet physical layer

set up MPLS tunnel between PEs

set up Ethernet PW inside tunnel

CEs appear to be connected by a single L2 circuit

(can also make VPWS for ATM, FR, etc.)

Y(J)S PWE-VPLS Slide 54

 VPLS
AC
PE CE

AC
CE PE

for clarity only one VPN is shown

PE AC CE

VPLS emulates a LAN over an MPLS network

set up MPLS tunnel between every pair of PEs (full mesh)
set up Ethernet PW inside tunnels, for each VPN instance
CEs appear to be connected by a single LAN
PE must know where to send Ethernet frames …
but this is what an Ethernet bridge does
Y(J)S PWE-VPLS Slide 55
 VPLS

V B CE

CE B V

V B CE

a VPLS-enabled PE has, in addition to its MPLS functions:

 VPLS code module (IETF drafts)
 Bridging module (standard IEEE 802.1D learning bridge)

SP network (inside rectangle) looks like a single Ethernet bridge!

Note: if CE is a router, then PE only sees 1 MAC per customer location
Y(J)S PWE-VPLS Slide 56
 VPLS bridge
PE maintains a separate bridging module for each VPN (VPLS instance)

VPLS bridging module must perform:

 MAC learning
 MAC aging
 flooding of unknown MAC frames
 replication (for unknown/multicast/broadcast frames)

unlike true bridge, Spanning Tree Protocol is not used

 limited traffic engineering capabilities
 scalability limitations
 slow convergence

forwarding loops are avoided by split horizon

 PE never forwards packet from MPLS network to another PE
 not a limitation since there is a full mesh of PWs
so always send directly to the right PE
Y(J)S PWE-VPLS Slide 57
 Bridge - both ways
CE

CE
V B CE

CE
CE B V

CE

V B CE

CE
a packet from a CE:
may be sent back to a CE
may be sent to a PE via a PW
a packet from a PE:
is only sent to a CE (split horizon)
is sent to a particular CE based on 802.1D bridging
Y(J)S PWE-VPLS Slide 58
 VPLS code module

VPLS signaling
establish PWs between PEs per VPLS

VPLS autodiscovery
locates PEs participating in VPLS instance

obtain frame from bridge

encapsulate Ethernet frames
and inject packet into PW

retrieve packet from PW

removes PW encapsulation
and forward Ethernet frame to bridge

Y(J)S PWE-VPLS Slide 59

 L2VPN vs. L3VPN

PE CE

CE PE
? PE CE

in L2VPN CEs appear to be connected by single L2 network

PEs are transparent to L3 routing protocols
CEs are routing peers

in L3VPN CE routers appear to be connected by a single L3 network

CE is routing peer of PE, not remote CE
PE maintains routing table for each VPN

Y(J)S PWE-VPLS Slide 60

 IPLS (IP-only LAN Service)
mechanisms may be simplified if Ethernet frames carry only IP traffic
enables upgrade of IP routers to support VPLS-like services
in this case CE devices are routers, not switches
frames are still forwarded based on MAC DA (not L3VPN)
but MAC forwarding tables updated via PW signaling, not 802.1D
PE snoops IP and ARP frames to discover CEs connected to it
creates (AC,VPN-ID,IP-addr,MAC-addr) entry
creates PWs to all PEs participating in VPN-ID
sends entries to these PEs
Address Resolution Protocol (ARP) messages are proxied
rather than being carried transparently
PE searches entries it has received
can support different AC types (Ethernet and FR)
ARP Mediation ensures proper mapping

Y(J)S PWE-VPLS Slide 61

LDP vs. BGP

Y(J)S PWE-VPLS Slide 62

 LDP vs. BGP
both use TCP for reliable transport (LDP uses UDP for hellos)
both are hard-state protocols
both use TLV format for parameters

BGP LDP
multiprotocol (IPv4, IPv6, IPX, MPLS) MPLS only
highly complex protocol simpler protocol
provides routing / label distribution only label distribution
built-in autodiscovery mechanism extendable for autodiscovery

Y(J)S PWE-VPLS Slide 63

 BGP
header (19B)

marker length type data

(16B) (2B) (1B)
(variable)

marker can be used for authentication (TCP MD5 signature)

length is total BGP PDU length, including header

type
– OPEN (for session initialization)
– UPDATE (add, change and withdraw routes)
– NOTIFICATION (return error messages, terminate session)
– KEEPALIVE (heartbeat)
KEEPALIVE packet consists of 19B header only

Y(J)S PWE-VPLS Slide 64

 BGP state machine

 idle – no session (awaiting session initialization)

 connect – attempting to connect to peer
 active – started TCP 3-way handshake (router busy)
 open sent – have sent OPEN message
 open confirm – after receiving TCP SYN for OPEN message
 established – BGP session up and running

Y(J)S PWE-VPLS Slide 65

 BGP OPEN

version my AS hold time BGP-ID op len opt parameters

(1B) (2B) (2B) (2B) (1B) (variable)

version (3 or 4)
my AS – identifier of autonomous system
hold time – max time (sec) between receipt of messages
BGP ID – sender’s BGP identifier
op len – length (bytes) of optional parameters
opt parameters - TLVs

Y(J)S PWE-VPLS Slide 66

 BGP UPDATE
WR len withdrawn PA len path
attributes NLRI
routes
(2B) (2B) (var) (var)
(var)

Withdrawn Routes – list of routes no longer to be used (NLRI format- see below)

Path Attributes – route specific information (see next page)

Network Layer Reachability Information – (classless) routing information

len prefix
(1B) (variable)

the NLRI is a list of address-prefixes

each prefix must be masked from the left to the length specified

Y(J)S PWE-VPLS Slide 67

 BGP UPDATE - Path Attributes
flags type code
(1B) (1B)

flags
O – optional/well-known bit
if 1 must be recognized by all BGP implementations
if W=1 and unrecognized attribute, BGP sends notification and session closed

T – transitive/nontransitive bit
if 1 and attribute unrecognized it is passed along, else silently ignored
well-known attributes are always transitive

C – complete/partial bit (for optional transitive attributes only)

L – attribute length bit (=0 attribute length is 1B, =1 length is 2B)

type code
ORIGIN, AS_PATH, NEXT_HOP, MED, LOCAL_PREF,
AGGREGATOR, COMMUNITY, ORIGINATOR_ID…
Y(J)S PWE-VPLS Slide 68
 BGP NOTIFICATON

error error data

code subcode (var)
(1B) (2B)

all notification messages cause BGP session to close

error codes include:
– message header error
– open message error
– update message error
– hold timer expired
– state machine error
– other fatal error

Y(J)S PWE-VPLS Slide 69

 LDP
header (10B)

version length LDP-ID messages

(2B) (2B) (6B) (variable)

version – presently 1
length - PDU length, excluding version and length fields
LDP-ID – identifies label space of sending LDP peer
– LSR-ID(4B) globally unique LSR ID
– label space ID (2B) for per-port label spaces
(zero for per-platform label spaces)
messages – zero or more TLVs (see next page)

Y(J)S PWE-VPLS Slide 70

 LDP messages

mandatory optional
type length message-ID parameters parameters
(2B) (2B) (4B) (variable) (variable)

type U message code

U – unknown message bit
if message type unknown to receiver
U=0 – receiver returns notification to sender
U=1 – receiver silently ignores
length - message length, excluding type and length fields
Message-ID – unique ID for message (for matching with returned notification)
if there are mandatory parameters, they most appear in a specific order
optional parameters may appear in any order

Y(J)S PWE-VPLS Slide 71

 LDP message types
Hello (UDP, for discovery)
Initialization (specifies LDP version, label space range, parameters)
KeepAlive (heart beat)
Notification (error, e.g.unsupported version, unknown/malformed msg, timer expired)
Address (LSR advertises its interface IP address(es) to peers)
Address Withdraw (LSR revokes previously advertised interface IP address)
Label Mapping (downstream LSR advertisement of a label mapping for a FEC )
Label Withdraw (downstream LSR informing that binding is revoked)
Label Request (upstream LSR request for binding in downstream-on-demand mode)
Label Release (upstream LSR informing that binding no longer needed)
Label Abort Request (upstream LSR asks to revoke request before satisfied)

Y(J)S PWE-VPLS Slide 72

 LDP state machine
 LSR periodically transmits hello UDP messages
– multicast to “all routers on subnet” group
– targeted to preconfigured IP address
 LSRs listen on this UDP port for hello messages
 when LSR receives hello from another LSR
– it opens a TCP connection to that other LSR
or (for extended discovery)
– it unicast transmits a hello back to the other LSR
 LSR with higher ID sends session initialization message
 other LSR LDP accepts (sends keepalive) or rejects
 informative or keepalive messages sent

3.2
Y(J)S PWE-VPLS Slide 73
Provisioning VPLS

Y(J)S PWE-VPLS Slide 74

 Provisioning
customers may want their SP to take an active role
in managing their networks

Provider Provisioned VPN (PPVPN) refers to VPN

for which SP participates in management and provisioning

by provisioning we mean (at least) :

 setting up the ACs (often manual configuration)
 assigning global VPN-ID to VPN instances
 discovery of all PEs that participate in a VPN instance
 associating AC with VPN at PE
 providing PEs with information needed to set up tunnels
 configuring tunnels with necessary characteristics

Y(J)S PWE-VPLS Slide 75

 Autodiscovery
we have assumed that each PE knows
which PEs participate in particular VPN instance

manual configuration is problematic logistically

autodiscovery refers to automatically finding all PEs in a given VPN

each PE "discovers" other PEs by means of some protocol

 BGP
 RADIUS (Remote Authentication Dial In User Service)
CE = RADIUS users, PEs = Network Access Servers (NAS)
PE can authenticate CEs and find other PEs
 targeted LDP (“Stokes draft”, “Stein-Delord draft” - expired)
advertise FEC in LDP
new TLV in label mapping message contains VPN-id, P or PE, capabilities

Y(J)S PWE-VPLS Slide 76

 VPWS Provisioning

Double Sided Provisioning

each AC provisioned with local name, remote PE address, and remote name
during signaling, local name is sent as SAII, remote name as TAII (AGI = null)
to connect 2 ACs by a PW:
local name = remote name(PWid FEC) or
local name of each must be remote name of the other

Single Sided Provisioning with Discovery

each AC provisioned with local name (VPN-id) and AII
during signaling, local name is sent as AGI
to connect 2 ACs by a PW:
both must have the same VPN-id
only one needs to be provisioned with remote name (local name of other AC)
neither needs to be provisioned with the address of the remote PE
during auto-discovery procedure:
each PE advertises its <VPN-id, local AII> pairs
each PE compares its local <VPN-id, remote AII> pairs
with <VPN-id, local AII> pairs from other PEs
if match then need to connect
local name sent as SAII, remote AII sent as TAII, VPN-id as AGI

Y(J)S PWE-VPLS Slide 77

 VPLS Provisioning

every VPLS instance is assigned a unique VPN-id

PEs are preconfigured or find each other using auto-discovery
if PE detects VPN-id to which it belongs
it sets up a PW
during signaling
– VPN-id is send as the AGI field
– SAII and TAII are set to null

Y(J)S PWE-VPLS Slide 78

 LDP VPLS

ex-“Lasserre-VKompella draft”, now draft-ietf-l2vpn-vpls-ldp

authors: Marc Lasserre - Riverstone and Vach Kompella – Alcatel
supported by Cisco, Nortel, Alcatel, Riverstone, Extreme, Luminous, Corrigent, Hatteras, Overture, RAD

use LDP for

– PW setup and tear-down signaling
– explicit withdrawal of MACs (force relearning)

full mesh of targeted LDP sessions between VPLS-enabled PEs

automatically establish a full mesh of Ethernet PWs
 participating PE sends an unsolicited label mapping message
to every other PE, specifying VPN-ID (preferably with generalized PWid FEC element)
 if receiving PE accepts,
it sends a label mapping message back

Y(J)S PWE-VPLS Slide 79

 BGP VPLS
ex-“Kompella draft”, now draft-ietf-l2vpn-vpls-bgp
authors: Kireeti Kompella, Yakov Rekhter – Juniper

uses BGP4 (with multiprotocol extensions) for:

 autodiscovery (uses Route Target extended community as VPN-ID)
 PW setup and tear-down (uses Network Layer Reachability Information)
 force MAC relearning (uses Relearn Sequence Number TLV)

protocol essentially identical to RFC2547bis (to be discussed later)

Y(J)S PWE-VPLS Slide 80

 BGP VPLS signaling
define demultiplexor = VPN-ID + ingress PE
VPLS Edge (VE) advertises VPLS NLRIs for each VPLS instance
NLRI defines demultiplexors for all PEs in VPLS instance
extended attribute encodes PE capabilities

if new PE joins VPLS

new NLRI seamlessly adds new label
coalesce to a single NLRI with temporary service disruption

PE sets up PW when it receives an NLRI for VPLS

to leave VPLS instance PE withdraws NLRI

remote PEs remove PWs

Y(J)S PWE-VPLS Slide 81

Generalizations

Y(J)S PWE-VPLS Slide 82

 Distributed (Generic) VPLS
CE
U-PE
access CE
PE VPLS N-PE network

U-PE CE
PE
CE

L2VPN framework allows decomposition of PE

 User-Facing PE (U-PE) performs Bridge functions
MAC learning, forwarding decisions
 Network-Facing PE (N-PE) performs VPLS functions
establishes tunnels, PWs V B

U-PE is inexpensive CLE, good for MTU applications

Y(J)S PWE-VPLS Slide 83

 Hierarchical VPLS
PE MTU VPLS

VPLS MTU PE HVPLS

PE MTU VPLS

straight VPLS has a problem – N2 PWs are used

which means N2 LDP sessions, and N2 floods and replications

to improve scalability, can use hub-and-spoke topology

if VPLS is in multi-tenant buildings, local PE is MTU
HVPLS PEs are full mesh, but do not perform bridging
spoke PW set up between PE and MTU (note end-point is virtual bridge)
Y(J)S PWE-VPLS Slide 84
L3VPNs

Y(J)S PWE-VPLS Slide 85

 BGP MPLS VPNs (2547bis)
presently most popular provider managed VPN

originally specified in RFC 2547, update in draft called RFC 4364

transports IPv4 (IPv6) traffic in MPLS tunnels

uses BGP for route distribution

since SPs commonly use BGP for routing

2547 is not an overlay model

– CE routers at different sites are not routing peers
– they do not directly exchange routing information
– they don’t even need to know of each other
– so customer needn’t manage a backbone or virtual backbone
– no inter-site routing problems

Y(J)S PWE-VPLS Slide 86

 BGP MPLS VPNs (cont.)

only PE routers maintain VPN information

P routers needn’t maintain any customer routing information

C routes either manually configured in PE

or advertised to PE using BGP, OSPF, etc.

PE advertises routes to remote PEs using BGP

remote PEs advertise routes to their CEs using BGP, OSPF, etc.

IP address overlap solved using Route Distinguisher (RD)

Y(J)S PWE-VPLS Slide 87

 RFC 4364 (2547bis) architecture
CE not peer to CE
CE peer to PE
C C C
C CE
CE PE P P PE
C CE is IP router C
SP label
ext label
IP Packet

Virtual router (peering) model, not tunneling

PE maintains Virtual Route Forwarding table for each VPN
BGP (with multiprotocol extensions) used for label distribution
in order to support private IP addresses
PE prepends 8B Route Distinguisher (unique to site) to IP address
Y(J)S PWE-VPLS Slide 88
 L2VPN vs. L3VPN
 C switch connects to L2 circuits  C router peers with SP router

 BGP or LDP  BGP

 all L3 traffic types  limited to IP traffic

 only Ethernet L2  supports different L2 technologies

 Cs responsible for routing  SP responsible for routing

 “overlay model”  “peer model”

 simple customer-SP interface  complex customer-SP interface

 C peering scales as VPN size  C peering independent of VPN size

 scaling problem  scales well

Y(J)S PWE-VPLS Slide 89