Transcript TDMoIP : IPR

MPLS
PWE3
VPLS
Yaakov (J) Stein
Feb 2010
Chief Scientist
RAD Data Communications
Course Outline
Forwarding and routing
2. Problems with IP routing
3. Label Switching
4. MPLS
5. LDP
6. Pseudowires
7. ATM PWs
8. TDM PWs
9. Ethernet PWs
10. VPLS (L2VPN)
11. MPLS-TP
1.
Y(J)S MPV
2
1
2
3
4
5
1
2
3
4
5
Forwarding and Routing
Y(J)S MPV
3
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)
Y(J)S MPV
4
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
Y(J)S MPV
5
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
Y(J)S MPV
6
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
Y(J)S MPV
7
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
Y(J)S MPV
8
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
Y(J)S MPV
9
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
Y(J)S MPV
10
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)
Y(J)S MPV
11
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
Y(J)S MPV
12
Problems with IP Routing
Y(J)S MPV
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

Y(J)S MPV
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
Y(J)S MPV
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!
Y(J)S MPV
16
Load Balancing
“fish diagram”
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 Equal Cost MultiPath (ECMP)
750 Mb over CDG and CEFG, link EF is still congested !
solution requires traffic engineering
Y(J)S MPV
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 (IntServ not 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
Y(J)S MPV
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
Y(J)S MPV
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)
Y(J)S MPV
20
higher layers
layer 3 (e.g. IP)
label switching (layer 2.5)
shim header
layer 2 (e.g. Ethernet)
physical layer
Label Switching
Y(J)S MPV
21
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
Y(J)S MPV
22
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
Y(J)S MPV
23
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
Y(J)S MPV
24
Forwarding Equivalence Class
equivalence class - set of elements 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)
Y(J)S MPV
25
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
Y(J)S MPV
26
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)
Y(J)S MPV
27
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 space may be
– per platform (unique to LSR) or
– per port (unique to input interface - like ATM)
LSRs optionally support 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 other LSR looks at the L3 headers/address
Y(J)S MPV
28
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)
Y(J)S MPV
29
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
Y(J)S MPV
30
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
Y(J)S MPV
31
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)
Y(J)S MPV
32
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
Y(J)S MPV
33
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
Y(J)S MPV
34
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
Y(J)S MPV
35
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 header
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
Y(J)S MPV
36
Label (20b)
TC(3b) S(1b)
TTL (8b)
MPLS
Y(J)S MPV
37
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 2001-
Y(J)S MPV
38
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)
Y(J)S MPV
39
Multiprotocol Label Switching
IPv4
IPv6
IPX
etc.
frame-relay
etc.
MPLS
Ethernet
ATM
Y(J)S MPV
40
MPLS Shim Header
Label (20b)
TC(3b) S(1b)
TTL (8b)
when a shim header is needed, its format should be:
Label there are 220 different labels (+ 220 multicast labels)
Traffic Class (ex-EXP)
was CoS in Cisco Tag Switching
could influence packet queuing
Stack bit S=1 indicates bottom of label stack
TTL decrementing hop count
used to eliminate infinite routing loops
generally copied from/to IP TTL field
Special (reserved) labels
0 IPv4 explicit null
1 router alert
2 IPv6 explicit null
3 implicit null
13 MPLS-TP GAL
S=0
top label
S=0
another label
S=0
yet another label
S=1
bottom label
Y(J)S MPV
41
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
Y(J)S MPV
42
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
Y(J)S MPV
43
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
Y(J)S MPV
44
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
Y(J)S MPV
45
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
Y(J)S MPV
46
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 - RSVP-TE
Y(J)S MPV
47
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
–
–
–
–
–
downstream binding
control driven
unsolicited and on-demand allowed
independent and ordered allowed
conservative and liberal label retention allowed
Y(J)S MPV
48
version
(2B)
length
(2B)
LDP-ID
(6B)
message TLVs
(variable)
LDP
Y(J)S MPV
49
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) format
Y(J)S MPV
50
LDP stages
Hello (UDP)
Discovery
Hello (UDP)
Initialization (TCP)
Session
Initialization (TCP)
Label Request (TCP)
Distribution
Label Distribution (TCP)
Y(J)S MPV
51
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

