Download TDMoIP : IPR

MPLS
Yaakov (J) Stein
February 2006
Chief Scientist
RAD Data Communications
Why study MPLS?

it’s new

it’s different and interesting

along with IPv6 it will save the Internet

it enables delivery of IP VPN services

it facilitates pseudowire functionality

all of the above
Y(J)S MPLS Slide 2
Course Outline
1) Introduction
2) MPLS Forwarding Component
3) MPLS Control Component
4) MPLS Traffic Engineering
5) MPLS Applications
Y(J)S MPLS Slide 3
1
2
3
4
5
1
2
3
4
5
Introduction
1.1 Review of forwarding and routing
1.2 Problems with IP routing
1.3 Label Switching
Y(J)S MPLS Slide 4
Forwarding and Routing
a router (switch) performs 2 distinct algorithms
 forwarding algorithm (forwarding component)
 routing algorithm (control component)
may be manual configuration or signaling protocol
from the forwarding point of view
there are three different types of network:
 broadcast (e.g. Ethernet)
 connectionless (e.g. IP)
 connection oriented (e.g. ATM)
1.1
Y(J)S MPLS Slide 5
Broadcast (e.g. Ethernet)
not for
me
for me!!
not for
me
not for
me
not for
me
not for
me
not for
me
message is sent to all possible recipients
all receivers check message destination address
if message destination address does not match receiver’s address
message ignored (except in promiscuous mode)
if message destination address matches receiver’s address
message processed
1.1
Y(J)S MPLS Slide 6
Connectionless Forwarding
broadcast is only practical for small networks (e.g. LANs)
large networks can be broken into subnetworks
with routers performing the internetworking
such a network is connectionless (CL) if
 no setup is required before sending data
CL forwarder (router)
each router makes independent forwarding decision

packets are self-describing
packet inserted anywhere will be properly forwarded
Notes:
– the address must have global significance
– IP actually relies on a L2 protocol (Ethernet, PPP) for final stage
1.1
Y(J)S MPLS Slide 7
IP Routing

Distance Vector (Bellman-Ford), e.g. RIP
– send <addr,cost> to neighbors
– routers maintain cost to all destinations
– need to solve “count to  problem“

Path Vector, e.g. BGP
–
–
–
–
–

send <addr,cost,path> to neighbors
similar to distance vector, but w/o “count to  problem“
like distance vector has slow convergence*
doesn’t require consistent topology
can support hierarchical topology => exterior protocol (EGP)
Link State, e.g. OSPF,
IS-IS
– send <neighbor-addr,cost> to all routers
– determine entire flat network topology (Dijkstra’s algorithm)
– fast convergence*, guaranteed loopless => interior routing protocol (IGP)
*convergence time is the time taken until all routers work consistently
before convergence is complete packets may be misforwarded, and there may be loops
1.1
Y(J)S MPLS Slide 8
IP Forwarding
what field is used for forwarding?
field used depends on application



regular: use longest destination prefix match
ToS: use longest destination prefix match + exact match on ToS
multicast: use longest/exact match on source/group address
how is forwarding performed?
forwarding algorithm depends on routing algorithm!



for Distance Vector - forward by cost
for Path Vector - forward by cost and path
for Link State - Dijkstra’s algorithm
1.1
Y(J)S MPLS Slide 9
Connection Oriented Forwarding
CO forwarder (switch)
input ports
1
1
2
2
3
3
4
4
5
5
output ports
each forwarder maintains forwarding table (or table per input port)
control component:
 route must be set-up (table must be updated) before data sent
 set-up may be manual or signaled
 once route no longer needed it should be torn-down
1.1
Y(J)S MPLS Slide 10
CO Forwarding
CO addresses need not have global significance
by using locally defined addresses:
 addresses are smaller in size
 no need for global allocation mechanism
 no need to maintain global database
L2 forwarding is based on address read and swap
12
17
23
Note:
when addresses are purely local
CO forwarding is called L2 (link layer) forwarding
1.1
Y(J)S MPLS Slide 11
CO Forwarding Table
input port
input address
output port
output address
1
21
2
21
1
37
1
21
2
12
5
12
3
5
5
12
4
15
3
37
Note: never really have an input port column
either it is irrelevant (CO address is per switch not per input port),
or if needed (e.g. ATM) we keep separate tables per input port (more efficient)
1.1
Y(J)S MPLS Slide 12
CO Routing
for CO forwarding we need to find a route at setup
– manual configuration (strict explicit route)
– use routing protocols (e.g. P-NNI for ATM)
CO routing protocols search for a global path
– hence they can guarantee global characteristics (SLA)
– pure CL routing can not guarantee path QoS
information source usually knows desired characteristics
so usually use source routing
source routing
– can force route to go through specific forwarders (loose explicit route)
– can reject forwarders that can not guarantee needed characteristic
– can request resource reservation in selected forwarders
1.1
Y(J)S MPLS Slide 13
Problems with IP routing

scalability
– router table overload
– routing convergence slow-down
– increase in queuing time and routing traffic
– problems specific to underlying L2 technologies
hard to implement load balancing

QoS and Traffic Engineering

problem of routing changes

difficulties in routing protocol update

lack of VPN services

1.2
Y(J)S MPLS Slide 14
Scalability
when IP was first conceived scalability was not a problem
as IP traffic increases, routing shows stress
simplistic example
– N hosts
– each router serves M hosts
– each router entry takes a bytes
hence
– router table size a N ~ N
– N / M ~ N routers (more routers => slower convergence)
– packet processing time* ~N (since have to examine entire table)
– ~N routers send to ~N routers tables of size ~N
so routing table update traffic increases ~N 3 (or ~N 4 )
* IP routing requires 1000s of clocks per decision
1.2
Y(J)S MPLS Slide 15
L2 Backbone Scalability
instead of expensive and slow IP routers
we can use faster and cheaper ATM switches in core
ATM
Classical IP
over ATM
but this doesn’t help! ATM switches are transparent to routers
since ATM switches do not participate in IP routing protocols
every IP router must be logically adjacent to every other
and we need ~ N2 ATM VCs !
if only the ATM switches could understand IP routing protocols!
1.2
Y(J)S MPLS Slide 16
Load Balancing
A
“fish diagram”
D
2
B
C
G
1
3
4
E
F
2
3
using hop-count as path cost
traffic destined for G from both A and B goes through D
so links CD and DG become congested
while links CE, EF, and FG are underutilized
since IP forwarding uses only destination address
this can’t be overcome in pure IP routing
problem even exists in equal-cost multi-path (ECMP) case
solution requires traffic engineering
1.2
Y(J)S MPLS Slide 17
QoS and TE
pure IP, being CL, can not guarantee path QoS
but other protocols in the IP suite can help



