Routing in L1VPN Networks
MPLS Japan 2006
Tokyo, October 2006

Dimitri Papadimitriou
NSG/CTO, Alcatel

All rights reserved © 2006, Alcatel

OutlineMotivation
Service Characterization
Service Models
Discovery / Routing
AnalysisConclusion

ALCATELVPN Routing| PAGE2
Presentation
Title || NOV
Date 2006| Page2

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel1Motivations for Layer 1 VPN
 Key Business Drivers for customers
y Outsourcing–Third party control: outsource direct management of layer 1 network–Off-loading CE-to-CE configuration: no need to configure and manage fullconnectivity between CEs
y Cost–Sites can be inter-connected without bearing full cost of deploying and managing
the layer 1 network

 Key Business Drivers for network providersy Network Resource saving–Sharing layer 1 network infrastructure with many customers–More flexible usage of spare resource (higher sharing ratio)

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

ALCATELVPN Routing| PAGE3
Presentation
Title || NOV
Date 2006| Page3

The BIG PictureCustomer Edge (CE) device
CECEPPE receives L1VPN service from theprovider network

 connected to at least one PE device(terminates L1 signal)

 examples: L2 switch, IP/MPS LSR, IProuter

Provider Edge (PE) device

 provides L1VPN service to thecustomer

 connected to at least one CE device examples: TDM switch, or OXC
Provider device (P) connected only to other provider
devices (P or PE devices) Example: TDM switch, or OXC
Providernetwork

Membership information

 list of CE-PE TE link belonging to thesame VPN

ALCATELVPN Routing| PAGE
4
Presentation
Title || NOV
Date 2006| Page4

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel2

Layer 1 VPN Service Characterization
 Connectivity
y Source-Destinationy Capacity
y Other traffic parameters Availability
y Function f(reliability, maintanability)y Availability = uptime (MTTF) / [uptime (MTTF) + downtime (MTTR)]–Reliability = probability Pr that system or component fails within a given period oftime (MTTF ~ 1/Pr)–Maintanability = probability Pm that system or component will be retained in or
restored to a specified condition within a given period of time (MTTR ~ 1/Pm)

ALCATELVPN Routing| PAGE
5Presentation
Title || NOV
Date 2006| Page5

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
AlcatelLayer 1 VPN Service Characterization
 Scalabilityy Number of sites per VPN / per PE
y Number of PEs per VPN
y Number of VPN per SP network (linearly)y Maintain VPN specific information on PE (CE) Robustness
y For a given set of features, with a given set of perturbations, the system continues tooperate correctly (as expected)
y Dependence– Configuration/maintenance operation between VPNs
– Isolation in case error/failure Efficiency (performance) Flexibility/adaptivity (evolutivity, migration)
 Manageability (configuration, accounting, monitoring/measurement) Security

ALCATELVPN Routing| PAGE
6
Presentation
Title || NOV
Date 2006| Page6

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel3

Layer 1 VPN Service Models
 Management based ⇒ Signaling information within provider network Signaling based ⇒ Routing information within provider network
y VPN membership information between PEs
y Provider network routing information

 Signaling and Routing based ⇒ Routing information between CE-PE
y VPN membership information between PEs
y Provider network routing informationy Customer network routing information

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

ALCATELVPN Routing| PAGE
7
Presentation
Title || NOV
Date 2006| Page7

Layer 1 VPN Service Models - Management-based Management based ⇒ Signaling information within provider network

Client-network I/f

Service Mgt(agent)Clientservice
agent

Network
Management layer

Network Mgt(agent)PE (Control)
PE device

SP network

ALCATELVPN Routing| PAGE
8
Presentation
Title || NOV
Date 2006| Page
8ServiceManagement layer

CE (Control)
CE device

Network Controllayer

Client network

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

4Layer 1 VPN Service Models - Management-based Management based ⇒ Signaling information within provider network
Order #1
Order #2

NMS
VPN#1 Operator

CE5
CE1P6P1
PE1

PE3

P5P2

CE4

VPN#2 Operator
PE2

CE2

P3

P4

CE3

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

ALCATELVPN Routing| PAGE
9PresentationTitle || NOV
Date 2006| Page9Layer 1 VPN Service Models - Signaling-based Signaling based ⇒ Routing information within provider network
y VPN membership information between PEs
y Provider network routing information

Service Mgt(agent)

Client-network I/f
if no unified service model

Clientservice
agent

Network
Management layer

Network Mgt(agent)PE (Control)
PE device

SP network

ALCATELVPN Routing| NOV| 2006
PAGE 10Presentation
Title | Date
Page| 10Service
Management layer

CE (Control)
CE device

Network Control
layer

Client network

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel5