Y(J)S MPV
52
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
Y(J)S MPV
53
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
Y(J)S MPV
54
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
Y(J)S MPV
55
Notifications
There are two types of notifications:
– error notifications (fatal errors - terminate session)
– advisory notifications (status messages)
LSR sends error 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.
Y(J)S MPV
56
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
Y(J)S MPV
57
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)
Y(J)S MPV
58
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
Parameters are themselves encoded as (sub)TLVs
Y(J)S MPV
59
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 MPV
60
LDP parameter (sub)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 MPV
61
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 MPV
62
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 MPV
63
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 MPV
64
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 MPV
65
CE
CE
ACs
CE
PE
ACs
PE
CE
CE
CE
Pseudowires
Y(J)S MPV
66
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
Enables exploitation of a single converged network (reduced OPEX)
PWs are bidirectional (unlike MPLS LSPs)
PW architecture is an extension of VPN architecture
Y(J)S MPV
67
Pseudowire Emulation
Edge to Edge
PWE3
Customer
Edge
provider’s
PSN
(CE)
Customer
Edge
(CE)
Customer
Edge
(CE)
Customer
Edge
Provider
Edge
Provider
Edge
(CE)
(PE)
(PE)
Customer
Edge
native
service
Pseudowires
(PWs)
native
service
(CE)
Y(J)S MPV
68
Provider Network Architecture
provider network is composed of:
• Provider routers (P routers)
• Provider edge routers (PE routers)
P
router
P
router
native
service
PE
router
P
router
A tunnel may
contain
many PWs
PE
router
native
service
P
router
Y(J)S MPV
69
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 MPV
70
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 MPV
71
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
–
–
–
–
–
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)
MPLS-f inner label
outer label(s)
ITU-T interworking label transport label(s)
IETF
PW label
tunnel label(s)
Y(J)S MPV
72
Simple MPLS solution
CE
CE
ACs
CE
PE
P
CE
P
PE
ACs
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 MPV
73
(Martini) Pseudowires
CE
CE
transport tunnel
ACs
CE
PE
ACs
PE
CE
CE
CE
PWs are bidirectional
transport MPLS tunnel set up between PEs
multiple PWs may be set up inside tunnel
MPLS (tunnel) label
PW (inner) label
payload
Native packet/frame encapsulated with 2 labels
P-routers are unaware of individual customer networks
Y(J)S MPV
74
PWE packet format
PSN / multiplexing
optional RTP header
optional control word (CW)
higher layers
payload
Y(J)S MPV
75
Example formats
MPLS PSN
tunnel
label(s)
PW
label
control
word
Payload
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 MPV
76
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 encapsulations 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 MPV
77
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

based on LDP
–
–
–
–
PE
P
P
P
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
Y(J)S MPV
78
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 MPV
79
Associated Channel
PWs have an associated channel for OAM, etc.
Main use is for VCCV
VC (old name for PW) connectivity verification
runs inside PW (same PW label) so that fate shares
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 MPV
80
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 MPV
81
ATM PWs
Y(J)S MPV
82
ATM
ATM is a universal communications technology
Data is sent in 53-byte cells = 5-byte header + 48 byte payload
Each cell is identified (addressed) by


Virtual Path Identifier (12b)
Virtual Channel Identifier (16b)
Cell header also contains



Cell Loss Priority (discard more probable if CLP=1)
Payload Type (user/OAM/resource management/congestion experienced)
Header Error Correction
VPI
VPI
VCI
VCI
VCI
PT
HEC
CLP
Y(J)S MPV
83
ATM Adaptation Layers
Client data (SDU) can be transported by ATM (PDU) using
 AAL1 (CBR)
 AAL2 (VBR)
 AAL5 (packet data)
AAL1 : each cell contains a segment of CBR (TDM) (SAR operation)



3 modes (unstructured, structured, structured with CAS)
1 or 2 byte header (with sequence numbers, etc.)
47 (or 46) bytes left for payload
AAL2 : each cell has 3-byte header (Channel ID, length, HEC)

1-45/64 bytes left for payload
AAL5 : client packet (SDU) divided into sequence of cells


8-byte trailer added (User-User indication, length, CRC)
padding added before trailer to make PDU multiple of 48 bytes
Y(J)S MPV
84
Types of ATM PWs

N:1 (Martini)
– control word optional
– remove HEC to form 52-byte cells
– pack 1 or more cells into MPLS packet (may mix VPI/VCI)

1:1 (ATM forum mode)
– special 3-byte control word required
– 1-byte header for each cell
– pack 1 or more cells into MPLS packet
– may mix VCI for given VPI (but then need to insert VCI)

SDU (for AAL5 only)
– control word with 4 flags required (SN optional)
– payload is the complete SDU (no trailer)

PDU (for AAL5 only)
– special 3-byte control word required
– 1-byte header after CW
– payload is N*48-byte PDU