TCP adds CO layer compensating for loss and misordering
IntServ (RSVP) sets up path with reserved resources
DiffServ (ToS) prioritizes packets (neither -Serv widely deployed)
so IP network managers mostly use network engineering
– i.e. throw BW at the problem
rather than traffic engineering
– i.e. optimally exploit the BW you have
1.2
Y(J)S MPLS Slide 18
Routing Changes
IP routing is satisfactory in the steady state
but what happens when something changes?
change in routing information
(new router, router failure, new inter-router connection, etc)
necessitates updating of tables of all routers
convergence will be slow
change in routing protocol is even worse
(e.g. Bellman-Ford to present, classes to classless, IPv4 to IPv6)
necessitates upgrade of all router software
upgrade may have to be simultaneous
need more complete separation of forwarding from routing functionality
1.2
Y(J)S MPLS Slide 19
VPN Services
192.115.243.79
192.115.243.19
IP
192.115.243.19
IP was designed to interconnect LANs
not to provide VPN services
all routers logically interconnected, so security weak
LANs may use non globally unique addresses (present solution - NAT)
complex provider - customer relationship
VC-merge problem (discussed later)
1.2
Y(J)S MPLS Slide 20
Solution - Label Switching
CO forwarder (switch)
CL forwarder (router)
LSR
label switching adds the strength of CO to CL forwarding
label switching has three stages:
– routing (topology determination) using L3 protocols
– path setup (label binding and distribution)
– data forwarding
label switching the solution to all of the above problems
–
–
–
–
speeds up forwarding
decreases forwarding table size (by using local labels)
load balance by explicitly setting up paths
complete separation of routing and forwarding algorithms
no new routing algorithm needed
but new signaling algorithm may be needed
1.3
Y(J)S MPLS Slide 21
Where is it?
unlike TCP, the CO layer lies under the CL layer
if there is a broadcast L2 (e.g. Ethernet), the CO layer lies above it
higher layers
layer 3 (e.g. IP)
label switching (layer 2.5)
shim header
layer 2 (e.g. ethernet)
physical layer
hence, label switching is sometime called layer 2.5 switching
1.3
Y(J)S MPLS Slide 22
Labels
a label is a short, fixed length, structure-less address
the following are not labels:
 telephone number (not fixed length, country-code+area-code+local-number)
 Ethernet address (too long, note vendor-code is not meaningful structure)
 IP address (too long, has fields)
 ATM address (has VP/VC)
not explicit requirement, but normally only local in significance
label(s) added to CL packet, in addition to L3 address
layer 2.5 forwarding
 may find a different route than the L3 forwarding
 is faster than L3 forwarding
 requires a flow setup process and signaling protocol
1.3
Y(J)S MPLS Slide 23
Forwarding Equivalence Class
equivalence class - set of entities sharing common characteristics
that can be considered equivalent for some purpose
Theorem (from set theory) - any equality relation (e.g. common features)
divides all entities into non-overlapping equivalence classes
any forwarding algorithm need only consider
 destination (and sometimes source) address
 service requirements (e.g. priority, BW, allowed delay, etc)
we can group together all packets with the same
destination and service requirements as a FEC
by the theorem every packet belongs to one unique FEC
packets in the same FEC should follow the same route
so we should map them to the same label (bind them)
1.3
Y(J)S MPLS Slide 24
FECs
what constitutes a FEC ?
for IP routing (de facto)
all packets w/ same destination IP prefix
that prefix being the longest in the routing table
for MPLS we can decide !
coarsest granularity
all packets with a destination address
served by a given router
finest granularity
all packets from given source socket
to given destination socket
with specified handling requirements
1.3
Y(J)S MPLS Slide 25
Label Switching Architecture
downstream direction
Label Switched Path
L3 link
ingress
L3 router
upstream direction
L3 link
egress
Label Edge Router
Label Edge Router
Label Switched Routers
L3 router
label switching is needed in the core, access can be L3 forwarding*
core interfaces the access at the edge (ingress, egress)
LSR router that can* perform label switching
LER LSR with non-MPLS neighbors (LSR at edge of core network)
LSP unidirectional path used by label switched forwarding (ingress to egress)
* not every packet needs label switching
(e.g. only small number of packets, no QoS)
1.3
Y(J)S MPLS Slide 26
Label Switched Forwarding
LSP needs to be setup before data is forwarded
and torn down once no longer needed
LSR performs
– label switched forwarding* for labeled packets
– label unique to LSR or unique to input interface (like ATM)
– optionally L3 forwarding for unlabeled packets
ingress LER
– assigns packet* to FEC
– labels packet
– forwards it downstream using label switching
egress LER
– removes label
– forwards packet using L3 forwarding
– exception: PHP (discussed later)
*once packet is assigned to a FEC and labeled,
no LSR looks at the L3 headers/address
1.3
Y(J)S MPLS Slide 27
Hierarchical Forwarding
many networks use hierarchical routing
– decreases router table size
– increases forwarding speed
– decreases routing convergence time
Country-Code Area-Code Exchange-Code Line-Number
telephone numbers
Internet DNS
ATM
972
2
588
9159
host
… SLD TLD
myrad . rad . co . il
VC
VC
VC
Ethernet/802.3 address space is flat
(even though written in byte fields)
1.3
Y(J)S MPLS Slide 28
IP Routing Hierarchy
IPv4
– originally flat space (1st come - 1st) until router tables exploded
– then 3 classes A 0 net7
B 10
net14
host24
host16
– now CIDR <RFC1519>
net22
C 110
ASany
host8
host
AS=Autonomous System
IP exploits hierarchy by employing interior/exterior routing protocols
IP can even support arbitrary levels of hierarchy
by advertising aggregated addresses
AS12
AS13
AS13
AS14
but the exploitation is not optimal
1.3
Y(J)S MPLS Slide 29
IP Routing Hierarchy Bug
Net 1
1 transit domain
2
Net 2
traffic from network 1 to network 2 must go through transit domain
to get to any host in network 2,
all transit domain routers forward to border router 2
transit domain routers shouldn’t need to know anything about network 2
but for IP protocols* change in network 2 forces rerouting in transit domain
in worst case, transit domain routers need to know all routes in Internet
avoiding maintenance of interdomain information
•
•
•
•
conserves routing table memory
ensures faster convergence
transit domain routers restart faster
provides better fault isolation
* except at BGP-OSPF interface
1.3
Y(J)S MPLS Slide 30
Label Stacks
since labels are structure-less, the label space is flat
label switching can support arbitrary levels of hierarchy
by using a label stack
top label
another label
yet another label
bottom label
label forwarding based only on top label
before forwarding, three possibilities (listed in NHLFE) :
– read top label and pop
– read top label and swap
– read top label, swap, and push new label(s)
1.3
Y(J)S MPLS Slide 31
Example Uses of Label Stack
Example applications that exploit the label stack
– fast rerouting
– VPNs
– X over MPLS (PWE3)
Note: three labels is usually more than enough
1.3
Y(J)S MPLS Slide 32
Fast Rerouting
IP has no inherent recovery method (like SONET)
in order to ensure resilience we provide bypass links
to reroute quickly we pre-prepare labels for the bypass links
when link down
change fwd table
swap
swap
12
11
10
swap
+
push
13
swap
swap
14
pop
11
11
protection LSP
11
from here on
no difference! *
* label space per LSR
not per input port
1.3
Y(J)S MPLS Slide 33
Label Switched VPNs
C
C
C
C
CE
CE
C
C
customer 1 network
P
P
P
C
CE
C
customer 2 network
customer 2 network
PE
PE
C
P
P
provider network
Key
C
Customer router
CE Customer Edge router
P
Provider router
PE Provider Edge router
C
C
CE
C
customer 1 network
1.3
Y(J)S MPLS Slide 34
Label Switched VPNs (cont.)
customers 1 and 2 use overlapping IP addresses
C-routers have inconsistent tables
egress PE
ingress PE-router inserts two labels
egress CE
IP headers
payload
P-routers don’t see IP addresses
so no ambiguity
P-routers see only the label of the egress PE-router
– they don’t know about VPNs at all
– no need to understand customer configuration
– hence smaller tables & no rerouting if customer reconfigures
ingress PE router only knows about CE routers
– no need to understand customer configuration
1.3
Y(J)S MPLS Slide 35
X over MPLS
P
router
P
router
native
service
PE
router
P
router
A tunnel may
contain
many PWs
PE
router
native
service
P
router
tunnel label *
PW label *
PW control word
payload
*
Dictionary:
MPLS-f inner label
outer label(s)
ITU-T interworking label transport label(s)
IETF
PW label
tunnel label(s)
1.3
Y(J)S MPLS Slide 36
Service Interworking
Network interworking (PW):
Native
Service
A
Customer
Edge
(CE)
Provider
Provider
provider Edge
Edge
network
(PE)
(PE)
Customer
Edge
(CE)
Native
Service
A
Service interworking:
Native
Service
A
Customer
Edge
Provider
Edge
(CE)
(PE)
Provider
provider Edge
network
(PE)
Customer
Edge
(CE)
Native
Service
B
1.3
Y(J)S MPLS Slide 37
Label (20b)
Exp(3b) S(1b)
TTL (8b)
MPLS Forwarding Component
2.1 The essentials
2.2 The documents
Y(J)S MPLS Slide 38
MPLS history
many different label switching schemes were invented
 Cell Switching Router (Toshiba) <RFC 2098,2129>
 IP Switching (Ipsilon, bought by Nokia) <RFC 2297>
 Tag Switching (Cisco) <RFC 2105>
 Aggregate Route-based IP Switching (IBM)
 IP Navigator (Cascade bought by Ascend bought by Lucent)