Layer 1 VPN Service Models - Signaling-based Signaling based ⇒ Routing information within provider network
y VPN membership information between PEs
y Provider network routing information

 Equivalent to the overlay model operations
Dest.CE ⇒ Dest.PE(intra-provider routing)
VPN#1 Operator

CE5
CE1

P6

P1
PE1

PE3

P5

P2

CE4

VPN#2 Operator
PE2

CE2

P3

P4

CE3Dest.PE ⇒ Dest.CE

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

ALCATELVPN Routing| NOV| 2006
PAGE 11
Presentation
Title | Date
Page| 11Layer 1 VPN Service Models - Routing-based (Signaling and) Routing based ⇒ Routing information between CE-PE
y VPN membership information between PEs
y Provider network routing informationy Customer network routing information

Service Mgt(agent)Client-network I/f
if no unified service model

Clientserviceagent

Network
Management layer

Network Mgt(agent)PE (Control)
PE device

SP network

ALCATELVPN Routing| NOV| 2006
PAGE 12Presentation
Title | Date
Page| 12Service
Management layer

CE (Control)
CE device

Network Control
layer

Client network

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel6

L1VPN Steps

1. Run discovery mechanism

 PEs to discover about remote VPN ports and their corresponding provider
addressing (PPI) CE to discover (when needed) set of remote CE port addresses (to be usedfor signaling) - only routed model

2. CE initiates signaling request to attached PE for a given remote CE Using private address space During signaling, at local/remote PE switch private with provider addresses(referred as “shuffling” approach) No need for VPN-ids in signaling between CE-PEs

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

ALCATELVPN Routing| NOV| 2006
PAGE 13
Presentation
Title | Date
Page| 13

L1VPN Building Blocks (Control Plane)

Membership Discovery
RFC 2858

MP-BGP RFC 4360
OSPF

RFC 2328
RFC 2370

PE-to-PE Exchange(Signaled model)
CE-to-CE Exchange(Routed model)

PE-to-PE Signaling(SPC mode)

Signaling
RFC 3473

RSVP-TERFC 4208
TE Routing

CE-to-CE Signaling(SVC mode)
PE-to-PE Exchange

RFC 3630

OSPF-TE RFC 4203

ALCATELVPN Routing| NOV| 2006
PAGE 14
Presentation
Title | Date
Page| 14

Note: routed model allow
for CE-to-CE exchange

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

7

VPN Membership Information

Port Information Table (PIT)
localized on each PE

PortPort Information
Information Table
Table (PIT)
(PIT)
Link
Link #1:#1: <172.16.1.1,<172.16.1.1, 10.1.1.1>
10.1.1.1>

 Contains list of <CPI,PPI> tuples per

Link
Link #2:#2: <172.16.1.2,<172.16.1.2, 10.1.1.2>
10.1.1.2>

VPN

Link
Link #3:#3: <3,172.16.16.1;<3,172.16.16.1; 3,10.1.10.1>
3,10.1.10.1>

Customer Port Identifier (CPI) Numbered link: IPv4/IPv6 address Unnumbered link: <port index, CE

172.16.16.1

10.1.10.1

IPv4/IPv6 address>

Provider Port Identifier (PPI)CE

 Numbered link: IPv4/IPv6 address Unnumbered link: <port index, PEPE

IPv4/IPv6 address>
CPI
CPI

PPI
PPI (provider(provider only)
only)

Note: on PE side, PPI maps VPN-PPI I/f
I/f #1:#1: 172.16.1.1
172.16.1.1(to maintain address space isolation) I/f
I/f #2:#2: 172.16.1.2
172.16.1.2

I/f
I/f #1:#1: 10.1.1.1
10.1.1.1
I/f
I/f #2:#2: 10.1.1.210.1.1.2

I/f
I/f #3:#3: <3,172.16.16.1><3,172.16.16.1>

I/f
I/f #3:#3: <3,10.1.10.1><3,10.1.10.1>

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

ALCATELVPN Routing| NOV| 2006
PAGE 15
Presentation
Title | Date
Page| 15

Discovery
Discovery: Piggybacking of VPN membership info in routing protocol

 Each PE advertises (to other PEs)y own IP address
y list of local <CPI, PPI> tuples
y GUID (Global Unique Identifier) associated to the VPN

 Remote PEs
y identifies list of common VPN members with advertising PEs
y perform address resolution during signaling phase

CE1PE3P5P2

ALCATELVPN Routing| NOV| 2006
PAGE 16PresentationTitle | DatePage| 16

CE5P6P1PE1

CE2PITrouting

PIT

CE4PE2P3P4

CE3ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

8Discovery
Single-end provisioning Add new [CE,PE] link to VPN A ⇒ localized configuration action only
CE1PITrouting

PIT

CE5P6P1PE1PE3P5P2

CE4PE2

