Transcript RFC3031 Multiprotocol Label Switching Architecture

RFC 3031:
Multiprotocol Label
Switching Architecture
Chapter 3.27 – 3.30
2005/07/14 (Thu)
Shinichi Ishida
3.27. Tunnels and Hierarchy
Ru takes explicit action to deliver packet to Rd,
even though Ru&Rd is not consecutive
and Rd is not the ultimate destination
=> encapsulate the packet inside a network layer

Hop-by-Hop Routed Tunnel
Tunneled Packet follows the Hop-by-Hop path

Explicitly Routed Tunnel
Tunneled Packet travels over
a path other than the Hop-by-Hop path
3.27.3. LSP Tunnels
implemeting a tunnel as a LSP
use label switching rather than network
layer encapsulation
the set of packets through the LSP tunnel constitutes a FEC,
each LSR in the tunnel must assign a label to that FEC.
3.27.4.
Hierarchy: LSP Tunnels within LSPs
R1 L
IP
R4
R2
L
L
IP
IP
R3
R22
R21
R23
L
IP
IP
3.27.5. (1/3)
Label Distribition Peering and Hierarchy
R1
R3
R2
IGP neighbors
R21
when two LSRs are
IGP neighbors > local label distibution peers
not IGP neighbors > remote …
3.27.5. (2/3)
Label Distribition Peering and Hierarchy
 Explicit
Peering
distribute labels by sending messages which are
addressed to the peer
useful when
the number of remote peer is small
the number of higher level label bindings is large
the remote peers are in distinct routing areas
3.27.5. (3/3)
Label Distribition Peering and Hierarchy
 Implicit
-
Peering
encode a higher level label as an attribute of a lower label
distribute the lower leve label to local peers
local peers propagate the information to their local peers
continue till the information reaches the remote peer
useful when
the number of remote peers is large
(not require n-square peering mesh)
3.28. Label Distribution Protocol Transport
label distribution protocol :
establish and maintain the label binding
Needs:
reliability, in sequence, flow control
use TCP as the underlying transport
[MPLS-LDP] [MPLS-BGP]
3.29. Why More than one
Label Distribution Protocol ?
‘which’ label distribution protocol to use
in ‘which’ circumstances ?
# this architecture does NOT establish
hard and fast rules for choosing
point out some of the considerations
in the following sections (3.29.1 – 3.29.3)
3.29.1. BGP and LDP
desirable to bind labels to FECs idetified
with routes to address prefixes
If there is
a standard, widely deployed routing algorithm
-> label distribution is best achived
by piggybacking on that
ex) BGP
a number of advantages
RR:significant scalability
3.29.2.
Labels for RSVP Flowspecs
When RSVP is used for particular flows
desirable to label the packets in those flows
→ RSVP filterspec:
not need to be applied at each hop
most efficient method of distributing labels
= having RSVP distribute the labels
as part of its path/reservation setup process ?
3.29.3.
Labels for Explicitly Routed LSPs
It is desirable for traffic engineering
- to set up an explicitly routed path
- to apply resource reservations along that path

two approaches
start with existing protocol extend to support
example
1 resource reservations
explicit routing & label
distribution
MPLS-RSVPTUNNELS
2 label distribution
explicit routing &
resource reservations
MPLS-CRLDP