so the IETF decided to standardize a single method
 BOFs 1994-1995
 WG chartered 1997
– co-chairs from Cisco and IBM (so similar to tag switching and ARIS)
– Cisco, IBM, Ascend authored architecture document
 MPLS standards-track RFCs 20012.1
Y(J)S MPLS Slide 39
MPLS
of all the label switching technologies - what is special about MPLS ?

multiprotocol - from above and below

label in L2 or shim header

single forwarding algorithm, including for multicast and TE

can run on IP router or ATM switch with only SW upgrade
(although can benefit from special HW)

label distribution piggybacked on existing routing protocols or via LDP

control-driven downstream label binding

support for constraint-based routing (for TE)
2.1
Y(J)S MPLS Slide 40
Multiprotocol Label Switching
IPv4
IPv6
IPX
etc.
frame-relay
etc.
MPLS
Ethernet
ATM
2.1
Y(J)S MPLS Slide 41
MPLS Labels
label may be an appropriate address in either L2 or L3
(even if we lose other features)
Examples:
– for ATM use VPI and VCI fields as two labels (only two labels, no TTL)
– for frame-relay use DLCI (only one label, no CoS, no TTL)
otherwise use shim header (described later)
ATM header
Ethernet header
PPP header
MPLS shim header
MPLS shim header
MPLS shim header
IP headers
IP headers
IP headers
payload fragment
payload
payload
ATM header
multi-access subnet
point-to-point & POS
payload fragment
MPLS over ATM
2.1
Y(J)S MPLS Slide 42
ATM Label Switching
GFC
VPI/VCI => top label
PTI/CLP/HEC
GFC
VPI/VCI => top label
PTI/CLP/HEC
MPLS shim
payload fragment
IP headers
rest of cells
payload fragment
1st cell
AAL5 PDU
shim
ATM cell
IP packet
ATM cell
AAL5 trailer
…
ATM cell
MPLS WG
in this mode the label is carried in the VPI/VCI
devoted a lot of time
this facilitates using ATM switches
to this case
however, we still need the shim header for S, and TTL
the label field in shim header is a placeholder and set to zero
2.1
Y(J)S MPLS Slide 43
MPLS Shim Header
Label (20b)
Exp(3b) S(1b)
TTL (8b)
when a shim header is needed, its format should be:
Label there are 220 different labels (+ 220 multicast labels)
Special (reserved) labels
0 IPv4 explicit null
1 router alert
2 IPv6 explicit null
3 implicit null
Exp (CoS) left undefined by IETF WG
was CoS in Cisco Tag Switching
could influence packet queuing
S=0
Stack bit S=1 indicates bottom of label stack
S=0
another label
S=0
yet another label
S=1
bottom label
TTL decrementing hop count
used to eliminate infinite routing loops
generally copied from/to IP TTL field
top label
2.1
Y(J)S MPLS Slide 44
Single Forwarding Algorithm
IP uses different forwarding algorithms
for unicast, unicast w/ ToS, multicast, etc.
LSR uses one forwarding algorithm (LER is more complicated)
– read top label L
– consult Incoming Label Map (forwarding table) [Cisco terminology LFIB]
– perform label stack operation (pop L, swap L - M, swap L - M and push N)
– forward based on L’s Next Hop Label Forwarding Entry
NHLFE contains:
– next hop (output port, IP address of next LSR)


if next hop is the LSR itself then operation must be pop
for multicast there may be multiple next hops, and packet is replicated
– label stack operation to be performed
– any other info needed to forward (e.g. L2 format, how label is encoded)
ILM contains:
– a NHLFE for each incoming label
– possibly multiple NHLFEs for a label, but only one used per packet
2.1
Y(J)S MPLS Slide 45
LER Forwarding Algorithm
LER’s forwarding algorithm is more complex


check if packet is labeled or not
if labeled
– then forward as LSR
– else
[Cisco terminology LIB]
 lookup destination IP address in FEC-To-NHLFE Map
 if in FTN
– then prepend label
and forward using LSR algorithm
– else forward using IP forwarding