CE2P3P6P1PE1PIT
CE5PITAdd link #2[CE4,PE3]

PE3P5P2

CE2

CE3routing

PIT
CE1P4

CE4PE2P3P4

ALCATELVPN Routing| NOV| 2006
PAGE 17PresentationTitle | Date
Page| 17CE3

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

OSPF as VPN Membership Discovery ProtocolRationales

 Widely used for TE routing (GMPLS protocol suite) Facilitate [CE,PE] TE link information exchangey Maintain single TE routing protocol
y Well-defined TE link attributes

 GMPLS L1 networks have usuallyy reasonable dimensions (#PEs, #CEs, etc.)
y smaller number of VPNs than L3 case (O(10k)) ~ O(10) to O(100)Issues Single AS (single or multi-area) AS-wide scope opaque LSAs require extended processing from RFC 2370
 Scalabilityy P participates in the flooding of L1VPN opaque LSAs and maintains LSAs inLSDBALCATELVPN Routing| NOV| 2006
PAGE 18
Presentation
Title | DatePage| 18

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel9LS Update (LSU) Packet Format and Header
3104Vers (8bits)

Packet Length (16 bits)

Router_ID (32 bits)

OSPF Header

Area_ID (32 bits)
LS checksum (16 bits)#LSAs (32 bits)

Auth. Type (16 bits)

Authentication (32 bits)
Authentication (32 bits)h Number of LSAs: the number of LSAs included in this

LS update (LSU) packetLSAs.
h Link State Update packet body: list of LSAs

Each LSA begins with a common 20 byte header (seenext slide)

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

ALCATELVPN Routing| NOV| 2006
PAGE 19
Presentation
Title | Date
Page| 19

LS Update Packet - LSA Header and Format0OSPF Header

L1VPN LSA: LS Type = 11 (Opaque) 31
LS Age (16 bits)
Opaque Type# LSAs (32 bits)

Options

LS Type = 11

Opaque ID (24 bits)
Advertising Router (32 bits)

LS sequence number (32 bits)

Opaque LSA Header

LS checksum (16 bits)

Length (16 bits)

Top level TLV…
Opaque LSA Header
Top level TLV
Top level TLV

ALCATELVPN Routing| NOV| 2006
PAGE 20
Presentation
Title | Date
Page| 20

Rule per [RFC3630]:
single top-level TLV per LSA
must include a single L1VPN top-level TLV
may include a single TE Link top-level TLV

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

10L1VPN TLV Structure

L1VPN Globally unique identifier <PPI, CPI> tuples association with a particular VPN
 Encode a VPN-ID, a route target, or equivalent
PE IP Address e.g. TE Router or local numbered TE link ID
L1VPN auto-discovery information: set of <CPI,PPI> tuples
L1VPN Information TLV in L1VPN LSA
310
Length (16 bits)

Type (16 bits)

Globally Unique Identifier

32bitsGlobally Unique Identifier
Reachable IP Address (PE)
<CPI,PPI> Tuple #1...
<CPI,PPI> Tuple #n

ALCATELVPN Routing| NOV| 2006
PAGE 21
Presentation
Title | Date
Page| 21

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

Theory of Operation
PEs origination and flooding

 local <CPI, PPI> tuples in L1VPN info TLV of LSAs
 Each PE must originate
y separate L1VPN LSA for each locally configured CE-PE linky separate L1VPN LSA for each VPN (no TE link TLV used) L1VPN LSA originatedy PE restarty change in PIT entry (no PIT per CE-PE link but per VPN)

AS wide scope flooding

 Flooding to all PEs within the AS
 Receiving PE to check whether
y PIT associated with the L1VPN specified in the L1VPN GUIDy Add/remove or modify the corresponding PIT entry

Policy PE local policy with respect to PIT management
ALCATELVPN Routing| NOV| 2006
PAGE 22
Presentation
Title | Date
Page| 22

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel11

LSA Selection Process (simplified)
LSA
Is entry inlink-state
database?

LSUYesNoAAdd
Add toto databasedatabase
Send
Send LSAck
LSAck
Flood
Flood LSALSA
Run
Run SPFSPF toto calculate
calculatenewnew routing
routing table
table
EndIs seq. #the same?

Ignore LSA
Yes

NoIs seq. #higher?
NoYes

Goto A

Send LSU
with newer
information tosource

End

ALCATEL VPN Routing | NOV 2006 | PAGE 23

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel

BGP as VPN Membership Discovery Protocol

Rationales

 Widely used for BGP/MPLS L3VPN routing [RFC4364]
y Single routing protocol for LxVPN (GVPN) with common mechanisms

 Support any topology (since BGP works across multiple routing domains, it
supports L1VPNs that span multiple routing domains)y Single ASy Multi AS (single or multi-carrier)Issues BGP rarely used in non-packet environments (in certain cases) need to augment reachability with CE-PE link information
y optional non-transitive attribute TE information processing

ALCATELVPN Routing| NOV| 2006
PAGE 24
Presentation
Title | Date
Page| 24

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

12

BGP (MP- BGP + Route Filtering)Route propagation: Multi-Protocol extensions to BGP [RFC2858]

 Propagation of local information to other PEs
 At provisioning time, when adding a new CE-PE link between
y Corresponding PE port associated with a PIT on that PE
y This PIT is associated (at provisioning time) with its configured VPN

Route filtering: Route Target Extended Community [RFC4360]
y Restrict exchanges to only PITs within a given L1VPN
y Tagging exported local information– each PE PIT configured with one or more Route Target Communities,(export Route Targets)
y Filtering imported information– each PE PIT configured with one or more Route Target Communities(import Route Targets)– set of imported routes into the PIT restricted to only routes that have atleast one of these communities

ALCATELVPN Routing| NOV| 2006
PAGE 25
Presentation
Title | Date
Page| 25

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
AlcatelBGP UPDATE message with MP_REACH_NLRIUPDATE message

Path
attributes

BGP Header…
ORIGIN
AS_PATH
NEXT_HOP

AFI
MP_REACH_NLRIUPDATE message with MP_REACH_NLRI: announceroutes

SAFI
NEXT_HOP…
NLRI

BGP NEXT_HOP: meaningless in case of an MP_REACH_NLRI
and can be left out
AFI: Specifies the type of network layer protocol associated with thenetwork address of the next hop (encoded in a separate field).
Specifies address type of next hop
SAFI: Specifies the type of the NLRI. New L1 VPN SAFINext_Hop: address of the next hop for the routes in the NLRI field.
The address type is defined by the AFI
NLRI: carrying the CPI and PPI information i.e. one or more <PPI,CPI> tuples

ALCATELVPN Routing| NOV| 2006
PAGE 26
Presentation
Title | Date
Page| 26ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,Alcatel

13BGP UPDATE message with MP_REACH_NLRIUPDATE message

Pathattributes

BGP Header…

UPDATE message with MP_REACH_NLRI: announceroutes

ORIGIN
AS_PATH
NEXT_HOP

MP_REACH_NLRI

AFINLRI: carrying the CPI and PPI information i.e. one or more <PPI,CPI> tuples

SAFI
NEXT_HOP…

Length (1 octet)

PPI AFI (2 octet)
PPI Length (1 octet)
Variable
CPI AFI (2 octet)

NLRI

CPI Length (1 octet)
Variable

ALCATELVPN Routing| NOV| 2006
PAGE 27PresentationTitle | Date
Page| 27

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
AlcatelAnalysis

Which routing protocol to choose ?
Depends on requirements

 Topology (single vs multi-domain) Number of PEs, CEs, VPNs, etc.
 Traffic engineeringy Coupled to intra-domain routing (single TEDB)y De-coupled from intra-domain routing Operationaly Service provisioning (CE-to-CE connectivity)y Network provisioning (PE-to-PE connections)

ALCATELVPN Routing| NOV| 2006
PAGE 28
Presentation
Title | Date
Page| 28

ALL RIGHTS All
RESERVED© 2006,ALCATEL
rights reserved© 2005,Alcatel

14Analysis

Timing: depending on need's importance vs urgency

 Dynamic PTI tables population may be rather static (… static PIT population)
 When dynamic frequency of changes/modification
Performance Extend OSPF with “external TE reachability” ⇒ impact on P scaling Extend BGP with “TE information” ⇒ impact on PE scaling
Cost Single protocol for LxVPN (x = 1, 2, 3)
 Single protocol for L1/TE operations
 Note: are operators looking for integrating their TE operations (including VPNor not) or VPN operations (including TE or not)

ALCATELVPN Routing| NOV| 2006
PAGE 29
Presentation
Title | Date
Page| 29

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
AlcatelConclusion

VPN membership information discovery in signaled/routed model OSPF
 BGP
BGP did not receive lots of attention in the GMPLS context

 Makes the choice of routing protocol less obvious
 Both OSPF and BGP require extensions
Choice of VPN membership information discovery

 Inter-carrier VPN will require BGP (inter-domain routing protocol)
 Single future proof / interoperable solution always better … but this future still seems really far away

ALCATELVPN Routing| NOV| 2006
PAGE 30
Presentation
Title | Date
Page| 30

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel15

In Memoriamof Emmanuel Desmet
deceased suddenly the 17th of October 2006

ALCATELVPN Routing| NOV| 2006
PAGE 31
Presentation
Title | Date
Page| 31

ALL RIGHTS All
RESERVED© 2006,
ALCATELrights reserved© 2005,
Alcatel16