port mode (Malis draft) - format same as N:1
Y(J)S MPV
85
headers
TDM payload
TDM PWs
Y(J)S MPV
86
What is TDM ?
TDM is a synchronous transport at


one of the PDH (G.702) rates
one of the SDH (G.707) rates
TDM networks are often used to carry telephony traffic
Native TDM networks





circuit switching ensures signal integrity
very high reliability (“five nines”)
low delay and no noticeable echo
timing information transported over the network
mature signaling protocols (over 3000 features)
Y(J)S MPV
87
PDH rates
level
0
64 kbps
*
1
E1 2.048 Mbps
*
2
3
E3
4
4
E4 139.264 Mbps
CEPT
24
T1 1.544 Mbps
*
4
T2 6.312 Mbps
4
34.368 Mbps
*
*
4
E2 8.448 Mbps
*
30
*
T3
7
44.736 Mbps
*
6
T4 274.176 Mbps
N.A.
*
24
J1 1.544 Mbps
*
4
J2 6.312 Mbps
*
5
J3 32.064 Mbps
*
3
J4 97.728 Mbps
Japan
Y(J)S MPV
88
TDM Structure
handling of TDM depends on its structure
unstructured TDM (TDM = arbitrary stream of bits)
…
structured TDM
framed
S
Y
N
C
(8000 frames per second)
S
Y
N
C
channelized
SYNC
S
Y
N
C
(single byte timeslots)
TS2
TS1
(1 byte)
TS3
…
signaling
bits
…
TSn
multiframed
frame
frame
frame
…
multiframe
frame
Y(J)S MPV
89
TDM PW Protocol Processing
TDM
IP Packets
IP Packets
TDM
PSN
Steps in TDMoIP
 The synchronous bit stream is segmented
 The TDM segments may be adapted
 TDM PW 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 MPV
90
TDM transport types
headers
TDM payload
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 MPV
91
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 MPV
92
TDM PW layering structure
PSN / multiplexing
Optional RTP header
TDMoIP Encapsulation (CW)
higher layers
SAToP
CESoPSN
AAL1
AAL2
HDLC
AAL1/CESoPSN used for preconfigured setup
AAL2 used for dynamic bandwidth
HDLC used for CCS signaling
Y(J)S MPV
93
TDMoIP packet format
IP header
(5*4bytes)
UDP header * (2*4bytes)
Optional RTP header (3*4bytes)
control word ** (4bytes)
TDM payload
Notes
* The UDP source/destination port number is used as a PW label
** The TDMoIP CW is essentially the header defined in the Martini drafts
Y(J)S MPV
94
TDMoMPLS packet format
outer
label
inner
label
control
word
TDM
Payload
• Inner and outer labels specify TDM routing and multiplexing
• Inner Label contains TDMoMPLS circuit bundle number
• The control word
• enables detection of out-of-order and lost packets
• indicates critical alarm conditions
• The TDM payload may be adapted
• to assist in timing recovery and recovery from packet loss
• to ensure proper transfer of TDM signaling
• to provide an efficiency vs. latency trade-off
Y(J)S MPV
95
TDM o L2TPv3
IP header
(5*4 B)
Session ID (4 B)
higher layers
Optional cookie (4 or 8 B)
TDMoIP control word (4 B)
TDMoIP payload
Note : No UDP header
Y(J)S MPV
96
Optional explicit timing
VoIP uses RTP (real-time protocol)
RTP can be used to transport timing across IP networks
It does this by providing:
 a 16 bit sequence number
 1 32 bit timestamp
at the expense of 12 additional overhead bytes per packet
Accurate timing is important in telephony
and IP networks add packet delay variation (PDV)
For TDM PWs, only the timestamp is needed
– encodes time of sending using clock N*8kHz
Y(J)S MPV
97
CESoPSN mode
PSN
CW T1/E1 frame
…
T1/E1 frame
Control word needed for sequence number
Otherwise a single lost packet could cause service interruption
Can efficiently handle fractional T1/E1
FRG field in CW enables support of multiframe


CAS signaling uses a superframe (16/24 frames)
Superframe/multiframe integrity must be respected
Y(J)S MPV
98
TDMoIP AAL1 mode
Packet loss, misorder, PDV problems can be solved by:




adding a packet sequence number
adding a pointer to the next multi-frame boundary
only sending timeslots in use
allowing multiple frames per packet
UDP/IP seqnum ptr
T1/E1 frames (only timeslots in use)
(with CRC)
for example
Good idea!
7
@
TS1 TS2 TS5 TS7 TS1 TS2 TS5 TS7
This is precisely AAL1 !
Y(J)S MPV
99
TDMoIP AAL2 mode
TDM frame
1
1
1
2
PSN hdrs
TDM frame
TDM frame
3
4
4
4
5
TDM frame
CW
2
2
hdr
1
2
3
4
TS1
3
5
3
hdr
1
2
3
TS2
TDM frame
4
hdr
5
1
2
3
5
4
5
5
TS3

Each minicell consists of a header and buffered data

Minicell header contains:
– CID (Channel IDentifier)
– LI (Length Indicator) = length-1
– UUI (User-User Indication) counter + payload type ID
Y(J)S MPV
100
Ethernet PWs
Y(J)S MPV
101
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 MPV
102
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 MPV
103
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 MPV
104
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 MPV
105
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 MPV
106
Ethernet Pseudowire packet (MPLS)
tunnel
label
PW
label
control
word
single Ethernet Frame
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 MPV
107
V B
CE
CE
B V
V B
CE
VPLS (L2VPN)
Y(J)S MPV
108
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 MPV
109
Basic (L2,L3)VPN model
physical link
customer
network
customer
network
emulated link
customer
network
Customer
Edge
(CE)
Provider
Provider
provider Edge
Edge
network
(PE)
(PE)
AC = Attachment Circuit
Customer
Edge
customer
network
(CE)
AC = Attachment Circuit
provider network may be L3 (e.g. IP) or L2 (e.g. Ethernet)
Y(J)S MPV
110
(L2,L3)VPN in more detail
C
C
C
C
CE
CE
C
C
customer 1 network
P
P
P
C
C
customer 2 network
P
provider network
CE
C
CE
P
PE
customer 2 network
PE
PE
C
P
C
C
CE
C
Key
Customer router/switch
Customer Edge router/switch customer 1 network
Provider router/switch
Provider Edge router/switch
Y(J)S MPV 111
VPN Challenges
192.115.243.79
192.115.243.19
SP
network
192.115.243.19
Security
Private IP addresses
Multiple higher-layer protocols
SP resource requirements
Complexity of provider - customer relationship
Y(J)S MPV
112
MPLS solves IP address problem
192.115.243.19
1
2
MPLS
network
1
192.115.243.19
MPLS label
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 MPV
113
2547bis (RFC 4364) L3VPNs
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
Y(J)S MPV
114
BGP MPLS VPNs (2547bis)
presently most popular provider managed VPN
originally specified in RFC 2547, update in 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 MPV
115
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 MPV
116
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.)
Y(J)S MPV
117
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 MPV
118
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 MPV
119
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 MPV
120
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 MPV
121
L2VPN vs. L3VPN
PE
CE
PE
CE
?
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 MPV
122
Distributed (Generic) VPLS
CE
U-PE
PE
access
N-PE network
VPLS
CE
CE
U-PE
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 Multi Tenant Unit applications
Y(J)S MPV
123
Hierarchical VPLS
PE
VPLS
MTU
PE
MTU
VPLS
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 MPV
124
MPLS-TP
Y(J)S MPV
125
Carrier Grade MPLS
Although designed acceleration of IP forwarding
MPLS is a generic transport technology
To be useful to carriers, it needs several additional features :
 ability to support various services, e.g., VPN
 determinism, scalability and reliability of existing CO transport networks
 OAM (fault and performance monitoring)
 protection switching (linear and ring)
 integration into operator’s NMS
This MPLS upgrade was initially brought to the ITU as
T-MPLS (Transport MPLS) in the ITU
It is now being co-developed by IETF and ITU as
MPLS-TP (MPLS Transport Profile)
Y(J)S MPV
126
What’s in MPLS-TP
MPLS-TP requirements defined in RFC 5654
As an MPLS profile, MPLS-TP

uses most of MPLS
– MPLS architecture and MPLS/PWE packet formats
– MPLS forwarding algorithm
– GMPLS signaling

does not use some MPLS features, e.g.
– ECMP
– MP2P LDP
– IP forwarding

and defines new functionality
– transport style layered OAM (MEPs/MIPs, AIS, alarms, …)
– resilience (sub-50 ms protection switching)
– static provisioning
Y(J)S MPV
127
GACH
MPLS-TP defines a Generic Associated Channel (GACH)
based on a Generic Alert Label (GAL) (reserved label 13)
MPLS label
GAL (label 13)
PWE ACH
ACH TLVs
Payload
(OAM/DCC/protection)
Y(J)S MPV
128