IP
router
pure IP link
LER
MPLS link
LSR
2.1
Y(J)S MPLS Slide 46
Penultimate Hop Popping
PH
I
E
IP link
CE
MPLS domain
the egress LER E also may have to work overtime:
–
–
–
–
–
read top label
lookup label in ILM
find that in NHLFE that the label must be popped
lookup IP address in IP routing
forward to CE using IP forwarding
we can save a lookup (and the first 3 steps) by performing PHP
but pay in loss of OAM capabilities
penultimate LSR PH performs the following:
–
–
–
–
read top label
lookup label in ILM
pop label revealing IP address of CE router
forward to CE using IP forwarding
2.1
Y(J)S MPLS Slide 47
Route Aggregation
net 1
1
IP link
12
13
31
IP link
net 2 2
22
32
E
IP link
3
net 3
23
MPLS domain
traffic from both network 1 and network 2 is destined for network 3
scalability advantages
– fewer labels
– conserve table memory
disadvantages
– IP forwarding may be required
– OAM backwards trail is destroyed
2.1
Y(J)S MPLS Slide 48
IP Router / ATM Switch
migration - important to be able to exploit existing forwarding hardware
we can use IP routers as LSRs
=
+
– already use the routing protocols for topology determination
– need to add label distribution protocol (or extend routing protocol)
– need to alter the forwarding algorithm
– can manage with software upgrade
but probably best to upgrade hardware too
=
+
we can use ATM switches as LSRs
– need to alter the routing protocols for topology determination
– need to add label distribution protocol
– already uses the forwarding algorithm
– probably can just upgrade software
2.1
Y(J)S MPLS Slide 49
ATM Cell Interleave
ATM switches
– have separate label space per input port
– segment traffic into ATM cells
what if the forwarding tables for both port 1and port 2 have the entry
incoming label 13 outgoing label 17 outgoing port
1 ?
13 data A1
13 data A2
A
17 data A1
2
13 data B2
B
B
17 data B1
1
13 data B1
ATM
LSR
1
2
17 data A2
ATM
LSR
17 data B2
2.1
Y(J)S MPLS Slide 50
VC/VP Merge
in order to properly reconstruct the packet we can use
VC-merge
buffer cells at the ATM LSR until end-of-packet detected
cells belonging to different packets aren’t interleaved
– introduces delay
– requires large memory
– requires ATM LSR to detect AAL5 end-of-packet
VP merge
use VPI as MPLS label
use VCI as multiplexing index
– limits number of available labels
2.1
Y(J)S MPLS Slide 51
Label Distribution Protocols
when LSR creates/removes a FEC - label binding
needs to inform other LSRs (“remote binding information”)
MPLS allows piggybacking label distribution on routing protocols
–
–
–
–
–
–
protocols already in use (don’t need to invent or deploy)
eliminates race conditions (when route or binding, but not both, defined)
ensures consistency between binding and routing information
only for distance vector or path vector routing protocols (not OSPF, IS-IS)
not all routing protocols are sufficiently extensible (RIP isn’t)
has been implemented for BGP-4
MPLS WG invented a new protocol LDP for “plain” label distribution
– messages sent reliably using TCP/IP
– messages encoded in TLVs
– discovery mechanism to find other LSRs
… and extended RSVP to LSPs for QoS
2.1
Y(J)S MPLS Slide 52
Control Mechanisms
pre-MPLS protocols used various control mechanisms
Example: label distribution
– Cisco and IBM - control driven
– Toshiba and Ipsilon - data (traffic) driven
MPLS is distinguished by its choice of control protocols
–
–
–
–
control driven
downstream binding
unsolicited and on-demand allowed
independent and ordered allowed
we will discuss these in the section on the control plane
2.1
Y(J)S MPLS Slide 53
MPLS RFCs
2547
2702
2917
3031
3032
3035
3036
3037
3038
3063
3107
3209
3210
3212
3213
3214
3215
(page 1 of 2)
BGP/MPLS VPNs
Requirements for Traffic Engineering Over MPLS
A Core MPLS IP VPN Architecture
Multiprotocol Label Switching Architecture
MPLS Label Stack Encoding
MPLS Using LDP and ATM VC Switching
LDP Specification
LDP Applicability
VCID Notification over ATM link for LDP
MPLS Loop Prevention Mechanism
Carrying Label Information in BGP-4
RSVP-TE: Extensions to RSVP for LSP Tunnels
AS for Extensions to RSVP for LSP-Tunnels
Constraint-Based LSP Setup using LDP
Applicability Statement for CR-LDP
LSP Modification Using CR-LDP
LDP State Machine
2.2
Y(J)S MPLS Slide 54
More MPLS RFCs
3270
3346
3353
3429
3443
3468
3469
3477
3496
3564
3478
3479
3480
MPLS Support of Differentiated Services
AS for Traffic Engineering with MPLS
Overview of IP Multicast in MPLS Environment
Assignment of the 'OAM Alert Label' for MPLS OAM functions
TTL Processing in MPLS Networks
The MPLS WG decision on MPLS signaling protocols
Framework for MPLS-based Recovery
Signalling Unnumbered Links in RSVP-TE
Support of ATM Service Class-aware MPLS Traffic Engineering
Support of DiffServ-aware MPLS Traffic Engineering
Graceful Restart Mechanism for LDP
Fault Tolerance for the LDP
Signalling Unnumbered Links in CR-LDP
2.2
Y(J)S MPLS Slide 55
Yet More MPLS RFCs
3612
3630
3809
3811
3812
3813
3814
3815
3916
3988
3985
4023
4026
4031
Applicability Statement for Restart Mechanisms for LDP
OSPF-TE
Generic Requirements for PPVPNs
Definitions of Textual Conventions for MPLS Management
MPLS Traffic Engineering Management Information Base
MPLS Label Switching Router (LSR) MIB
MPLS FEC-To-NHLFE MIB
Definitions of Managed Objects for LDP
Requirements for Pseudo-Wire Emulation Edge-to-Edge
Maximum Transmission Unit Signalling Extensions for LDP
PWE3 Architecture
Encapsulating MPLS in IP or GRE
PPVPN Terminology
Service requirements for Layer 3 PPVPNs
2.2
Y(J)S MPLS Slide 56
Even More MPLS RFCs
4023
4090
4105
4124
4125
4126
4127
4128
4182
4201
4206
4216
4220
4221
4247
4364
4368
4377
4378
4379
Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Requirements for Inter-Area MPLS Traffic Engineering
Protocol Extensions for Support of Diffserv-aware MPLS TE
Maximum Allocation BW Constraints Model for Diffserv-aware MPLS TE
Max Allocation w/ Reservation BW Constraints Model for Diffserv MPLS TE
Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS TE
Bandwidth Constraints Models for Diffserv-aware MPLS TE
Removing a Restriction on the use of MPLS Explicit NULL
Link Bundling in MPLS Traffic Engineering (TE)
Label Switched Paths (LSP) Hierarchy with GMPLS Traffic Engineering
MPLS Inter-AS TE Requirements
Traffic Engineering Link Management Information Base
Multiprotocol Label Switching (MPLS) Management Overview
Requirements for Header Compression over MPLS
BGP/MPLS IP VPNs (was 2547bis)
MPLS Label-Controlled ATM and FR Management Interface Definition
OAM Requirements for MPLS Networks
A Framework for MPLS OAM
2.2
Detecting MPLS Data Plane Failures
Y(J)S MPLS Slide 57
MFA forum IAs
1.0
Voice over MPLS IA
2.0
MPLS-PVC UNI IA
3.0
LDP Conformance IA
4.0
TDM Transport over MPLS using AAL1 IA
5.0
I.366.2 Voice Trunking over MPLS IA
6.0.0
MPLS Proxy Admission Control
7.0.0
MPLS UNI protocol
8.0.0
TDM over MPLS using Raw Encapsulation
2.2
Y(J)S MPLS Slide 58
ITU-T Recommendations
Y.1411
ATM-MPLS network interworking - Cell mode user plane interworking
Y.1412 ATM-MPLS network interworking - Frame mode user plane interworking
Y.1413 TDM-MPLS network interworking – User plane interworking
Y.1414 Voice services - MPLS network interworking
Y.1415 Ethernet-MPLS network interworking – User plane interworking
Y.1710 Requirements for OAM functionality for MPLS networks
Y.1711
Operation & Maintenance mechanism for MPLS networks
Y.1712 User-plane fault-management for ATM and MPLS OAM
Y.1713 Misbranching detection for MPLS networks
Y.1720 Protection switching for MPLS networks
X.84
FR over MPLS core networks
G.8110/Y.1370 MPLS Layer Network architecture
2.2
Y(J)S MPLS Slide 59
control plane
user (data) plane
MPLS Control Component
3.1 Procedures and scenarios
3.2 Label distribution protocols
3.3 LDP and BGP-4 details
Y(J)S MPLS Slide 60
Control and User Planes
topology determination
use standard IP routing protocols
BGP, OSPF, IS-IS, PIM
label distribution
control plane
piggyback on routing protocol
use LDP, RSVP-TE
forwarding paradigm
label-stack CO forwarding
user (data) plane
3.1
Y(J)S MPLS Slide 61
What is Needed ?
control plane




all IP routing protocols (BGP,OSPF,PIM,etc)
procedure to bind label to FEC (label assignment)
protocol to distribute label binding information
procedure to create forwarding table
user (data) plane


procedure to label incoming packet
forwarding procedure
– forwarding table lookup
– label stack operations
3.1
Y(J)S MPLS Slide 62
All the Tables
FEC table
FEC
protocol
input port
handling
192.115/16
IPv4
2
best-effort
Free Labels 128-200 presently free
FTN
ILM
NHLFE
FEC
port/label in
port/label out
192.115/16
2/17
3/137
port/label in
port/label out
next hop
operation
2/17
3/137
5.4.3.2
swap
3.1
Y(J)S MPLS Slide 63
LER Architecture
control plane
IP routing protocols
IP
routing
table
IP routers
label binding and
distribution protocols
free label table
LSRs
user (data) plane
FTN
IP
forwarding
table
labeling procedure
egress LER
MPLS
forwarding
table
3.1
Y(J)S MPLS Slide 64
Binding & Distribution Options
label binding (assignment)
– per port or per LSR label space
– control driven vs. data driven (traffic driven)
– liberal vs. conservative label retention
label distribution (advertisement)
– downstream vs. upstream
– downstream on-demand (dod) vs. downstream unsolicited (du)
– independent vs. ordered
3.1
Y(J)S MPLS Slide 65
Per Port Label Space
LSR may have a separate label space for each input port (I/F)
or a single common label space
or any combination of the two
separate labels spaces means separate forwarding tables per port
ATM LSR have per port label spaces (leads to interleave problem)
per port label spaces increases number of available labels
common label space facilitates several MPLS mechanisms (e.g. reroute)
3.1
Y(J)S MPLS Slide 66
Control vs. Data Driven
there are two philosophies as to when to create a binding
data-driven (traffic-driven) binding (Toshiba CSR, Ipsilon IP-Switching)
automatically create binding when data packets arrive
(from first packet?, after enough packets? when tear LSP down?)
control-driven binding
(Cisco Tag Switching, IBM ARIS)
create binding when routing updates arrive
(only update when topology changes? update upon request?)
although not specifically stated in the architecture document
MPLS assumes control driven binding *
* two implementations of control driven:
– topology-driven (routing tables are consulted)
– control-traffic driven (only routing update messages are used)
3.1
Y(J)S MPLS Slide 67
Liberal vs. Conservative Retention
LSR receives “advertisements” (label distribution messages) from other LSRs
conservative label retention:
LSR retains only label-to-FEC bindings that are presently needed
liberal label retention
LSR stores all bindings received (more labels need to be maintained)
using liberal retention can speed response to topology changes
LSRs must agree upon mode to be used
A advertises label
B is previous hop LSR
but C retains label anyway
later routing change makes C the previous hop
C immediately can start forwarding
B
A
C
3.1
Y(J)S MPLS Slide 68
Downstream vs. Upstream
downstream
binding means to allocate a label to a FEC
local binding - LSR allocates the label from “free label” pool
remote binding - LSR that receives the label
which LSR allocates ?
MPLS uses downstream binding
label allocated by LSR downstream from the LSR that prepends it
label distribution information flows upstream
reverse in direction from data packets
to set up LSP through link from LSR A to LSR B
LSR B binds label 13 to FEC
B advertises label to LSR A
LSR A sends packets with label 13 to B
label 13
A
13
B
3.1
Y(J)S MPLS Slide 69
On-demand vs. Unsolicited
downstream on-demand label distribution:
LSRs may explicitly request a label
from its downstream LSR
unsolicited label distribution:
LSR distributes binding to upstream LSR w/o a request
(e.g. based on time interval, or upon receipt of topology change)
LSR may support on-demand, unsolicited, or both
adjacent LSRs must agree upon which mode to be used
LSR A needs to send a packet to LSR B
LSR A requests a label from LSR B
B binds label 13 to the FEC
B distributes the label
A starts sending data with label 13
I need a label
I allocated 13
A
13
data
B
3.1
Y(J)S MPLS Slide 70
Independent vs. Ordered
independent binding (Tag Switching)
– each LSR makes independent decision to bind and distribute
ordered binding (ARIS)
 egress LSR binds first and distributes binding to neighbors
 LSR that believes that it should be the penultimate LSR
binds and distributes to its neighbors
 binding proceeds in orderly fashion until ingress LSR is reached
LSRs must agree upon mode to be used
B sees that it is egress LSR for 192.115.6
B allocates label 13
B distributes label to C and D
C distributes label to E
13
D
192.115/16
B
E
C
13
A
3.1
Y(J)S MPLS Slide 71
LDP tasks
a label distribution protocol is a signaling protocol
that can perform the following tasks:

discover LSR peers

initiate and maintain LDP session

signal label request

advertise binding

signal label withdrawal

loop prevention

explicit routing

resource reservation
3.2
Y(J)S MPLS Slide 72
Label Distribution Protocols
label distribution can be carried over various protocols
There are presently four options:

LDP
– MPLS-enhanced IP networks

BGP4-MPLS
– RFC 2547 VPNs

RSVP-TE
– traffic engineering support

CR-LDP
– constraint based (no longer recommended by IETF)
3.2
Y(J)S MPLS Slide 73
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
3.2
Y(J)S MPLS Slide 74
LDP
major focus of the IETF MPLS WG was the design of LDP
based on similar TDP from Cisco
LDP sets up a bidirectional LDP session
both sides can request or advertise labels
LDP usually uses TCP
–
–
–
–
–
needs reliable transport (e.g. what happens if miss a binding)
needs in-order delivery (e.g. binding+withdrawal)
hard to develop new reliable transport protocols
single acknowledgement timer for session
piggybacking ACK on data packets
Use UDP for discovery (hello) messages
periodic keepalive messages (if not received, session terminated)
messages encoded in TLV (Type Length Value) form
3.2
Y(J)S MPLS Slide 75
LDP Setup
Hello (UDP)
Discovery
Hello (UDP)
Initialization (TCP)
Session
Initialization (TCP)
Label Request (TCP)
Distribution
Label Distribution (TCP)
3.2
Y(J)S MPLS Slide 76
Discovery Phase

LSR periodically multicast transmits hello to “LDP discovery” UDP port
– to “all routers on subnet” multicast group
– to preconfigured IP address (when not all LSRs on same subnet)
(extended discovery) “targeted LDP”

LSRs listen on this UDP port for hello messages

Hello message contains:
– hold time
– LSR Identifier

when LSR receives Hello from another LSR
– it opens a TCP connection to that other LSR (if needed)
or (for extended discovery)
– it unicast transmits a hello back to the other LSR
LDP session can now be established

3.2
Y(J)S MPLS Slide 77
Session Initialization

The LSR with higher identifier sends (TCP)
a session initialization message to the other LSR

session initialization message contains:
–
–
–
–

LDP Protocol version
label distribution and control method
timer values
label space ranges (not any more !)
if receiving LSR accepts these parameters
then it transmits a KeepAlive
else it transmits a reject
3.2
Y(J)S MPLS Slide 78
Distribution Messages

label mapping
– downstream LSR advertisement of a label mapping for a FEC
two FEC types: host address, IP address prefix

label withdrawal
– reverse of mapping message
– downstream LSR informs upstream LSR
that it has revoked a previous binding
– upstream LSR can not longer use the label

label release
– upstream LSR informs downstream LSR
that it no longer needs a binding
– typically when downstream is no longer next hop
and operating in conservative retention mode
3.2
Y(J)S MPLS Slide 79
Request Messages
in downstream-on-demand mode upstream LSR must request binding
upstream LSR sends label request message when:
– FEC in FEC table
next hop LSR is LDP peer
FEC not in forwarding table
– FEC next hop changes
upstream LSR doesn’t have a mapping from new next hop
– receives FEC label request from upstream LDP peer
next hop LSR is LDP peer
upstream LSR doesn’t have a mapping from next hop
upstream LSR sends label request abort message when:
– upstream LSR needs to revoke request before satisfied
for example, next hop LSR for FEC has changed
3.2
Y(J)S MPLS Slide 80
Notifications
There are two types of notifications:
– error notifications (fatal errors - terminate session)
– advisory notifications (status messages)
LSR sends notification messages when:
– received LDP message with unsupported protocol version
– received LDP message with unknown type
– KeepAlive timer expired
– session initialization fails due to unacceptable parameters
– etc.
3.2
Y(J)S MPLS Slide 81
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 MPLS Slide 82
LDP packet format
header (10B)
version
(2B)
length
(2B)
LDP-ID
(6B)
message TLVs
(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)
message TLVs – zero or more message TLVs (see next page)
3.3
Y(J)S MPLS Slide 83
LDP message TLVs
type
U
(15b)
length
(2B)
message-ID
(4B)
mandatory
parameter
TLVs
(variable)
optional
parameter
TLVs
(variable)
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
3.3
Y(J)S MPLS Slide 84
All LDP message types
Hello (0x0100)
Initialization (0x0200)
KeepAlive (0x0201)
Notification (0x0001)
Address (0x0300)
Address Withdraw (0x0301)
Label Mapping (0x0400)
Label Withdraw (0x0402)
Label Request (0x0401)
Label Release (0x0403)
Label Abort Request (0x0404)
3.3
Y(J)S MPLS Slide 85
LDP parameter TLVs
U F
type
(14b)
length
(2B)
value
U – unknown message bit
if message type unknown to receiver:
U=0 – receiver returns notification to sender
U=1 – receiver silently ignores
F – forward unknown message bit
if U=1 and message type unknown to receiver
F=0 – do not forward
F=1 – forward
type - TLV type (FEC TLV, label TLV, address list TLV, hop count TLV,
path vector TLV, status TLV )
length - length of value field in bytes
3.3
Y(J)S MPLS Slide 86
FEC TLV
type (2B)
U=0 F=0 type=0x0100
length (2B)
FEC element 1
…
there may be more than one FEC element for mapping messages only
the FEC elements are not themselves TLVs (no length needed), instead
– wildcard FEC (0x01)
– prefix FEC (0x02) + address family (IPv4, IPv6, Ethernet, E.164, etc.) +
prefix length in bits + prefix
– host address FEC (0x03) + address family + length + address
3.3
Y(J)S MPLS Slide 87
Generic Label TLV
type (2B)
U=0 F=0 type=0x0200
length (2B)
label (20 bits)
this is the generic label TLV
there are also special label TLVs for ATM and FR based MPLS
3.3
Y(J)S MPLS Slide 88
Status TLV
type (2B)
U F type=0x0300
E F
length (2B)
status code data (30b)
message ID (32b)
message type (16b)
Status TLVs : mandatory parameters in notification messages
optional parameters in other messages
U=0 when status in notification message, else U=1
E - fatal error bit E=1 for fatal error E=0 for advisory notification
the two F bits are equal and have the normal meaning
status code data = 0 means success
message ID - the message to which the status refers
message type - the message type to which the status refers
3.3
Y(J)S MPLS Slide 89
Example full message label mapping
mapping message length=24
U=0 type = 0x0400
(2B)
FEC TLV (2B)
U=0 F=0 type=0x0100
message-ID
(4B)
length=8 (2B)
prefix FEC element (8B)
type = 0x02 family=1(IPv4) prefix-length=16 prefix=192.115/16
label TLV (2B)
U=0 F=0 type=0x0200
length=4 (2B)
label = 17
3.3
Y(J)S MPLS Slide 90
BGP4 Label Distribution
BGP peers exchange VPN routes
can easily associate a label with these routes
all BGP procedures are immediately available for use
for label distribution messages
BGP4 is a very extensible protocol
– multiprotocol extensions support address families
(originally for IPv4,IPv6, etc)
– MPLS defines a new address family
3.3
Y(J)S MPLS Slide 91
BGP
header (19B)
marker
(16B)
length
(2B)
marker can be used for authentication
type
(1B)
data
(variable)
(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
3.3
Y(J)S MPLS Slide 92
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
3.3
Y(J)S MPLS Slide 93
BGP OPEN
version
(1B)
my AS
(2B)
hold time
(2B)
BGP-ID
(2B)
op len
(1B)
opt parameters
(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
3.3
Y(J)S MPLS Slide 94
BGP UPDATE
WR len withdrawn
routes
(2B)
(var)
PA len
(2B)
path
attributes
(var)
Withdrawn Routes – list of routes no longer to be used
NLRI
(var)
(NLRI format- see below)
Path Attributes – route specific information (see next page)
Network Layer Reachability Information – (classless) routing information
len
(1B)
prefix
(variable)
the NLRI is a list of address-prefixes
each prefix must be masked from the left to the length specified
3.3
Y(J)S MPLS Slide 95
BGP UPDATE - Path Attributes
flags
(1B)
type code
(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
L – attribute length bit
(for optional transitive attributes only)
(=0 attribute length is 1B, =1 length is 2B)
type code
ORIGIN, AS_PATH, NEXT_HOP, MED, LOCAL_PREF,
3.3
AGGREGATOR, COMMUNITY, ORIGINATOR_ID…
Y(J)S MPLS Slide 96
BGP NOTIFICATON
error
code
(1B)
error
subcode
(2B)
data
(var)
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
3.3
Y(J)S MPLS Slide 97
D
A
G
C
B
E
F
MPLS Traffic Engineering
4.1 Introduction to Traffic Engineering
4.2 DiffServ and IntServ
4.3 TE protocols
Y(J)S MPLS Slide 98
Traffic Engineering
TE is control of network traffic to achieve specific objectives
unfortunately users and providers have contradictory objectives
user objectives (QoS)
–
–
–
–
–
–
network availability
packet loss
end-to-end delay
round-trip delay
packet delay variation (PDV)
error rate
provider objectives (performance)
–
–
–
–
–
bandwidth utilization
resource utilization
speed of failure recovery
ease of management
monetary outlay
Y(J)S MPLS
4.1
Slide
c99
Network and Traffic Engineering
Network Engineering
putting the bandwidth where the traffic is
– physical cable deployment (thick pipes)
– over-provisioning
– virtual connection provisioning
– violates providers objectives
Traffic Engineering
putting the traffic where the bandwidth is
– explicit traffic routing
– route optimization
– can it meet user objectives?
4.1
Y(J)S MPLS Slide 100
IP’s Problem
A
D
1
G
C
B
0.5
E
traffic from A to G 1Gb
traffic from B to G 500Mb
all links 1Gb except EF 500 Mb
F
were C,D,E, and F ATM switches there would be no problem
(1Gb over ACDG, 500Mb over BCEFG)
with standard hop-count cost function, all traffic over CDG
resulting in 1.5Gb there (congestion) and CEFG idle
with administrative cost on CDG we can force all the traffic to CEFG
even worse congestion !
finally with administrative cost and ECMP we can load balance
750 Mb over CDG and CEFG, link EF is still congested !
what can we do?
4.1
Y(J)S MPLS Slide 101
Solution
IP’s problem arises from
– the forwarding being purely local
– but the routing being too global
IP routing always optimizes a global (usually additive) metric
discrete optimization problem
does not take local constraints (e.g. BW of individual links) into account
we need to optimize a global metric
while taking local constraints into account
this is called constraint-based routing
discrete optimization with inequality constraints
main constraint is BW, but also maximum delay, packet loss, etc.
another constraint: explicit include/exclude links/routers
4.1
Y(J)S MPLS Slide 102
MPLS TE
MPLS that we have seen so far allows explicit routing
– can minimize number of hops
– can tailor LSP to needs
MPLS-TE LSPs can be setup according to constraints
– only include in LSP LSR with sufficient available BW
– only include in LSP LSR that guarantees sufficiently low delay
traffic engineering achieved by extending base protocols

enhanced routing protocols (resource reservation)
– OSPF  OSPF-TE
– ISIS  ISIS-TE

constraint-based signalling protocols (pinned LSPs and reservation)
– RSVP  RSVP-TE
– LDP  CR-LDP (no longer under active development)
4.1
Y(J)S MPLS Slide 103
IP Fixes
two approaches to QoS were developed for IP (never popular)
IntServ (guaranteed QoS)
–
–
–
–
define traffic flows (CO approach)
guarantee QoS attributes for each flow
reserve resources at each router along the flow
signaling protocol (RSVP) needed
DiffServ (statistical QoS)
–
–
–
–
–
retain CL paradigm
no guaranteed QoS attributes
classify packets (differentiated)
offer special treatment (priority) relative to other packets
no resource reservation
4.2
Y(J)S MPLS Slide 104
DiffServ
DIffServ was developed in IETF after IntServ
RFCs 2474, 2475
IntServ too heavy-weight (and too revolutionary) for most purposes
resource reservation is against IP-philosophy
if not enough BW, then more democratic for all to suffer
if reserve BW and don’t use, then this is simply over-provisioning
DiffServ is evolutionary “coarse-grained” approach to IP QoS
DiffServ
– divides traffic into service classes
 and allocates resources on a per-class basis
– uses 6 bits of ToS byte in IP header to mark packets
 field is renamed Differentiated Services Code Point
 no setup or router state required
– DSCP defines per-hop behaviors (PHB)
 tells router how to treat packet
– three standard PHBs (BE, AF, EF)
4.2
Y(J)S MPLS Slide 105
DiffServ PHBs
Best Effort
– standard IP service
– QoS depends on momentary network load
Assured Forwarding
– AF specifies class that determines queue
– in addition, three drop-precedence levels (low, med, high)
– AF packets from a single source should not be mis-ordered
even if have different drop-precedence (i.e. single queue)
Expedite Forwarding
– EF packet should experience no queuing delays
– EF packets should have low loss
– implemented by dedicated EF router queue
4.2
Y(J)S MPLS Slide 106
MPLS and DiffServ
what does all this have to do with MPLS ?
MPLS will have to co-exist with DiffServ IP
MPLS provides similar functionality
Exp bits in MPLS shim header are similar to DSCPs
– only three bits (8 classes) while DiffServ ended up with 6 bits
– but 8 service classes is usually more than enough
commonly 4 classes are offered (bronze, silver, gold, platinum)
LSR can maintain mapping from Exp to PHB
e.g. Exp=000 for BE, Exp=001 for AF low drop precedence, etc
no new signaling mechanism required
LSP with Exp mapping to PHB is called an E-LSP
ingress LER assigns the EXP field
4.2
Y(J)S MPLS Slide 107
L-LSP vs. E-LSP
with DiffServ each FEC is defined by
– destination address
– service class
there are two ways of implementing the DiffServ mapping
L-LSP (Labeled-inferred LSP)
–
–
–
–
behavior based on label alone
support different service classes by using different labels
LSP BW allocated from specific queue (class)
Exp may be used for drop precedence
E-LSP (Exp-inferred LSP)
BW %
L-LSP
L-LSP
L-LSP
– behavior based on label + Exp field
– LSP BW allocated from link
– can support 8 different service classes per label
4.2
Y(J)S MPLS Slide 108
IntServ
RFCs 2205-2216, 2379-2382
IntServ is an overall QoS architecture (not just RSVP)
IntServ is a radical departure from pure IP
and requires IntServ-enabled routers
IntServ
– enables providing end-to-end QoS guarantees
 for services that need them
– defines flows (introduces CO to IP’s CL architecture)
 flows are classified into three service classes (BE,CLS,GS)
– specifies admission control and policing
– like all CO architectures, requires signaling protocol (RSVP)
IntServ-enabled routers
– reserve needed resources along the flow’s path
– routers must retain state
4.2
Y(J)S MPLS Slide 109
IntServ CoS
Best Effort
–
–
standard IP service
QoS depends on momentary network load
Controlled Load Service
–
–
–
–
service equivalent to unloaded network
low packet loss
most packets will experience delay close to minimum
no quantitative guarantees
Guaranteed Service
–
–
–
bounded worst case delay (no PDV guarantee)
low packet loss (zero if node buffers correctly provisioned)
quantitative guarantees
4.2
Y(J)S MPLS Slide 110
RSVP
RSVP
primary signaling protocol for IntServ
runs over raw IP or UDP/IP
does not setup path, uses path setup by routing protocols
sessions identified by source and destination socket numbers
requests unidirectional QoS characteristics from network
causes routers along path to reserve link and node resources
network responds with success/failure
routers maintain soft-state, reservations time-out unless refreshed
two main message types: PATH and RESV
4.2
Y(J)S MPLS Slide 111
RSVP Messages
receivers
sender
PATH
– message from sender to receiver(s)
– carries classification info and TSpecs
RESV
– response of receiver to PATH message
– carries session ID and RSpec specifying QoS required
– this is the actual request for resource reservation
4.2
Y(J)S MPLS Slide 112
MPLS and IntServ
what does all this have to do with MPLS ?
MPLS extension of RSVP : RSVP-TE (RFC 3209)
can be used as a label distribution protocol
for downstream-on-demand binding
create and distribute bindings between RSVP flows and labels
Note: requests by LSRs and hosts (RSVP only by hosts)
uses label instead of source and destination socket numbers
extends RSVP by adding new objects (e.g. label) and procedures
allows strict/loose explicitly routed LSPs
like LDP there is peer discovery, label requests, binding messages
QoS and traffic parameters are carried transparently
4.2
Y(J)S MPLS Slide 113
CR-LDP
RSVP-TE is not the only way of setting up a LSP for TE
Constraint-based Routing LDP (CR-LDP) extends LDP
basic LDP lacks
– explicit routing
– resource reservation
so CR-LDP adds
– explicit route object, carried as TLV in label request
– traffic parameter object
 peak/committed data rate
 peak/committed burst sizes
 etc.
and since we are already extending the basic protocol …
– path pre-emption priority
– path re-optimization (with pinning option)
– LSP setup failure notification
– automatic LSP failure recovery policies
– etc.
4.3
Y(J)S MPLS Slide 114
Setup Procedures
Example setup ingress
with explicit routes
CR-LDP:
egress
A
B
C

A reserves resources, sends label request w/ explicit route BC & resource req.s

B reserves resources and sends label request w/ explicit route C & resource req.s

C reserves resources, locally binds label and sends label mapping to B

B matches mapping to previous request, remotely binds, sends label mapping to A

A remotely binds label
RSVP-TE:

A sends PATH message to B w/ explicit route BC and resource requirements

B forwards PATH message to C after changing explicit route to C

C determines required resources, reserves, locally binds label and sends RESV to B

B matches, reserves resources, remotely binds, and sends RESV to A

A matches, remotely binds label and reserves resources
4.3
Y(J)S MPLS Slide 115
RSVP-TE/CR-LDP Comparison
1/2
CR-LDP extends an MPLS label distribution protocol
adding explicit route and resource reservation features
RSVP-TE extends a pure IP resource reservation protocol to MPLS
requires running two protocols
both distribute binding information
both support explicit routing, pinning, and resource reservation
CR-LDP uses TCP (reliable)
message order is guaranteed
lost packet delays all processing
RSVP-TE uses IP (in core) or UDP/IP (unreliable)
needs refreshes for reliability
RSVP-TE supported by Cisco and Juniper, and selected by IETF
CR-LDP supported by Nortel and Nokia, was favorite of ITU-T
4.3
Y(J)S MPLS Slide 116
RSVP-TE/CR-LDP Comparison
2/2
CR-LDP is hard-state
RSVP-TE is soft-state
– automatically tracks changes
– needs refresh overhead (can be reduced by bundling)
both use ordered binding from egress to ingress
after first traversing from ingress to egress
but CR-LDP reserves resources in forward direction
RSVP-TE reserves in backward direction
RSVP-TE uses standard IntServ QoS model (TSpec/RSpec)
CR-LDP uses its own QoS model (traffic parameters)
CR-LDP may be vulnerable to TCP DoS attacks
RSVP-TE specifies authentication control
4.3
Y(J)S MPLS Slide 117
OSPF-TE and IS-IS-TE
constraint-based routing needs link attribute information
most important - available BW
link-state protocols have mechanisms to flood link-up/link-down
to every router in the domain
piggyback attribute as TLV on link-up/link-down messages
– OSPF add to Link-State Advertisement (LSA) (RFC 3630)
– IS-IS add to Link-State Packets
once router receives attribute information it can reserve resource
when attribute information changes need to reflood
but every allocation changes attributes!
to decrease overhead:
 only flood when change passes threshold
 inherent timing bounds
4.3
Y(J)S MPLS Slide 118
MPLS Applications
5.1 L3 VPNs
5.2 L2 VPNs
5.3 PWE3
Y(J)S MPLS Slide 119
2547bis (RFC 4364) VPNs
CE not peer to CE
CE peer to PE
C
C
C
CE
C
PE
P
P
PE
C
CE
C
CE is IP router
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 in BGP
PE prepends 8B Route Distinguisher (unique to site) to IP address 5.1
Y(J)S MPLS Slide 120
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
5.1
Y(J)S MPLS Slide 121
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)
5.1
Y(J)S MPLS Slide 122
L2VPN - VPWS
CE
AC
PE
PE
AC
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.)
5.2
Y(J)S MPLS Slide 123
L2VPN - 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
5.2
Y(J)S MPLS Slide 124
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, but
no STP)
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
5.2
Y(J)S MPLS Slide 125
Pseudowire Emulation
This is a special case of
“Pseudowire Emulation Edge to Edge”, or PWE3
Packet
Switched
Network
Customer
Edge
(CE)
Customer
Edge
(CE)
Customer
Edge
(CE)
Customer
Edge
(PSN)
Provider
Edge
Provider
Edge
(CE)
(PE)
(PE)
Customer
Edge
native
service
PseudoWires
(PWs)
[tunnels]
native
service
(CE)
5.3
Y(J)S MPLS Slide 126
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)
PSNs
 IPv4
 IPv6
 MPLS
 L2TPv3
5.3
Y(J)S MPLS Slide 127
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
– framework, requirements, architecture documents
– service specific encapsulation documents for each native service
5.3
Y(J)S MPLS Slide 128
Why MPLS for PWE3 ?
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 connection multiplexing method
–
–
–
–
–
Dictionary:
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)
ATM-f
ITU-T
IETF
inner label
outer label(s)
interworking label transport label(s)
PW label
tunnel label(s)
5.3
Y(J)S MPLS Slide 129
PWE packet format
outer
label
inner
label
control
word
Payload
• inner and outer labels specify forwarding and multiplexing
• outer label is standard MPLS stack
• inner label contains PW label
• control word
• enables detection of out-of-order and lost packets
• flags may indicate critical alarm conditions (TDM PWs)
• PW PID nibble
5.3
Y(J)S MPLS Slide 130